Aspects of SAP Portal Protection

SAP has become a highly targeted application for cybercriminals. In a report by Onapsis it was found that 95% of SAP installations could be compromised with data being stolen and critical business operations impacted. The report went onto describing the situation as “falling through the cracks” because of a “responsibility gap” between SAP operations and IT security teams.

This situation has resulted in making SAP a vulnerable piece of kit that now needs special attention. Fortunately, solutions exist to help mitigate this vulnerability and we can discuss those as we look more closely at the security issues affecting SAP.

We begin our journey into how to secure a SAP portal by looking at the key areas that are affected. These can be broken down into:

1. Authentication into the portal
2. Privileged access rights
3. External attacks

The third area is one that is a more recent issue for SAP. It used to be the case that SAP was a closed system, i.e. it was designed for internal use within an organization. But as cloud computing and web API’s have become the new order, SAP too has extended its interface to include web connectivity.   This opening up of the SAP platform to outside factors means that it has become a target for web based attacks. But we mustn’t forget insider threats and simple mismanagement of credentials.

SAP Protection Drivers

The reasons to protect a SAP portal fall into two basic areas:

1. The protection of proprietary information and other sensitive data
2. The need to meet compliance and regulatory requirements, for example the EU Data Protection Directive

Authentication

Username and Password + Second Factor

The correct implementation and design of a robust authentication system within SAP is a fundamental step in controlling access to proprietary data. SAP default username and password configuration can be extended to use a two-factor system by way of a ‘one-time password’ (OTP). The SAP OTP has additional entropy as it is also time-limited, i.e. a TOTP and so exists for a configurable time period only. The use of second factor for any application sign in is recommended to reduce the risk of credential theft through spear phishing attempts and / or malware – the second factor being more difficult to steal as it is an out-of-band system, typically on a mobile device, like the SAP OTP generator.  There are a number of third party systems that can offer SAP second factor extension and it is worth exploring these to find the right fit / second factor method for your user base and your overall web application landscape

Digital certificates

As an alternative to username and password, SAP supports the use of browser based digital certificates or even RFID card based ones (which generate a temporary certificate at login). Certificate can make sign in very seamless; however they can be more difficult in terms of management / issuance, especially when working with an extended user base. The security of digital certificates is also questionable as the more common and usable browsers based types are device identifiers, as opposed to user identifiers (once installed) and should really be paired with a second factor to improve security and tie the login to a user.

SSO

The sign on features of the SAP portal, which also include integration with internal directories such as Microsoft Active Directory, can be used as the basis for Single Sign On, SSO.

SAP SSO can also be used as part of a wider federated identity system. Federation tokens, generated by an Identity Provider and which identify the user, are accepted across federated applications. The tokens are generated using the standard protocol SAML 2.0. These tokens are shared with each member of the federated system and allow SSO across the eco-system.

SSO has a lot of benefits in terms of usability of the portal. However, as previously mentioned, hardening of the login system can be handled through the use of an out-of-band second factor, like the OTP generator, or an SMS text PIN code. Again SSO systems that extend the SAP authentication modules and that are especially designed to handle SSO within an SAP environment should be sourced to ensure that the flexibility required for a successful SSO implementation can be achieved.

Privileged access and Risk Based Authentication

Security and usability are often at odds with each other and one area that can minimise the impact on usability is to have granular security options. Being able to apply more stringent security based on particular variables means that SAP security is more likely to be effective. In other words, being sensible in the application of security policies and applying them at the correct policy level, at the right time, will give you a more usable and yet more robust system; this is true for most security applications, not just SAP; usability can often improve security simply because people don’t try to circumvent it.

SAP is configurable to allow you to apply appropriate authentication based on risk factors. For example, you can enforce or suppress the use of second factor if certain identifying criteria exist, for example a geolocation setting e.g. the user is in a certain country, could force a  second factor authentication request.

