PLCs: To Scan Or Not To Scan

PLCs: To Scan Or Not To Scan

Speakers: Raphael Arakelian

Conference: S4

YouTube: https://www.youtube.com/watch?v=yqhn4xPwbfQ

Overview

The critical question of whether to actively scan Programmable Logic Controllers (PLCs) in Operational Technology (OT) environments has long been a contentious issue. Raphael Arakelian's talk, "PLCs: To Scan Or Not To Scan," delivered at the S4 conference, delves into this complex dilemma, aiming to provide empirical data to guide asset owners. The presentation highlights a significant trust gap: while asset owners recognize the importance of active detection for comprehensive asset inventories, they often hesitate to deploy it due to concerns about operational impact and a history of shifting vendor messaging.

Arakelian’s research directly addresses the lack of in-depth, independent studies on the impact of active scanning on live PLCs. For years, OT monitoring vendors advocated for passive detection, only to gradually incorporate active techniques and rebrand them as "safe." This shift has eroded confidence, leaving asset owners without clear, evidence-based guidance. This talk aims to bridge that gap by thoroughly investigating the effects of both traditional and "targeted" active scanning on various PLC models, providing much-needed clarity for the ICS security community.

The significance of this research cannot be overstated. PLCs are the backbone of industrial control systems, directly influencing physical processes. Any disruption or performance degradation caused by security tools can have severe consequences, from production halts to safety incidents. By meticulously detailing his testing methodology and findings, Arakelian empowers asset owners to make informed decisions about their OT security strategies, advocating for a data-driven approach to a critical security challenge.

Background

▶ Watch: Introduction: The dilemma of active OT scanning. (0:00)

The evolution of OT monitoring has been marked by a significant shift in philosophy regarding active data collection. Historically, between 2013 and 2018, the prevailing wisdom among OT monitoring vendors was that active detection on OT devices was inherently dangerous and should be strictly avoided, with passive detection being the recommended approach. This stance was largely due to the perceived fragility of industrial control systems and the potential for traditional IT-centric scanning methods to disrupt critical operations.

However, as the limitations of purely passive monitoring became apparent—particularly in achieving comprehensive asset inventories and detecting certain types of threats—many of these same vendors began to integrate active capabilities into their products. Concurrently, their messaging underwent a dramatic transformation. What was once deemed perilous was now rebranded as "safe, reliable, and highly recommended." This abrupt change, often unaccompanied by rigorous, publicly available studies, understandably created skepticism within the asset owner community.

To distinguish their new active methods from the potentially disruptive traditional active scanning employed by IT vulnerability scanners, OT vendors introduced a new lexicon. Terms like "safe queries," "polling," "smart polling," "selective probing," and "safe probing" emerged. Raphael Arakelian argues that these terms, while marketing-friendly, obscure the fundamental nature of the activity. He proposes the more accurate and transparent term targeted active scanning. This approach, he explains, is an active communication and a scan, but it is specifically designed to mimic the well-known and expected communication patterns between engineering workstation software or diagnostic tools and OT devices, thereby avoiding the broad port and service scanning characteristic of traditional IT tools.

Arakelian’s study was meticulously designed to address the empirical void surrounding these claims. He focused specifically on PLCs due to their critical role as OT endpoints and their inherent sensitivity, making them both essential to inventory and risky to scan. The research aimed to answer several key questions: How do different OT monitoring products perform in terms of impact during targeted active scanning? Does targeted active scanning truly mimic diagnostic tools in its operational impact? And what are the real-world consequences of applying traditional active scanning methodologies to these sensitive devices? By sharing his detailed methodology, Arakelian also seeks to encourage vendors to adopt similar transparent testing procedures and share their results with the broader ICS security community.

Key Findings

▶ Watch: Study objectives: Investigating PLC scanning impact. (4:00)

Raphael Arakelian's comprehensive study unveiled several critical findings that challenge prevailing assumptions about active scanning in OT environments. The overarching discovery is that active scanning, even when "targeted," can indeed have a measurable impact on PLC performance, and this impact varies significantly based on the tool used and the specific PLC model.

One of the primary metrics investigated was scan time, which represents how frequently a PLC cycles through its program. The study observed noticeable increases in scan time across different PLCs when subjected to various scanning tools. For instance, while specific numerical increases were not detailed in the presentation, the qualitative observation of elevated scan times suggests that the processing overhead introduced by active queries can, in certain circumstances, affect the deterministic operation of a PLC. The Siemens S7-1200, in particular, exhibited concerning spikes in scan time, which Arakelian hypothesized could be due to "improper handling" on the tool's side, causing the PLC to spend extra processing time dealing with unexpected or malformed requests.

