Security Operations Centers (SOCs)
Early in my career in information security I developed and managed a national incident response team. Soon after the team became operational, team members started to realize that we needed a room from which we could track incidents and coordinate handling them. Not long afterwards, we were granted exclusive use of a room with special locks and plenty of whiteboards—this became our “war room.” We had to deal with an increasing number of incidents every year, and were thus constantly in our “war room,” scrambling around like crazy. Without it, I do not know what we would have done.
I just had a discussion about SOCs with Yvonne Vega of NetForensics. A SOC is very similar to an incident response “war room,” only in a SOC, the scope of operations is much larger. In a recent white paper, CA describes SOCs in the following way:
“Security Operation Centers (SOCs) can provide a real-time view into a network’s security status, making a proactive approach to security a reality via automated alerts, detailed reports, and remediation. A SOC monitors and manages all aspects of enterprise security in real time, from a single, centralized location, It discovers and prioritizes events, determines risk level and which assets are affected, and recommends and/or executes the appropriate remediation solution. It delivers detailed reports at the local and network levels, meeting both real-time management and audit requirements.” See http://www.secguru.com/files/papers/best_practices_snoc_white_paper.pdf .
Let’s face it— there is a lot to be monitored out there when it comes to the output of hosts, devices, and security tools such as firewalls and intrusion detection systems (IDSs). According to one estimate, a medium-sized organization is likely to be bombarded with the following types and amounts of daily log and other output:
- Unix (syslog) – 65,000 events
- Windows (Event Logs) – 1,036,800 events
- IDS and access logs – 1,100,000 events
- Firewall output (syslog) – 787,000 events
- Anti-virus output – 12,000 events
Simply reading this volume of output, let alone making sense of it, is an overwhelming task, one in which I would not care to engage for any sum of money. Having all log output sent to a single location, such as a host within a SOC, is only the starting point in getting things under control. Having a Security Information and Event Management (SIEM) tool that not only aggregates, but also correlates events is an even greater step in the right direction. Much of the data that central syslog servers or SIEM tools collect is sensitive, however, requiring that these machines and tools be placed in a dedicated, secure room. Normal server rooms are not the right place, because system administrators have physical access to server rooms. They could cover their tracks if they were to engage in malfeasance on a server and then gain physical access to, say, a SIEM appliance to erase the log data that might incriminate them. A SOC, on the other hand, would be ideal, provided, of course, that only information security staff were allowed access to such an area. A SOC would also be extremely useful as a place in which to hold sensitive conversations that should not be heard by anyone other than members of the information security staff.
It seems somewhat strange to me that SOCs within private industry are few and far between. With the sheer number of security breaches that now typically occur—an estimated over 200 in an organization of 7500 users every year in a research study I recently completed—one would think that SOCs would be commonplace throughout the commercial sector, yet they are not. I wonder how much a company could save in operational costs if they would set up SOCs. And I also find it ironic that in the US military and departments and agencies within the US government SOCs are commonplace, yet private industry seems to for the most part turn their back on them (unless they obtain outsourced monitoring services in which the service provider has a SOC).
I strongly suspect that the major setback to setting up and running SOCs is the upfront financial cost. Money does not exactly grow on trees nowadays. A company could always completely outsource SOC operations, and in so doing could save considerable up-front expense. But I am conservative when it comes to completely (but not partially) outsourcing monitoring and detection functions. Outsiders do not know a company’s operations, critical servers and applications, and the like as well as internal staff members do, so if an organization obtains outsourced help for monitoring and detection, some of that company’s employees should also be involved in these functions. And if an organization completely outsources monitoring, but if something happens to the service provider, e.g., it goes bankrupt, it can leave an organization gravely empty-handed when it comes to operational monitoring. But sometimes costs savings is cost savings—period—driving organizations to select wholly outsourced monitoring services.
The “bottom line” is that your organization might greatly benefit from having a SOC. It might be wise to perform a feasibility analysis and, if funds are available, proceed with setting up a SOC to support your organization’s security operations.