SAP Vulnerabilities Archives - Page 5 of 11

Discover, Implement and Test Security Notes using SAP Solution Manager 7.2

Layer Seven on May 11, 2017

The results of the recent Verizon DBIR revealed significant differences between industries in terms of vulnerability patching. Organizations in sectors such as information technology and manufacturing typically remove over 75% of vulnerabilities within 3 weeks of detection. At the other end of the spectrum, 75% or more of vulnerabilities discovered in financial and public sector organizations and educational institutions remain unpatched for longer than 12 weeks after discovery.

The DBIR masks important differences between patching for devices and applications. Servers, for example, are generally more effectively patched than routers and switches.

Patch cycles for SAP infrastructure and applications are typically more drawn-out than most other technologies. There are several reasons for this. The most important is the lack of visibility into the impact of SAP patches. This leads to a reluctance to apply corrections that may disrupt the performance or availability of systems.

SAP Solution Manager 7.2 overcomes this challenge by enabling customers to pinpoint the impact of security notes before they are applied in systems. Change impact analysis is performed using Usage and Procedure Logging (UPL) and Business Process Change Analyzer (BPCA) integrated with System Recommendations (SysRec).

SysRec provides a real-time analysis of missing security notes and support packs for ABAP and non-ABAP systems including Java and HANA. It connects directly to SAP Support to discover relevant notes and packs for systems configured in the LMDB – SolMan’s landscape information repository. It also connects to each managed system within SAP landscapes to check the implementation status of notes.

System Recommendations is accessed through the Change Management group in the Fiori launchpad for SAP Solution Manager.

The dashboard below is displayed after the SysRec tile is selected and summarizes notes across the landscape. IT Admin Role and System Priority are attributes maintained in the LMDB. Views can be personalized to sort or filter by attributes or notes.

You can apply a wider selection of filters in the detailed section of SysRec to further breakdown the results.

Once the filters are applied, the selection can be saved as a Fiori to tile to avoid reapplying the filters during future sessions. The tile is saved to the launchpad and the counter in the tile automatically updates based on the current status of the system.

The details for each note can be read by clicking on the short text.

The Actions option allows users to change the status of notes and add comments. Status options are customizable.

Corrections can be downloaded directly from SAP Support by selecting Integrated Desktop Actions – Download SAP Notes.

Once selected, you can change the target system before the download. The note will be available in SNOTE within the target system after the download.

Change impact analysis is performed at both a technical and business level. For technical analysis, SysRec reads data collected by Usage and Procedure Logging (UPL) to display information related to the usage level of objects such as programs, methods and function modules impacted by notes. This is performed by selecting the relevant notes and then Actions – Show Object List.

The results below reveal that Note 2373175 is impacting the standard SAP class CL_HTTP_SERVER_NET. This class was used 325311 times in system AS2 during the timeframe defined for UPL.

For business impact analysis, SysRec integrates with Business Process Change Analyzer (BPCA). BPCA reads solution documentation maintained in Solution Manager to discover modules, transactions, reports, and other areas impacted by notes.

SysRec’s ability to perform comprehensive and reliable change impact analysis for security notes enables customers to overcome one of the most significant roadblocks to effectively patching SAP systems. The usage data collected through UPL together with the solution documentation leveraged using BPCA provides SAP customers with the insights to develop test strategies targeted at the actual areas impacted by notes and narrow the window of vulnerability for unpatched systems.

In a forthcoming article, we will discuss how to import SAP templates and create and execute test plans using Test Management in SAP Solution Manager 7.2.

Security KPI Monitoring with SolMan Dashboards

Layer Seven on March 28, 2017

SAP Fiori revolutionizes the user experience in Solution Manager 7.2. The dynamic tile-based layout replaces the work center approach in Solution Manager 7.1. In fact, since the Fiori launchpad provides direct and customizable access to applications, it virtually removes the role of work centers in Solution Manager. Fiori and Fiori Apps are the first pillar of the new user experience in Solution Manager. The second is the revised dashboard framework.

Both Fiori and the dashboard framework are built on HTML5-compliant SAPUI5 technology. Unlike the Flash-based dashboards in Solution Manager 7.1, dashboards in version 7.2 are compatible with most browsers and mobile devices. In common with the packaged dashboards available using the Focused Insights add-on, the dashboard framework includes a series of reusable dashboard templates to support application and cross-application scenarios. This includes areas such as availability and performance management, incident management and service management.

