Unfortunately, it is an accepted fact that when it comes to security breaches, the question is not if, but when they will occur. So it is important to master the art of damage control and prevent serious consequences. In other words, detecting security incidents, dealing with them appropriately, and having an effective improvement process are more important than ever.

So more and more organizations are relying on services offered by security operations centers (SOC) as part of their cybersecurity strategies, whether operating an SOC themselves or outsourcing the necessary services. An SOC can make a valuable contribution to maintaining and restoring an adequate level of security by identifying security threats, taking precautions and handling incidents. This article examines the requirements and skills needed to set up an effective SOC.

Developing and operating an SOC is no simple undertaking, even if in some ways much can be achieved with relatively simple tools. One reason is that a functioning SOC has organizational and technical requirements that have to be met, and these alone can present a challenge. An SOC can only be successful when it builds upon a foundation that ensures a certain basic level of information security. This includes consistently implemented base-level security, a comprehensive asset directory and sound policies.

What is an SOC?

In the context of this article, the term SOC is used to refer to the following:

An SOC is a service center offering the processes, technologies and human resources needed to detect adverse events or situations through the ongoing monitoring of information processing systems, to react, and to prevent or minimize the resulting damage.

An SOC can be a department within an organization or operated by an external service provider, or a combination of the two.

Requirements for an effective SOC

As with other fields of IT, the factors affecting an SOC have different aspects: human resources, processes and technologies. The functional interaction of these aspects is especially important for an SOC. The graphic below highlights the impact of any shortfalls:

The organization for which the SOC is working plays a major role as well. Perhaps the most important organizational requirement is to clearly word and communicate expectations to the SOC, i.e. have a clearly defined service mandate. This should be determined at the level of upper management or, in the case of public organizations, by a suitable political body, and can be of a legal or regulatory nature.

The performance mandate should at a minimum include the following:

• Customer’s definition of the SOC, i.e. internal or external groups for which the SOC operates.
• Definition of the SOC’s authority. It needs to be clear which actions the SOC is authorized to perform. Here, the spectrum can range from a purely advisory role through to the implementation of procedures and performing of tasks on systems.
• Service catalog listing all of the SOC’s services, such as response, vulnerability handling, malware analysis, etc., including a specification of the service level.

In order for the SOC to do its job effectively, the organization must have reached a certain minimum level of maturity with respect to information security. This includes the following:

• Established principles for setting up and maintaining information security, data management and processing (governance)
• Appropriate policies and guidelines with respect to IT and information security
• Data classification and corresponding basic protection, ideally based on an established framework such as NIST CSF
• Regular effectiveness assessments of the technical and organizational measures taken
• A catalog of all IT assets (systems, infrastructure components, software, etc.)

Which resources, processes and technologies are required?

The following sections explore the minimum elements required for an SOC with respect to these three aspects in more detail.

Human resources

Perhaps the most important resource for the success of an SOC is its staff. Unfortunately, there is often a lack of qualified specialists – a deficiency generally countered with continuing education and training, but also with technical resources (automation and orchestration, machine learning, artificial intelligence). Although the resources currently available are very effective and constantly becoming more powerful, they cannot (yet) replace human abilities altogether. Therefore an adequate number of qualified specialists are required, usually two to three at minimum.

Processes

By definition, the SOC is a service center that works in close contact with its customers. The corresponding organizational and technical interfaces and associated processes are extremely important, must be clearly defined and, most importantly, they must run smoothly in a crisis situation. Most SOC processes rely directly or indirectly on one or more of these interfaces, which is another big reason why the SOC has to be considered as part of the whole. The key processes relate to the following areas:

• Processes for escalation to management as well as to the legal, compliance and HR divisions
• Bringing in support, be it internal departments outside of the SOC or third-party experts, e.g. in special areas like forensics or malware analysis or for incident management in general
• An enterprise risk management interface
• In-house and external communication processes and the corresponding maintenance of a comprehensive communications matrix with all of the necessary contact information
• Threat modeling, i.e. preparing threat models specific to the organization and situations
• Monitoring, triage and alerts based on this modeling
• Procedures for the analysis of incidents and their classification according to impact and urgency
• Incident handling, i.e. how the SOC responds during an actual security incident
• Restoring normal operations
• Ensuring seamless traceability of SOC processes

The threat models make it possible to answer the following questions:

• What threats are relevant to the organization?
• What kinds of precautions are required?
• How do these threats manifest from a technical standpoint?
• How, and with what tools, can the SOC detect these threats?
• How can such attacks be prevented or neutralized?
• What precautions can be taken?

The resulting knowledge is valuable for helping establish set procedures for attacks identified as relevant and for the necessary incident handling. These playbooks play a key role in the effective and efficient handling of incidents, such as malware outbreaks, DDoS attacks, data leaks, etc. But they are also useful for restoring normal operations.

