Layer Seven Security

OPM Data Breach Reveals the Limitations of Cybersecurity Solutions

Layer Seven on June 23, 2015

The fallout from the record-breaking breach disclosed by the Office of Personnel Management (OPM) earlier this month reached a low point at a Capitol Hill hearing on June 16. During the hearing, members of the House Committee on Oversight and Government Reform scolded OPM officials and IT executives for their “complete and utter failure” to protect sensitive personal information stored in compromised systems. The breach is estimated to impact at least 3.2M federal employees and contractors. However, the number of breached records may be as high as 14M.

While the root cause of the breach is yet to be disclosed, there are several factors that are suspected to have contributed to the successful attack against the OPM. The first is OPM’s sluggish response to the recommendations of a systems audit performed by the Inspector General last year. The Inspector General Audit Report identified numerous material weaknesses in OPM’s security program and practices, including missing configuration baselines for operating platforms and ineffective security monitoring procedures. OPM has been widely criticized for failing to implement many of the key recommendations made by the Inspector General.

The second is weaknesses in cybersecurity tools put in place by the Department of Homeland Security to detect and contain the type of incident that led to the breach at OPM. The most widely criticized tool is Einstein, the multi-billion dollar intrusion detection system deployed by US-CERT to monitor government Internet gateways for malicious traffic. Einstein is at the cornerstone of the $4.5 billion U.S National Cybersecurity and Protection System (NCPS) program. Despite a recent $200M upgrade, it failed to expose the original attacks that led to the breach at OPM. Yet again, this serves to illustrate known limitations with signature-based intrusion detection systems that can be circumvented by scrambling or encrypting attack payloads. These and other drawbacks have led institutions such as SANS to conclude “It is far too easy to fool or shut down an IDS machine for them to be utilized as the primary line of defense against intruders”.

It also illustrates the broader concern over the effectiveness of cybersecurity solutions, not just network-based IDS or, for that matter, IPS systems. According to a joint study performed by Juniper Networks and RAND earlier this year, worldwide spending on cybersecurity is growing between 10 to 15 percent per year. However, despite investing increasing amounts on cybersecurity tools, most companies report a low level of confidence in the ability of such tools to improve the security of their infrastructure. This sentiment is understandable and is based on the questionable success of conventional tools to combat cyber threats. The irony of sky-rocketing costs for cybersecurity tools against the backdrop of the declining value of such tools is not lost on customers.

For this reason, organizations would be better served by redirecting budgets from dubious investments in redundant tools to tackling the most critical issue in cybersecurity today: the shortage of skilled resources capable of modelling and managing the wide array of risks in complex and evolving threat landscapes. The global cybersecurity skills shortage is borne out by the following startling facts:

83% percent of enterprises lack the skills to protect their IT assets (1)

1 out of 3 security professionals are not familiar with advanced persistent threats (2)

62% of organizations did not increase security training in 2014 (2)

There are 1M unfilled positions for security professionals worldwide (3)

One of the consequences of the skills shortage is that it often leads enterprises to rely on a patchwork of third parties for core security services. OPM, for example, is alleged to have granted privileged access to contractors in China, one of the nation states suspected of perpetrating the attack.

For SAP systems, the aim of fostering an effective security operations center or center of excellence is made easier by the availability of a wide array of powerful monitoring tools in Solution Manager. The most important of these tools is Configuration Validation (ConVal) which can be leveraged to implement automated, policy-based vulnerability management. The accessibility and convenience of tools such as ConVal eliminates the need for third party security software and enables customers to focus more resources on staffing, training and other needs.

ConVal performs system configuration monitoring. It also monitors critical authorizations, transactions and profiles. For security information and event monitoring (SIEM), most existing platforms can analyze event data in SAP log files including the Security Audit Log. Platforms such as HP Arcsight, RSA enVision, McAfee/ Intel, and Splunk can be tuned to review SAP logs using available connectors or modules. For more information on ConVal or integrating SAP systems with your SIEM platform, contact Layer Seven Security.

Sources:
1 ESG, March 2015
2 2014 APT Study, ISACA, April 2014
3 Annual Security Report, Cisco, January 2014

