By Jay Thoden van Velzen, Office of the CSO
SAP requires that its products and supporting services meet the security requirements set by the company. Inevitably, though, with SAP’s variety, complexity, and rate of change in the organization and its internal and external services portfolio, not all products can always meet all security policies to the letter. Security policies aim to cover as much as possible, but there can be edge cases that a particular policy didn’t cater for. For that, we have the exception management process, where business justifications are evaluated against financial and security risks and where possible mitigation approaches are discussed.
SAP Global Security and Cloud Compliance (SGSC) is the central security and compliance organization in the company. This organization is co-led by Chief Security Risk & Compliance Officer Marielle Ehrmann and Chief Security Officer Sebastian Lange and is responsible to centrally manage security and compliance risks for SAP. Its functions include setting security policies for the different business units, security risk management, and central governance.
SAP is structured into several Lines of Business (LoB) that each themselves are large organizations that represent different segments of SAP’s product portfolio or cloud infrastructure, service, and delivery operations. Each LoB has a Business Information Security Officer (BISO), who act as Chief Information Security Officers (CISO) for their organizations with their own team to manage security and compliance in their LoB. The diagram below shows the setup. Dotted lines between BISOs and CSO are omitted.
SGCS structures its security programs along the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF). From there, we derive a security control framework based on applicable standards and requirements. Since those standards are technology-agnostic, SGSC further develops that into a security policy framework that describes how those standard controls must be implemented in a particular practical context. That provides developer, DevOps and operations teams with concrete instructions on what is expected of them to meet compliance.
These policies must be adopted by the LoB teams, with oversight tracking that processes are followed. LoBs can challenge policies for operational reasons, which allows a process to refine them to ensure they are practical and achievable, while ensuring the intent of the policy is maintained. A practical example of that was discussed here.
Finally, internal and external audits verify that the policies are indeed followed, and teams and their leaders are held to account if they don’t.
Before new policies or changes go into effect, they are announced generally a quarter in advance to give teams the opportunity to prepare for them. Any associated scans for the policy are marked for information only. Once the policy is active, any LoB not yet able to meet it will need to request an exception to the policy. This can also apply to acquisitions when they are onboarded onto SAP’s security framework.
The intention of the risk-based exception management process is to ensure that the intent of security policies is still met. But we must manage edge cases where the policy causes real business impact on the LoB team. Exceptions are temporary and are granted for 6 or 12 months. The process requires teams to provide mitigating controls and a plan towards meeting compliance.
SAP’s security exception process has 4 different review stages. The process is cumbersome to teams so they must consider the effort involved in submitting exception requests and only do so when they believe they have no other option. The process is intended to manage genuine challenges teams encounter to fulfill security controls. It should not be easy to get an exception. The multiple stages ensure that both the relevant LoB and BISO carefully consider the risks involved, as well as guarantee central oversight by SGSC before any exception approval is granted.
In the very first stage, the relevant security topic or policy owner in SGSC reviews the exception request to see whether it warrants consideration at all. Spurious requests are quickly rejected, as well as requests to bypass baseline security controls. For instance, exceptions for certain cloud guardrails such as centralized logging or enforced encryption standards are not realistically entertained for debate as exceptions. Teams cannot ask for exceptions to be permanently exempt from the central vulnerability management program, threat detection and incident response, or the Secure Development and Operations Lifecycle (SDOL), nor compliance and audit relevant controls.
There must be a legitimate reason why a security control poses an undue burden and cannot be fulfilled as defined in the policy. After the SGSC owner determines that the LoB request has merit, the request moves back to the LoB to prepare a considered case. If it does not, the exception request is denied and closed.
In the second stage, the LoB team requesting the exception must work with the Risk Coordinator for their unit to perform a risk assessment. This determines the security and financial risk exposure, and whether that risk can be reduced with mitigating controls. If the risk exceeds acceptable levels, the exception request ends here.
If on the other hand the business justification and the risk assessment meet approval, the exception request moves on to the next stage.
The LoB team now needs to supplement the risk assessment with a plan for mitigating controls to not reduce the security posture. The team must also prepare a plan and timeline to get in compliance with the policy, so no future exceptions are needed.
The exception request with supporting documentation is then reviewed by the business unit’s BISO. BISOs may return the request to the team for clarification or improvements, accelerate the timeline, or decide to reject the exception request outright, based on their security and compliance assessment.
Only after the BISO approves the request, and the L1 Manager accepts any residual risk, does the exception request move back to the central security team for final review.
Finally, the BISO submits the LoBs case to SGSC for central review. The security topic or policy owner evaluates the case and brings in other domain experts as needed. The central team can request the LoB to clarify aspects, provide more detail, or reconsider the risk assessment based on its broader scope and views of security risks the LoB didn't think of. For instance, any downstream impact on other LoB teams or SAP broadly.
If the policy owner rejects the request and the LoB L1 Manager and BISO disagree with the decision, they can appeal directly to the CSO and CSRCO. Unless somewhere along the process there was significant oversight or misunderstanding, such appeals rarely succeed.
If the policy owner agrees with the LoBs assessment, a temporary exception is granted and recorded, which also mutes associated scan alerts. Risks associated with the exception are recorded in the LoB’s Risk Register. If the financial value exceeds a standard threshold, the risk is also tracked centrally by SGSC’s Security Risk team.
LoB teams must monitor the progress of their mitigation plans and work towards compliance by the end of the exception period.
Every exception is temporary. Once the end date of the exception is reached, the impacted team ideally no longer needs the exception.
However, that is not always the case. The engineering effort required for the remediation may have taken longer than estimated or has downstream dependencies that weren’t previously understood. In that case, the process starts again at 1. If the remediation is not completed yet, but is well under way, the exception can be extended by going through the entire process again, including new risk and security reviews. However, the extension can also be rejected at each of the stages, as risk and security circumstances may have changed during the exception period.
However, in very rare circumstances we find during exception extension reviews that no new risks have been discovered, the business reasons for the exception continue to be valid, mitigating controls are in place to manage risk and the situation is unlikely to change.
For instance, we found a team through scans that generated thousands of keys that weren’t rotated. These turned out to be test keys used by the SAP Data Custodian development team in their development and testing cycles. The keys weren’t used to protect anything. Rather than force the team into repeated exception requests that the process is not intended for, instead the relevant policy requirement was adapted to accommodate this unique use case.
The purpose of the exception process is to ensure that exceptions are rare, safe, and justified. And as mentioned before, always temporary. The priority is always first to protect the business, and not let teams escape their responsibilities. The entire process is documented, and available for inspection and review for audits.
We believe this is a responsible way to maintain our security and compliance posture, while allowing teams some flexibility to conduct their business operations.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.