April 2012 - Layer Seven Security

A Ten Step Guide to Implementing SAP’s New Security Recommendations

admin on April 19, 2012

On January 16, SAP issued a revamped version of the whitepaper Secure Configuration of SAP Netweaver Application Server using ABAP, which is rapidly becoming the de-facto standard for securing the technical components of SAP. According to SAP, the guidance provided in the whitepaper is intended to help customers protect ABAP systems against unauthorized access within the corporate network. In fact, many of the recommendations can also be used to protect SAP systems against remote attacks originating outside such a network. These attacks are targeted at the technical components of SAP Netweaver that are responsible for managing user authentication, authorization, encryption, passwords and system interfaces, as well as underlying databases and operating systems. Breaches in these components can enable attackers to take complete control of an SAP environment.

The following is a quick guide to help you comply with SAP’s recommendations.

1. Disable unnecessary network ports and services. In most cases, this means blocking all connections between end user networks and ABAP systems other than those required by the Dispatcher (port 32NN), Gateway (33NN), Message Server (36NN) and HTTPS (443NN). NN is a placeholder for your SAP instance number. Administrative access should only be allowed through secure protocols such as SSH and restricted to dedicated subnets or workstations through properly configured firewall rules.

2. Install the latest version of SAP GUI. This should be 7.10 or 7.20 with activated security rules configured with the ‘Customized’ setting and the ‘Ask’ default action.

3. Implement strong password policies, restrict access to password hashes in tables and activate the latest hashing algorithms. SAP does not specify the exact settings for password policy parameters but you should use frameworks such as the PCI DSS as a proxy. Refer to section 8.5 of the standard. Default passwords should be changed for standard users and the password hashing mechanism should be upgraded to the latest version available for your system. Wherever possible, downward-compatible hashes should be removed from the database.

4. Enable SNC and SSL. SAP client and server communication traffic is not cryptographically authenticated or encrypted. Therefore, data transmitted within SAP networks can be intercepted and modified through Man-In-The-Middle attacks. Secure Network Communication (SNC) should be used for mutual authentication and strong encryption. This can be performed natively if both servers and clients run on Windows. You will need to use a third party product to secure connections between heterogeneous environments such as AIX to Windows.

SNC will secure network communication using the SAP DIAG and RFC protocols. For Web-based communication, you should switch to HTTPS/ SSL and restrict access to the relevant cryptographic keys.

5. Restrict ICF services. Many of the services enabled by default in the Internet Communication Framework (ICF) are open to abuse and could enable unauthorized and malicious access to SAP systems and resources. At a very minimum, you should deactivate the dozen or so services mentioned by SAP in the white paper. This can be performed through transaction SICF.

6. Secure Remote Function Calls (RFC). Wherever possible, remove trust relationships between systems with differing security classifications and hardcoded user credentials in RFC destinations. The belief that RFC connections using SAP_ALL privileges is fine as long as the user type is not set to dialog is a myth. This represents a serious risk to the integrity of information in SAP systems.

7. Secure the SAP Gateway. The Gateway is used to manage RFC communications which support SAP interfaces such as BAPI, ALE and IDoc. Access Control Lists (ACL) should be created to prevent the registration of rogue or malicious RFC servers which can lead to the interruption of SAP services and compromise data during transit. You should also enable Gateway logging and disable remote access.

8. Secure the SAP Message Server. The Message Server is primarily a load balancer for SAP network communications. Similar to the Gateway, it has no default ACL which means it is open to the same type of attacks. You should filter access to the Message Server port using a firewall and create an ACL for all required interfaces.

9. Regularly patch SAP systems. Implement missing SAP Security Notes and patch systems at least once a month. Security Notes can be downloaded from the SAP Service Market Place.

10. Regularly monitor the SAP security configuration. Standard SAP services such as EarlyWatch (EWA) and the Computing Center Management System (CCMS) can be used to monitor some security-relevant configurations. However, they do not provide the same coverage as professional-grade security tools such as those used by Layer Seven Security. You can learn more about SAP security monitoring through vulnerability assessment here. To discover why vulnerability assessments should be an integral component of your SAP security framework, click here.

