Cyber Security Archives - Page 9 of 12

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

7 Reasons You Should Upgrade to SolMan 7.2

Layer Seven on August 2, 2016

SAP Solution Manager (SolMan) is the epicenter of SAP implementations and the standard for monitoring and maintaining SAP landscapes. The general availability of release 7.2 in August is expected to deliver major advances in seven specific areas.

The first is support for managing the implementation lifecycle of HANA and S/4HANA. SolMan 7.2 is optimized to not only manage HANA systems but also run directly on HANA. Licenses for HANA are bundled with SAP maintenance contracts and are therefore effectively free for SolMan 7.2.

The second is support for hybrid systems. SolMan 7.1 SP13 or lower is directed primarily at ABAP and Java systems. However, SolMan 7.2 will extend support for monitoring both cloud and on-premise environments including SuccessFactors.

The third is an improved user experience through SAP Fiori. The Fiori launchpad provides a simple and graphical interface and replaces the work centers available in release 7.1. Dashboards have been migrated from Adobe Flash to the SAPUI5 (HTML5). Since HTML5 can be rendered on any device, SolMan no longer needs Android and iOS apps to support mobile users. The Fiori Launchpad enables users to personalize their screens to include access to other applications (see below).

The fourth is a wider array of application and cross-application dashboards for monitoring metrics such as system security, changes, events, incidents, availability and performance. Customers can also leverage custom dashboards using predefined templates available from Focused Insights. This includes dashboards for monitoring not just technical but business metrics. Focused Insights include over 800 best practices KPIs that can be deployed in minutes without programming.

The fifth is an enhanced Custom Code Management application to enable customers to optimize the quality, performance and security of custom developments. This includes governance models to identify custom code in system landscapes and tools such as UPL and SCMON to track the usage of custom code. Usage data can be used to decommission idle code to lower the attack surface for custom developments and reduce the scope of testing during system upgrades or enhancements.

The sixth is tighter integration between the Test Suite and solution documentation, enabling customers to focus testing on business processes impacted by proposed changes. This is performed using Business Process Change Analyzer (BPCA). BPCA leverages the inventory of business processes in solution documentation and Technical Bills of Materials (T-BOMs) for executables within processes.

SolMan 7.2 enables users to record and replay test scripts to automate testing using Component-Based Test Automation (CBTA). These and other applications for creating and maintaining test plans, scripts, and results including defects are accessed through the Test group in the SAP Fiori Launchpad.

The seventh and final reason for upgrading to SolMan 7.2 is that SAP cannot extend the deadline for ending maintenance for release 7.1 beyond December 31, 2017. Customers have a relatively short window to upgrade to release 7.2. The Monitoring and Alerting Infrastructure (MAI) is mandatory for all operations in SolMan 7.2. Therefore, MAI must be enabled in SolMan 7.1 before any upgrade. A stack split is performed during the upgrade procedure. Database migration to SAP HANA can also be performed during the upgrade. Detailed information is available in Notes 2161244, 2045230 and 2045342.

To discuss how Layer Seven Security can support your Solution Manager 7.2 implementation or upgrade projects, contact us here.

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.

US-CERT Issues Alert for SAP Invoker Servlet Vulnerability

Layer Seven on May 12, 2016

US-CERT published an alert yesterday to warn SAP customers of the dangers posed by the invoker servlet vulnerability in AS Java systems. According to the alert, there is evidence to suggest that SAP systems at 36 organizations have been exploited by the vulnerability. The organizations are based in the United States, United Kingdom, Germany, China, India, Japan, and South Korea, and operate in industries that include oil & gas, telecommunications, utilities, retail, automotive and the pubic sector.

The invoker servlet vulnerability arises when servlets can be called directly either by servlet name or by fully-qualified class name. This can be exploited to bypass authentication and authorization rules defined in the web.xml files of Java applications. In the cases referenced by the US-CERT alert, attackers appeared to have exploited the invoker servlet to call a Java component that enabled them to execute OS commands and create user accounts in SAP systems.

The vulnerability was patched by SAP in 2010. SAP also modified the default configuration of AS Java to disable the invoker servlet in versions 7.20 and later. Corrections were provided in Notes 1445998 and 1467771. The evidence of the active exploitation of the invoker servlet vulnerability five years after the underlying flaw was patched by SAP demonstrates that the greatest risk posed to SAP systems is the exploit of known weaknesses rather than so-called zero-day vulnerabilities.

The invoker servlet should be disabled at a global level by setting the EnableInvokerServletGlobally key to false. The key is located in the global properties of each J2EE instance. You can follow the three steps below to discover systems in your landscape vulnerable to the exploit using SAP Solution Manager.

1. Create a target system in Configuration Validation to check the value of the key for all systems using the servlet_jsp store. See below.

2. Edit the target system by removing all parameters in the servlet_jsp store except EnableInvokerServletGlobally. Set the value for the key to true and maintain the weight/ info. See below.

