Layer Seven Security

New SAP Guidance Recommends Configuration Validation for Security Monitoring

Some of the most critical recommendations issued by SAP in the recently released paper Securing Remote Function Calls include the use of configuration validation in Solution Manager to monitor RFC destination settings. This includes checks for destinations with stored credentials, trusted connections, and authorizations granted to RFC users in target systems. It also includes the review of profile parameters for RFC and secure network communication, as well as access control lists for RFC gateways. The SAP paper lends support for other security functions in Solution Manager such as management dashboards and alerts by pointing out that “an overview of the current security status can be provided in a security dashboard and alerts on noncompliance can be collected in the alert in-box” (p33).

The paper draws together leading practices and SAP recommendations into a single reference document for protecting one of the most vulnerable areas in SAP landscapes that is often targeted by remote attackers. RFC is a proprietary SAP technology that drives cross-system integration. Misconfigurations in RFC destinations and gateways that manage RFC communications can lead to the complete compromise of not just individual SAP systems but entire landscapes. Common mistakes include using destinations with stored logon credentials or trusted connections between systems with differing security classifications, using service or communication user types for RFC destinations rather than system users, granting excessive authorizations to RFC users, failing to limit access to remote-enabled function modules, and non-existent access control lists to control the registration and starting of external RFC servers.

The paper emphasizes the importance of established and well-known counter measures for securing RFCs based on the authorization concept. This includes not granting full access to objects such as R_RFC_ADM, S_RFC_TT, S_ADMI_FCD used to administer RFC destinations and other objects such as S_RFC , S_ICF and S_RFCACL that control access to remote-enabled function modules and logons in trusting systems. The paper also discusses enhancements delivered by SAP in the most recent release of NetWeaver AS ABAP, including unified connectivity (UCON). UCON blocks access to remote-enabled function modules using whitelists configured in so-called communication assemblies. According to SAP, “Typically, less than 5% of all available RFC function modules are used in customer software systems for remote RFC communication” (p14). It also outlines methods for performing short-term and long-term traces to identify authorizations checks performed during the execution of RFC-enabled function modules called remotely. This should be used to reign in access privileges for RFC users. Finally, the paper outlines how to control dangerous RFC callbacks and activate switchable authorization checks that are only enabled in specific RFC scenarios.

Contact an SAP Security Architect at Layer Seven Security for professional services to implement these and related SAP recommendations. Our SAP Cybersecurity Solution includes a gap assessment for all of the recommendations on RFC security issued by SAP in the paper.

To request a copy of the SAP paper Securing Remote Function Calls, email info@layersevensecurity.com.

Featured in SAPinsider: How to Build Security using SAP Solution Manager

Data breaches occur all too often and organizations are frequently left blindsided. As a result, cybersecurity has become a board-level issue across all industries. According to a recent survey of global business leaders, cyber risk is regarded as one of the most significant threats faced by corporations today, and is consistently rated higher than legislation, regulation, and other risks.

Even SAP systems are not immune from the anxiety surrounding cybersecurity. The architecture and complexity of SAP landscapes, as well as the form and volume of data typically managed within SAP systems, makes them targets for attackers. This was illustrated by the discovery of a modified Trojan that was targeting SAP clients in 2013. The malware targeted SAP GUI configuration files and was capable of malicious activities such as logging keystrokes; capturing logon credentials; and identifying, copying, and exporting files.

Responding to such threats is a daunting challenge. However, SAP customers do not have to look far for the tools to secure their systems from cyber threats. In fact, SAP offers a variety of tools with standard license agreements that can be leveraged immediately at zero cost.

Read more at SAPinsider

How to Secure SAP Systems from Password Attacks

Exploiting weak password hashes is one of the most common and successful attack scenarios used against SAP systems. The availability of open-source programs such as Hashcat and John the Ripper enables even novice hackers to perform attacks against SAP passwords. In fact, Hashcat is capable of breaking any SAP password encoded using the BCODE hash algorithm in a maximum of 20 hours, regardless of the length and complexity of the password.

