Risk Assessment in SAP Against a Cybersecurity Framework

Reading time: 4 mins

Key Takeaways

⇨ To ensure cybersecurity, organizations must know how to evaluate the risks they face.

⇨ When performing any kind of risk analysis, there needs to be a common unit of measurement.

⇨ Once the biggest threats are defined, then organization can decide how best to mitigate them.

In the first article in this series, we gave an overview of the NIST 800-53 Rev5 and CMMC frameworks and demonstrated how the SOX SOD risks align to those frameworks. In the second installment, I’ll give an overview of how risk levels are assigned to controls and how to manage that risk.

When performing any kind of risk analysis, there needs to be a common unit of measurement. The Common Vulnerability Scoring System (CVSS) score is the measurement used for evaluating risk in a numerical fashion. It standardizes the idea of High, Medium, and Low into numerical values that can be calculated and used for grading vulnerabilities. Those same numbers then apply to remediation of vulnerabilities and measuring risk universally.

Generally, it is common practice to align risks to the NIST framework to define risk levels and then align them with the CVSS mapping. Below is a table mapping the risk scoring that SAP uses to the NIST and CVSS scoring. This is the verbiage you will find on all of SAP’s security notes.

Scorecard Mapping
SAP NIST CVSSv3.1
Critical High 9.0 – 10
High High 7.0 – 8.9
Medium Moderate 4.0 – 6.9
Low Low 0.1 – 3.9
None 0

 

One of the key things to understand is that CMMC does not break things out by risk, so cross-referencing the risk value to NIST is necessary in order to merge it into an existing cybersecurity risk management program.

Scoring Risks

In the previous article, we looked at how SOX Segregation of Duties risks aligned to CMMC and NIST frameworks. Now we are going to show you how to align those risks to NIST and CMMC and how to score them. For this example, we will focus on a common job-related segregation of duties risk from the SAP GRC rulebook:

F005 – Maintain bank accounts and post a payment from it

P001 – Create fictitious vendor and initiate payment to the vendor

SAP GRC Risk CMMC Practice NIST SP800-53 Rev 5 Control NIST Risk Rating
F005 AC.L2-3.1.2

Transaction & Function Control

Limit Information Systems Access to the types of transactions and functions that authorized users are permitted to execute.

 

AC.L2-3.1.4

Separation of Duties

Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

 

AC(5) – Separation of Duties
Identify and document organization-defined duties of individuals requiring separation and define system access authorizations to support separation of duties.
AC5 – High

 

P001 AC.L2-3.1.2

Transaction & Function Control

Limit Information Systems Access to the types of transactions and functions that authorized users are permitted to execute.

 

AC.L2-3.1.4

Separation of Duties

Separate the duties of individuals to reduce the risk of malevolent activity without collusion

 

AC(5) – Separation of Duties
Identify and document organization-defined duties of individuals requiring separation and define system access authorizations to support separation of duties.
AC5 – High

 

Table Reference

Lowering Risk

Firstly, we have to understand how and why a risk is scored the way it is within a framework in order to manage the process of risk reduction, mitigation, and acceptance. The NIST baseline is the common starting place for doing a risk analysis. In our example above, Separation of Duties is a high risk in the NIST baseline. This is called a Raw Risk Level. There are two ways to lower risk in this situation:

  1. System Hardening: System hardening the process of implementing changes, either to code or process, that address the risk. In the case of Separation of Duties, it would be to rework the security roles containing those transactions to remove the risk from inside the role. This transfers the risk to the user level. From there, it is a business decision to further harden the system by changing the tasking of the employees to remove the risk or to mitigate the risk instead.
  2. Mitigation: Mitigating the risk is the process of having some method to monitor what is going on to track the risk and validate the activities being executed. Those familiar with SAP GRC are familiar with the concept of mitigation controls. But the real secret to passing an audit is writing mitigation statements that are meaningful and provable.

How to Write a Meaningful Mitigating Statement

A mitigation statement is a detailed explanation with supporting documentation intended to lower the raw risk level of a control without further hardening the process. Writing mitigation statements is critical to successfully navigating an audit. The statements need to be specific, clear, and have detailed information. Each point in the statement must be provable from a validator/auditor’s point of view. There are four responses to mitigate risk: tolerate, terminate, treat, or transfer.

The key to writing a strong mitigation statement is to address one or more of those mitigation responses to validate lowering the risk of a control. The formula for writing a solid mitigation statement is that it must:

  • Clearly identify the risk
  • Describe how the risk does or does not impact the system
  • Describe any mitigation strategies like log reviews, user access reviews, change management, tightly controlled background processes, tightly secured roles, or other sorts of things that make it much harder for the risk to be executed
  • Provide details on supporting documentation, where that documentation can be found, who owns, reviews, and approves that documentation, and the frequency of those reviews.
  • Explain how the mitigation strategies terminate, treat, or transfer the risk
  • Detail any residual risk after the mitigation if that risk should be tolerated and specify why

Once the mitigation statements are in place, the final step is to retain the described audit documentation and manage the document retention process. This process is the same for a cyber audit as it is for a financial one.

In part three of this article series, I’ll cover how to roll this risk analysis up into a companywide cybersecurity risk management program. If you’re looking for greater depth into cybersecurity policy compliance, watch for my new book on this topic coming in 2023 from Espresso Tutorials.

More Resources

See All Related Content