A good rule of thumb when doing remediation is that it should be as transparent as possible, so that it has a minimal impact on the business. Sometimes business or user impact is impossible to avoid. For example, implementing a much stricter password policy or disabling group accounts may have an effect on how people perform their jobs. For the most part, patches and system updates should be transparent to users. The more transparent your remediation, the fewer problems you're likely to have implementing it. As you plan your remediation process, always keep transparency in mind.
Now that you have your results and understand what needs to be done to comply with PCI DSS, it's time to prioritize your risk. With the help of your assessor, work to determine which problem can be exploited easiest and can cause the most damage. These are the ones that should be fixed first. If there are not any “gaping holes,” the conversation should turn to the items that you can address that will (1) get you some quick wins, and (2) give you the biggest bang for your compliance buck. There are many tools that can be used to help you classify risks, including the many vulnerability-aggregating Web sites. Here are some that you might find useful.
Fun Ways to Use Common Vulnerability Scoring System
The Common Vulnerability Scoring System (CVSS) is a standard for scoring vulnerabilities that has become more widely used. ASVs must use CVSS scores instead of PCI scores starting June 30, 2007 for any vulnerabilities that have a CVSS score. Most vulnerability databases will list CVSS scores, which are great in helping you to determine the impact of a vulnerability. There are some vulnerabilities that may not have a CVSS score, but NIST provides a tool to help you calculate them, which can be found at
http://nvd.nist.gov/cvss.cfm?calculator.
For example, let's say that your report shows that you don't have your credit card area physically secured. Because this is not a specific vulnerability with a specific system, there won't be a CVSS score for it, but you can use CVSS to help you determine the priority.
In this example, we'll use a physical security issue to show you how this works. While this system is mainly for computer security issues, it works pretty well for physical vulnerabilities, as well.
Jeff is the afternoon manager for Teri's Tapas To Go, a small tapas bar near midtown Manhattan. When Teri built out the location, she found certain constraints as to where electric and telecommunications wiring could be placed. Thus, she has a fax machine near the bathroom to receive faxes containing orders with cardholder data on them. Because the fax machine is not visible by Jeff (or any employee) unless she is in front of the counter, she cannot closely monitor it. Often, Teri's staff are busy with customers and are not watching the fax machine. If they are too busy, they may not hear the fax machine and therefore delay in checking for new orders. Anyone passing by the bathroom could easily grab a fax.
On the calculator page, Teri would start with the Base Scoring Metrics. This gives her a base CVSS score to work from.
Related exploit range is where an attacker would have to be to be able to exploit this vulnerability. If an attacker can compromise the system over the Internet or some other remote means, then it would be remote. In our case, with the credit card area not being physically secured properly, it would be local.
Attack complexity is how difficult the attack is to pull off once an attacker has found the vulnerable target. If the attack requires other factors to be in place for it to work, it may make it complex. In our case, we'll say that this is low complexity. Once an attacker knows where the credit card data is, it's easy for them to get to it.
The level of authentication needed is if an attacker must be authenticated to pull off an attack. This means that there is some test to verify who the user is that must be bypassed to attack the system. An example would be something like a fake badge to get access to the fax machine. In this case, an attacker would not because the fax machine is in a public area, so the level will be not required.
Confidentiality impact describes how the exploit will affect the confidentiality of data in question. In our case, if they can access cardholder data by walking into a protected area and wheeling a file cabinet with all cardholder data in it out the door, it would be complete. Normally a heavy filing cabinet is pretty safe, but since Teri has faxes coming in with cardholder data and there is little to no protection of that data once it hits the fax machine. In this case the confidentiality impact could be Partial (as in you are not getting ALL of the cardholder data), or Complete (as in you did get the complete card number). For illustration purposes, we'll choose partial.
Integrity impact describes how the attack will impact the integrity of data. In our case, it's not likely that integrity will be compromised, so we'll use none.
Availability impact describes the measure of how the availability of systems and data is affected. Because the attacker can walk off with a fax, the data is no longer available, so we'll mark that as partial.
The Impact value weighting allows you to give more weight to confidentiality, integrity, or availability. In our case, the biggest problem will be confidentiality, because the attacker just walked off with cardholder data, so we will chose Weight confidentiality. At this point if we click Update Scores, we will get a base score of 3.7.
Next we will do the temporal score metrics.
Availability of an exploit lets you to determine if an exploit is actually available or not. In our case, we'll say that a functional exploit exists since the attack would work much of the time, but there may be times when one of Teri's employees would catch somebody.
The type of fix available allows us to specify if there is currently any way to remediate the problem. We'll say that Teri has asked employees to keep an eye on the fax machine, which is a temporary fix until she finds a better home for the fax machine.
Level of verification that the vulnerability exists allows us to specify how sure we are the vulnerability is actually present in the system. In our case, we know that the vulnerability exists so we'll choose confirmed.
Finally, we arrive at the environmental score metrics section. Here we will score the kind of damage that will happen.
Organization specific potential for loss allows you to specify the physical impact the attack could have on your systems. In our case, one credit card number stolen on a fax won't bankrupt Teri, so we'll say it has low (light loss) potential for loss.
The percentage of vulnerable systems allows us to choose how many of our systems are vulnerable to this attack. In Teri's case, this is her only fax machine so we'll say all choose high (76 to 100 percent).
Now that we're done, we click the Update Scores button and get an overall score of 3.9.
There are many ways to prioritize risks – more than we could review in the scope of this book. Don't spend a huge amount of time and effort prioritizing risks, since in the end they all need to be fixed. But it's good to have a general idea.