.svg)
A targeted risk analysis, as the name suggests is a risk analysis focused on a narrow scope, often an asset, a threat, or a control. Its purpose is to determine risk and help define aspects of risk management practices.
Various requirements in PCI DSS v4.0 and earlier have controls that are periodic or are activated on a regular interval. Some common intervals have been daily, quarterly, annually, etc. While these intervals are common, many entities wanted more flexibility as to when and how often some activities can be undertaken.
PCI DSS v4.0 has introduced the concept of Targeted Risk Analysis to help define the periodicity of certain requirements. This ability to define how often an action needs to be repeated adds considerable flexibility to implementing the control. Several requirements in PCI DSS v4.0 now allow an entity to perform a Targeted Risk Analysis which can help determine how often that action should be repeated to maintain a certain level of risk. For example, requirement 7.2.5.1 allows the entity to define, using a Targeted Risk Analysis, how often All access by application and system accounts and related access privileges are reviewed.
For PCI DSS purposes, a risk analysis that focuses on a specific PCI DSS requirement(s) of interest, either because the requirement allows flexibility (for example, as to frequency) or, for the Customized Approach, to explain how the entity assessed the risk and determined the customized control meets the objective of a PCI DSS requirement.
Additionally, those entities planning on utilizing a Customized Approach to meet requirements must also perform a Targeted Risk Analysis for each of those requirements.
How to do a Targeted Risk Analysis
The Targeted Risk Analysis should be reviewed at least annually, or more frequently based on risk and implementation.
Each requirement that allows for the period for performing activities to be set using a Targeted Risk Analysis will need its own Targeted Risk Analysis. In other words, the Targeted Risk Analysis is not one exercise for all requirements; it is a separate exercise, one for each applicable requirement or subset of assets. Therefore, a QSA will expect to see several TRAs, one for each requirement with this flexibility.
Requirement 12.3.1 defines what must be included in a Targeted Risk Analysis. Appendix E2 of the PCI DSS v4.0 standards document provides a template that can be used to conduct and document the Targeted Risk Analysis. It is not required that this template be used. However, it is very important that no matter which method or document is used, at a minimum, all elements in requirement 12.3.1 are addressed and answered. Keep in mind that although this template is in an appendix to support customized approaches, the template (or the content) can be used for all TRAs.
When conducting the Targeted Risk Analysis, the PCI DSS reminds us to keep in mind:
- The asset being protected is the cardholder data that is stored, processed, or transmitted by the entity.
- The threat actor is highly motivated and capable. The motivation and capability of threat actors tends to increase in relation to the volume of cardholder data that a successful attack will realize.
- The likelihood that an entity will be targeted by threat actors increases as the entity stores, processes, or transmits greater volumes of cardholder data.
- The mischief is directly related to the objective.
The term mischief here is exemplified by if the objective is malicious software cannot execute, the mischief is that malicious software executes; if the objective is day-to-day responsibilities for performing all the activities are allocated, the mischief is that the responsibilities are not allocated. In a nutshell, then, mischief is the opposite of the objective.
Within the template, some questions are straightforward. We'll explore some questions that merit discussion.
Question 1.3 asks to describe the mischief and its effects. This requires that we put on our threat actor hat and write down the malicious activities that can be performed and the effect those activities will have. For example, requirement 12.10.4.1 asks for periodic training for incident response personnel. The mischief here, and its effects can be explored by asking the question what happens when periodic training is not conducted or attended?.
Question 2.3 and 3.x asks how the proposed solution will prevent the mischief. To answer this, first, understand what the controls or steps do to stop/block/slowdown the malicious acts. Then what can malicious actors do to circumvent those controls, and then finally, how will the entity know if the control has failed.
Carrying forward our example, one answer may be that by conducting training every x months, incident response personnel would know the latest detection and response techniques, understand their tools better, and be fully aware of their responsibilities and role in responding to security alerts and incidents so that we reduce the likelihood of correct an effective incident response is increased and detection and detection and response times, and overall impact of any incident on the business, reduced.
Conclusion
Targeted Risk Analysis is a new tool to help formally define and design controls to meet security and compliance objectives. There are many requirements and situations where a Targeted Risk Analysis is warranted.
Many Targeted Risk Analysis can be complex and require in-depth knowledge in threat modeling, risk analysis, and controls design. VikingCloud consultants and QSAs are well-versed in all these areas and have experience in a wide range of environments. Contact VikingCloud to learn more about Targeted Risk Analysis and how it can help your PCI compliance routine.
Click here for more information about VikingCloud's Risk Management solutions or contact a the VikingCloud team.
.svg)
