How to Implement Advanced Security Monitoring Without Third-Party Software
The fear and anxiety driven by the wave of cyber attacks in recent years has led many companies to bolster their security programs. It’s also led to a stream of software solutions from third-party developers offering to solve customers’ cyber security challenges. You may have heard the sales spin, watched the demos, and even considered the proposals. But before you launch the purchase order, ask yourself: Is there an alternative? What if the tools you need to secure your SAP systems were available to you at this very moment?
SAP has equipped customers with a variety of tools to protect against even the most advanced forms of cyber threats. The tools are available in SAP Solution Manager and include:
1. Configuration Validation: Implement automated vulnerability checks across your entire SAP landscape
2. System Recommendations: Detect security-relevant SAP patch day and support package notes
3. Change Analysis: Analyze the root cause of changes in your SAP systems
4. End-to-End (E2E) Alerting: Investigate email and SMS alerts for critical SAP security events
5. Security Dashboards: Monitor the health of your SAP systems in near real time
The need to monitor access to classified data in SAP systems has never been greater. End users are increasingly working with SAP data from outside the borders of corporate networks. Corporate information is also increasingly under threat from cyber criminals, hacktivists, cyber spies and terrorists that seek to exploit classified information for financial gain or to further ideological or national interests.
Read Access Logging (RAL) empowers organizations to combat these threats by providing the ability to detect and contain information leaks before they escalate into large-scale data breaches. This is performed by logging and monitoring access to sensitive data in SAP systems. RAL can also be used to identify malicious changes by tracking old and new values for classified data.
This article will explain how you can enable RAL in your SAP systems. The use-case illustrated in the article is sensitive employee data including social security numbers (SSN), salary and banking information. However, RAL can support any use case including health records, payment data, pricing information, etc. It can also be used to monitor access to custom data fields in your SAP systems.
RAL is accessed using the SRALMANAGER transaction. The screen below displays the options available in the Administration tab of the control panel. You will need the templates roles SAP_BC_RAL_ADMIN_BIZ, SAP_BC_RAL_ADMIN_TEC and/ or SAP_BC_RAL_CONFIGURATOR to administrator RAL.
The options in the Administration tab are organized in line with the sequence of activities performed to configure RAL. The first step is the definition of Logging Purposes. A log purpose is the specific use-case for the log groups you will create in later steps. In the example below, we have created a use-case to group sensitive employee-related data.
Next we must create Log Domains. These are assigned to data fields to support log analysis since many fields are unintelligible when relying on just system identifiers. The screen below captures the log domains we have created for employee data including banking information, salary and SSN.
Once we have defined our log domains, we must configure recordings to capture the data fields that we will assign to the domains. Recordings can be used for SAP GUI (Dynpro) and Web GUI (Web Dynpro) sessions. Below we have created a recording to capture specific types of employee information using SAP GUI. Click on the image to enlarge.
We can choose the data fields to log by selecting the Record Field option in the context menu. The screen below shows that we have selected to record the SSN field during a recording session in an IDES system with mock data using SAP GUI.
The fields captured in RAL during the recording sessions are assigned to log domains during the configuration step. In the example below, we have assigned the SSN field to the SSN log domain. You can choose to record field values in log entries during this step and to include/ exclude initial values. You can also specify whether the trigger for logging should be data entry performed by the end user or data displayed to the user or both. Specific users can be excluded from RAL using the User Exclusion List. Therefore, we can ensure HR and other users that require access to employee information for their role are not included in log results.
The final step is enabling RAL by maintaining the profile parameter sec/ral_enabled_for_rfc in each application server. RAL configuration settings can be transported within your SAP landscape using transaction SRAL_TRANS.
Log analysis is performed using the options in the Monitor tab. This can be performed using the role SAP_BC_RAL_ANALYZER.
The entries for all log domains are displayed below. The first entry in the log reveals that the user SAPADMIN successfully read the SSN of employee ID 109815 at 9.06AM on September 18, 2015.
Other log entries reveal that the user also accessed the bank details and salary information of the employee on the same day. See below.
Changes performed by SAPADMIN for data fields logged by RAL would be displayed as separate log entries if we had selected the option to record field inputs with values.
RAL is available in NetWeaver 7.40 but SAP intends to make it available for earlier releases. For further information including professional services to enable Read Access Logging in your SAP systems, contact Layer Seven Security.
For logging table-level access in SAP systems, we recommended using the Workload Monitor accessible through transaction ST03. You can configure table access logging for up to five transactions including well-known table maintenance transactions such as SE16, SM30 and SM31. The log below from the Workload Monitor displays the number of records viewed or modified using transaction SE16 for the user table USR02 during a specific date. Large record counts could indicate a potential data breach. Correlation with transaction starts performed by users logged in the Security Audit Log or STAD should be possible using conventional SIEM solutions or SAP Enterprise Threat Detection.
According to a recent study performed by the Center of Strategic and International Studies, the annual cost of cybercrime is more than $400 billion. This is equal to almost 1 percent of global income and higher than the national income of most countries. The report states that “The most important loss from cybercrime is in the theft of IP (intellectual property) and business confidential information, as this has the most significant economic implications”. In fact, some estimates place the cost of IP theft higher than the actual returns to IP creators: According to the World Intellectual Property Organization (WIPO), the world IP market generates $180 billion a year in fees and royalties, whereas IP theft costs the US economy alone more than $200 billion. This means that eliminating IP theft could more than double the returns on innovation for IP-generating firms.
Losses can vary significantly between sectors. The risk of IP theft and losses resulting from stolen data is higher in sectors where IP can be more readily monetized such as finance, chemicals, aerospace, energy, defense and IT. The impact of IP theft on individual firms can also fluctuate depending on how closely R&D and innovation-driven IP is tied to profitability. In extreme cases, it can lead to a complete collapse in profits. This is illustrated by the experience of Codan, an Australian technology company that manufactures mining and communications equipment. Codan’s net profit fell by 500 percent in a single year from $45M to $9M following the theft of technology blueprints during a targeted cyber attack. The stolen blueprints were used by counterfeiters to manufacture imitations that substantially undercut the price of genuine products manufactured by Codan. Despite slashing the price of its products, Codan was unable to stem the loss of market share that eventually eroded the company’s profits. The attack against Codan was profiled in a recent episode of Four Corners, a current affairs program aired by the Australian Broadcasting Corporation. The episode can be viewed below and underlines the destructive impact of financially-motivated economic espionage. According to research performed by Symantec and Kaspersky, such attacks are growing in volume and sophistication. They are frequently performed by organized criminal groups that target high-value corporate information that can be exploited for insider trading or other purposes.
Protection against such threats requires a layered security strategy including countermeasures at the network, OS, database and application level. For SAP application stacks, you can refer to Layer Seven’s white paper Protecting SAP Systems from Cyber Attack. The paper outlines a comprehensive approach for securing SAP systems against advanced threats and includes guidance for encrypting sensitive communications, securing access, implementing robust password policies, effectively patching SAP systems, and other areas.
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.
1 ESG, March 2015
2 2014 APT Study, ISACA, April 2014
3 Annual Security Report, Cisco, January 2014
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.
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).
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.
One of the most startling facts revealed by the 2015 Cyber Risk Report is that over 44 percent of data breaches stem from the exploitation of known vulnerabilities that are over two years old. This suggests that effective patching can dramatically lower the likelihood of a successful data breach and, when employed with other countermeasures such as system hardening to prevent misconfigurations, it can reduce the risk to negligible levels.
Developing a workable patch management process that addresses the numerous threats confronted by SAP systems presents a formidable challenge for organizations. The need to maintain high levels of availability and control changes that may negatively impact system performance or even lead to software regression often delays the implementation of critical patches. In some cases, it prevents the application of security patches altogether.
The risks posed by weaknesses in patching procedures should not be understated and are borne out by the findings of the HP study. Statistics reveal a direct correlation between ineffective patching and significantly higher levels of susceptibility to security threats that lead to data breaches.
Traditionally, SAP customers have relied upon tools such as RSECNOTE and SAP EarlyWatch Alert (EWA) to identify patches and verify their implementation status. RSECNOTE can be executed using transaction SA38 or ST13. It should return relevant Security Notes and convey whether Notes are successfully implemented, require implementation or are manually confirmed. EWA is a diagnosis report that is run from SAP Solution Manager for managed systems on a weekly schedule. The system configuration checks performed by EWA should include an identification of relevant Security Notes.
EWA, however, no longer performs any meaningful check for security-relevant Notes. Fewer than 10 percent of the 364 Patch Day Notes and Support Pack Notes released by SAP in 2013 were checked and reported through EWA. By 2014, EWA had lost all relevance for security patching: none of the 389 SAP patches released last year were checked by EWA.
RSECNOTE has not fared any better. According to Note 888889 updated in September 2014, the tool is effectively deprecated by SAP and should no longer be relied upon.
RSECNOTE and EWA have been replaced by tools with more powerful calculation engines capable of supporting more detailed analysis of not just Hot News and Security Notes, but also Java patches and Notes for general, performance and legal areas.
These tools include System Recommendations (SysRec), accessible through the Change Management Work Center of SAP Solution Manager. SysRec uses the SAP-OSS RFC destination to connect directly to SAP Global Support and check the status of Notes in managed systems. The results are based on the specific kernel, patch and support package level of systems maintained in the Solution Manager System Landscape (SMSY). This minimizes the risk of both false positives and false negatives.
SysRec can be filtered by SAP system, component and date range. Only components are that are applicable to the selected system are displayed by SysRec.
Priority levels and the implementation status of each Note are displayed in the returned results. The Download Notes option can be used to download all or selected Notes from the SAP Service Marketplace. Click on the image below to enlarge.
SysRec can be used to identify both ABAP and Java patches. However, Java patch notes are displayed in the Corrections tab rather than the tab for Security Notes.
The Create Request for Change option is used to trigger a change request to implement the relevant Notes when using ChaRM.
The automated job SM:SYSTEM RECOMMENDATIONS should be scheduled to collect information on the status of implemented Notes from managed systems. The frequency of the automatic check can be set to daily, weekly or monthly.
Once corrections are identified and applied, the implementation status of the Notes should be validated across all systems in your landscape. This can be performed using Configuration Validation. The implementation status of Notes is recorded in the PRSTATUS field of the ABAP_NOTES store. The PRSTATUS of completely implemented notes should be E. Therefore, you can define operators to search for Notes implemented in a reference system with the identical component and release dependencies that have the same PRSTATUS. Based on the example below, for instance, Configuration Validation will check that version 2 of Note 1922205 for component SAP_BASIS is completely implemented (PRSTATUS = E), taking into account the release dependencies.
Notes that are not completely implemented in comparison systems are flagged as non-compliant in BW reports generated by Configuration Validation.
Our recent article outlining the advantages of using SAP-delivered components versus third party software resonated strongly with customers seeking an effective and cost-efficient solution to address cyber threats impacting their SAP systems. The article examined the five key benefits of a Solution Manager-based strategy that included lower costs through the avoidance of licensing and maintenance fees for third-party software, the ability to configure custom security checks to address system, company or industry-specific risks, alerting for critical security events, detailed reporting driven by SAP Business Warehouse, and the availability of SAP support. The article presented a compelling argument for selecting SAP Solution Manager over the host of competing solutions offered by independent vendors.
The benefits delivered by Solution Manager stem from the depth and volume of security-related data that is continuously pulled from managed systems into the platform. Solution Manager lays at the core of SAP system landscapes and therefore occupies a central vantage point to oversee the security of connected systems. In contrast, third party software solutions are not embedded within SAP landscapes to the same extent and therefore lack the connectivity and range of Solution Manager.
Aside from the advantages mentioned above, there are three other benefits delivered by Solution Manager for security monitoring. The first is the availability of security dashboards. SAP delivers three security apps through the standard WebDynpro dashboard application in Solution Manager, located in the Cross-Application section for dashboard apps. This includes the Security Overview app, which summarizes security policy compliance by system across landscapes, the Security Details app, which displays compliance levels for software, configuration and user categories, and finally, the Security List app, which conveys security compliance levels for every SAP System ID. Dashboards apps can be automatically refreshed as often as every 5 minutes to provide security information in near real-time.
The second is Solution Manager’s ability to deliver detailed metrics for analyzing changes. Like third party solutions, components such as Configuration Validation in Solution Manager are able to pinpoint differences between actual and recommended security settings. However, Solution Manager goes a step further by enabling users to drill-down into the underlying changes that created risks identified by security scans. This is performed through Change Analysis which provides timestamps for changes in managed systems and the original values for instance, profile or other parameters before the changes were implemented.
The third is Solution Manager’s flexibility to support security policies aligned to any compliance framework. This includes not only familiar frameworks such as SOX and PCI DSS but requirements that are unique to specific industries or sectors. The transparent security checks performed by Configuration Validation can be customized for all regulatory, statutory and other forms of compliance standards.
Organizations do not have to look far for the solution to remove security vulnerabilities in their SAP systems. Most are delivered with standard license agreements by SAP and can be leveraged immediately at zero cost. Tools such as Configuration Validation provide a powerful and cost-effective alternative to third party solutions. They are also fully supported by SAP. You can learn more about SAP Configuration Validation here or contact Layer Seven Security to unlock the value of your Solution Manager systems.