
In a connected enterprise, the question is no longer if a cyberattack will happen, but when. Are you prepared, or is your IT infrastructure facing a total blackout?
In a connected enterprise, the question is no longer if a cyberattack will happen, but when. Are you prepared, or is your IT infrastructure facing a total blackout?
Finding the right technology or service provider can be time-consuming and frustrating. In recent years, the market has evolved significantly—new providers have emerged, technology has improved, and established SOC vendors have updated their services. As a result, the selection process has become more complex, and comparing different offerings is increasingly difficult.
The key question is: How can your available budget be used efficiently to minimize the risk of a successful attack and limit the damage?
This article provides an overview of the challenges and driving factors in the area of Detection and Response. We also explain how to make the right decisions and which technologies are essential in a modern SOC.
The U.S. National Institute of Standards and Technology (NIST) defines the five functions Identify, Protect, Detect, Respond, and Recover in its Cybersecurity framework. These are also adopted in many standards and regulations, such as the ICT Minimum Standard. This article will use Detect and Respond (or Detection and Response) as equivalents to the German terms Erkennung/Detektion and Reaktion.
Detection and Response capabilities are commonly referred to as SOC capabilities and will be labeled as such in this article.
According to the BACS Half-Year Report 2024/1 (published on November 7, 2024), the number of cyberattacks remains high and continues to grow more targeted. Attacks on OT environments are now no longer an exception and can lead to production outages.
Pure protection measures are no longer sufficient. Attack attempts that bypass protection mechanisms can still be detected and mitigated through targeted Detection and Response measures.
A recent Survey by Suisse Digital shows that exactly these functions—Detection and Response—are underdeveloped, despite clear requirements from standards and regulations like the ICT minimum standard, StromVV the RevDSG, DORAor NIS-2 Directive. Commonly cited reasons include cost, complexity, and lack of in-house expertise.
Key challenges preventing the expansion of Detection and Response capabilities include:
So how should you proceed—and which Detection and Response measures are sensible and proportionate?
Detection and response is not an end in itself. The capabilities are used to ensure business capability and to detect and stop attacks. Therefore, they are included in various standards and regulations and used as building blocks in a security architecture.
Nevertheless, SOC capabilities are significantly less developed than the other NIST functions according to a current survey by Suisse Digital. There is therefore a need for action to ensure business continuity.
Implementation should follow a risk-based assessment that considers business processes and includes the individual environment. To do this, it is necessary to identify a company’s critical processes and values in order to subsequently derive the protection requirements.
Influencing factors include, for example, the industry in which I operate, since each industry has typical attack scenarios and system environments. Another influencing factor is the business processes and overall architecture. Business processes define the critical steps, data and systems that need to be protected, and the overall architecture enables compensatory measures.
Implementing a best-practice approach across all capability areas company-wide is not realistic, especially for smaller companies. The high costs that would arise from consistent implementation of all capabilities usually exceed most IT budgets.
It turns out that after the preliminary protection needs analysis, the threat situation must also be taken into account in order to derive the individual prioritization that can be implemented with the available budget. The depth of implementation of the identified capabilities also plays a role in planning the next steps. The depth of capabilities means, for example, whether all systems can be monitored with a technology or only critical systems. In addition, service times such as 24x7 or 10x5 can be distinguished.
The individual situation of a company then determines further areas for action. If operational technologies (OT) are in use, for example in machine control, signal technology, monitoring and control of pipelines, these components must also be taken into account in a concept.
In this context, capabilities do not necessarily mean only technical capabilities, but also organizational capabilities, i.e., processes to be able to react quickly and efficiently.
After identifying and selecting the required capabilities, there are two options:
a) Technology selection
b) “Make” vs. “Buy” decision and selection of a service provider
Depending on the corporate strategy, one question may already answer the other: for example, if a company decides to outsource supporting functions such as IT and use service providers, selecting a service provider narrows down the possible EDR technologies. Most service providers support two EDR technologies.
The reverse is also true. If an (EDR) technology is selected first, the service provider should be able to operate this technology, thereby reducing the selection of service providers. Which question takes priority must be answered individually for each company and considered in the overall concept.
The identified capabilities usually also require technological support. For the area of detection and response, this includes Endpoint Detection and Response (EDR) technologies, Security Information and Event Management (SIEM) solutions, Network Detection and Response (NDR) technologies, and, for companies using Operational Technology (OT), a corresponding specialized OT monitoring and security solution. Identity Detection and Response (IDR) has come into sharper focus in recent months, as the technologies are now mature and identity is one of the most critical elements in the security concept.
To control and monitor these technologies as a whole and then initiate targeted measures, it is recommended to use a SOAR (Security Orchestration Automation Response) tool. To use this effectively, a high degree of standardization within the infrastructure is a prerequisite. Visibility of business processes and their requirements is also essential in order to use such software meaningfully.
Each technology area includes several active manufacturers, and selecting the right solution can be difficult, as smaller companies lack the capacity for a detailed analysis. Procurement based on data sheets and documentation is also challenging, because these are often similar across manufacturers and it is difficult to determine if the solution fits the planned deployment environment without a proof of concept (PoC) or proof of value (PoV).
We recommend answering the following questions when selecting a technology (e.g., in a PoV):
The second question in building capabilities is which capabilities should be built internally (make) and which should be covered by external service providers (buy). Here, the required depth of capabilities (see above), the cost, and the size of the company play a central role.
For example, building 24x7 monitoring requires a large team, which many companies do not have and cannot afford to build. If 24x7 is covered by a service provider, a contact person is still needed who can make decisions (e.g., shut down servers and services, isolate clients). The contact person must be just as reachable as the service provider. Therefore, it may make more sense to reduce monitoring by the service provider to 5x10 and possibly even cover this internally.
Building internal know-how, being able to operate the deployed technology, understanding the generated alerts, and responding appropriately is a major effort. A service provider can support this, as they are able to focus on the deployed technologies and build sufficient knowledge. This enables faster analysis, and only specific questions and recommended actions need to be handled by the company itself.
Furthermore, the homogeneity and use of standard software influence the ability to use service providers for monitoring (see SOAR). The more homogeneous the infrastructure is, the easier it is for a service provider to take over monitoring, and the fewer questions arise about exceptions and unknown systems. Alerts generated by Microsoft technologies like Defender for Endpoint, Defender for Identity, or Microsoft Sentinel can be processed by most service providers, who can provide concrete assistance. If the infrastructure is very heterogeneous and little standard software is used, service providers will have difficulties analyzing security incidents and more inquiries will end up with the internal teams. The added value of a service provider decreases.
The smaller the company, the more a standards-based approach to the software used pays off, and the more value a standardized managed service can provide. Building a specialized team is generally more expensive than purchasing a service.
EDR technology has now matured and belongs to legacy systems. A concept for detection and response is no longer conceivable without an EDR system. This is because an EDR system is widely deployed and at the same time can take an in-depth look at and intervene in endpoints. However, selecting an appropriate system or provider is considerably more difficult. Various aspects and criteria must be considered:
In general, one of the market leaders can be used here. These currently include Microsoft, CrowdStrike, SentinelOne, PaloAlto, and TrendMicro. Depending on the requirement, the selection narrows down to one or two technologies.
Until a few years ago, detection and response services were primarily implemented through the development of SIEM solutions. In recent years, this trend has shifted toward EDR and is now moving toward XDR or NG-SIEM platforms. Classic SIEM systems are therefore used as (normalized) log solutions and are no longer at the forefront as a detection platform.
SIEM systems are useful tools for simplifying evidence requirements and access (audit), as decentralized systems are significantly more complex when answering inquiries. Since companies in regulated industries or critical infrastructure usually have increased evidence requirements, SIEM is a useful addition that can also be integrated into the processing of security incidents.
Moreover, the newer NG-SIEMs or XDR platforms are also a meaningful supplement. Here, expert systems such as EDR and NDR are connected to a central (SIEM) system, where additional logs, such as firewall logs or access and change logs, are also fed in. This allows the analysis of alerts from a single interface while still maintaining the detailed insight from expert systems. This combination is increasingly being integrated into SOC services and can be considered a sensible solution if, for example, evidence requirements need to be covered or all security-relevant information should be visible at a glance.
Ensuring the security of OT systems was traditionally managed through physical or logical network separation. This is no longer sufficient today for various reasons. On the one hand, IT systems are indispensable in the data processing and control of OT systems, and on the other, more and more groups—such as external service providers or manufacturers—require access to the systems. A completely separated network is now rarely encountered. This leads to additional protection needs in the OT environment.
Some manufacturers such as Dragos, Nozomi, and Claroty as well as Microsoft with Defender for IoT or Tenable IoT have focused on this area and provide specialized monitoring solutions that do not directly interfere with OT processes and protocols, but can detect irregularities and generate alerts. Evaluating and deploying such systems is now a necessity for OT environments.
On the other hand, this is difficult to outsource, as OT environments are highly customer-specific and many Managed Security Service Providers (MSSPs) are still developing appropriate capabilities. Therefore, it is essential to evaluate the required capabilities thoroughly and, if necessary, to establish an internal process to protect this area. It appears that today, especially smaller, OT-specialized providers can offer real added value.
NDR systems detect anomalies in network traffic and trigger alerts in case of irregularities. NDR systems like Darktrace, Exeon, or Vectra also enable monitoring of network traffic without directly interfering with it or requiring agents to be installed on endpoints—something rarely feasible in OT environments. Although traditional NDR systems focus less on OT environments and security systems, they can still be used in this area.
The challenge with NDR systems is the high false positive rate, where legitimate data flows are classified as potentially dangerous. The corresponding analysis requires experience and time and can result in significant effort. Nonetheless, NDR systems have their justification as a compensating measure. Usually, however, an NDR system is not introduced as the first system.
For all technologies used, integration into appropriate response processes is a key element. No technology works unless the alerts are processed and unless there is a clear plan on how to respond in specific situations, who to inform, and how to proceed. Preparing the processes and the action plan for a security incident (Incident Response) is critical. Especially in smaller companies, this is often not sufficiently considered, and there is an over-reliance on technology alone.
Creating playbooks can be a major advantage in crisis situations and significantly reduce the impact of an attack.
If you have any questions or comments, don’t hesitate to contact us.