The second key parameter, memory utilization, also showed increases, indicating that active scanning consumes additional PLC resources. This is a critical observation, as excessive memory usage can lead to performance degradation or even instability in resource-constrained industrial controllers. It's important to note that memory utilization could not be tracked on the Siemens S7-1200 due to technical limitations, meaning the full extent of impact on this specific model might be underestimated based solely on scan time data.

A significant finding emerged from the comparison of different tools. The two commercial OT monitoring tools (OT Monitoring Tool A, a Tier 2 vendor, and OT Monitoring Tool B, a Tier 1 vendor, per Dale's 2023 OT detection market analysis) demonstrated varying degrees of impact. While both employ targeted active scanning, their implementation details likely contribute to different performance footprints. The study also included Nmap, configured for targeted active scanning using specific protocol scripts (e.g., Ethernet IP info, Modbus Discover, S7 info). The performance of Nmap, even in its targeted configuration, provided a valuable open-source benchmark, often showing more pronounced impacts compared to some commercial tools, further emphasizing that "targeted" does not automatically equate to "minimal impact."

Crucially, the study implicitly highlighted the severe risks of traditional active scanning on PLCs. While not explicitly detailed in its impact results in the Q&A, the initial framing of the problem underscored the historical vendor warnings against such methods. The contrast drawn between traditional and targeted scanning throughout the talk reinforces that IT-centric scanning approaches are generally unsuitable and potentially disruptive for OT devices.

Finally, Arakelian's research casts doubt on the blanket claim that targeted active scanning perfectly mimics diagnostic tools in terms of impact. While the communication patterns may be similar, the frequency, volume, or specific queries made by monitoring tools can still introduce a non-negligible load that typical engineering workstation interactions might not. The observed increases in scan time and memory utilization suggest that even "safe queries" are not entirely without consequence, necessitating careful validation and monitoring.

Technical Deep Dive

▶ Watch: Experimental setup: Network, PLCs, and monitoring. (5:00)

Raphael Arakelian's study was built upon a meticulously designed and controlled laboratory environment, ensuring repeatable and measurable results. The test setup comprised a small, isolated network facilitated by an Allen Bradley Stratix switch. This switch served as the backbone, connecting three distinct PLC models, each representing a different manufacturer and architecture, to ensure a broad representation of common industrial controllers. The selected PLCs were:

1. An Allen Bradley Compact Logix 5370
2. A Phoenix Contact PLCnext
3. A Siemens S7-1200

Each PLC was configured to run an identical program: a simulation of mixing feeds from two hypothetical tanks into a third, based on specific constraints related to tank levels and draining rates. This standardized program ensured that the baseline operational load and logic complexity were consistent across all tested devices. A critical operational parameter, the scan rate (how frequently the PLC executes its program cycle), was uniformly set to 10 milliseconds across all PLCs, providing a high-frequency, deterministic baseline against which impacts could be measured.

Two key PLC performance parameters were chosen for investigation, both recommended for monitoring by the "top 20 secure PLC coding practices":

1. Scan time: The duration of a single program execution cycle.
2. Memory utilization: The percentage of available memory being used by the PLC.

It was noted that memory utilization could not be tracked on the Siemens S7-1200, limiting the data collected for that specific model to scan time only.

To maintain a controlled environment, external communications to and from the PLCs were strictly limited. The only permitted communications during the test were with an edge gateway for data logging of the measured parameters and with an NTP source (provided by the cyber laptop) for time synchronization. This isolation ensured that any observed impacts were attributable solely to the scanning activities.

The experimental procedure involved a cyber laptop with high specifications, which hosted and executed multiple cybersecurity scanning tools. Each tool was run sequentially, taking its turn to scan a target PLC. Throughout each scan, network traffic was meticulously captured using Wireshark on both the cyber laptop and a dedicated collection laptop. The collection laptop served a dual purpose: to view the collected performance data from the PLCs and to act as a control. Before scanning any PLC, the collection laptop itself was scanned to establish a network baseline of packets for comparison.

Crucially, the study incorporated pre- and post-scan periods for each PLC and tool combination. These periods served as critical baselines, allowing Arakelian to accurately understand the impact of the scanning tool by comparing PLC performance during the scan to its stable operation before and after the active queries. To ensure statistical robustness and demonstrate repeatability, every scan by a specific tool on a particular PLC was conducted in triplicate.

The study employed a total of nine distinct tools or variations. While not all nine were explicitly named, the speaker detailed the primary categories:

1. OT Monitoring Tool A: A commercial product from a Tier 2 vendor (as per Dale's 2023 OT detection market analysis). This tool was configured for targeted active scanning.
2. OT Monitoring Tool B: Another commercial product, this time from a Tier 1 vendor in the same market analysis. This tool also utilized targeted active scanning.
3. Nmap (Targeted Active Scanning): The open-source network scanner was configured to perform targeted active scanning using specific Nmap scripts tailored to PLC protocols. These included:

• Ethernet IP info script for the Allen Bradley Compact Logix.
• Modbus Discover script for the Phoenix Contact PLCnext.
• S7 info script for the Siemens S7-1200.

The inclusion of Nmap in a targeted configuration allowed for a comparison of open-source capabilities against commercial offerings. The study's scope also explicitly included traditional active scanning, which was likely performed using other Nmap configurations or additional IT-centric vulnerability scanners as part of the broader set of nine tools, to gauge the most disruptive impact.

By combining a controlled physical environment, standardized PLC programs, precise performance metrics, and a diverse set of scanning tools, Arakelian established a robust methodology to empirically evaluate the true impact of active scanning on critical industrial controllers.

Demo / Proof of Concept

▶ Watch: PLC program details and monitored impact parameters. (6:15)

While Raphael Arakelian's presentation did not include a live demonstration or a proof of concept in the traditional sense, the entire study itself served as a comprehensive, scientific proof of concept. The detailed methodology, controlled laboratory setup, and systematic testing across various PLCs and scanning tools provided empirical evidence for the claims made. The "demo" was the rigorous collection and analysis of data from the experimental setup, which effectively demonstrated the measurable impact of active scanning on PLC performance parameters like scan time and memory utilization. The results presented from this meticulous research act as the definitive proof, illustrating how different scanning approaches affect real-world industrial controllers under controlled conditions.

Defensive Implications

▶ Watch: Overview of cybersecurity scanning tools used. (8:00)

The findings from Raphael Arakelian's study offer crucial insights and actionable recommendations for asset owners and security practitioners responsible for defending OT environments. The primary defensive implication is that while active scanning is often necessary for comprehensive asset inventories and robust security posture management, it must be approached with extreme caution and a deep understanding of its potential operational impact.

Firstly, defenders must recognize that not all "targeted active scanning" is created equal. The study demonstrated varying impacts across different vendor products and even with open-source tools like Nmap when configured for targeted scans. This means asset owners cannot blindly trust vendor assurances of "safety" without empirical validation specific to their environment and PLC models. Organizations should demand detailed impact studies from their OT monitoring vendors, ideally mirroring the rigorous methodology used in this research.

Secondly, a critical defensive measure involves proactive monitoring of PLC performance parameters. Continuously tracking metrics like scan time and memory utilization on critical PLCs can provide early warning signs of operational stress or disruption caused by active scanning. Establishing baselines for these parameters during normal operation and then observing deviations during or after scanning activities is essential. Any significant or sustained increase in scan time or memory utilization should trigger an investigation and a re-evaluation of the scanning methodology or tool configuration.

Thirdly, the study reinforces the absolute necessity of avoiding traditional active scanning methodologies on PLCs. These broad, IT-centric scans are highly likely to disrupt sensitive industrial processes and should be strictly prohibited in OT networks. Network segmentation and robust firewall rules are crucial to prevent such scans from reaching critical controllers.

Furthermore, asset owners should strive to understand the specific sensitivities and vulnerabilities of their deployed PLC models. Different PLCs, even within the same vendor family, may react differently to various protocols and queries. This necessitates a tailored approach to active scanning, where scanning profiles are optimized for specific devices. When considering new OT monitoring solutions, organizations should inquire about the vendor's testing procedures and request data on how their tools perform against the specific PLC models in the asset owner's environment.

Finally, the differentiation between Tier 1 and Tier 2 vendors (as per Dale's 2023 OT detection market analysis) implies that the maturity and robustness of scanning implementations might vary. While not explicitly detailed, defenders might consider this an additional factor when evaluating solutions, potentially favoring vendors with a proven track record of deep OT protocol understanding and extensive testing. Ultimately, defensive strategies must move beyond passive observation and embrace a calculated, evidence-based approach to active data collection, prioritizing operational continuity and safety above all else.

Key Takeaways

• Active scanning on PLCs, even when termed "targeted," can have a measurable and potentially disruptive impact on operational performance, specifically affecting scan time and memory utilization.
• The impact of active scanning varies significantly between different OT monitoring tools and even across different PLC models (e.g., Allen Bradley, Phoenix Contact, Siemens).
• Vendors' claims of "safe" active scanning require independent, empirical validation; asset owners should demand transparency and detailed impact studies.
• Traditional active scanning methods used in IT environments are generally unsafe and should be strictly avoided in OT networks due to their high potential for disruption.
• Asset owners must implement continuous monitoring of critical PLC parameters, such as scan time and memory utilization, to detect and respond to any adverse effects of active scanning.
• A data-driven, cautious approach is essential for integrating active detection into OT security strategies, prioritizing operational safety and reliability.

About the Speaker(s)

Raphael Arakelian is the speaker for "PLCs: To Scan Or Not To Scan" at the S4 conference. Further biographical details, such as his title or company affiliation, were not provided in the talk transcript or metadata bundle.