Are 95 percent of SAP systems really vulnerable to cyber attack?

Layer Seven on May 26, 2015

Earlier this month, SAP issued a strongly-worded response to claims made by the software vendor Onapsis in a press release that over 95 percent of SAP systems assessed by Onapsis were exposed to vulnerabilities that could lead to the compromise of SAP systems. According to SAP, “The press release published by Onapsis is aimed at alienating SAP customers while promoting Onapsis’ own products. The assertion that over 95% of SAP systems were exposed to vulnerabilities is false.” In spite of such protests, the claims led to a wave of concern over vulnerabilities in SAP systems. The concerns were deepened by the revelation that the data breach at the government contractor USIS reported in 2014 was caused by a vulnerability in an SAP ERP system. The forensic investigators engaged by USIS to review the breach concluded that attackers were able to gain access to the system by exploiting an undisclosed SAP-level vulnerability or series of vulnerabilities. This assertion was based on evidence contained within SAP application trace logs and other sources. The breach led directly to the leakage of highly sensitive information impacting an estimated 25,000 government employees.

Along with similar incidents experienced by the Greek Ministry of Finance and Nvidia, the breach at USIS has served to illustrate the devastating impact to organizations when SAP systems are not securely configured and monitored to guard against possible cyber attack. Since the news of the source of the breach became public, security researchers have put forward several theories of possible exploits that could have been employed by attackers to compromise SAP systems connected to USIS. The theories include the use of default passwords, vulnerabilities in RFC gateways, remote code execution, and even database-level exploits. The fact that the attackers were presented with such an array of possible vectors is disturbing to say the least and highlights the wide attack surface presented by SAP systems.

Unless the specific SAP vulnerability that was exploited to breach USIS was a zero-day exploit, its likely that the breach could have been prevented through the proper hardening of SAP systems, regular patching, and continuous monitoring using tools provided by SAP in Solution Manager. It should be noted that almost all the attack vectors presented by researchers to explain the attack at USIS can be blocked by either applying applicable SAP patches or by observing the relevant SAP security guidance. This also applies to the so-called ‘Top Three Common Cyber Attack Vectors for SAP Systems’ declared by organizations such as Onapsis. Furthermore, once hardened, SAP systems do not necessarily require third party tools to monitor for possible changes or configuration errors that may expose them to cyber threats. The simplest, quickest and most cost-effective strategy is to leverage tools available in Solution Manager. They include System Recommendations for patch management, Change Analysis for detecting and investigating configuration changes, Alerting for security incident and event management, Dashboards for compliance monitoring and finally, Configuration Validation for comprehensive, automated vulnerability management. In short, both the information and the tools you need to secure your SAP systems against the type of attack that breached USIS are available to you at this very moment.

Turn the Tide against Cyber Attacks with SAP Enterprise Threat Detection

Layer Seven on April 9, 2015

One of the most striking facts revealed by the 2014 Verizon DBIR is that only one in every six data breaches are detected by organizations that are the victim of such breaches. The statistic revealed that the vast majority of organizations lack the capability to detect incidents that lead to a data breach.

According to an earlier study sponsored by Oracle, organizations that have implemented incident detection capabilities are not necessarily any better off: nearly 70 percent require greater than one day to identify incidents of unauthorized system access. Given that most breaches unfold in less than a single day, organizations could suffer catastrophic losses before they even detect the underlying incident.

The problem is particularly acute for SAP environments. Maintaining a low mean time to detection is one of the key metrics used to measure the effectiveness of threat management programs. This is the gap between the time an incident occurs and the time the threat is detected and contained. While SAP systems generate a large quantity of logs in various formats, collating and parsing such logs presents several technical challenges, as well as consuming an extensive amount of time and resources. Performing such an analysis in near real-time using conventional tools is impractical, especially in high-volume environments that often generate several gigabytes of log data each hour. Hence, means times to detection are generally high for threat management programs encompassing SAP systems. This increases the vulnerability of such systems by providing adversaries with a longer timeframe to attack and compromise systems before detection.

