Why Exceptions as Code Just Makes Sense for Your SIEM
Cybersec Café #42 - 11/19/24
“As Code” is kind of a buzzword nowadays.
Infrastructure as Code, Detection as Code, Automation as Code, …
As Code implementation is the new wave.
But it comes with good reason as it brings some great benefits that are built in as default.
Change Management is the major umbrella benefit of an “as Code” implementation.
The Change Management process brings code review in as a byproduct, allowing team members to not only review quality of code but to also ensure bugs are not introduced.
On top of this, Change Management also brings in Risk Management by reducing risk for failure and disruption to business operations through collaboration.
Version control is major benefit when integrating with a tool like GitHub, making it easier to quickly reference when changes were made and roll back to working versions in the event a version breaks the application.
A searchable code base is especially beneficial in an Infrastructure as Code architecture, allowing engineers to easily view configurations at a glance rather than digging through levels of UI to understand how a service is configured.
Okay, well if there are all these benefits, why is no one talking about Exceptions as Code for your SIEM?
At a high level, Exceptions as Code enables you to Centrally Manage and Review Exceptions along with the default benefits that come with an “as Code” implementation.
But, there’s also a lot of other exceptions specific benefits that as well.
Exception Specific Benefits
Want to follow along? Check out the partner repo here to view a sample of how to implement your own Exceptions as Code.
Importable to Detections
The common first step for Security Operations teams is to implement their exceptions at a detection level.
While this makes sense at the start, especially as you’re writing logic for new detections, it doesn’t scale well.
Abstracting your exceptions out your detections is easier done sooner rather than later - as your detection base grows, your exceptions will grow with it. If you go down this path, you may realize too late that it has gotten out of hand and will require a massive lift and shift to abstract these exceptions out.
If you design your “as Code” implementation from the start, you’ll easily be able to import them into your detections with a single line of code.
Single Source of Truth
Abstracting your exceptions away from your detections brings a major benefit that you won’t appreciate fully until you have it: a Single Source of Truth.
For anyone that has dealt with asset inventory use cases before, you know how difficult of a problem this is to solve. You can’t protect what you don’t know.
Well, this rings true for exceptions too. If you can’t accurately audit your exceptions, you’ll never know if your detection coverage is accurate.
A single source of truth also means you can say “goodbye” to exception drift.
Exception drift is essentially when exceptions don’t get reviewed properly because they’re forgotten about due to complexities in implementation. Having one source of truth mitigates this since all exceptions are stored in one location.
The last benefit of the single source of truth is reusability. You’ll undoubtedly find crossover in exceptions between detections, and this single source will allow you to import that same exception into multiple places while managing them from a single location.
Reviews
Exception review is an integral part of the detection lifecycle.
In order to ensure your coverage is correct, it’s necessary to review not only the contents of the exceptions themself, but also where the exceptions are implemented.
“As Code” makes this easy - you can easily view the exception files for your review, and do a quick search to see exactly where that exception is implemented.
On top of that, when a new exception is added, the change management and code review systems in place make it easy to view and approve exceptions at a glance.
- Today’s Sponsor -
Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!
Implementation
Here are some key steps to ensure you implement your Exceptions as Code in a scalable manner:
Reference File
As your exceptions grow, it’s important to have a main reference file: exceptions.py
It’s important to abstract your exceptions in this manner to keep them organized (examples can be by log type, user exceptions, global event exceptions, etc.) but to also make them easy to find for yourself.
This file will act as your organizer for all exceptions, importing each sub file in and making them callable through their own methods inside a class.
Having all sub files linked to a main file allows you to easily draw relationships as you scale by looking at the master file, enabling you to quickly review files.
Correctly Create Exceptions
It’s important to not confuse exceptions with detection logic.
Remember, exceptions are generally users, accounts, and things that are expected, but they are not pieces of the detection logic.
Think of them as an added layer on top of an already built detection to tune the fidelity of the detection itself.
Logical Architecture
Take some time to understand what exceptions you already have in place and how you would group them together currently.
Then think about any detection work you have scheduled - how would you group these exceptions now, and how would you group them in a way that’s scalable for the future?
Taking extra time on this step can be extremely beneficial to not waste extra time rearchitecting after implementation.
Reviews
It’s important to find a system for review that works for your team.
Exceptions are not always meant to be implemented into infinity.
Creating a process for notating when detections should be reviewed is important. This can be done at it’s simplest form through comments, or even through key value pairs where the a sub value is the review date.
Choose what works best for your team.
Conclusion
Hopefully with these points, I’ve gotten you to consider the benefits of Exceptions as Code and how it can help you manage your workload better of your Security Operations.
While the lift and shift of an existing implementation can be daunting, the benefits that come later on outweigh the efforts now.
Let me know your thoughts on Exceptions as Code here, or on my Twitter!
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!