This third article focuses on a key question: how do you measure the efficiency of your OT detection? 

From compliance to efficiency: a KPI paradigm shift 

KPI stands for Key Performance Indicator. However, we tend to create KPIs to monitor progress against our plans, not real performance. While useful, monitoring only deployment or coverage (number of sites connected to the SOC, EDR deployment on OT machines, number of probes registered to the management console) tells you very little about the actual ability of your SOC to detect a real attacker. 

So, how confident are you in your detection tools, use cases, and processes? The only way to be sure is simple: test them. And the best way to test them is through Purple Team exercises. 

What is Purple Teaming in OT? 

A Purple Team exercise is a collaborative mission between the Red Team (attackers) and the Blue Team (defenders). Unlike a traditional Red Team assessment, where the defenders are kept in the dark and evaluated afterward, a Purple Team exercise is an iterative, joint effort. 

This collaborative approach allows both teams to: 

• Share assumptions about the OT environment 
• Validate detection logic in real time 
• Understand blind spots 
• Improve playbooks and detection pipelines 
• Align everyone around a realistic threat model 

Performing a Purple Team Exercise 

A Purple Team operation can be summarized in three main phases: 

1. Preparation

The preparation phase is often the most challenging, especially in OT environments, where safety, process continuity, and vendor constraints must be considered. 

Depending on the maturity of the organization, preparation can range from basic to highly sophisticated: 

• Unit Tests 
  Small, isolated tests of specific detection rules (e.g., “Detect Modbus function code 90”). 
• Feared Scenario-based Testing 
  Build scenarios around the organization’s crown jewels and failure modes (e.g., “Unauthorized remote program upload on a PLC controlling a critical process”). 
• CTI-Infused Testing 
  Integrate threat intelligence: test techniques used by real OT-focused attackers (e.g. TTPs from Volt Typhoon, Sandworm, Xenotime, or ransomware groups targeting industrial environments). 

To structure the preparation phase, two elements are essential: 

• A good knowledge of your OT environment 
  Planning an exercise that will be relevant to both the business risks & OT detection without impacting the process requires a deep knowledge of the site and its automation. 
• Mapping to the MITRE ATT&CK for ICS matrix 
  Mapping your tests to the ATT&CK matrix allows you to have a common language with the detection teams. This allows you to select relevant techniques, avoid blind spots, and ensure coverage across multiple layers: OT workstations, PLCs, network interactions, engineering actions… 

2. D-day (Execution)

Execution is performed jointly: 

• The Red Team launches controlled and authorized actions 
• The Blue Team monitors detections in real time 
• Both teams adjust, document, and validate findings as the exercise unfolds 

Depending on the scope and complexity of the tests, the Purple Team operation can last from a few hours to a few days. 

Ensuring Reproducibility with Caldera 

To ensure repeatability and consistency across Purple Team exercises, automation becomes key.  Caldera, an open-source Breach & Attack Simulation (BAS) framework developed by MITRE, is a powerful tool for this. 

As a former pentester, I’ve always disliked the term “automated pentest”—but BAS tools are the closest thing we have to repeatable, safe attack execution. 

Why use Caldera instead of performing tests manually? 

Caldera enables you to: 

• Prepare and validate a controlled list of tests on a controlled list of assets 
• Ensure only authorized actions are executed 
• Guarantee reproducibility across environments 
• Replay the exact same actions to measure improvements after configuration changes 

Some OT-specific plugins already exist in the Caldera-OT module, supporting Modbus, Profinet, DNP3, and others. 

Recently, Wavestone released two additional OT plugins: 

• Siemens S7 protocol support 
• OPC-UA communications actions 

Caldera in a nutshell 

Caldera usage relies on: 

• Abilities: atomic technical actions (e.g., reading coils, writing tags, scanning a PLC) 
• Adversaries: collections of abilities that form a scenario 
• Operations: real-time execution of those adversaries against a target 

Fact sources: parameters provided for an operation; you can launch the same operations against different environments by just changing the fact source. 

The following video (French with English subtitles) will walk you through a demonstration of Caldera on our small ICS demo setup: 

