Threat Landscape

Threat Landscape

The Cost of Security Breaches

Since 2014 security has moved high up the IT strategy priority list, with the threat of cyber-attacks increasing in cost and sophistication, and often topping the news agenda.

81%

81% of large UK organisations have had a security breach

60%

60% of small UK organisations have had a security breach

59%

of respondents expect there will be more security incidents in the next year than last

cost of breaches nearly doubles in last year

The average cost of the worst breach suffered has gone up significantly particularly for small businesses – it’s nearly doubled over the last year.

£600k - £1.15m

is the average cost to a large UK organisation of its worst security breach of the year

£65k - £115k

is the average cost to a small UK business of its worst security breach of the year

Organisations of all sizes continue to suffer from external attacks

Attacks by outsiders continue to cause most security breaches to all organisations. Malicious software is increasingly the means for such attacks. The focus of attacks seems to have shifted back towards large organisations.

55%

of large UK businesses were attacked by an unauthorised outsider in the last year (down from 66% a year ago)

73%

of large UK organisations suffered from infection by viruses or malicious software in the past year (up from 59% a year ago)

38%

of large UK organisations were hit by denial of service attacks in the last year (similar to the 39% a year ago)

24%

of large UK organisations detected that outsiders had successfully penetrated their network in the last year (up from 20% a year ago)

16%

of large UK organisations know that outsiders have stolen their intellectual property or confidential data in the last year (up from 14% a year ago)

(Public sector information licensed under the Open Government Licence v3.0.)

Bespoke security policy

Traditional defensive tools such as antivirus and IAMS help to protect against malware and unauthorised access, but hackers are continually searching for new attack vectors to compromise information security. Organisations need to have effective preventive, detective and administrative tools to cover risk management, the protection of data assets and business continuity.

In recent years SAP ® systems have been widely connected to the internet and have adopted open source standards and protocols to increase connectivity. An organisation’s IT estate is likely to encompass a range of SAP ® and proprietary systems that further add to the complexity of security planning. At present there is no central security component, but SAP ® provide a powerful array of controls that can be weaved into a bespoke security policy using a layered defence.

OWASP Top Ten Security Risks

The Open Web Application Security Project (OWASP) is a prominent not-for-profit organisation that is dedicated to supporting organisations to develop and maintain secure web applications. OWASP list the Top Ten Most Critical Web Application Security Risks that is regarded as an authoritative analysis of the threat landscape for Internet enabled applications.

SAP ® systems need to be patched and secured and regularly upgraded less they become vulnerable to the attack vectors identified in the OWASP Top Ten. Furthermore, there are other risks to consider when planning your security programme such as user access and authentication, web service vulnerabilities and regulatory requirements.

OWASP Top Ten (Open Web Application Security Project)

The ten most critical web application security risks and their controls in SAP ® systems

A1 – InjectionInjection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. Input validation of SAP ® fields and remove/escape illegal characters. The OWASP preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface.
A2 – Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities. The SAP NetWeaver ® platform features central routines for user authentication and single sign-on that cannot be bypassed. Different authentication strengths can be configured, such as user/password or digital certificates, and certified interfaces exist to plug-in partner solutions.

Create a whitelist / blacklist in the sqlnet.ora file for host names or IP addresses
Review the REMOTE_OS_AUTHENT parameter setting for remote database access.
A3 – Cross-Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Input validation and SAP Secure Programming Guidelines ®. BSP/HTMLB or WebDynpro should be used in combination with ACL whitelists.
A4 – Insecure Direct Object References A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):

1. Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources.
2. SAP Access Control ®. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
A5 – Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date. Configure to a level that provides a baseline security using standard SAP settings. Develop a consistent system hardening process and regular software updates. Development, QA, and production environments should all be configured identically.

Tasks include: ensure ports and services that are not required are closed, restrict access to BASIS functions, access and identity management and security patch management.

A strong SAP ® application architecture that provides good separation and security between components.

Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.
A6 – Sensitive Data Exposure Many web applications do not properly protect sensitive data, such as credit cards, tax ids, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. Do all of the following, at a minimum:

1. Consider the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit.
2. Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
3. Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
4. Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
5. Disable autocomplete on forms collecting sensitive data and disable caching for pages displaying sensitive data.
A7 – Missing Function Level Access Control Virtually all web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access unauthorized functionality. SAP provides a consistent and easily analysable authorization module that is invoked from all your business functions.

1. Configure the process for managing entitlements and ensure you can update and audit easily. Don’t hard code.
2. The enforcement mechanism denies all access by default, requiring explicit grants to specific roles for access to every function.
3. Workflow conditions need to be in the proper state to allow access. NOTE: Most web applications don’t display links and buttons to unauthorized functions, but this “presentation layer access control” doesn’t actually provide protection. You must also implement checks in the controller or business logic.
A8 – Cross-Site Request Forgery (CSRF)A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. Preventing CSRF usually requires the inclusion of an unpredictable token in each HTTP request. Such tokens should, at a minimum, be unique per user session.

