Configuration-as-Code

One of the main issues in incident detection, Threat hunting procedures, and threat detection (TI) is the high granularity of scripts and functions, the need for version control, and tracking changes. Therefore, information security engineers, striving to improve detection efficiency and work quality, have adopted the best practices from IT development and named this method Configuration-as-Code. Let's figure out what it represents.

What is detection as code?

Configuration-as-Code (or CI/CD in information security) is the division of processes and procedures into the most atomic functions, which are handled in the same way as code: they are stored separately, edited, versioned, tested, analyzed for quality, and subsequently used as needed in completely different processes.

For example, the account audit procedure:

• firstly, it is divided into many implementations and versions depending on the tools used;

• secondly, the same procedure is used in different processes: in incident management, asset management, and any others as needed.

If different specialists need to adjust it, the same code will be edited, and everyone will see each other's changes.

Similar to the concept of Everything as Code (IaC), Configuration-as-Code (CaC) uses a machine-readable file format and describes scalable data models that allow building any infrastructures, regardless of volumes, types, and data structures.

Here you can draw an analogy with the DevOps direction, which uses practices that help build large complex pipelines from bricks. So, security management processes can also be decomposed, divided into atomic functions, repeatedly reusing clearly working cogs in a large coordinated mechanism.

Similar to the CI/CD workflow, the process of developing and implementing security functions should include the following mandatory steps:

1. Identification of suspicious or malicious behavior logic;

2. Reproduction (modeling) of this behavior in code. For example, if the process is started from a non-standard parent - trigger;

3. Writing various test cases to check the functionality;

4. Including the function in the version control system;

5. Build, deploy to production, build the build;

6. Continuous support, update (the process of supporting the security function works in the PDCA cycle of continuous updating and support, for completely different cases of deviations, violations of correct operation).

These steps show that the Configuration-as-Code workflow should take into account the procedure for improving the existing security functions repository. If necessary, you can return to the first step for each function and run complex operations again through the testing and deployment procedure.

The concept of Detection-as-Code arose from the need for automated, systematically repeatable, and recordable security approaches, which is its value. Previously, threat detection was not fully developed as a systematic regular discipline with effective automation and recording of results.

The threat detection method, adapted to specific environments and systems, has a more powerful effect. Using well-written detection code that can be tested and verified in a version control system allows engineers to create higher quality alerts and reduce false positives, reducing burnout and eliminating unnecessary activity.

What are the benefits of Configuration-as-Code?

The benefits of Configuration-as-Code include:

1. Creating custom flexible detection tools using a programming language;

2. Applying the test-driven development (TDD) approach;

3. Integration with version control systems;

4. Workflow automation;

5. Code reuse.

Writing detections in a common, flexible, and convenient language like Python has many advantages.

Convenience and simplicity

Instead of using domain-specific languages with some set of limitations, you can create more customized and complex detection methods that meet the specific needs of your infrastructure. These language rules are also often more readable and easier to understand, which can be critical as complexity increases.

Much has already been developed for you

An additional advantage of using a common language is access to a rich set of built-in or third-party libraries developed by other security professionals. For example, libraries for interacting with APIs significantly increase the efficiency of detection and automation.

TDD

Ensuring the quality of detection code helps identify "blind spots," check for false positives, and improve detection efficiency. The TDD approach allows security teams to anticipate attacker actions, document the knowledge gained, and create a library of analytical data on attacker strategies and their routes.

In addition, the TDD approach improves the quality of detection code, making it more modular, extensible, and flexible. Engineers can easily make changes to their code without fear of disrupting alerts or weakening infrastructure security.

Writing detections in a common, flexible, and convenient language like Python has many advantages.

Version control systems

When writing or modifying detections in the form of code, version control allows specialists to quickly revert to previous states in case of errors. Version control can also provide the necessary information for specific detections that trigger alerts or help identify changes in detections.

Detection methods must evolve as new data becomes available. Change control is an important process that helps teams adjust detections as needed. An effective change control process improves the quality of documentation and the review of all changes.

Automation of security processes

Information security engineers who have been anticipating a shift in automation will benefit from the integration of the CI/CD pipeline. Implementing this method at the early stages of the delivery process helps achieve two goals:

• Eliminating fragmentation between teams that work on a common platform and review each other's code;

• Ensuring automated testing and delivery systems to detect security breaches. Security teams maintain flexibility, focusing on creating accurate detection systems.

  Reusing their work

  Finally, Detection-as-Code promotes code reuse for a wide range of detections. As security engineers write detection code, they begin to identify non-obvious patterns and repeated procedures. This decomposition allows optimizing the process and reusing code in similar cases in other detections.

  Conclusion

  Each infrastructure is unique and requires an individual approach to detection methods. The concept of Detection-as-Code (DaC) allows security engineers to create individual rules, regularly improving through code testing, managing versions with various software tools. The flexibility and reliability of programming languages allow detecting both simple and complex attacker actions, while providing the necessary context enrichment. Within this approach, specialists even structure and normalize logs into a strict schema for executing SQL queries, which helps in studying fault tolerance when processing large volumes of security event data.

  Detection-as-Code (DaC) takes its rightful place alongside Infrastructure-as-Code (IaC) within the rapidly evolving concept of "Everything as Code" (EaC), where every level of the stack is expressed through code.