3. Debriefing

The debrief is where most of the value is extracted. The following types of Key Performance Indicators might be used: 

• Detection Coverage – what percentage of executed stimuli were detected? 
• Alert Quality – were alerts actionable, precise, and intelligible? 
• Reaction Time – how long before an alert is raised and acknowledged? 
• Playbook Efficiency – were the right actions taken in the expected time frame? 

These might phase results in: 

• Updated detection rules 
• Improved SIEM/SOC playbooks 
• Better monitoring architecture 
• Training material for analysts and engineers 

Start Testing Now! 

Purple Team testing brings value immediately, no matter what your current maturity level is: 

• It validates your tools in real-world conditions 
• It trains your SOC and OT teams 
• It reveals blind spots early in the program 
• It provides quantitative KPIs to drive detection improvements 

And yes, it is possible, in most production environments, under the following conditions: 

• Strictly controlled scope 
• Vendor-approved actions 
• No disruptive functions executed 
• Involvement of operations and safety teams 
• Continuous monitoring of system behavior during testing 

In short: start small, stay safe, and iterate. 

Do not wait for your OT security program to be “finished” before you start testing its effectiveness! 

Cet article Purple Teaming for OT:  How to switch from a compliance to a performance mindset? est apparu en premier sur RiskInsight.

In a previous article: Cybersecurity monitoring for OT, Current situation & perspectives we have seen that OT, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. But, due to the difficulty in updating legacy Industrial Control Systems (ICS), cybersecurity measures are often added after deployment. Continuous monitoring is seen as a practical substitute for built-in, cyber-by-design protection. 

When it comes to monitoring tooling, we observed that 100% of our clients have detection tools deployed on the IT side of industrial sites. But only one-third extend monitoring down to the lower layers of the industrial environment:

There is a large variety of detection sources allowing monitoring across different levels of the Purdue model:

• Firewalls (including industrial firewalls)
• Endpoint protection (AV, application whitelisting, EPP, EDR etc.)
• Authentication and access logs (e.g., Active Directory, local authentication)
• Remote access logs (e.g., VPN, jump servers, bastion)
• Deceptive technologies (e.g., honeypots or decoys)
• Network detection and monitoring probes (listening industrial networks)
• Logs from media sanitization or data transfer stations (e.g., USB kiosks)
• Industrial logs (from SCADA, HMI, PLC … when available)

Traditionally, these logs are collected and analyzed by SIEM and/or SOAR solutions, with or without specific OT detection patterns, and should enable the SOC team to detect, investigate, and respond to security events.

Building a consistent detection strategy for OT environments does not require collecting data from every possible source. In fact, a few well-chosen, properly configured, and actively monitored sources can provide strong visibility and early detection capabilities. The key is to focus on data sources that are both relevant to the specific OT architecture and feasible to monitor without disrupting operations. Prioritizing quality and operational relevance over quantity ensures a more effective and sustainable cybersecurity posture.

How to get the most of detection sources?

Start with logs you already have

A pragmatic and cost-effective way to approach OT detection is to start by leveraging the logs and detection patterns already available within the industrial environment, particularly those already exploited for your IT environments. For example, firewall logs, especially those monitoring IT/OT boundaries, can provide valuable insights into network traffic patterns, segmentation breaches, or suspicious remote access attempts. Similarly, Active Directory (AD) logs can reveal abnormal user behavior, failed authentication attempts, or privilege escalations — all of which are critical signals in both IT and OT contexts. Leveraging these existing sources allows organizations to build initial detection capabilities without heavy investment, while laying a solid foundation for more advanced monitoring in the future.

Rather than starting with deploying complex OT-specific detection tools, organizations should build initial detection capabilities using what is already deployed, configured, and understood. This not only reduces costs but accelerates implementation across industrial sites. The goal is to ensure a consistent baseline of visibility across critical applications, systems, and infrastructure before diving deeper.

By starting with what you already have, and focusing on coverage, not complexity, organizations can address OT detection with speed, relevance, and operational realism, while setting the stage for more advanced capabilities down the line.

