What I have learnt from my recent SAP cybersecurity engagements

While a pre-implementation security acceptance test has been a common feature of any large system implementation, it has often been ignored in cases of SAP implementations. This is mostly due to the complex SAP implementation projects, which can often take more than a year. This means that the project team is no longer available when security vulnerabilities/issues start to unravel a few months after go-live. End result - there is no one to own and fix up these security vulnerabilities/issues!

I have been involved in pre-implementation system security testing for many large SAP projects. In this blog, I want to share my experiences, which should be helpful for organizations currently undergoing SAP implementation and wondering how and when they should address security aspects in their project.

This is not an exhaustive list and definitely not based on a large data set. However, based on my discussions with many experts in this area, I suspect this is true for most SAP implementation projects.

So, here are my top ten learnings: 

1. First of all, senior management involvement is a must. SAP security should be a topic for the steering committee and not delegated to the project team.
2. SAP security testing is not just about testing user access or SoD conflicts. While excessive and conflicting user access is a common issue, these are not the only security challenges in an SAP implementation.
3. SAP system hardening is very important. Organizations have security standards/baselines for most of their technologies including operating systems, databases, firewalls, web servers, etc. However, not many have a defined security hardening standard for their SAP technologies (such as NetWeaver Application Server (‘AS’), HANA database, SAProuter, etc). Remember, a large number of security vulnerabilities can be addressed by avoiding system misconfigurations.
4. SAP security cannot be decoupled from the infrastructure security. Network segregation of SAP systems, hardening of SAP servers, and securing communication protocols are as important as securing the SAP system itself. Therefore, SAP security testing should cover the entire SAP system network and not just the application layer.
5. SAP Production (‘PRD’) systems are not isolated from Development (‘DEV’) and Quality Assurance (‘QA’) systems. Do not exclude SAP DEV and QA systems from security testing. Privilege escalation exploits often work through system hopping from less secure DEV/ QA systems to more secure PRD systems.
6. Organizations are generally surprised with the large number of security vulnerabilities identified by SAP security testing, and they are often not prepared for it. Plan sufficient time to address security vulnerabilities identified.
7. SAP releases monthly security patches. Given the typical duration of SAP implementation projects, it means that a large number of security patches will be missing at the time you go live. It is important that the project team monitors and apply security patches, even before you 'go live'.
8. A typical SAP project includes multiple SAP systems (such as S/4 HANA, Fiori, Solution Manager) and each of these SAP systems have multiple environments (DEV, QA and PRD). Securing and monitoring so many SAP systems manually is a challenge. Organizations should consider implementing automated SAP security monitoring systems early in the project.
9. Code quality is another key source of security vulnerability and most SAP projects have a large number of custom codes. While code security vulnerability testing should be part of SAP security testing, you should focus on enforcing a secure 'code lifecycle management'. This typically should include documented secure coding guidelines, training for programmers as well as checking security vulnerabilities as part of the development process.
10. Finally, there is never a right time to conduct security testing. That is, if you listen to the project team! Security testing is usually not scheduled in the project timeline. When the question of security testing is raised, the project team often use ‘lack of time’ to justify pushing security testing after go-live. Remember, a little delay is better than going live with an insecure SAP system. Security testing should always be performed before the system goes for User Acceptance Test (‘UAT’).

Good planning is essential to ensure ongoing security of your organization’s most valuable IT asset. It is cheapest and most efficient to address security aspects as early as possible in the project.