Security Guide for SAP NetWeaver and S/4HANA

The SAP NetWeaver profile parameters can largely make or break the security of the SAP system. Critical configurations relating to secure communication, behaviour of default users, password policies, gateway security, network security and many many more depend on appropriate profile parameters configuration.  The invest in this task is basically in figuring out which of the hundreds of profile parameters are security-relevant, parameterizing/instantiating those for your enterprise and ensuring those configurations are in place all the time - preferably in an automated fashion.

There are a few useful resources which can help you with identifying security-relevant profile parameters. You can use our Benchmark - WALLSEC Security Hardening Baseline for SAP NetWeaver - Profile Parameters.  Collect all those relevant configuration parameters possibly in a form of your own enterprise baseline/hardening procedure and validate those against your systems.  You can perform the validation manually by executing transaction SE38 and the report RSPARAM or you can work on automating the evaluation. There are multiple alternatives to achieving automation:

• STC01 provides functionality to perform profile parameter checks on a single system

• Solution Manager provides functionality to monitor configuration on all connected systems

• Profile parameters are stored in flat files. Those can be retrieved, parsed and analyzed on a regular basis.

The invest is considered low as we do not need any additional tooling apart from what is already there and the baseline definition and automation implementation project could be done in a short time. This task possibly has the highest impact on the security of your SAP system, therefore we consider this one a "QUICK WIN!" with high return on invest (ROI).

The network environment surrounding our SAP systems surely play an important role. In times where Zero Trust is the leading principle for driving security strategy, good old network segmentation may not fit well into the Zero Trust model or better said, because of Zero Trust assumptions, segregation may be regarded unnecessary. Blindly applying/assuming Zero Trust on an SAP system does not work. For multiple reasons we still consider network segmentation a good and appropriate approach towards securing SAP systems.  SAP systems rely on secure network environments (e.g. Gateway Security) and network security need to be maintained. Here we consider the ROI to be average. 

SAP NetWeaver and S/4HANA represent the application layer which still has a high dependency on underlying technologies. The security of the application stack depends on the database security, operating system security, virtualization layer security, etc. Security of underlying infrastructure is paramount to security of the SAP application layer. The invest in securing the SAP NetWeaver / S/4HANA application server will not be enough if unauthorized access is possible on OS-layer where a malicious user can dump the whole database, copy the SAP system private keys and manipulate just about any parameter of the system.

The database and operating system layers become nowadays more constant as SAP has moved from  supporting dozens of operating systems and databases to  concentrating on HANA as the database layer and only a few Linux distributions like SUSE and RedHat. This makes security somewhat easier as we can set clear technical expectations for the few possible underlying technologies.  Organizations often already have security baselines / hardening procedures for Linux server distributions - applying those would be mostly sufficient (a few SAP-specifics on OS level still need to be considered). The HANA database is not simple, nevertheless applying  only a dozen of configurations already improves the security posture widely. We consider that in most organizations  on those underlying layers, an appropriate level of security already exists and controls are in place. Fine-tuning and re-evaluating (possibly through a security audit) the posture of the underlying layers will provide you the  much needed assurance that no weaknesses exist below the critical SAP application layer. We consider the invest in re-evaluation/assurance  as low and with a high ROI. This measure is a Quick WIN!

While custom development is not desired, certain business cases require extending, customizing and adapting functionality. Custom developed code and applications require all the tedious processes which normal software enterprises apply to ensure product security - from peer reviews, to automated code vulnerability scans (SAST), manual code reviews, dynamic vulnerability testing, etc. There are dozens of third party software that will support you in that matter and there is also the SAP in-house CVA Tool (Code Vulnerability Analysis) which you may use for the SAST part of your project. The security  quality gates need to be embedded into the established release management plan of the projects, including quality gates like peer code review, SAST and penetration tests before releases.

You need to expect a high invest in time and resources and the respective high return.

