SAP is one of the most widely-used ERP systems globally, so it makes sense that it’s regularly being updated to meet businesses’ evolving needs. These updates often take the form of security patches that help reduce attack surfaces.
When SAP releases new patches, the process for implementing the updates is often involved and lengthy—not like applying updates to your mobile phone (click “accept” and the rest is done for you). IT leaders and their teams need to manage the updating process, speeding it along as much as possible since patches often mean system downtime—this business disruption is best limited as much as possible. Similarly, patch installation has the potential to open up new vulnerabilities in the interim, and a misconfigured patch could create new issues or weak points in the platform post-update.
If your enterprise is running SAP, it’s critical to thoroughly understand what goes into a successful update, fully plan the process, test out patches, and consider the ramifications of updates on daily operations and overall security. To help ease deployments, here are three of the most common SAP patches along with additional context on best practices for their implementation.
SNotes (aka SAP Notes)
Stability and security are the core goals of SNotes, which are generally aimed at providing a fix for a known issue or platform error. According to SAP.com, “Security notes contain information about both the affected SAP HANA application areas and specific measures that protect against the exploitation of potential weaknesses. Additional security measures are also documented here. SAP security notes are released as part of the monthly SAP Security Patch Day.”
Quick implementation of SNotes is recommended; when a critical flaw or system vulnerability is discovered, patch deployment delays leave those vulnerabilities intact for longer. In addition, SNotes often improve the performance of SAP platforms so installing patches will help make the system run optimally, benefiting users and the company as a whole.
SNotes can also be targeted at a specific problem and can either be corrected in the SAP platform by the installation of a patch or could come via manual instructions on how to resolve an issue. These patches are released often and are grouped into Support Package stacks that focus on a specific problem or functionality issue. Special attention needs to be allocated to the name and identity number of that stack, as it specifies what version of the SAP software the patches are compatible with.
SAP Service Packs
While SNotes are more tactical in nature, targeting specific issues, service packs are larger collections of updates for particular versions of SAP software, all in one place. These are generally used to bring a system up to date that hasn’t been updated in a while or that is recently deployed. Some service packs are larger than others, and some contain updates that vary in seriousness; closely review the release notes and the provided instructions to prioritize installation accordingly.
Service packs are highly intensive when it comes to deployment; you can’t expect to fit them into regular business operations. The pack needs to be downloaded, and tested, and the current system prepped. Don’t overlook the testing step—applying the pack elements in a non-production environment before going live will minimize risk and help identify issues before problems hit the production system. Also recommended is backing up the SAP system before installing the service pack; that way, an installation that goes awry can be scrapped and you can reset to the backup state.
Kernel Patches
The “kernel” of SAP is the system’s foundation and innermost core processes, responsible for memory management, process and task management, disk management, and much more. As such, patches are sometimes released to make the SAP platform and features work smoothly, perform better, enhance security, or address errors that are occurring in the kernel.
Kernel patches are complex and require thorough testing and planning. All of the above recommendations for the process of installing and testing patches apply here, too. There is an added caveat here that misconfiguration or sloppy installation can have a significant impact on the SAP system as a whole. Since SAP is one of the most critical pieces of software in many enterprises, that impact could be disastrous. Prepping, testing, and developing a contingency plan if the update causes disruption is highly recommended.
Conclusion
These three types of patches are the most common ones IT teams will be working with as they keep SAP platforms secure and up-to-date. Their installations are usually quite involved, so minimizing the risk of disruption should always be top-of-mind, such as making the update in off-hours, creating a backup, and utilizing a test deployment environment to ensure the installation will happen smoothly in practice.
In addition, patches should be prioritized based on how critical they are to security and core business operations. Utilizing the Common Vulnerability Scoring System (CVSS) can help professionals determine where their focus should be in the immediate term. Taking a risk-based approach to managing SAP updates will serve an enterprise well over time—in the form of up-to-date defenses, robust product performance, and minimized operational downtime.
By Christoph Nagy, CEO, SecurityBridge
Christoph Nagy has 20 years of working experience within the SAP industry. He has utilized this knowledge as a founding member and CEO at SecurityBridge–a global SAP security provider, serving many of the world’s leading brands and now operating in the U.S. Through his efforts, the SecurityBridge Platform for SAP has become renowned as a strategic security solution for automated analysis of SAP security settings, and detection of cyber-attacks in real-time. Prior to SecurityBridge, Nagy applied his skills as a SAP technology consultant at Adidas and Audi.
