How to Make Threat Detection Better?

I keep coming to the same topic over and over — why are we still bad at detecting threats?

---

I keep coming to the same topic over and over — why are we still bad at detecting threats?

I’ve lamented on this a few times, either touching on general difficulties with detection, its uncertainty or highlighting the fragile detections people write. I also noted the critical role of context in threat detection, which seems to imply that the best detections are written on-site by each team, and not by the vendors in their comfy little labs …

Here, I want to continue the conversation on detection quality. Also, I want to look for some ideas that can help everybody. How do we get the mainstream companies to improve their detection quality? What does it mean to have “good” detections? How do we get to more and better detections? More curiously, how do we get to better detections that are also developed rapidly (to avoid the “good/fast/cheap — pick any two” syndrome that led to many fragile IP- or hash-based detections)?

Now, some people will say that there are NO good answers. Hence, their only answer is to have organizations outsource detection to a quality MDR or an MSSP. Sure, that would solve the problem for them (It would, right? Right?!), but it would really just shift the bigger picture problem resolution to their MSSP. Specifically, how would many MSSP teams write good detections without access to the best of the best detection authoring talent? Worse, sometimes said MSSPs will try to “mass produce” detection rules hence losing local, on-site detection context. Even more worse, sometimes you can spot an MSSP that simply relies on commercial SIEM stock detection rules. Economies of scale here may translate into missed attackers …

Also, there will be a category of people that will say that the answer is …. drumroll … machine learning. However, guess what makes detection difficult for many security scenarios? The fact that we do not have reliable data on attackers and attacker behavior. Also, guess what is required for machine learning to work well? Just the data we just noted the lack of. No way, right?! So, ML unicorn cavalry is not coming.

Well, instead of just lamenting and highlighting the challenges, what can we do?

Let’s try to decompose the good detection into elements. What do you need to write a good detection? (Note that we kinda sorta punted the definition of “a good detection” to a later post…)

• You need some knowledge of the attacker; specifically, you need elements of such knowledge that you can latch onto in your detections. For example, if you somehow know what the attacker is thinking about, you can not necessarily write rules on that …
• Naturally, knowing the attacker goal is useful, because this may point at the types of telemetry you’d use to detect them and from what parts of the environment (Database logs? Application traces? Cloud authentication logs?)
• In addition to attacker knowledge, you need some useful telemetry that you can apply that knowledge to. Note that this equally applies to both rule-based and ML -based detections, but you will likely need more telemetry if you were to develop your own ML detections.
• Knowledge that separates good from bad, attacker knowledge alone won’t cut it as there are legitimate activities that look the same in some regards. Unless you know “good” well, your detections will become “false positive” machines.
• Naturally, some way to express or declare detections, a language (like say YARA-L or Sigma) or a method at least. Further, it goes without saying that you would need some kind of tool to actually implement that method.
• Finally, it is fair to say that you would need some test data or a test environment, or at least a testing approach, to verify that what you created actually does what you wanted to do (and does not do a lot of other unneeded things).
• Anything else I missed?

Now, reading the above surely does not mean that you will write good detections, but IMHO you will have a fair shot at that. Frankly, this is much more nuanced IRL.

For example, during a recent SANS webcast we went through a bunch of rules and derived these additional lessons.

Recent SANS Webinar on Detection

By the way, this post ended up being more of “an incomplete thought” then a solid framework, but I hope you forgive me. More to come!

Related blog posts:

• “Modern Threat Detection at Google” (ep17)
• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “What Are You NOT Detecting?”
• “Can We Have “Detection as Code”?”
• “Role of Context in Threat Detection”
• “Detection Coverage and Detection-in-Depth”
• “Why is Threat Detection Hard?”
• “On Threat Detection Uncertainty”
• Our Cloud Security Podcast by Google :-)

---

Originally published at Medium.

New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center”

It is with much excitement that we announce a new paper about transforming your security operations; it is published under the Office of…

---

It is with much excitement that we announce a new paper about transforming your security operations; it is published under the Office of the CISO at Google Cloud.

This work is focused on our vision as well as our lessons in building effective security operations for the future. We spent a lot of time thinking about what to call the new model. We ultimately settled on the name “Autonomic Security Operations” for the vision (note that the previous contender was “10X SOC”, which one do you like more?)

