Rating Impact, not theoretical severity, is goal of ‘Non-Intrusive and Context-Based Vulnerability Scoring’
If you’re in charge of a couple of thousand boxen, you can’t patch every vulnerability report at once, so sysadmins will welcome help sorting out their priorities.
That’s what a couple of researchers hope to offer in what they call NCVS, the Non-Intrusive and Context-Based Vulnerability Scoring framework: making sense of the risks in a complex cloud.
The idea is that because a in cloud environment – the test the paper uses is a 16-machine Hadoop cluster behind eight switches, but a real cloud is much bigger – the importance of any single vulnerability depends on its context.
A MySQL instance might, the authors note, be subject to a vulnerability that scores high on the Common Vulnerability Scoring System (CVSS).
In practice, however, it might only be launched when an event logging system needs it, and only used internally (that is, it’s not facing the Internet) – putting it lower on the patch-list than a moderate network time protocol bug in a publicly-visible router.
That’s what the EPFL (École Polytechnique Fédérale de Lausanne in Switzerland) pair, Hao Zhuang and Karl Aberer, are trying to fix: they want to add systems’ contexts to the vulnerability scoring.
That provides two things: a score that ranks a whole cloud, by taking into account the contexts of its different systems; and it helps sysadmins prioritise their patches, when confronted with a couple of dozen vulnerability reports all landing at 4PM on Friday afternoon.
NVCS is designed to automatically scan an environment (from the inside, it’s not yet-another-Shodan) without heavy instrumentation; rather, they write, it’s a “non-intrusive approach capable of collecting three types of contextual information by mining log information and network traffic”.
The system then uses something akin to a PageRank to graph the network it’s discovered, so as to score and prioritise the vulnerabilities that exist in the system.
In building their ranking, NCVS is designed to take into account hardware dependencies (what switches is a vulnerable router connected to, or what servers connect to those switches?); software dependencies (what operating system and applications are running on each node?) and network dependencies (for a given activity, what IP addresses, ports, and protocols are used?).
To put the resulting hierarchy of vulnerabilities to the test, the pair took their test Hadoop cluster and Cisco network (not stipulated, but the listed vulnerabilities were Cisco publications) with ten vulnerabilities, and treated it as if it had been compromised and taken completely offline.
The vulnerability matrix in the NCVS test environment
Their claim is that patching vulnerabilities in the order given by their NCVS score brought the system back online faster than fixing them in order of CVE severity.
As they explain:
We observe that fixing vulnerabilities according to the scores output by NCVS can recover the capability of the Hadoop cluster much faster than fixing vulnerabilities based on CVSS ranking list.
Thus, we can say NCVS can output more meaningful vulnerabilities’ scores than CVSS since NCVS takes into account the context of the target service.
That’s because NCVS tends to rate network vulns as worse than their CVSS scores might indicate; and because NCVS rates a vulnerability in a Hadoop master as more important than in a slave. ®
Sponsored: Customer Identity and Access Management