A conceptual generic overview of DaC

DaC is much younger, and so not yet as mature as the other as-code or code-centric paradigms. The challenge this presents is that high level concepts are less discussed and agreed upon, with most of the attention being anecdotal or focused on very specific implementations within specific technologies and products. It would benefit the industry to establish more conceptual workflows or reference architectures at a higher level.

In order to simplify the understanding of DaC and to be able to approach it from a conceptualized model prior to putting it into practice, we will first aim to establish that higher level conceptualized overview, including defining a hierarchical relationship between major components and structuring some common lexicon.

Note: for the sake of simplicity, we will refer to rules throughout this DaC section, when in reality, they mostly can be replaced by any detection capability.

Core components of DaC delineation

The core components are the top level of a full hierarchy of components and considerations.

First, the top level hierarchy can be broken down as follows:

Fig. 47 Mind map of the related components of DaC

The core components set the foundation for DaC and establishing a hierarchical relationship of components and considerations. They should be applicable across any environment or technology stack.

The core components consist of the following:

#	Core Component	Description
1	Maintaining rules within VCS	Rules managed in version control such as GitHub
2	Syncing rules from VCS to security platform	How the rule updates get to the platform
3	Maintaining rules within security platform	Rules are managed within the respective security platform
4	Syncing from security platform to VCS	How the rule updates get from the platform

To get a better understanding of the core components as well as the full hierarchy, here is an example broken down to the consideration level:

Core Components	Sub-components (optional)	Options	Considerations
Maintaining rules within VCS	Creating Detection Rules	Manually Creating Rules Based on Template	Copy template file
			Generate template dynamically from schema
			Auto suggest and validate with VSCode extension
		Dynamic rule builder	Generate interactively with CLI
			Generate from web form
		File format	TOML
			YAML
			JSON
	Rule versioning	Abstracted implicit versioning	Hash rule changes and lock on release builds
			Insert version on specific merge flows
		Manually versioning	Add to the rule file
Syncing rules from VCS to security platform		Cron based syncing	GitHub action workflow
			Buildkite automation
			Pull from platform
		Sync on merge flow	Push on merge to main
			Push to Kibana space based on branch name

The difference between a sub-component and an option is that all components and sub-components must be accounted for, whereas options are mechanisms to solve the component piece.

The further down the hierarchy is traversed, the less exhaustive and specific it becomes, as it will be more dependent on the specifics of the implementation. For the sake of showcasing their purposes, we will focus on some of the more common ones, which likely will be present in most scenarios.

Governance models of DaC Delineation

The next most important consideration is the control of the flow of updates. There are many options and discrete interactions across the entirety of DaC, so it is imperative that the expectations and assumptions of the authoritative flow of data are compliant. For this, we introduce three governance models which account for the majority of use cases.

#	Governance Models	Description
1	VCS as authoritative	Updates flow from VCS to platform
2	Platform as authoritative	Updates flow from platform to VCS
3	Dual sync between VCS and the platform	Updates can be made within the platform or VCS but sync collisions must be handled

The decision on what governance model to apply should be made early, because many of the considerations from the previously discussed hierarchy have a lot of implementation details which will differ based on this decision.

A diagram of what the governance models look like across the core components can be found below:

Fig. 48 DaC core components and governance models

Implementation flow

The final high level concept is the implementation flow, which is the exact flow implemented, across the individual components, options, and considerations.

Bringing it all together

To summarize the relationship between the major topics:

• The core components of DaC

  • Primary considerations across all use cases

  • Consists of options and considerations

• The governance models of DaC

  • Dictates the authoritative flow of updates across the core components

• The implementation flow of DaC

  • Details the specific flow of updates based on implemented criteria