How can your database be in two places at once when it ain’t anywhere at all?
In Fridays’ edition of DigitalBond’s blog, databases are mentioned.
“Dueling Incident Databases. Joe Weiss has his personal incident database. Wurldtech recently announced their new Delphi vulnerability database. Now Automation World reports that Eric Byres will be resurrecting the BCIT Industrial Security Incident Database thanks to some new funding source.”
I will not go into the issues of why there are multiple databases or how best to pool resources. However, I will provide my thoughts on the need for incident databases.
- I strongly believe one of the biggest reasons why so little is being done to secure industrial control systems is the lack of perceived need since there are so few cases that have been reported (Australia and Davis-Besse).
Consequently, control system cyber security is treated as the second coming of Y2K – nothing happened, it was simply a ruse for consultants and vendors to make money.
There needs to be a business case and the only way I know of making a business case is to show that it is real and has had significant economic impact.
- I strongly believe most people still view cyber security in the traditional IT form- “the 12-year old pimply-faced hacker concocting new Microsoft viruses or worms.”
Control system cyber incidents are much more prevalent that many believe and most are unintentional. They are simply not recognized as cyber incidents. There needs to be a better definition of “cyber” that reflects what can happen to control systems.
- Existing IT databases and reporting do not address control systems.
Consequently, several years ago, DOE tasked CERT/CC and KEMA (myself and Bob Webb) to perform a scoping study for establishing a CERT for Control Systems.
It was recognized that private industry would not provide input to the government and consequently, it was strongly recommended that a CERT/CC, not US CERT be augmented with control system expertise.
This was not followed and consequently there is very little reporting of control system incidents.
- I strongly believe you can’t develop solutions if you don’t know the problems you are trying to solve.
Since there are so few publicly identified cases, most “solutions” for control systems are based on IT problems, not control systems. Specifically, they do not address legacy/field devices.
In fact, many of the solutions being touted as fixes can, and have, actually exacerbated control system reliability. Additionally, you can’t have “best practices” when you don’t know the problems you are trying to prevent.
- Following 9/11, there was a march to “connect the dots”. That is, with all of the disparate information, why couldn’t we tell what was going to happen.
Without an incident database and experts to review the incidents, it is not possible to determine if there are patterns occurring.
It became evident to me as Marshall Abrams of MITRE and I worked on the Bellingham pipe break that there were other control system cyber incidents of a similar nature.
Additionally, when I was at a process control systems users group meeting last week, I mentioned the Browns Ferry broadcast storm. That brought a reply from one of the attendees that he had a similar that resulted in a local blackout. I believe there are underlying patterns but they have not been adequately researched.
- The risk equation is frequency times consequence. Today, it is not possible to prudently assign values to either. An incident database can help.