SAP Vulnerabilities Archives - Page 7 of 11

What’s New in the SAP Cybersecurity Framework 3.0

Layer Seven on January 14, 2016

Released earlier this month, the third version of the SAP Cybersecurity Framework includes important changes in the areas of transport layer security, logging and monitoring, and vulnerability management. It also discusses the most significant hack against SAP systems to date: the devastating data breach suffered by U.S Investigation Services (USIS). USIS performed background checks on prospective federal employees for the Office of Personnel Management (OPM) and other government agencies before it’s contracts were severed after the announcement of the breach in 2015.

The breach is estimated to have impacted the personal information of up to 20 million individuals. According to the findings of an internal forensic investigation, attackers were able to breach systems at USIS by exploiting an undisclosed vulnerability in a connected SAP ERP system sometime in 2013. The attack went unnoticed by intrusion detection and other network-level monitoring devices. The specific vulnerability exploited by the attackers has been the subject of widespread speculation by security researchers. Some have argued that the breach was caused by a brute-force password attack. Others have pointed towards RFC exploits or unapplied security patches. The source of the breach could have been any one of these or a combination of other vulnerabilities. The wide attack surface presented by SAP systems makes it impossible to pinpoint the root cause without access to the log data. Regardless, the breach demonstrated the destruction that can be wrought by successful attacks against vulnerable SAP systems. The contracts lost by USIS as a direct result of the attack were valued at $3 billion. The organization laid off 2500 workers and filed for bankruptcy shortly after the public announcement of the breach.

For transport layer security, the framework has been updated in line with RFC 7568 issued by the Internet Engineering Task Force (IETF) for deprecating Secure Sockets Layer Version 3 (SSL v3). SSL was the standard protocol for securing Web-based communication between clients and servers. Support for SSL has been gradually waning as a result of the growing awareness of weaknesses in its encryption scheme and key exchange mechanism. The POODLE vulnerability proved to be the final straw since it could be exploited to break encrypted SSL sessions and access sensitive data passed within such sessions including cookies, passwords and tokens.

The new version of the Framework includes an improved section on Read Access Logging (RAL). RAL should be configured to log access and changes by unauthorized users for sensitive data fields in SAP systems. This includes fields for banking, credit card and salary data. Exclusion lists can be maintained to rule out logging for authorized users. Together with the updated framework, you can also refer to an earlier Layer Seven article on protecting sensitive data in SAP systems using RAL for more information.

Lastly, much of the technical jargon related to Configuration Validation (ConVal) in earlier versions has been removed to focus on the core use-case for ConVal. ConVal is a powerful vulnerability management framework included in SAP Solution Manager that is recommended by SAP for managing vulnerabilities in SAP systems.

Since licensing for Solution Manager is included in SAP support and maintenance agreements, ConVal provides the most cost-effective alternative to third party tools.

You can download version 3 of the SAP Cybersecurity Framework in the whitepaper Protecting SAP Systems from Cyber attack from the Resources section.

Get Ready for SAP Solution Manager 7.2: What to Expect

Layer Seven on December 14, 2015

It’s well known that licenses for SAP Solution Manager are included in SAP maintenance and support agreements. However, with the release of version 7.2 next year, SAP will take this a step further by providing free licenses for SAP HANA for use with SolMan 7.2. Customer’s will still have to pay for hardware costs but HW costs have been falling and there is the option for cloud services to avoid hardware costs altogether.

Other improvements in SolMan 7.2 include a streamlined architecture requiring fewer integrations and system resources and delivering faster processing times. Depending upon the implementation scenario, customers will be able to lower SolMan running costs by up to 70 percent.

SolMan will also provide a vastly improved UI based on the Fiori Lauchpad and support access through Apple, Android and Windows mobile devices. Click on the images below to enlarge.

SolMan 7.2 will provide full support for HANA, S/4HANA, Cloud and Hybrid solutions, enabling customers to manage and monitor all SAP on-premise and cloud systems.

For security monitoring, we can expect improved reporting capabilities based on UI5 that do not require embedded BI or Flash, tighter integration between the SolMan frontend and BW Query Designer to support highly customizable reports, upgraded dashboards and alerts, and the ability to not only discover missing Security Notes for systems using SysRec but also identify the business processes impacted by the planned implementation of Notes. The latter will rely on solution documentation maintained directly in SolMan and a much improved Business Process Change Analyzer application that will integrate with Test Management to enable customers to develop, execute and review the results of test cases for planned changes.

SAP will remove maintenance for the current version of Solution Manager at the close 2017. Customers will have around 18 months to upgrade their Solution Manager platforms. The advanced performance and analytical capabilities offered by SAP HANA together with the major enhancements in Solution Manager 7.2 suggest that most customers will opt for early adoption. This will strengthen SolMan’s position as the premier solution for monitoring the security of SAP systems, providing the lowest total cost of ownership, unlimited flexibility and scalability, and unrivalled performance.

Are your System Users Vulnerable to SAP Hacks?

Layer Seven on November 24, 2015

One of the most telling statistics revealed at BlackHat USA earlier this year was the fact that 84 percent of InfoSec professionals regard unmanaged privileged credentials as the biggest cyber security vulnerability within their organizations. For SAP environments, the dangers posed by abusing user accounts with privileged access are well-known and can include shutting down SAP servers to interrupt the availability of services, reading or modifying sensitive information, and performing unauthorized changes to system configurations, programs, users, and other areas. For this reason, privileged access is carefully granted and vigilantly monitored in most systems, especially productive systems. This includes privileges assigned through powerful authorization profiles such as SAP_ALL, SAP_NEW, S_ABAP_ALL and S_A.SYSTEM.