SAP systems support a variety of cryptographic algorithms to convert passwords into hash values. These values are stored in table URS02. This is designed to prevent the storage of passwords in clear-text. During the logon procedure, passwords entered by users are converted to a hash value and compared to the value stored for the user in table USR02. The logon is successful if there is match between the two values.

Since hash algorithms are one-way, it is not possible to calculate passwords from hash values. However, it is possible to compare values generated by tools such as Hashcat to the values stored in SAP tables to break passwords providing both are encoded using the identical algorithm.

Therefore, it is critical to restrict the ability to read and extract password hash values in table USR02. This can be achieved by controlling direct access to database tables through SQL statements using firewall rules. The ability to read tables using generic table browsing tools accessible through transactions SE16, SE17 and SE11 should also be restricted and monitored.

Note that USR02 is not the only table containing password hash values. In some releases, hashes can also be found in tables USH02, USH02_ARC_TMP, VUSER001 and VUSR02_PWD. Such tables should be assigned to the authorization group SPWD (refer to Note 1484692). Access to table USRPWDHISTORY should also be restricted since attackers are often able to guess current passwords based on former passwords if users employ variations of the same password.

There should be similar restrictions on debugging and transport authorizations since these can also be used to access or export SAP tables containing password hashes.

Users with access to multiple systems or systems in different environments should be required to use different passwords for each system and environment. Passwords for productive systems should not be identical to those used to access development or test systems.

SAP password code versions A-E are based on the MD5 hashing algorithm. The hash values generated through this mechanism are stored in the table column BCODE. All MD5 hashes are susceptible to brute force and other password attacks. Code versions F and G use the SHA1 algorithm. SHA1 hashes are stored in the PASSCODE column. They are less vulnerable than MD5 hashes but can be broken if passwords are short and relatively non-complex. The most secure hashing algorithm supported by SAP systems is iterated salted SHA-1 in code version H. This mechanism uses random salts and a higher number of iterations to mitigate password attacks. Iterated salted SHA-1 hash values are stored in PWDSALTEDHASH.

SAP kernels should be upgraded to 7.02 or higher to support PWDSALTEDHASH hash values. For added security, default iterations and salt sizes can be increased using the login/password_hash_algorithm parameter.

Once this is performed, the profile parameter login/password_downwards_compatibility should be set to 0 to ensure only the strongest possible hash values are generated. CUA systems can be excluded from this requirement if they are connected to systems that do not support PWDSALTEDHASH.

The report CLEANUP_PASSWORD_HASH_VALUES should then be run to discover and remove redundant password hashes. There is a clear security risk if this is not performed. Attackers may be able to use passwords encoded in BCODE and PASSCODE hashes if users employ identical or similar passwords encoded in PWDSALTEDHASH.

Enforcing single sign-on (SSO) for all dialog users provides the optimal level of protection against password attacks by removing the need to store hashes altogether. However, once SSO is enabled, direct logons should be blocked through the parameter snc/accept_insecure_gui=U and by ensuring users are not exempted from SSO through settings in user records maintained in the SNC tab of SU01.

Taken together, these countermeasures should safeguard systems from dangerous password attacks aided by well-known and easily accessible tools that can be leveraged to take full control of SAP systems.

Update: A new version of Hashcat capable of cracking SAP code version H password hashes encoded using SHA-1 is currently in beta testing. You can learn more at http://hashcat.net/forum/thread-3804.html

A Five Step Guide to Securing SAP Systems from Cyber Attack Without Breaking the Bank

With SAP solutions deployed by 85 percent of Forbes 500 companies, they are a prized target for cyber attackers. Watch our Webinar playback to discover how to secure your SAP systems against targeted cyber attacks that could lead to denial of service, financial fraud or intellectual property theft. The Webinar is hosted by John Corvin, a Senior SAP Security Architect at Layer Seven Security. The insights delivered during the Webinar are based on lessons learned from hundreds of front-line engagements, aligned with leading practices and SAP recommendations and delivered by experienced SAP security consultants. Learn how to:

