SOX Compliance Archives - Page 3 of 3

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.

The Hidden Danger of GRC

admin on February 4, 2012

Does anyone remember the world before GRC? I know it seems like decades ago but the fact is solutions such as SAP GRC are a relatively new phenomenon. Until recently, most of us were working with SU01 and SUIM. While such tools have undoubtedly made life easier for administrators and auditors alike, there’s a hidden danger associated with their use that I’ve observed over and over again when clients rely too heavily on them to secure their environments.

Before we get to that, here’s a brief survey of GRC platforms for readers looking to adopt or switch solutions:

Today’s GRC landscape is far more complex than a simple toss-up between Approva and SAP GRC (formerly Virsa). Although these platforms remain the most popular among large companies with thousands or even tens of thousands of users, the market includes a number of new upstarts that are worth considering if you’re looking to save some serious dollars without sacrificing functionality. This includes Alert Enterprise, Security Weaver, Xpandion and CSI Tools (the links are provided below). All of these vendors offer a suite of scalable applications designed to provision user access, monitor segregation of duties in real time and automate user access reviews.

The pros and cons of the different platforms depend upon what you’re looking for. However, one very important piece of advice is to define your requirements very clearly and stick to them throughout the selection process. This way, you won’t be swayed by clever marketing that offers you bells and whistles you’ll never use. I’ve lost count of the number of times I’ve seen security and audit groups buy vast GRC suites to monitor everything in sight when in fact all they really needed was a basic tool to check their authorizations once a year or, at best, every quarter. Truth be told, if this is what you’re looking for, you should consider sticking with SAP SUIM. It may be so slow and cumbersome, but it gets the job done for next to nothing.

There’s also another important benefit to persevering with standard SAP functions that’s often overlooked: working directly with SAP builds a familiarity and depth of understanding of your environment that’s hard to form when you’re dealing with SAP through GRC tools. It also requires more intellectual effort and therefore forces users to develop their investigative skills rather than rely upon canned queries and reports.

In the grand scheme of things, these are minor drawbacks. We could just as easily argue that the enormous time and effort freed up by GRC tools allows resources to be devoted to more value-added areas. True, but there is a far bigger concern that can’t be so easily dismissed.

In the minds of those that administer GRC tools, the very notion of what is and isn’t SAP security is closely associated with the scope of the software they use. In other words, these tools shape our conception of security. Time and again, we are lulled into a false sense of security because of the rosy picture painted by GRC software. Often, this turns out be a mirage when we are forced to widen our paradigm to include the security of technical components of SAP that are beyond the scope of these programs. SAP security is about more than authorizations. It’s even deeper than Basis. In fact, it reaches down into the very kernel of SAP. It includes areas that are new to the SAP landscape and others that are often simply overlooked or underestimated. Many of these areas are discussed in our whitepaper Perfect Storm: The Brave New World of SAP Security. The moral of the story is that the results of GRC tools should be taken with a pinch of salt. Locking down critical authorizations, users and configurables doesn’t mean that your SAP systems are secure or even compliant with SOX, PCI or other standards. It’s only a small part of a broader security strategy that should include managing the technical components of SAP Netweaver that can be highly vulnerable to internal and external attack.