2. Dale Peterson - ICS Security Architecture

Learning Goal: To understand the key network architecture decisions that affect cyber risk.

Dale Peterson (that’s me) provides the second lecture with 45 minutes on ICS Security Architecture. Along with Marty’s: Know Your ICS lecture, this provides the basics so we are all on the same page moving forward. It is aimed at the engineer or operations professional new to cybersecurity. That said, I think there are a few gems in the specific stories even if you know all about security perimeters, remotes access and other basics.

Questions to consider and comment on:

1) What are some examples of common ICS communication you would not want to allow through your Enterprise / ICS security perimeter? And what would you do if your ICS application requires a large number of ports allowed through the security perimeter?

2) How many DMZ’s should you have for your Enterprise / ICS security perimeter, and what is the purpose for each DMZ?

3) What remote access to you allow to your ICS? How many people from what organizations? How often?

4) If you say the security perimeter between the enterprise/corporate network and the ICS is your first or primary security perimeter, where would you put your second security perimeter?

Strategic Pull Quote: “We are not in this game to see who can deploy and maintain the most security controls, our goal is to manage risk to a level appropriate to the company.”

KEY QUESTION: Are there security controls you have in place today or see widely recommended that have lead to little or no reduction in cyber risk

Here are some questions and answers we received previously on this video:

QUESTION: What is your preference for segregation between IT/OT: deploying uni-directional gateways or 2 adjacent firewalls (barbican) approach? And why (considering budget is not a constraint)?

Use of One-Way Technology

1. A key determinant of the best security perimeter architecture and product-type is based on what you will allow through the security perimeter. In fact, limiting or eliminating inbound connections are much more important than what product is selected to enforce this.

2. There are certain places where one-way is the clear answer. First, is it something that can support one way? If it requires two-way communication, then my view is that having two one-way devices (one for each direction) is not worth doing from an efficient risk reduction perspective. Yes, it does mean that a single TCP connection cannot be used for control of the process, so there is some risk reduction. Just not enough imo, to spend the money and add the complexity. Again this is a judgment call. The one-way vendors, such as Waterfall and Owl, would disagree. Given the almost inexorable increase in two-way communications to ICS coming in most sectors for valid and high value business reasons, the one-way everywhere appears to be a losing battle to fight.

3. Great places for one-way technology include cases where historical data needs to be sent to the enterprise or cloud. We are seeing a lot of predictive maintenance in the cloud offerings, and one-way reduces the risk of this to the confidentiality of the data. The integrity and availability of the ICS is not a risk. Another great example is a one-way device between the safety system and control system. If the asset owner in TRISIS had this, the attacker would not have been able to get to the safety controller from the DCS. The safety system can send data to the DCS, but the DCS cannot access the safety system. I’ve also seen one-way used to send screen captures to the enterprise for remote support, and a variety of other purposes.

QUESTION: How do we tackle patch management considering we need to fetch patches from a live update server in the Enterprise network (level 4) while opting for the uni directional gateway? We will require a gateway in both directions won’t we?

Getting Info In and Out of an ICS

This recommendation is less controversial. Most will have an update server in an ICS DMZ (some label this as Level 2.5 or 3.5 in the Purdue model. This update server will pull (initiate the TCP session) the updates from the enterprise network. Ideally an update server in the ICS, probably on Level 2, will pull the updates from the update server in an ICS DMZ. For smaller installations some asset owners will have the ICS computers pull the updates directly from the update server in the ICS DMZ.

Another thing to consider as your ICS security program becomes more mature is whether this update path can only be open when needed. Even though the above method does not allow any inbound connections and would be least privilege, it still is an attack path. If it is only needed once a month or for 5 minutes a day, for example to get anti-virus signatures or to get the schedule / recipe information, you could have a mechanism to only open this for that short period of time.

The nice thing is automation professionals are very good at setting up something that open and closes a connection, so they often build this in house. Or you can buy it. Not something you would do at the start of your program, but always be thinking efficient risk reduction. Where will I get my maximum risk reduction for the next dollar or hour spent?

QUESTION: Do you recommend the use of NAT/PAT in the barbican deployment? Do you think NAT/PAT configuration on the Enterprise firewall to mask the IP/port entries on the ICS firewall is an overkill? Should we make do with a transparent setup with limited UTM features for inspection instead?

This is a not applicable question. Your ICS devices and addresses should never reach the enterprise firewall. They should not go past your ICS DMZ. And your ICS DMZ should never reach out to the Internet. Your ICS firewall ruleset should not allow this. I could go down the rabbithole of DNS tunneling and stopping DNS queries from the ICS zone (search on the S4 Events YouTube channel for detail), but this gets very technical.

Remote Access

The bane to ICS security for at least the last five years, and a much talked about item in a COVID-19 world. Think about how the attackers are getting in. Spearphishing to gain access to the enterprise, compromise someone with administrative remote access to the ICS zone, use their credentials for anytime access. It represents 80%+ (made up stat but probably correct) of the known attacks in ICS. So let’s dive into this a bit with some concrete lessons learned / guidance:

  • All remote access, including from the enterprise, to ICS needs to require two-factor authentication. I’ve been hugely disappointed that DHS and other industry groups have not used their big megaphones to say this is a must. That you are negligent if you are not doing this.
  • Eliminate all unnecessary remote access. Much of the ICS remote access is for convenience. And some of the remote access needs can be solved by other means. For example you can send screen shares through one-way devices so that engineers, administrators, vendors can support the site without access to the ICS site.
  • Eliminate always on remote access when possible (perhaps less possible during COVID-19). Many organizations are moving to an open circuit so remote access is impossible except when the ICS requires the support. A process is put around the connecting and allowing remote access. There are products that can do this, or you can roll your own. The key is to have a timeout or planned check during rounds so that the remote access isn’t left in the always on state.
  • Consider providing highly privileged users with a second account for remote access, particularly in COVID-19 times when remote access is their norm. The remote access account could be in a different, and possibly specially created, role with fewer privileges than they had on site. I don’t see much of a distinction between cloud based or enterprise based remote access. Whoever can execute better is a fine choice.

One last thought, I’m eagerly awaiting DPI for external access rather than an all or nothing choice. This will become more important as valuable cloud services are available. For example, what if I want by boiler vendor to monitor and adjust certain settings to reduce maintenance and for more efficient operation. The risk would be a lot less if I could restrict them to certain function codes and certain points/tags/coils/registered and in a certain range. As an asset owner I could then say the maximum impact of a compromise of the cloud service provider is x.