Layer Seven Security

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.