Risk and PCI-DSS

December 17, 2008

I recently had lunch with a friend and we spent a lot of time talking about PCI. I am heavily involved in some PCI-related activities at work that has resulted in me knowing more about PCI then I would care to. I wanted to document some of the subject matter we discussed especially with regard to: how to approach a PCI compliance assessment project, states of compliance, and articulating risk related to requirement gaps.

So where to begin? Well, you can start by going to the PCI Standards Council website – there is a load of information there. You can find out:

1.    The merchant level of your business based on the number of card transactions your company performs.
2.    The kind of validation actions you are required to take.
3.    How your “validation actions” need to be validated.

One point I would like to throw out there for companies with numerous subsidiaries is you need to work with your QSA to determine if the subsidiaries that are under your company umbrella are separate from a compliance perspective or if they are under the compliance status of the parent company. Not understanding this early in the process could result in a lot of wasted time.

Another point on this topic is that one needs to understand the flow of PAN through your environment. Visually (and accurately) representing this very early in the process will reduce assumptions and be of great benefit through the assessment lifecycle.

In general, PCI Compliance seems to be very binary – you are either compliant or not; the severity of one’s non-compliance is where the grey is. Non-compliance can result in fines, increased transaction fees, and whatever other penalties exist. I will end this thought with stating that not all QSAs are created equal nor are all payment processors created equal. On the PCI Council website – they advise people to choose QSAs that know your industry – that is great advice. Some payment processors will recommend QSAs for you. Do your homework and make sure it is a QSA you are comfortable with.

Let’s talk risk and PCI. I think of PCI risk different then some folks. I separate the risk of being non-compliant from the risk of the gaps themselves. Let me explain.

Risk associated with just being non-compliant (no incident has occurred): Merchants can be fined for not being compliant. In this type of scenario – the merchant’s payment processor could levy the fine. As a matter of fact, the card associations can fine the payment processor who can then fine the merchant. Fine amounts can vary and there is no guarantee that you will be fined for being out of compliance. Also, it would appear that fines for this type of non-compliance are independent of the number of requirement gaps. So whether a merchant has one requirement gap or dozens – the fine is for being non-compliant. If an organization is not compliant – the expected annualized loss magnitude for not being complaint would be the expected monthly fine amount multiplied by 12.

Risk associated with being non-complaint; an incident has occurred. This is where the pucker factor starts. This is a situation where a merchant has suffered a breach and is non-compliant or possibly even compliant. There are numerous resources out there about the fines that can be levied against the merchants by the card associations, payment processor fines / increases transaction charges, card replacement costs, reputation costs and much, much more. This is a worst case loss scenario from a risk perspective. For large merchants, I would think that monetary impact would easily be hundreds of thousands of dollars to a couple million dollars; more depending on the size of the breach. TJX is a good *worst* worst case benchmark.

Risk associated with the gaps themselves. When it comes to assessing the gaps – or risk issues – I prefer to assess them independent of the compliance status. Even though a single risk issue can result in a state of non-compliance which has its own risk (fine) amounts – what good is it for the risk issue itself to assume the risk amount of not being compliant in cases where you have multiple gaps? So, I prefer to think of them independently. This allows for better mitigation prioritization, cost benefit analysis, and being more objective in how you articulate the risk to the decision makers.

If you think about what I have written you can easily imagine a situation where a merchant could justify remaining out of compliance because the cost of not being compliant (in absence of a breach) is cheaper then becoming compliant. For some companies that may be a viable option (though few would probably ever admit that is their approach), but most companies want to be compliant, want to show due care to their customers / consumers, and do not want to take the chance on a breach and the reputation impact that comes with that.

Finally, for most companies – achieving compliance cannot happen with one stroke of the magic wand. There may be a period of time between gap identification and mitigation, which means the company, needs to manage that risk accordingly. I hope some of my thoughts above might help with that (combined with your legal council input, leadership input, your QSA, etc.)

Now, if the PCI Security Standards Council would take more of a risk based approach in determining level of compliancy and magnitude of fines – that would be pretty cool. And no, using CVSS scores to tag technical vulnerabilities is not really a risk based approach.

** Late addition to the post ** – My next post will be about a positive PCI QSA experience I recently had.


Risk and CVSS (Post 5) *FINAL*

September 4, 2008

I had no idea that the CVSS topic would turn into a five post series. There was just too much information and thoughts to cram into one or even two posts so for those of you that read even a few let alone all five – thanks for persevering.

