The implementation approach for S/4 Hana is very flexible; depending on the organisation and its current situation, starting points may vary. Each of these has a different security and remediation exposure but broadly there are three distinct groups.
The first are those customers that go straight to S/4 Hana, having not previously run SAP. As a ‘greenfield’ implementation, the organisation has many configuration options available to it, but will often need to place significant trust in available accelerators from its partners as well as SAP as the software vendor.
The second group are those running SAP ECC (ERP Central Component) that want to ‘lift’ their current environment into S/4 – therefore opting for a migration. As such, many of the relevant design 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.
Thirdly there is the group that are 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.
The five most common S/4 Hana security and remediation challenges
Despite there being a different starting point for security considerations, these groups potentially face a common set of security challenges as follows.
1. SAP standard roles may contain critical access and SoD risks
SAP delivers over 170 ‘best practice’ standard roles in S/4 Hana. Given they are standard and not unique to each organisation, 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.
If these roles are not split out and segregated into several other technical roles, and the underlying risks are not addressed, the organisation’s entire S/4 Hana environment may be put 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 SoD or sensitive access risks; instead people will have much greater access than they should. 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, intended to improve the customer user experience by providing a consistent and simple look and feel for SAP activities, complicates this further. 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.
This conflicts directly with access restrictions that may be in place in the actual S/4 core; users may think they can undertake actions that they may not be able to complete, as well as potentially having 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 redesigns will cause role designs to change
Most existing SAP customers moving from SAP ECC to the new digital platform will want to take the opportunity to redesign at least some of their business processes – and this will also impact the way roles need to be designed.
It would be a mistake to shortcut the role redesign process by trying to lift what is already there, especially if the new processes will be fundamentally different. So ensuring the role design supports the 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-sheet applications that reside on the Hana databases for example, 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. Identifying S/4 Hana access risks and SoDs requires the right tools
With S/4 Hana, building roles is conceptually the same, with no context of access risks during the build process itself. If there are no tools to identify the access risks, then an organisation won’t know a risk exists until it is picked up 12 to 18 months later, following an audit.
But a significant amount of damage could be done in that period.
If users are assigned more and more access, which contains many SoDs and sensitive access risks, then a bigger and bigger headache is created – one that will result in a lot of remediation work following the audit. By ensuring roles are clean from the very start, this scenario will be avoided and any remediation kept to a minimum.
4. Process owners may not know how clean their roles are
It’s highly unlikely that the process owners for the different functions across the S/4 environment will all 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, there is a danger it could unwittingly be lifted across to the new environment. Organisations will then be stuck in the same trap of assigning more and more access to people and again compounding the problem, which will eventually need to be remediated.
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 the new S/4 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 doesn’t go far enough; it also provides a poor (business) user experience.
Traditional implementations indicate 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 S/4 Hana projects, with security viewed as a non-functional requirement or as a non-event entirely.
At some point, 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 the enterprise needs to be protected from risks that may occur. With data one of an organisation’s 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 a way to analyse and validate the suitability of these standard roles to spot where risks might exist needs to be found. But in an ideal world, the right level of expertise needs to be involved from the very start of an S/4 Hana transformation to design roles in the right way.
It’s likely that existing SAP customers will be impacted more by a move to S/4, especially those looking to migrate from SAP ECC. But whatever the starting point, the advice above is applicable to any organisation implementing SAP’s new platform. In summary, putting the right amount of effort into good role design and access management at the beginning of a project avoids a much bigger remediation challenge 12 to 18 months later.
Add Comment