3. Run the weighted validation report for all Java systems and review the results of systems with the EnableInvokerServletGlobally set to true. See below.

The invoker servlet vulnerability is one of the 500+ checks performed by security rulesets provided by Layer Seven for ABAP, Java, HANA, and database systems. The rulesets can be imported into your Solution Manager systems in seconds to perform daily automated scans for vulnerabilities in SAP systems. To learn more, contact Layer Seven Security.

How to Visualize Cyber Security Risks in Your Systems with SAP Lumira

Layer Seven on April 28, 2016

SAP Lumira can be used to access, visualize and explore data of any size from virtually any source. It enables users to build and share powerful interactive data visualizations using a simple user-friendly interface. Since Lumira can acquire data and enable users to create customized reports through self-service, it removes the need for programming, scripting and any other form of development.

This article demonstrates how you can use Lumira to visualize security vulnerabilities in your SAP systems and overcome limitations with standard Business Warehouse (BW) reports. The demonstration is based on the Standard Edition of Lumira, available at the SAP Store. This edition will operate with minimal hardware requirements from any system with a Windows 7 or higher operating system.

After Lumira is installed, you will need to add the BW data connector using the Extension Manager since the data source is underlying BW reports in Solution Manager (SolMan). The reports store the results of automated security reviews performed by SolMan. The next step is to set the connection to the BW server in SolMan under Network in the Preferences section. This includes the server URL, hostname, instance and user credentials required for the connection.

Once the connection is established, you can define the variables including reference systems, comparison systems, stores, items and fields. This covers the security policies setup in SolMan, the systems that are mapped for monitoring, and the containers that store the results of the security reviews. We recommend creating a separate Lumira report for each security policy based on different system types (ABAP, Java, HANA, etc.).

You can begin building your visualization and exploring security vulnerabilities as soon as the data is acquired by Lumira. In the report below, we have created charts and tables that convey security vulnerabilities discovered using SolMan by area, system and risk level.

The results can be filtered by any of these elements. The tables provide details of each finding including the objectives of every check, recommendations to remove vulnerabilities, links to relevant SAP Security Notes, and information available at the SAP Help Portal. The reports can be exported to PDF, CSV or Excel. They can also be shared via URLs with users or groups defined in Lumira.

SAP Lumira can be used to visualize not only security vulnerabilities discovered by Solution Manager but also unapplied Security Notes in SAP systems. See below.

To learn more or to discuss how we can assist your organization leverage the full capabilities of SAP Lumira for dynamic, cost-effective and real-time security monitoring, contact Layer Seven Security.

How to Block RFC Callback Attacks in Your SAP Systems

Layer Seven on March 23, 2016

Callback attacks exploit weaknesses in RFC security to execute function modules in calling systems. The impact of such attacks can be severe, ranging from the creation of dialog users with system-wide privileges to modifying or extracting sensitive data. This can occur if client systems execute malicious code within the function modules of connected systems. In the following example, the source code for the standard function module RFC_PING within a compromised system has been modified to create a new user with the SAP_ALL profile in any client system that connects to the system and calls the function module to perform a connection test.

The called system will exploit the callback functionality of RFC calls to firstly execute the BAPI_USER_CREATE1 function module to generate the dialog user in the calling system and secondly, run the BAPI_USER_PROFILES_ASSIGN function module to assign the SAP_ALL profile to the new user. Once this is complete, the attacker will be able to logon directly into the calling system with the new user. Since this is performed in the background, administrators that perform the connection test from the calling system would not be able to detect the exploit based on a review of the test results returned by the system (see below).

Callback attacks can be exploited to hop from development or test systems to productive systems by exploiting insecure RFC destinations between systems in different environments. Such attacks rely on the privileges of RFC users in client systems. Therefore, it’s important to restrict the authorizations of technical users to the minimal required for each scenario.

They also count on the ability to call any function module within client systems to run exploits. This should be controlled by enabling positive whitelists for RFC callbacks. Whitelists are controlled by the profile parameter rfc/callback_security_method. Empty whitelists should be enabled by default for all new RFC destinations. For existing destinations, rfc/callback_security_method should be set to 1 and the DUI event should be enabled in the Security Audit Log. This will log RFC callbacks executed within the system. The called function modules are displayed in the message text (see below).

The log results are available in RFC destination maintenance using transaction SM59. Administrators can use the log results to automatically generate whitelists for permitted callbacks to specific function modules for each destination. Once the whitelists are generated, rfc/callback_security_method should be set 2 to enable the whitelists in simulation mode. At this point, the DUJ event should be enabled in the Security Audit Log to record rejected RFC callbacks. The log results should be periodically reviewed to update the whitelists before finally activating all whitelists through rfc/callback_security_method=3. Once activated, callbacks to function modules outside the whitelists are rejected by client systems (see below).

