Open TwistMeister opened 1 year ago
The requirements for now are:
As a developer I want to define (custom) procedures for my organisation by writing Bits and json schemas defining my questions
As a redteamer
I want procedures to be triggered upon a relevant (set of) OOIs (regular BIT functionality)
I want every step of the procedure to be stored and documented (every step is a new QuestionOOI bound to the triggering OOI as defined in the BIT for this step. The Bit also carries the jsonschema which posed the question, The form then submits to Bytes and is processed into a new OOI containing the answer which in turn might trigger a secondary BIT for this procedure, repeating the cycle)
I do want a procedure to disappear once the related Finding(s) is/are deleted. But it should be present in the history.
I do not want to have to upgrade my KAT installation to add new procedures. They should be part of the BITS plugin list.
Questions:
Can I properly pre-define procedures or do I need the flexibility to adapt it along the way?
Procedure refinement is done outside of KAT, however, a new version of the procedure might be required at some point which means new BITS.
Should Redteamers always be able to perform steps in name of another organization member (possibly not a user in KAT)?
No.
Should we be able to retrieve all raw data at once from Rocky?
No, step by step is fine.
As an auditor
I want to be able to see when each step of the procedure was performed by whom.
Correct, but this is something we need to fix for every declared object, indemnification etc.
For a specific step of a procedure, I (might) want to retrieve information about:
How many times it has been performed
Should be a fairly straight forward query.
Histogram of what the next steps were
Maybe, but not for this version
Issues
Context
KAT being a tool for tracking vulnerabilities, it has the power to extend its functionality to track the actions that follow the vulnerabilities. These are often documented in procedures. Procedures differ per organisation and per Finding. They might involve input from an organization member, permissions for downtime from management, software to be updated and lots of other kinds of actions. They can be captured in a decision tree, such as this small example of a decision when we experience a DDoS attack:
This perhaps should be captured in a Directed Acyclic Graph, the common data structure to de fine a workflow.
Examples
Sequence Diagram
The flow for when missing TLS triggers a list of steps in a mock procedure:
Resulting Entities
Requirements
As a redteamer
Questions:
As an auditor
Technical Details
Data to bytes
This requires the option to save raw files to Bytes, since the recorded steps need to be documented. This is a minimal backend feature since a
BytesClient
is present.JsonSchema OOIs
Somehow Octopoes should provide a structured view of the Procedure, as that is Octopoes' responsibility: a structured view of the raw data. Besides, XTDB is a good tool to track entities over time, allowing the lifetime of a procedure to be queried and displayed in Rocky.
Technically there are a few challenges flowing from the requirements:
@underdarknl had the idea to create JsonSchema OOIs that represent Questions and Answers:
@Donnype had the idea to collect a procedure in one aggregate object with a step(s) field that keeps track of what the present and completed steps are:
Concrete Examples of use-cases
TODO (@underdarknl)