Data Security, APT Activity, and Inherited Risk for ICS

By Jason Holcomb Director, Industrial Control Systems Security

Data Security, APT Activity, and Inherited Risk for ICS

In traditional IT security, there is heavy focus on data — data security, data breaches, data loss. It has often been said “it’s all about the data.” This generally isn’t the case for Industrial Control Systems (ICS). There are a few exceptions, but you will often hear discussion about the C-I-A triad for ICS where ‘C” (confidentiality) takes a lower priority position behind Availability and Integrity. I’d like to challenge this notion, not from the angle of data within the ICS, but from the perspective of data about your ICS stored in business network environments.

If I’m an adversary, how much can I learn about your ICS from documentation intentionally or unintentionally available on your business networks? In my experience, the answer is a great deal across many organizations and industries.

Last week’s US-CERT TA17-293A alert highlights “Advanced Persistent Threat Activity Targeting Energy and Other Critical Infrastructure Sectors.” Some quickly noted that the alert was not clear on the impact to ICS and whether it was specifically targeting ICS despite some of the language indicating that. There is an important discussion to be had there but regardless of whether the actor was targeting ICS or acting opportunistically, there are key points related to data security to consider:

1.) In the reconnaissance phase for one victim, information about ICS equipment was publicly available:

“…the threat actors downloaded a small photo from a publically (sic) accessible human resources page. The image, when expanded, was a high-resolution photo that displayed control systems equipment models and status information in the background.”

While it probably did not provide the proverbial keys to the kingdom, we’ve learned from cyber attacks outside of ICS that every morsel of information matters in piecing together a successful attack. This is definitely something that ICS security programs should be monitoring – from extranets, job postings, vendor press releases, LinkedIn, and other forums.

2.) Once on the business network, the attackers were able to view files about the ICS:

“The threat actors viewed files pertaining to ICS or Supervisory Control and Data Acquisition (SCADA) systems. Based on DHS analysis of existing compromises, these files were originally named containing ICS vendor names and ICS reference documents pertaining to the organization (e.g., “SCADA WIRING DIAGRAM.pdf” or “SCADA PANEL LAYOUTS.xlsx”).”

This is where I would like to focus the discussion and challenge the “data doesn’t matter” notion. Many organizations are still struggling to understand the inherited risk between disparate networks and systems such as ICS, business environments, and increasingly other connected systems from the Internet of Things (IoT). Data security negatively affects that inherited risk when your business environment becomes the wiki for an adversary planning the next phase of their attack. This and many other factors compel us to look at ICS security outside of just the plant floor, substation, or remote point. We must consider the ecosystem that all these things live within because it all contributes to the risk.

The US-CERT Alert covers detection and prevention mechanisms specific to the relevant threat as well as general best practices. Here are a few recommendations for beginning to address the issues related to data security for ICS not covered in the Alert:

  1. Build a process to routinely assess what data is available about your sensitive control system environments from both the Internet and corporate intranets, file shares, etc.
  2. Provide a process and secure mechanism for control system engineers to share and exchange data. While there is no perfect solution here, whatever you do should be built with an understanding that it could be the engineers that are targeted by spear phishing and that their credentials may be harvested. Any solution should be able to clearly articulate the attack cases it is trying to protect against because in my experience, a targeted engineer is usually not adequately accounted for… much more that could be discussed here that we will save for a future post.
  3. Add ICS data targets/objectives to your next corporate penetration test.

Don’t fall into the “ICS data doesn’t matter” trap. Taking these steps will help prevent your business network from providing the blueprint for attacking your ICS.


About the Author

Jason Holcomb
Director, Industrial Control Systems Security
Revolutionary Security

Jason leads Revolutionary Security’s Industrial Control Systems (ICS) practice. He has been actively involved in helping secure SCADA, DCS, and other Operations Technology (OT) for over 15 years with experience spanning the utility, oil and gas, chemical, and manufacturing industries.

Share this post