How to secure an SAP S/4 transformation project

While SAP ECC 6.0 is fully supported until 2027, it is already an outdated system missing some of the great innovations from SAP in recent years. Therefore, many companies are currently undergoing or planning their SAP S/4 transformation journey.

A typical transformation requires many decisions – strategic ones such as choosing between a system conversion (a.k.a. brownfield), a new implementation (a.k.a. greenfield) or a hybrid approach. Then there are operational decisions related to data migration, handling custom developments/enhancements and business process changes. Also, there are other decisions related to the system architecture – on-premise deployment vs cloud (private vs public). In my experience, all of these discussions leave little time to think about one important aspect – SECURITY.

It is not uncommon for the SAP project team (or System Integrators (‘SI’)) to focus on ensuring the system works, whilst neglecting the governance, risk and compliance aspects. Given the unique nature of SAP S/4 HANA, it is not an easy task – security aspects cannot be handled by the SAP functional team, BASIS team, or infrastructure security teams. It needs specialists who understand the SAP S/4 system architecture and associated risks/threats.

Unfortunately, many SIs do not have this expertise or do not include it in the SAP S/4 transformation program in order to keep the costs low. While this serves the SI (and the user organization in short run), it is not a sustainable solution.

We all know that ‘secure by design’ is important. Once the design ignores the security requirements, it is always going to be hard to retrofit the security aspects. So, it is very important to plan for security at the beginning of SAP S/4 HANA programmes.

Here are some of the key things to ensure you remember:

1. Perform an information security risk assessment to prioritise security controls
2. Assign adequate resources and budget to address security requirements
3. Prioritise security areas/packages and develop a roadmap for implementation
4. Ensure security acceptance testing is included as part of the overall system testing strategy

Every organization and every project is different with its own set of challenges and priorities. However, I have assisted a lot of clients with SAP S/4 HANA transformation security and have noted some key themes which often crop up that are crucial for organizations to discuss and consider before implementing transformation programmes:

1. SAP security policies, procedures, guidelines and standards
   1. It is important to align SAP security with the overall organizational information security policies, procedures and guidelines. The first step is to translate these into SAP security requirements by coming up with documented SAP security policies, procedures and guidelines.
   2. Just like the security standards/baseline for operating systems and databases are documented, it’s important to document the security standards/baseline for SAP components such as NetWeaver ABAP, NetWeaver Java and HANA database.
   3. Ensure that the SAP S/4 HANA transformation program adheres to these SAP security policies, procedures, guidelines and standards.
2. Data privacy
   1. Perform an assessment against any relevant personal data protection requirements and ensure sensitive data in SAP is clearly identified.
   2. Based on risk assessment results, plan sufficient controls to mitigate any data privacy risks. This may be in form of restricting access to sensitive data, data masking/obfuscation and data logging.
3. Secure authorization design
   1. One of the biggest challenges with SAP is its complex authorization design. Apart from the standard authorization components of roles, profiles, authorization, & objects, the security team has to deal with added considerations for SAP Fiori (such as Fiori applications, catalog & OData service). A wrong design will not only compromise the security but will also add to the ongoing cost of maintenance.
   2. Ensure that the SAP role design supports need-based access and aligns with any potential Segregation of Duties (‘SoD’) requirements.
   3. The SAP authorization design should be easy-to-maintain and easy-to-scale to meet future requirements.
   4. It should also be easy for business users to understand both from future access requests as well as user access review.
4. SoD compliance
   1. I have often seen SoD issues crop during post SAP implementation audits. At this point, it may already be too costly to address SoD risks.
   2. It is best to define SoD requirements as part of system function requirements discussions (hint – involve your internal auditors upfront in your SOD design) and address SoD in the initial SAP role design.
   3. It is also a good idea to define SoD compliance requirements in the user access management procedures upfront.
5. SAP vulnerabilities management
   1. SAP systems are exposed to multiple threats and attacks. These can be managed by avoiding misconfigurations and ensuring that security patches are implemented quickly.
   2. SAP testing should include system security assessments to ensure that SAP is configured securely. A check against the SAP system security standard/baseline should be performed.
   3. The SAP team should also ensure that all relevant security patches are implemented before the go-live.
6. Secure DevOps
   1. All SAP projects include some level of custom developments/enhancements.
   2. The organization should document secure programming standards for SAP developments/enhancement and a source code review should be in-built into the development process.
   3. SAP provides some built-in tools such as Code Inspector and ABAP Test Cockpit (ATC) to test the custom codes. Some organizations prefer to use more specialised tools to enforce the code security.
   4. It is also best to plan for secure SAP operations before the system is switched to production use. This should include procedures for change management, security patching, and security monitoring.
   5. While many organizations have existing SIEM or SOC solutions, they generally lack the ability to monitor the SAP systems. Organizations should consider using automated tools for SAP threat detection and monitoring and integrating it with the organization wide SIEM/ SOC solution.

I understand that many organizations may find that list quite daunting. However, it is always a good idea to conduct a risk assessment and then prioritise these based on your risk perception. Even where it is not possible to take immediate steps to address the risks, it is best to build a solution that can scale up and incorporate required controls in future.

With a good plan and clear direction, these security controls can be easily built into the SAP S/4 transformation program. This will ensure that the SAP system is ‘secure by design’.

I will be more than happy to have one-to-one discussion to understand your individual challenges, and help you come up with a tailored approach. Please feel free to contact me for a detailed discussion: barun.kumar@turnkeyconsulting.com