Building a Security Operations Centre (SOC)

Building a Security Operations Centre (SOC) is undoubtedly the best move you can make towards protecting not only your organisation’s data, systems and services, but also any sensitive information about your clients that you handle or store. This article is a brief overview of the task of building a SOC, introducing not only the key elements but also how the challenges of increased security requirements and rapid response are addressed.

The process for building a SOC can be time consuming and it is directly related to the available budget. The best approach is to create a plan that allows for incremental phases of implementation. Starting with a gap analysis, you will be able to define and prioritise the milestones for incremental improvements by setting the appropriate expectations and timelines. To start with, take a look at the Centre for the Protection of National Infrastructure (CPNI) and more specifically the Top 20 Critical Security Controls guidance.

The incremental improvements need to take under consideration the collaboration and communication between people, technology, and processes. These are the three equally important components that define a SOC.

People

Hiring new staff or allowing existing employees to step in to fill the necessary roles is equally acceptable as long as training is provided so that they understand their role in dealing with the constantly changing threat landscape. The SOC staff have a challenging job with a number of designated roles to be fulfilled. The roles and duties of the SOC staff can be summarised as follows:

• Tier 1 Security Analyst – Continuous monitoring of systems and alerts in place, from all sensors and endpoints.
• Tier2 Security Specialist – In-depth analysis of incidents based on correlated data, impact analysis, and remediation recommendations.
• Tier 3 Subject Matter Expert – In-depth knowledge of network events with forensics and malware reverse engineering skills. Closely involved in threat detection analytics.
• SOC Manager/Director – Responsible for the technology strategy to meet Service-Level Agreements (SLAs), with a deep understanding of incidents. Acts as the organisational co-ordinator for business-critical incidents while providing input to the overall security strategy.

Each role is equally important and an effective SOC requires good cooperation between the roles while also following the Standardised Operating Procedures (SOP) in place. Keep in mind that a SOC is usually operated on a twenty-four hours basis, seven days a week. In that case, the SOC must be sufficiently resourced to be able to cover all shifts, including one-hour shift transfers, considering time off, sick days and holidays.

Most importantly, the SOC manager needs to be able to actively direct the SOC strategy by prioritising tasks, take the appropriate decisions for mitigating incidents and ensure minimal impact to the business as new attacks emerge and threats evolve.

Processes

Well-defined repeatable processes ensure that no important tasks are overlooked. All steps from the moment an alert is raised in Tier 1 must have a fully documented procedure for evaluation and escalation to the next tiers. The most frequently used incident response process model is the DOE/CIAC model, which consists of six stages: preparation, identification, containment, eradication, recovery and lessons learned. The “Computer Security Incident Handling Guide” (NIST SP800-61 Revision 2), provides excellent guidance in developing Incident Response procedures.

The processes and procedures in place in a SOC are determined by its scope. More specifically, by the number of services offered, the number of customers being supported, and the different technologies being used. According to McAfee, the following is a list of the basic procedures required for maintaining a SOC:

• Monitoring Procedure
• Notification Procedure
• Escalation Process
• Transition of Daily SOC Services
• Shift Logging Procedures
• Incident Logging Procedures
• Compliance Monitoring Procedure
• Report Development Procedure
• Dashboard Creation Procedure
• Incident Investigation Procedure

However, this is only an example and a small sample of the procedures that may be required. The above list is subject to customisations based on the types of technologies in use.

Technology

Data collection, correlation, monitoring and real-time analysis are the core technologies of a successful SOC. The data collection is performed across a number of heterogeneous systems including logs from various sources.

Data collection and correlation should not only be able to go back and trace an incident but also enable real-time response. Thus, visibility and response is tied to the correlation of network events originating from network traffic, system logs, endpoint data, threat intelligence feeds, and security events.

The 2015 SANS CyberThreat Intelligence (CTI) Survey indicates that 69% of the respondents reported that their organisation implemented CyberThreat Intelligence capability, with 27% indicating that their teams fully embrace the concept of CTI and integrated response procedures across systems and staff. A state-of-the-art SOC needs to be able to spot patterns in network events but most importantly develop the capability to consume and leverage threat intelligence from past incidents and from information-sharing sources.

Additional Responsibilities

SOC staff will be required to deal with events from hundreds of systems, to say the least. As the correlation point of events, the SOC has the responsibility to decide how these events are going to be managed without instigating the Incident Response Plan every time. This event management process usually deals with:

• Malware Outbreaks
• Phishing Campaigns
• Social Engineering
• Information Leakage, Operations Security (OpSec)
• Tickets for any reported issues related to the overall security posture (systems, services, accounts, etc.)
• Routine security testing, diagnosis and various security assessments

Priority and Severity are two factors that the SOC needs to understand very well and should not be confused with each other.

Having defined priority levels, enables the SOC staff to know the essential response time in each case. Prioritisation allows for incidents to receive attention quickly so that they can be dealt with efficiently within predefined timeframes. If an issue is not resolved within the allocated time constraint, then there are agreed escalation procedures in place to be followed. Keep in mind that there might be incident tickets containing sensitive information that need to be viewable only by the appropriate staff.

Severity on the other hand defines the level of impact, across systems and services. By providing clear and adequate details for each defined severity level being used, the SOC are able to not only to react to each security incident appropriately but also take appropriate actions to mitigate the impact.

Conclusions

The building of a Security Operations Centre (SOC) is a challenging task.  A SOC build needs to anticipate the obstacles it will face during its creation, such as lack of resource or technologies that do not fully meet the SOC’s need.  A SOC should be expected to mature over time. No SOC is exactly identical to the next as each organisation has different requirements with unique characteristics regarding its overall security posture, risk tolerance and budget. Even though the common goal of every SOC is to minimise the attack surface and swiftly detect, prioritise and respond to incidents as they occur, there are several limitations and constraints affecting its boundaries. However, the creation of a SOC is a key contributor to any organisation’s ongoing security posture and cyber defence operations.

-- This is a blog post I created for Sysnet and I am reposting it here for historical purposes. This was originally posted here.