DHS‘ new semantic approach to risk mitigation

Marty Edwards, acting director of ICS-CERT, stunned me today at WeissCon when he explained the policy behind how ICS-CERT issues security advisories and alerts. Marty introduced a fresh approach to looking at vulnerabilities by excluding anything that appears not to be a bug (software defect) that can be fixed by the vendor. In other words, you won’t see any advisory or alert on “features” that can be exploited. This radically cuts the amount of vulnerabilities in the ICS space by roughly 90%, since the vast majority of security “issues” we have (I try not to call them vulnerabilities) are not bugs, but design flaws. So today everybody has gotten much more secure because so many vulnerabilities just disappeared.  And we don’t even need to continue the silly discussion on irresponsible vulnerability disclosure any longer since it’s not vulnerabilities what the usual suspects would disclose in the first place. Brave new world.

Before Marty’s new world order, vulnerabilities used to be something different. Here’s what DHS used to call a vulnerability before all that trouble with Stuxnet and Beresford:

“A flaw or weakness in a system’s design, implementation, or operation and management that could be exploited to violate the system’s security policy.“ (Catalog of control systems security: Recommendations for standards developers, page 129)  

Until today, ICS security was difficult. Now it’s easy. For ICS-CERT. For the rest of us, it remains difficult, because your process doesn’t care if it was a bug or a feature that had been exploited.

Ralph Langner