Under these circumstances, the general availability of SAP Enterprise Threat Detection (ETD) on March 16 could not have been timelier. ETD is the only solution capable of providing visibility into potential insider and outsider threats impacting SAP systems in real-time. ETD minimizes mean times to detection and therefore shortens the timeframe that adversaries are provided to compromise and harm systems. It does so by harnessing the data streaming capabilities of the Event Stream Processor (ESP) and the ability of SAP HANA to analyze large and complex data sets instantaneously.

Log data is automatically extracted from monitored systems and components and pushed to a REST-based API exposed by ESP. Log information is harvested from a wide array of sources within each system including Gateway, HTTP, Business Transaction, Change Document, Read Access, System, Security Audit and User Change Logs. ETD SP01 also supports logs that use the UDP-based syslog protocol. Syslog is a common standard for capturing, labelling and transmitting system events for security auditing and other purposes. It is used by a wide variety of systems and components including, most notably, SAP HANA or, more specifically, the SUSE platform supporting HANA.

Once the log data is formatted and normalized by ESP, it is transferred to SAP HANA for storage and made available to ETD for analysis. Threat detection using ETD is performed primarily through pattern recognition. In other words, log data is evaluated by ETD to determine whether logged events match predetermined patterns for suspicious activity. Examples include logon attempts using standard users, multiple and concurrent failed logon attempts in the same system using the identical user, or changes to variables implemented during a debugging session. Patterns are risk-weighted by severity and trigger an alert whenever a match is detected by ETD. Alerts can be viewed through the ETD Dashboard or Launch Pad (see below).

Screenshot Launchpad

 

ETD SP01 includes over 50 patterns for ABAP systems based on SAP best practices. However, SAP recommends enabling and tuning patterns to address specific risks within each landscape and developing custom patterns using the Pattern Configuration tool bundled in ETD. Pattern identification and development is also performed by SAP Service Partners such as Layer Seven Security.

Future releases and enhancements of ETD will widen support for Java and cloud-based systems. SAP also intends to integrate ETD with Solution Manager for monitoring and incident management.

SAP ETD closes a critical gap exposed by limitations in existing SIEM and other solutions to absorb and analyze security-relevant event information stored in SAP logs. It also delivers the capability to identify and respond to security threats revealed by event data in real-time. For these reasons, ETD represents one of the most important technological innovations in SAP security in recent years and offers the most effective response to insider and outsider threats impacting SAP systems.

The use-cases for ETD can be illustrated by the recent insider breach at AT&T that led directly to a $25M FCC fine levied against AT&T. The breach centered on the accessing of personally-identifiable customer information by call center employees without authorization. This information was subsequently sold by the employees to third parties. Such a scenario can be mitigated in SAP systems through the integration of Read Access Logs with ETD. Providing the relevant patterns are appropriately configured, ETD would generate an alert when sensitive data fields are accessed by users frequently and in large volumes. Since the alert is generated as the incident is unfolding, it will provide investigators with the opportunity to respond to the incident in real-time and prevent the leakage of sensitive data.

To learn more about Enterprise Threat Detection, you can visit SAP at booth #S216 in the South Expo Hall at the upcoming RSA Conference. You can also contact Layer Seven Security.

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

Layer Seven on February 10, 2015

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.

SAP Cybersecurity Framework 2.0: What’s New?

Layer Seven on January 14, 2015

Since the official release of the SAP Cybersecurity Framework in 2014, the standard has become the de facto benchmark for securing SAP systems from advanced cyber threats. Drawing upon guidance issued directly by SAP, as well as the real-world experience of front-line SAP security architects and forensic investigators, the framework delivers a single point of reference to harden SAP systems from cyber risks. It enables enterprises to counter weaknesses in perimeter controls such as network firewalls and intrusion detection systems by securing the technical infrastructure of SAP systems. Vulnerabilities in such infrastructure could be exploited to bypass perimeter controls and corrupt or leak sensitive business information or perform denial of service attacks in SAP systems.

The threat posed by attackers that seek out and exploit vulnerabilities has reached epidemic proportions. By all measures, attacks are growing in frequency and sophistication. The number of threat actors is also increasing, ranging from organized gangs of cyber criminals to hacktivist groups and state-sponsored agents. Finally, the impact of cyber attacks has reached new levels. The cost of a successful data breach is no longer measured in purely monetary terms. Recent experience has demonstrated that the impact can be strategic and long-lasting.

