The Art of Being Lazy

Detection engineering is hard, and it's hard in no small part because there's so much to it, whether that be defining use cases, writing rules, writing documentation, supporting analysts, suppressing false positives, working with data engineers, or any number of other things we are often expected to do as detection engineers not to mention all the understanding and research required to be able to do all the above well. In truth there's far more to it than hard work alone can ever manage to keep on top of. So how do we do it? How can we better manage the little time and resources we have as detection engineers to generate the very best rulesets we can that deliver the best results to the SOC?

Bill Gates once said "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it." and that sums up the key solution to this problem. Laziness.

Enter the Laziness Matrix:

The laziness matrix balances the two big concerns when writing rules, how important the use case is, and how easy it is to satisfy. If you've got two important use cases but one can be satisfied in 10 minutes and the other in 10 days, you start with the easy one because you simply get more for your time.

To place a use case in a box on the matrix you have to understand the two defining elements of it: its risk score, and its challenge to detect. The risk score can be determined though another handy matrix:

By balancing the severity of what's being monitored with, essentially, the quality of the rule you're using to detect it, you can pin down the risk associated with a firing of any given rule, with your best rules being those that hardly ever fire in error, and detect the really bad stuff.

But again, the goal is to get as much bang for your buck out of everything you do as a detection engineer, because that's probably all you really have time for and so the second part of the laziness matrix comes into play: the challenge to detect.

The challenge to detect is really just how hard it is to get the rule written and actively monitoring for alerts while being well tuned, and this isn't just about the technical challenge of writing some rules, although that's part of it. But it's also about data, network visibility, and any other obstacles in the way of writing a perfect detection rule. Easy would be a simple rule, where all the data is freely available in the SIEM and of high quality. Hard might be a rule where you need to correlate multiple logs, ingest new data, or tune out significant false positives.

My matrix originally only had those two categories, easy and hard, it was only recently I added a further two, challenging and constrained. A "constrained" rule is one which requires significant data engineering work, new tooling, upgrades to monitoring hardware, or anything else which requires more than a detection engineer alone can do.

And between those two traits of a use case you can place it on our matrix, and this offers you a superpower: prioritisation. You can think of the numbers in the laziness matrix as "points", your goal as a detection engineer is to score as many points as possible. This prioritisation goes beyond just picking which rule to write next though, it also plays out in how we actually go about writing and implementing rulesets. Writing rules can take bloody ages so if you can outsource or minimise that workload somehow you save yourself a tremendous amount of work. Some SOCs realise this and rely wholly on built in rulesets provided by their SIEM vendor, or publicly available rulesets like SIGMA HQ.

But the issue with this is that those rules were made for someone else's network, someone else's users, and someone else's ability to cut through noise, the reality is that while default and open source rulesets are helpful and should be used to maximum effect, they should never be solely relied upon as bespoke rules will always offer you more control and specificity over what you detect.

I am lazy though, and I also definitely don't have the time to write thousands of bespoke rules for every use case in the world, and so I made this handy flowchart to manage when I settle for an open-source/built-in rule vs writing my own.

The basic premise goes "why bother doing what's already done for you". If you can use someone else's work to satisfy one of your use cases then you don't need to duplicate that work yourself. On the other hand, if a use case is only partially, or not at all satisfied by what you can beg, borrow, and steal from the internet then you've got a job on your hands and that is when you write a bespoke rule.

I wrote this piece because as detection engineers we're often balancing one too many tasks, and in an environment where our time is in short supply, both ourselves and the SOCs we work in benefit when we defend our time a little better. This isn't really about laziness, it's about getting the most for the work you do, and who wouldn't want that?