We will now focus on the two detection tools most widely adopted and discussed in industrial environments today: EDR solutions and OT network detection probes.
In the following sections, we will examine how to leverage these solutions effectively and outline our recommendations.

EDR

Endpoint Detection & Response solutions provide continuous monitoring and analysis of endpoint activities to detect, investigate, and respond to cyber threats in real time. EDR collects detailed data such as process execution, file changes, network connections, and user behavior. By leveraging behavioral analytics and threat intelligence, EDR tools can identify suspicious activities like malware infections, lateral movement, or privilege escalation.

This detection tool, widely used and popularized in IT environments, is now being adopted by most of our clients for deployment within their industrial environments, driven by the evolution of deployment models, the broader coverage of operating systems, and the improved performance of detection models in increasingly complex environments.

However, this does not mean that 100% of OT devices are compatible with EDR solutions. In fact, EDR compatibility varies significantly across different industrial systems due to their diversity and operational constraints. EDR deployment is generally straightforward on higher levels of the Purdue model, such as Layer 3 and Layer 3.5, where systems resemble traditional IT environments like servers and workstations. At Layer 2, implementation requires careful evaluation with vendors support and testing, as devices and protocols become more specialized and resource constrained. Finally, at the lowest levels, controllers, PLCs, and field devices, EDR is generally not viable due to limited processing capacity, proprietary operating systems, and real-time performance requirements.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To conclude, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

A detection probe is a piece of equipment, virtual or physical, connected to the information system in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyze this data.

Probes for industrial environments, which we will refer to simply as OT probes here, are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behavior. All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. OT probes promises wide detection capabilities and variety of possible cases of these data. The features and types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular. 

However, our clients often face significant challenges when it comes to deploying these probes and effectively leveraging them for detection at scale.

Here are a few common pain points when deploying OT probes:

• Industrial site network capabilities and resources: Deploying OT probes often presents significant challenges due to the limitations of industrial network infrastructure. Network taps and SPAN ports on switches, commonly used for traffic monitoring, are not always manageable or available in OT environments, which limits options for passive traffic capture. Additionally, the costs associated with installing dedicated network taps can be prohibitive, especially across distributed and remote industrial sites. Moreover, deploying and maintaining probes requires skilled resources on-site.
• OT probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team knowledge and lack of documentation. Moreover, because industrial environments vary between different sites within the same organization, it is very difficult to establish a one-size-fits-all blueprint. In some architectures, achieving comprehensive asset coverage may require deploying dozens of collection points. As a result, selecting and configuring listening points is a repetitive, iterative process that must be adapted for each location to ensure optimal visibility and detection capabilities.

More than deploying, operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively. On average, we estimate that one full-time SOC analyst is required to manage the alerts generated by 50 probes.

In the end, OT probes may be popular, but deployment and tuning costs and resources limit their full utilization. Our recommendation is to prioritize deploying OT probes for critical sites or within key network segments that demand advanced industrial and network monitoring capabilities. Deployment should also be aligned with the organization’s capacity to manage the associated tuning and operational workload. This approach helps maximize return on investment while ensuring effective detection where it matters most for our clients.

Consider other solutions?

Regarding detection for industrial perimeter, while this article focuses on key detection sources like EDR and OT network probes, it is important to acknowledge that other solutions such as deceptive technologies (e.g., honeypots or decoys) can also play a valuable role and be relevant in specific scenarios or environment according to your industrial sites architecture or feared compromission scenarios.

Conclusion

To conclude, here are the key recommendations to build an effective detection tooling strategy to monitor industrial environments       :

1. Leverage existing tools for immediate impact:

Begin by maximizing the value of detection sources already available in your industrial environment: firewall logs, active directory, remote access logs… and EDR, that can be quickly implemented on OT servers and workstations, offering high visibility with minimal effort. Adapting proven IT detection logic to OT use cases enables organizations to rapidly establish a baseline level of visibility without the need for heavy investments or complex integrations. This pragmatic approach ensures faster deployment and broader coverage of your OT assets.