SAP had reservations with Deloitte’s blueprint for Marin County

admin on April 18, 2012

After recently losing Beneficial Mutual as an audit client, Deloitte suffered another major setback last week. While a U.S District Court Judge dismissed racketeering and other claims against the firm made by Marin County as a result of what the Californian authority considered a botched implementation of SAP for Public Sector, the court declared that the county had a plausible claim of bribery against Deloitte.

In the $30M complaint against Deloitte attached below, Marin County alleged that Deloitte had misrepresented its skill and experience to obtain the contract for the implementation, staffed the project with inexperienced consultants and deliberately concealed issues and risks arising during the implementation from the county. This included a practice of under-testing and “truncated, simplistic and incomplete tests that were intended to produce positive results to create the false impression, prior to the go-lives, that the SAP system was in fact ready for production”. It also included alleged bribing of the county official overseeing the project. After the implementation failed to support basic financial, payroll and HR functions, Deloitte offered costly post-production support to the county to address the problems plaguing the system.

The county eventually scrapped the implementation, despite paying $11M in consulting fees, and alleged that Deloitte’s conduct was consistent with the approach used by the firm during similar SAP implementations for public organisations in Los Angeles, San Antonio, Colorado and Miami-Dade.

During initial hearings, SAP declared that it had expressed concerns with Deloitte’s blueprint designs which put the county “at risk of an improperly designed system which could lead to substantial rework … or a re-implementation after go live”. However, this did not appear to have led SAP to question earlier accolades it had made regarding Deloitte’s ‘depth and breadth of skills and services’ or Service Partner Awards bestowed by SAP to Deloitte.

Commenting on the Court’s decision, County Counsel Jack Govi stated that “the county is confident that Deloitte will be held accountable for its misconduct, which has cost the county of Marin taxpayers millions of dollars”.

The case highlights the importance of selecting the right system integrators for SAP implementations and the problems that arise from misaligned objectives between business partners during transformations. Customers, vendors and system integrators should remain focused on shared objectives rather than their own specific goals which often conflict with those of the project.

When do default passwords become a configuration error?

admin on April 13, 2012

The answer is when your Legal department is managing the fallout after a data breach. The case in point is the Utah Department of Health which announced this week that over 280,000 records belonging to Medicaid and CHIP recipients were compromised after a breach last week believed to be perpetrated by a group in Eastern Europe (http://www.health.utah.gov/databreach).

The group exported 25,000 files containing personal information including social security numbers, belonging to hundred of thousands of individuals. According to the Department, the breach was caused by “a configuration error at the authentication level of a server’s multilayer security system.” This seems like a rather euphemistic way of saying the server had a default password that the attackers were able to exploit. The Department states that it has implemented ‘corrective measures’ which presumably includes changing the password. It has also offered free credit monitoring for those effected by the breach.

To learn how to manage default users and passwords in SAP systems, download our free white paper at http://layersevensecurity.com/SAP_security_white_papers.html.

Why you should immediately patch the recent DoS Vulnerability in AIX

admin on April 11, 2012

IBM released an advisory in February for a Denial of Service (DoS) vulnerability in AIX versions 5.3, 6.1, and 7.1. The warning seems to have flown under the radar since so far, many companies running the effected AIX OS platforms for their SAP environments have yet to deploy the patch. The vulnerability relates to a flaw in ICMP packet handling. An ICMP echo reply with ID=1 can lead to a DoS. ICMP is part of the Internet Protocol Suite and can be used to relay query messages. Echo reply is a ping utility that can be executed remotely with no authentication and very little complexity. The vulnerability has a CVSS base score of 7.8 and exploitability sub-score of 10 which means it is rated as extremely dangerous. The relevant security update can be downloaded directly from IBM through ftp://aix.software.ibm.com/aix/efixes/security/icmp_fix.tar. Technical information is available at http://www-01.ibm.com/support/docview.wss?uid=isg1IV08255.