Final thoughts on CVSS; two good and two not so good:

NOT SO GOOD:

1.    The CVSS framework is probably not being *fully embraced* or properly utilized by the people that need to leverage it the most – consumers of vendors that use it to score vulnerabilities with their products. Scoring the environmental metrics and observing the impact to the base metrics could add a lot of value. Other frameworks or organizations that reference CVSS scores as part of a vulnerability management process should mention the optional metrics that can influence the base score that a vendor provides. Better yet, maybe throw a disclaimer that the CVSS score listed today may be outdated and needs to be updated.

2.    The CVSS risk vernacular needs to be updated. I would recommend that the CVSS-SOG consider participating in “The Open Group” “Risk Management and Analysis Taxonomy” forum. Better yet, the CVSS-SOG should consider adopting the FAIR methodology. Specifically, use CVSS metrics that could factor into FAIR taxonomy elements. Some of the CVSS metrics focus more on impact then on the vulnerability itself. This can be a slippery slope especially when there are no metrics for “threat event frequency” let alone “loss event frequency”.

GOOD

1.    Pretty much all the CVSS metrics have some usefulness and should be able to be used by most information security professionals and especially risk analysts. I am already creating a small utility to use so I can consistently analyze various vulnerabilities and when appropriate – use the metrics as contributing factors for FAIR.

2.    Industry adoption. A lot of vendors use the CVSS framework. PCI-DSS references it for vulnerability related PCI guidelines. Just remember, use the whole framework and do not rely upon what is spoon-fed to you by PCI QSAs or value added resellers. If applicable, take back your ability to analyze risk and make informed decisions.

There you have it. Again, thanks for reading and submitting comments. The feedback and scrutiny has been well taken and appreciated.


Risk and CVSS (Post 4)

September 3, 2008

We are now up to the CVSS “Environmental Metrics” group. According to the CVSS documentation, this group ‘captures the characteristics of a vulnerability that are associated with a user’s environment’. This group is also optional from a scoring perspective and is intended to be completed by someone familiar with the environment the vulnerability resides within.

In “Post 1” I mentioned that CVSS does not take into consideration “threat event frequency” or how often I expect to get attacked nor does it take into consideration “loss event frequency”; how often I expect to realize a loss. The “environmental metric” does not fill this void either – but there is still value in being able to quickly analyze vulnerability in the context of these metrics – again, as contributing factors to various FAIR risk taxonomy elements.

FAIR & CVSS "Environmental Metrics) Mapping

FAIR & CVSS

Collateral Damage Potential. This metric measures the potential for loss of life or physical assets through damage or theft of property. Now real quick, I scoffed when I saw the loss of life – and none of the risk issues I have ever dealt with ever involved estimating loss of life. However, there are real life examples of software defects (essentially vulnerabilities) that have loss of human life implications. Take a look at “Geekonomics” by David Rice, there is some fascinating information in the book that will give you a whole new perspective on vulnerabilities. Getting back on track, the collateral damage metric maps very well to the “probable loss magnitude (PLM)” branch of the FAIR taxonomy. I do not want to dive into PLM right now – but let me state this – the word potential is not the same as probable, nor does it imply expected loss. So with the CVSS metric it could be very easy for someone to err on the side of a worst case loss versus choosing a value that best resembles expected loss. Either way, with CVSS this would just result in the CVSS score being raised. I would prefer to see a value in terms of dollars; whether it is monetary ranges or actual expected loss amounts based off simulations.

Target Distribution. This metric measures the proportion of vulnerable systems. I like this metric and I think it can be very useful as a contributing factor to the FAIR taxonomy element “threat event frequency”; specifically “threat contact” and possibly “threat capability”. The number and placement of vulnerable systems in my environment could directly factor into how often or what type if threat agents I expect to come into contact with the vulnerable systems – let alone attack them. Remember, within FAIR – attacking an asset with a vulnerability does not guarantee loss. We have to take into consideration the ability of the attacker to overcome the control resistance applied to the asset.

