Posts Tagged ‘risk assessment

20
Mar
15

You Make The Rules

At last year’s Community Meeting, there were a couple of instances where members of the PCI SSC reminded organizations that it is up to them to set the parameters of their PCI assessment. A lot of people in attendance took those comments to mean it is up to merchants and service providers to define the scope of their assessment, but it goes further than that.

For years organizations have complained that they receive varying advice from different QSAs even when the QSAs are from the same firm. Obviously this situation is frustrating for not only merchants and service providers, but for the QSAs as well.

To address this situation, the Council is telling all PCI stakeholders that it is up to the organizations being assessed to define the rules of the assessment. Not just the scope, but also what level of risk that the organization is willing to accept. So what does that mean? I intend to clarify that in this post.

And to be extra clear, this is not some excuse to create a set of rules that allow you to skate by. You must show your work and document your rationale. If your QSA has honest concerns about your work, then expect some push back and bringing your acquiring bank into the discussion. If your acquiring bank agrees with your rules, then you need to get that in writing from them and everyone should move on. But if your acquiring bank agrees with your QSA, then expect to make changes to your rules.

Scoping

Scoping is the responsibility of the organization being assessed, not your bank’s or your QSA’s responsibility. This requirement is even explicitly called out in the PCI DSS on page 10, second paragraph, second sentence.

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope.”

The first step in defining scope is to define the rules of how to scope. This is the toughest part of scoping.

Complain about it all you want, but the Open PCI Scoping Toolkit is a good framework to start the discussion about how to scope a PCI assessment based on the risk presented by devices. My first recommendation is that I would highly recommend that you stick with the three categories. In my experience, organizations that create more categories just end up creating more confusion and consternation. However, there is no way to go with fewer categories without putting your entire network in-scope.

Categories 1 and 3 are not the ones in question. My personal opinion is that having two sub-categories in category 1 seems silly to me. Devices and systems that directly process, store or transmit cardholder data (CHD) or are in use within or define the cardholder data environment (CDE) are category 1 regardless. Category 3 devices/systems are those that never, ever come into contact with the CDE. In my opinion, these two categories are clear cut and pretty straight forward.

Where the arguments occur or will occur most often is over the category 2 devices and systems. You can accept the four sub-categories that are defined in the toolkit or come up with your own. If you are going to define your own sub-categories for category 2, the key point to remember is that category 2 devices/systems have direct or indirect influence over the category 1 devices/systems because they have access in some way to the CDE. The sub-categories are used to define the level or risk or threat these category 2 devices/systems represent to the category 1 devices/systems based on the type of access the category 2 devices/systems have to the CDE.

The difficulty with setting the category 2 sub-categories is that everyone has their own risk tolerance. It is those differences in tolerance that create the problems. Security personnel tend to be more conservative because it is their butt on the line if something bad happens. The further people get away from security, the more risk tolerant people seem to get because they do not have a complete understanding/appreciation of the minutiae.

Experience says that whatever and however you define category 2 devices/systems do it as simply and clearly as possible. I would highly recommend you keep the number of sub-categories to a minimum and that you use examples for each sub-category so that readers understand where devices/systems fall under your sub-categories. The key outcome of this effort is a formal document, similar to the Open PCI Scoping Toolkit that; defines your categories, the rationale for those categories, provides examples for each category and is approved by executive management.

Once you have defined your scoping categorization rules, then it becomes an exercise in categorizing your inventory of networks, devices and systems based on your criteria. Do not be surprised if during this process networks, devices and systems you thought were out of scope suddenly come into scope. This is not unusual because prior to this point you were just taking a scientific wild ass guess (SWAG) as to what was in-scope.

Risk Assessment

Once you have your scoping categories set, you need to roll that methodology into your risk assessment so that you can properly assess your risk. By doing so most organizations find that their risk assessment shows more devices/systems at higher risk because they are now in-scope for PCI compliance.

Take your scoping categories and convert them to weights for evaluating risks. For example, category 1 devices/systems would carry the highest risk weighting available. Category 3 devices/systems would carry the lowest risk weighting allowed. Category 2 systems would carry risk weights somewhere between the highest and the lowest based on how you have defined your category 2 sub-categories.

Define Your Terminology

This is very straight forward, but is usually missed by most organizations. Organizations need to define their terminology. In particular, what the organization means by ‘significant change’, ‘period’ and ‘periodically’. I wrote a post on this very topic a while back so I will not bore you here with that discussion. These are very important definitions that must be set.

However there are likely other terms that should be defined for your QSA and anyone else without intimate knowledge of your technology environment. My personnel pet peeve is the lack of definitions of acronyms that are commonly used by your organization but that might be easily misunderstood by anyone else. It never ceases to amaze me when people inadvertently treat an outsider as an “idiot” when they speak in acronyms and the outsider has no clue as to what was said because they are not insiders.

My favorite example of this was a person that kept referring to the ‘HSM’ during our interview. Given this was a PCI assessment, my assumption was that they were referring to a hardware security module, however the way they used ‘HSM’ in our interview seemed to be in the wrong context. So I asked them and they confirmed my suspicion, they had been referring to a custom application called high-level system messaging. Had it been in a mainframe environment, HSM could have been a reference to hierarchical storage management. This is why a glossary of terms and acronyms is a good thing to build, not just for PCI but for any newcomer to your environment.

Discuss This With Your QSA

Finally, do not keep your QSA in the dark as you work through this process. As you create your documentation and classify your devices and systems, run this all by your QSA to get their buy in before they start your assessment. Most organizations will not run into too much push back from their QSA unless they are trying to set the bar too low in a vain attempt to make the PCI compliance process too easy, i.e., checking a box. The last thing you should do is spring this on your QSA the day they start your assessment. And that includes if you update or change your rules between assessments.

