The problem with discussing risk on a SCADA/ICS network, especially the way that most security guidelines describe it, is that it isn’t a linear function.
In other words, the risk of A happening, B happening, and C happening is not A times B times C. That might be true with safety, but it is definitely not true for security. If A, B, and C are built of the same or similar technology it is likely that all three would be attacked. Then the overall risk goes up exponentially while the assets at risk are subject to an extreme condition. Additionally, most risk assessment methods look at the impact of just the one device, not the impact of ALL such devices.
I do not expect that someone who hacks a single device will ignore all the others with the same firmware on the rest of the network. Yet, that’s how many risk assessments are done. Worse, the outcome of A, B, and C happening all at once may be far worse than the sum of any one of the three failing. This is where safety and security mindsets diverge. In safety, one can presume the failure rate is somewhat random. In security, random coincidences are never taken at face value.
Often, people have no idea of the common software that may exist across multiple embedded platforms. Software components such as BusyBox are often embedded in many devices. Embedded device vendors are quite shy about disclosing the “software ingredients,” even when they’re obligated to do so by copyright. There is really no way that we can easily know what common software components exist in an embedded system.
For this reason, I take a very jaundiced view of the risk assessment process. If you want real security, you must design the diversity from the bottom-up, not the top down. This is also why bolt-on security fails so often. Installing a steel door on a grass hut may keep people from busting through the front door, but the rest of the structure is still at risk. If the rest of the dwelling isn’t designed for security, no one product can fix the situation.
That said, there is one good thing about Risk Assessments: They are written from a top-down approach. Top-Down documentation is ideal for first responders who probably do not know much about what they’re dealing with. With the risk assessment documents, though they are a bit disorganized for this purpose, it is at least standard and can be used to bring others full situational awareness quickly.
To give an analogous safety example: On the side of every rail tank car or tank trailer for the road, there is a diamond with three numbers on it for Health, Flammability, and Instability. The fourth quadrant has Special Hazard, such as acid, base, oxidizer, radioactive, etc. This is the first thing someone looks for following an accident. Next are the standardized Material Safety Data Sheets. Again, it’s not the whole story, but it’s a pretty good overview of what the product is and what precautions should be taken.
Following a hack, it may be dangerous to approach an operating process network. We need to have information ready for the first responders to know what things they can do right away. Indicating what networks can they isolate immediately and from where, where the actual processing takes place, which instruments and controls are critical, etc.
What worries me more are the people who attempt to “risk assess” their way toward a better design. That rarely ever works well. It ignores practicalities such as who do you send to fix a broken smart pressure gauge on the process network when it breaks at 2 AM?
Risk assessing your way toward better security is like trying to build a house by starting with the roof. It would take extraordinary expense and ingenuity to get an acceptable result.