Survey Reveals 65 percent of SAP Platforms Were Breached Between 2014-15

Layer Seven on February 26, 2016

Earlier this week, the Ponemon Institute released the results of the most comprehensive study performed to date on the state of SAP cybersecurity. The Institute is widely known for the annual Cost of Data Breach report that trends average data breach costs across major countries. However, it also performs a variety of other studies related to privacy, data protection and information security. It’s latest study Uncovering the Risks of SAP Cyber Breaches reviews the challenges and perceptions associated with securing SAP platforms. The study surveyed over 600 IT and security professionals between December 2015 – January 2016.

The key findings of the study include:

65% of SAP platforms suffered one or more security breach over the prior 24 months. 32% experienced between 1-2 breaches. 16% were breached 3-4 times and 12% between 5-6 times

75% of respondents believe it is likely their SAP platforms have one or more malware infection

The impact of an SAP breach is serious to catastrophic in 92% of organizations

The average cost of a breach that interrupts the availability of SAP systems is $4.5M

47% of respondents expect the volume of cyber attacks against SAP systems to increase over the next 24 months. 42% expect no change. Only 11% expect a decrease

75% express low levels of confidence in their company’s ability to immediately detect an SAP breach. 65% believe they would not be able to detect a breach within one week and 59% doubt they would be able to detect a breach within a month

59% expect trends such as the cloud, mobile, big data and IoT to increase the attack surface and the probability of a breach in SAP systems

The ability to assess and audit compliance levels of SAP systems against security policies and standards is considered important by 78% of respondents

81% believe it is important to continuously monitor the security of SAP platforms

54% of respondents supported the statement that it is the responsibility of SAP, not their organizations, to safeguard the security of SAP software. The reality is that the responsibility is shared. SAP is responsible for ensuring the integrity and security of software code. To this end, SAP works diligently to detect and remove programming errors before and after the release of applications. However, the responsibility for implementing patches for programming and other errors lays exclusively with the customer.

SAP is also accountable for providing guidance to securely configure its systems and counteract known vulnerabilities and attack vectors. Recommendations for dealing with RFC exploits, password attacks, standard users, vulnerable Java and ICF services, and numerous other areas can be found in online SAP security guides, as well as SAP advisories and papers such as the Secure Configuration of SAP NetWeaver Application Server using ABAP and Securing Remote Function Calls.

Finally, SAP is responsible for providing customers with the tools to secure their infrastructure. This includes tools for identifying and applying security patches, performing continuous and automated audits for vulnerabilities that may be exploited to breach systems, and supporting real-time threat detection and response. SAP’s product portfolio includes tools to meet all of these needs. Patch management can be performed using System Recommendations. Vulnerability management for over 500 vulnerabilities impacting ABAP, Java and HANA systems can be accomplished using Configuration Validation. Customers can leverage these tools within their Solution Manager platforms without resorting to third party software solutions. For real-time threat management, customers can deploy Enterprise Threat Detection. Alternatively, they can integrate their SIEM platforms directly with SAP systems using adaptors or indirectly using agents.

Cybersecurity Targets in China’s New Five Year Plan

Layer Seven on February 19, 2016

The details of China’s latest five year plan covering the period between 2016-2020 are expected to be released next month but early indications suggest it will focus upon reducing China’s reliance on foreign technology. Intelligence agencies and security researchers contend there is a strong correlation between industries targeted for growth by China and industries that suffer data breaches as a result of targeted attacks. For example, China’s last five year plan covering 2010-2015 focused upon sectors such as energy, healthcare and manufacturing. Over the same period, companies within these sectors experienced large-scale breaches that bore the hallmark of state-sponsored attacks. This includes organizations such as Anthem, US Steel, Medtronic and Westinghouse.

Since the new five year plan will launch during a period of unprecedented low growth in China, it is expected to lead to even more aggressive economic espionage in the form of cyber attacks against sectors targeted by China. This is likely to accelerate the shift from cyber attacks performed by criminal gangs for financial motives to state-sponsored cyber espionage driven by the strategic objectives of nation states.

According to the recently released Global Threat Report from CrowdStrike, the industry most at risk from China’s attention is energy. The new five year plan is expected to include objectives for building more nuclear power facilities, clean energy technology, and reducing China’s dependence on foreign oil. Next in line is transportation as China seeks to expand its airline and high speed rail industries, and domestic car production, including support for electric and hybrid transportation. Third is the public sector. China is expected to increases efforts to target foreign governments and think tanks in order to further its national interests. Fourth is the defense industry, particularly weapon systems, military personnel information, logistics, and technology related to aircraft carriers and drones. Fifth is the technology sector including the semiconductor industry, software source code, and social media applications that China is looking to replace with domestic versions. Other industries that are expected to feature heavily in the plan are healthcare, telecommunications, finance, manufacturing, media and agriculture. The Global Threat Report is available at crowdstrike.com.