I agreed to speak at Jeffrey Carr’s Suits and Spooks in Boston on October 18th. The theme of this edition is Offensive Tactics Against Critical Infrastructure, and my sector to attack is electric. I’ll be showing how an adversary would compromise individual and large numbers of power plants. There are not going to be any new 0-days because the plants are insecure by design, but there will be new information on how an attacker would do this and how easy it is to have a major impact. (Note – space at the event is limited to 130, and the lineup is strong with Dan Geer and others)
This is an atypical audience to present ICS security too, and it is part of a deliberate strategy. We are increasingly avoiding the usual events and focusing more on ways to reach C-level executives and those outside the ICS security echo chamber.
Over the past ten years have seen dramatic increase in cyber security of a specific DCS or SCADA system occur in two different ways:
- A CEO/COO determines that ICS security is a top priority. In this case the security posture improves dramatically in 2 to 3 years. The security posture is at a level that most in the ICS security community believes is near impossible or doesn’t exist.
- The Operations team determines that ICS security is a top priority. In this case the security posture improves to an appropriate level in 5 to 7 years. Improving ICS security is much more of a time investment than equipment purchase, so with the right emphasis and diligence over years an Operations team can get there.
So one key is to convince CEO/COO or those that influence CEO/COO that run SCADA and DCS that they need to get serious about securing their ICS. Convince them it is in their best risk management interest to devote resources to this and measure results. Unfortunately, we are reaching few if any CEO/COO at ICSJWG, WEIScon, SANS Summits, … or on this website.
Of course it would help if those active in ICS security would stop “the soft bigotry of low expectations”. The security deficiencies from insecure by design to basic security implementation vulns are frequently bemoaned, but the same people who recognize the dire situation more often make excuses that call people or companies out to fix the real problem.
The comments on our Utilizing Demonstrated Engineering Experience article demonstrate the frustration, if not the futility, of trying to convince the majority of engineers that they are responsible for the cyber portion of a SCADA or DCS in the same way they are responsible for the equipment than performs the process. It’s often viewed as a black box that the vendor puts in and the engineers absolve themselves of any related responsibility for the robustness or security of this critical cyber component. I’m not sure how a professional engineer can do this, but I’m told as long as all or most engineers ignore the cyber portion they can’t be held professionally liable.
This issue or problem is almost enough to move me to Joe Weiss’s use of cyber incident over cyber security incident terminology.
We haven’t given up the ICS security community, but the CEO/COO and advisors are perhaps a more promising second front — or at least worth a try now that Stuxnet has at least raised the topic.
Image by Dale Peterson (Sundial Peak and Lake Blanche in the Wasatch Mountains, Utah yesterday; always looking for hiking partners on true SCADA Security Summits)