The security operations center (SOC) is a critical element of running a situationally aware and highly responsive security organization. Unfortunately, many companies today don’t have the resources to form a SOC, much less manage one that integrates seamlessly with existing security and networking teams. Companies that are able to fund, staff, and operate a SOC often find themselves with two separate security-focused teams—security and security operations—that present different skill sets, capabilities, reporting structures, and processes.
Infosec Insider spoke with Dave Ockwell-Jenner, Senior Manager, Operational Security & Risk Management (STORM) at SITA, an aviation technology company which supports nearly every airline and airport around the world. Needless to say, SITA’s threat landscape is broad and diverse, giving Ockwell-Jenner and his team unique insights on leading practices for managing a successful SOC. He shares his recommendations and time-tested tips, below.
What does today’s SOC look like?
I like to think of the SOC as being a “Security Operations Capability” instead of a “Security Operations Center” since, in my view, it’s more important to focus on the capability (i.e., what you can do as an organization) rather than thinking of it as a place of operations run by dedicated individuals. Some organizations maintain separate SOC teams, but I think it works well when the SOC is part of the existing security team; only then can its work and findings be truly integrated into an overall security and risk context.
The modern SOC might be staffed with network analysts, system administrators, software developers, and other non-traditional skillsets. At the end of the day, the SOC’s role is to “find bad” from various angles and then “take care of it.” “Bad,” however, comes in many forms, and, for instance, network packet hounds are going to miss identifying application attacks, and software developers are likely not to have been schooled in the ways of IP packet analysis. This is precisely why a SOC works best when it’s part of the overall capability of the larger security and networking team. Today’s organizations need complementary and diverse skills to handle the types and frequency of attacks we’re seeing in most enterprises.
As it relates to the “take care of it” part, many robust and mature teams aren’t set up to manage suspicious findings, incidents, or identified attacks within the SOC itself. Remediation and resolver teams—either internal to the company or provided by an external organization on a contract basis—are great partners to have.
Are there things you’ve seen that curb the SOC’s ability to perform at the highest level?
Security operations centers grew out of military-style intelligence adapted to the enterprise. Even though the field has evolved and we’ve learned many lessons as they relate to running a cybersecurity capability, many SOCs today still resemble command centers and feel almost military-like in their setup. In some ways this breeds a hierarchical chain of command, with your level 1 “SOC jockeys” playing the role of the cyber defenders you see in movies, the ones staring intently at the screen before the adversary launches some wildly successful offensive.
This concept might tempt some organizations to staff their SOC with narrowly focused skillsets and roles. Whilst this can scale well, it also limits the flexibility of the SOC to adapt. And we know for certain that security organizations, as a whole, need to remain agile and have the ability to pivot around any type of observable. For larger organizations that have the resources, the hierarchical model can work well if too much “red tape” isn’t in the way. For smaller organizations—which is the reality for most—teams should consider the breadth of members’ capabilities as they’re staffing or reorganizing.
In your view, how can a SOC be most effective?
A SOC’s primary value isn’t in stopping instances of attack, it’s helping define how to stop whole classes of attack. If your SOC is spending all its time chasing down commodity malware cases, maybe the organization needs to look at how to reduce this busywork and focus on larger scale patterns. I have seen many SOCs just throw people at a problem to make it scale when it would be more logical to find the root of the problem which can, in turn, reduce the team’s workload.
To this point, SOC staff must be aware of what can be done with what they catch. For instance, does your SOC see tens of malware cases per week yet the help desk can only manage and remediate five? How can you look differently at what’s being captured in your systems to identify the commonalities between each malware case and use that knowledge to eliminate the class of problem rather than the specific instances?
Considering my current role at an aviation technology company, I like to draw a parallel to aircraft safety issues, which many people can understand easily: When an air accident occurs, the investigation is performed not only to learn what happened in that specific instance, but also to develop recommendations that ensure the whole class of problem does not reoccur across the entire air community. It’s not a matter of fixing one flight or one aircraft, but making the airline industry safer in aggregate.
How do you see the SOC evolving in the foreseeable future?
The reality of today’s cyber attacks is that the techniques, tools, and procedures used by adversaries change more rapidly than most SOCs can iterate their use cases. The result is usually a set of detective controls that expose yesterday’s threats. This isn’t necessarily bad, as yesterday’s attacks persist (and work), but the heavyweight traditional detective capability (security information and event management—SIEMs—primarily) is slow to adapt. This SOC tooling must become nimbler to be more effective, which is perhaps why we are seeing a bit of a trend away from collect-and-alert systems toward collect-and-search systems.
How can SOC teams tweak inputs to improve operations capabilities?
Many people think of SOC inputs as the alerts produced from detective controls, and the outputs as a set of actions (e.g., firewall blocks, AV scans, etc.). A more contemporary approach, I think, is to rely more heavily on threat intelligence (as a combined technology and human capability) and hunting activities as your inputs as well. SOC analysts should be skilled beyond “I see, I do” and operating at a level of, “I see, I wonder what that means?”
In addition to these more proactive inputs, incident response, for me, is critical to fine-tuning a SOC. The intelligence gained from incident response should always include lessons for detection by the SOC, not just indicators of compromise (IOCs), but observations on adversary behavior. For instance, my organization’s SOC is seeing an increase in the use of PowerShell launched from macro-laden Microsoft Office documents that are being used to gain persistence. Can your SOC detect Word spawning PowerShell, writing a registry Run key?
How can the SOC be a better business partner?
A SOC is an ideal stakeholder in the selection of new security technologies. They are at the front line and will often know where the organization is weak. A portion of the rest of the security team should be dedicated to addressing this. The conclusion may not be, “buy more,” but the simpler (and more cost effective), “do more with what we have.” Don’t have an endpoint detection and response tool? Could anything else in your arsenal provide you some of that capability (e.g., using your vulnerability scanner to hunt malware IOCs).
For its own sake, to better help the business by unburdening itself, automation is a SOC’s best friend. I believe much of what traditional SOCs do can be automated. In some cases, that might be simply integrating detections with the ticketing system. In others, it might be what I call “ghetto analytics” – rapidly evolving rules made-up as we go that help trigger action automatically.