Technologies

The most important technical realms of an SOC are:

• A platform with security information (security intelligence)
• Tools for the investigation and analysis of incidents
• A complete, current list of all IT components (asset database), including the relevant responsibilities and contact information. Systems can only be protected if their existence is known in the first place.
• A system for recording, managing and documenting security incidents and the corresponding processes (incident management system)

The information platform is usually a classic SIEM or at least offers some of its features, but it might also be a well-configured log management system with the right monitoring rules. What is important here is to integrate as many relevant information sources as possible from across the entire organization, but most certainly the following:

• Security-related activities at all endpoints, i.e. not only the users’ workstations
• Security-related activities on the network (network traffic, firewall logs, proxy logs, vulnerability scans, etc.)
• Authentication and authorization processes (LDAP, Active Directory, VPN, etc.)

Ideally, this information is enriched with information from external sources, such as threat and vulnerability feeds.

If the usual channels of communication are unavailable or if they are to be avoided during incidents, it makes sense to have alternative communication methods (out-of-band) available, such as mobile phones. The SOC’s customers should also know which communications options are to be used. In this context, it is worth considering a backup internet connection, especially if business activities are highly dependent on a functioning internet connection.

Moreover, it makes sense to establish avenues for forensic investigations or to have certain services that can be deployed when needed.

In addition, for the sake of traceability as well as future improvements, it is essential that the activities of the SOC be recorded, with a ticketing system for instance.

Finally, it is very important that the quality and performance of the SOC be regularly assessed – on the one hand, to gain an objective basis for future improvements and, on the other hand, to better demonstrate the business-relevant benefits and value of the SOC.

The relevant considerations affect the selection of appropriate data sources, such as the ticketing system, SIEM, automation tools, customer feedback, etc. and the selection of an appropriate reporting tool, which may already be available. It is a good idea to focus on a few, yet meaningful measuring points and their accurate presentation in order to avoid misinterpretation.

One especially important metric is the time between the initial security breach and the detection of the attack (time to detection). This metric provides information about the entire cascade, from detection, identification, classification, and reaction. This requires a thorough analysis of the cause (root case analysis) and the initial compromising of the system or asset.

Various studies have shown that today only a small percentage of SOCs record any metrics at all, most of which are of a purely quantitative nature, such as the number of attacks or the number of patched vulnerabilities. The trick here is to also collect metrics that are business-relevant, such as the prevention of negative effects on business activities.

Final notes and recommendations

The following sections delve deeper into some other aspects that can simplify the structure of an SOC or improve its effectiveness and efficiency.

If parts of the SOC are outsourced, you will need to focus particularly on activities that require a deeper understanding of internal business activities, the advantages and disadvantages, as well as the associated risks.

The relatively high level of maturity often required of external service providers in certain areas frequently stems from the fact that these providers selectively and restrictively focus on certain technologies and services. If an organization requires extensive options for customization, it is often a good idea to closely weigh the advantages and disadvantages here as well.

If, in addition to the SOC, the organization in question has other departments that handle certain SOC tasks – such as a network operations center (NOC) or a computer emergency response team (CERT) – they must work closely with the SOC in order to avoid inefficiencies and problems stemming from redundant processes, overlapping and internal conflicts.

The structure and operation of an SOC represent a sizable cost factor, regular realistic simulations are essential in determining whether the investment is having the desired effect and whether the SOC is truly fit to handle a serious incident. Based on the results, specific improvements can be made and the efficiency of the SOC improved. A big part of improving the success rate of an SOC is trial and error.

Conclusion

To boil it all down to the key recommendations:

• Ensure that organizational structures and the performance mandate are clear
• Ensure that solid, functioning basic protections are in place, e.g. based on a recognized framework, such as NIST CSF
• Start small and define the most important use cases
• Collect metrics and incorporate them in the continuous improvement process

Lastly, remember that not every organization needs a fully-fledged SOC. In smaller environments, individual functions and technologies may be sufficient. However, no organization should go without adequate basic protection, proper data storage and processing practices, a few sound policies, and a minimum level of monitoring.

Find out more

• Recommendations for CSIRTs on how to improve, mature and be better prepared
• Assessing the maturity of CSIRT capabilities
• The SIM3 CSIRT Maturity Model
• A SOC Maturity Model

About the Author

Tomaso Vasella has a Master in Organic Chemistry at ETH Zürich. He is working in the cybersecurity field since 1999 and worked as a consultant, engineer, auditor and business developer. (ORCID 0000-0002-0216-1268)

Links

• https://opencsirt.org/maturity/sim3/
• https://vuldb.com
• https://www.enisa.europa.eu/publications/csirt-capabilities
• https://www.enisa.europa.eu/topics/csirts-in-europe/csirt-capabilities/csirt-maturity
• https://www.nist.gov/cyberframework