Layer Seven Security

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

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

admin on May 29, 2014

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

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

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

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

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

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

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

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

A First Look at the U.S Data Security and Breach Notification Act

admin on February 11, 2014

On January 30, members of the U.S Senate and House of Representatives introduced a new bill intended to enforce federal standards for securing personal information and notifying consumers in the event of a data breach. Sponsored by leaders of the Senate Commerce, Science and Transportation Committee, the Security and Breach Notification Act of 2014 would require the Federal Trade Commission (FTC) to develop and enforce nationwide security standards for companies that store the personal and financial information of consumers. According to Committee Chairman Jay Rockefeller, “The recent string of massive data breaches proves companies need to do more to protect their customers. They should be fighting back against hackers who will do whatever it takes to exploit consumer information.”

If enacted, the measures introduced by the Bill would direct the FTC to develop robust information security measures to protect sensitive data from unauthorised access and exfiltration. The FTC would also be empowered to standardize breach notification requirements across all states to ensure that companies need only comply with a single law. The law would be enforced jointly by the FTC and state attorneys. Civil penalties for corporations and criminal penalties for corporate personnel would be imposed for violations of the law. The latter would include imprisonment for up to five years. Unlike HIPAA and SEC Disclosure Guidelines, the requirements of the Act are not limited to health organisations or publically listed companies. They are applicable equally to both private and public organisations that store customer information across all industries and sectors. They are also applicable to data entrusted to third party entities.

The proposed Federal data security and breach notification standards are firmly supported by the FTC. During a speech delivered to a privacy forum on December 12 2013, FTC Chairperson Edith Ramirez supported the role of the FTC as an enforcer of consumer data protection standards. The organisation has aggressively pursued companies that have suffered data breaches for alleged unfair and deceptive trade practices and imposed fines of up to $10 million. However, FTC rulings are often challenged on the grounds that the organisation lacks a clear legal mandate. The Data Security and Breach Notification Act would provide the mandate required by the FTC against clearly-defined standards for data protection.

This includes standards for identifying and removing vulnerabilities in systems that contain customer information and monitoring for breaches to such systems as required by sections 2 (C) and (D) of the Act. To learn about vulnerabilities effecting SAP systems and implementing logging and monitoring to detect potential breaches in SAP applications and components, download our white paper Protecting SAP Systems from Cyber Attack. The paper presents a framework of 20 controls across 5 objectives to safeguard information in SAP systems from internal and external threats.

Monitoring Access to Sensitive Data using SAP RAL

admin on November 20, 2013

The disclosure of up to 200,000 classified documents belonging to the NSA by Edward Snowden in 2013, together with the release of over 750,000 U.S Army cables, reports and other sensitive information by Bradley Manning in 2010, has drawn attention to the need to control and monitor access to confidential data in corporate systems. For this reason, the general availability of the latest version of the SAP NetWeaver Application Server in May could not have been more well-timed.

NetWeaver AS ABAP 7.40 includes a new component known as Read Access Logging (RAL) to register and review user access to sensitive data. The momentum for RAL is driven not only by well-publicised information leakages but data protection requirements impacting industries such as e-commerce, healthcare and financial services. RAL is also in demand with organisations that have a relatively open authorization concept and therefore are more susceptible to data misuse. Aside from enabling organisations to verify user access to sensitive data and respond to potential abuses before they lead to the mass exfiltration of information, RAL acts as a deterrent for such abuse if users are aware that their actions are logged and monitored.

RAL supports calls though RFC, Dynpro, Web Dynpro and Web service channels. It is not enabled by default and therefore must be activated by selecting the Enable Read Access Logging in Client parameter in the Administration tab of the RAL Manager accessed via transaction SRALMANAGER. However, prior to enabling RAL, customers should follow several predefined configuration steps using the SAP_BC_RAL_CONFIGURATOR and SAP_BC_RAL_ADMIN_BIZ roles and associated authorization objects delivered by SAP. The first involves defining logging purposes to create logical groupings of log events based on the specific requirements of the organisation.  The second step is creating log domains to group related fields. For example, a domain for customer-specific information could be created to band together fields such as address, date-of-birth, SSN, etc.

Steps one and two establish the overarching structure for log information. The actual fields to be logged are identified during step three through recordings of sessions in supported user interfaces. Once identified, fields are assigned to log conditions and domains in step four. SAP will initiate RAL when the Enable Read Access Logging in Client parameter is selected which represents the final step of the configuration process.

Logs can be accessed through transaction SRALMONITOR or the Monitor tab of SRALMANAGER. Log entries include attributes such as time of the entry, user name, channel, software component, read status, client IP address and details of the relevant application server. Extended views provide more detail of log events than default views. The log monitor supports complex searches of events and filtering by multiple parameters.

RAL configuration settings can be exported to other systems through an integrated transport manager accessed through transaction SRAL_TRANS. Furthermore, logs can be archived using standard Archive Administrative functions in SAP NetWeaver via transaction SARA.

Although RAL is currently only available in NetWeaver AS ABAP 7.40, a release is planned for version 7.31 in the near future. Layer Seven Security can enable your organisation to leverage the full benefits of Read Access Logging and safeguard confidential information in SAP systems. To learn more, contact our SAP Security Architects at info@layersevensecurity.com or call 1-888-995-0993.