However, in contrast to Focused Insights and dashboards in Solution Manager 7.1, the new framework provides a flexible and user-friendly platform for creating custom dashboards to monitor key performance indicators (KPIs) in SAP systems and landscapes, including security-relevant KPIs.

A dashboard consists of multiple tiles. Each tile is associated with a single KPI. Tiles can be clustered into groups within a dashboard. Once the option to a create new dashboard is selected (see below), users can select either standard tiles or create custom tiles for the dashboard. Standard tiles include predefined KPIs available from the SAP KPI Catalog.

For custom tiles, users can select from a variety of data sources including Business Warehouse. Security-related information such as vulnerabilities and missing security notes detected by Solution Manager are stored in InfoProviders within an internal Business Warehouse.

Once the data source is selected, users can maintain filters and thresholds to break down the results.

Users can also select the type of visualization for each tile including combination, micro, single, stack and table charts.

Dashboards support drill-down analysis by enabling users to navigate directly from summarized information in each tile to the detailed information in Business Warehouse. An example is provided below. The following dashboard monitors security KPIs for patch levels, network security, RFC security, access control, logging and auditing, and system configuration management. The highlighted tile in the dashboard displays the number of unapplied security notes for system PM1. A single click on the tile will display the details of the notes in a table that can then be exported directly to Excel.

Explore Service Level Reporting in SolMan 7.2

Layer Seven on February 27, 2017

Service Level Reporting (SLR) in SAP Solution Manager performs regular checks against key performance indicators using information available from the EarlyWatch Alert (EWA), Business Warehouse (BW) and the Computer Center Management System (CCMS). The checks can be for single systems or systems grouped into solutions. Reports run automatically on a weekly or monthly schedule but can also be triggered manually for on-demand reporting. SLRs can be displayed in HTML or Microsoft Word. SAP Solution Manger automatically distributes SLRs by email to recipients maintained in distribution lists.

Security-related metrics stored in internal or external BW systems can be read by SLR to create dynamic, detailed and user friendly vulnerability reports. This includes areas such as settings for profile parameters, access control lists in gateway security files, trusted RFC connections or destinations with stored logon credentials, unlocked standard users and standard users with default passwords, active ICF services, filter settings in the security audit log, missing security notes, and users with critical authorizations, profiles or transactions. For HANA systems, it includes database parameters, audit policies, the SYSTEM user, and users with critical SQL privileges. For Java systems, it includes properties for the UME and the invoker servlet. Furthermore, since event data from monitored systems is stored in BW and CCMS, SLR can also report on metrics for events in audit logs including the security audit log and syslog. The latter is particularly relevant for HANA systems which can write logs to operating system files.

SLRs are created and customized in the area for SAP Engagement and Service Delivery in the Fiori Launchpad.

Variants need to be maintained for each report including relevant systems, solutions, data sources, metrics, thresholds and schedule (weekly or monthly).

Once activated, the reports are executed by a regular automated job and accessed through the tile for Service Level Reports.

Comments can be included in SLRs before the reports are automatically distributed by email. SLRs include details of each vulnerability check, risk ratings, and links to relevant SAP Notes and documentation at the SAP Help Portal. Reports also include a gap assessment against compliance frameworks such NIST, PCI-DSS and IT-SOX. SLRs are archived by Solution Manager for trend analysis.

Introducing the SAP Cybersecurity Framework 4.0

Layer Seven on January 25, 2017

Cyber attacks are at epidemic levels. According to research performed by 360 Security, there were over 85 billion attacks in 2015, equivalent to 2000 attacks per second. The cost of data breaches continues to grow, year after year, and reached record levels in 2016. Juniper Research estimate that average costs will exceed $150M within three years.

Introduced in 2014, the SAP Cybersecurity Framework provides the most comprehensive benchmark for securing SAP systems against advanced persistent threats. It presents a roadmap for hardening, patching and monitoring SAP solutions using standard SAP-delivered tools. The newly released fourth edition of the Framework includes important updates in the areas of transport layer security, network segmentation in virtualized environments, and security settings applied through application level gateways.

The Framework no longer recommends the use of the EarlyWatch Alert (EWA) for security monitoring. This is due to concerns related to the updated rating scale used to grade security risks in the EWA. However, the Framework includes an expanded section for security monitoring using SAP Solution Manager including an overview of security-related tools bundled within Solution Manager such as Configuration Validation, System Recommendations, Monitoring and Alerting Infrastructure (MAI), Service Level Reports, Interface Monitoring, and Dashboards.

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

RFC Hacking: How to Hack an SAP System in 3 Minutes

Layer Seven on January 21, 2017

