More SRE Lessons for SOC: Simplicity for Security

As we discussed in our blogs, “Achieve Autonomous Security Operations: Reduce Workload”, “Achieving Autonomous Security Operations: Automation as a Force Multiplier“, “Achieving Autonomous Security Operations: Why Metrics Matter (But Not What You Think)”and the last “More SRE Lessons for SOC: Release Engineering Ideas” your security operations center (SOC) can learn a lot from what IT operations discovered during the Site Reliability Engineering (SRE) and the DevOps revolution.

Let’s dive into another fascinating area of ​​SRE wisdom that is deceptively simple – the principle of…simplicity (SRE Book, Chapter 9 “Simplicity”). Say what? It sounds abstract and philosophical, how can it help my SOC today? Well, let’s find out!

The first point they make is a reminder of what makes it all exciting: “Software systems are inherently dynamic and unstable.” But SREs have it easy, here in our beloved domain of cyber we not only have “inherently dynamic and unstable systems”, but also attackers who affect them in dynamic, beautiful (sometimes ugly) and unpredictable. 10X pleasure guaranteed! So, yeah, that’s a big part of why security is fun, but also tricky. This means that we need simplicity even more.

But what is simplicity? Phil’s 8 megatrends blog reminds us of this by calling one of its cloud megatrends “Simplicity: the cloud as an abstraction machine.” Specifically:

“A common concern about moving to the cloud is that it is too complex. Admittedly, starting from scratch and learning all the features offered by the cloud can seem daunting. Yet even today’s feature-rich cloud offerings are much simpler than previous on-premises environments, which were much less robust. […]

The cloud will only get easier as the market rewards cloud providers for abstraction and autonomous operations. In turn, this allows for more scale and more use, creating a relentless hunt for abstraction. […]

Increased simplicity and abstraction allow for more explicit assertion of security policy in a more precise and expressive way applied in the right context. Simply put, simplicity removes more potential surprises – and security issues are often rooted in surprise.

So eliminating surprises and reducing single/broken/snowflake systems and siled processes will make security (and SOC in particular) easier. SREs have already figured out a lot of this.

To dive into the details, they say that their “The job is to keep agility and stability balanced in the system.” For us in security, another (delicate) dimension is added: the threat. Sometimes compliance is also built in, which can push the organization to adopt old, ultimately more fragile ways of working (by the way, compliance that reduces security by advocating outdated approaches is a reality). Fragile systems (and processes) + threats + regulations = a lot of complexity. And a complex system is always difficult to monitor for threats, which are then also difficult to investigate, making life for the SOC a pain.

Also, SREs say that “Reliable processes tend to increase developer agility.” We wish we could always say that secure processes do the same. And, how about that, many actually do! At Google, we have many examples of something that’s secure and good for developers and good for business. Think zero trust well implemented, which helps users, simplifies IT and reduces risk. It also makes the work of a SOC easier. Anyway, we digress a bit…

Consider other manifestations of SRE principle of simplicity. Now that’s really juicy: “Essential complexity is the complexity inherent in a given situation that cannot be removed from a problem definition, whereas accidental complexity is more fluid and can be resolved with engineering effort.” This line alone is magic for the SOC!

I have always said, for example, that SIEM is complex, in large part because its mission is complex. Now, if your SIEM provider makes the SIEM as complex as the mission, but not more complex, you may have a winner. Ideally, this should make it simpler, but frankly, it won’t make it simple. Because it just isn’t! However, excessive and removable complexity is a sworn enemy of security.

In other words, detection is difficult, but some tools complicate the task. Don’t use them, use those that do not add complexity.Push back when accidental complexity is introduced” as the SREs say. We absolutely must fight this battle within the SOC.

Moreover, if SREs say this “every new line of code written is a handicap”, then in the SOC each detection rule is. You deploy this detectionthen you create a job, labor in some cases, for you or your colleagues who must respond to the resulting alerts. Think about it! The way to make this work, rather than fail, is to have a solid lifecycle for all detection content, in my opinion. Then each line you add offers more value than responsibility, even if the responsibility is never 0.

“The ability to make changes to parts of the system in isolation is critical to creating a supportable system.” So? Tome, a bad “integrated” platform is worse than two good tools that can interconnect via APIs. That’s why I think the best of breed ultimately won on security and sequels and overly promising broad rigs lost (although this point is frankly very controversial, so let me digress quickly of this particular argument…)

“Simplicity is an important goal for SREs because it correlates strongly with reliability: simple software breaks down less often and is easier and faster to repair in the event of a failure. Simple systems are easier to understand, easier to maintain and easier to test. » And of course simple systems and processes are easier to secure and monitor for threats. Now some readers may say “but wait, I’m a bank with 300 years of history, every process I have is complex, not simple”. Sure, but you can always “push back when accidental complexity is introduced”. If your IT is inherently complex, the struggle to reduce “excessive and removable” complexity is more necessary, not less.

Naturally, simpler systems in your SOC helper even more. Do you really need this rule with 5 correlated states or a playbook with 30 decision boxes? And if you need to create a 30-box alert triage process flowchart, don’t make a 70-box flowchart?

In short, they say “The simplicity of the software is a prerequisite for reliability.” We can add: also for security and threat “detectability” and “investigability” (can we just say observability?).

So your mission, should you choose to accept it, is to eliminate unnecessary complexity from your SOC. Where is the complexity hiding in your SOC? In detection content? Playbooks? Escalation process? Workflows that involve other teams? Metrics and associated data collection? This is where you are going to look to reduce complexity.

To finish, “For SREs, simplicity is an end-to-end goal: it must extend beyond the code itself to the system architecture and the tools and processes used to manage the software lifecycle.” I wish we had this for security and SOC in particular.

PS So I’ve re-read this post a few times (well, OK, more than a few times) and it still looks more conceptual than practical. So, maybe a handy tip: When you come across or create a SOC process, or a piece of technology in or around your SOC, think “does this add complexity?” » » and « Is this complexity really necessary? If YES and NO, then consider doing things differently. If YES and YES, then think if the answer to the second question is really YES…

Related blog posts:

More SRE Lessons for SOC: Simplicity for Security was originally published in Anton on security on Medium, where people continue the conversation by highlighting and responding to this story.

*** This is a syndicated blog from the Security Bloggers Network of Stories by Anton Chuvakin on Medium Written by Anton Chuvakin. Read the original post at:——2

Source link