SecOps Needs More Democratization, Not Less SOC

An increasing complexity of technologies, as well as an increasing number of failures and attacks followed by an increasing dependency on business goals, is changing the way we run Security Operations Centers.

I previously discussed the concept of a Fusion Centre as an imperative to respond to the second trend. While bringing business experts into a SOC function might help security professionals get a better alignment with the business and strategize the SOC, it will not address all the scalability and agility problems inherent in a SOC.

How to Implement Cybersecurity Automation in SecOps With SOAR

Automation is the obvious solution. And that’s the reason why we see most SOCs prioritizing Security Orchestration Automation and Response (SOAR) projects are a great foundation for automating your SOC playbooks.

Some CISOs even see SOAR as the key foundation for DevSecOps. To me, this makes sense, as most traditional SOC analysts lack a software engineering or developer background. In this case, a low- or no-code SOAR platform is the perfect tactical solution to automate SOC playbooks and keep pace with DevOps or the growing business demand for monitoring and IR.

“Introducing automation in the SOC will turn your security operating model on its head.”

The first question in the automation journey is usually: How do I set the focus? Unfortunately, I see too often SOCs taking their existing playbooks and baking them into automated platforms without making many changes. Perhaps the existing playbooks are good enough to automate without much change, due perhaps to some regulatory requirements or other commitments.

On the other hand, this approach has a foundational flaw, which we saw already with some other transformational journeys in the past. For example, the rush to the public cloud and urgency to deliver pushed a lot of CIOs to adopt a “lift and shift” strategy, rather than refactor the applications to inherit all advantages of the public cloud. The result was a fast delivery, but it only scratched the surface of possible benefits.

Introducing automation in the SOC will turn your security operating model on its head. A SOC that can automate most of its tasks not only has the potential to become more efficient by getting everything done much faster, it has the potential to revolutionize the way your security operations work. With automation, you can execute your playbooks at speed of light instead of hours and maintain an endless scalability to provide a tailored experience for every employee and customer.

“Over time, the ‘O’ and ‘C’ in ‘SOC’ will slowly disappear.”

State of SecOps

The evolution of SecOps has been driven by the need to improve the effectiveness of cybersecurity, particularly in large organizations. SecOps has evolved from a reactive approach to security to a more proactive approach that is focused on automation and orchestration.

SecOps challenges include the complexity of the environment and the need to integrate with existing processes and systems. Organizations must ensure that they are securely managing their assets and data, while also meeting compliance and regulatory requirements. In addition, the SecOps team must be able to quickly detect and respond to security events.

In the past, organizations only responded to security events after they occurred, often with manual processes. Today, SecOps teams are using automation to reduce the amount of manual work and enable them to identify, respond to, and mitigate security events more quickly.

Let’s look at some examples of how industry-leading security operations centers are approaching this automation journey.

• Amazon AWS has claimed for a while that they don’t have a centralized SOC. All alerts are escalated directly to staff members and there is only one engineer on duty to watch the monitoring systems. This sounds like fantasy to most organizations, but most also don’t have the privilege of starting with a greenfield approach and an army of engineers.
• At Palo Alto Networks, we have a small group of security operations engineers who apply what we call the 30/30/30 model. The analysts spend 30% of their time on triaging high- fidelity signals, 30% building and tuning detection analytics, and 30% threat hunting and performing retrospective analyses. Most alerts go initially to affected employees for triage and the SOC analyst won’t engage unless a specific feedback or alert threshold is reached. This method has distinct cost advantages; you don’t necessarily need an expensive 24/7 rotation model. Most alerts are covered by automation, and in case an alert reaches the threshold outside of business hours, there is an analyst on duty to cover it.
• Last but not least, Google, known for its strong and diverse group of security experts, recently published a white paper on this topic. They shared their lessons learned running security internally and transforming traditional SOCs into Autonomic Security Operations. In this white paper, Anton Chuvakin and colleagues argue that cloud adoption is a key driver for transformation of security operations strategies. Over time, the “O” (operations) and “C” (center) in “SOC” will disappear. The results will be pretty similar to the above concepts: a SOC-less organization.

SecOps Automation Challenges

The security community has been banging around this automation topic for a while. So why then is it still such a big deal for SOCs to automate? Ask some reluctant CISOs and they’ll tell you their hesitation is technical in nature, e.g., “we’re still trying to instrument our controls” or “according to our playbooks, automation might cause some stability issues.” However, the feedback is mostly centered about the requirements of the SOC itself and not the requirements of the business teams or workforce.