Secure SAP networks and communications
Protect remote function calls
Control critical user authorizations
Build log forensics
Configure security-relevant parameters

The Webinar will also enable you to identify opportunities for your organization to continuously monitor the security of SAP systems using standard tools and components available in SAP Solution Manager without licensing costly third party software. This will empower your organization to unlock the potential of SAP software and maximize the ROI of SAP licensing, while minimizing software-related capex and opex.

 

Can’t access YouTube? Watch on Vimeo: https://vimeo.com/107386560

Three More Reasons for using Solution Manager to Secure SAP Systems from Cyber Attack

Our recent article outlining the advantages of using SAP-delivered components versus third party software resonated strongly with customers seeking an effective and cost-efficient solution to address cyber threats impacting their SAP systems. The article examined the five key benefits of a Solution Manager-based strategy that included lower costs through the avoidance of licensing and maintenance fees for third-party software, the ability to configure custom security checks to address system, company or industry-specific risks, alerting for critical security events, detailed reporting driven by SAP Business Warehouse, and the availability of SAP support. The article presented a compelling argument for selecting SAP Solution Manager over the host of competing solutions offered by independent vendors.

The benefits delivered by Solution Manager stem from the depth and volume of security-related data that is continuously pulled from managed systems into the platform. Solution Manager lays at the core of SAP system landscapes and therefore occupies a central vantage point to oversee the security of connected systems. In contrast, third party software solutions are not embedded within SAP landscapes to the same extent and therefore lack the connectivity and range of Solution Manager.

Aside from the advantages mentioned above, there are three other benefits delivered by Solution Manager for security monitoring. The first is the availability of security dashboards. SAP delivers three security apps through the standard WebDynpro dashboard application in Solution Manager, located in the Cross-Application section for dashboard apps. This includes the Security Overview app, which summarizes security policy compliance by system across landscapes, the Security Details app, which displays compliance levels for software, configuration and user categories, and finally, the Security List app, which conveys security compliance levels for every SAP System ID. Dashboards apps can be automatically refreshed as often as every 5 minutes to provide security information in near real-time.

The second is Solution Manager’s ability to deliver detailed metrics for analyzing changes. Like third party solutions, components such as Configuration Validation in Solution Manager are able to pinpoint differences between actual and recommended security settings. However, Solution Manager goes a step further by enabling users to drill-down into the underlying changes that created risks identified by security scans. This is performed through Change Analysis which provides timestamps for changes in managed systems and the original values for instance, profile or other parameters before the changes were implemented.

The third is Solution Manager’s flexibility to support security policies aligned to any compliance framework. This includes not only familiar frameworks such as SOX and PCI DSS but requirements that are unique to specific industries or sectors. The transparent security checks performed by Configuration Validation can be customized for all regulatory, statutory and other forms of compliance standards.

Organizations do not have to look far for the solution to remove security vulnerabilities in their SAP systems. Most are delivered with standard license agreements by SAP and can be leveraged immediately at zero cost. Tools such as Configuration Validation provide a powerful and cost-effective alternative to third party solutions. They are also fully supported by SAP. You can learn more about SAP Configuration Validation here or contact Layer Seven Security to unlock the value of your Solution Manager systems.

Five Reasons You Do Not Require Third Party Security Solutions for SAP Systems

You’ve read the data sheet. You’ve listened to the sales spin. You’ve even seen the demo. But before you fire off the PO, ask yourself one question: Is there an alternative?

In recent years, there have emerged a wide number of third party security tools for SAP systems. Such tools perform vulnerability checks for SAP systems and enable customers to detect and remove security weaknesses primarily within the NetWeaver application server layer. Most, if not all, are capable of reviewing areas such as default ICF services, security-relevant profile parameters, password policies, RFC trust relationships and destinations with stored logon credentials.

