SAP S/4HANA: 5 Ways to Build In Security From the Start

Originally published by Onapsis here.

Many SAP customers are currently at the point of either planning or executing a transformation to SAP’s next generation ERP, S/4HANA. More than 18,800 companies[1] have adopted SAP S/4HANA and thousands more are in the process of migrating to the new platform, with the deadline approaching in 2027. This marks when SAP will officially end its support of legacy versions, such as SAP ECC and SAP R/3, including no longer releasing security patches. Organizations must upgrade to SAP S/4HANA before this deadline to avoid the risk of their most business-critical operations running on outdated and un-patched software.

While migrating to SAP S/4HANA offers many benefits, it also comes with increased complexity. There are many things to consider for this major digital transformation project and security should be a top priority for organizations.

The Importance of Security in SAP S/4HANA Migrations

SAP systems are responsible for running the enterprise, powering operations and fueling the global economy. Considering 77% of the world’s transactional revenue touches an SAP system and 92% of the Forbes Global 2000 uses SAP, a successful attack on unprotected SAP applications could have far-reaching consequences. The U.S. Department of Homeland Security has issued six alerts to date about cyber attacks targeting mission-critical enterprise systems, including SAP. Last April, SAP and Onapsis released research finding more than 300 confirmed exploitations of unprotected SAP applications, including more than 100 hands-on attacks on organizations in less than a year. Among the compromised data included sales, HR, customer PII, engineering, intellectual property and financial information.

Many organizations still find it difficult to monitor, detect, and prevent attacks at the application level. A 2021 Ponemon study reveals that most large enterprise organizations feel that their portfolio of applications has become more vulnerable, with many practitioners saying much more needs to be done to protect organizations at the enterprise application level: 57% can’t quickly identify vulnerabilities and 63% can’t monitor and prevent attacks[2]. On top of that, almost two-thirds of organizations have a backlog of security vulnerabilities[3]. It’s important to patch promptly because threat actors are also keeping an eye on patch releases. Our threat intelligence found critical SAP vulnerabilities being weaponized less than 72 hours after the patch was released.

Given the evolving business application threat landscape and the growing knowledge of threat actors, organizations must build security into the start of transformation projects and application development to uncover and address security issues. The potential business impacts to neglecting SAP security at the application level are too great to ignore:

• Exfiltration of sensitive or confidential corporate information, user credentials and personal information
• Fraudulent transactions and financial harm
• Downtime and project delays
• A deficiency in IT controls for data privacy (e.g., GDPR), financial reporting (e.g., SOX), or industry-specific regulations (e.g., PCI-DSS)
• Brand and reputational damage affecting relationships with customers, shareholders and regulators

Including security at the beginning of a transformation project, also known as shifting left, brings in security validation at the moment when code is created instead of at the moment when code is deployed or tested. This means enterprises can prevent those risks from becoming a reality or prevent those risks from leaving the development environment so they don't materialize in production.

Best Practices for Securing an SAP S/4HANA Migration

Given the growing risk of breaches to ERP systems, enterprises need an effective way to safeguard their assets across all functions as they transition to SAP S/4HANA. By enabling security to be built in from the start, organizations can avoid security-related roadblocks and delays to help bring projects in on time and on budget. Below are five actions organizations can take to ensure a secure SAP S/4HANA migration:

Find and fix legacy issues

It is ideal for organizations to address custom code, vulnerabilities, and compliance issues in their legacy systems before the migration. This way, the organization can be confident that their applications are as secure as possible before they move to the new environment and that they are maintaining compliance throughout the project.

Many organizations have been using SAP technology for decades, creating millions of lines of custom code through the years. While it’s likely that not all legacy applications will be migrated, for those that are, this is a great opportunity to analyze the underlying custom code. Chances are, when some of that code was written, security wasn’t top of mind. Today, secure code needs to be a priority. This process will ensure that poor, unnecessary, or outdated code isn’t brought into the new SAP S/4HANA environment.

Security by design

A security-by-design approach is essential to eliminating blindspots and keeping an organization’s business-critical applications secure, available, and compliant. Organizations should establish security and compliance technology baselines and tooling requirements at the start of the SAP S/4HANA migration project. This means secure code, configurations, and other processes can be incorporated throughout development and carried through to production. This type of approach significantly streamlines transformation and migration and can help projects finish on time and on budget.

Trust, but verify

Many organizations don’t have the internal resources they need to handle the SAP S/4HANA transformation project themselves, so they bring in a system integrator or third-party developers to help. These third parties could be responsible for writing custom code, setting up the environment, ongoing management (e.g., patching), and more. Organizations need to ensure they are validating this outsourced to ensure security best practices are being followed and that risk is not being introduced to their critical systems.

Another third-party angle to consider is what other systems, partners, and vendors might be connecting to the new environment. Organizations should ensure that these third parties have appropriate privileges and authorizations assigned. A partner, vendor, or other third party with broad access permission can open the entire business to risk. Securing access and authentication to these applications should be the first step in this process. It is critical to start with an assessment of all privileges, access rights, users, and roles. This should be done for employees as well as third-party users.

Automate security assessments where you can

To say there are many components to keep in mind when migrating applications to S/4HANA is an understatement. Legacy custom code, newly written custom code, transports, user authorizations and roles, IT general controls, patching process are just a few. Manually reviewing each of these components is not only impractical in terms of the resources and time you would need, but also ineffective. Manual reviews are prone to human error and there’s a high risk that critical issues could go unnoticed.

This is another reason it’s important to consider security at the start of the project. Selecting the right security assessment tools–those that are designed for SAP development and vulnerability management processes–means organizations don’t have to rely on manual reviews throughout the transformation project. This saves time, frees up resources to focus on core competencies, and decreases the chances of missing issues.

Continue to maintain SAP S/4HANA security and compliance

Once the migration process is over, the job isn’t done. Now, organizations need to make sure security issues and additional risk isn’t introduced to their new S/4 systems. This means continuing to use secure development processes with custom code and transport analysis, staying on top of new SAP Security Notes, regularly performing vulnerability scans, and validating IT general controls.

References

1. The True State of S/4HANA in 2022

2. Reducing Enterprise Application Security Risks: More Work Needs to Be Done

3. The Third Annual Study on the State of Endpoint Security Risk Ponemon Institute LLC Publication Date: January 2020