2. Deploy advanced solutions where you can manage the workload

When extending your detection capabilities, prioritize the deployment of advanced tools like OT network probes where they provide the most value. For network probes, focus on critical sites or segments, and carefully select listening points to balance visibility, cost, and operational overhead. This targeted deployment approach ensures resources are used efficiently and strategically.

3. Prioritize quality and relevance over quantity

Building an effective OT detection strategy does not require monitoring every possible data source. Instead, focus on sources that are both relevant to your environment and technically feasible to collect without disrupting operations. This approach allows reducing log storage and management costs and enable the creation of more relevant, high quality detection rules.

Do not hesitate to reach out to discuss how you can build and improve your detection strategy to monitor your industrial assets!

In our next article, we will look at how to evaluate detection in industrial environments using purple team exercises, a practical way to assess and improve your detection capabilities.

Cet article Cybersecurity tooling strategy for an effective industrial detection est apparu en premier sur RiskInsight.

Operational Technology, while overall less impacted than IT, is not exempt from cyberthreats & not immune to cyberattacks. Let’s take a closer look at a simplified view of the threat landscape for industrial environments:

• Hacktivism: Increased geopolitical tensions in 2025 have led to low-level attacks by groups like CyberArmyofRussia_Reborn and CyberAv3ngers.
• Cyber Crime / Ransomware: There has been an 87% increase in ransomware attacks on industrial groups in 2025 according to Dragos in its annual report.
• Nation-State: Notable campaigns include Voltzite OT information theft and the IOControl campaign.

This threat landscape was notably depicted by Chris Sistrunk, ICS/OT Technical Leader at Mandiant, Google Cloud Security, at Black Hat 2025:

Given this increasing threat landscape targeting OT, continuous monitoring is essential. So, we know why industrial information systems need to be closely monitored, and we also know that our clients are actively working toward that goal. But one key question remains: how do we measure the effectiveness of detection? And how can we improve it?

How to assess the effectiveness and improve detection on industrial perimeter?

To answer that question, we developed a methodology aimed at evaluating detection capabilities within industrial SOCs.

The evaluation was built around the core activities of a SOC, structured into four pillars:

Using this framework, we assessed ~15 industrial clients to better understand their level of maturity. In this article, we’ll share the key trends and insights that emerged, focusing specifically on detection-related questions. Two follow-up articles will be published: one delving into the effectiveness of various detection strategies and solutions, and another explaining how to test detection capabilities in industrial environments with purple teaming and the custom modules developed for that purpose.

Governance & Strategy

The first question we focused on was whether industrial sites monitoring is handled by a dedicated team using specialized tools — or if, on the contrary, it’s integrated into a broader, centralized SOC approach.

Responses are unanimous:

These figures can be explained by several factors. One key reason is financial rationalization. Maintaining two separate teams with similar skill sets: managing alerts, configuring tools, duplicating capabilities… is costly. However, a unified SOC implies an extended scope to cover OT, but not the presence of OT-specific tools or expertise and in the end, OT detection capabilities.

Even if this approach does not guarantee effective detection and response across the OT scope, a unified SOC can manage OT incidents efficiently, under the right conditions:

End-to-end monitoring

If we look closely at the simplified threat landscape, cyberattacks might not be IT or OT-specific. Cybercrime such as ransomware, the dominant threat today, is not limited to IT or OT alone. It often spreads across both, making it essential for alerts to be followed from end-to-end.

In the end, unifying the detection teams & tools make sense as attacks are not necessarily exclusively IT or OT.

Link with industrial sites

Response time & information sharing is crucial in cyber incidents. As most security teams are centralized in a unique location, there is a need for a link between central security teams and local industrial sites in cyber incident response process:

• This relay is familiar with industrial sites, their specific characteristics, operational context, and modes of functioning
• They also maintain contact on-site to quickly gather the information required for triage, doubt resolution or investigation
• In addition, in global organizations, having resources in the right time zones and ability to communicate in the local language is key, especially in the industrial world

Referred to as Cyber-OT Referents, these relays play an active role in the incident resolution process, particularly during investigation and remediation:

In conclusion, even though unified SOC covering IT and OT are often driven by cost optimization, the model makes sense considering that many threats span both domains. Still, this must not be treated as a simple extension of the perimeter to cover, dedicated OT relays and expertise are essential to properly handle industrial-specific contexts.

Tooling

When it comes to tooling, we observed that 100% of our clients have detection tools deployed on the IT side. However, only one-third extend monitoring down to the lower layers of the industrial environment.

Detection sources covering different levels of the Purdue model

We will focus on popular solutions to address detection in industrial environments: EDR and OT probes.

2.2.1 EDR

Few figures regarding EDR:

Most of our clients have started deploying EDR in their industrial environments.

However, this does not mean that 100% of EDR-compatible OT machines are covered.

For environments that support it, extending EDR coverage allows to:

• Address low maturity: Start with tools that are easier to implement and require less maturity.
• Broad coverage: Focus on quickly covering a wide range of systems, sites, and critical applications.
• Leverage IT tools: Use IT-based solutions like EDR for effective detection without heavy infrastructure requirements.

To do so, most organizations opt to use the same EDR solution for both IT and OT environments. It enables faster rollout thanks to a known and already-integrated tool. Depending on needs and available resources, a different solution may be selected to improve resilience and OT-compatibility.

To conclude, with IT/OT convergence, deploying EDR Agents on OT Servers and Workstations is becoming increasingly relevant, and a quick win for OT detection, according to our clients’ feedback.

OT Probes

Few figures regarding probes:

When it comes to probes, the gap between these two figures highlights the challenge of deploying probes at scale and effectively using them for detection in industrial networks.

Indeed, probes collect and correlate information through network traffic capture. To be effective, their deployment requires carefully selecting listening points based on the intended targets. Listening points need to be tailored to each site architecture, often limited by local team’s knowledge and lack of documentation.

Operating these probes also comes with challenges and requires a significant workload. They tend to generate a high number of false positives, which means teams must create tailored detection rules and playbooks to filter and respond effectively.

In the end, OT Probes may be popular, but deployment and tuning costs and resources limit their full utilization.

Start basic with OT detection tools

In the end, for OT detection, we believe in starting basic by leveraging “IT” tools to ensure a first level of coverage across all sites, critical apps, and infrastructure:

• Prioritize critical assets: Focus on key systems (MES, safety tools, network) essential for production, ensuring they are closely monitored before extending deployment to the lower levels of the Purdue model.
• Implement basic detection: Establish foundational detection across sites and infrastructure for early issue identification, before advancing to complex OT solutions.

Training & Testing

Detection does not rely on deploying tools alone; we will focus here on team’s ability to use them effectively.

A need for more OT-specific knowledge

Benchmark figures revealed a limited understanding and adaptation of both teams and processes to industrial environments:

To bridge the gap, teams need training tailored to industrial contexts, basic for all SOC analysts, and in-depth for OT specialists.

In the same way, investigation and response processes must also be adapted to address the specific needs of industrial environments, where priorities such as availability differ from those in the IT world.

Test your detection!

Finally, improving detection starts with evaluating it but today …

Only a small minority test their real detection capabilities, but we believe that there is room for purple team exercise in OT. These collaborative exercises with the OT SOC, tailored to its maturity and goals, can test and enhance both detection tools and OT SOC processes.

It can start simple: by selecting appropriate production environments and performing a few basic tests like inserting a USB key with a standard malware sample or attempting a couple of privilege escalation actions… we can evaluate whether the EDR deployed on a workstation connected to your SOC will trigger an investigation.

This exercise helps identify the blind spots and adjust tooling, process and playbooks accordingly.

Conclusion: How to enhance the overall low maturity in detection for industrial systems?

The benchmark’s first conclusion is clear: maturity levels are low, and this is a consistent answer across all collected responses. How to enhance this overall low maturity in detection for industrial systems?

Here are the key outcomes regarding the three topics covered in this article:

Do not hesitate to reach out to discuss how you can strengthen your detection capabilities and measure your maturity against the market!