Security Requirements. These metrics enable the analyst to customize the CVSS score based on the importance of the affected IT asset to a user’s organization in terms of confidentiality (CR), integrity (IR), and availability (AR). Possible values include: LOW, MEDIUM, HIGH, or NOT DEFINED. These metrics were designed to work with the CVSS “Base Metrics” group; specifically the CIA Impact metrics. So if the vendor analyst states that a vulnerability has a Confidentiality Impact, and the analyst for the organization that has the vulnerable asset states that her or his organization has a Confidentiality Requirement – then the CVSS score could increase. Sounds pretty straightforward – seems to map nicely into the PLM branch of the FAIR taxonomy. Specifically, as contributing factors to estimating loss should the vulnerability be exploited and a loss occur.

It is too bad that the CVSS environmental metrics are optional. I understand why they are and regardless of CVSS generating a score and not taking into account loss event frequency – just imagine how much more informed a security folks and decision makers could be if they took a few more minutes to analyze a given vulnerability and the CVSS score that was provided to them from a vendor in light of these metrics.

In the next (and final) CVSS post, I will share some final thoughts on CVSS and finally put a nail in what was not intended to be a series of posts. Thanks for reading!


Risk and CVSS (Post 3)

September 3, 2008

If you missed the first two posts, the links to Post 1 and Post 2 are on the right hand side of your browser screen.

Let’s get to it…

We are now up to the CVSS “Temporal Metrics”. According to the documentation, these are optional and are meant to be completed by the vendor vulnerability analyst more so then the end user. As to be expected, all three of these can be considered as contributing factors to assessing a vulnerability for risk.

FAIR & CVSS "Temporal Metric" Mapping

FAIR & CVSS

Exploitability. This metric measures the current state of exploit techniques or code availability (possible values are: Unproven, Proof-of-concept, Functional, High, and Not Defined). So the key words here are “current state”. Thus indicating that state changes for better or for worse over time. So in the world of FAIR, this would seem to map nicely to “threat capability” and “control resistance”. “Threat capability” because the exploit methods may be limited to a very small percentage of the threat community; a fraction of the percentage of the threat population as a whole (the community is a subset of the population). “Control resistance” because the exploit may only be possible if the attacker has local system access. Heck, in some cases, security controls could be entirely absent and the system is no more vulnerable then if there were a tens of thousands of dollars worth of controls (paying dollars to protect pennies).

Remediation Level.  According to CVSS, this metric is an important factor for prioritization. Possible values for this metric include: Official fix, Temporary Fix, Workaround, Unavailable, and Not Defined. These choices are more on how the vendor would score it. Seems like there is room for us, the risk assessors to provide our own value. This metric maps well to control resistance in the FAIR taxonomy. Specifically, how resistant are my security controls against the overall threat population? Just because the vendor may not have a solution for us, there could be off-setting controls that do not require a vendor solution for the short term. I appreciate the context this metric was developed within – but do not be fooled into taking logic back into your own hands when it comes to these metrics. We all hear and preach about security in depth – take an opportunity to leverage those investments when analyzing vulnerability from a risk assessment perspective.

Report Confidence. This metric measures the degree of confidence in the existence of the vulnerability and the credibility of the known details. Provided values include: Unconfirmed, Uncorroborated, Confirmed and Not Defined. This may be the one metric that when a vulnerability is first disclosed, only the vendor or other industry experts can accurately select a value for. But within days, weeks or months of public disclosure – pretty much any non-“wolf crying” security expert can do some simple Google searches and validate a provided CVSS metric score or update one on their own. From my perspective, this metric maps well to FAIR’s “threat event frequency” and “threat capability” taxonomy elements. For “threat event frequency”; specifically, “threat contact” and “threat action”. For “threat capability” because the exploit methods may be limited to a very small percentage of the threat community; a fraction of the percentage of the threat population as a whole (the community is a subset of the population). How often do I think a threat agent comes into contact with a vulnerable system and how often do I think they will attempt to exploit the vulnerability once they do come in contact it.  So, “report confidence” is a contributing factor to possibly a higher threat contact or threat action – but does not necessarily guarantee that your threat event frequency is going to be higher or that every threat agent in a threat community or threat population is capable of exploiting the vulnerability – especially in light of other security controls that may be present in your environment.

I will do two more posts on the CVSS framework; the “environmental metrics” group and then a summary post. Thanks for reading!


Risk and CVSS (Post 2)

September 1, 2008

Just before I published “Risk and CVSS (Post 1)” a week or so ago, there was some email strands on the SecurityMetrics.Org mailing list about the scoring methodology that CVSS uses. I had planned on commenting on the scoring as part of this series – but am only going to say that one should be very cautious about how they use such a score – especially in determining a risk rating or quantifying. I have seen multiple risk scenarios where the vulnerability is very high, but the loss event frequency is so low or the impact is low enough that the overall risk is pretty much nothing.

