A failing grade
When reading CERT advisories in the ICS space I used to skim to the CVSS score as a quick way to assess what the vuln was. I rarely like what I see when I think about the actual vulnerability to which the score is applied.
CVSS, or the Common Vulnerability Scoring System, is meant to provide an abbreviated summary of a vulnerability. Chiefly, it is a means to quickly convey how serious a vulnerability is by showing both how easy a vulnerability is to exploit, as well as what the impacts of exploitation are.
There are two big problems with CVSS in the ICS space. For starters, it doesn’t tell us much about the ICS impact of a vulnerability (whether a bug can cause a loss of view or a loss of control for a control system would be nice to know). More importantly, the scores published in official advisories are often just plain wrong.
The latest example of this would be the Garrettcom Magnum switch advisory, released only a few weeks ago.
One of the discoverers, Ashish Kamble, has a good technical summary of the vulnerabilities here: https://community.qualys.com/blogs/securitylabs/2015/06/16/device-vulnerabilities-fixed-garrettcom-magnum-series .
There are a few interesting issues, chiefly surrounding how Ashish’ writeups conflict with the ICS-CERT advisory:
– The ICS-CERT advisory states that CVE-2015-3959 (hardcoded password for the ‘factory’ account) is exploitable via serial access only. If we read Ashish Kamble’s advisory above, this does not appear to be the case. Ashish gives this particular bug an access vector of “Network” while ICS-CERT once again defers to the vendor and states that it is only accessible locally. (GarrettCom says it is only locally exploitable via Serial). Who is right?
– The ICS-CERT advisory gives the hardcoded SSH private key a CVSS score of 4.3. Supposedly this is because there is a Medium ‘access complexity’ for exploitation(1). There is also supposedly no Integrity of Availability impact associated with this account(2).
– CVSS itself does not take into account control systems layout. The Access Vector requirement is limited to ‘local’, ‘adjacent network’, and ‘network’. This isn’t really a failing of CVSS (the scoring system is meant to motivate end users into better protecting vulnerable systems), but it is a common misconception in the ICS security space that CVSS scores somehow consider a typical network architecture when rating the access vector.
1 This bit makes no sense if you read the access complexity definitions in the NIST CVSS guide, which state that a ‘medium’ access complexity level means a misconfiguration or uncommon configuration is the only way to exploit the system. A hardcoded SSH private key which allows remote ‘admin’ login is not a misconfiguration on the part of the end user — the end user has no control of it all!
2 A thought exercise: assume that we log in to a managed switch with admin credentials and disable all of the ethernet ports and change the configuration of the switch itself so as not to be reachable on the network. What is the Availability impact of that? (Hint: the answer is, ‘Complete loss of availability’).
Towards a Better Way
In the ICS space, availability trumps all. But…what is availability, anyway? For a safety-critical process, a loss of view of the process (or process component) is enough to cause a big problem for most operators. For example if a mining operation loses the ability to view data from its landslide sensors, it may cease operations until the view is restored. That is a big impact. For other control system components, it is probably no big deal. For example a tank water level sensor being unreadable may not be a big deal if field workers can just as easily keep an eye on things.
Likewise for controllability of a process. Some ICS will absolutely need the ability to remotely operate equipment; others may live without any remote control over their process for short periods.
Quickly determining what, if any, view and control impact a vulnerability has on a process can let the operator more quickly decide what patches to apply or what compensating control to put into place surrounding a vulnerable component.
If I were king for a day, I would categorize vulnerabilities like this:
Loss of View: None = No impact. Partial = Ability to cause a system outage in which the operator will be aware that there *is* an outage. Complete = Ability to cause a system outage which is masked from the operator.
Loss of Control: None = No impact. Prevent = Prevent operators from controlling the components. Control = Remotely operate the component. (Note: it is possible to have LoC:PC as a score, meaning that the attacker is able to have exclusive control of the device via the vulnerability).
As with CVSS itself, these scores would not take into account the network layout. I’d love to do so, but I think that it would only help end users who were strictly following one particular security model.
Of course, someone else in the world must be thinking about ICS-specific vulnerability scoring metrics (right? someone?). Labs is beginning to highlight these impact metrics on our own reports for clients, I can only hope that we are not alone in doing so.
If such a metric is ever encoded in a version of a public Industrial Vulnerability Scoring System (IVSS), we can work on more accurately applying the scores to vulnerabilities themselves.
Image by thedavisblog