While it is no secret that managing ad-hoc detections written inside a SIEM with little oversight is untenable, what is the alternative? And more importantly, how does a security practice get there? Here is what I did to move RapDev’s Managed SOC Service towards Detection-as-Code (DaC) and detection engineering at scale.

Step 1 : Frameworks

When I started the audit of our practice, I had to base the review in some grounded framework. After reviewing a few options, I chose the open-source Threat Detection Maturity Framework (TDMF) to base development at the RapDev-level and MITRE’s Summitting the Pyramid from the Center for Threat Informed Defense at the Development-level. The purpose of having both is important. The TDMF tracks leadership buy-in and investment in addition to detection development methodology, while MITRE’s framework gets at “What makes a good detection?” To measure true progress, I needed to know we’re not only writing worthwhile rules, but that the program had proper governance and direction.

Step 2: The Hard Part – Baselines

It’s tough to criticize your own work. But there is no reason to embark on this growth path if you’re not willing to set your pride aside. Internally, I did a deliberate review of Standard Operating Procedures, scripts built for deployments, our internal repository structures, tagging strategy, how an Analyst found the need for a new detection, and so on. The actual checklist was quite long – and if you’d like to engage us on an audit, let us know! – but eventually our starting point came into focus. Tracking against the TDMF, this program audit gave me multiple avenues to grow at the program level. It was clear that implementing DaC was crucial to handle the scale we operate at. 

Step 3: The Boring Part – Planning

The most critical requirement was a scalable solution that could handle operating across our managed security clients. And you don’t get scalable if you don’t take time to deliberately plan the full engineering lifecycle. Here are some of the more important decisions we had to make: Tagging strategy, playbook format, deployment methods, unit testing methods, Git repository structure, drift detection mechanisms, and version tracking. Some of these are easy checks if you choose Terraform. In our case, Terraform did not exactly meet our needs! By no means is that exhaustive either. But when you approach Detection-as-Code, you need to apply the same rigor you do to the SDLC.

In working with some clients migrating their security practice to Datadog and going through maturity assessments, we find that trying to rush to build the architecture or publishing standards is the number one speed bump. In other words, skipping the planning phase.

Step 4 : Letting the Engineers, Engineer

Individual ownership is at the heart of RapDev. With the requirements set, templates identified, and SOP updates shipped, it was up to the experts to build. What came of it was a Detection Engineering practice that truly does operate at scale. The payoff for implementing DaC compounds over time, too. Faster iteration, clearer ownership, measurable coverage, and a program that improves every sprint as expert engineers build better and attentive leaders stay engaged.

The work is not over now that we have our infrastructure stood up, though. Aligning to frameworks and tracking development only works if you actually track your development! DaC only propels your practice if its standards are maintained. But at RapDev, we know good security engineering because all we do is engineering! And more than that, we can help you with your security engineering, too! The best time to start your security maturity journey is before your next detection rule needs writing. Contact us today to talk about security migrations or our Managed SOC service!