During the course of delivering dozens of PCI assessments over the years, my clients and I have often scratched our heads, trying to determine why on earth a company that is going through a PCI assessment would also need to undergo an annual formal risk assessment. Well, wonder no more – the PCI Standards Council recently released their Risk Assessment Guidelines document, created by the Risk Assessment Special Interest Group (SIG). This post will provide you with the eight-mile-high overview of this document to brief you and to help you determine if it impacts your organization.
The purpose of this document is to provide a guideline for assessed entities to consider while undergoing their annual risk assessment as per the PCI DSS requirement 12.1.2:
“12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.
Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.).”
Thanks first to those folks who have volunteered to participate in the SIG to research and create this document, for efforts like these allow for the PCI Data Security Standard (DSS) to evolve. Keep in mind that the information presented in this document is only a guideline and not to be considered as the PCI standard itself, although it is quite feasible for the PCI Council to adopt some of the information from this report into a future version of the standard. That said, this is a well-written document that will help send you down the right path.
While a PCI assessment is quite prescriptive (think scalpel!), annual risk assessments allow organizations to keep up-to-date with business changes and provides a mechanism to evaluate those changes against the evolving threat landscape, emerging trends, and new technologies (think blunt object!). Many companies who are farther along the maturity curve include some degree of constant formal risk evaluation/assessment when considering new changes, new technologies, or when conducting regular vulnerability management meetings.
What do we Need to Look at?
Your formal risk assessment should look at people, processes, systems, networks, applications, data, and anything that you may care about. The SIG recommends that you focus on entities that handle cardholder data (CHD), but depending on your organization and your architectures, you may also opt to consider out-of-scope entities while undergoing your risk assessment.
Who Should be Doing This?
Some organizations opt to outsource their formal risk assessment to a third party who specializes in performing such assessments. Some organizations create a risk assessment team consisting of personnel from various departments (e.g., security operations, systems administrators, HR, legal). I think that in most cases, a hybrid approach is optimal – where the risk assessment team includes both a third party risk assessment professional(s) as well as an internal risk assessment team. The professional risk assessors /security consultants do this kind of stuff every day and are acutely aware of risk assessment methodologies and of current threat matrices (and may be able to save the team significant time). The company personnel are most tuned in to their own ecosystems (people/processes/technologies/systems), more so than any outsider will ever know. Do you have any thoughts/recommendations about the ideal mix?
What are we Measuring?
The PCI DSS requires that you have documented all cardholder data flows and inventories. If you have not done this yet, then we have some talking to do. You should then determine what vulnerabilities and threats exist against these entities, along with any controls that may be in place to mitigate that risk. You can then go through various gyrations to measure and determine risk, and then make educated decisions to determine your best course of action to address any risks. The document provides a few excellent examples about how to create risks matrices.
Do we Need to Evaluate Third Parties?
This section should help open your eyes about any third parties with whom you are entrusting the security of your (or your customers’) cardholder data. While it is important to have a written agreement in place where the third party agrees to protect CHD, you should also do your due diligence to make sure that there is a clear understanding about who is responsible for what. If you are unsure whether or not a third party is properly caring for your CHD, you may need to do some additional legwork. I have blogged about this in the past and can provide a link to anyone interested in that posting.
Show Your Work
As I’ve often told our clients, you want to make sure that you create some sort of audit trail that demonstrates you are performing the periodic tasks required for PCI compliance. The annual risk assessment is one of those things. You should expect that your QSA will ask to review some sort of a formal report that shows that you have indeed put the right amount of time and effort into this.
If you’ve been performing formal risk assessments each year and have a robust audit trail of reports to prove it, you probably don’t need to change anything. If you’ve been using a third party to perform your annual risk assessment, do not take for granted that they are covering everything that needs to be covered. For example, your formal risk assessment may focus on financial systems and not at all on general threats/vulnerabilities/risks on PCI systems, so make sure this isn’t slipping through the cracks. For those of you who may be a little behind on the maturity curve, I’d recommend that you start developing (and performing!) your risk assessment methodology sooner rather than later to avoid a mad dash to the PCI finish line. Do you have any ideas on how to begin to build out a risk assessment program?