لخّصلي

A VULNERABILITY ASSESSMENT IS NOT A RISK ASSESSMENT
The next time you are hiring for an open-information security position, if you want to watch the candidates squirm, ask them to describe the difference between a vul- nerability assessment and a risk assessment. It may seem like splitting hairs, but this casual use of terminology is usually a symptom of information security inex- perience that leads to some very ineffective security programs. Just like running a vulnerability scan isn’t a penetration test, it isn’t fair to equate a vulnerability scan to a risk assessment. Too many organizations think that if they get a pretty report out of Qualys or Nessus scanners listing all the running services, missing patches, and possible vulnerabilities that they have performed a risk assessment. For every one vulnerability that you might discover during a security scan, there could be two or ten risks associated with that single vulnerability, and all of them may have
different risk exposure ratings. Take, for example, an organization that has no central identity and access management system, so the accounts on all 100 of their servers are managed individually. This single issue is going to have several possible consequences, including users being given too much access, being given access to the wrong resources, inconsistent access controls, or maybe just how difficult it is to properly audit. Do all these risks have the same likelihood of resulting in a data breach? Probably not, but a scanner would report the use of local account manage- ment as a single finding with a single risk rating. That just isn’t good enough.

Vulnerability Assessment
All too often, security professionals confuse the terms risk assessment and vulnerability assessment, but they really are different activities. A typical vulner- ability assessment will identify weaknesses and flaws through some kind of active means such as scanning or configuration analysis. Vulnerabilities are identified and rated based on a very general knowledge of how they might be exploited; however, no real analysis of applicability or threat analysis is included. In addition, a vulnerability assessment assumes a single finding per vulnerability, but in reality, there could be several combinations of different threats with a single vulnerability that will result in several distinct risks. This level of detail isn’t captured in a vulnerability assessment.
Vulnerability assessments are good tools to be used as part of an overall risk assessment process. They can produce good metrics to measure the effectiveness of current control measures like patch management processes or hardening of servers. They are also useful if you need to identify resources that are susceptible to a particular exploit or running a prohibited service. Attackers typically use vulnerability scans as part of their reconnaissance, so it is good to run the same tests yourself to identify which weaknesses would be visible to an attacker.
Risk Assessment
In general, a technical risk assessment is going to include a vulnerability assess- ment of some kind; however, there is much more to a risk assessment than just identifying weaknesses. If you just want a list of things to fix, do a vulnerability assessment, but if you really want to understand your exposures and prioritize remediation efforts, then you need a risk assessment.
A risk assessment is the superset of activities for taking that vulnerability data, mapping it to likely threats, evaluating the severity for the given environment, and articulating the risk(s) that might result. A risk assessment should also take into account the sensitivity level of the resource that has the vulnerability, whereas a typical vulnerability assessment would assume the same risk level no matter where it is found. If Microsoft announces a new vulnerability in Windows, they don’t list it as a high risk for servers and moderate risk for desktops. Similarly, any scanning or assessment tool may provide some guidance about the applicabilityof a vulnerability, but you are going to get a very one-dimensional risk score from a vulnerability assessment. For example, Figure 3.2 shows a typical vulnerability finding from a scan of a Web server, using the QualysGuard vulnerability scanning tool. The impact statement describes two potential threat activities, unauthorized reading of communications and intentional modification of messages in transit. This would be included in a vulnerability report as a single item, but even without analyzing this weakness any further, it is clear that there are at least two possible risks associated with it. One threatening the confidentiality of the data and other affecting the integrity.
Further, a comprehensive risk assessment needs to account for any compensat- ing controls that already exist. These controls may not neutralize the vulnerability, but they reduce the inherent risk in some way. In the case of the Web server sup- porting weak SSL ciphers, a compensating control might be that the Web server is only ever accessed over a secure VPN connection, thus not relying on the SSL encryption to protect the communications.
By the end of the risk assessment stage, the risk exposure should be deter- mined for each threat/vulnerability pair. The combination of the likelihood that the threat will exploit the vulnerability, and the severity of the exploit, combined with the sensitivity of the asset itself yields the risk exposure rating. The risk exposure describes the outcome of a successful exploitation of the vulnerability by the threat. Sometimes the risk exposure is referred to as the “impact” or “consequence” of the risk, and it should always be tied to a particular threat/ vulnerability pair.Notice that this description helps us rate the severity of the exploit by indicat- ing how much data (all client data from the United Kingdom) will be affected, and the sensitivity by the scope of which data will be disclosed (sensitive, regu- lated customer data). It also indicates that a notification to clients will be required which affects reputation, costs money, and could expose the organization to civil legal action. A dollar value of financial loss is also stated in order to quantify the impact to the organization.
When articulating a risk, it is not enough to just describe the lack of a control and call it a risk. For example, you may see someone with no formal risk assess- ment training describe the risk in the previous example as “TLS/SSLv3 is not required for all communications.” The lack of strong encryption is not a risk; in fact, there may be plenty of other ways to protect information from disclosure in transit. We need to be careful not to assume the solution when describing the risk. It is a common tendency to have the control in mind when you are assessing a risk, but this will often be too prescriptive. In our earlier example, SSLv2 may be required by the business to support a specific set of clients with older browsers. Especially, as an auditor or outside consultant, you should avoid locking the client into one solution to address a risk and rather focus on the root cause or intent of the finding.