Now, when we say “autonomic” here, we do not mean “without people” or “fully automated.” All of us here agree that it is quite impossible. When we think of autonomic security operations, we think of an approach that leverages automation, but also focuses on being agile, adaptive to rapidly changing environments, and the one that utilizes people with dramatically increased effectiveness.

While I want you to read our paper, let’s now think about two interesting and useful ideas from it.

One question that I’ve been trying to explore, such as in this podcast, is: we do know that DevOps and SRE approaches revolutionized how IT is managed and practiced. I’ve been thinking about what can possibly be a similar revolution in security and, more specifically, in security operations.

The answers, of course, are obvious. What is the “O” in SOC? Operations. What happens to operations in the DevOps model? It becomes fused with development, thus toil decreases, while automation increases. Less toil, but more code.

Naturally, we see the same start to slowly happen in good SOCs or detection teams (if you insist on being “SOCless”). In the SOC context, this is about detection engineering, detection as code and related concepts.

Just as naturally, and just as it happened in IT first, many people don’t like these changes. Remember the comments to my blog post about how they don’t want anything “as code” because this means they have to code? I’m pretty sure that Windows NT system administrators of the 1990s also did not want to become part of DevOps…

Next, what about the other part of the SOC, namely the “C”? Will SOC remain at the center of anything? Will it always be a crowded room with fancy monitors?

As we watched current events affect security operations, we learned that SOC as a big room, full of people, may in fact disappear. However, I’ve long argued that SOC is first a team that focuses on detecting threats and helping respond to them and so it will not vanish anytime soon. What if the future SOC would be a center in the same sense as “a center of excellence”, but not a central physical location anymore?

So, what happens if a SOC both becomes infused with DevOps approaches and stops being a centralized silo?

As you learn from our new paper on autonomic security operations, we are presenting this very vision of future security operations. Using the lessons from DevOps and SRE approaches, we propose that a security operations center would become less about operations and would become less of a center.

These changes are critical, if not to say truly necessary, to deal with the business, IT landscape and threats of the future. Below — and of course in the paper — you will see many examples of how we describe such transformed SOC and how you can take steps towards making your security operation center work that way.

So, please see a tiny subset of my favorite quotes from our paper:

• “Autonomic Security Operations is a combination of philosophies, practices, and tools that improve an organization’s ability to withstand security attacks through an adaptive, agile, and highly automated approach to threat management. “
• “An unfortunate common theme of many cloud transformations is that the SOC requirements get deprioritized when organizations have tight timelines and budgets to drive their teams to the cloud. The reason being, most SOC teams are too busy fighting fires and don’t have the spare cycles to focus on adapting their use cases to cloud workloads and modernizing their own infrastructure.”
• “To be 10 times more effective with the people component, your SOC cannot achieve this by increasing the personnel by a factor of 10. As of today, both threats and technology resources that need effective security are increasing at a much faster pace than people entering the workforce. […] It is absolutely impossible for most organizations to 10x their headcount in a SOC.”
• ”At Google and across other industry-leading security operations teams, the role of an analyst is not simply to manage cases and perform tier-1 level work. Analysts are engineers, architects, project managers, and are empowered to be leaders of their subject matter focus. At such a SOC, the concept of Level 1 to Level 3 analysts is a thing of the past, rather, you should organize teams based on aligning skills to the use cases that fall under their purview.”
• “The SOC can only truly be 10X and transformative if it also has strong influence over the upstream elements of the security lifecycle. You can make a significant impact on the amount of alerts that get into your SOC if your team has a strong integration with your DevOps practice. A deep understanding of how infrastructure and applications are securely built, deployed, and managed across your organization paired with your ability to influence this design can only improve your ability to catch attackers at their earliest onset, or even better, prevent them from getting in entirely.”

But really, go and read the paper here. We have a lot more value there!

Also, read about the related solution launch here.

Related blog posts on SOC:

• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “New Paper: “Future of the SOC: Forces shaping modern security operations””
• “New Paper: “Future of the SOC: SOC People — Skills, Not Tiers””

---

Originally published at Medium.