Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
aarthi_kannan
Advisor
Advisor
(Aarthi Kannan serves as APJ Regional Senior Security Expert for SAP Enterprise Cloud Services (ECS). She is also an avid Cloud Security enthusiast and a shift-left proponent for securing compute and data solutions on the cloud. In her current role, she is responsible for advising existing and potential customers on the multi-layered defense-in-depth security features and operational security aspects of the RISE with SAP private cloud environment.)

Introduction


The SAP S/4HANA Cloud, Private Edition serves as the foundation for the “RISE with SAP” offering, safeguarding customers’ essential business data and their mission critical operations. SAP Enterprise Cloud Services (ECS) is the business unit that manages and delivers the SAP S/4HANA Private Cloud environment, featuring a multi-layered defense-in-depth security architecture that covers both infrastructure and technical managed services.

As customers embark on their digital transformation journey, RISE with SAP is at the forefront, offering organizations a path to innovation and growth. However, as your business ascends to new heights, so do the potential cybersecurity risks. In this ever-changing landscape, understanding and instituting a comprehensive vulnerability and patch management program is key to safeguarding your RISE with SAP Private Cloud environment.

This is a two-part blog series; in this first part of the blog series, we will focus on the critical aspects of the Vulnerability Management process as implemented by SAP Enterprise Cloud Services (ECS). We will also cover the importance of implementing patches on time and the security risks of not doing so. The second part of the blog series will focus on the Patch management process within SAP ECS.

Overview


Vulnerabilities are weaknesses, flaws, or gaps in the security of hardware, software, networks, or systems that can be exploited by attackers to compromise the confidentiality, integrity, or availability of information, assets, or resources. Patches are additional pieces of code developed to address problems (also commonly referred to as “bugs”) in operating systems, databases, application software, or even firmware. Patches enable additional functionality or address security flaws within a program.

SAP’s Vulnerability management program is designed to proactively prevent the exploitation of security vulnerabilities that exist within SAP’s cloud services and solutions. Patch management is the systematic process of identifying, acquiring, testing, deploying, and monitoring updates, fixes, and patches to software applications, operating systems, and hardware devices. When vulnerability management is combined with an effective patch management program, it will reduce the potential for active exploitation of vulnerabilities by malicious entities.

Not all vulnerabilities have patches. Accordingly, administrators and security teams must not only be aware of either actual or potential vulnerabilities and available patches, but they must also be aware of other methods of remediation (such as configuration changes, employee training or even server reimaging) that limit the exposure of systems to vulnerabilities. Further when no patches are available, countermeasures must be in place either to remediate the flaw temporarily or permanently.

Importance of patching vulnerabilities on time


Timely patching of security flaws is widely recognised in the quest to provide appropriate security. It is essential to maintaining the confidentiality, integrity, and availability of information resources and data.

What are the benefits of timely patching?


As a Cloud service provider, SAP understands the immense importance of a comprehensive vuln management and patching program and how it is critical to achieving appropriate security. In years past, many people approached server patch management with the following mindset: “We don’t patch unless there is a reason to upgrade the version for application compatibility.” This philosophy is no longer appropriate today because of the risk of downtime that can result from malicious code targeting known vulnerabilities on unpatched systems. Regular patching is like maintaining the locks on your doors to ensure that potential entry points are secure.

Patching systems and software on time offers numerous benefits, primarily centered around security, stability, and functionality.  Here are some of the key advantages of applying patches promptly:

  • Security Enhancement: Patches often address known security vulnerabilities. Applying them promptly helps protect your system from potential exploits and cyberattacks. Patching can also prevent data breaches by addressing security flaws that could be exploited to gain unauthorized access to sensitive data.

  • Compliance and Risk Management: Timely patching is often a requirement for regulatory compliance in industries such as healthcare, finance, and government. It reduces the risk of security incidents, data breaches, and downtime, which can have legal, financial, and reputational consequences.

  • Stability & Reliability: Patches not only address security issues but also fix software bugs and glitches. This leads to a more stable and reliable system, reducing the risk of system crashes or unexpected behavior.

  • Productivity Gains - Improved Performance, User Experience: In some cases, patches may introduce new features or improve existing ones, enhancing the functionality of the software or system. Some patches include performance enhancements, which can improve the system performance.


