The Utilities Guide to SAP RISE: Navigating Shared Responsibility and Security
Electric utilities operate in a highly regulated physical domain. As organizations like Oklahoma Gas and Electric (OG&E) modernize their enterprise resource planning environments, executing a secure RISE with SAP business transformation requires a fundamental shift in defensive strategy.
Defending the enterprise core requires security leaders to understand that migrating to a hyperscaler does not eliminate organizational risk. It simply changes the battlefield. For a deeper technical breakdown, watch the full webinar on security and compliance in the shared responsibility model with OG&E and Onapsis.
What is the Shared Responsibility Model in SAP RISE?
The SAP RISE shared responsibility model dictates that SAP manages the underlying cloud infrastructure, but the customer retains absolute accountability for application security, data protection, and regulatory compliance.
While the term implies a partnership, it does not equate to shared accountability. If a utility experiences a breach within its SAP environment, regulators and customers will hold the utility strictly responsible regardless of SAP’s infrastructure management.
Security leaders must recognize that they can no longer rely on traditional network-level controls when navigating the SAP shared responsibility model for cloud security. SAP dictates that securing anything beyond the infrastructure layer falls firmly on the customer’s shoulders.
Why Do Utilities Treat SAP Like Operational Technology (OT)?
Utilities treat SAP like Operational Technology because these environments prioritize extreme uptime, operate on legacy lifecycles, and require highly specialized talent to secure and maintain.
Much like physical power plants or transmission systems, SAP environments are characterized by specific constraints:
- Decade-Long Lifespans: Systems remain in place for ten to twenty years with a significant resistance to architectural change.
- Niche Expertise: Managing these environments requires deeply specialized personnel who understand proprietary protocols, making external talent expensive and difficult to source.
- Operational Fragility: Applying patches or introducing new security tools creates widespread internal fear of disrupting critical grid operations, supply chain logistics, or ratepayer billing.
By treating the ERP as the “OT of the business,” utility security teams can successfully apply passive and highly tested tools that fail safely without bringing down the core production environment.
How Does SAP RISE Change Security Visibility?
Moving to SAP RISE eliminates traditional network-level visibility, forcing security operations centers (SOC) to implement application-centric threat detection and response capabilities to detect malicious activity.
In legacy on-premises deployments, security teams could inspect packet-level traffic and rely on physical data center firewalls that mirror SCADA network segmentation. SAP RISE encapsulates the environment, removing direct access to underlying hypervisor or infrastructure logs.
Furthermore, traditional SOC teams are generally blind to SAP’s proprietary logs, transaction codes, and terminology. Organizations must utilize dedicated SAP threat detection software to act as a translator, converting complex and anomalous SAP events into actionable threat intelligence for standard SOC analysts defending critical infrastructure.
Why is Clean Code More Critical Than a Clean Core?
Clean code is more critical than a clean core because shifting vulnerable custom applications to SAP BTP merely relocates the exploitation risk rather than eliminating it.
SAP heavily advocates for a “Clean Core” methodology, encouraging customers to push custom extensions into the Business Technology Platform (BTP). However, relocating poorly written ABAP or Java code does not actually secure the environment.
Threat actors, including nation-states targeting the energy sector, currently operate under the cyber persistence theory, a domain of constant contact where adversaries mass-scan for misconfigurations and generate functional exploits in hours. Eliminating opportunities for exploitation requires a mature SAP DevSecOps program to ensure that every line of custom code is free of critical vulnerabilities before it is deployed.
How to Secure the Transition to SAP RISE
Establishing cyber resilience for RISE with SAP requires implementing rigorous code scanning, continuous application monitoring, and demanding explicit security visibility before contract execution.
Utility companies must use this migration as an opportunity to redefine legacy processes, as you cannot securely retrofit a cloud environment after the fact.
Prerequisites
- Executive alignment on the reality of cloud accountability for critical infrastructure.
- A pending or active SAP RISE migration contract.
- Deployment of a centralized vulnerability management platform tailored for SAP and utility frameworks.
Step-by-Step Actions
- Negotiate Security Add-Ons Early: Demand the inclusion of all necessary SAP security add-ons before signing the RISE contract. Negotiating power completely evaporates after execution.
- Deploy DevSecOps Gates: Integrate automated SAP application security testing software directly into the development pipeline. Stop insecure code from entering the production environment to establish a clean baseline.
- Implement Application Threat Hunting: Use advanced investigative solutions to emulate adversary tactics, techniques, and procedures (TTPs). Hunt for indicators of compromise within the SAP application layer and tune security controls based on active threat intelligence targeting the energy sector.
- Automate Compliance Audits: Map automated platform alerts to specific SOX, NERC CIP, or regional regulatory controls. Provide external auditors with continuous reporting via automated SAP compliance software to satisfy relentless audit cycles without manual data extraction.
Verification
Execute an adversary emulation exercise against the RISE environment using real-world threat intelligence. Verify that the specialized SAP security tools successfully detect the application-layer intrusion, translate the alert accurately for the SOC, and provide the necessary data to tune the controls without disrupting core utility operations or power delivery.
Frequently Asked Questions
What is the difference between shared responsibility and shared accountability in SAP RISE?
The shared responsibility model means SAP manages the cloud infrastructure, but the customer retains full accountability for application security, data protection, and compliance. If a utility experiences a cyberattack or data breach, regulatory bodies like NERC and state public utility commissions will hold the utility strictly responsible, regardless of SAP’s role in managing the hypervisor or servers.
Why do electric utilities treat their SAP environments like operational technology (OT)?
Utilities treat SAP like operational technology because these systems prioritize extreme uptime, operate on decade-long lifespans, and require deeply specialized talent to maintain. Much like a physical power plant, applying rapid patches or introducing untested security tools to the enterprise resource planning (ERP) system creates internal fear of disrupting critical grid operations, supply chains, or ratepayer billing.
Why are traditional security operations centers (SOC) often blind to SAP RISE threats?
Traditional SOC teams are blind to SAP RISE threats because the cloud migration removes network-level visibility and analysts generally do not understand proprietary SAP transaction codes or logs. Utility organizations must adopt application-centric monitoring and utilize specialized threat detection platforms to translate anomalous SAP events into actionable intelligence for standard SOC analysts defending the grid.
Does the SAP Clean Core methodology eliminate custom code vulnerabilities?
The SAP Clean Core methodology does not eliminate vulnerabilities; it simply relocates the exploitation risk to the SAP Business Technology Platform (BTP). To truly secure the enterprise environment, utilities must focus on clean code by embedding automated application security testing into the DevSecOps pipeline to catch insecure programming patterns before they reach production.