Another noteworthy comment from Risk and CVSS (Post 1) – would be surrounding PCI QSA’s that apparently think that they are providing value-add to PCI merchants by including CVSS vectors and partial scores (directly from the National Vulnerability Database) in their reports but not educating the merchant on how the CVSS “Environmental Metrics” can significantly lower the score that only represents the Base and Temporal metrics. From my perspective, this is where “value add” should come into play from a professional services contractor. If you are paying for consulting firms to assess your compliance or risk posture – do not hesitate to ask them their methodology for scoring or rating risk – you may not be getting your money’s worth.

Back to Post 2….

Despite a problematic scoring model and the suggestion that the CVSS vulnerability score is representative of the actual risk to an organization – the CVSS framework does allow one to consistently and quickly analyze a vulnerability. Yes – consistently and quickly.

After three weeks of analyzing CVSS, I believe that the components of the frame work that make up the three metric groups (base, temporal, and environmental) are great contributing factors (details or facts that influence or factor into risk elements) to the FAIR methodology. Below, I will attempt to quickly cover all three CVSS metric groups and how they map as contributing factors to FAIR. I think this exercise should also result in better understanding the elements that make an information security risk and their relationship with each other.

In CVSS, the “Base Metric” group ‘captures the characteristics of a vulnerability that are constant with time and across user environments’. Specifically, how the vulnerability is exploited (access vector), the complexity of the attack required to exploit the vulnerability (access complexity), number of times an attacker must authenticate pre-attack (authentication), the confidentiality impact to the asset that is vulnerable (confidentiality), the integrity impact to the asset that is vulnerable (integrity) and the availability impact to the asset that is vulnerable (availability).

FAIR & CVSS "Base Metrics" Mapping.

FAIR & CVSS

In FAIR, there is a risk taxonomy diagram (see above) that visually depicts risk and the elements that make up risk. With risk being at the top, it splits off into two branches: “loss event frequency” and “probable loss magnitude”; both of which are broken down further. The CVSS “Base Metrics” can be mapped to FAIR.

Access Vector – CVSS suggests this represents how the vulnerability is exploited: local (system) access, adjacent network, or network. You can read the CVSS documentation for details. In FAIR, I think this vector is a great contributing factor to the “Contact” and “Threat Capability” taxonomy elements. Contact – how often do I expect a threat agent to come in contact (not necessarily attack) a vulnerable system. “Threat Capability” – what percentage of the threat community do I think is capable of overcoming the security resistance present on the asset – let alone get access to it?

Access Complexity – CVSS suggests this measures the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system. Metric values include: HIGH, very hard to exploit; MEDIUM, not easily exploited; LOW, easy to exploit. This CVSS metric maps to three different FAIR taxonomy elements: “Action”, “Threat Capability” and “Control Resistance”.
Action – How often will the threat agent attempt to attack my asset after it comes into contact with it? Threat Capability – what percentage of the threat community do I think is capable of overcoming the security resistance present on the asset? Control Resistance – My security controls are effective against what percentage of the threat population?

Authentication – In CVSS, this is the number of times the attacker must authenticate to a target in order to exploit a vulnerability; Multiple – two or more authentication instances, Single – one authentication instance, None – no authentication. Within FAIR, I have mapped this to “Control Resistance”.

The three other “base metrics” – confidentiality impact, integrity impact, and “availability impact” are all contributing factors to the “probable loss magnitude” branch of the FAIR taxonomy diagram. The metric values for each of these three impacts are – None, no impact; Partial, some impact, and Complete, total loss. Keep in mind that the three metrics are probably more reflective of state versus actual loss. So, the real impact can really only be measured or estimated by someone more familiar with the vulnerable system (its role in a business process and the amount of data on the system).

Since this is running into a long post, I will go ahead and wrap-up. We still have the “temporal” and “environmental” metric groups to look at. Another thought that came to mind while typing this was how access exploit methods can change over time. So any given CVSS score is reflective of the circumstances at that point of time. Thus, these scores should not be blindly used with no additional review of the metrics that make them up.

