DAC-use-cases

Use cases for end to end implementations of detection-as-code (DAC)

Core Components of DaC within Elastic

• CC1: Maintaining rules within a Version Control System (VCS)
• CC2: Syncing rules from VCS to Elastic Security
• CC3: Managing rules within Elastic Security (consistent with a DaC approach)
• CC4: Syncing rules from Elastic Security to VCS

Governance Models Dictating the Core Components of DaC

• GM1: VCS as authoritative
• GM2: Elastic security as authoritative
• GM3: Dual sync between VCS and Elastic Security (optional)

Use cases

use case	governance model	CC1	CC2	CC3	CC4	notes
infosec	GM1	no DR repo usage use of custom rules create detection rules in kibana and export versioning? custom exceptions and actions management custom unit tests limited rule schema validation no detection logic validation	deploy via CI/CD and custom REST calls	manual management and tines	tines to push based on X trigger? (or schedule?)	need to verify; grimoire
fork DR	GM1	DR repo usage use of custom rules create detection rules in kibana and export versioning using lock files custom exceptions and actions management custom unit tests rule schema validation detection logic validation	use of detection-rules repo features for syncing	syncing handled via VCS with limited direct management in Elastic Security	not applicable or minimal use	Leveraging detection-rules repo for rule maintenance
import DR	GM3	import rules via detection-rules libraries	automated syncing to Elastic Security	manual rule management within Elastic Security	syncing back to VCS as part of dual sync process	Import libraries to assist dual sync
platform centric MSSP	GM2	secondary role of VCS	infrequent or batched syncing to Elastic Security	primary rule management within Elastic Security	infrequent syncing back to VCS, if at all	Elastic-centric rule management for multiple clients

Reference Automation Workflows in DaC

In practice, the Detection as Code (DaC) approach within Elastic Security leverages a series of GitHub Actions workflows to automate various synchronization tasks. These workflows facilitate the continuous integration and deployment of detection rules, ensuring that they are consistently aligned with the latest developments and threat intelligence. The following workflows can be found in the .github/workflows directory:

• Push to Production Sync: Automates the process of pushing verified rules from the Version Control System to the Elastic Security environment upon changes being merged into the main branch.
• Manual Dispatch Sync Workflow: Allows repository maintainers to manually trigger a rules synchronization, providing control over when rules are updated in Elastic Security.
• Scheduled Sync Workflow: Executes at predetermined intervals to check for and synchronize any updates from Elastic Security, ensuring the detection rules are current.
• CI/CD Per-PR Sync Workflow: Runs a series of checks on pull requests to validate rule changes before they are merged, ensuring that all updates meet the defined standards for detection rules.

These workflows are essential tools in managing the lifecycle of detection rules, contributing to a robust and responsive security posture.