Layer Seven Security

Five Logs that Could Reveal a Data Breach in your SAP Systems

One of the most important discoveries uncovered by security researchers investigating the recent data breach at Anthem is that the original compromise may have occurred as early as April 2014, nine months before the breach was discovered by the organisation.  The attack has led to the loss of personal information impacting over 80 million individuals. The investigation into the impact on health records stored by the organisation is ongoing. Such records have a far higher value in underground markets than financial data including banking and credit card information.

Anthem was alerted of the breach after a system administrator learned that his logon credentials had been compromised and used by attackers to access servers containing sensitive data. The fact that the discovery was made by Anthem itself should be applauded. The majority of breaches are not. Most are detected by law enforcement agencies, third parties, and even customers. However, the time lag between the initial breach and its eventual discovery is a concern and one that is consistent with most other successful attacks. According to the 2014 Verizon Data Breach Investigations Report (DBIR) based on an analysis of 1300 confirmed data breaches and 63,000 security incidents, the gap between the average time taken by attackers to compromise their targets and the time taken by victims to discover a breach has been widening steadily since 2004. This suggests that attackers are developing and exploiting ever more effective methods to compromise organisations at a rate that outstrips the ability of companies to detect and defend against such attacks. This is despite higher spending on both security solutions and personnel.

Protecting information in SAP systems from attack vectors used successfully against organisations such as Anthem requires two critical countermeasures. The first is system hardening. The second is log monitoring. This article focuses on the second of these measures. The effective and timely review of forensic data captured by several SAP logs can enable your organisation to drive back attacks before they lead to a data breach.

The first category of logs covers network traffic patterns. Incoming and outgoing connections registered in ICM/ Web Dispatcher, SAProuter, message server and gateway server logs should be regularly reviewed for suspicious network activity. This includes connection attempts from unknown or unauthorized source IPs or during unusual hours, as well as sessions that involve the transfer of large volumes of bytes to external destinations. The latter is a clear sign of potential data theft.

The second category covers authentication and authorization logs that record logon attempts and the actual resources accessed after successful logons. The main source of such data in SAP systems is the Security Audit Log. However, for more granular information, you should review log entries in the Read Access Log which register views and changes to sensitive data fields. UME log events in the J2EE Engine can be monitored using the NetWeaver Administrator. Within this category, logon attempts using default accounts across multiple systems and during irregular hours are especially suspicious.

The third category covers changes for configuration settings, files, user accounts, documents, programs and tables.  Logging such changes will support the reconstruction of events and help contain any breach. Authorization, password and other changes impacting user master records are automatically stored in non-transparent SAP tables which can be viewed using transaction SU01. Change documents can be used to capture changes to sensitive data objects. Changes to critical tables can be logged using SE13 and analyzed through report RSTBHIST. Changes to productive systems implemented through SAP transports are recorded in CTS and TMS logs stored in both transport directories and tables E070 and E071. Changes to profile parameters in managed systems, including security-relevant areas, are logged in Solution Manager and can be analyzed using Configuration Validation or Change Analysis.

The fourth category covers application and system events that are not directly security-relevant but may indicate potential malicious activity. This includes system shutdowns and restarts, unscheduled or unauthorized backups and error messages for the usage of memory, disk, CPU and other system resources. Such information can be collected from Syslog and other host-level event logs. It can also be accessed through local or central SAP System logs using transaction SM21.

The final area covers database-level actions and events, particularly activities performed by privileged non-system users including the execution of ALTER, INSERT and DELETE commands and CREATE and GRANT schema changes. You can minimize the performance impact of database logging in some database versions and releases by creating context-dependant policies that limit logging to precise scenarios. Examples include database connections originating during specific time periods or from outside specific application servers identified by hostname or IP address.

Attackers may attempt to remove evidence of their actions by altering or deleting log records. Therefore, it is important to secure access to SAP tables and OS-level files containing log information. Also, log files should be replicated to independent time-synchronized servers and log data held directly in SAP systems should be periodically archived using the archiving transaction SARA.

Three Steps to Prevent a Sony-Scale Breach of Your SAP Systems

The recent attack experienced by Sony Pictures Entertainment may well prove to be the most significant breach of the year. By all measures, the impact has been devastating for the organization, leading to the loss of almost 40GB of data to attackers. This includes not only proprietary intellectual property such as digital media, blueprints and schedules, but also social security numbers, bank accounts and payroll information. The loss of some of this information has led directly to several lawsuits against the company. It has also severely damaged and undermined the Sony brand. The attack has illustrated the vulnerability and unpreparedness of organizations in the face of sophisticated, targeted cyber threats.

The most surprising fact about the breach is that it is the second time in three years that Sony has been the victim of such a destructive attack. Therefore, the company has drawn has a great deal of criticism for alleged security practices that arguably should have been stamped out following the previous breach in 2011. In terms of the monetary impact of the recent attack, many experts estimate that impairment charges could range between $70M-$80M for Sony. Some place the cost closer to $100M.

The attackers compromised digital certificates used to authenticate Sony’s servers and released information related to over 1600 Linux/ Unix and 800 Windows servers at the company, as well as IP and MAC addresses and computer names of over 10,000 PCs within its network. This includes many SAP servers. An analysis of the leaked data performed by Joris van de Vis available on the SAP Community Network revealed that the data includes SAP server hostnames, IP addresses, SAP System IDs (SIDs), and version information for operating systems and databases. It also includes username and password combinations stored in unencrypted files. However, the most damaging revelation is that the leaked data includes the results of security assessments performed for SAP systems at Sony. Such reports could provide attackers with insights into vulnerabilities impacting these systems.

