How security operations centers work to benefit enterprises

SOC framework: People, processes and technology

A popular model of the SOC framework is described in the SANS Institute whitepaper "Building a World-Class Security Operations Center: A Roadmap" by Alissa Torres. Her model shows the SOC building blocks as a triad of people, processes and technology, with people representing the most important element.

A security operations center's staff includes the SOC manager, who is supported by an alert analyst -- tier 1 -- an incident responder -- tier 2 -- and a subject matter expert and hunter -- tier 3.

The processes component includes policies, standards, procedures and guidelines to direct the SOC team on such activities as identification of incidents/events, triage of incidents/events, containment, eradication, recovery and capturing lessons learned. Essentially, the processes element deals with the classic elements of cyber incident response discussed in NIST SP 800-61, "Computer Security Incident Handling Guide."

The technology component includes technical capabilities to monitor network traffic, collect and analyze system logs, capture threat intelligence feeds, detect incidents and gather forensics. However, these data feeds by themselves are not adequate to determine the size of a threat, whether it is a false positive or if it is a true attack.

Therefore, some tools -- such as security information and event management (SIEM) systems -- may be useful to analyze and sort the data related to flagged security incidents. However, they are still not complete without the human analyst and their review.

"There is no replacement for the human analyst," Zimmerman said.

The concept of tier levels

The tier concept basically categorizes the capabilities, experience and basic duties of the various SOC analysts. As a parallel metaphor, when looking at the service desk concept from the Information Technology Infrastructure Library, the tier concept dictates the flow of requests for assistance from elementary -- tier 1 -- to intermediate -- tier 2 -- to expert support -- tier 3.

Tier 1: Alert analyst

Security analysts designated at the tier 1 level continuously monitor all alerts and tickets coming into the SOC. They also monitor security sensors and endpoints for alarms or unusual characteristics, review open tickets, close false positives, and conduct basic investigation and mitigation. The analyst triages security alerts and, if the alert reaches a predefined level or threshold per the SOC escalation policy, a case is created and the alert is escalated to tier 2.

Tier 2: Incident responder

Tier 2 analysts are more experienced security professionals who can perform a more thorough analysis of an incident. This can be done using threat intelligence feeds or by analyzing other similar cases or incidents. The tier 2 analyst then determines if any critical data or systems have been affected, and, if so, he or she will recommend and advise on a response/remediation.

Tier 3: Subject matter expert/hunter

A subject matter expert is just that, a highly trained and experienced security professional with expertise in advanced network forensics, intrusion detection and cyber incident response, as well as advanced training in anomaly detection.

SOC workflow

The SOC workflow is generally developed and enhanced over time as users gain experience responding to and resolving security events. Ultimately, the SOC workflow depends on the SOC team's head count and support structure. A typical workflow is described below.

Input

Input into the SOC begin with alerts, alarms and logs from antimalware systems; hosts and servers; intrusion detection systems and intrusion prevention systems; firewalls; VPNs; and data loss prevention systems. SIEM platform output can provide another compendium of information produced by security log analysis.

Other input sources are calls and email alerts from users to the SOC regarding security concerns, such as unusual events on their workstations, possible phishing attacks or possible ransomware attacks. These calls may come directly from users or via the IT service desk.

Other sources of input include information from device administrators and submissions from the tier 1, tier 2 and tier 3 analysts.

Similarly, input from any threat management subscriptions or open source threat data will be fed into security operations centers for context and perspective. Even alerts from US-CERT, ICS-CERT and local Fusion Centers can and should be fed to the SOC team.

Visibility

The data sources listed above will ideally be consolidated into a situational awareness feed, such as a dashboard or a large status screen in the center. The dashboards can help the SOC manager and other analysts achieve and maintain a satisfactory big picture of the organization's security posture -- i.e., situational awareness.

Additionally, a ticketing system can provide a sense of security to the SOC team. Even simple lists or displays of the number of open security-related tickets by priority can help the team gauge the pace of attacks and security issues.

Output

The SOC team's output will include ticket closures, feedback to other threat analysts on situations and solutions, and any cases where the SOC requires added resources and expertise.

SOC limitations

The biggest weakness of security operations centers -- as with all security systems and processes -- is that they cannot detect previously unknown threats and zero-day attacks. Therefore, to reduce this weakness, it is imperative that all signatures and security protection devices be kept up to date, patched and refreshed.

Analyst retention and burnout pose further risks to security operations centers. At the 2012 RSA Conference, Ben Rothke provided some excellent perspective on this issue during his session on the care and feeding of security analysts, who are key to the SOC's success. Rothke noted that good SOC analysts are hard to find and hard to keep. Hence, management needs to recognize that you "get what you pay for" and, as such, SOC analysts need to be nurtured with extensive training, bonuses, promotions, job rotation and management opportunities.

The future for SOCs

The next step for security operations centers appears to be into the cloud.

One perspective being advanced is security operations center as a service (SOCaaS). In this case, the SOCaaS is a hired cloud service provider that collects system and event data and logs from other cloud-based systems. Theoretically, this can help customers outsource their SOC operations; however, it also enables increased scrutiny of the service and data flows. This approach is still in its infancy, and it does not offer the exciting view of the video walls and giant SOC facilities normally seen in advertisements.