What are the Security Risks due to not patching on time?


Failing to patch systems and software in a timely manner can pose significant security risks, which directly impact the organization’s security posture. Here are some of the key risks associated with not patching on time:

  • Increased Vulnerability to Ransomware attacks: Ransomware attacks have been on the rise, and they often exploit unpatched vulnerabilities. According to the Sophos “The State of Ransomware 2023” report, it cost companies on average $1.82 million to recover from a ransomware attack in 2023 — and that doesn’t even include paying a ransom. The downtime caused by such attacks also significantly impacted productivity.

  • Data Breaches: Unpatched systems often have known vulnerabilities that malicious actors can exploit. They can use these vulnerabilities to gain unauthorized access, disrupt services, or steal sensitive data, leading to data breaches. According to various reports, around 60% of data breaches are linked to known vulnerabilities for which patches were available but not applied. According to IBM’s Cost of a Data Breach report, 2023, the global average cost of a data breach in 2023 was USD 4.45 million, a 15% increase over 3 years.

  • Compliance Violations: Failure to apply patches on time can lead to non-compliance with industry regulations and data protection laws, resulting in fines and legal penalties.

  • Financial Losses & Reputation Damage: Cybersecurity incidents can lead to substantial financial losses, including expenses for incident response, recovery, and legal actions. Publicly disclosed security breaches can damage an organization's reputation, eroding customer trust and loyalty.

  • Propagation of Malware: Unpatched systems can serve as entry points for malware, allowing it to spread throughout the network and compromise other devices. Malicious software can infect systems through unpatched vulnerabilities, leading to unauthorized access, data theft, and system corruption.

  • Business Disruption: Cyberattacks targeting unpatched systems can disrupt business operations, causing downtime, loss of productivity, and revenue loss. Constantly dealing with security incidents and recovering from attacks can disrupt business ops and reduce productivity.


Major Cyberattacks on Unpatched Systems


There have been several major cyberattacks in the past that exploited unpatched vulnerabilities. Figure 1 shows some well-known examples:


Figure 1 - Major cyberattacks due to unpatched vulnerabilities [1] [2]




  • WannaCry Ransomware (2017): One of the most infamous cyberattacks, WannaCry, exploited a vulnerability in Microsoft's Windows operating system. The attack affected over 200,000 computers in more than 150 countries. The ransomware spread rapidly, encrypting users' files, and demanding a ransom payment in Bitcoin. Many affected systems had not applied a critical patch that Microsoft had released months before the attack.

  • NotPetya Cyberattack (2017): NotPetya was a destructive cyberattack that primarily targeted Ukraine but quickly spread globally, impacting numerous multinational organizations. The attack exploited the same EternalBlue exploit that WannaCry used. It targeted unpatched systems and caused significant disruptions in businesses worldwide, leading to financial losses in the billions of dollars.

  • Equifax Data Breach (2017): In 2017, Equifax, one of the largest credit reporting agencies in the US, suffered a massive data breach that exposed sensitive information of approximately 147 million people. The breach was attributed to an unpatched Apache Struts vulnerability; the patch was released in Mar 2017. Equifax had failed to apply a patch for the known vulnerability, which ultimately led to the breach in May – July of the same year.

  • SolarWinds Supply Chain Attack (2020): The SolarWinds breach was a sophisticated attack where malicious actors compromised the software update process of SolarWinds' Orion platform. This allowed them to distribute a backdoored update to thousands of organizations. The attackers exploited a vulnerability that was not promptly patched, enabling them to conduct espionage and data exfiltration.

  • Apache Log4j Vulnerability (2021): In late 2021, a critical vulnerability in the widely used Apache Log4j library was discovered (CVE-2021-44228). Attackers quickly began exploiting this vulnerability to gain unauthorized access to systems. Organizations that didn't apply the available patches were at risk of compromise.