The need to secure and continuously monitor such areas for changes that expose SAP systems to cyber threats is clear and well-documented. However, the real question is do organisations really need such solutions? In 2012, the answer was a resounding yes. In 2013, the argument for such solutions began to waiver and was, at best, an unsure yes with many caveats. By 2014, the case for licensing third party tools has virtually disappeared. There are convincing reasons to believe that such tools no longer offer the most effective and cost-efficient solution to the security needs of SAP customers.

The trigger for this change has been the rapid evolution of standard SAP components capable of detecting misconfigurations that lead to potential security risks. The most prominent of these components is Configuration Validation, packaged in SAP Solution Manager 7.0 and above and delivered to SAP customers with standard license agreements. Configuration Validation continuously monitors critical security settings within SAP systems and automatically generates alerts for changes that may expose systems to cyber attack. Since third party scanners are typically priced based on number of target IPs, Configuration Validation can directly save customers hundreds of thousands of dollars per year in large landscapes. The standard Solution Manager setup process will meet most of the prerequisites for using the component. For customers that choose to engage professional services to enable and configure security monitoring using Solution Manager, the cost of such one-off services is far less than the annual licenses and maintenance fees for third party tools.

The second reason for the decline in the appeal of non-SAP delivered security solutions is a lack of support for custom security checks. Most checks are hard-coded, meaning customers are unable to modify validation rules to match their specific security policies. In reality, it is impossible to apply a vanilla security standard to all SAP systems. Configuration standards can differ by the environment, the applications supported by the target systems, whether the systems are internal or external facing and a variety of other factors. Therefore, it is critical to leverage a security tool capable of supporting multiple security policies. This requirement is currently only fully met by Configuration Validation.

The third reason is security alerting. While some third party solutions support automated scheduled checks, none can match native capabilities in Solution Manager capable of the near-instant alerting through channels such as email and SMS.

The fourth and fifth reasons are shortcomings in reporting and product support when compared to the powerful analytical capabilities available through SAP Business Warehouse integrated within Solution Manager and the reach of SAP Active Global Support.

More information is available in the Solutions section including a short introductory video and a detailed Solution Brief that summarizes the benefits of Configuration Validation and professional services delivered by Layer Seven to enable the solution in your landscape. To schedule a demo, contact us at info@layersevensecurity.com.

SAP HANA: The Challenges of In-Memory Computing

This article is an extract from the forthcoming white paper entitled Security in SAP HANA by Layer Seven Security. The paper is scheduled for release in November 2013. Please follow this link to download the publication.

According to research performed by the International Data Corporation (IDC), the volume of digital information in the world is doubling every two years. The digital universe is projected to reach 40,000 exabytes by 2020. This equates to 40 trillion gigabytes or 5200 gigabytes for every human being in the world in 2020. As much as 33 percent of this information is expected to contain analytic value. Presently, only half of one percent of available data is analyzed by organisations.

The extraction of business intelligence from the growing digital universe requires a new generation of technologies capable of analysing large volumes of data in a rapid and economic way.  Conventional approaches rely upon clusters of databases that that separate transactional and analytical processing and interact with records stored in secondary or persistent memory formats such as hard disks. Although such formats are non-volatile they create a relatively high level of latency since CPUs lose considerable amounts of time during I/O operations waiting for data from remote mechanical drives. Contemporary persistent databases use complex compression algorithms to maximise data in primary or working memory and reduce latency. Nonetheless, latency times can still range from several minutes to days in high-volume environments. Therefore, persistent databases fail to deliver the real-time analysis on big data demanded by organisations that are experiencing a significant growth in data, a rapidly changing competitive landscape or both.

In-memory databases promise the technological breakthrough to meet the demand for real-time analytics at reduced cost. They leverage faster primary memory formats such as flash and Random Access Memory (RAM) to deliver far superior performance. Primary memory can be read up to 10,000 times faster than secondary memory and generate near-zero latency. While in-memory technology is far from new, it has been made more accessible to organisations by the decline in memory prices, the widespread use of multi-core processors and 64-bit operating systems, and software innovations in database management systems.