Finally, I want to start introducing risk scenarios on this blog. To do so, I need to create a fictitious company profile that will be referenced in all of the scenarios. Hopefully in the next few weeks I can get this profile created and published. Once it is done, I think there will be a strong enough foundation from an information standpoint to start publishing risk scenarios and having what I am sure is to be contested – yet meaningful – dialogue.


Risk and CVSS (Post 1)

August 24, 2008

I recently stumbled across the CVSS v2 vulnerability scoring method – as I was writing a post about risk vernacular. Per the CVSS v2 complete guide, “The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impact of IT vulnerabilities.”  As I started highlighting parts of the guide that were thought provoking from a risk perspective, I realized this would probably result in at least two posts – maybe three. So off we go…

I would encourage anyone reading this to perform their own review of CVSS and how it can possibly augment their own risk assessments efforts. In my opinion, there are some really useful “metric vectors” that provide a simple yet powerful way to analyze a vulnerability. In addition, I really like how they have a simple “scoring vector” – essentially a shorthand representation of all the individual “metric vectors”. I could see how this could be really useful for archiving / documenting purposes but for also being to programmatically manipulating for other purposes.

Thought 1: One of the first things that stood out to me as I started reading the CVSS guide was on page three, where they talk about “prioritized risk”. While I agree that their vulnerability score can be considered contextual and be used to compare variance in multiple vulnerabilities– I do not agree that it is representative of the actual risk to the organization.

Here is why.

No where in CVSS is there a metric for gauging how often assets within your environment – that have the vulnerability being analyzed- are being attacked let alone compromised. Now, I am not implying that the authors and maintainers of CVSS are trying to mislead security professionals – but I think this underscores a problem within our industry about knowing what risk is, the elements that make up risk, and risk vernacular.

Let’s talk about vulnerability for a minute. Generally speaking, it can be something (noun, a weakness) or a state / condition (adjective, my application is highly vulnerable to x). It would appear that CVSS accounts for both because you use CVSS to determine how vulnerable you are to vulnerability. Sounds confusing – but not all is lost.

FAIR – the risk assessment methodology I use – accounts for vulnerability as a condition. Within FAIR, vulnerability is derived from “threat capability” (the percentage of my threat community that can overcome control resistance) and “control resistance” (the percentage of control resistance I have against the “threat population” as a whole; for FAIR, threat community is a subset of threat population). When you have and can leverage a methodology and risk taxonomy like FAIR – you can see how easy it is to not take for granted what I would call risk term generalizations – using terms without truly understanding how they should be properly used or not knowing what they really mean. Just to reiterate – vulnerability is an element of risk – not risk itself.

Thought 2: On page 6, section 1.7 of the guide “Quick Definitions”, “threat” is defined as the “likelihood or frequency of a harmful event occurring”. This is the closest to “threat event frequency” or “loss event frequency” that CVSS comes close to touching. Threat can be both a noun and verb – but I have yet to see a dictionary that includes likelihood in its definition. It may sound like I am splitting hairs on definitions and picking on the CVSS folks – this is not my intention; but some of the concepts being discussed are foundational to understanding risk.

To wrap this first post about CVSS, I would offer the following:

1.    That the CVSS-SOG consider participating in the The Open Group; specifically in the “Risk Management and Analysis Taxonomy” forum.
2.    Do not discount the useful of CVSS in analyzing a vulnerability or a state of vulnerability. Just because there may be some risk term short comings does not mean their metric vectors cannot be effectively used.

In the next CVSS related post, I will focus more on the CVSS Metric Groups and how these have forced me to take a step back and evaluate the rigor and consistency I apply to risk assessments.


Risk Vernacular

August 16, 2008

Vernacular is such a “power” word. At 10,000 feet and in the context of risk; “risk vernacular” is essentially a “risk language”.

As I begin to move closer to presenting scenarios and risk analyses, I decided to create a separate page on the blog for some risk terms and definitions. Some of them will be FAIR terms and some others are terms I have learned about from other risk disciplines or stumbled across that seemed to make sense. Yes, there may be disagreement on what I have listed. Please understand that these are the terms that I have cut my “risk teeth” on and seem to stand up fairly well to scrutiny within our industry and our peers in other risk discipline.

Bur more importantly – these are terms and definitions that I think are easy to explain to the non-risk individual.

Take a look at the page, and be prepared to revisit it, because a lot of these terms will be referenced extensively in coming posts.

The next post will be about the “Common Vulnerability Rating System v2”; some positive thoughts, “lukewarm” thoughts, and “caution flags”.