Alexey Peshik, Security Vision
Over the last decade, we have learnt that manual investigation and response processes are limiting us in terms of speed, which greatly affects our ability to handle the growing flow of incidents and threats. To help address this situation, IS professionals are beginning to adopt new approaches such as Everything as Code (EaC), which originated from software development practices.
One of the main problems of incident detection, Threat hunting and threat detection (TI) procedures is the high granularity of scripts and functions, the need for version control and change accounting. Therefore, information security engineers, in an effort to increase detection efficiency and improve the quality of work have adopted best practices from IT development and called this method Configuration-as-Code. Let's understand what it is.
What is detection-as-code?
Configuration-as-Code (or CI/CD in information security) is the division of processes and procedures into maximally atomic functions, which are handled in a code-like manner: they are separately stored, edited, versioned, tested, analysed for quality and subsequently used in completely different processes if necessary.
For example, the account audit procedure:
firstly, is broken down into many implementations and versions depending on the tools used;
Secondly, the same procedure is used in different processes: in incident management, in asset management and in any other processes as needed.
If different specialists need to adjust it, the same code will be edited and everyone will see each other's edits.
Similar to the Everything as Code (IaC) concept, Configuration-as-Code (CaC) uses a machine-readable file format and describes scalable data models that allow any infrastructure to be built, unconstrained by data volumes, types and structures.
An analogy can be drawn here with DevOps, which uses practices that help build large, complex pipelines from bricks and mortar. So, security management processes can also be decomposed, divided into atomic functions, repeatedly reusing clearly working cogs in a large well-coordinated mechanism.
Similar to the CI/CD workflow, the process of developing and implementing IS functions should include the following mandatory steps:
1. identification of the logic behind suspicious or malicious behaviour;
2. Reproducing (modelling) this behaviour in code. For example, if a process is launched from a non-standard parent - triggering;
3. Writing various test cases to verify the functionality of the function;
4. Incorporating the function into the version control system;
5. Building, rolling it out into a prod, building a build;
6. Continuous support, update (the IS feature support process works in a PDCA cycle of continuous update and support, for completely different cases of deviations, violations of correctness of operation).
These steps show that the Configuration-as-Code workflow should consider a procedure to improve the existing IS function repository. If necessary, for each function, it is possible to go back to the first step and roll out complex operations again through the test and rollout procedure.
The Detection-as-Code concept emerged from the need for automated, systematically repeatable and fixable approaches to security, which is its value. Threat detection had not previously been fully developed as a systematic regular discipline with effective automation and capture of results.
A threat detection method tailored to specific environments and systems has a more powerful effect. Using well-written detection code that can be tested and validated in a version control system allows engineers to create better 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 your own flexible discovery tools using a programming language;
2 Adopting a development through testing (TDD) approach;
3. Integration with version control systems;
4. Automation of workflows;
5. Code reuse.
Writing discovery in a common, flexible and user-friendly language such as Python has many advantages.
Convenience and simplicity
Instead of using object-oriented languages with some set of constraints, you can create more customised and complex discovery methods to suit 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 benefit 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 greatly enhance detection and automation.
TDD
Quality assurance of detection code helps identify blind spots, check false positives, and improve detection efficiency. The TDD approach enables security teams to anticipate attackers‘ actions, document the insights gained, and build a library of analytics about attackers’ strategies and routes.
In addition, the TDD approach improves the quality of detection code by making it more modular, extensible, and flexible. Engineers can easily make changes to their code without fear of disrupting alerts or weakening infrastructure security.
Version control systems
When writing or changing discoveries in the form of code, version control allows experts to quickly revert to previous states in the event of errors. Version control can also provide necessary information for specific detections that trigger alerts or help identify changes to detections.
Detection methods must evolve as new data becomes available. Change control is an important process to help teams adjust discoveries as needed. An effective change control process improves documentation and validation of all changes.
Automate security processes
Information security engineers who were expecting a shift in automation will benefit from the integration of the CI/CD pipeline. Implementing it early in the delivery process helps achieve two goals:
Eliminating silos between teams that work on a common platform and test each other's code;
Providing automated testing and delivery systems to detect security breaches. Security teams retain flexibility by focusing on building accurate detection systems.
Re-using their work
Finally, Detection-as-Code promotes code reuse for a wide range of detections. As information security engineers write code for detection, they begin to identify non-obvious patterns and repeated repetitions of procedures. This decomposition provides an opportunity to optimise the process and reuse the code in similar cases in other detections.
Conclusion
Each infrastructure is unique and requires a customised approach to detection methods. The concept of Detection-as-Code (DaC) allows IS engineers to create customised rules, making regular improvements through code testing, managing versions through various software tools. The flexibility and robustness of programming languages can detect both simple and complex actions of attackers, while providing the necessary contextual enrichment. As part of this approach, experts even structure and normalise logs into a rigorous schema for executing SQL queries, which helps in the study of fault tolerance when processing large volumes of security event data.
Discovery as Code (DaC) is taking its rightful place alongside Infrastructure as Code (IaC) under the rapidly evolving concept of Everything as Code (EaC), where each layer of the stack is expressed through code.
