Risk Assessment is a core feature of most modern security considerations, including the PCI DSS. Featuring as Requirement 12.2, it splits into two parts:
- There is a documented process resulting in a formal, documented analysis of risk.
- The process is performed at least annually (or upon significant change)
Unlike other areas of the PCI DSS which are very prescriptive, this requirement on first reading doesn't really show much relationship to the rest of the PCI DSS, but don't be fooled.
Outside of the PCI DSS, A security risk assessment identifies and quantifies untreated risks to assets before selecting controls to mitigate such risks. Under the PCI DSS, the identification of assets and the selection of controls is essentially done for you by virtue of:
- defining the scope of your assessment,
- determining if your card data processes qualify for any reductions under an SAQ and
- applying the technical controls of the PCI DSS
What can often be overlooked are the times within the PCI DSS when risk assessment contributes to other PCI DSS controls - here are the 7 explicitly mentioned:
6.1 - Vulnerability Management; does your risk assessment provide an evaluation of the likely risk you are exposed to for the system in scope? Does it also rank vulnerabilities you become aware of from scan reports, pen test reports and industry sources of information?
9.9.2 - Periodic Inspection of Devices; what reasoning determined the frequency under which you are inspecting your devices? Various suggestions exist, including those by the PCI SSC, but the PCI DSS is looking for merchants to identify their frequency through risk assessment. Obviously this won't feature if you don't have any PED's.
10.6.2 - Reviewing of logs of other systems components periodically as determined by your risk assessment. Whilst you may be qualifying for risk reduction under an SAQ, you could be giving yourself and customers a false sense of security if you are not reviewing all valuable log information, the risk assessment is a perfect vehicle for defining which other logs might identify problems or risks to your CDE and getting them reviewed.
10.8.1 - Respond to failures of any critical security control…..using a risk assessment to determine whether further actions are required as a result of the security failure. If something keeps going wrong, you perhaps need to replace it and the risk assessment process can assist in the justification for securing additional budget to address this, otherwise it may struggle to get funded as there's no documented business case.
11.3 - Penetration Testing. Specification of penetration tests can vary hugely based upon the environment, budget, technologies, and time. By using your risk assessment, this can help to determine the requirements in conjunction with pure specification.
11.5 - Change-detection. Your individual environment may have a solution which places critical files in unusual or non-standard places; this is where the evaluation of your solution would yield a decision of what would therefore be monitored.
A.2.2 - Entities with existing implementations of SSL or Early TLS. Although you would need an RMMP (risk mitigation and migration plan), it makes more sense to have the information in your core risk assessment, it becomes a copy and paste exercise then to produce a current RMMP.
In Summary, if you've previously wondered what the Risk Assessment activities relationship with the PCI DSS is, then you have some more information. Ultimately, good security operates from a position of understanding risks and having this to support your PCI DSS business as usual activity is simply a bonus! If you have any questions about PCI and want to speak to a Nettitude consultant contact us today.