This particular revelation leads to the first recommendation for how to prevent a Sony-scale breach of your SAP systems. It is suspected that the attackers targeted security groups and users at Sony in order to access information that could be used to aid their attack. Therefore, it is imperative to secure such information within your network. The use of desktop-based tools to audit SAP systems and the circulation of the output from such tools in common file formats such as Excel and PDF can pose a serious security risk. You can remove this risk by ensuring that security-related data never leaves your SAP systems. This can be achieved by avoiding the use of third-party tools. A more secure option is to leverage vulnerability management components in Solution Manager such as Configuration Validation. This will ensure that access to security-related data on managed systems is secured using the SAP authorization concept directly within SAP systems.

The second recommendation is to reexamine your current cost-benefit calculations or risk-reward ratios when determining resource requirements and spend levels for security countermeasures. Sony’s experience has illustrated that traditional assumptions no longer apply. The impact of a breach is not just technical or even financial but strategic and can cause far-reaching harm to your organization. Security is no longer a question of ‘just enough’. It’s all or nothing.

Our final suggestion is not to focus exclusively on your network security. The most effective strategies are designed from inside-out rather than outside-in. According to a recent survey published by the Ponemon Institute, most organizations allocate 40% of their security budget to network security. In contrast, database security receives an average of just 19%. These ratios should change to reflect a greater emphasis at the application, host and database level for defense in depth.

In the view of McAfee Labs, we can expect to see more headline-capturing attacks next year. The research group’s 2015 Threat Predictions report forecasts an increase in cyber attacks as state-affiliated, criminal and terrorist actors grow in number and employ ever more sophisticated and stealthier techniques against their targets. You can read the report at McAfee for Business.


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

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.

Layered Defenses in Oracle 12c: The New Benchmark for Database Security

Oracle databases support more than two thirds of SAP deployments in mid to large size enterprises. Oracle’s domination of the SAP database market is due to a widely regarded performance edge in areas such as compression, availability and scalability. Oracle databases are also optimized for SAP technology as a result of a long-standing partnership between Oracle and SAP that includes joint software development. Oracle development teams work closely with SAP developers in Walldorf, Germany to performance test Oracle releases against SAP systems and incorporate new Oracle features in SAP releases. Dedicated Oracle technical support teams are also based at SAP HQ in Walldorf to respond to escalated database issues reported by SAP customers.

Database security has improved markedly since the first R3 release on Oracle in 1992. Oracle pioneered Transparent Data Encryption (TDE) and granular access controls through the Database Vault for Release 2 of Database 10g. The latest generation of the flagship Oracle database incorporates more security enhancements than any previous release. Launched by Oracle on July 1, Database 12c introduces redaction capabilities designed to protect the display of sensitive data. Redaction masks sensitive data in real time based on user, group, application, IP address or other variables configured in declarative policies. Since redaction is context-dependant rather than universal, organisations are able to conceal sensitive data displayed in applications from specific groups while revealing it to others. Redaction compliments TDE used to protect sensitive data at the database level by extending data protection to the application level. Redaction can be used to partially or fully transform displayed information without altering data in buffers, caches or storage. It is enforced directly in the database kernel.

Oracle 12c also introduces an important enhancement to the Database Vault through Privilege Analysis. This feature can be used to identify unused permissions based on an analysis of the actual usage of roles and privileges. Enabling the new privilege capture mode through the Vault triggers an advanced logging feature that tracks the use of privileges granted to users and applications. This allows organisations to identify and remove unused permissions and roles and enforce access based on the principle of least privilege.

The third major innovation introduced in 12c is Conditional Auditing. The ability to configure precise, context-dependant logging should reduce the performance overhead associated with database auditing and enable more effective analysis of audit logs. Conditional Auditing supports highly selective logging policies that minimize log entries to specific events such as particular SQL statements including the actions CREATE or ALTER originating from outside specific application servers identified by IP address. Other variables include programs, time periods and connection types. Conditional Auditing also introduces AUDIT_ADMIN and AUDIT_VIEWER roles to better protect the integrity of policies and logs which are now part of single unified architecture. Database auditing in 12c can be integrated with the Oracle Audit Vault and Database Firewall, used to control and monitor SQL network activity. Unlike standard packet filter firewalls that operate at layers 3 and 4 of the OSI model, the Oracle Database Firewall performs highly accurate analysis of SQL traffic at layer 7 and can block SQL injection attacks.

Database 12c introduces Data Discovery and Modelling (DDM) and Sensitive Data Discovery (SDD) functions to scan for sensitive data. Once discovered, organisations are provided with built-in tools to protect information through a combination of encryption, redaction, masking and/or auditing.

12c also includes an improved authorization framework that incorporates the use of ACLs to control operations such as SELECT, INSERT, UPDATE and DELETE for database objects based on users or roles.

Taken together with pre-existing database security features such as TDE, privileged user management using schemas and roles based on protective zones known as realms, whitelisting for SQL statements using the Oracle Firewall, data labeling, online patching and configuration scanning, Oracle 12c provides a comprehensive suite of functions to counteract a wide array of internal and external threats while balancing requirements for performance and high availability. 12c sets a new standard for database security and should strengthen Oracle’s position as the preferred database for SAP customers.