hawk-soard 0.1.1

HAWK SOAR Daemon

Coding guidelines: Doc Strings https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html

pep8 (enter steps to configure git commit to use style guidelines)

classes should be camel case e.g. class HawkSoarAPI() functions should be snake e.g. def my_func()

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

File structure: hawk-soard - HAWK SOAR Application hawkSoar - Main Project app folder lib - Library code: API code for talking to different API's, including logging in. unit - Folder for holding unit test for library code. cache.py - Local helper to set and get cache creds.py - For getting creds from Vault database.py - sets up cache database tables, also query functions eyecon.py - API helper functions for Communicating with standard API calls getting events, agents, etc marketplace.py - API helper functions for Communicating with marketplace API login, getting plugin details, download plugins soar.py - API helper functions for communicating with SOAR API. Get task, Return results from task. common - Common code that can be used anywhere common.py - common functions process.py - common functions for interacting with processes manager - Manager code for different parts of the program cache.py - cacheManager code that manages getting and setting data to cache and syncing with remote cache manager.py - Main manager that starts all the other managers. Manages data between the different managers marketplace.py - Detects new plugins to be installed and installs them and notify the PluginManager of new plugins. Updates Cache plugin.py - For handling registering and deregistering plugins. is responsible for maintaining the state of the registered plugins, broadcasting the registry of those plugins and fielding requests that come in. task.py - taskManager get's task from SOAR API then directs the task to the correct plugin. Returns results to SOAR API. Scheduler marketplace - Where the plugins will be installed in the appropriate folder based on type. contain decision include
ingest investigate network_utilities - Test plugin to build plugin template. code - Where the plugin's code exist html - HTML templete code for plugins view on dashboard. test - Unit test for testing plugin's code. uses investigate_plugin_test_class.py notify record recover utility plugins - Plugin template code investigate - Plugin template for investigate plugins PluginBase.py - Plugin base template code for investigate plugins base.py - Plugin template code for all plugin types test - Unit test unit - Unit test investigate - unit test for investigate plugins investigate_plugin_test_class.py - Plugin unit test code for investigate plugins. Used by code in plugins unit test. errors.py - Custom exceptions logger.py - Logging for program models.py - data models for task objects used by plugins parse_config.py - Parse hawk-soard.cfg file (might be moved to helper_functions.common.py) rpm - Files for building RPM package hawk-soard.spec - Spec file for generating RPM hawk-soard - starts application, daemonize requirements.txt - used for non-rpm install with pip, list all required software to be installed setup.py - install application

Execution Workflow:

Manager starts, needs config

• soar api needs initializing and login
• via soar api, a list of playbooks is pulled
  • get playbooks api code
• load all available plugins?

  • but do not start plugin unless in playbook

  • only 1 instance of plugin runs at a time (for now, can try parallel in future), and answers any questions sent to its queue (incoming/outgoing)

  • run start method if found

  • manager or communication service is responsible for owning the websocket connection, and listening to all outgoing plugin queues and sending the response at the same time, it will be listening to all websocket requests and placing them in the proper plugin incoming queue task broker class

  • initializing the run-time configuration

    • inside manager: for each playbook
      • for each step:
        • initialize each module with given config inside the step to listen for events and pre-process or w/each
        • also pass the given steps playbook data config, so it knows what steps are next and whats previous, or if we're the end.

  • runtime behavior

    • does each step block until other plugins in given step complete? thus providing a total answer? blocks/delays but guarantees message totallity?