A method for gradually expanding the scope of vulnerabilities entering the change management process.
The default configuration of QualysGuard can fairly easily produce reports so large that users may recoil away from them because of the sheer volume of data these reports may contain. A multitude of levels, color codes, and categories adds confusion to what would otherwise be a large report. Incomprehension in regards to how vulnerabilities should be processed can easily turn isolated False Positive claims into a total of lack of confidence in the scanning service.
This article will introduce a method that is designed to avoid these pitfalls that is based on an evolving process which takes advantage of the gradual levels of integration of QualysGuard within an organization.
Please see the article Prioritize Vulnerabilities as per Severity Level for a discussion of the meaning of the Severity level.
The notion of these Severity levels is crucial to the methodology that will be presented here and this article will continue on the assumption that these levels are well understood.
The Gradual Approach
The key point of this method is that we will gradually change the threshold of the vulnerabilities that will be included in reports. Below is an quick overview of the gradual expansion of the scope and what will make it into a report.
Stage 1: Red 5s Only
Stage 2: Red 5s and 4s
Stage 3: Red 5s, 4s, and 3s
Stage 4: Red 5s, 4s, 3s, and Yellow 5s
Stage 5: Red 5s, 4s, 3s, and Yellow 5s, 4s
Stage 6: Red 5s, 4s, 3s, and Yellow 5s, 4s, 3s
What is important to understand is that if you have reached Level 3, if a Red 5 is found, it is addressed first. Any vulnerability in a report is subject to this pecking order: higher level vulnerabilities are processed first, regardless of ease or age.
￼There is no use delivering a 60 page report on someone's desk and expecting them to fix all the vulnerabilities in a week. Or a month. Or any reasonable length of time, that is.
Instead, focus on the truly critical findings - vulnerabilities that really must be addressed. Such as the red level 5s. This will normally drastically reduce the volume of problems that need to be addressed.
As discussed in "Prioritize Vulnerabilities as per Severity Level", these vulnerabilities will also generally have easier to deploy fixes associated with them.
Given their importance, generally speaking, it is unwise to discard these vulnerabilities as they pose a significant threat to the information system.
Aside from overwhelming administrators, sometimes there is doubt regarding the need to fix something or the accuracy of the scanning engine and it’s original finding. By limiting the scope to only the Red 5s in a first instance, both these risks can be addressed effectively.
Typically red level 5 vulnerabilities will have the full backing of the vendor. QualysGuard will not be the only tool reporting this these issues must be fixed. Furthermore, as we are restricting ourselves to red Vulnerabilities and excluding the yellow Potential Vulnerabilities, the risk of False Positives is very low.
Due to the sharp focus on the (comparatively) small number high impact vulnerabilities, the return on investment should be pretty quick to come by.
All stakeholders will quickly be able to see results, whether it be because there were only a few vulnerabilities to fix, or because each vulnerability fixed produced a (relatively) big drop in the scores.
When the reports have been empty for a while (because all the vulnerabilities have been and are being fixed), it is time to move on. The idea is to capitalize on the confidence that was built around the results and the maturity of the processes that have now had the time to become routine.
At this point the Red 4s are included.
This will dramatically bump up the number of vulnerabilities to be processed. However, as we are dealing with in principle the same sort of problem as Red 5s, this is just more of the same whilst trying to control the in-flow of the changes that need to be managed.
Not All Change Is Good For You
During the first iterations for the process, Stages 1 and 2, there was no room for debate. Given the importance of the problems being found and the damage that could potentially be done, there is very little justification for rejecting a change. At best it might be delayed, but not fixing a level 5 or 4 vulnerability is generally not an option.
When we move to Stage 3, "No" becomes an option. So the process needs to be adapted to allow for feedback from the business owner or system architect to reject a change as it wold break required functionality.
As introduced in Prioritize Vulnerabilities as per Severity Level, Severity level 3 vulnerabilities often do put the target at risk, but generally are not associated with a patch, but at best a configuration change. However, sometimes the security risk comes from a feature.
It must therefore be possible in the process to post a recommendation that a change should be made to improve the security posture of the target, unless the business owner or the architect requires the feature/function to operate in just at way.
Once the processes have been running for a while and the are no more vulnerabilities in the reports, we can further expand the reach of vulnerabilities that will be included in the security driven change management process.
During the first stages of the process we have restricted ourselves to only dealing with red confirmed vulnerabilities. The gradual lowering of the filter to go from level 5 to levels 5 though 3 served mostly to control influx of change. Restricting ourselves to confirmed vulnerabilities was designed to build confidence in the findings of the scanner engine.
The avenues for rejection of a change have gone from inexistent (Stage 1 and 2) to possible (stage 3), subject to the risk being accepted for Medium level vulnerabilities. Rejection for want of accuracy was not admitted.
Once we reach Stage 4, vulnerabilities need to be qualified by administrators as the scan port might well be incorrect. Yellow Potential Vulnerabilities are subject to a certain amount error given that QualysGuard will always avoid endangering a target. In some cases the engine needs to decide between pressing ahead and achieve full accuracy, and crashing the target, or making do with less information being less accurate, but not perturbing the target. QualysGuard will always choose the latter.
At this point of the lifecycle the basic rules still apply: fixes are scheduled based on the severity level of the vulnerability. Level 3 vulnerabilities can be rejected if required features are disabled.
However, Stage 4 requires the process to allow for qualification of a vulnerability that the vulnerability truly exists and discarding if it is a False Positive. If it is not a False Positive, it needs to be processed and a change made.
Moving to Stage 5 is very much like the move from Stage 1 to Stage 2: nothing much changes, except that more vulnerabilities are now included in the process.
Total Mastery of Scan Driven Changes
Once we reach the final stage several things should be acquired by now: a) trust in the accuracy of the scan reports, b) responsible and well thought out refusal of changes, c) manageable in-flow of changes prioritized based on an established process, and d) provable results of several months worth of the vulnerability program running.
This final stage will require the utmost professionalism by the consumers of the vulnerabilities that are now being reported by QualysGuard. Not only might the vulnerability finding be incorrect (we are now including yellow Potential Vulnerabilities level 3s) but if confirmed present, the fix may require a change that breaks required functionality.
As with Stage 3, we are now allowing for the business owners and system architects to say "No" based on compatibility issues, something that was previously reserved for confirmed red 3s only.
Ignored, Not Forgotten
This lifecycle makes no mention of the Severity level 1 or 2 vulnerabilities, whether red confirmed or yellow potential. This is due to the triage made in Prioritize Vulnerabilities as per Severity Level, where we demonstrated that severity level 1 and 2 vulnerabilities are likely to have a negative return on investment.