ERP Migrations: Creating New GRC Exposure and Upgrade Hazards

Scott Goolik, Symmetry

Scott Goolik, Symmetry


By Scott Goolik Symmetry

Vice President of Compliance and Security Services

As anyone with an iPhone or Windows PC understands, when Apple or Microsoft issue a new software update, apps and functions that worked fine before suddenly experience degraded performance or simply do not work at all.

There is a parallel for enterprises today as they move to upgrade and migrate to the latest enterprise resource planning (ERP) software from companies like SAP and Oracle. These comprehensive software platforms act like the ‘heart and lungs’ for these companies, managing everything from the supply chain and logistics through to HR and financials.

A key part of ERP software is governance, risk and compliance (GRC) controls, in particular Segregation of Duties (SoD), which are designed to safeguard businesses, investors and customers alike.

At their primary layer, SoD and other access control measures provide checks and balances to prevent careless processes from exposing a business to risks. Taking it a step deeper, these access control measures are carefully designed, systematic rules implemented to keep people from defrauding an organization.

Businesses today count on GRC solutions for their ERP software as an operational necessity — much like encryption or security monitoring. Like these controls, GRC can blend seamlessly into an enterprise and with automation doesn’t have to restrict or slow down daily operations. In fact, without creating additional work for administrators, a system can effectively and automatically check every task employees do in their ERP software.

However, this streamlined process can be disrupted when new functionality is introduced into a system, just like an iPhone or Windows PC update. A good example of this upgrade hazard comes from SAP, one of the main ERP providers with more than 365,000 customers in 180 countries.

SAP Fiori is a new role-based, simplified and personalized user experience interface for SAP. Because SAP’s GRC software is designed around its legacy user interface, the introduction of SAP Fiori can create false negatives around an enterprise’s SoD conflicts.

So how can a business ensure its SAP Fiori solution for access control isn’t missing or mislabeling SoD issues? In the traditional SAP interface, users perform tasks through transactions by selecting them from the menu or entering the transaction code as a shortcut.

SAP’s GRC software then checks these transactions against a list of SoD conflicts to catch combinations of actions that could lead to fraudulent actions. For example, if a user can both create and pay vendors, they could abuse their access power by creating a fictitious vendor to begin funneling money out of the company.

A less extreme example involves flagging authorization risks that circumvent business processes — for example, ensuring managers can’t sign off on their own work. SoD checks are critical in catching these discrepancies for organizations. SAP Fiori, however, functions through service authorizations instead of transaction authorizations. If a user is performing similar tasks like creating or paying a vendor, a transaction start authorization isn’t necessary.

This ultimately means that most SAP GRC solutions can’t monitor for SoD conflicts within Fiori apps, which increases an enterprise’s exposure to fraud. To accurately analyze SoD conflicts and maintain compliance in this SAP example, a GRC solution must check both transaction start authorizations as well as service authorizations.

Within this analysis, a company’s service authorizations will output hash value character codes that correspond to services. To properly interpret these outputs, a company’s GRC team needs to add these codes to its rulebook, essentially creating an ad-hoc SAP Fiori solution for access control.

This can prove challenging because hash values can be system-specific and difficult to connect to the underlying services. Also, manually recreating a complex set of SAP GUI checks in Fiori introduces the opportunity for dangerous errors or inconsistencies — ultimately making maintaining GRC more difficult in the long run.

To close the emerging gap in access controls in this example, businesses need a GRC solution with an included ruleset designed to work across both Fiori and SAP GUI.

This way you can eliminate false negatives, inconsistent security rules, and complex maintenance requirements while protecting the business and ensuring compliance.

As IT departments continue to upgrade software platforms and migrate them to hybrid infrastructures, it is critical for corporate GRC teams to ensure that any upgrades or migrations of ERP or other important software do not create new holes in their SoD processes and expose the company to increased fraud.

Scott Goolik is vice president of Compliance and Security Services at Symmetry. A recognized expert in the field of SAP security and compliance, Scott has over 20 years of expertise in SAP security and is a regular presenter at SAP industry tradeshows and ASUG events.