Given the significant investment and commitment required by an organisation to roll-out SAP S/4 HANA, the need to ensure the new environment is clean and secure from day one is paramount. That way you will lessen, if not completely bypass, the need for costly remediation at a later point.
The implementation approach for S/4 HANA is very flexible and so depending on your organisation and its current situation, you may commence your implementation from a different starting point. Each of these has a different security exposure but broadly, we see three distinct groups.
The first are those customers who go straight to SAP S/4 HANA, when they previously haven't been running SAP. As a “greenfield” implementation, the customer has many configuration options available to them but will often need to place significant trust in available accelerators from their partners and from SAP as the software vendor. The second group are those who are running SAP ECC and want to ‘lift’ their current environment into SAP S/4 HANA - therefore opting for a migration. As such, many of the design relevant decisions should already have been made, including the fundamental security design. There may be the opportunity to trust existing solutions in part and focus on the changes to that as part of the implementation. The third group are those existing SAP ECC customers who feel the best approach would be to start over - redesigning the underlying business processes, and implementing the new platform from scratch.
Despite there being a different starting point for security considerations, these groups potentially face a common set of security challenges, which we’ll explore in this post.
The 5 most common challenges of SAP S/4 HANA security:
1. SAP designed over 170 standard roles that may contain critical access and SoD risks
SAP delivers over 170 “best practice” standard roles in SAP S/4 HANA. Given they are standard and not unique to each business, it’s highly likely that they will need to cater for the lowest common denominator of business process. Therefore, they are likely to have significant sensitive access and Segregation of Duties (SoD) risks given the wide, comprehensive access to applications and underlying authorisations. So, if you don't split out and segregate those roles into several other technical roles, and you don't address the underlying risks, you maybe putting your entire SAP S/4 HANA environment in a precarious position right from the outset.
Many SAP customers are advised to adapt their current standard roles to the 170 new roles and assign them accordingly. But this won’t address your SOD or sensitive access risks, and instead you’ll have people with much greater access than they should have. SAP are not going to know how many individuals will work on specific processes or how the business teams will be structured and therefore it will be impractical of them to split each and every role down to the required steps in a template process.
The use of the SAP Fiori user interface complicates this further. Fiori is intended to improve the customer user experience by providing a consistent and simple look and feel for SAP activities. Many implementers take the view that since Fiori is just an end-user portal intended to access their functions, there is no need to limit the authorisations in this layer. That directly conflicts with access restrictions that may be in place in the actual S/4 core. This then means that users will think they can do actions that they may not be able to complete and also may have a more complex view of application tiles in their portals which either error immediately or are unnecessary for their job. In addition, maintenance of a user’s Fiori application assignment also needs to be considered from a joiners, movers and leavers process to retain that consistency throughout the employee lifecycle.
2. Business process re-designs will cause role designs to change
For existing SAP customers moving from SAP ECC to the new digital platform, most will want to take the opportunity to redesign at least some of their business processes - and this will impact the way roles need to be designed too.
It would be a mistake to shortcut the role redesign process by trying to lift what you already have, especially if your new processes will be fundamentally different. So ensuring the role design supports your new processes will eliminate the need for remediation in this area further down the line. In some cases, the new business processes will be mandated through technical changes to the underlying solutions. This might introduce Fiori based fact-sheets applications that reside on the HANA databases or may be due to different technical changes to the data model (transactions or tables removed/replaced) meaning that some important activities in the business are fundamentally amended.
3. Unable to identify or remediate SAP S/4 HANA access risks and SoDs without the right tools
With SAP S/4 HANA building roles, is conceptually the same, with no context of access risks during the actual build process itself. So, if you don't have the tools to identify your access risks, then you won’t know a risk exists until it is picked up 12 to 18 months later, following an audit.
But just imagine how much damage could be done in that period.
If your users are assigned more and more access, which contains many SoDs and Sensitive Access risks, then you’re creating a bigger and bigger headache - and it will result in a lot of remediation work following your audit. By ensuring your roles are clean from the very start, you will avoid this scenario and keep any remediation to a minimum.
4. Process owners do not have full understanding of SAP ECC access to benchmark SAP S/4 HANA design
It’s highly unlikely that all of your process owners for the different functions across your SAP S/4 HANA environment, will have a full understanding of the access that's been granted to other users from the previous SAP ECC system. This means they won't know how clean their roles are.
So, if a hidden SoD risk already exists in SAP ECC, the danger is you could lift this across to your new environment unwittingly. You’ll then be stuck in the same trap of assigning more and more access to people and again compounding the problem, which eventually you're going to need to remediate.
5. Limited knowledge or expertise to recommend appropriate role designs or controls
It’s clear that SAP’s standard roles are being recommended for deployment as an adequate measure to secure your new SAP S/4 HANA environment. In addition, at the presentation layer (SAP Fiori), users are sometimes given access to all Fiori applications, in the hope that the backend roles and authorisations will prevent an application from being accessed. For most companies, this just won’t go far enough and provides a dreadful user experience for business users.
We have seen from traditional implementations that some SAP customers have not recognised the importance of embedding security and controls at the heart of their projects. This is the fundamental cause of many remediation projects. It is likely that functionality is being prioritised within SAP S/4 HANA projects, with security viewed as a non-functional requirement or as a non-event entirely.
Remember, at some point, your users will need to log in to this new environment and at that time, security and control will become vital. ‘Security’, because users will need to use the functionality being deployed - and ‘Control’, because you need to protect the enterprise from risks that may occur. With data as one of your organisations most critical assets, it would be an ill-advised approach not to factor in strategies to protect it from the outset.
At the very least you need to find some way to analyse and validate the suitability of these standard roles to spot where risks might exist. But in an ideal world, you need the right level of expertise involved from the very start of your SAP S/4 HANA transformation to design your roles in the right way.
It’s likely that existing SAP customers will be impacted more by a move to SAP S/4 HANA, especially if you are looking to migrate from SAP ECC. But whatever your starting point, the advice provided in this blog is applicable to any organisation implementing SAP’s new platform. Put the right amount of effort into good role design and access management at the beginning of your project, and avoid facing a much bigger remediation challenge 12 to 18 months later.
If you have any comments or questions, please feel free to use the comment submission below, or see how Turnkey’s SAP security services can help your business.
