Integrated Risk Management
Through the application of technology and automation, we'll help you manage your risks efficiently and effectively across the entire enterprise.
Identity and Access Management
We'll help you ensure everybody within your organisation has access to the right systems and data, for the right reasons, and at the right time.
Cyber & Application Security
Our experts will uncover security weaknesses within your security design and business-critical applications. Helping you protect your organisation from both internal and external threats.
Bedrock Managed Service
Scalable support and on-demand expertise that seamlessly integrates with your existing operations.
About us
A group of passionate individuals with a shared purpose to help the world's leading companies embrace best practices for GRC and risk management.
Partners
Turnkey's strategic partner network consists of selected organisations that complement our capabilities.
Corporate Social ResponsibilityCSR
We are committed to being agents for change through our Climate Action Plan, championing diversity in our workplaces, and more.
Get in touch
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Careers
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Webinars & eBooks
All of Turnkey's webinars, guides and other insights available in one place.
Blogs
Read the latest insights from our experts on GRC and risk management, covering the latest industry topics.
Press Coverage
See all the publications where Turnkey, our experts and our successes have been noted.
Key events
See the key industry conferences on GRC, SAP security and risk management which we are attending.
Case Studies
Client satisfaction is of the utmost importance to us, and we strive to constantly deliver above expectations, going the extra mile at every opportunity.
18 August 2020

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.