The long awaited detail of INL’s Consequence-driven, Cyber-informed Engineering (CCE) methodology is now available in the Andy Bochman / Sarah Freemen book Countering Cyber Sabotage. I had the opportunity to interview the authors for an hour in this week’s Unsolicited Response episode that you can see below.

There is a lot to like about the methodology, and you should look at and consider it, but I must admit to being disappointed that it is not primarily a consequence reduction methodology. The 2+ year promotion of this methodology had at it’s core that a highly skilled, highly resourced adversary (think nation state) will be able to gain administrative access on your ICS no matter what you do. Or to repeat one of Andy’s well-worn sayings – “If you’re a critical infrastructure provider, you will be targeted. And if you are targeted, you will be compromised.”

This mantra is saying that likelihood of a successful attack is 1 or 100%, regardless of the security controls deployed. It follows then that all effort for risk reduction should be on consequence reduction. Why would I bother deploying another security control if it is not going to reduce the likelihood of attack by an adversary?

My view is not that likelihood is 1. It is more of a Taleb approach that likelihood can be made small, but not 0, and the high consequence event is unacceptable. Hence after some basic security controls, the next thing to do often is focus on consequence reduction. (Actually the preferred approach is efficient risk reduction. Where will I get the most risk reduction for the next dollar or hour spent?)

My summary of the CCE approach is:

  1. Identify high consequence physical events that could be caused by a cyber attack
  2. Go through a very detailed, but traditional ICS cyber assessment process to understand the security posture, vulnerabilities, attack paths, etc.
  3. Finish with mitigations that could be consequence reduction, particularly non-cyber mitigations, or traditional likelihood reductions

On reflection, the consideration of both the traditional security assessment / likelihood reduction and consequence reduction makes sense for an INL methodology. They have been and will continue to do these CCE engagements for .gov organizations and the most critical privately owned critical infrastructure systems. If they only focused on half of the risk equation, the results would have been found lacking. And those organizations can afford an INL team plus their own people to work on CCE for six – twelve months.

While the 2+ year positioning and the Introduction and Chapters 1 – 4 are a bit misleading, or even contradictory, with the methodology, the name is consistent. The key here is the first C, Consequence-driven. Step 1 is to identify the high consequence events to scope and put boundaries around the rest of the work in CCE.

I believe the CCE program will be of most value to organizations that are new in their ICS security efforts and those that benefit from a CCE branded approach and documented rigor it provides. If you are well along on your ICS security program and focused mainly on security controls, then a true consequence reduction approach, like a Cyber PHA, is the way to go.

Or you can keep it very simple with a two-step, two-sentence process. 1) Identify your high consequence events that could be caused by a cyber attack. 2) Find a way to reduce the consequence if that cyber attack occurs. Examples of consequence reduction are non-cyber mitigations to prevent the consequence, faster recovery, alternate sources, putting people in the loop … You would be surprised what is available when you get the right people in the room brainstorming consequence reduction possibilities.