I’ve worked in security operation centers (SOCs) since before they were even called that, and I’ve seen a lot. A lot of threats, a lot of technologies that worked for a while—until the threats evolved past them—and a lot of frustrated SOC teams.
As someone who attended the very first RSA and Black Hat security conferences, I’m amazed that every year the exhibition floors at those events are jammed with vendors coming out of the woodwork with new technologies. It’s great to have choices, but there are just too many security options for SOC teams to manage. And interoperability is non-existent with so many new offerings hitting the market, creating a management nightmare for SOCs.
Thirty years ago, the biggest threat to computer security came from malicious code. But things escalated quickly, with new types of external threats, along with internal security issues. When I started in security, we talked about “defense in depth.” Each new product we bought added another layer. When we began our triage processes to find and mitigate threats, each layer took us in a different direction, which required different tools. And that really hindered our effectiveness.
The History of SOC Tools
In the days before specialized security technologies, businesses relied on computer incident response teams (CIRT) to handle security. CIRT teams spent days or even months manually collecting and poring over disparate datasets to identify an incident. We had to create our own search criteria to find an indicator—a grep or keyword search—within large volumes of data.
About 20 years ago, the first security information event management (SIEM) tools debuted. They were designed to create connectors into an organization’s security stack. The concept was to establish a central location where security teams could write queries, create alerts and correlate artifacts to build a story. Unfortunately, as useful as SIEMs can be, they still haven’t completely accomplished this goal.
The next era of technology featured perimeter security solutions such as next-gen firewalls and intrusion detection systems (IDSes). Similar to how antivirus solutions work, an IDS relies on signatures to watch for suspicious or anomalous activities. And it found a lot of them. However, there were far too many false positives, and keeping the signature database current required several full-time employees.
IDS evolved into intrusion prevention systems (IPSes). Over time, IPS performance improved to the point where if its detection capabilities were fired, the solution could automatically respond to a threat. This could range from shutting down a firewall port to creating a new access control list (ACL) rule. Some security teams were not comfortable automating those actions; remember, this was long before the machine-learning solutions we have today. But the bigger challenge was that the bad guys who were trying to breach data-rich systems were able to stay ahead of the IPS solutions—and this remains an ongoing problem.
Next came endpoint detection and response (EDR) solutions, which record everything happening on an organization’s endpoints (computers and servers). EDR gave CIRT teams greater visibility into suspected malicious activities, which made a significant difference in visibility and detection, but it still failed to stop every threat.
Stack Overflow
With all these new technologies, the security stacks at most midsize and larger organizations ballooned. This proliferation of solutions contributed to the development of SOCs.
The U.S. government established security operations centers in the late 1970s. But businesses didn’t follow suit for decades. The idea behind SOCs was to have a team of experts working in the same room at the same time. When someone saw something, the group could discuss it and respond quickly and effectively. Cyber threat intelligence (CTI) was discussed as early as 2004. The term has been applied rather haphazardly to a broad range of activities, many of which pre-date the actual creation of the term, such as IP reputation lists and vulnerability management.
At the same time, information security practitioners sought to bring new and novel techniques that would advance the industry, many of which have proven useful in the practical work of securing computers and the information on them. But even with expert teams focused on threat intelligence, as well as monitoring, detection, investigation and response, the amount of data coming into the typical SOC was overwhelming.
If you visit most SOCs today, you’ll still see a lot of “swivel-chairing” going on, as experts copy data from one user interface to another to conduct triage and perform investigations. SIEMs only have pieces of the data, so you need to take those pieces and use an EDR solution or forensic tools to try and figure out what’s happening. Traditional SIEMs set out to become the “single pane of glass for all cyber information,” but that hasn’t happened because of today’s volume of security data.
What’s Next in SOC Technology?
If SOCs are ever going to stay ahead of the fast-growing, diverse threat landscape, they must get all of their organization’s data—not just security data—in one location. Achieving the goal of a true next-gen SIEM for next-gen SOCs requires all of the data and context, as well as threat intelligence and sharing, orchestration and automation capabilities.
If I receive an alert, I want to automatically orchestrate my investigative workflow. To make the right decisions, SOC teams need all of the information automatically presented to them. Don’t make them copy and paste artifacts or call a third-party resource for help. Consolidating all of the pertinent information into a central repository will spur collaboration and faster, more effective responses.
I have enough gray hair from using security technologies that failed to deliver on their promises. It’s time to reinvent the tools that SOC teams need to do their jobs.
