Compliance to new Secure Configuration of SAP NetWeaver v1.2 standart. New challenges?

We have some good news – SAP has just updated their document “Secure Configuration of SAP NetWeaver® Application Server Using ABAP™; to version 1.2. The previous version was released in September, 2010.

I hope this document will be used as a practical standard for the baseline security configuration of SAP NetWeaver ABAP engine and that’s why we have implemented compliance for this standard in ERPScan Security Scanner for SAP in 2010 and now successfully updated our scanner to new SAP requirements. It wasn’t a big deal because we have already implemented all the checks except one new option.

Today I will talk about the changes in the latest version. The main oness were focused on RFC issues, WEB-application security and SNC. Let’s discuss in detail different topics:

Password management:

Only 2 new options were added:

  • login/password_history_size – the number of passwords (chosen by user, not administrator) that the system stores and that the user cannot use again. 5 is recommended but 12 is better.
  • login/password_expiration_time – defines the validity period of passwords in days. It is recommended to choose the value of 30 to 90 days according to your corporate compliance policy. For example, according to PCI DSS, this value must be set to 90.

Secure Network Communication:

As for the SNC, there is nothing new, except SNC without a single sign-on capability is now available to all SAP NetWeaver customers for SAP GUI and RFC connections.

And now it is much easier to deploy it but unfortunately it is still very rarely implemented at customers’ systems.

Limit Web-Enabled Content:

One additional RFC service have been added – /sap/bc/bsp/sap/icf

Also I would like to recommend that you restrict access to some other dangerous services:

  • /sap/public/icf_info/icr_groups and /sap/public/icf_info/icr_urlprefix – the information disclosure issue that can help attackers find some useful URLs;
  • /sap/public/info – information disclosure issue that can help attackers find the information about the installed version and more;
  • BSP test applications for troubleshooting:
    • /sap/bc/bsp/sap/it00
    • /sap/bc/bsp/sap/sbspext_htmlb
    • /sap/bc/bsp/sap/sbspext_xhtmlb
    • /sap/bc/bsp/sap/htmlb_samples
    • /sap/bc/bsp/sap/bsp_verification

There are also many other issues in web services and I will focus on them in further posts because it is a broad topic to discuss.


Here we will find the most relevant changes. In my experience, while conducting security assessments of SAP Installations,I find RFC connections from Test system to Production client with stored credentials of users with SAP_ALL rights in almost every system. In the most cases it is possible to get the access to the test system with the use of default credentials, for example, EARLYWATCH with password SUPPORT in the 066 client. It is one of the easiest and most dangerous ways to hack a SAP system that still exists.

Some recommendation said that:

  • Connections in which systems of higher security classification trust systems of lower security classification (e.g. test to production, or development to production connections) should be avoided
  • RFC destinations with stored user credentials from systems of lower security classification to systems of higher security classification should be avoided
  • User accounts have minimum authorizations (especially not SAP_ALL) assigned in the destination target and that the user type is set to “SYSTEM”

So let’s see what SAP recommends in the new guidelines except that:

  • First of all, trusted connections must have the S_RFCACL authorization and the wildcard must be ignored. This authorization is excluded from the SAP_ALL profile by default and it is recommended to check the PRGN_CUST table where ADD_S_RFCACL must be NO.
  • Ensure that RFC authority checks are enabled by setting profile parameter auth/rfc_authority_check. The authorization check uses the authorization object S_RFC to check whether the user defined in the destination has RFC authorization for the function group of the called function module. Possible values:
    • 0 – no authorization check;
    • 1 – authorization check active except for the same users and SRFC-FUGR objects;
    • 2 – authorization check active except for SRFC-FUGR objects;
    • 9 – authorization check active.

It is recommended to set the value to 9.


This topic has been left untouched. One of the things I would recommend to do is to limit the access to Message Server HTTP Port (81NN) and implement logging using options:

  • ms/http_logging set to 1

These are all of the main changes to the standard and of course you need to review the released SAP Security Notes regularly on the SAP Service Marketplace to identify those Notes that are not covered by SAP Solution Manager system recommendations and use other sources where the relevant information about latest vulnerabilities is published:

As for the conclusions: the changes are important but there are still many things to do to make this standard complete. In this blog I will focus on the other issues which were left behind and, I hope, will also be implemented into this standard within the next SAP release.

I wish you good luck with complying with this new standard and I will be happy to answer any questions regarding this standard and other SAP security issues.

Do you want more?

Subscribe me to your mailing list