The SAP HANA platform includes a database system that processes both OLAP and OLTP transactions completely in-memory. According to performance tests performed by SAP on a 100 TB data set compressed to 3.78 TB in a 16-node cluster of IBM X5 servers with 8 TB of combined RAM, response times vary from a fraction of a second for simple queries to almost 4 seconds for complex queries that span the entire data range. Such performance underlies the appeal and success of SAP HANA. Since its launch in 2010, SAP HANA has been deployed by 2200 organisations across 25 industries to become SAP’s fastest growing product release.

SAP HANA has emerged against a backdrop of rising concern over information security resulting from a series of successful, targeted and well-publicized data breaches. This anxiety has made information security a focal point for business leaders across all industry sectors. Databases are the vessels of business information and therefore, the most important component of the technology stack. Database security represents the last line of defense for enterprise data. It should comprise of a range of interdependent controls across the dual domains of prevention and detection.

The most advanced persistent databases are the product of almost thirty years of product evolution. As a result, today’s persistent databases include the complete suite of controls across both domains to present organisations with a high degree of protection against internal and external threats. In-memory databases are in comparison a nascent technology. Therefore, most do not as yet deliver the range of security countermeasures provided by conventional databases. This includes:

Label based access control;
Data redaction capabilities to protect the display of sensitive data at the application level;
Utilities to apply patches without shutting down databases; and
Policy management tools to detect database vulnerabilities or misconfigurations against generally-accepted security standards.

The performance edge enjoyed by in-memory database solutions should be weighed against the security disadvantages vis-a-vis persistent database systems. However, it should be noted that the disadvantages may be short-lived. Security in in-memory databases has advanced significantly over a relatively short period of time. The most recent release of SAP HANA (SPS 06), for example, introduced a number of security enhancements to SPS 05 released a mere seven months earlier. This includes support for a wider number of authentication schemes, the binding of internal IP addresses and ports to the localhost interface, a secure store for credentials required for outbound connections and more granular access control for database users.

The most crucial challenge to database security presented by the introduction of in-memory databases is not the absence of specific security features but architectural concerns. Server separation is a fundamental principle of information security enshrined in most control frameworks including, most notably, the Payment Card Industry Data Security Standard (PCI DSS). According to this principle, servers must be single purpose and therefore must not perform competing functions such as application and database services. Such functions should be performed by separate physical or virtual machines located in independent network zones due to differing security classifications that require unique host-level configuration settings for each component. This architecture also supports layered defense strategies designed to forestall intrusion attempts by increasing the number of obstacles between attackers and their targets. Implementation scenarios that include the use of in-memory databases such as SAP HANA as the technical infrastructure for native applications challenge the principle of server separation. In contrast to the conventional 3-tier architecture, this scenario involves leveraging application and Web servers built directly into SAP HANA XS (Extended Application Services). Unfortunately, there is no simple solution to the issue of server separation since the optimum levels of performance delivered by in-memory databases rely upon the sharing of hardware resources between application and database components.

Aside from such architectural concerns, the storage of large quantities of data in volatile memory may amplify the impact of RAM-based attacks. Although widely regarded as one of the most dangerous security threats, attacks such as RAM-scrapping are relatively rare but are becoming more prevalent since attackers are increasingly targeting volatile memory to circumvent encrypted data in persistent memory. Another reason that RAM-based attacks are growing in popularity is that they leave virtually no footprint and are therefore extremely difficult to detect. This relative anonymity makes RAM-based attacks the preferred weapon of advanced attackers motivated by commercial or international espionage.

This paper presents a security framework for SAP HANA SPS 06 across the areas of network and communication security, authentication and authorization, data encryption and auditing and logging. It also provides security-related recommendations for the SAP HANA appliance and SAP HANA One. Taken together, the recommendations in this paper should support the confidentiality, integrity and availability of data in the SAP HANA in-memory database.

Securing Your SAP Systems: How to Counter Every Current and Emerging Threat