The SAP Cybersecurity Framework fills the void created by weaknesses in perimeter security and the limitations of GRC software that focus exclusively on the SAP authorization concept. It empowers organizations to better understand and respond to lesser known risks in the technical components of SAP systems to greatly reduce the likelihood of a system breach. It also enables enterprises to improve breach detection capabilities to respond more rapidly to attacks and contain the impact.

What’s more, the framework provides a clear path for securing SAP systems from cyber threats using only standard SAP-delivered software. It demonstrates that effective strategies are not necessarily tied to licensing third party solutions but leveraging the host of security tools made available by SAP to customers without any additional expense. This includes automated vulnerability detection and alerting tools available in Solution Manager. It therefore provides a powerful and cost-effective alternative to approaches that revolve around purchasing, installing and configuring solutions from independent software vendors.

The SAP Cybersecurity Framework 2.0 improves upon the original standard by incorporating new SAP guidance in areas such as trace functions to identify authorizations required for RFC users, enabling switchable authorization checks, whitelists for RFC callbacks, and approaches for identifying required security patches included in Notes and support packages.

Trace Functions
There are several limitations with analyzing log data in event logs configured in the Security Audit Log and transaction STAD for restricting permissions for RFC users. The former only record function groups accessed by users and the latter is resource-intensive. Therefore, SAP recommends using short and long-term trace functions through transactions STAUTHTRACE, STRFCTRACE or STUSOBTRACE. This approach will reveal the function modules accessed by users and consume fewer system resources than STAD.

Switchable Authorization Checks
Switchable authorization checks are intended to strengthen security for critical remote-enabled function modules that are used to access or modify sensitive data by requiring additional authorization checks above and beyond the standard S_RFC check. They are delivered via Notes and support packages but should only be enabled after relevant user profiles are updated to include the new authorizations. The DUO and DUQ event logs of the Security Audit Log should be activated and reviewed to identify the specific users requiring the authorizations during a non-disruptive logging phase.

RFC Callbacks
Positive whitelists for systems with later versions of SAP Basis have been introduced by SAP to control the dangers posed by RFC callbacks. Callbacks enable servers to open RFC connections in clients during synchronous calls using the privileges of the RFC user in the client system. A new profile parameter rfc_callback_security_method is used to enable the whitelists which are configured using SM59.

Security Notes and Support Packages
The framework no longer recommends the use of the EarlyWatch Alert and RSECNOTE for the identification of relevant Notes and support packages. Both components have severe drawbacks and are effectively deprecated by SAP. Security Notes and support packages should be identified using System Recommendations accessed through the Change Management Work Center in Solution Manager or via WDC_NOTE_CENTER through the Easy Access Menu.

The SAP Cybersecurity Framework is presented in the white paper Protecting SAP Systems from Cyber Attack.

SAP Security Architects at Layer Seven Security perform comprehensive gap assessments against the recommendations of the SAP Cybersecurity Framework and enable customers to implement defense in depth by hardening the entire SAP technology stack. The layered control strategy supported by the framework is based on best practices and SAP security recommendations and represents the most comprehensive, efficient and cost-effective approach to secure SAP systems from cyber attack. To learn more, contact Layer Seven Security.

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

Layer Seven on December 19, 2014

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.

 

New SAP Guidance Recommends Configuration Validation for Security Monitoring

Layer Seven on December 2, 2014

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

Layer Seven on November 18, 2014

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

Layer Seven on November 4, 2014

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

FBI Director James Comey Speaks out on the Threat of Cybercrime

Layer Seven on October 9, 2014

During a candid discussion with host Scott Pelley of 60 Minutes at FBI headquarters in Washington DC, James Comey speaks out about the threat of cybercrime confronted by American citizens and corporations. Comey declares that cybercrime perpetrated by nation states, criminal syndicates and terrorist organizations has reached epidemic proportions and is directly costing the US economy billions of dollars a year.

Can’t access YouTube? Try Vimeo: https://vimeo.com/108513963

