Provide privileged user approval workflow for scenarios and payloads

[damians-filigran]

Context / User Story

As a security team at a large enterprise, we are very mindful of the risk of security controls impacting company operations, including interrupting a revenue-generating system or business process, or breaching a compliance requirement.

A technical example of this might be to stop a logging service on a production system, or deleting logs. If this is a regulated system, such as falling under PCI-DSS, then stopping that logging service could lead to a non-compliance at the next PCI-DSS audit.

As such, it would be necessary for all scripts, including payloads from injects, to be reviewed by the relevant compliance team and asset owner, to confirm that the scenario would not cause a production system interruption, compliance breach, or other high severity issue.

Benefits

Having such an approval process would assist uptake of BAS solutions in large enterprises with these concerns. It would facilitate the sponsorship of a more widespread BAS programme with the owners of the assets that the security team would like to deploy OpenBAS agents to, and also provide an overarching assurance layer, by using tags to mark particular assets or payloads as 'out of bounds' that would
ease any reservations from IT leadership. This is an example of the cybersecurity metaphor of "install stronger brakes, so that we can feel safe to go faster".

Proposed Solution

As a MVP, it is proposed to have an administrative option in platform configuration to enable "Scenario approvals". There would be a radio button in platform configuration to enable this option, and then an exposed configuration option that allows fine-grained configuration to fit the organisation's workflows.

The proposal is to keep the structure as simple as possible, allowing users to adopt and adapt it to fit their needs. This would be by using tags. Tags would be applied to both assets, and payloads, for which approvals would be required.

The dedicated configuration screen would allow labels to be mapped to users. eg. "Asset - Finance" mapped to "Sr A. Countant". This would indicate that for any asset or payload with the tag 'Asset - Finance', the user 'Sr A. Countant' would need to provide their approval before the scenario that targets their asset can be run.

When preparing a scenario, as the analyst is adding assets and payloads, OpenBAS would check the tags associated with those assets and payloads, and check if they are present in the Scenario approval configuration map. If the tag is present, then it means that that authorised user must approve the scenario before it can be run.

All 'Scenario Approval'-mapped tags will be shown at the bottom of the scenario overview in an "Approvals required' checkbox list, one checkbox for each tag. These appear dynamically as assets/payloads are added. For most users, these checkboxes are greyed out. Only the users mapped to that tag in the configuration screen have rights to check/uncheck those checkboxes. The system would then only allow the scenario to be run once all the tags present in this list have been checked.

This approach would allow:

• Use of existing mechanisms (tags)
• Red teamers to be aware of assets/payloads that require approval, as they're designing the scenario, in advance of it being run, and to decide whether or not to remove them
• Approvers to view all tags relevant to them
• Use of any other reporting, filtering, API, etc. methods for editing OpenBAS content, to manage and report on tagged/approval processes