One of the highlights of the Sapphire conference earlier this month was the insightful session on SAP security delivered by Gordon Muehl, Senior Vice President of Product Security at SAP. A recording of the session can be viewed below. The session highlighted the threat presented to Internet-enabled SAP systems by external agents and stressed the importance of protecting systems against Web-based attacks such as verb tampering. According to SAP, such measures should include secure software development procedures and training for developers, as well as independent code reviews performed by specialized security resources to validate programs before release. SAP also recommends a proactive patch management strategy that includes regular monitoring of SAP Security Notes and the rapid application of high priority patches.

Layer Seven Security leverage leading SAP-certified solutions to secure SAP systems against external threats, identify code-level vulnerabilities and detect critical missing Security Notes. To learn more, contact a representative now.

Securing Your SAP Systems: How to Counter Every Current and Emerging Threat

Countering the Threat of Corporate Espionage

According to the results of a survey released by HBGary during the recent 2013 RSA Conference in San Francisco, more than 70 percent of American investors are interested in reviewing the cybersecurity practices of public companies and nearly 80 percent would not invest in companies with a history of cyberattacks. The survey of 405 U.S. investors also found that more than 66 percent of investors are likely to research whether a company has been fined or sanctioned for data breaches before making an investment decision. The survey underscores the fact that today’s investors are acutely aware of the impact of a successful breach on brand reputation and financial performance. This includes the breach of both customer data and intellectual property (IP).

Although the former tends to attract more public attention, the latter has a more pervasive effect on corporate competiveness and performance. A 2012 FBI report entitled Economic Espionage: A Foreign Intelligence Threat to American Jobs and Homeland Security revealed that the cost of IP theft to U.S companies resulting from commercial espionage was over $13 Billion in the last fiscal year. IP-intensive industries account for almost 35 percent of U.S. gross domestic product (GDP) and over 60 percent of merchandise exports. Furthermore, they support 40 million jobs in the United States.

Legal protections such as copyrights, patents and trademarks do not effectively protect intellectual property that is susceptible to theft to regions in which such protections are ineffectively enforced. The importance of IP to the national economy and the difficultly of enforcing rights outside the U.S has led the Department of Homeland Security to brand IP theft as one of the most dangerous threats to national security. In the words of the Assistant Director of the FBI’s Counterintelligence Division, “with each year, foreign intelligence services and their collectors become more creative and more sophisticated in their methods to undermine American business and erode the one thing that most provides American business its leading edge; our ability to innovate.” In a statement to a subcommittee of the House of Representatives last year, the Assistant Director cited the efforts of a foreign corporation to extract information related to the production of titanium dioxide from the DuPont Corporation in 2011. DuPont is an industry leader in the market for titanium dioxide, estimated to be worth $12 Billion.

Although IP theft is far from new, it is amplified by globalization, the increasing interconnectedness of business partners and the accessibility of electronically-stored intellectual property.

In response, the U.S Government Accountability Office (GAO) recommends a variety of technical controls designed to manage access to information, ensure system integrity and encrypt sensitive data. This includes measures to safeguard network boundaries, enforce authentication and authorization, protect against malware, secure communication paths, and analyze, detect and patch vulnerabilities.

The protection of intellectual property within SAP environments requires a combination of countermeasures covering the triad of people, process and technology. The importance of the first and second of these areas should not be understated. Data breaches often result not from the absence of effective technical controls but employee actions or inactions caused by a lack of awareness and training. Therefore, data protection policies and procedures, including incident response plans, are an important component of strategies to safeguard intellectual property. Process-level measures should include risk assessments to isolate and classify IP, and to identify relevant threats.

Technical countermeasures should include secure landscape architectures. Firewalls and proxy servers should be used to filter access to SAP systems with properly configured ingress and egress rules. Furthermore, network traffic should be monitored and controlled through in-line intrusion prevention systems and Security Information and Event Management (SIEM) systems capable of detecting and responding to certain types of attacks. Data Leak Prevention (DLP) technologies can also be deployed to block the exfiltration of confidential data. Unfortunately, network-level controls are often side-stepped by targeted and sophisticated attacks. DLP, for example, can be by-passed by encoding, encrypting and transmitting data out of corporate networks using protocols such as VOIP rather than methods such as SMTP and FTP, commonly monitored by DLP systems.