This might be the core of the automation problem. Too often we forget to zoom out and revalidate the problems and requirements established by our internal customers. As SecOps heroes, we believe (incorrectly) that most employees don’t understand the problem and we arrogantly assume that only we can get it right; we are the wizards and all employees are the muggles. But let’s not forget that most of the problems with traditional SOCs are associated with one single problem: alerts with lack of a business context.

“Too often we forget to zoom out and revalidate the problems and requirements established by our internal customers.”

So, how can we consider a more customer-centric view in the automation journey? One of my CISO colleagues summarized it this way: “Today, employees or business functions want to have the freedom of choice on the visibility and the number of alerts they get from their security teams. As long as they stay responsible and understand the risks, we will provide them this comfort, but still do our spot checks to verify.”

In practice, such a democratized SOC model could look very different for every organization, but there are some good examples for this strategy:

• Data leakage detection is potentially the most difficult to deploy and often the noisiest cybersecurity control that ever existed. Central reviewing of DLP alerts is not only ineffective and cost-intensive, but also significantly impacts data privacy. Statistics tell us most data leaks are not intentional, hence escalating those alerts straight to the respective employees and their manager and helping them to understand the problem will eventually create the best return on investment for the company. Improving your data security culture can be a game changer.
• Application flaws or configuration issues. You don’t really believe your SOC analysts can consistently bridge the gap between the application security issues and DevOps teams, do you? Every DevOps team understands the simple principle: you build it, you run it. As a CISO, we have to add “you secure it” to this principle.
• CISOs and their teams add value to the SOC by defining and configuring the right prioritized policies and guardrails as part of the SDLC or CI/CD pipeline. All alerts go straight to the respective DevOps teams for review and handling. Example: A new project going live on Google Cloud with a bad configuration will be automatically shut down and escalated back to the DevOps team for remediation. No exceptions!
• Phishing. Yes, it’s 2021 and everybody should be aware of phishing and how to handle it. Empowering employees and escalating the alerts back to them for non-blocked phishing emails, e.g., through an interface in your mail program, additional emails, robo-call or corporate message, etc., will not only release your analyst to do more important tasks, but also increase awareness among your employees.
• Compliance monitoring. Some industry regulators mandate monitoring of system administrator activity or access attempts to critical applications. While there are obvious risks like insider threat of escalating those alerts directly to the respective team, I would argue that it’s crazy to assume your centralized SOC will ever be in the position to interpret these activities without the help of SME. So, why not escalate those alerts directly to tribe leads or dedicated security experts on those teams?
• In the end, you are still left with traditional SOC alerts like network intrusion and malware events, which can be handled only by your SOC expert. On the other hand, most modern IPS/sandbox technologies are in the position to translate those alerts directly into preventative signatures. Consequently, there is no need to review and triage every single alert. The only centralized operational function your SOC might keep is incident response and a dedicated threat hunting/forensics team looking retroactively into data and malware for successful intrusions and improving your policies and analytics.

The list of democratized SOC use cases can go on and on, but the point I am trying to make is that an automated SOC will always have to start its journey with reevaluating the problem it’s trying to solve with its customers. Democratizing a process always requires a two-way approach. Educate your workforce, get their buy-in on the scope, and only then start to leverage them as your extended SecOps analysts.

Ideally, you do this before introducing automation into the SOC. You’ll be surprised by what you do differently or not do at all. As a result, some organizations might even achieve the vision of a SOC-less organization, but the reality is that most organizations would still require a centralized team to manage their legacy infrastructure or processes.

At the same time, more and more traditional SOC responsibilities will be transitioned to your company’s workforce, making them responsible for their own security operations. This is a democratized SOC.

The Future of SecOps

SecOps will continue to evolve toward more proactive security management. This will include more automation of security processes, detection of potential threats and prevention of data breaches. Artificial intelligence (AI) and machine learning (ML) will be used to identify potential threats, analyse data, and aid in response times. Additionally, organizations will use cloud-based services to centralize security operations, reducing manual processes and freeing up time for security teams. Security teams will continue to need to be multi-skilled, with a combination of technical, analytical and communication skills, to be successful in SecOps.

Additional Resources

• Report Benchmark Your Sensitive Content Communications Privacy and Compliance
• Blog Post What Is a Private Content Network?
• Blog PostWhat Is a SOC Report?
• ArticleWhat Is FIPS Compliance?
• Blog PostWhat Is a Security Wipe?