RFC exploits are hardly new. In fact, some of the well-known exploits demonstrated below are addressed by SAP Notes dating back several years. However, the disturbing fact is that the measures required to harden SAP systems against such exploits are not universally applied. As a result, many installations continue to be vulnerable to relatively simple exploits that could lead to devastating consequences in SAP systems. The impact of the exploits in the demonstration below include the theft of usernames and password hashes, remote logons from trusted systems, and the creation of dialog users with SAP_ALL privileges.

The first exploit demonstrates how attackers can perform operating system commands to extract sensitive information from an SAP database. This is performed through external programs such as sapxpg that are called through the RFC gateway without any authentication. The information extracted in the demo includes user credentials. However, the exploit can be used to read or modify any data from SAP databases.

The second exploit demonstrates how attackers abuse the RFC protocol to change system users to dialog users and then logon from remote systems using the privileges of RFC users.

The final exploit demonstrates the dangers of RFC callback attacks. In the example below, an RFC callback from a compromised system to a vulnerable system creates an unauthorized user in the calling system with the dangerous SAP_ALL profile. Attackers can also use this exploit to change salary information, modify programs, and many other scenarios.

Systems vulnerable to RFC exploits can be discovered using SAP Solution Manager. Solution Manager regularly scans and alerts for vulnerabilities in RFC communications such as weaknesses in access control lists for RFC gateways, RFC users with administrative profiles, RFC destinations with stored logon credentials, and missing whitelists for RFC callbacks. The Monitoring and Alerting Infrastructure (MAI) of Solution Manager generates alerts for changes to RFC destinations, successful or unsuccessful attempts to call external programs through the gateway server, and RFC callbacks. Contact Layer Seven Security to discuss how to leverage Solution Manager to discover and remove RFC vulnerabilities in your SAP systems.

SAP RFC Hacking from Layer Seven Security on Vimeo.

SAP CSO Recommends Solution Manager for Security Monitoring

Layer Seven on September 20, 2016

SAP Chief Security Officer, Justin Somaini, opened the first of a series of five webcasts from the America’s SAP User Group (ASUG) on the topic of SAP security. The series is intended to present SAP’s response to the growing concern over cybersecurity by discussing:

The IT threat landscape and SAP’s approach to strategic security;
Best-practices to safeguard both on-premise and cloud SAP landscapes;
Secure configuration and patch management;
Security for SAP HANA; and
SAP’s security portfolio for responding to internal and external attacks.

During the webcast, Somaini contends security is becoming an important differentiator between competitors in all markets, especially within the technology and manufacturing sector. He also acknowledges that SAP systems often store and process some of the most valuable data within organizations and are therefore particularly at risk from cyber threats. According to Somaini, “the application layer needs to be the first and last line of defence” due to inherent weaknesses in firewalls and other network technologies that cannot protect SAP applications from external threats. In his view, SAP applications should be hardened to build greater resilience against attacks.

Somaini tackles the question of single point versus integrated security solutions by recommending the use of tools that SAP customers already own in platforms such as Solution Manager over a patchwork of external tools. You can view a recording of the webcast and register for other upcoming webcasts in the series by following this link.

Detecting SAP Cyber Attacks with SAP Solution Manager

Layer Seven on September 15, 2016

Despite the $75 billion spent by organizations on security software in 2015, average times to detection for cyber attacks are an astounding 170 days (DBIR, 2016). Most attacks therefore go undetected for almost six months.

An incident response strategy can address this gap by enabling organizations to proactively discover and contain security incidents that could lead to data breaches if left unchecked. The cornerstone of effective incident response is detection. This involves collecting and analyzing information from a variety of sources to identify signs of abnormal events that could include potential malicious actions. SAP systems capture a variety of security-relevant events across multiple logs. The most significant is the Security Audit Log.

The Security Audit Log should be configured to log successful and unsuccessful logon attempts by privileged and standard users, RFC calls, changes to user records, report and transaction starts, and other critical events. This is performed through filters defined in each system. Log data is stored in local or central files that are read by the Security Monitor of the CCMS. This data is available to Solution Manager for centralized alerting.

Solution Manager should be configured to monitor not just events in the Security Audit Log, but also security-relevant events in logs for the gateway server, message server, SAProuter, Web Dispatcher, system log, UME log and, for HANA systems, syslog servers. This captures critical events such as external programs started through the gateway server, external programs registered with the gateway, HTTP requests from remote or unrecognized IPs, and successful/ unsuccessful connections through application gateways.