Therefore, technical countermeasures must be applied within multiple, interdependent areas to safeguard SAP assets. This includes application, platform, program and end-user areas. Layer Seven Security’s new white paper, Defense in Depth: An Integrated Strategy for SAP Security, outlines a layered approach to protecting data in SAP systems. The paper discusses methods to secure SAP applications, programs, servers, databases, and other components against attacks that attempt to exploit common weaknesses in such environments and extract proprietary, sensitive and valuable forms of intellectual property from organizations.

Lessons from the Top Ten Data Breaches of 2012: Defense-in-Depth for SAP Systems

According to the Privacy Rights Clearinghouse (PRC), there were 680 reported data breaches in 2012 covering all forms of commercial, governmental, educational, medical and non-profit organizations. The breaches are estimated to have compromised over 27M data records.

Top Ten Data Breaches 2012

 

The most significant breach occurred at VeriSign. Although the extent of the breach has never been disclosed nor, for that matter, the cause, the breach could potentially have an enormous impact on the ability of companies to establish secure connections to intended servers and verify the identity of those servers. This is because VeriSign is one of the principal issuers of SSL certificates used for encryption and mutual authentication. VeriSign also manages 2 of the world’s 13 root DNS servers, which control the complete database of Internet domain names and corresponding IP addresses. Although the breaches occurred during 2010, they were not disclosed by VeriSign until late 2011 when the company reported the incidents in public filings to the SEC. Guidelines issued by the SEC in 2011 now require registrants to “disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky“. A similar breach at the Dutch certificate authority Diginotar led the authority to file for bankruptcy in September 2011.

The second most significant data breach in 2012 was experienced by Global Payments, a large credit and debit card payments processor. The breach appeared to have stemmed from the compromise of servers in the company’s North American network but quickly spread to other areas of the network. According to initial estimates, approximately 1.5M records including Track 2 credit card data (card expiration date and credit card number) were directly exposed by the breach. This was later revised to 7M. Details on the cause of the breach have never been released by Global Payments. However, the company has disclosed that it has invested almost $85M on measures to improve security following the incident.

In the third major breach of 2012, a targeted phishing attack against employees at the South Carolina Department of Revenue led to the theft of usernames and passwords which were used by foreign attackers to access internal systems and other resources through remote services. Shortly thereafter, the attackers extracted over 8GB of data from the company through compressed database backup files. The files contained an estimated 5M social security numbers, 3M bank accounts and almost 400,000 credit card numbers. The attack may have been prevented through two factor authentication on remote access points. Furthermore, the damage would have been far lower had all the targeted data been encrypted.

Personal and financial records were also breached at the University of Nebraska, the fourth incident in the list. Banking information, social security numbers, addresses, grades and transcripts belonging to current and former students may have been compromised during a targeted attack against some of the organization’s databases.

The fifth and sixth incidents in the list did not involve the breach of financial data. However, they did involve the loss of hundred of thousands of customer records including social security numbers, drivers license numbers, dates of birth and employer information. Both breaches were caused by improperly configured servers. In the case of the Utah Department of Health, a default password had not been changed on one of the compromised servers. In both cases, the effected data had not been encrypted.

In the seventh most important data breach of 2012, an undisclosed vulnerability is suspected to have enabled unauthorized read-level access to a subscriber database at Intel. The database stored sensitive customer-related information including passwords, social security and credit card numbers in plain-text. However, there is reason to believe that the vulnerability was relatively short-lived and did not lead to the leakage of mass amounts of data, explaining the relatively low ranking of the incident. The group suspected to be responsible for the breach is also linked to similar breaches at NASA and US Bank in the same year.