Cet article Cybersecurity monitoring for OT – Current situation & perspectives est apparu en premier sur RiskInsight.

OT Probes: A tool for monitoring industrial networks 

Figure 1: Listening to the network to assess and detect 

A detection probe is a piece of equipment, virtual or physical, connected to the information system (IS) in order to map and monitor it. It consists of sensors distributed across the network to collect data. And typically, a central console to aggregate, correlate and analyse this data. Probes for industrial environments – which we will refer to simply as OT probes here – are characterized by their passive, non-invasive listening on the network, and their understanding of industrial protocols and behaviour. Many players are present on the market, you can find our market overview here: https://www.riskinsight-wavestone.com/2021/03/les-sondes-de-detection-en-milieu-industriel-notre-vision-du-marche/  

All their probe solutions work on the same principle: network traffic is collected using flow duplication (SPAN, ERSPAN …) or physical duplicator like taps, etc. Packets are inspected in real time to provide several types of data: flow inventory and mapping, asset and vulnerability management, and finally anomaly and incident detection. 

This variety of possible use cases of these data and the types of users involved (operational and business team, cybersecurity team, etc.) is what makes OT probes so popular.  

However, procuring and deploying these solutions are costly. The organisation must have a clear understanding of their needs, a view of potential users and the exact added value required before embarking on such a project. 

Let’s take two very different examples 

Imagine two companies are considering deploying OT probes on their industrial sites.  

1st Company: WavePetro 

WavePetro is a company with a large sensitive site, which has a good level of cybersecurity maturity, as well as a segmented architecture. The company wants to deploy OT probes to be compliant with regulations and to improve its detection capabilities. 

Considering its architecture and detection requirements, numerous listening points will be needed on the site. WavePetro can rely on its local teams for expertise and site knowledge to support this complexity. 

2nd Company: RenewStone 

RenewStone has numerous scattered and unmanned small sites with different cybersecurity maturity levels. The sites are connected to central Group infrastructure. 
The company wants to deploy OT probes to gain visibility on its sites using inventory and vulnerability management features.  

With this configuration, RenewStone needs to standardize a turnkey OT probe roll-out and run service with as little local complexity as possible.  

Figure 2: 2 companies, 2 reasons to deploy OT probes, 2 implementation plans 

What is required for a successful roll-out? 

Although these two companies have different drivers and maturities, they will go through the same 5 key stages, albeit with different approaches.  

1.Perform a Proof of Concept 

Let’s start with the first step: the proof of concept. The objective for both companies is to test the feasibility and challenge the value this tool brings to the organisation. 

While WavePetro have to validate feasibility on a reduced perimeter in the factory, RenewStone has to validate OT probe added value validation on few different sites. 

The PoC is key in identifying what can be valuable for both companies. To get the most of it, it is important to: 

• Adapt vendors selection to your needs: The market is quite diversified between pure players, those specializing in industry or extending their IT solutions …  
  Do I want strong detection capabilities? Do I want a managed service? Do I want a unified solution for IT and OT?  
• Select the PoC scope: Identify a representative scope with resources to test on so that results can be reproduced at scale.  
• Draft a target architecture before the PoC: This allows to test an architecture that will be representative of what would be deployed at scale, in order to validate the tests carried out. 

PoC is an essential step to ensure that the tool provides value to your company, but also to be able to convince businesses to deploy especially when not constrained by regulations. 

2.Build the associated operating model  

Even from the early stages, before rollouts, it is important to remember that the end goal of the probes deployment will be to get value from its operation. To be able to do so, it is essential to: 

• Define an operating model for handling alerts, managing the inventory and managing the probes themselves. While WavePetro can have an operating model heavily relying on local knowledge and expertise, RenewStone must build a central operation model to include group teams such as SOC, OT security, network, infrastructure and so on. 
• Decide whether to call on a third party or manage your probes in-house: Few vendors also propose managed service, so you would need to create your own model, which could also rely – wholly or partly – on externalization. 
• Create a RACI: Considering the different use cases and the number of players involved in using or maintaining probes, a RACI is key to ensuring that all stakeholders are involved. 