The Event Calculation Engine (ECE) within Solution Manager continuously monitors event data recorded in such logs to identify potential attacks based on metrics configured for each log source. This is performed using existing data providers such as Diagnostics Agents and sapstartsrv. Both are automatically installed with SAP systems. The monitoring interval for log sources can be customized but the recommended interval is 60 seconds. The ECE can be configured to perform event correlation for sophisticated pattern analysis.

Alerts are triggered by ECE for events that match a defined pattern or exceed thresholds for specific metrics. The alerts are displayed in the Alert Monitor for Solution Manager. Priority levels can be set for each alert based on a High-Medium-Low scale. Alert data also be transferred to Business Warehouse for detailed reporting and analysis using real-time dashboards.

Solution Manager also channels notifications for alerts to designated Incident Responders through email and text message. Notifications can be grouped to avoid alert flooding. Each notification provides a URL to the relevant alert or alert group within Solution Manager. Incident Responders can add comments to the alert in the Alert Monitor, follow guided procedures for handling alerts, and create and assign tickets for incident management within Solution Manager.

The example below displays the alert details and notifications generated by Solution Manager for a failed logon by the standard SAP* user in a monitored system.

1. Attempted logon using SAP* user in client 001 of system PM1.

2. Event summary in the Security Audit log.

3. Event details in the Security Audit Log.

4. Email notification of event.

5. The email attachment for the alert notification.

6. The Alert Inbox in SAP Solution Manager

7. The details of the alert in the Alert Monitor

SAP Security Notes – August 2016

Layer Seven on September 2, 2016

Note 2319506 addresses a blind SQL injection vulnerability in Database Monitors for Oracle. The vulnerability impacts all versions of SAP Basis and rates extremely high on the impact scale using the common vulnerability scoring system. Content-based and time-based blind SQL injection is used by attackers to determine when input is interpreted as a SQL statement. The results are used to fingerprint databases, build database schemas and escalate attacks.

The blind SQL injection vulnerability in the Database Monitors is caused by improper validation of user-supplied input in the function modules STUO_GET_ ORA_SYS_ TABLE and STUO_GET_ORA_SYS_TABLE_ 2. The modules are used to read Oracle system tables containing sensitive data including database instances and logical names for database connections. Corrections for the vulnerability are included in support packages for relevant SAP Basis versions detailed in Note 2311011.

Note 2313835 deals with a high risk denial of service vulnerability in the Internet Communication Manager (ICM). The ICM manages client-server communication using Web protocols such as HTTP, HTTP, and HTTPS. For NetWeaver Application Server Java, the ICM also manages communications based on the proprietary SAP P4 protocol. Note 2313835 provides kernel patches for DOS and DDOS attacks targeted at the P4 port of AS Java that could lead to service disruptions caused by resource exhaustion.

Note 2142551 delivers a framework for protecting AS ABAP against clickjacking attacks. This includes a client-dependent positive whitelist maintained in the HTTP_WHITELIST table. The key data to be maintained for each entry in the whitelist is entry_type and host. The recommended value setting for entry_type is 30 to enable clickjacking protection. Trusted hosts and domains should be defined in the host field.

Note 2012284 provides corrections to extend virus scanning to objects created by Knowledge Provider, a document and content management service within NetWeaver Application Servers.

Three Reasons You Should Budget for SAP Breach Costs

Layer Seven on June 28, 2016

The average cost of a data breach has now surpassed $4 million. This is according to the latest study from the Ponemon Institute issued earlier this month. The study surveyed 383 organizations in 12 countries. It revealed that not only are data breach costs increasingly across the board, the probability that organizations will suffer a breach impacting 10,000 or more records is 25 percent.

The global results mask significant differences between countries and industries. For example, average data breach costs are highest in the U.S ($7M) and sectors such as healthcare, education and financial services. However, regardless of country or industry, the majority of breaches (48%) are caused by cyber attacks rather than human error or system glitches.

The results of the Ponemon study are contested by the report Beneath the Surface of a Cyberattack from Deloitte Advisory. According to the report, actual costs are far higher than indicated by the Ponemon study which focuses upon measuring direct and tangible costs for breach notification, forensic investigations, legal fees, public relations, regulatory fines and other areas. Deloitte estimate that such costs account for less than 5% of the total business impact of data breaches. The strategic impact of breaches in terms of increased insurance premiums, loss of intellectual property, reputational harm and other hidden costs is far higher than the direct impact. This is illustrated by a breach of patient records experienced by a healthcare company cited in the report. Only 3.5% of the $1.6 billion lost by the company as a result of the breach was associated with direct costs.