SAP NetWeaver roles, profiles and authorizations management is often a full-time job for a whole team in larger enterprises. Under this particular item we want to zoom out on the topic and concentrate only on the pure basics of SAP NetWeaver user management and authorizations. We want to concentrate on SAP basis and not go deep into the different modules and associated roles and authorizations. We want to make sure that default accounts are secured, make sure that overprivileged profiles are assigned only to the right users and basic critical authorizations objects are not falsely applied to the wrong profiles/roles/users. Limiting ourselves only to those few items, we can very time-efficiently scoop the low-hanging-fruit and have a very high return on our invested time.

We have already discussed some of those in another post, including some hands-on guides:

• Measure #1: Default Passwords 

• Measure #3: Critical Authorizations 

Here we tackle the bits and pieces of SAP authorizations. We establish users and authorizations management processes, implement IDM/ARM tools, identify segregation of duties violations on the basis of business processes, etc. In larger enterprises this could be easily a full-time job of 5 to 10 people. The established processes are often in the center of compliance requirements resulting from different certifications and attestations such as SOX, ISO27001, etc.

Having scooped the low-hanging-fruits in the previous task and thus even partially mitigated even the internal malicious user scenario, the true attack vector we address with this measure is a determined insider who misuses possibly falsely assigned permissions which do not fall in the Basic category we previously addressed. 

Here our Return rating is definitely debatable.  There could be further mitigating deterrent controls in place such as SIEM on application layer addressing the determined insider attack vector. While looking at the topic only from technologic standpoint, the rating may be adequate. Nevertheless, some enterprises must satisfy their e.g. SOX requirements and those certifications are not really negotiable, but rather a "must have". In such cases the return justifies any invest. 

Implementing a rigorous patch management process for any system is of utmost importance to the system's security. SAP systems are often in the heart of business processes and downtimes and disruptions are highly undesirable. Therefore, SAP NetWeaver / S4HANA patch management becomes often a tedious planning process with irregular cycles, carefully analysing every change which each patch/note introduces.

SAP has come a long way in terms of patching products and fixing reported security issues. SAP has established a monthly Patch Day on every second Tuesday of the month.

You can get more information on released patches under the following link:

• https://wiki.scn.sap.com/wiki/display/PSR/The+Official+SAP+Product+Security+Response+Space 

A good KPI for monitoring the efficiency of the process is the exposure time of your SAP systems. The exposure time would be the timeframe between SAP releasing the patch and  your SAP basis team installing the patch. That would be the time window where your system would be exposed to the vulnerabilities fixed by those patches.

Best Practice: While SAP would generally release security patches with a CVE ID and respective CVSS scoring, the customer's CERT Advisory Teams may re-prioritize the SAP patches in order to assess in how far the organization is actually affected by those issues.  This would provide a much better insights into the resulting risks of the exposure window discussed above.

Integrating SAP NetWeaver / S/4HANA systems into your SOC is not a straightforward activity. The SIEM technology you use must have the ability to integrate with SAP systems. SAP NetWeaver logs are not text files in a standard format which can be collected easily by a standard agent from the system. Often clients will need adapters or "intermediate" SIEM tools which will collect the logs, make sense of the SAP logs, "normalize" those and forward events to the actual SIEM solution in the company.

After the technology integration part is resolved (which is not trivial and would be rather costly), SIEM use cases and SOPs need to be defined. Because of the specifics of the SAP NetWeaver technology layer, you most probably cannot rely on all-rounder SIEM experts, but you would rather need skilled SAP security experts (not that easy to find) who also have the specific experience of developing SIEM use cases.

 That should not discourage anybody from going down that road. SAP systems are often the crown jewels of the enterprise IT environment and must be a part of the enterprise SOC program rather sooner than later. Nevertheless, be prepared that it may not be a straightforward exercise.    

Here is a helpful blog in case you are using Splunk as SIEM, explaining how to integrate you SAP security audit log with Splunk without the need of log adapters, intermediate SIEM solutions or similar:

• How to Integrate Your SAP Log with a Splunk SIEM?

Education and awareness is one of the best invests, but also a costly one. Security-averse resources with SAP background are scarce in the industry. Security officers and security experts often have little influence on the capabilities of operating resources. While we as security experts may provide guidance and mentoring, the People part is at the end often out of our span of control.