In the previous article “Efficient Patch Management for SAP” we talked about what needed to be considered for an efficient process to apply SAP security patches. Although the topic appears simple in a Windows environment, it remains a challenge for the SAP community. I decided to split the content into multiple articles, so it’s easier to digest all the info.
Today, we’re looking at the implementation and deployment of SAP security updates. However, before we start, we need to identify the relevant security notes. In standard SAP, Solution Manager provides the “System Recommendations” that, along with other notes, also lists security patches. A more focused and accurate alternative is SecurityBridge Patch Management which will also provide a full list of security notes relevant to a specific instance of your landscape. I would recommend that you select a tool, over manually creating a backlog as SAP also updates the security notes from time to time.
SAP provides multiple applications and components and some of these require a dedicated patch process. To simplify things, let’s focus on the core SAP S/4HANA and its predecessor SAP Netweaver products. These consist of a Kernel, an Application (ABAP and/or JAVA) and the underlying database. SAP provides the following types of corrections:
Customers of SAP can download the security patches via the ONE Support Launchpad or SAP Security Notes Application.
While the technical deployment varies according to correction type, they all follow the staging level principle. This means, that any correction needs to be installed in the development system first and following a preliminary technical check, the correction can move into the test stage. For ABAP-based corrections and Support Packages, the SAP Transport Management system (STMS) is used. Thanks to CTS+ some JAVA corrections can be also deployed. Kernel and some component updates, need to be installed (manually) per staging level.
Once in the test environment, a test should be conducted. SAP states that customers don’t need to test whether the security patch has eliminated the vulnerability, however customers ought to test the business processes that are used in production. After passing the QA process, the deployment to the production stage can be executed. Depending on the content of the transport request, this can often be done during normal business hours. As there are several scenarios that can lead to unwanted behavior, such as process abortion, it’s recommended that the correction is imported after normal business hours.
Important Observation: Occasionally, a correction requires a customer to rethink specific areas of their SAP implementation. In a scenario where SAP has decided to add additional authorization checks into specific business functions, the customers need to ensure that their business users receive the required authorization. If this is overlooked, it will mean that the end-users will not be able to continue their business operations.
The term HotNews is used by SAP to describe critical correction notes. These exist not only in the context of SAP security but of course also for SAP business processes. Such prio 1 SAP Notes are also published in the SAP NotNews Application available on the SAP ONE Support Launchpad.
Corrections that affect the SAP system security are additionally rated with a CVSS score. HotNews Notes are usually at least CVSS 9 or 10.
Of course, customers should pay special attention to SAP’s HotNews, but don’t forget the High and Medium priorities. Especially with the SAP security notes, it can happen that serious errors are fixed, but are only rated with a relatively low CVSS score. The CVSS rating may be reduced if the SAP vulnerability can only be exploited with direct network access or prior authentication.
So, we have made it into production and have eliminated the previously existing vulnerability. In an ideal world, this described process works like a charm. Unfortunately, as is often the case, particularly in information technology, the devil is in the details.
1. Plan your resources: SAP provides many security patches that require manual pre- / post-actions. These need to be performed by the customer. If overlooked, the customer risks reducing the effectiveness of the patch.
2. Analyze dependencies: SNOTES exist that list side effects or dependencies. In such a case, the customer needs to carefully review the description and act accordingly. It is wise to combine the implementation into a single SAP transport to simplify the deployment.
3. Don’t lose control, again: Tracking and transparency are important to not lose control over manual activities and to keep up with the status. Incident or Ticket Systems can be the ideal companion, for storing and sharing information. The SecurityBridge Platform provides an integrated Security Incident Management that provides an open API to integrate with any existing ITSM platform.
SecurityBridge Patch Management and Transport Center have been designed to prevent situations that can lead to missing important patches or cause outages because of erroneous patch deployment. SecurityBridge’s integrated Incident Management application provides the foundation for tracking and documenting the steps required to reach a secure state.
Automate patch management processes with SecurityBridge™
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
