Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:30 AM
Dan Koloski
Dan Koloski
Connect Directly
E-Mail vvv

The SOC Is Dead…Long Live the SOC

The traditional security operations center can't deal with present reality. We must rethink the concept in a way that prepares for the future.

I recently moderated a CISO panel that featured security leaders from a diverse set of industries. A group of hardworking, knowledgeable, professional experts in the field of cybersecurity (most with decades of experience) discussed how difficult their jobs have become and how vulnerable they felt their organizations were despite their best efforts.

Listening to the discussion, I was struck by how much of their efforts depended on hiring and retaining extremely scarce expert personnel. It got me thinking about how we may be in one of those difficult moments when our own history impedes our ability to adapt for the future. Here's a rundown on some of the key takeaways from our chat.

We need to redefine the perimeter. Our collective security efforts in the past mainly focused on keeping bad actors out — that is, drawing a logical box around what needs to be protected and making efforts to build fortified walls. Unfortunately, drawing that box has become much more complicated in a world of cloud, software-as-a-service (SaaS), bring-your-own-device policies, and mobility. Much of what needs to be protected is no longer under our direct control; indeed, much of it may be living in systems and managed by teams we aren't even aware of. We need to reframe our thinking and define the perimeter, given that enterprise networks now extend across these various systems and teams. 

Understanding all of this, identity is now the ideal way to define your network perimeter. The contextual information and associated analytics about who is doing what and whether each individual's actions are appropriate given his or her job function represents the future of our security efforts. However, this data must be collected across all priority assets — which means a large amount of data to collect and analyze by a workforce that is already spread too thin.   

Rules-based protection isn't sufficient anymore. Traditional security operations center (SOC) approaches were largely designed for a world in which we had a reasonably clear picture of what might happen and could build rules-based defenses against it. This approach is still necessary, but it's no longer sufficient on its own because of the rise of advanced persistent threats that operate across long time spans using multi-stage attack vectors. Instead, it's important to admit that we cannot foresee all the rules necessary and that we aren't necessarily equipped to derive them. 

The rise of the "threat hunting" approach is one way SOC practices have evolved to address this problem, but it too lays the burden largely on workers who are already overtaxed. This reliance on a hero's level of effort is not sustainable over the long term. Instead, we must embrace analytic solutions that can remove effort from the system instead of just shifting the effort around from analysts to threat hunters. 

Nothing is going to get any slower. In the boardroom, innovation is top dog, and so the SOC's traditional role of gating deployments is under pressure. Even in the face of increasing threats, the business expects the SOC will be part of the team that expedites time-to-market, not impedes it. Evolutions in software development methodologies (such as DevOps) and technology (such as continuous integration/continuous delivery) further promotes this trend toward speed. 

The SOC can't expect to gain buy-in for a traditional time-intensive approach, and there won't be tolerance for laissez-faire security approaches either. Instead, the SOC needs to find ways to move faster. Once again, the solution many enterprises rely on is to tell their SOC personnel to "work harder," exacerbating the burnout of key resources.

The architectural solution requires a complete platform upgrade. Visit many SOCs and you'll find that human effort is at the center of everything. Companies deploy security information and event management systems but rely on humans to wade through the alerts. Some use predictive analytics but often have humans double-check every conclusion. There is a vast number of data repositories, but people are expected to integrate the silos. 

There is an alternative. One can collect the requisite information across a sprawling hybrid cloud setup, unify the data from all the existing silos, use purpose-built machine learning and data science for extracting signal from noise, and link it all directly to automated remediation — only escalating to human actors in exceptional cases that can't be covered by these platform-level approaches. This model also eliminates much of the burden on personnel, already buried by day-to-day tasks, to focus their energy where high-skill analysis and remediation is required.