This stage must be addressed upstream to facilitate the next steps. 

3.Prepare the roll-out  

Once the first step has demonstrated the added value of a probe and their operating model has been defined, let’s prepare for the roll-out. You need to define the final target: 

• Where you will deploy: Especially if you have many diverse sites, like RenewStone, you need to be precise on, and prioritize, the scope: It will not be possible to deploy all sites at the same time. 
• When you will deploy: Work on budget estimates, even if not accurate, as soon as possible so that sites are able to plan a roll-out on the following year. Probes are an expensive solution, not only in terms of hardware and licensing, but also in terms of the resources required to deploy and operate them. 
• How you will deploy: In any case, you need to work on a standard architecture blueprint. But especially if you have many sites to deploy or very limited local resources, you should work on building a packaged service offer to deploy.  

This preparation part is key to avoid wasting time with deployments and guarantee their success. 

4.Deploy ! 

Let’s start deploying… The motto is the same for both companies: Start small and grow.  
The difference lies in the scale:  

• Gradually roll out across the site for WavePetro: It will take some time to be able to listen everywhere effectively. Focus on the expected data to prioritize where to place the probe at first and where to listen to the network. 
• Learn and improve from one roll-out to the next for RenewStone: Rollouts are centralized and more standardized, so teams will learn and improve from one roll-out to the next. There should be a first ring of roll-out that is comprised of representative sites to test and improve the deployment model on.  
• Include change management: in all cases, the deployment of a new tool must absolutely include awareness-raising and training if probes are to find their users. 

Deploying OT probes can be a long and tedious process, but do not get discouraged, because there is still one big step left! 

5.Fine-tune OT probe console 

A probe roll-out is not a “1-and-done” kind of project. This is a tool for continuous improvement and needs to learn to deliver value. You should therefore dedicate time to: 

• Fine-tune OT Probes dashboard: Take time to improve the detection model (whitelist some behaviors, prioritize sensitive assets …), the automatic asset inventory and mapping (enrich inventory, import data, tag VLANs …), and so on. This fine-tuning needs to be done by someone with site-specific knowledge.  
• Integrate with other technologies: You can integrate OT probes consoles with your other solutions and tools such as the SIEM, firewalls or CMDBs to make the most of the data collected by the probes. 
• Try adding features: once you have gained some maturity over the solution, you can go even further with the features available like performing active queries to enrich the inventory and go even further with the features available. 

Fine-tuning enables the solution to reduce the amount of data it retrieves, so that it can focus on security data and alerts that will bring value to your company and its security level. 

Figure 3: Takeaways from 5 key steps towards an OT probes service 

Conclusion 

These 2 examples have taught us a lot about OT probes, and the many challenges involved in deploying and using them. If tomorrow, I were facing a customer wondering what to do with this OT Probe project on his roadmap, I would pick out 3 main elements: 

Figure 4: The 3 keys to a successful probe project 

Before deploying: Is it worth it ? 

Without clearly identified use cases and defined objectives, you may end up with probes providing unused or no real added value information. OT probes are expensive, both financially and in terms of time. You need to make sure they are worth it, and then gives you the means to fully exploit them. 

To do this, take the time to evaluate the quality and value of the information provided by the OT probes with your different teams (cybersecurity, operations, business…). 

Start small and grow 

Don’t be afraid to start small and grow progressively, whether that is in the number of monitored sites, assets or use cases. 

The long-term operation of OT probes is complex and builds over deployments. Take the time to take care of the solution adoption: if you want teams to use the solution, train them and demonstrate OT probes value! 

Rely on continuous improvement 

As for any robust cybersecurity process, continuous improvement should be at its core. Cyber threats are constantly evolving, from attacker techniques to OT exposure due to process digitalization. 

In parallel OT Probes can provide a wide of capabilities from incident detection to cartography, vulnerability management and even more yet to be released by editors. 

Focus first on capabilities that reduce your OT risks, progressively improving the services as it gains maturity! 

Cet article Detection probes for OT : The keys to a successful deployment est apparu en premier sur RiskInsight.