ICS Cybersecurity: 3 Reasons Why Periodic Technical Assessment (Still) Matters

ICS Cybersecurity: 3 Reasons Why Periodic Technical Assessment (Still) Matters

“Our SCADA communications use AES256 and are 100% secure so we don’t worry too much about security.”

That’s a real quote from a real Industrial Control System (ICS) manager from this decade. A technical assessment of that system proved otherwise—there were in fact real cybersecurity vulnerabilities that required immediate and long-term remediation.

With all the headlines and activity around cybersecurity for ICS, owners and operators of this technology are challenged to determine what they should be doing to manage their business and operational risk and ensure safety and reliability.

Whether in the form of a vulnerability assessment, a cybersecurity-informed asset inventory, thorough threat modeling, or even some carefully-orchestrated penetration testing – getting a technical-level view of how your ICS environment and components appear to an attacker (intentionally malicious or otherwise) is a foundational but often-overlooked step. For simplification here, we’ll call this concept “technical assessment”, understanding that there is difference between these various types of testing and assessment activities that we can hash out in a future discussion.

It still amazes me to see brilliantly-engineered ICS, capable of managing intricate processes that enable our modern way of life, accompanied by so little documentation or understanding of how the system interacts with the outside world – whether that outside world is a network connection or a human interface. A good technical assessment helps provide this understanding.

In a world filled with silver bullet security products and complex service offerings, we can’t lose sight of the foundational concepts. Periodic technical cybersecurity assessment is a crucial part of that foundation. In case you need convincing, here are three reasons why this matters for ICS:

1.) Understanding. Without the objective view of a technical assessment, you will never really understand your risk.

We don’t have actuarial tables or threat intelligence sufficient to predict an ICS attack so any risk discussion is fraught with subjective input. Contrast that with what you can learn from a well-executed technical assessment. Here are a few real-life examples:

  • ICS devices inadvertently directly connected to the Internet with limited security controls
  • Unknown, unidentified devices connected to the system
  • Default and easily-guessed user credentials – so many times in so many places, sometimes in a way that allows easy access from the business network
  • Completely open connections to 3rd party/supplier networks

Anyone who does this work will tell you that they routinely see these things and many more, assessment after assessment. Most of the time there was no awareness before the exercise, despite current policies, programs, or supposed understanding of risk that may have existed.

2.) Prioritization. You need a technical assessment in order to prioritize security investments.

Without the input a technical assessment provides, you could end up spending your money on people, process, or technologies that are ineffective or provide no value.

Knowing what you have (i.e., asset management augmented by a technical security assessment) is essential for making sound decisions about how to manage security for just about anything, ICS included. Too many organizations running ICS critical to their business simply do not know what they have. This is true at multiple levels - they do not have an inventory of the assets themselves or, if they do, it does not contain the most basic information about ports, services, software vulnerabilities, default credentials, and other configuration data.

3.) Validation. Technical assessment allows you to help measure the effectiveness of your cybersecurity program.

It’s easy to look good on paper. I’ve seen many organizations that do but still have significant technical gaps, creating real vulnerability, for which they have not accounted. This is true for both IT and ICS environments but especially true in ICS given the often decentralized and distributed nature. It is common for engineers and technicians to take action or introduce a change for the purpose of “making something work” not understanding the vulnerability it creates. While good change management policy should prevent this, it doesn’t always and certainly wouldn’t prevent someone with malicious intent.

Some will argue that their ICS is too fragile for any kind of technical assessment. This is problematic for so many reasons. There are almost always ways to perform technical assessment without operational interruption, even in the most sensitive of ICS. We’ll save the “how to do this” details for a later post but our team has been performing these assessments successfully for many years across a variety of different industries and ICS applications.

While many wouldn’t be quite as naïve as the ICS manager in the opening paragraph, they may fall victim to false assumptions about their level of security without a thorough assessment.

Request a Meeting


Three Reasons to Add a Discovery Phase to Your Next OT Security Assessment
Technical Assessments for ICS—Know the Risks