However, countermeasures to prevent abuses of privileged credentials in SAP systems are usually focused upon dialog users since interactive logon is not possible with most other user types. This includes system users that are used for background processing. Therefore, it’s common to find system users with privileged access in productive systems, especially when such users support several cross-system connections and integration scenarios.

The risks posed by system users with privileged credentials should not be overlooked and can be as grave as those posed by dialog users. Attackers are able to modify user types from system to dialog in several ways. The most common method is through the Function Builder used to build, test and manage function modules.

Attackers can access the Function Builder through transaction SE37 in a connecting system to execute the BAPI_USER_CHANGE remote-enabled function module (RFM). This RFM can be used to implement user changes in destination systems. The changes are applied using a privileged system user in the destination system. The credentials for such users are often stored in RFC destinations configured in connecting systems. The relevant RFC destination is entered in the field RFC target sys of the Function Builder (see below). The username of the system user configured for the RFC connection is entered in the USERNAME import parameter. Finally, the values of the LOGONDATA and LOGONDATAX are maintained to specify the dialog user type.

Once executed from the connecting system, BAPI_USER_CHANGE will change the system user to a dialog user type in the destination system through a remote function call. This will enable the attacker to logon to the destination system through methods such as the Remote Logon option in the RFC destination maintained in the connecting system (see below).

Since attackers can bypass the restrictions placed on system users by abusing the privileged credentials provided to such users, it stands to reason that super user privileges should be managed for all user types, not just dialog users. This should include minimizing privileges for technical system and communication users to the minimum required for each scenario. Trace tools such as STAUTHTRACE, STRFCTRACE and STUSOBTRACE can be used to identify the authorization objects required for each user. This should be supported by enabling switchable authorization checks for sensitive function modules such as BAPI_USER_CHANGE, BAPI_USER_CREATE1 and BAPI_USER_PROFILES_ASSIGN, and, in NetWeaver releases 7.4X, enabling Unified Connectivity (UCON) to restrict external access to remote-enabled function modules.

RFC destinations with stored logon credentials can be identified using the config store RFCDES_TYPE_3 in Configuration Validation (ConVal). RFC users with critical profiles such as SAP_ALL can be identified using the store RFCDES_TYPE_3_CHECK. See below.

How to Discover Missing Security Notes for Your SAP Systems using ConVal

Layer Seven on October 20, 2015

Earlier this month, the New York Stock Exchange released a definitive guide to cybersecurity targeted at directors and officers of public companies. Developed with Palo Alto Networks, the guide includes contributions from over thirty-five industry experts and contends with a wide range of questions including legal and regulatory issues, cyber insurance, supplier risks, and incident detection and response. It also discusses investor perspectives towards cybersecurity and cites a recent survey of 130 global institutional investors with an estimated $3 trillion under management that reveals 4 out of 5 institutions would blacklist the stocks of hacked organizations. The full report can be downloaded here.

According to the guide, cybersecurity risk management plans should include several critical countermeasures. One of the most important is effective patch management. In fact, the report points out that “system compromise and data breach are rarely the result of some sophisticated attack that no one has ever been seen before. The bulk of effective attacks use vulnerabilities that have been known for years…..Lack of patching and other standard security issues are normally the culprits” (p95).

This suggests that more active and rapid patching can significantly lower the risk of successful cyber attack. For SAP customers, this calls for the regular application of SAP-delivered security patches to address programming and other flaws. Security fixes are generally released by SAP on Security Patch Day, scheduled for the second Tuesday of every month. Corrections are packaged in Hot News, Security and Support Package Notes that are available through the SAP Support Portal.

There are several options for discovering relevant Security Notes for SAP systems. The first is directly through the SAP Support Portal using preconfigured filters for registered systems and products. Automatic email notifications can be setup through the Portal for newly released Notes.

The second is System Recommendations (SysRec). You can refer to our earlier post for guidance on how to Discover Security Patches for your SAP Systems using System Recommendations.

The third is a standard report available in Configuration Validation (ConVal). Although this approach draws upon SysRec, it consolidates missing SAP patches for all systems across landscapes. This is useful if you need to check the patch status of several systems at the same time. The instructions below provide a step-by-step guide for detecting unapplied SAP Security Notes using ConVal.

Step 1. Open Configuration Validation from the Root Cause Analysis or Change Management work center in SAP Solution Manager. Click on the image below to enlarge.

Step 2. Select the Reporting Templates option from the Report Execution tab.

Step 3. Select the report highlighted below and click ‘Start configuration reporting’.

Step 4. Maintain the filters for the report by selecting specific SAP System IDs (SIDs), system types, areas, and the date range. In the example below, we have selected Hot News and Security Notes released between Jan-Sep 2015 for all ABAP systems in the landscape. Click Execute when you are done.

Step 5. Analyze the results. In the report below, the table on the left provides a count of missing Notes by SID. The table on the right displays the unapplied Notes in each row against SIDs in each column.

The details of each unapplied Note are provided in the lower section of report. This includes version, description, priority level, and impacted application components. The results can be filtered by priority level to focus on Hot News and High Priority patches. Results can also be exported to .xls and other file formats for further analysis.

Featured in SAPinsider: Unlocking the Cyber Security Toolkit in SAP Solution Manager

Layer Seven on October 15, 2015

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

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).

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.

Discover Security Patches for your SAP Systems using System Recommendations

Layer Seven on March 4, 2015

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.

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.