The following is a transcript of the excerpt:

James Comey: Cybercrime is becoming everything in crime. Again, because people have connected their entire lives to the Internet, that’s where those who want to steal money or hurt kids or defraud go. So it’s an epidemic for reasons that make sense.

Scott Pelley: How many attacks are there on American computer systems and on people’s credit card numbers and the whole mass of it? What does a day look like if you’re concerned with crime in cyberspace?

James Comey: It would be too many to count. I mean, I think of it as kind of an evil layer cake. At the top you have nation state actors, who are trying to break into our systems. Terrorists, organized cyber syndicates, very sophisticated, harvesting people’s personal computers, down to hacktivists, down to criminals and pedophiles.

Scott Pelley: What countries are attacking the United States as we sit here in cyberspace?

James Comey: Well, I don’t want to give you a complete list. But I can tell you the top of the list is the Chinese. As we have demonstrated with the charges we brought earlier this year against five members of the People’s Liberation Army. They are extremely aggressive and widespread in their efforts to break into American systems to steal information that would benefit their industry.

Scott Pelley: What are they trying to get?

James Comey: Information that’s useful to them so they don’t have to invent. They can copy or steal so learn about how a company might approach negotiation with a Chinese company, all manner of things.

Scott Pelley: How many hits from China do we take in a day?

James Comey: Many, many, many. I mean, there are two kinds of big companies in the United States. There are those who’ve been hacked by the Chinese and those who don’t know they’ve been hacked by the Chinese.

Scott Pelley: The Chinese are that good?

James Comey: Actually, not that good. I liken them a bit to a drunk burglar. They’re kicking in the front door, knocking over the vase, while they’re walking out with your television set. They’re just prolific. Their strategy seems to be: We’ll just be everywhere all the time. And there’s no way they can stop us.

Scott Pelley: How much does that cost the U.S. economy every year?

James Comey: Impossible to count. Billions.

Scott Pelley: Sounds like cybercrime is a long way from Bonnie and Clyde for the FBI.

James Comey: Bonnie and Clyde could not do a thousand robberies in the same day, in all 50 states, from their pajamas, halfway around the world.

Scott Pelley: The FBI’s had legendary problems upgrading its computer systems. Are you now to a place where you’re satisfied that you’re meeting the cybersecurity threat?

James Comey: We’ve made great progress coordinating better as a government. When I last left government, my sense of us was kind of like four-year-old soccer. So like a clump of four year olds chasing the ball, we were chasing it in a pack. We’re about high school soccer now. We’re spread out. We pass well. But the bad guys are moving at World Cup speed. So we have to get better.

Scott Pelley: Do people understand, in your estimation, the dangers posed by cybercrime and cyber espionage?

James Comey: I don’t think so. I think there’s something about sitting in front of your own computer working on your own banking, your own health care, your own social life that makes it hard to understand the danger. I mean, the Internet is the most dangerous parking lot imaginable. But if you were crossing a mall parking lot late at night, your entire sense of danger would be heightened. You would stand straight. You’d walk quickly. You’d know where you were going. You would look for light. Folks are wandering around that proverbial parking lot of the Internet all day long, without giving it a thought to whose attachments they’re opening, what sites they’re visiting. And that makes it easy for the bad guys.

Scott Pelley: So tell folks at home what they need to know.

James Comey: When someone sends you an email, they are knocking on your door. And when you open the attachment, without looking through the peephole to see who it is, you just opened the door and let a stranger into your life, where everything you care about is.

Scott Pelley: And what might that attachment do?

James Comey: Well, take over the computer, lock the computer, and then demand a ransom payment before it would unlock. Steal images from your system of your children or your, you know, or steal your banking information, take your entire life.

Scott Pelley: We have talked about a lot of menacing things in this interview. Do you think Americans should sleep well?

James Comey: I think they should. I mean, the money they have invested in this government since 9/11 has been well spent. And we are better organized, better systems, better equipment, smarter deployment. We are better in every way that you’d want us to be since 9/11. We’re not perfect. My philosophy as a leader is we are never good enough. But we are in a much better place than we were 13 years ago.