Vulnerability Assessment

Vulnerability Assessment, sometimes abbreviated to VA, is one of the fundamental activities of cybersecurity. Vulnerability assessment, is the set of activities that are performed to learn about all possible vulnerabilities in a system or entity.

What is Vulnerability Assessment

Not to be confused with Risk Assessment, as much as risk and vulnerability may seem synonymous, in technical jargon they are not at all. One definition for risk can be: “impact of uncertainty on our objectives” (a definition very similar to the one given by ISO); vulnerabilities, on the other hand, can be defined as: “weaknesses in an asset that can be used by an adversary to compromise a system.” The difference between the two is obvious, since while risk is a measure of the impact of an adverse event, vulnerability is an identified weakness. We might therefore add that without having identified vulnerabilities, it is more difficult to estimate with certainty the risks we have in our company or system.

Who then can make use of a vulnerability assessment? Not only those who are going to audit risk but anyone who wants to know with a good approximation what parts of our infrastructure are most exposed. The VA may be necessary for those who are auditing or need to comply with laws and regulations, often through remediation or mitigation activities of vulnerabilities and risk. It is therefore good practice for companies to perform a VA periodically (once a year is more than sufficient) or as a result of major changes in IT structure (e.g., purchase of new equipment, change of software provider). In the following sections, I will show you what are the basic steps that a VA conducted in good practice should have. Feel free to take these tips as a foundation on which to build, either on your own or with your team, a VA flow that is more personalized to your company.

Purpose and Preparation

As also with risk analysis, define a clear purpose for the VA. An analysis of all possible vulnerabilities on all of an enterprise’s systems would not only be costly in terms of time and resources, but would also be difficult to scale. Consider that once the VA performs, the same procedure could be repeated without substantial change in the months or years to follow. Define, then, for what reason you are performing the VA and on what machines. The key scoping nodes are:

(1) the collateral damage and expected results you are trying to mitigate-no one knows better than you what is important to your business. If you are curious about what vulnerabilities are present in your system you probably already have an idea of what could harm you and your business. Clearly define what collateral damage you feel you need to avoid, what risks you want to mitigate, and what sensitive information you do not want to have exposed.

(2) the units: define a precise set of stakeholders, actors and factors that are involved in your analysis. Highlight which ones go together and which should be considered separate. For example, if you were managing a greenhouse, you should pair sunflowers and gardeners as culnerable units, since they will often be together and the activities of one greatly influence the yields of the other. Otherwise, if, for example, one of your computers is handled only by outsiders, over whom you have limited control, you should consider the computer and the outside actor as two separate entities.

(3) vulnerability dimensions and sub-dimensions: remember that not all vulnerabilities are equal, depending on exposure, adaptability, and sensitivity, each vulnerable unit should be considered as such in a different way. For example, sunflowers are vulnerable to climate change, gardeners to pandemics; if gardeners are, in fact, able to store sunflowers in the greenhouse when needed, the sunflower/gardener unit should be considered much less vulnerable to climate change, and only remains significantly exposed to the pandemic factor. Pandemic should be considered a sub-dimension of “sensitivity” vulnerabilities since this vulnerability impacts us because of issues of sensitivity rather than adaptability (gardeners may wear masks but that does not change things if they are positive) or exposure (gardeners have an immune system that repels many attacks but it only takes one to pass).

(4) units of vulnerability measurement: you need the vulnerabilities you examine to meet some qualitative or quantitative logic so that you can clearly see whether or not the mitigations you implement have a significant impact. For example, you could use the phishing emails you receive each day as one of the metrics to measure the vulnerability of your employees. If you log 20 phishing emails per day, and implement a spam filter that blocks at least 18 of them, you will know that you have reduced your exposure by 90 percent.

Vulnerability Scanning and Classification

Once you have laid the groundwork for your VA, you can think about using automated tools to scan your systems. So-called Vulnerability Scanners (VS) are tools that can perform a vulnerability scan completely autonomously. There are many types of tools, free and paid, that can be employed depending on the system and the vulnerabilities in scope. I suggest that you always keep in mind that it is good practice to distinguish at least two types of VS: Authenticated and unauthenticated scanners. In the second case, scanning is done as if you were an actual external actor intent on accessing the system, thus without being in possession of credentials or other sensitive information that could facilitate systems penetration. If you were acting as an external actor in possession of such benefits, or as an internal actor, you would be performing a scan as an Authenticated Scanner. The reason it is very useful to make this distinction is that this way you can distinguish between vulnerabilities that can only be exploited by insiders (or after acquiring critical information) and which vulnerabilities are instead at the mercy of everyone. Depending on your VA activity and purpose, this distinction can make a big difference on how you decide to remediate vulnerabilities that emerge. Once you have done the scan and obtained the results, build a report that reflects the structure you have drawn and answers the questions posed in the first step. A good report can greatly influence the willingness of the stakeholders involved to mitigate a vulnerability; keep this in mind when deciding which tools to perform the VA with.

Remedy and Review

Once the results of the scans have been catalogued, it is time to look for a solution to the vulnerabilities encountered. Easier said than done in some cases, try to focus efforts on the vulnerabilities that have the most impact or require the most reasonable effort to mitigate. At this stage then it is especially crucial to negotiate with the stakeholders involved. If it emerges from your VA that a vendor or third party poses a high security risk, you will have a negotiation to conduct for your reasons to be considered. In these circumstances, good planning and reporting can make as much of a difference as having the right remedy to propose. Once you have implemented your solutions, you cannot fail to test that the actions you have taken have had an effect. Run the same tests again and compare the results