SAP security hardening can sometimes take the back seat when implementing an SAP system. Take an example; if a business is going to be switching from ECC to S4, what is the main priority for your basis and security consultants? Yes, you guessed it, just get it working and keep that team of PM’s off your back. Implementations are the definition of the phrase “time is money” and the Project Management team will remind you of that on the daily so covering all aspects of security in a small time frame is difficult and one must prioritise deliveries accordingly. So why is security hardening so important and what are SAP doing to make this process easier for their customers? Let’s start by defining what security hardening means and what it aims to deliver for you and your business. Security hardening is a set of tools, techniques and best practices that aim to reduce vulnerabilities in applications, systems, infrastructure, databases, etc. Hardening in SAP aims to reduce the attack vectors available for potential malicious targeted attacks, which in turn reduces the attack surface area. Hardening your SAP landscape doesn’t have to cost a huge amount, if any at all. Starting with a clear and concise plan will help you to build a check list that can be executed annually or after a system upgrade/conversion.
Starting at the HANA DB, there are a number of cost effective quick wins that can be executed to help be more secure and audit compliant.
Disable your SYSTEM user
The SYSTEM user is an exceedingly good technical account in the HANA DB, it cannot be deleted, it can be used by multiple users and it has a broad permission base. We would strongly recommend that it be disabled in all tenants delivered with you SAP system, and do not forget about the SYSTEM DB. When this account is used, organisations will lose all accountability and find it next to near impossible to audit any administrative activities as multiple users are using the same account, not to mention it would be the first account that a hacker would target to gain access to your DB, an all round easy win for the auditors if not Deactivated or managed correctly. If the SYSTEM user is disabled, what can you do? Well its simple, you design a set of roles that meet the requirements for your security/basis team. The SAP HANA Security Guide has a lot of information on this.
Configure SSO for your Admins & Users
Removing the ability to brute force accounts is always an easy and cost effective way to harden your SAP landscape. SAP HANA supports several protocols for SSO including Kerberos, SAML 2.0, JSON web tokens, and logon and assertion tickets.
Encrypt all client connections
When connecting via JDBC or ODBC, its recommended all traffic is configured to communicate over HTTPS. Granted the passwords are always transmitted in encrypted hashed form during the authentication process, its still recommended the transported layer is also encrypted.
HANA MiniChecks
SAP have kindly given their customers a bunch of excellent SQL’s queries which can help you pin point any gaps in your security layer, it also contains a list of handy SQL’s for performance and troubleshooting. The Note 1969700 is a one stop shop for all your HANA Admin needs, so download the attached file in the note and store it locally (make sure to check it regularly for updates).
The HANA Security Mini Checks can be found in SAP Note 1969700, look for the statement called HANA_Security_MiniChecks.txt.
The SAP HANA Security checks cover a wide array of security checks on your DB, some examples:
Active Debug Tracing
LDAP Authentication without TLS.
Audit Policies
SSFS master key set to initial
CONTENT ADMIN granted to users
SYS_BI_CP_ALL privileges granted to user
Users with critical privileges assignment
An example of how it will look when exported. SAP also point you to the note which best suits the recommended config.
HANA Log & Data Volume Encryption
Upon installation, the HANA Log & Data volumes are unencrypted. We strongly recommend that you enable data and log volume encryption immediately after installation, handover from your hardware or hosting partner, and after you have changed the root encryption keys for both services. If you want to check the state of the volumes, you can use the below SQL: SELECT * FROM M_ENCRYPTION_OVERVIEW WHERE SCOPE='LOG' OR
SCOPE = 'PERSISTENCE’
SAP S4 HANA
In the past couple of years we have seen and greatly welcomed a new initiative from SAP called “Secure By Default“. Secure by default is a relatively new initiative introduced by SAP in 2019 to help customers operate a more secure S4 application, all the new values are received automatically. You may ask, why now? Wouldn't this be an obvious task that you would expect all customers to carry out in their environments? Well the answer is yes and no. Whilst security is an extremely important priority for all business‘s, one must weigh up time and effort is costs to cover the changes. Companies must take into account what a change would mean, who would test the change and would this result in instability. SAP have taken this headache off the table for their customers. With S4 2021, SAP have introduced 27 new security parameter default changes, most notably the activation of table logging for business-critical tables. This logging allows tracing all changes on field level for financial and business relevant tables.
Some more examples of security parameters changes by default can be seen below:
rfc/reject_expired_passwd - New Default value = 1 Controls whether logon with expired or initial password via RFC is allowed or not. If not set to 1, users with a non-productive password are able to remotely call RFC function modules.
rfc/callback_security_method - New Default Value = 3 Permit or deny execution of RFC callbacks in accordance with configured allow list and write corresponding entry in Security Audit Log. If not set to 3, improper RFC callback attempts are still allowed.
login/password_hash_algorithm - Improved hashing algorithm = encoding=RFC2307, algorithm=iSSHA-512, iterations=15000, saltsize=256. The hash value calculation can be improved with this parameter to make dictionary and brute force attacks more difficult.
A full list of the improved security setting from 2019, 2020 & 2021 can be seen here.
There are of course some very expensive and robust third party software products you could use to run and automate these checks but we believe that using the above tips & tricks combined with the EWA report that SAP provide, you can effectively and efficiently secure your SAP environments.
Comments