Privileged logon is another area that can be used to help the granular nature of your security policies within SAP but one which can also potentially be a security problem. Insider attacks against organizations are one of the biggest threats to data protection. In the, ‘2015: Vormetric Insider Threat Report’, with research carried out by Harris Poll and analysed by Ovum, they found that “Insider threats are the most dangerous”. One of the major threats in systems like SAP is from insiders by them simply the sharing their passwords. This is reinforced in a Forrester report showed that one of the biggest issues in enterprise security is privileged access and password management. The use of second factor or SSO with forced authentication using second factor significantly diminishes this risk.

Before closing off on access control, one thing to never, ever do, is to keep in place the default credentials that are used during your SAP configuration and setup – they are well-known and used by cybercriminals.

Encryption

SAP data repositories contain sensitive and proprietary information which is a target for external cybercriminal and insider breaches alike. Aside from the obvious need to protect company data, there are security and privacy issues around the extended data sets of customers’ and partner companies, as well as regulation requirements. Encrypting SAP repository data and ensuring all network communications are encrypted will help to minimize the security risks and meet various data security based compliance needs, such as the EU Data Protection Directive.

Web Attacks and SAP

The opening up of SAP to web services has meant that web-based attack vectors are now affecting the portal. SAP is vulnerable to the same web-based threats as any web application, this includes XSS, CSRF and database injection attacks, like SQL injection.  SAP has released over 3000 security patches, many of which are to fix issues that allow web based attacks to occur. For example, in August of this year alone, there were eight Cross Site Scripting (XSS) security notes released.

Some malware has even been created to specifically seek out SAP installations, a kind of ‘reconnaissance malware’. The malware scans for SAProuter flaws and can steal login credentials or carry out false transactions. SAP fixes vulnerabilities once identified, but cybercriminals are always watchful of software vulnerabilities, especially zero-day vulnerabilities, which SAP are not aware of. The result is an untenable situation whereby the average patch window for SAP has grown to 18 months. In the Onapsis report mentioned earlier, they found that in 2014 the average number of patches per month was 30. And the release of SAP HANA has only exacerbated this situation. The result of such a heavy patch management overhead is to make SAP even more vulnerable to software vulnerability exploits. Patching cannot hope to control the malware onslaught that is being experienced across all organizations and alternative solutions need to be looked at, for example the use of a Web Application Firewall (WAF).

Many web based attacks start as a phishing or spear phishing email, which uses social engineering techniques to steal login credentials. So the use of second factor, as previously discussed, mitigates the impact of these phishing attempts.

You must view your SAP installation and any extended components as you would any web-based system and use web security tactics to ensure they are hardened.

Monitoring and patching of system components and OS/Browser patching, are two areas that need consideration in your security strategy that deals with web attacks.

Protecting SAP: Roundup

Ultimately it is a fine line between hardening SAP and making it an easy application for your extended user base to use. Some areas to concentrate security measures on include:

• Authentication and login: As we’ve mentioned one area that deserves special attention is your login choices. Security needs to be balanced with usability and the use of second factor should be explored, even with SSO.
• Access management: Restricting access on a per role basis and providing privileged access controls can help in minimizing data exposure.
• Patch management: Timely patch management across the SAP installation can help to mitigate issues related to software vulnerabilities; however the number of patches issued by SAP puts this strategy at risk and alternative tools, such as Web Application Firewalls should be sourced
• Education of users: Education can help users to recognise phishing attacks and prevent employees sharing passwords
• Monitoring of incoming threats / user behaviour: Monitoring and audit can help recognise incoming threats before they become a breach. Monitoring and logging of user behaviour can help to recognise unusual patterns of behaviour and mitigate insider threats.
• Use of a Web Application Firewall: A fast moving threat landscape demands a more flexible approach to we attack prevention.
• Layering: You need to add layers of protection that encompass both preventative and monitoring capabilities to secure your SAP portal.