Both of the studies echo the results of an earlier report from the Ponemon Institute that placed the average cost of data breaches impacting SAP systems at $4.5M. The report also revealed that 65% of companies had experienced one or more SAP breach within the last 2 years. The significant impact of data breaches and the likelihood that organisations will experience a breach if they haven’t already done so suggests that breach costs should be planned and budgeted. However, aside from region, sector and other factors, there are three reasons that could negatively impact the extent your organization budgets for SAP breach costs. The reasons are outlined below.

1. You do not effectively identify, prioritize and apply security patches for SAP systems

The majority of exploits for SAP systems do not target zero-day vulnerabilities. Most exploits focus upon long-standing and well-known vulnerabilities that can be removed by regularly upgrading SAP systems and applying Security Notes provided by SAP. A case in point is the invoker servlet vulnerability addressed by the recent alert issued by US-CERT. This vulnerability was disclosed in 2010 and addressed by several Notes issued by SAP in the same year.

2. You do not effectively manage vulnerabilities in SAP systems

SAP systems can present a wide attack surface to attackers if they are poorly configured and monitored. A comprehensive vulnerability management program for SAP systems should include continuously monitoring and removing vulnerabilities in areas such as remote function calls, gateway servers, message servers, client-server and server-to-server communication, password policies, session management, audit settings, ICF services, UME settings, Java services and user privileges.

3. You do not effectively discover and respond to malicious events in SAP systems

SAP systems include a wide array of logs that should be continually monitored for indicators of a potential attack. This includes events such as logons or attempted logons with standard users, changes to RFC destinations, ICF services or global settings, trusted system logons, RFC callbacks, path traversals and suspected XSRF attacks. Alerts for such events should be triggered and automatically transmitted to incident response teams to ensure attacks are blocked and contained.

Customers that implement strong patch, vulnerability and threat management programs for SAP systems can justifiably budget far less for SAP breach costs that those that do not by reducing both the likelihood and impact of a potential breach. In fact, they may be able to remove the need to budget for breach costs altogether and rely upon on cyber insurance by satisfying the due diligence requirements of cyber insurance policies.

Customers that haven’t Implemented patch, vulnerability and threat management capabilities can address the gap by leveraging standard tools available in SAP Solution Manager without licencing third party software. This includes System Recommendations for patch management, Configuration Validation for vulnerability management and E2E Alerting for threat management. Layer Seven Security empower customers to unlock the capabilities of SAP Solution Manager for automated vulnerability scanning and security alerting. To learn more, contact Layer Seven Security.

Security in SAP HANA

Layer Seven on May 30, 2016

SAP HANA is now deployed by over 7,500 organizations worldwide. While this represents only a fraction of the 300,000 companies that use SAP software globally, adoption is growing rapidly, doubling in 2015 alone. As expected, the introduction of SAP Business Suite 4 SAP HANA (S/4HANA) has accelerated this growth by widening the use-case for SAP HANA from analytics to transactional processing for core business processes.

While the performance and administrative benefits of SAP HANA are clear-cut, the benefits for security are more questionable. Unlike conventional persistent databases, HANA does not provide any native capability for label-based access control, data discovery and classification, data redaction and masking, or database firewalls. HANA also presents an architectural challenge for security engineers since some implementation scenarios integrate application and database layers that are traditionally hosted in separate physical or virtual servers.

SAP has addressed some of these concerns in later releases of HANA. SPS 12 includes features to isolate databases in multi-tenant environments to prevent cross-database attacks. It also includes more advanced logging capabilities to support multiple log formats and fine-grained audit policies. This is discussed in the newly updated whitepaper Security in SAP HANA, available in the resources section. The whitepaper provides a framework for securing HANA systems including network security, authentication and authorization, encryption for data in transit and at rest, and OS-level security for SUSE Linux Enterprise (SLES) and Red Hat Enterprise Linux (RHEL).

HANA vulnerabilities such as potential misconfigurations in database parameters or users with special privileges should be monitored using SAP Solution Manager (SolMan). In common with other SAP systems, HANA is connected to and monitored by SolMan. Security-relevant data is extracted by agents from HANA and transmitted to SolMan for analysis. SolMan analyzes the data using rulesets to identify potential vulnerabilities that could be exploited by attackers. The results are accessible through BW or BI including Lumira and Crystal Reports.

Rulesets benchmarked against best practices and SAP recommendations can be licensed from Layer Seven Security and imported directly into your Solution Manager platforms. To learn more, contact us.