Category: Database Security

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.

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.