Detection-as-Code — Putting Theory Into Practice

Anything (and everything) “as code” is kind of the “in” thing right now — IaC, PaC, SaC (wait, that’s “sleep” as code – pretty sure I made that up). Detection-as-code (DaC) is gaining traction, but there’s not a lot of information about how security teams are putting it into practice. Most of what you’ll find on DaC is from vendors or more theoretical than practical. So in the vein of solving problems — how do you make DaC work for an in-house security team? And why does DaC make sense at FloQast?

What Does That Mean?

First let’s get on the same page about what we mean when we say “detection” and “detection-as-code.” A detection alerts or otherwise makes note of something like brute force attempts or odd behavior (“detecting it”). Detection-as-code is the management of those detections via code, similar to software development. There may be some building and testing within the GUI, but you will store the detection as code. I think that’s the fundamental entry point for calling something DaC. You can get more intense with version control, unit testing, and the like, but the key is your detections and associated stuff live in code rather than (or in addition to) within whatever you are using for detection.

There’s some discussion of DaC being more of a mindset than actually making your detection code, but many of the benefits of DaC do require actual code. There are benefits to adopting a DaC mindset where you apply DevOps principles to detection engineering, but to really get the benefits of DevOps, you’ve got to take that final step and get your detections into code.

Why Would You Want To Do That?

Implementing DaC has several advantages. Big ones are testing, version control, and disaster recovery. Being able to test your detections programatically is convenient and quicker than testing via the GUI. The version control available is helpful when you “fix” a detection only to find it didn’t quite work as expected. Rolling back is simple since you have the code readily available. Plus with your detections in code, recovering can be as simple as running your most recent good build.

Another huge (HUGE) benefit is being able to reuse code. Copy, paste, tweak, done. That tends to be a faster process than using a GUI. True, you can clone a rule, make the changes, update the test cases, etc., but that tends to be a little inefficient. With DaC, you can script adding your test cases and easily reuse code from one detection to the next.

A benefit not often noted is having your detections in code means moving to a new product is easier. Instead of going through your old system’s GUI and finding stuff, you have code ready to code for your new tool. There will be syntax to update, but updating code is more efficient than comparing two GUIs and tracking manually.

What Does It Look Like?

Being a SaaS company, FloQast already operates with CI/CD and DevOps. The infrastructure was readily available to transition security monitoring to DaC. It did require a solution that works well with DaC (Panther) and a security team willing to write code. If you aren’t comfortable with an IDE and some form of Git, there will be a steeper learning curve.

Creating detections isn’t much different — you still have to find or modify events to serve as test cases. One of the best things about DaC is being able to collect several test cases and run through all of them at the same time. Testing detections after creation can be a “fun” back and forth of tweak the detection and then do something that should trigger it to see if it works. That can be quite slow. With test cases, as you built the detection you are able to test it — eliminating the back and forth and giving you greater confidence when detections are deployed. And you know within seconds if things are working (with local testing) or as fast as your build runs (once you push to the CI/CD pipeline). Depending on the solution, you may still do your initial development and testing in the GUI. But your detection is “finalized” when it is put into code, PR submitted and approved, and merged.

That looks a lot like the DevOps Infinity Loop doesn’t it? For a more built out view of the DaC lifecycle, check out this blog from Snowflake

Having an extra set of eyes on your detections is a bonus. Before the detection is pushed to prod, you have someone else looking through the logic and confirming what you did works. Plus with PRs and comments, you have a history of what was done so when you look at that detection later, you have some ideas about why you did what you did. It can take a little bit longer to get a detection into production, but that’s a reasonable tradeoff given the benefits.

Another big selling point for DaC is having an easily updatable and audited exception path. It’s easy for rule exceptions to get buried and left in place indefinitely because out of sight, out of mind. When you use DaC, those exceptions can be kept front and center where you can easily add and change as needed.

Are You Writing All Your Own Detections?

Um, no. Panther comes with a robust set of detections. There are also several repos available with great information you can use to build your own — you may have to translate from one syntax to another, but having a starting point is a big help. Some of my go tos are from Splunk, Elastic, Azure, and Sigma.

Summary — Now What?

That’s an idea of what we’re doing, but it really doesn’t give a concrete representation of DaC in practice. Over the next few months, we’ll be rolling out more information about how we’ve implemented DaC. It’s not for everyone, but it works well for FloQast. Some things to look forward to…setting up a DaC CI/CD pipeline with Jenkins, log ingestion via code, and prioritizing detections using a risk registry.

Page Glave

Page is a Security Engineer at FloQast focusing on detection engineering and incident response. Outside of the infosec bubble, she enjoys music, creative pursuits, and the outdoors.