As any current or former employee at a utilities company can attest, there are nuances to systems and applications used to run the business. This applies whether it’s a power company, gas company, water company, waste treatment company or any other utility. Utilities companies that run SAP are no exception, as they very likely leverage SAP’s Industry Specific – Utilities (IS-U) product to support industry-specific processes like meter reading, meter data management, customer care, contract accounting, billing/invoicing and more. It’s also likely that these companies in today’s digital age have increased the use of mobile technology like SAP Fiori for their field workforce and almost certainly must connect their SAP environment(s) with third-party integrations to deliver end-to-end solutions for both their customers and business stakeholders.
The net result of these system and architecture nuances is that companies need to understand how their risk posture is impacted and, more specifically, how the logical access in their SAP environment needs to be handled from a security design and SAP GRC perspective to minimize those risks and significant downstream efforts to address mishandled risks.
Tailoring SAP GRC Segregation of Duties (SOD) and Sensitive Access (SA) Ruleset
As mentioned, utilities companies that run SAP are very likely using SAP’s IS-U product. This is because some utilities-specific business processes are not natively covered by traditional core SAP ERP modules in SAP ERP Central Component (ECC) and SAP S/4HANA. For example, the sales and distribution (SD) module was built with “order to cash” in mind but does not adequately cover the “meter to cash” process more relevant to utilities, which includes subprocesses such as device management and customer service. Consequently, from a Segregation of Duties (SOD) and Sensitive Access (SA) SAP GRC ruleset standpoint, users must ensure that the appropriate business processes, functions, actions (transaction codes) and permissions (authorization objects/values) are properly defined to identify relevant access risks. Though SAP GRC does now come with an out-of-the-box IS-U ruleset, it should be validated and customized according to the organization’s business processes as parts of the ruleset may not be relevant or applicable.
Taking the device management process as an example, there are multiple subprocesses to consider such as meter reading, order processing, device creation and device removals. Within those subprocesses, relevant transactions and authorizations must be defined. For example, the ability to adjust device installation facts through ES31 is an important transaction within device management. In this case, ES31 must have its relevant authorization objects defined and its functions mapped. Just like a traditional SAP ERP ruleset, IS-U transactions must be appropriately designed to ensure not only an accurate ruleset, but more holistically, a compliance-relevant tool.
Consider the Impact of Elevated Fiori Usage
Utilities organizations leveraging SAP have many use cases for the SAP Fiori launchpad. The mobility component of SAP Fiori is critical for utilities organizations as they provide mobile-friendly access to field personnel while out on the job. SAP Fiori introduces some key security and GRC considerations, however, that must be accounted for when implementing SAP security designs. As discussed in a separate Protiviti blog, the decisions a customer makes around how Fiori is deployed can also make a big difference in how security design should be addressed. In any scenario, and as security technicians understand, the authorization concept for SAP Fiori is different with the reliance on OData Services rather than transaction codes (T-codes). For utility companies using any financially-relevant Fiori tiles, a study should be performed to: 1) assess where the access fits in the SAP GRC ruleset, and 2) identify which specific authorizations need to be added to positively identify access risks without false positive or negatives.
Considerations for Third-Party Integrations
Along with SAP Fiori, our experience is that utilities organizations leverage many bolt-on SAP modules, SAP cloud applications and third-party tools alongside SAP ECC, SAP S/4HANA and SAP IS-U. Some of these tools, such as SAP Geographical Enablement Framework, provide powerful dashboards for monitoring physical assets such as water lines or cables. Similar to Fiori, these bolt-on applications or third-party tools introduce many new security requirements into an implementation such as:
- How do these tools impact the non-dialog user design (i.e., system and service accounts)?
- What new transactions or Fiori apps are needed to enable these tools to work? Are they sensitive? How should they be mapped in the GRC ruleset?
- Is there sensitive data involved with these tools? How heavily does the access to the tool need to be restricted?
We have seen some third-party tools with specific requirements for the connection setup into the SAP environment as well as the end user security assigned for end users of the third-party tool. This complexity, alongside all the other considerations mentioned above, means utilities companies running SAP have their work cut out for them when it comes to security design and SoD.
Source: https://www.sap.com/products/geographical-enablement-framework.html
Wrap-up
Anyone reading this blog that has already been through this journey is likely nodding their head by this point. For anyone either going down this path soon or in the midst of some of the challenges associated with these risks, a fresh look at the SAP security design and SAP GRC ruleset are essentially mandatory activities. While it may be painful to address these issues now, we have all seen how costly and time-consuming these challenges become once they are verified as compliance concerns by internal or external auditors. Save time now and get ahead of these nuanced challenges.
To learn more about our SAP capabilities, contact us or visit Protiviti’s SAP consulting services.
