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.
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.