Planning Ahead for a Secure SAP S/4HANA Migration

If ever there was an area ripe for shifting security left of the deployment process in the enterprise world, enterprise resource planning (ERP) software is the most prime of candidates. Consisting of complex environments with lots of legacy code and the slimmest tolerances for downtime, ERP is typically protected by security controls bolted on after the fact, rather than built into the architecture from the get-go.

For many SAP shops, though, the next few years could be the perfect time to completely shift that dynamic. With SAP pushing customers hard to migrate away from Business Suite to S/4HANA, there's a huge opportunity for security teams to finally make some headway on baking security into SAP deployments rather than cobbling together controls as an afterthought. Organizations that play their cards right can use the migration process as a way to sanely rearchitect and bolster their ERP security controls. But it's going to take planning and early action from the security team.

Even with SAP caving a bit on the date for dropping Business Suite support, the timer is on for organizations to migrate to S/4HANA. The deadline is now 2027, which might seem like the distant future for many IT generalists. But in the world of mission-critical enterprise software, that's a shorter runway than some organizations may realize—especially when accounting for building security design into the early phases of the process.  

Which is why ERP security specialists recommend that organizations don't tarry in their planning for this migration. It's going to take time for all stakeholders—including the security team—to coordinate their approach.

"Given SAP has set a deadline for supporting traditional Business Suite applications, it's best you migrate as soon as possible in order to incorporate security and compliance as a way to mitigate costs and exposure," says JP Perez-Etchegoyen, CTO of ERP security firm Onapsis. 

Tackling migration ASAP will give teams more time to do the security groundwork on the front end of deployment, which will not only harden the platform but reduce ROI and disruption over the long term, as it will help teams avoid costly security remediation once the S/4HANA platform is in place.

According to a recent study by Turnkey Consulting, more than two-thirds of organizations admit that security wasn't given enough focus in their past SAP implementations and 80% admit that security findings are common during audits of these systems. What's more, due to the nature of ERP systems, fixing these findings is very disruptive to the business. The survey showed that 75% of respondents say security remediation of insecure SAP implementations has moderate to considerable impact on day-to-day operations of a business.

"Preventing and mitigating security issues is by far less expensive and less risky than being reactive and implementing fixes after the SAP Applications are production ready," says Perez-Etchegoyen. "This is especially important when we are talking about migration to SAP S/4HANA."

Code Cleanup

One of big difficulties is complexity of the SAP application ecosystem and the expanded threat exposures that comes with every integration and pieces of custom code built into an organization's unique deployment. One of the first early tasks organizations should be doing is working to cull unused code before migration.

"Customization in SAP code can lead to unwanted complexities if left unmanaged," Perez-Etchegoyen says. "Use this time to analyze custom SAP code to perform hygiene on unused code. This process will ensure that you are not bringing poor code and issues into your new SAP S/4HANA environment."

Additionally, organizations should be doing a lot of early work considering not only how they will secure the application layers of the system, but also the database layer, says Jonathan Haun, senior director of business intelligence and technology at SAP consulting firm Enowa, and author of SAP HANA 2.0 Security Guide.

"There are two distinct layers of security in an S/4HANA system. There is the traditional ABAP application server layers, but there is also a new SAP HANA database layer," Haun says. "One mistake I often find is that the security and BASIS team fail to properly implement a security model to govern and protect the SAP HANA database that operates the S/4HANA application."

As he explains, the potential for fraud and cybercrime is just as high in the database as in the applications layer, and furthermore the design of S/4HANA has shifted a lot of application processing to the database. However, traditional SAP security teams have little to no experience architecting security controls at the database level, and another factor further complicating matters is that there isn't a one-size-fits-all tool to cover all layers of an S/4HANA deployment, he says.

"There is no single tool that can help a security person manage all aspects of application layer and database layer security," he says. "On top of this, tools used to manage the application layer and database layers have evolved rapidly and have changed significantly in a short time frame. This places constraints on the availability of training and also creates a lot of confusion."

This means that it is going to take considerable effort, learning, and training for security stakeholders to come up to speed on the new SAP platform's architecture before they can lay the foundation for a secure migration.

Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register.