All of this effort should result in a much more straight forward assessment because you have defined the rules and criteria to which you are to be assessed.

23
Nov
14

Face It, You Are A Poor Judge Of Risk

“The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown.” HP Lovecraft

We have a pop quiz today.

  1. Are you more likely to die from an alligator attack or a shark attack?
  2. Are you more likely to win the PowerBall lottery jackpot or become a movie star?
  3. Are you more likely to die in a vending machine accident or from a lightning strike?
  4. Are you more likely to be elected President of the United States or to date a supermodel?
  5. Are you more likely to die from influenza or from drowning?
  6. Are you more likely to catch influenza or Ebola?

The purpose of this pop quiz is to demonstrate how poorly we humans evaluate and understand risks. I have to admit I got caught on a couple of these as I did the research.

If anything, the Ebola discussion has brought this issue of risk judgment to the forefront given the unfounded fear people have of Ebola. As a mathematician by schooling it has fascinated me as I watch the media reports and government officials cave into the spread of fear over something very highly unlikely to occur to anyone in the general population.

Do not get me wrong. If I were a health care worker anywhere in the world, I would have concerns about my risk of catching Ebola. After all, they are on the front line and Ebola has around a 50% fatality rate. Add into that the informative, but frightening, video that Dr. Sanjay Gupta of CNN did on the difficulty of removing a containment suit without potentially infecting yourself, and it confirms the threat a health care worker should be feeling if confronted with a potential Ebola patient that is symptomatic.

But for anyone outside of health care, there should be little if any reason to be concerned. Yet a good percentage of the public is irrational when it comes to Ebola regardless of the fact that it requires contact with a symptomatic person’s bodily fluids in order to be infected. But unlike a person with influenza, an Ebola infected person that is contagious does not have the mobility required to have contact with people unless those people come to them. As a result, all of these mental gymnastics that people go through about the possibility that an infection could occur on a bus or the subway are silly because the person with Ebola when they are contagious would look worse than a zombie off of ‘The Walking Dead’, assuming they could even walk at that point.

I am sure you are all saying that this is all good and well, but what is the point here in regards to PCI?

Glad you asked. I bring this up because the PCI DSS is heading more and more to be driven by risk and the assessment of that risk. Yet as I have hopefully shown by my quiz questions, people and their organizations are poor at understanding and determining risks. So organizations need to get much better at performing risk assessments (if they are performed at all) so that they can truly understand and manage risks. That said, a risk assessment does not have to be, nor should it be, a huge “death march” of a project. A proper risk assessment should answer the following questions.

  • What are the risks to the organization? This does not have to be an exhaustive, all inclusive list as you find in the various risk assessment methodology frameworks. But should include all of the most likely risks. For PCI compliance, this risk assessment only needs to address the risks to those things that are in-scope for the assessment. However, most organizations need the risk assessment for other reasons, so it often contains all risks, not just PCI risks. If it does contain risks outside of PCI, you should add columns for your other requirements so you can filter out just the PCI, HIPAA, GLBA, FISMA and any other risk frameworks.
  • What is the likelihood of the risk occurring? Typically, I use a scale of 1 to 5 where 1 is it occurs infrequently and 5 represents that it occurs often. If something never occurs, then it should be removed from the list.
  • If the risk occurs, what is the impact on the organization? Here I use a scale of 1 to 3 where 1 is low, 2 is moderate and 3 is high.
  • Multiply the likelihood with the impact and you get the risk rating.
  • Sort the risk ratings from highest to lowest and you have your risk assessment rating completed.

But hold on, you are not done just yet. Now you need to set your organization’s risk threshold. This will likely be a very contentious discussion as you will find that people within the organization have widely differing views on the level of risk they are willing to accept. However, it is important to capture the highlights of this discussion so that you have documentation for future discussions as you discuss future risk assessment results and reset the organization’s risk threshold.

Risks that fall below a certain risk rating are accepted and management formally agrees to accept them. Those above that level you develop methods of mitigating and managing those risks. Under my rating system, the lowest score that can be achieved is 1 and the highest score is 15. A lot of organizations might say that a total score of below 4 is to be accepted. For some organizations a better approach to accepting risk is sometimes to only accept those risks that have an impact of ‘Low’ (i.e., equal to 1). Therefore, all moderate and high impact risks are mitigated and managed.

Once you have your analysis done you will have a list of risks that require mitigation and management through monitoring and other methods.

Answers

  1. According to the Florida Museum of Natural History, between 1948 and 2005 there were 391 alligator attacks resulting in 18 fatalities whereas there were 592 shark attacks with 9 fatalities. That makes the alligator fatality rate almost three times as high as the shark fatality rate.
  2. The odds of winning the PowerBall are around one in 175M. While still incredibly long, the odds of becoming a movie star are significantly lower at one in 1.5M.
  3. Lightning is more deadly but do not underestimate that vending machine. According to the US National Oceanic and Atmospheric Administration (NOAA), the odds of being hit by lightning in the US are one in 1.9M. According to the US National Safety Council, there is a one in 112M chance of dying in a vending machine accident.
  4. The odds are in your favor if you are interested in dating a supermodel. Even better than becoming a movie star. You have a one in 88K chance of dating a supermodel according to Ask the Odds. The odds of being elected President are slim at one in 10M.
  5. The US Centers for Disease Control (CDC) estimate that the odds of drowning are one in 31.4. The CDC estimates that the odds of dying from influenza are around one in 345K.
  6. The CDC estimates that one in eight people will catch the flu in any given year and as seen in a previous answer, there is a one in 345K chance that a person will die as a result. Given the population of the US is around 315M and only four people have actually caught the Ebola virus in the US, there is around a one in 78M chance of catching Ebola in the US but that could change slightly if more infected people enter the US.



January 2022
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Months