The remaining incidents in the list involved the breach of large volumes of customer-specific data including names, addresses, phone numbers and email addresses from well-known e-commerce companies. In some cases, credit card data and passwords were also effected but the difference between these incidents and those placed higher on the list lies in the fact that sensitive data was encrypted. LinkedIn, for example, used SHA-1 to encrypt passwords. The exception is Yahoo!: over 400,000 were extracted from the company’s servers in plain-text through a SQL injection attack. All three organizations, Zappos, LinkedIn and Yahoo!, are subject to lawsuits for allegedly failing to properly safeguard user data.

Defense-in-Depth for SAP Systems

The incidents reviewed in this article cover a broad spectrum of organizations and industries. Clearly, the risk of data breach is no longer the sole preserve of e-commerce companies running custom-developed programs accessible to the general public through Web application servers. In fact, the most significant breaches effected enterprise systems designed principally for internal use. This should come as no surprise. Most system landscapes are highly integrated with multiple access points. This presents a large attack surface and provides opportunities to vault from compromised systems to connected systems by exploiting trust relationships and communication pathways required to successfully integrate applications in such landscapes.

SAP landscapes are a prime example of highly integrated environments supporting a variety of services through ports and protocols that include HTTP (80), HTTPS (443) and SMTP (25), commonly used by Web application servers. Therefore, SAP systems must be protected against the identical attack vectors that led to many of the data breaches discussed above. This includes methods such as SQL injection, exploitation of default passwords and configurations, and insecure system interfaces.

Protection should be applied at four distinct levels. The first is the authorization level. SAP systems contain thousands of authorizations that control access to various functions and resources. The improper assignment of authorizations can lead to the accumulation of access rights that may provide users with privileges beyond role requirements. Such privileges may be abused to compromise the confidentiality and integrity of information in SAP systems. Therefore, the proper assignment of authorizations and the maintenance of an adequate segregation of duties is the first pillar of SAP security.

The second area is the platform level which is comprised of two components.  The first component is the secure configuration of the SAP NetWeaver Application Server. This includes network filters that restrict access to SAP services accessible from end-user networks, configuring ACL files for SAP Gateways and Message Servers, enabling SNC and SSL to encrypt network communications, robust password policies, the use of the latest password hashing algorithms, disabling and/or changing passwords for default users, disabling dangerous Web services, securing RFC connections, and regularly patching SAP systems.

The second component of platform level security is the configuration of underlying databases and operating systems in accordance with vendor-specific recommendations or generally-accepted security benchmarks. For example, Oracle databases supporting SAP systems should be secured in accordance with the comprehensive security guides issued by Oracle for each database version. In some cases, vendor-specific recommendations may conflict with SAP requirements. Therefore, recommendations must be applied carefully and selectively, wherever appropriate.

The third area is the program level. SAP programs should be protected against unauthorized changes. Furthermore, custom programs should be developed, tested and deployed in a secure manner to ensure they are not susceptible to code-level vulnerabilities. This includes missing or broken authorization checks, backdoors and rootkits, injection flaws, cross-site scripting, buffer overflows and directory traversals. An effective software development process including requirements for code reviews by appropriately trained resources could meet part of this requirement. However, SAP programs are more effectively controlled through tools that act as a firewall to prevent the deployment of vulnerable code and tools that detect and auto-correct suspicious statements in ABAP code. Currently, the only solution capable of performing both functions is CodeProfiler, developed by Virtual Forge.

The final area of a complete SAP security framework is client-level protection. For SAP GUI, this should include disabling scripting and recording, enabling SNC encryption, and appropriate security module settings. For browser-based access, SAP applications should be located in a trusted zone with less restrictive security settings. This will enable active scripting of Java applets required for certain SAP components without lowering the general security profile of browsers for untrusted connections. Client-level security should also include malware protection, Web filtering and restrictions on the administrative privileges of end-users.

The appropriate management of risks at all four levels in contemporary SAP environments (authorization, platform, program and client) will provide the defense-in-depth required to withstand sophisticated and determined attacks against SAP systems and minimize the risk of a data breach.