And why you need automation…
Securing SAP systems is a lot of work and involves many different teams with different skillsets, from management to tech-teams and beyond. Add the complexity typically around SAP landscapes and soon you will notice that you need to work smarter, not harder, to achieve a level of comfort in the security of your SAP systems. We posted more general items on this topic but would like to zoom in on some typical practical examples in this post. The examples below by far do not cover all the challenges that SAP customers deal with but are there just to give you a bit of an understanding of what we saw customers struggle with over the years.
As more customers make the move to, at least partially, host SAP systems in the cloud (often still based on IAAS on a Hyperscaler such as AWS, Azure or Google Cloud) we see an increase of hybrid landscapes where some SAP systems are still hosted on-premise and others in the cloud. This in itself is not a bad thing but brings new challenges for customers, for example, around network-level security. Where in the past, the boundaries of the perimeter were physically determined by the fence around their own building/datacentre, it now means that connections between SAP systems are leaving their premises and often travel over the public internet to reach other SAP systems. This means more emphasis is put on securing those connections introducing TLS and SNC to encrypt HTTP and RFC connections. Read more about this topic in a previous blog.
More internet exposure
With the introduction of SAP HANA and Fiori, we saw more and more SAP systems being exposed to the internet to support all kinds of internet-based scenarios. With the Covid pandemic fresh in our memories, this increase further accelerated to support working from home, leading to a situation where many SAP systems are internet exposed. It is not hard to find those SAP systems and we have written on the topic on many occasions like here and recently on the Dutch Institute for Vulnerability Disclosure. The movement towards more internet exposure is a logical one, but while doing so make sure to keep some ground rules (like for the SAP Web Dispatcher) at hand to make sure your SAP systems are not unnecessarily over-exposed.
High complexity and many items to check
With dozens of SAP security specific parameters per system and hundreds of SAP Security notes to check, there is a big need for automation. This does not even include more complex checks on e.g. Access Control Lists that need a deeper level of finetuning. Implementing an efficient and effective SAP Vulnerability Management process nowadays cannot be done without some form of automation.
This is a topic we see many customers struggle with, especially since SAP releases many SAP Security notes and patching that often means downtime or additional testing, which often conflicts with business needs. The testing can be automated in many cases but requires many hours of creating test scripts and tooling. This is an important process, but it all starts with proper insight into which components are affected and which patches are missing. This is not just on the application level for SAP HANA, ABAP, JAVA, etc, but can also mean you need to patch or upgrade your Database, SAP clients like the Gui or the Operating System or SAP Kernel.
There are many specific challenges for SAP customers, but there is also a big overlap in common challenges that customers have. Protect4S automates detecting these issues and supports the SAP Vulnerability Management process with automated scanning for 2000 vulnerabilities, misconfigurations, missing patches, parameters, etc.
With an increasing dependency on SAP systems for your core processes, with more external exposed systems and with the complexity that comes with SAP systems, it’s time to bring your SAP Vulnerability Management to the next level and work smarter, not harder!