Tired of chasing alerts and feeling like you’re constantly one step behind attackers? In today’s threat landscape, traditional security operations are like running on a hamster wheel – exhausting and ultimately ineffective. SOC teams are drowning in alerts, struggling to manage disparate tools, and facing burnout from the relentless pressure. It’s time to break free from the cycle of reactive security and embrace a new approach: Detection-as-Code (DaC).

Think Like a Developer, Secure Like a Pro

DaC applies the principles of software development to threat detection. Imagine writing code that automatically identifies and responds to threats, instead of manually configuring complex rules and sifting through mountains of logs. With DaC, you can:

• Stop the Spread: Standardize your detection logic across all clients or business units, ensuring consistent protection and eliminating security gaps.
• Turn the Tables on Attackers: Respond to new threats in real-time by updating your detection code on the fly. No more waiting for vendor updates or scrambling to patch vulnerabilities after an attack.
• Unleash Your Team’s Potential: Foster collaboration and knowledge sharing with version control and code repositories. Empower your analysts to become proactive threat hunters, not just alert responders.
• Say Goodbye to Guesswork: Ensure the quality and reliability of your detection logic with automated testing and continuous integration. No more sleepless nights worrying about false positives or missed attacks.

Behind the Code: How BlackCell Develops and Deploys Detections

BlackCell ESM‘s Detection-as-Code capabilities are built on a robust development and deployment process that mirrors best practices in software engineering. This ensures the quality, reliability, and continuous improvement of our detection rules.

Here’s a glimpse behind the scenes:

• Threat Intelligence: Our threat intelligence team provides the initial input for new detection rules ensuring that our detection ruleset is constantly evolving and adapting to real-world threats.
• Structured Rule Development: Our detection rules are defined in files with strict schemas, ensuring consistency and readability. These files contain not only the detection logic but also essential metadata like MITRE ATT&CK classifications, which helps categorize and understand the threats each rule addresses.
• Advanced Development Environments: Our engineers utilize widely used and proven development environments that, with appropriate settings and add-ons, automatically enforce coding standards and best practices, further enhancing the quality and maintainability of our detection rules.
• Version Control and Collaboration: We leverage GitLab to manage our detection rules. This allows our security engineers to collaborate seamlessly, track changes, and ensure version control, just like software developers. Every modification to a rule is documented and traceable, ensuring accountability and facilitating continuous improvement.
• Multi-Stage Review Process: New detection rules undergo a rigorous review process. Engineers submit proposed rule changes via merge requests, which trigger automated checks and require approval from senior detection engineers. This ensures that every rule meets our high standards before being deployed.
• Maturity Model: We use a maturity model to track the effectiveness of our detection rules. New rules start with a low maturity level. Based on real-world performance data, rules that consistently detect threats and generate minimal false positives progress to higher maturity levels. Rules that underperform are flagged for further improvement or refinement.
• CI/CD Automation: We employ CI/CD pipelines to automate the testing and deployment of new or updated detection rules. These pipelines perform multi-level checks to ensure that only high-quality, effective rules are released into the production environment, minimizing false positives and maximizing threat detection accuracy.

We write our detection rules in Elastic Lucene and store them in human-readable TOML files. Below is an example of a typical detection rule:

Our detection rule files are more than just queries. They include a wealth of information, such as investigation guides for analysts, MITRE ATT&CK mappings to understand the threat context, and other relevant metadata.

To ensure quality and consistency, we’ve integrated multiple checks throughout the development process.  Our engineers utilize tools directly within their development environments, and we’ve built custom validators that run as part of our automated CI/CD pipelines. These validators rigorously examine the syntax and content of each rule file.

For deployment, we’ve created a secure uploader script that interacts with the BlackCell ESM API. This script is utilized by our CI/CD pipelines and allows us to instantly push new and updated rules to all managed ESM deployments.

To maintain order and traceability, every detection update is linked to a GitLab issue and its corresponding branch.  Before any changes can be merged into production, they must pass all of our automated checks, validation steps, and a thorough peer-review process.

This meticulous approach to development and deployment is core to BlackCell ESM’s DaC capabilities. It ensures that our clients receive accurate, reliable, and continuously updated threat detection.

The Future of Security is Code

Don’t just keep pace with attackers – outsmart them. Embrace Detection-as-Code with BlackCell and transform your security operations from reactive to proactive, from chaotic to controlled, and from overwhelming to empowering.