In the previous two articles in this series, we gave an overview of the NIST 800-53 Rev5 and CMMC frameworks, explained how SOX SOD risks align to those, and how to manage risk assessment and mitigation statements. In this third and final installment, we will go deeper into how to execute a risk assessment in your SAP landscape. We will highlight some of the key things to look for. I’ll wrap up by explaining how to add risk in the SAP environment into a companywide compliance program. This risk assessment process has a few goals:

• Providing analysis of the system risk level for inclusion in a NIST/CMMC compliance effort
• Prioritizing risk reduction efforts
• Communicating risk to people outside of IT and Audit
• Passing an audit

The first step in doing a risk assessment of your SAP landscape is to identify the people and teams to involve. Identifying controls that apply to SAP will involve working with the SAP Basis and Security teams, as well as server and database administrators. Download the NIST controls from this link.

Risk Analysis

The most efficient way to manage a risk analysis is to start with the high risks and work your way down to the low ones. The first-pass review is to identify ones that don’t seem to apply to your landscape and situation. They will need to be addressed from a mitigation statement perspective. For those that aren’t applicable, you should write a mitigation statement that explains why it’s not applicable, and that the control will be evaluated on some preset interval to ensure that it remains not applicable. Once you’ve got a list of the controls that should be evaluated, break them out by technical process. You can start with anything that you have an existing controlled process for, things like user access management and review, security note application, transport management, etc. Review the documentation for those processes against the control to do a gap analysis. Ensure that the process addresses all items in the control. Then write a mitigation statement explaining how the process addresses the control, where the process documentation is located, and how it lowers or removes the risk.

Identifying Risk

Following the risk analysis, evaluate at the business process and transaction code level. Review what they do and align them to the NIST framework. An example process would accomplish the following:

• Start with the critical transactions listed in the SAP GRC rulebook.
• Include server and database management tools and functions done outside of SAP at the server level.
• Look at critical authorization objects like:
  • S_RFC – Remote Function Call: This is associated with risks around cross-system, platform communication, anything with communication to cloud applications or anything that moves data or provides access from outside of the specific environment. Vulnerabilities that speak to authorization hijacking, cross-site scripting, or other directory/system traversal.
  • S_TABU_DIS: Table access risks will be access level risks, directory, or table traversal. Vulnerabilities around information theft, table code, or data insertion or corruption. Can be used in ransomware attacks if there is access to do anything to tables.
  • S_TRANSPORT – Transport of code: These risks will be around change management.
  • There are a multitude of others.

Tailoring Risk Levels

Tailoring risk levels means evaluating the context of the risk in the landscape and deciding if it posed a higher or lower risk than the control proposes. The process would be to:

• Look at the transaction and authorization objects texts and the details on the values of the fields within the authorization objects when aligning the transactions to NIST risks.
  • Look at the functionality of the work being done at the server and database level to align to NIST risks.
  • Evaluate both of these within the context of the landscape itself–its connectivity, hosting location, and data and privacy concerns.
  • Evaluate what roles contain them and who they are assigned to.
  • Evaluate if access to these is controlled through an emergency access management tool or process.

Communicating Risk Outside of IT and Audit

The biggest challenge that technology teams have is how to communicate risk to people outside of the technology team. Upper management wants to see a Summary Risk Matrix heat map so they can understand at a high level what the overall risk to the architecture is and where they should put their financial investment first. A Summary Risk Matrix takes the calculated risk analysis and summarizes it by the likelihood that a problem will happen and the impact it would have if it did. It is commonly color-coded red/yellow/green where the highest risk is red and the lowest is green. It categorizes risks as either Acceptable or Unacceptable. Acceptable Risk is determined by the business. It is a financial decision, not a technical one, and requires working with a liaison between finance and IT to review the mathematical calculations to translate them into the risk matrix. An example summary risk matrix is shown below. Keys to reading this Risk Matrix:

• Likelihood x Impact/Volume = Risk
  • Risk declines with Likelihood
  • If something is likely and would have a major impact, it is categorized as an Unacceptable Risk–Extreme

A summary risk matrix is usually rolled up from different systems or processes into heat maps presented by the business department (Finance, HR, Information Technology, Cybersecurity, Audit, etc.). A heat map for cybersecurity risk across the SAP Landscape would be rolled up into the overall cybersecurity summary.

Document Retention for Cyber Audit

Most of us have been through a financial audit with its interrogatories, sampling, and requests for evidence. Passing a cyber audit is much the same as passing a financial one. There are a lot of tools on the market for monitoring and retaining evidence, but what should you do if that’s outside of your budget? In that situation, the only difference between a financial audit and a cyber one is deciding how much data you can reasonably keep. It’s not reasonable to keep all system, user, or change logs. But it is reasonable to decide on a sampling size and frequency. If the choice is to perform spot checks in logs, write up a process document that defines the following:

• What is going to be checked
• How often
• What should be documented and how
• A plan retaining the evidence

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.