These examples demonstrate the serious consequences that can result from neglecting patch management. Applying patches promptly and regularly is essential for maintaining a strong defense against cyber threats and protecting sensitive data.

Key Considerations


While it might seem completely reasonable to deploy patches against vulnerabilities as soon as possible, there are a few aspects to be considered while implementing an effective vulnerability management program.

Shared Security Responsibility Model


Security within the RISE with SAP Private Cloud environment is a Shared Responsibility between various entities like SAP, Customers and Hyperscale Cloud Providers as shown in Figure 2. The Shared Security Responsibility Model is explained in more detail in this blog. This is important for customers to consider from the perspective of Vulnerability and Patch Management. Accordingly, SAP is responsible for managing vulnerabilities and patching at the infrastructure layer (with the caveat that customers are accountable for providing downtime windows for applying certain types of patches, that require system rebooting). Customers are responsible for vulnerability and patch management at the application layer. Customers are also responsible for testing the applications after applying patches at the infrastructure and application layers.


Figure 2 - Shared Security Responsibility model



Constraints, Dependencies and Maintenance Windows


Constraints, dependencies, available maintenance windows and patch availability impact vulnerability and patch management. Finding vulnerabilities and managing them in today’s environments can be overwhelming. The MITRE CVE DB has more than 20,000 vulnerabilities. Patches are released daily. The sheer volume of available patches makes it is difficult for even the most experienced administrators to maintain awareness of available patches and deploy them in a timely manner. The time that follows immediately after the release of a patch is essentially a vulnerable moment due to time lags to obtain, test, and deploy a patch. There is no guarantee that the patch will work, so it is well advised to test them to ensure that they work or that they don’t break something else.

In the private cloud environment, there are other dependencies on customers around downtime windows which further decrease the efficiency of the patch management process. From the customer’s perspective, some of these patches require a reboot, which could mean possible downtime. Application regression testing may also need to be incorporated depending on the nature of the patches and how the patch affects the system.

All these things affect the vulnerability and patch management program, and they all must be weighed appropriately. One cannot assume that patches are immediately implemented without additional consideration for priorities, countermeasures, and especially, for testing. In fact, the patch management program must be carefully assessed, prioritized, and managed, and thorough testing is a critical success factor. For a cloud service requiring service level agreements for system availability, this is, without question, a daunting program management challenge.

Good Industry Practices Employ Risk Management


The only way to truly keep your cloud services safe is to prioritize patching based on business risk, which requires broad and deep insight into the vulnerabilities themselves. We can gain this insight only through accurate, up-to-date vulnerability research and trustworthy threat intelligence.

To bring order to the chaos, you must:

  • Understand your threat environment

  • Gain intelligence on threats and vulnerabilities to effectively prioritize and

  • Use extensive vendor patch data for rapid remediation


Vulnerability Management in SAP Enterprise Cloud Services


Vulnerability Management Lifecycle


SAP’s Enterprise vulnerability management lifecycle is an iterative process consisting of 6 steps, as seen in Figure 3.


Figure 3 - Vulnerability Management Lifecycle




  1. Identify – The goal is to identify and classify assets and integrate these with the Vulnerability management platform. Another key point is to plan for network discovery to identify undocumented assets to help ensure the completeness of data.

  2. Test – Next is to establish the vulnerability detection technique. Depending on the nature of assets identified in the previous step, we may need a combination of techniques like agent-based scans, network-based scans, and Web application scans.

  3. Scan – This is where the scanning is performed. In SAP vulnerability scanning happens at a set schedule for different platforms preferably in an automated fashion and communicated to stakeholders.

  4. Score – Identified vulnerabilities must be prioritized according to the severity of the issue, criticality of the system, level of exposure, availability requirements of the system, etc.

  5. Report & Mitigate – The prioritized vulnerabilities are communicated regularly in the form of reports to the business units. These reports contain all relevant asset data and vulnerability details to enable operating units to act on mitigating the vulnerability.

  6. Measure – Key factors like the number and priority of open vulnerabilities are measured and continuously monitored per business unit. As per policy, all software vulnerabilities must either be mitigated or covered by appropriate exception and risk should be registered.


