Security Instrumentation for Industrial Control Systems (ICS) Environments


If you are reading this blog, chances are you are already familiar with what Industrial Controls Systems (ICSs) are. If you’re not, this paragraph will serve as a very short primer. A huge number of organizations operate ICS devices. They can be found in power and energy, automated manufacturing, military, pharmaceuticals, telecommunications and so on. ICSs often provide a finite number of capabilities to control things like temperature, pressure, and flow. Because their operations are foundational in our day-to-day life, they’re frequently associated with critical infrastructure. In other words, they are totally essential as high-value targets for individuals, groups and even governments with malicious intent.


ICS security is primarily focused on availability, with a dash of integrity, when considering the “Confidentiality, Integrity and Availability (CIA) triad.”  In some cases, the ICS devices are literally there to keep the lights on, so availability should be key. As such, security practices that are commonplace in IT, such as vulnerability scanning, patching and the introduction of endpoint or network security controls, are often seen as too great a risk as it relates to availability.

Many ICS devices run operating systems that hit their end of life over a decade ago, like Windows NT 4.0, which Microsoft officially stopped supporting about 14 years ago. This means that some of these devices can’t be patched—not that they were patched anyhow—because these devices generally operate as a black box that can be altered, less the warranty becomes void. So, in addition to no patching, there is no system security hardening or the installation of security tools. To make matters worse, many of these systems aren’t designed with cybersecurity in mind, so the devices run with unneeded network services, clear text protocols, embedded passwords, unnecessary applications and the like.

Further complicating matters is that while these specific ICS devices were at one time air-gapped, that is more often not the case. And this includes devices that were never designed with the idea of possible communication with a local network or public network like the Internet. As such, many ICS devices are actually hyper-connected with a combination of legacy and modern communication channels, which include dial-up, Bluetooth, wireless, physical serial connections, serial over Ethernet, TCP/IP, Modbus, DNP3 and various other open and proprietary protocols. There are even mobile phone apps designed to help manage and monitor ICS devices.

While there are some security solutions deployed in ICS environments, historically organizations haven’t been able to validate them in production. Instead, they need to build a testbed environment that is somewhat close to the actual production environment. However, because it is only a testbed, the results are rarely empiric.

For a more detailed understanding of ICS security issues, check out the book Industrial Network Security. This book is written by Eric Knapp, the Chief Engineer for Cyber Security Solutions and Technology at Honeywell. Eric is a close friend and former co-worker who literally wrote the book on ICS security.


Organizations operating ICS devices need to validate the security controls protecting the actual ICS devices through an approach called Security Instrumentation.

Security Instrumentation is the validation of the security controls protecting these ICS devices. This approach safely validates production security controls on product networks using real attacks. Any type of simulation, simulated testbed network or simulated attack won’t accurately represent the true state of security effectiveness around the ICS devices.

With the Security Instrumentation approach, it is now possible to safely deploy sensors in production ICS environments that attack each other, not the ICS devices. This makes validation much safer than a traditional scan, assessment, penetration test, etc. and without potentially impacting availability.

By having sensors safely attack each other, it becomes possible to know empirically what’s working and what’s not in terms of the real state of security effectiveness in the ICS environment. Organizations can know what preventative controls are actually blocking real attacks, what monitoring controls are actually detecting real attacks, what networks are actually segmented, and the state of logging and alerting.

The process of having sensors safely attacking each other with real attacks in the production network can be automated. Security/operations engineers can be alerted any time the security effectiveness in the ICS environment drops from a known good state to a problem state, thus providing the rapid identification and mitigation of issues.

Instead of a dangerous penetration test—or a testbed simulation which offers results that aren’t empiric—and the laughable annual security snapshot reports (that are almost always out of date before the last line of the report is printed), leveraging Security Instrumentation does it all. What you get is a safe, effective and continuous measure of security effectiveness that, with predicated evidence and regarding security, controls blocking, detecting and alerting.

While it would be great to have more secure ICS devices (and some ICS vendors are working towards that goal) the reality is that in the foreseeable future, the urgency for strong security built around these ICS devices will arise, along with a need to validate that those security controls are doing their jobs effectively and providing value.

back to blog
Business Need