Patrick Bareiss

Continuous Integration (CI) and Continuous Delivery (CD) is a well-known concept in software development. In this blog post, I will introduce the concept of CI/CD and adapt it to the IT Security world based on the example of detection rule development.

Continuous Integration (CI) means that the main branch is continuously validated by creating a build and running automated tests against the build. CI focusing on automating the testing process to ensure that the application is not broken. Continuous Delivery (CD) is an extension of CI and focusing on a fast and sustainable way of code release to the customer.

In order to make the CI/CD process in software development more clear, I will use the following picture to explain the process:

In this example, we have two developer and a scrum master. Developer 2 developed a new feature and (1) pushed the code to the Version Control Server (e.g. Gitlab). Subsequently, the code is pushed (2) to a build and test server (e.g. Jenkins). The code is built and afterwards tested against multiple defined test scenarios. This process is called CI. The result is reported to the development team (3). Furthermore, if all test scenarios were successful, CD can be used to deploy the application (3). The application can be deployed (4) either on a Development (DEV) or a Production (PROD) environment. If the application in PROD doesn’t work as expected, issues are created in a ticketing system (5). These issues will be solved in future releases and is divided between the developer (6).

After introducing the CI/CD process in traditional software development, we want to adapt this process into the IT Security world. We will use the detection rule development as a successful example of adapting CI/CD in IT Security.

We have the same starting point as the previous example: a team of two developer and one scrum master. Developer 2 was developing a new detection rule in Sigma and pushing it to the Git server (1). Subsequently, the CI/CD module is triggering the Continuous Integration (2). CI is converting/building the Sigma detection rule into a Kibana or Splunk search. Afterwards, the detection rule is tested with Atomic Red Team. When the detection rule was successfully tested, the Sigma rule get delivered either to a development (DEV) or production (PROD) environment using Sigma2SplunkAlert converter or a similar tool for ELK (3,4). Docker and/or Gitlab Runner can be used for the Continuous Delivery (CD) process. In the production environment, issues can be used to control the continuous detection rule tuning and improvement process (5). These issues are assigned to Developer in a future release (6).

Thank you for reading.