SAP Vulnerability Advisory Services


SAP has a Vulnerability Advisory Services (VAS) team as shown in Figure 4. This is a team internal to SAP that is responsible for monitoring vulnerabilities in software relevant to SAP operations and providing the criticality and priority rating in alignment with the platforms or business units. Additionally, the VAS team is responsible and accountable for publishing and updating SAP CERT notifications, or SCNs, for all relevant vulnerabilities containing the latest criticality and priority rating.


Figure 4 - SAP Vulnerability Advisory Services (VAS)


The VAS team ingests the daily NIST vulnerability feeds and monitors software vendors’ web sites relevant to SAP environments to identify new vulnerabilities. A risk-based approach is used to analyze and prioritize vulnerabilities. Some factors which are considered when determining the priority of a vulnerability:

  • Environment (DEV, PRD etc.)

  • Severity level of the vulnerability

  • Likelihood of occurrence

  • Magnitude of impact

  • Existing compensating and mitigating controls

  • Exploitability and ongoing malware campaigns


The received vulnerability information is analyzed by members of the SAP VAS team. This includes reading and understanding the vulnerability and additional research, if needed. Based on this, the SAP CERT advisory is then published. The vulnerability rating is done in an SAP-developed tool: the SAP CERT advisory service. The rating of the vulnerability is estimated using the following criteria:

  • Base score – represents the fundamental characteristics of a vulnerability that are constant over time and affect user environments (access vector, access complexity, authentication, impact on confidentiality, integrity, and availability)

  • Temporal score – represents the characteristics of a vulnerability that change over time but not among user environments (exploitability, remediation level, and report confidence)

  • Environmental score – represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment (collateral damage potential, target distribution, and security requirements)


Common Vulnerability Scoring System (CVSS)


Common Vulnerability Scoring System (or CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. The latest version of CVSS (v.3.1) was released in June 2019. SAP’s vulnerability severity level is based on CVSS v.3.1 base scoring.

The respective severity levels are defined as:

  • Critical: CVSS 9.0 – 10.0

  • High: CVSS 7.0 – 8.9

  • Medium: CVSS 4.0 – 6.9

  • Low: CVSS 0.1 – 3.9


The priority level is ultimately a result of the severity of the vulnerability together with the asset attributes in combination with the exposure level.

Handling Zero-day vulnerabilities


When patches are unavailable, as in the case of zero-day vulnerabilities, a risk assessment will be performed by the risk coordinator within SAP ECS. The risk mitigation plan will be reviewed and documented in collaboration with the SAP Enterprise Vulnerability Management Team and asset owners. Exception requests will be handled over the established exception management process. In the absence of patches, mitigating controls will be applied to prevent exploitation of such vulnerabilities.

Conclusion


In summary, the first part of this blog series depicts the importance of an effective Vulnerability management program to address vulnerabilities via timely application of patches. This is reinforced by exploring the benefits of applying patches on time and highlighting the security risks of not patching on time. This blog also explains the Vulnerability Management lifecycle followed by SAP Enterprise Cloud Services (ECS), along with a detailed look at the teams and steps involved in the process within SAP. Vulnerabilities are scored and rated as per the CVSS version 3.1 and patches are prioritized accordingly. The second part of this blog series will focus on Patch management in detail.

External References:


1 - Cybercrime and Exploits: Attacks on Unpatched Systems - Security News (trendmicro.com)

2 - Computer giant Acer hit by $50 million ransomware attack (bleepingcomputer.com)

Acknowledgement


The author would like to express deep appreciation for Roland Costea (Chief Information Security Officer, ECS), Alexandra Anghelache (Security Transformation Lead) and Namrata Mohanty (Infosec Compliance Senior Specialist) from SAP Enterprise Cloud Services for their support in creating and reviewing the content and providing valuable feedback. The author would also like to express gratitude to Sasi Kathirasen Mani, Regional Head Execution for APJ and GCR, SAP Enterprise Cloud Services for his encouragement and support to publish the blog.

Disclaimer


© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.