Top 3 CISO pitfalls to avoid for achieving NIS-2 compliance in SAP
Chapters
Share Article
The European Union updated the Network and Information Systems Directive (NIS-2) in January 2023, and the EU member states must incorporate it into their national law by October 2024. Looking at the calendar, CISOs from companies running SAP at the core of their business processes might be under pressure to ensure NIS-2 compliance for their SAP systems in a very short timeframe.
The NIS-2 directive foresees the CISO as the accountable role within the organization for running assessments to identify potential cybersecurity threats and vulnerabilities. Based on the findings, the CISO oversees the implementation of security controls to mitigate identified risks. Additionally, robust incident detection and response capabilities must be established to quickly detect and respond to cybersecurity incidents.
SAP application landscapes are comprehensive and complex environments that require automated tools to meet the compliance and governance requirements of NIS-2. Due to the time pressure, CISOs might run into pitfalls, which we aim to address in this article, along with recommendations to avoid them.
Here are the 3 most important pitfalls, and how to avoid them to ensure SAP compliant with NIS-2:
Pitfall #1: Only implementing SAP security monitoring
Quite often, we see CISO organizations refer to SAP Security as a synonym for monitoring the SAP Security Audit Log. This is notable because SAP basis teams often point to their colleagues responsible for managing SAP user authorizations when asked about their SAP Security posture, which did not cover all aspects of the topic. Therefore, CISOs cannot rely on this specific view of SAP Security from their SAP basis teams.
It seems this perspective comes from IT infrastructure security, where monitoring is by far the most important topic. This may be because, at the infrastructure level, it is all about communication between endpoints, issues with communication protocols, and the behavior of the endpoint’s operating system. While secure architecture and configuration of the infrastructure are critical, the focus is on identifying attack vectors and patterns. This should empower SOC teams to achieve fast threat detection and response.
However, SAP environments are more complex as they have their own communication architecture, user identity and access management, user authorization concept, source code management infrastructure, and specific methods for accessing and changing data.
Focusing solely on monitoring the SAP Security Audit Log to protect SAP systems against cyberattacks is not enough. Not only do SAP Security teams need additional logs and context information to identify and understand attack vectors, but they also need to continuously mitigate and fix vulnerabilities in SAP systems. These vulnerabilities are not just limited to system configurations. SAP releases monthly security patches for their own applications and SAP customers must also maintain and fix vulnerabilities in their custom SAP applications. These topics are essential for hardening SAP environments.
Without proper hardening, protecting SAP systems against cyberattacks is quite difficult, if not impossible. It’s like trying to defend a castle with many holes in its perimeter wall. If you only implement monitoring as part of your SAP Security posture, even less critical attack vectors will threaten your SAP system.
Recommendation: Build your SAP Security on 4 core security technologies
Therefore, a good SAP Security posture covers at least the following core topics:
- Threat Detection (monitoring of all security logs),
- Vulnerability Management, including not only secure system configurations but also
- Patch Management (SAP code security) and
- Custom Code Security.
The SecurityBridge Platform is designed to help you efficiently implement these 4 key areas in your organization. The preconfigured Threat Detection for SAP can be installed in a day to get an instant security shield around your SAP system. The Vulnerability Management module includes hundreds of checks to provide efficient system hardening. Additionally, streamline your Patch Management process and implement code security checks within your SAP custom development, ensuring comprehensive SAP security.
Pitfall #2: Connecting SAP Security Audit Log directly to SIEM
When focusing only on SAP security monitoring and fast implementation due to the lack of time and resources, CISOs might be tempted to take the shortcut and integrate (send) all SAP Security Audit Log records directly into their enterprise SIEM. However, this is the worst approach for the SAP Security posture for multiple reasons.
First reason: high operational cost. Many companies already have enterprise-level SIEM solutions that consolidate various security logs from network, infrastructure, and operating system levels. It may look like a cost-effective approach to use a connector and pull records from the SAP Security Audit Log, which is just a file on the OS level in most cases. Unfortunately, CISOs often underestimate the log volume in SAP environments, leading to high operational costs for SIEM solutions, as they are typically priced based on data volume. Since up to 90% of the SAP logs are usually filtered out, sending them to SIEM means paying for 100% data volume while using only 10%— not a good deal.
Second reason: lack of SAP knowledge in SOC teams. SIEM solutions are usually used by SOC (Security Operations Center) teams with a broad knowledge of securing IT environments. However, protecting SAP environments requires specific knowledge and expertise, typically owned by SAP Basis team members specialized in SAP Security. SAP administrators are the ones best equipped to respond effectively to threats.
Third reason: least efficient solutions. Even if we ignore the first two reasons, it is very cumbersome to create event filters for SAP Security logs. Even with specialized resources available, it still requires a huge implementation effort to get to a level where the SOC team can process decisions enabling events to act accordingly and provide swift threat response. Unfortunately, even AI-based approaches are ineffective at the current stage, as SIEM solutions still operate based on an infrastructure and OS data model. They require an SAP data model and not just a connector that simply feeds log records into the SIEM database.
Recommendation: Use an out-of-the-box SIEM for SAP
Projects aiming to integrate SAP Security into an enterprise SIEM should ensure that only pre-filtered events correlated to decision-enabling messages are sent to the SOC team, so they can effectively respond to cyberattacks. This keeps the SIEM operational costs low and delivers know-how where needed.
Although SIEM solutions are typically set up to use powerful algorithms, and recently AI capabilities, to correlate events from all kinds of sources, SAP environments remain challenging for SIEMS tools as they require a dedicated correlation model.
Therefore, it is much more efficient to use an out-of-the-box SIEM solution for SAP that comes with predefined SAP Security monitoring templates. They ensure that no important log records and security information are filtered out while delivering only the necessary events to the SOC team.
Pitfall #3: Implementing SAP Security as a tool
When CISOs aim to improve their IT Security posture and include SAP, they often look for a quick win and a short-term project. Upon starting, they sometimes discover that the SAP teams are already using some SAP Security tools, like a Patch Management tool for the SAP Basis team or a Code Scanner for the SAP custom development department. This might give the misleading impression that an SAP Security monitoring tool is enough to complete the mission.
However, this approach creates more load for SAP Operations, as the events are rarely handled by the SOC team but are instead routed to the SAP Basis team. We often see monitoring dashboards displaying tons of critical events nobody is paying attention to. As SAP Security events are now visible to the organization, a process must be in place to handle them. Ideally, this process should integrate with the other SAP Basis processes and extend into the SAP development and change management processes.
Recommendation: Implement an SAP Security process
While implementing a process takes more time and requires more resources, it is important to achieve quick wins at the beginning by picking up the “low-hanging fruits” and getting some critical tasks done. For this reason, we typically recommend customers to structure their SAP Security implementation into three phases, with each process built on top of an integrated and automated security platform for SAP:
- Kick-start your SAP Security
Ideally, your SAP Security solution is built for SAP and can therefore be installed directly in an SAP system without the need for any additional hardware or technical prerequisites. Ensure you have access to SAP Security knowledge and visibility into the current state of your SAP Security posture from the very beginning. A strong understanding of SAP security is crucial to accomplish the other steps of this phase within a day. - Get your SAP landscape secure – step-by-step
Once you have gained transparency, you can start creating an SAP Security Roadmap that allows you to constantly improve your SAP Security posture. Read this blog to discover some key best practices to accomplish this. - Establish processes to keep your SAP secure
Once you have implemented a security platform for SAP and gained SAP Security practice, you can start creating processes to maintain that level of security. The following article covers some recommended processes to stay secure with your SAP environment.
Interested in learning more about adopting an All-in-One Security Platform for SAP as the fastest and most efficient way to a mature SAP Security posture?
Contact us and we will be happy to tell you more about our guided approach to SAP Security excellence. For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
