informa
/
Cloud
Commentary

My Journey Toward SAP Security

When applications are critical to the business's core functions, the CISO and their staff better get the security right.

It was just a few years ago that I first got religion on SAP cybersecurity. I was serving as Chief Information Security Officer (CISO) for a large retailer. The company had begun migrating from various technology solutions into an SAP environment. As CISO, I had the accountability of ensuring all technology implementations were secure and resilient. What initially caught my attention with this project was the criticality of the SAP applications to the core functions of the business. If SAP was disrupted, the business impact could be catastrophic.

The project documentation identified that going forward, the company would leverage SAP applications to manage the company's supply-chain, product inventory, financial reporting, and it would have B2B connections to third parties for the support of these critical business functions. Naturally, this got my attention, and I knew that if I failed to create a strong security and governance process around these SAP applications, I would be failing to secure the most critical business functions in the organization. 

Related Content:

8 Reasons Perimeter Security Alone Won't Protect Your Crown Jewels

The Threat from the Internet—and What Your Organization Can Do About It

New on The Edge: Don't Fall for It! Defending Against Deepfakes

Every company uniquely does business, and therefore every security leader has the challenge of understanding the specifics of the company's critical application landscape, so they can customize the security priorities and expenditures to protect their organization best. With this in mind, I had a new focus on securing SAP to secure the core business functions it supports.

I began looking at how other organizations secured their SAP applications, and I was surprised to see the antiquated security models still in use today by many companies. SAP provides a sophisticated ecosystem of applications built by SAP and SAP partners. These applications work harmoniously to enable and support critical business functions, much like those planned by my organization.

Additionally, SAP has its custom coding language, known as Advanced Business Application Programming, or ABAP, that provides powerful data manipulation and reporting capabilities. I would later find out that organizations typically have millions of lines of custom ABAP code, and that most code security tools do not review this custom code. My level of concern increased even more.

The processes and technologies we implement to secure technology are always evolving. Security capabilities adapt to keep pace with the ever-growing capabilities of threat actors. In security, we face an intelligent and dynamic adversary. New technology capabilities and older applications are often ripe for exploitation and must be continuously reviewed to ensure adequate security control and governance capabilities are in place. Traditional SAP security has not kept pace with the threats that are present today. 

Given the criticality of the business functions supported by SAP, the data within the application is of the highest sensitivity and importance. Much of this data is regulated by governments to ensure accurate financial reporting is in place, and that personally identifying information is protected. In response to these regulations, the traditional model of securing SAP applications consists mostly of engineering user authorizations to ensure there are no toxic combinations, where a single person could leverage permissions within the application to violate the regulatory requirements.

The SAP environment is typically audited to ensure adequate separation of duties and financial controls both by internal and external auditors. While this is a critical practice to maintain for user ID security, if that is the extent of the security focus applied to SAP, then I found it to be severely lacking. My observation, given the complexity of the applications, customizations, and the current capabilities of threat actors, is that today a more robust approach to securing SAP is required.

The realization that traditional user-ID focused security is insufficient isn't ground-breaking news. Threat actors have already figured this out, and the evidence of increased breaches of SAP applications demonstrates that reality. Threat actors frequently exploit unpatched and misconfigured applications, and they can also leverage the ABAP code capabilities to breach systems.

However, given the proprietary nature of the SAP ecosystem, traditional security controls often cannot be leveraged to avoid or even detect these breaches. Security for SAP applications was a challenge, and I knew I needed help to address this. Fortunately, I found a vendor in the SAP business-critical application space that offered up a free risk assessment of my SAP systems. I then arranged for an SAP security expert to attempt to breach my system, and I learned a few lessons quickly.

With little effort, my company's SAP implementation was breached in less than 60 seconds, and the security expert gained full control of the system. I want to tell you I was surprised by this, but I was not. I had anticipated it for the reasons I mentioned already – the traditional security approach did not account for configuration, application patching, and custom code security. What did stand out to me, however, is that none of my existing security controls identified the breach. My company had implemented many advanced security controls, and we had a highly talented security operations center team constantly surveilling threats in the business. The unfortunate reality was that when my SAP system was breached, no one noticed. No logs were generated. No one was alerted. There was nothing in place to prevent this threat or even to detect it. 

The threat actor, an SAP security expert in this case, had full control of our SAP system, and from there was able to perform a variety of destructive actions to the business, including disabling some or all of the critical business functions SAP enables, and initiating other fraudulent activities. One does not need to use a lot of imagination to see the more subtle advanced persistent threat and espionage possibilities as well.

Based on the experience and information gathered, I was able to build a business case around my concern which resonated with other company executives and board members. My budget to secure SAP was approved, and the next phase of the journey began. As I mentioned, SAP applications are complex, and securing them takes time. Because of our decisive actions, we were able to build a meaningful security approach. 

Recommended Reading:
Editors' Choice
Kirsten Powell, Senior Manager for Security & Risk Management at Adobe
Joshua Goldfarb, Director of Product Management at F5