Compliance to new Secure Configuration of SAP NetWeaver v1.2 standart. New challenges?
We have very good news – SAP have just updated their document “Secure Configuration of SAP NetWeaver® Application Server Using ABAP™; to version 1.2. Previous version was published in September, 2010.
I hope this document will be a de-facto standard for 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. I’d like to note that it wasn’t that hard because we have already implemented all the checks except one new option.
Today I will talk about the changes in new version. The main changes were focused on RFC issues, WEB-application security and SNC. Let’s look deeper into different topics:
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. https://service.sap.com/~sapdownload/011000358700001270931999E/SNCHBEN.PDF
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
Additionally 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 – information disclosure issue that can help attackers find some useful URLs;
- /sap/public/info – information disclosure issue that can help attackers find information about installed version and more;
- BSP test applications for troubleshooting:
There are also many other issues in web services and I will focus on it later in further posts because it is a big topic.
ABAP RFC CONNECTIVITY
Here we will find the most relevant changes and I understand exactly why. In my experience, while conducting security assessments of SAP Installations, in almost every system I find RFC connections from Test system to Production client with stored credentials of users with SAP_ALL rights. And in the most cases access to the test system can be acquired by using default user 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 but it still exists.
The old 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 S_RFCACL authorization and 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. 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.
MESSAGE SERVER SECURITY
This topic has been left untouched. One of the things I would recommend is to restrict access to Message Server HTTP Port (81NN) and implement logging using options:
- ms/http_logging set to 1
That’s all of the main changes to the standard and of course you need to regularly review the released SAP security notes on the SAP Service Marketplace to identify those notes that are not covered by SAP Solution Manager system recommendations and use other sources where relevant information about latest vulnerabilities is published:
- SAP Security (https://service.sap.com/security)
- SAP Security Guides (https://service.sap.com/securityguide)
- SAP Security Notes (https://service.sap.com/securitynotes)
- ERPScan security advisories (/category/advisories/ )
- ERPScan security whitepapers (/category/publications/ )
As for the conclusions: the changes are good but there are still so many things to do to make this standard complete. So in this blog I will focus on other issues which were unfortunately 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.