The Detection-As-Code (DaC) approach to cybersecurity

Today, manual threat detection processes are becoming obsolete. Detection engineering can advance security operations, especially detection as code (DaC), which is a very suitable approach to threat detection.

Performing detections allows defining the logic for analysing data from different security logs and deciphering what behaviour attackers exhibit. Thus, with this type of detection, when an attack rule is met, an alert is sent to the cybersecurity team to investigate and resolve it.

DaC is a flexible, structured approach to writing detections that applies software engineering best practices to cyber security. Teams can create scalable processes to write and enforce detentions and identify sophisticated threats in rapidly expanding environments.

What is the DaC?

As mentioned, DaC is a systematic and comprehensive approach to software-driven threat detection, i.e. machine-readable definition files and descriptive models.

The stop-as-code approach is structured to analyse security log data that is used to identify the behaviours of cybercriminals. Writing expressive detentions and automating responses in code allows security teams to create scalable processes to identify sophisticated threats in rapidly expanding environments.

Combining detection engineering with the set of practices and systems can deliver modern, effective threat detection to drive any company’s operations, as was once the case with DevOps. A detection engineering workflow follows the following steps:

1. Observe suspicious or malicious behaviour.
2. Model it in code.
3. Write several test cases.
4. Commit to version control.
5. Deploy to test and then to production.
6. Tune and update.

Thus, detection as code arises from the need for automated, systematic, repeatable and predictable approaches to security. So problems can be fine-tuned to particular system environments. Also, security teams can produce high quality alerts that quickly indicate the possibility of threats, through well-written code, source control verification and peer review.

Implementation of the DaC

A first phase of the DaC implementation is to establish a channel that allows the company to submit requests for new detectors, i.e. employees must be able to submit communication ideas via the new request function built into an SCM platform. They should also create templates to ensure that all the data needed by detection engineers is entered. These engineers must set up detection sprints to track performance and guide the entire company on which detection issues to prioritise.

The second phase involves the development of the detector, the detection engineer must create a template that will be used in the construction of the detector itself. This template should be written in a format that is easy to parse programmatically and human readable, such as YAML/TOML. Once this template is created, the logic of the detector must be identified. This may mean performing some localised tests in a test environment to obtain the initial logic.

Phase three is the testing phase, where tests are run against the new detector code. If they pass the tests they are integrated into the CI/CD pipeline. Once the tests are fully completed, a peer review is performed to verify the code accurately against the problem described in phase one.

Finally, in phase four, once the development branch has been merged with the master branch, the CI/CD tools read the code configuration. If set to “active”, the CD tools attempt to implement the rule logic in the detection platform listed in the configuration file.

Benefits

The benefits of DaC include general detection capability, flexibility and customisation using a recognised programming language such as Python. Languages such as Python allow more sophisticated detections to be written, using rules that tend to become more readable and easier to understand as the complexity of the code increases.

An additional benefit of using languages such as Python is the ability to use a set of built-in or third-party libraries to communicate with APIs, which improves detection efficiency.

Another major benefit of this approach is to detect blind spots early on, cover testing for false alerts and promote detection efficiency, provided there is adequate quality control for the code. Therefore, employing a test-driven development (TDD) approach makes it easier for cybersecurity teams to think about how an attacker would do it, analyse that information and understand how the attack lifecycle works.

Using TDD is a validation of code correctness that improves code quality and allows for more modular and flexible detections. In addition, changes can easily be made to your detection without interrupting alerts and code operations.

On the other hand, when new modifications or detections are written, version control allows teams to roll back to the previous state and indicates whether teams are using the most up-to-date detection.

As new data and additional features are introduced into the system, the detections must also be modified. Change control is therefore essential to adjust detections as necessary and to ensure that changes are documented and reviewed.

Also, the use of a CI/CD pipeline helps eliminate silos between teams because they work together on a common platform, review each other’s code, and proper organisation is maintained. In turn, test channels are provided and automated for security detections. Teams can continue to work in an agile manner by focusing on accurate detections.

Finally, DaC can encourage code reuse across a large set of detections. This ability to reuse code is used to perform the same or a very similar function across different detections without the need to start a code from scratch. Code reuse allows functions to be shared between elections or to adapt detection for specific uses.

In short, as the security department writes detections over an extended period of time, it begins to identify patterns as they emerge, and it is here that existing code can be reused to meet the needs of different detections without starting from scratch.

Conclusions

In conclusion, every environment is different and each needs a different set of detection solutions. For this to be possible, cybersecurity teams must create customised rules to have version control suited to their needs.

The flexibility of an expressive programming language makes it possible to detect advanced or simple behaviour, search for context and analyse the events that occurred. DaC makes it possible to write flexible, company-specific detections.

Cybersecurity teams can structure and normalise logs in a strict schema for querying and analysing large volumes of security data. DaC together with Infrastructure as Code (IaC) form the emerging idea of Everything as Code (EaC), where at every layer of security, everything is expressed in code.