Security Testing
Tomaso Vasella
How to make sure your SOC succeeds
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.
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.
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:
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:
The following sections explore the minimum elements required for an SOC with respect to these three aspects in more detail.
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.
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:
The threat models make it possible to answer the following questions:
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.
The most important technical realms of an SOC are:
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:
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.
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.
To boil it all down to the key recommendations:
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.
Our experts will get in contact with you!
Tomaso Vasella
Tomaso Vasella
Tomaso Vasella
Tomaso Vasella
Our experts will get in contact with you!