Three topics for this week’s article: Importance, Risk Management, and Level 0 Risk Reduction.
Importance
Joe Weiss, who I call the Paul Revere of ICS security for his yeoman’s work raising the alarm in the 2000 – 2010 decade, was not a fan of my article last week and past communications on Level 0 and risk reduction. He led off his LinkedIn post with:
The OT network community cares about data; the engineering community cares about deaths Dale Peterson has written and held podcasts on the lack of importance of Level 0,1 devices.
There is no dispute that Level 0 is important to monitoring and controlling a physical system. It’s required unless things are manually controlled with lever’s, switches, and knobs. You can’t turn things on/off, make them spin faster/slower, or raise or lower a temperature without Level 0. It’s also near impossible to monitor a large physical process without the sensors at Level 0.
There are sensors and actuators that are more “important” than others at Level 0. Some control is fine tuning, some sensors provide nice to have, not required, data. Understanding the “importance” of a particular Level 0 sensor or actuator could play a part in understanding the consequence side of the risk equation.
Additionally, there is no dispute in the ICS security community, and likely in much of the engineering community, that almost all Level 0 devices lack source or data authentication. They are in the “insecure by design” category. Send them a legitimate, properly formatted command, and they will do what they are told regardless of who or what sends it.
Summary: There is no dispute in the ICS security community that Level 0 is “important”, essential in fact, to monitor and control a physical system. There is no dispute in the ICS security community that almost all of Level 0 lacks even basic security.
Risk Management
ICS security professionals, engineers and others should focus and make decisions based on a risk management criteria. This is critically important given the potential high consequence events and the current security posture of most ICS. Every possible expenditure of time or money to reduce risk should be evaluated on how it reduces the risk to human safety, financial loss, customer/community impact, environmental impact and reputation.
We are not in a competition to see who can deploy the most good practice security controls. Cyber hygiene, that typically focuses on universal security patching, is a lot of work for minimal risk reduction for 90%+ of the ICS cyber assets. In last week’s article I made the case that deploying a second Level 0/1 comms monitoring network is also highly inefficient risk reduction. Both are not wrong, just not where you would put resources if you are trying to maximize risk reduction for an expenditure of resources.
Last November I wrote a two-part article: ICS Security Maturity Model (What To Do In What Order) Part 1, Part 2. It’s my analysis of the path where most asset owners will maximize the risk reduction for resources spent. My list is below, and I’m sure some will differ. The key is you should be looking at the issue from a risk standpoint, including both likelihood and consequence reduction.
- Establish A Security Perimeter
- Harden The Attack Paths (allowed paths through the security perimeter)
- Setting And Meeting A Recovery Time Objective (RTO), Phase I
- Basic Detection
- Eliminating High Consequence Events
- Incident Response
Summary: The evaluation criteria for selecting ICS security related projects should be the risk reduction achieved, either likelihood or consequence reduction, for the time and money spent. These security projects should also consider if consequence reduction efforts would lead to more efficient risk reduction.
Risk Reduction Achieved With Level 0 Security and Level 0/1 Communication Monitoring
Secondary Monitoring Network for Level 0/1 Communications
If the scenario is someone hacking the PLC/Level 1 to provide false sensor data to the ICS, then the much more efficient risk reduction is to secure these Level 1 devices. Securing Level 1 has been my push since Project Basecamp in 2012. Signed firmware, secure boot, and authentication of source and data for all comms Level 1 and up. Would I like to see this on Level 0 as well. Yes, starting with Level 0 that has an IP address. It’s just that the risk reduction by securing one PLC is huge in comparison to securing one Level 0 device.
The good news is there are now PLC’s and controllers with the required security. I would have put upgrading the Level 1 devices as item 7, 8 or 9 in the list above for legacy systems, before widespread security patching in ICS zones. I would put secure Level 1 devices as part of all new ICS deployments.
If an attacker is physically down at the Level 0/1 communication and sending false information to the Level 1 device, and that information is subsequently used by the rest of the ICS, then why couldn’t the attacker just send the false data to the second monitoring network? They just replace the legit sensor with their own sensor feed. Jason Larsen showed this in his infamous Triangles session at S4x14. Now you could say this is why all sensors and actuators should have source and data authentication to make it more difficult to send false data from Level 0. I’d agree, but monitoring Level 0/1 communication doesn’t necessarily stop spoofing comms. The attacker just needs to be on the Level 0 side of the ICS and secondary monitoring network.
The cost of deploying and maintaining a secondary monitoring network is much larger than other risk reduction options. A colleague pointed out the configuration for the analytic engine to compare the value in the ICS to the value in the secondary monitoring network is also not a small effort. Asset owners are “challenged to manage this kind of configuration between L2 and L3 or L4. In short, manageability is non-trivial at scale. Anything more than monitoring the most critical sensors for hazardous process is probably unsustainable.” There are much more efficient and effective risk reduction options for most ICS than a secondary monitoring network for Level 0/1 communications.
Level 0 Security
Why not prioritize securing Level 0? At a minimum adding source and data authentication to all communications to Level 0? Again, this is the right thing to do, but it’s far down the risk reduction priority list for most ICS for the following reasons:
- It’s hard for an attacker to reach Level 0 with a cyber attack. Most of the cyber attacks are coming from the corporate network into Level 2, through Level 1 and then to Level 0 (unless they just run a denial of service attack somewhere upstream). As Level 0 is deployed with IP addresses, this may be less true and should be considered in design particularly with the following point in mind.
- If Level 1 is secured, it can be used as a security gateway to limit access and authenticate the source and data of all communication before this communication is sent to Level 0. This is a far more efficient solution than adding security at Level 0 (again the right thing to do at some point).
- Authentication at Level 0 isn’t possible until the device communicating with Level 0, typically the Level 1 device, is secured. Something needs to digitally sign the hash that Level 0 would verify. And vice versa.
- If the attacker has physical access to Level 0 or to the Level 0/1 communications, a physical attack is, in most cases, going to be much easier than a cyber attack. Flip a switch, smash something, unplug a cable, etc.
————
As a final note, I’d like to encourage vigorous debate on any set of risk reduction recommendations. What is the suggested security control that will reduce likelihood? What is the suggested action that will reduce consequence? What will it cost relative to other options? What is your reasoning and assumptions behind your risk reduction claims. These are important discussions, and we need more voices with different backgrounds involved.
I hope we can move away from saying a whole group of people doesn’t care about human life. I hope we can move away from statements saying a whole profession shouldn’t be involved in helping solve this important problem. There are only a tiny number, maybe zero, people who have all of the knowledge required to find the best way to solve this problem. Engineers, ICS security pro’s, CISO’s, finance, risk management and others (even regulators) working together will get us to where we need to go.