But this model requires massive amounts of compute power and storage, as well as well-tuned data science that has experience with lots of similar data — which is why the architectural upgrade is most efficiently delivered in a SaaS model rather than as an on-premises bespoke IT project. Here again, we run into the weight of history and the inertia of our current approach: "We can't put security info into the cloud!" [Editor's note: Oracle and other companies offer the SaaS model.]

As I think about these issues, my observation is that we are both our worst enemy and our only salvation. My fellow panelists in that CISO panel voiced a similar concern precisely because the SOC has become so good at using a heavyweight, rules-based, labor-intensive approach to protect a known perimeter, we are actually self-limiting our adoption of necessary improvements.

In some monarchies, the death of a king is announced with the phrase, "The king is dead…long live the king" (with the former addressing the deceased king and the latter addressing the successor). As we are faced with an environment that has overwhelmed our current SOC efforts, stare down a severe shortage of expert personnel who are rapidly burning out, and find that in some cases our own inertia is preventing us from adapting, perhaps it's time for us to embrace the successor of our current SOC.

That's why I say: The SOC is dead…long live the SOC.

Related Content:

Dan Koloski is a software industry expert with broad experience as both a technologist working on the IT side and as a management executive on the vendor side. Dan is a Vice President in Oracle's Systems Management and Security products group, which produces the Oracle ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
7/10/2017 | 12:54:13 PM
Misplaced analysis
I think this was a misplaced view into the issues facing enterprise security. 

This onus should be placed on the rest of the company - period. This is 2017 and we should never hear the phrase "We gave them training but they didn't understand it" anymore. I was at an all hands meeting with the CEO of a large financial last year with around 4,000 people. When he started talking about the security group he went off for 5 minutes to remind everyone that their job is Risk Management first and everything else second. Building that new cutting edge app is fantastic - until it exposes the entire company to ransomware.

A few simple topics to discuss instead of improper SOC standards would be:
  • Secure coding - Dev through Production
  • Secure hardware implementation
  • Secure remote and cloud access
  • Top down SLT mandated security
  • Stop babying end users and hold them responsible

 All of these can be done while still building out continuous development efforts and achieving growth. But companies don't do it.

 Most of the security issues companies face today are known and should have already been prevented/blocked through normal, everyday efforts but they perceive those efforts as hindrances because they don't think end users can handle them or they don't have personnel who understand them.

 The standard contract for the public(CC, car purchase, etc.) must be written in a 7 grade or lower reading level otherwise it can be legally considered confusing.

 I disagree that the problem is the security folks or the methodologies they are using.
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-13
Eaton Intelligent Power Manager (IPM) prior to 1.69 is vulnerable to unauthenticated remote code execution vulnerability. IPM software does not sanitize the date provided via coverterCheckList action in meta_driver_srv.js class. Attackers can send a specially crafted packet to make IPM connect to ro...
PUBLISHED: 2021-04-13
SAP NetWeaver AS JAVA (Customer Usage Provisioning Servlet), versions - 7.31, 7.40, 7.50, allows an attacker to read some statistical data like product version, traffic, timestamp etc. because of missing authorization check in the servlet.
PUBLISHED: 2021-04-13
SAP Manufacturing Execution (System Rules), versions - 15.1, 15.2, 15.3, 15.4, allows an authorized attacker to embed malicious code into HTTP parameter and send it to the server because SAP Manufacturing Execution (System Rules) tab does not sufficiently encode some parameters, resulting in Stored ...
PUBLISHED: 2021-04-13
SAP NetWeaver AS Java (Applications based on HTMLB for Java) allows a basic-level authorized attacker to store a malicious file on the server. When a victim tries to open this file, it results in a Cross-Site Scripting (XSS) vulnerability and the attacker can read and modify data. However, the attac...
PUBLISHED: 2021-04-13
SAP Commerce, versions - 1808, 1811, 1905, 2005, 2011, Backoffice application allows certain authorized users to create source rules which are translated to drools rule when published to certain modules within the application. An attacker with this authorization can inject malicious code in the sour...