search

BIGred053 / edr-agt-tester

0 stars 0 forks source link

High-Level "Plan of Attack" #2

Open BIGred053 opened 3 years ago

BIGred053 commented 3 years ago

General Approach

  1. Focus on *nix systems first, add Windows support if time provides
  2. Focus first on inflexible implementations (hard-code commands, filenames, data and destination addresses) for simplicity and to help generate expected results to validate behavior against a. Iterate within each "activity type" to add more dynamic behaviors where required (i.e. enabling users to provide an executable, filename and path, etc.) b. Iterate on entire design to add UX improvements if time allows
  3. Start by "baking in" known values, strive for more dynamic data collection via system commands if there is time to allow for this and if this is a desired behavior

Sequence of Features

  1. Build base logging, since process-related data (timestamp, username, process info) is a shared concern for all logging
  2. Start with "File Operations" activity type, since working with Files via Ruby is a known quantity for me a. Create, modify, and delete based off of a fixed "default" filename, type, and path within the program + base logging b. Add file-specific logging behavior via a decorator c. Add the ability for users to define file type and path
  3. Add "Process Spawning" behavior, since the logging is all covered by the base logging class, so all that is unique is the functionality a. Create a process using a fixed "default" process (e.g. ruby process_test.rb- prints out foo) and log data b. Add the ability for users to define their own executable
  4. Add "Network Activity" last, since this involves additional logging behavior and new functionality. a. POST data via HTTP/HTTPS to a fixed URL + base logging for this process (Unless answers from #1 indicate curl or some other approach is preferred to have a distinct process focused on network activity) b. Add network-specific logging behavior via decorator
  5. Tie everything together via a centralized "application" that can run everything, or can intake user flags to only run specific portions of the utility

Optional Extensions

  1. Investigate/Implement data management with logs to avoid log file size inflation
  2. Add the ability for the user to define a destination to which log results can be posted for validation
  3. Consider and implement UX improvements
  4. Add dynamic data collection for network operations, if desired
  5. Consider some sort of pattern (perhaps Observer or Facade) that could be utilized to automatically execute tests when the EDR agent is updated for validation.