While attending a vulnerability tracking and management tool demo, I found a concept that was lurking in my mind for a long time: aging affects a vulnerability score.
I have a lot of questions, not enough neither correct answers, but I share them
But first, recall what a vulnerability is and how to score it, from the manual:
An asset vulnerability is a glitch that can be exploited by an attacker in order to act upon this asset.
That action affects information Confidentiality, Integrity and Availability
if we mind Information Security point of view.
Better yet, if we extend to Dependability it also affects Safety. That is a better angle, where does Information Security fit when a 90mph vehicle blocks its breaks? May be we can recover the information but not the people inside.
Based upon impact over CIA we can score the vulnerability. Some earlier methods were DREAD and STRIDE, the first once gone and the second used still used in risk modelling, I've been told.
- Damage – how bad would an attack be?
- Reproducibility – how easy is it to reproduce the attack?
- Exploitability – how much work is it to launch the attack?
- Affected users – how many people will be impacted?
- Discoverability – how easy is it to discover the threat?
Both methods are not fit to scientific purposes.
| Threat | Desired property |
|---|---|
| Spoofing | Authenticity |
| Tampering | Integrity |
| Repudiation | Non-repudiability |
| Information disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorization |
Take note that STRIDE considers the CIA Triad.
The current method is CVSS version 3.1 but I will use the 3.0 because I like it more, in particular another calculator from FIRST.
Now it is time to open both calculators and play with them, starting with the worst case:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
The calculator has three zones, one of them is the base, it is abstract, isolated from context and time.
What does it mean? If the score is high but you do not have an affected asset, nevertheless it remains high, as soon as you install it, you have the vulnerability. If it is fixed but you do not apply the patch, it is still high.
Environmental zone is you, not only your system but each point of it. Two assests can have the same vulnerabilty, but different security requirements or been one in the perimeter and the other protected by a firewall, score changes.
A 10 point critical vulnerability in a device facing Internet drops to 7.6 high when disconnected from the network:
CIA lies at the heart of the scoring sisytem. Play with the parameters, if CIA impact is zero, score is zero.
Hover the mouse pointer over the buttons of the calculator and you will see the definitions.
CIA requirements allows you to adjust to what value has the information in this asset to you. CIA modifiers is what the impact is in this asset, perhaps you do not have any information. Can you tell the difference between "modifiers" and "requirements"?
In this particular device, you have read only storage, Integrity is safe, score lowers. But you have an extra requirement that there can not be changes, scores raises.
Any more?
I've been noticed that there are more dimensions, not explicitely considered:
Who is affected?
It is not the same a final user that the sysadmin.
Who must fix it?
It is not the same waiting for the patch of an external product that having to produce it for your own system. Neither if the failure is exploited in the browser, out of your control that in the db, yours.
Thing about XSS vs SQLi.
Where does the report come from?
It is not "Report Confidence". If a costumer reports it, you can have reputational impact if she is not happy with your solution.
More on another post in spanish.
Time
CVSS deal with tiem in this way:
Report Confidence (RC)
Given more time, from rumor to official declaration, it raises the score.
Remediation Level (RL)
It starts with a hack, ends with a new fixed and integrated version of the software, the score gets lower.
Exploit Code Maturity (E)
From a POC to a script kiddie too, score raises again.
My fourth dimension is aging, but which one?
- from vulnerability existence
- from being present in my system
- from detection in my system
- from the discovery in my system
It is not the last one, a vulnerability tracking system must use the detection timestamp.
From this point, it is only half cooked thinking.
Does it raise the score an eleven year old vulnerability discovered now in a ten year old legacy system? There has been plenty of time to be exploited, time attenuates.
If my system is installed right now, any day makes exposition worst
Another factor is CEO Happines: How can it be that we have this vulnerability going for so long? First thing you have to do is forensic analysis in order to tell if it has been exploited.
Graphically:
Time between vulnerability existence and detection is short
system =========================================
vulnerability ===============================
report ++=============================
grows grows shrinks
The same time is longer:
system =========================================
vulnerability ===================================
report ++++++++++++++ ====================
shrinks shrinks
This grows and shrinks parametry only can be the result of a statistical analysis of what have happened in the reality, a good topic for research, do not forget to mention that you have read this post ;')
What must never happen to you:
system =============================
vulnerability =====================================
No hay comentarios:
Publicar un comentario