The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is subject to exposure.

The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs the risk that the URL will be exposed to an attacker, thus compromising the secret token.
A9 – Using Known Vulnerable Components Vulnerable components, such as libraries, frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause serious data loss or server takeover. Applications using these vulnerable components may undermine their defences and enable a range of possible attacks and impacts. Ensure that you keep your components up-to-date. Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version.
A10 – Unvalidated Redirects and ForwardsWeb applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Safe use of redirects and forwards can be done in a number of ways:

Simply avoid using redirects and forwards.

If used, don’t involve user parameters in calculating the destination. This can usually be done.

If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorised for the user.

Copyright © 2003 – 2013 The OWASP Foundation

Other Security Considerations

Virus and MalwareVirus Protection is required as a baseline security measure.The SAP Virus Scan Interface ® has built in scanning for:

GUI_UPLOAD in the SAP ABAP Stack
HTTP_UPLOAD (BSP)
FileUpload of WebDynpro for Java.
Secure Remote Function Calls (RFCs)Default RFC communication is performed in clear-text exposing data and log on information to network sniffing. SAP has released a number of patches for the RFC library and Secure Network Communications ® (SNC) can be used to encrypt network traffic.

Access to transaction SM59 and table RFCDES should be reviewed, and authorisation object S_RFCACL can improve the security of trusted RFC calls.
Secure configuration of the Gateway ServerMan In The Middle Attacks can involve the manipulation of RFC calls that are intended for a legitimate external server before returning the results to the requesting client through the Gateway. Such an attack could be used to modify RFC requests and the data returned to SAP systems.Monitor / disable remote access to the Gateway Server that controls traffic between SAP and external systems.
Buffer OverflowBuffer overflows are a common attack vector to introduce malicious code to an application.SAP Secure Programming Guidelines ® to provide Input validation of custom code and conduct detailed reviews to discover and eliminate buffer overflow problems in custom code for the Web-facing technology components of SAP NetWeaver ® (SAP Web Application Server ®, SAP Internet Transaction Server ®, and SAP Enterprise Portal ®). Consider Penetration testing.
Java script attacks against the sandboxInternet browsers can open vulnerabilities to the application. Java is open source code that is vulnerable to reverse engineering.Controls can include disabling Java in the browser and using separate browsers for Java based web applications. Disable unnecessary services. Consider the SAP White Paper recommendations to prevent a Java attack.
Program errorsInsecure custom code can introduce security vulnerabilities.SAP Secure Programming Guidelines ® can ensure a basic level of code security to counter problems such as race conditions, inadvertent information disclosure in error messages and anonymous web browsing.
Controlling SAP UsersSAP ® has numerous default users and passwords that require secure configuration.Administrators should change the default passwords of standard users and design control strategies for all privileged default users.
Password SecurityPassword security can be compromised by software tools to decrypt passwords.Standard SAP ® password security can be enhanced by disallowing backwards compatibility in the CDVN1 hashing algorithm.
Backdoors and RootkitsBackdoors and rootkits are often very difficult to detect in the thousands of lines of code in typical application software.SAP Code Inspector ® can be used to guard against backdoors and rootkits in critical programs.
Secure Web servicesWeb services should be hardened in line with SAP recommendations.Customise error pages so they do not display sensitive system information about the target system such as hostname, SSID and system number.

Disable unnecessary services and follow the SAP security recommendations ® in the guide Secure Configuration, SAP Netweaver Application Server ABAP ®.
Secure the SAP GUI ® and web clientsPotential buffer overflow vulnerabilities have been identified and have been addressed by SAP patches.

Web clients can be vulnerable to phishing attacks.
SAP GUI ® should be patched or upgraded against known buffer overflow vulnerabilities. Consider disabling SAP GUI scripting and virtualisation options.

Phishing attacks can be addressed by user education, using SSL/TLS to enable users to identify legitimate websites, URL filtering to block malicious sites, and hardening, upgrading and patching Internet browsers.

Copyright © 2003 – 2013 The OWASP Foundation

Enterprise Security Controls

IT departments must focus on vulnerabilities but they should also implement strong preventive security controls. SAP® provides a suite of security products that Soteria can implement to provide both a baseline level of security and a comprehensive layered defence.

Soteria can also advise on security practices that can be adopted on an enterprise level. The aim is to identify infrastructure flaws, such as the use of less secure protocols, and the selection of insecure vendor proprietary software and open source code. The use of escrow arrangements, password policies and data back-up is also recommended.