SAP Netweaver Archives - Page 2 of 4

Q&A: Cybersecurity Monitoring with SAP Solution Manager

Layer Seven on July 30, 2017

How does Solution Manager detect threats and vulnerabilities in SAP systems? What specific applications in SolMan are used for vulnerability, patch and threat management? What are the requirements for using these areas? How long does it take to configure? What are the differences between monitoring using SolMan 7.1 and 7.2? What are the benefits of using SolMan versus third party tools? Why should you partner with Layer Seven Security to help you leverage the cybersecurity capabilities of SAP Solution Manager?

Discover the answers to these and many other questions in the new Q&A section and learn how you can immediately protect your SAP systems from advanced threats using tools you already own and an approach recommended by SAP.

Remember to bookmark the page since we will be updating the questions and answers periodically. Also, feel free to submit your questions for our experts in the comments below.

Q: What is SAP Solution Manager?
A: Solution Manager is the most widely deployed SAP product after ECC. It’s installed in almost all SAP landscapes and is used for application lifecycle activities such as system patching and upgrades, change management, incident management, and system monitoring.

Q: How is Solution Manager licensed?
A: Usage rights for Solution Manager are bundled with SAP support and maintenance agreements. SAP Enterprise Support customers can manage their whole IT infrastructure with Solution Manager. Customers with Standard Support can manage SAP products within their IT landscapes with Solution Manager. Licensing for SAP HANA is included with the usage rights for SAP Solution Manager 7.2.

Q: What security tools are available in Solution Manager?
A: There are several applications in Solution Manger that should be used for advanced security monitoring. We recommend Service Level Reporting, Security Dashboards, System Recommendations, Interface Monitoring and Security Alerting.

Q: Why doesn’t Layer Seven Security recommend the EWA and SOS reports?
E: There are drawbacks with both reports. The EarlyWatch Alert (EWA) performs some security checks but is not specifically a security report. Therefore, the range and volume of checks performed by EWA for security is low. The Security Optimization Service (SOS) provides better coverage but is not fully automated. You must submit a service request to run SOS for ABAP systems. Service requests to run SOS for Java systems must be submitted to SAP.

Q: What are Service Level Reports?
A: Service Level Reports (SLR) automate vulnerability reporting for SAP systems. They perform scheduled checks for hundreds of security weaknesses for ABAP, HANA and Java systems and automatically distribute the results via email, SFTP or the Enterprise Portal. SLRs include detailed descriptions for findings, risk ratings, links to relevant SAP Notes and guidance at the SAP Help Portal and compliance scorecards for frameworks such as NIST, PCI DSS and IT-SOX.

Q: How do SLRs work?
A: SLRs read the results of automated daily vulnerability scans performed by Solution Manager for SAP systems. The results are checked against security KPIs during runtime. SLRs are typically scheduled to run on a weekly or monthly schedule.

Q: Are SLRs available in multiple languages?
A: Yes, SLRs can be run in any language including French, German, Spanish, Arabic, Japanese, and Mandarin.

Q: Are SLRs customizable?
A: Yes, you can customize every aspect of service level reports including the design, layout, security checks, and KPI metrics and thresholds.

Q: Can you provide a sample Service Level Report?
A: Yes, submit your request here.

Q: What is System Recommendations?
A: System Recommendations is an application in Solution Manger that performs automated patch management for SAP systems. It connects directly to SAP Support to download required security notes and monitor the status of notes implemented in systems through regular background jobs.

Q: Does System Recommendations also download and apply corrections?
A: Yes, System Recommendations downloads corrections from SAP Support to target systems. The user is automatically directed to SNOTE in the target systems once the corrections are downloaded.

Q: Does System Recommendations identify the impact of security patches?
A: Yes, System Recommendations integrates with applications in Solution Manager to perform change impact analysis and discover programs, function modules, transactions, reports and business processes effected by notes.

Q: Does System Recommendations integrate with Change Request Management (ChaRM)?
A: Yes, System Recommendations includes the option to automatically generate a change request for required notes.

Q: What are Security Dashboards?
A: Security Dashboards monitor critical key performance indicators to track vulnerabilities and threats across SAP landscapes in real-time.

Q: What type of metrics are monitored by Security Dashboards?
A: The Dashboards connect to data stores in Solution Manager for event-driven alerts and system and user level vulnerabilities. Users can drilldown from aggregated results to detailed values.

Q: What type of data visualizations are available in the Security Dashboards?
Users can select from column, line, pie, scatter and other charts and Fiori tiles and tables.

Q: What is Interface Monitoring?
A: Interface Monitoring is used to map and track system interfaces in SAP landscapes including RFC, HTTP, IDoc and Web Service connections. It automatically creates a topology of system interfaces and monitors the usage of the interfaces in real-time. Alerts can be generated for channel metrics including availability, configuration and performance.

Q: What is Security Alerting?
A: Security Alerting is based on the Monitoring and Alerting Infrastructure (MAI) of Solution Manager. MAI connects to data providers including event logs to monitor for security vulnerabilities and incidents. MAI generates automatic notifications for security incidents including emails and text messages.

Q: What type of security vulnerabilities and events are monitored by MAI?
A: MAI monitors system-level vulnerabilities such as the enabling of the invoker servlet in Java systems, insecure entries in access control lists for gateway servers, vulnerable RFC destinations, missing security notes, and many other areas. It also monitors KPIs for user-level security including users with dangerous profiles such as SAP_ALL and unlocked standard users.

Q: Can you perform threat detection using MAI in Solution Manager?
A: Yes, MAI includes file and database connectors for real-time monitoring of event data captured in SAP logs. This includes the security audit log, HANA log, UME log, HTTP log, gateway server log, and the Read Access Log.

Q: Can you integrate MAI alerts with Security Information Event Management (SIEM) and incident management systems?
A: Yes, MAI alerts can be automatically forwarded to SIEM systems such as Splunk, ArcSight, and QRadar for event correlation and forensic analysis. Alerts can also be forwarded to incident management systems such as BMC Remedy and ServiceNow.

Q: Does Solution Manager provide best practices for alert handling?
A: Yes, the Guided Procedure (GP) Framework in Solution Manager provides best practices and standard operating procedures for investigating and resolving security alerts. This standardizes and improves incident management procedures and reduces response times. The guided procedures include automated steps to further improve incident handling.

Q: What are the main differences between SAP Enterprise Threat Detection (ETD) and threat detection using SAP Solution Manager?
A: SAP ETD provides more advanced capabilities for event correlation and forensic analysis. However, Solution Manager can forward event data to SIEM systems that can correlate and analyze data on a wider scale than ETD by combining data from SAP and non-SAP sources. Also, ETD does not monitor for system-level vulnerabilities or provide guided procedures for alert handling.

Q: What are the requirements for using the security applications in Solution Manager?
A: The security applications are available in any SP level of Solution Manager versions 7.1 and 7.2. The only requirements are the completion of the SOLMAN_SETUP procedures for the relevant version.

Q: What are the differences between Solution Manager 7.1 ad 7.2 for security monitoring?
A: The main difference is the user-experience. Solution Manager 7.2 provides the improved Fiori interface including a launchpad for direct access to applications. Some functions such as automatic download of SAP corrections in System Recommendations are only available in Solution Manager 7.2. Also, the dashboarding and interface monitoring capabilities are more advanced in the latest version of Solution Manager.

Q: How many environments and systems can you monitor with Solution Manager?
A: There are no limits on the number of environments or systems that can be monitored by Solution Manager. However, Solution Manager must be appropriately sized to monitor large landscapes.

Q: How long does it take to configure the security applications?
A: Typical implementation timeframes are between 2-4 weeks for mid-sized landscapes.

Q: If security applications are available in standard installations of Solution Manager, why do we need to work with SAP Partners such as Layer Seven Security to configure these components?
A: Solution Manager provides the framework and the tools to perform advanced security monitoring. However, the standard installation of Solution Manager does not provide sufficient content for security monitoring. The content is developed, maintained and supported by Layer Seven Security. This includes patent-pending custom security policies, BW infoproviders, service level reports, monitoring objects and guided procedures. The content is licensed by SAP customers from Layer Seven Security and imported or transported into Solution Manager.

Q: What are the benefits of using Solution Manager for security monitoring versus third party tools ?

A: There are many advantages for using Solution Manager over third party tools. The most significant is lower cost: licensing and importing content for Solution Manager is less expensive than licensing entire platforms and solutions for SAP security monitoring. Solution Manager is also more flexible and customizable. It’s also recommended by SAP and supported and maintained directly by SAP. For further information, download the comparison chart.

Q: Does Layer Seven Security provide online demos for security monitoring using Solution Manager?
A: Yes, you can request a demo here.

Q: Does Layer Seven Security provide free readiness checks and trials for security monitoring using Solution Manager?
A: Yes, we offer free readiness checks to discover and remove any configuration gaps in Solution Manager to support security monitoring. We also provide free trials for Layer Seven’s custom security content. The trials can be performed remotely or on-site for up to 5 systems.

Q: Who shall I contact for further information?
A: Please call Layer Seven Security at 1-647-964-7370 or email info@layersevensecurity.com

A First Look at Support Pack 5 of SAP Solution Manager 7.2

Layer Seven on June 26, 2017

Released earlier this month, Support Pack 5 for SAP Solution Manager 7.2 delivers important enhancements in several key areas. This includes support for exporting and importing solution documentation between systems, improved SAP-delivered solution blueprints, and an enhanced graphical editor for mapping business processes. SP05 also introduces a new Fiori App for Quality Gate Management in ChaRM. There are also new Fiori Apps for Data Volume Management to support data aging and identifying unused data.

For security, SP05 introduces several notable changes. Solution Manager Configuration and Administration now includes a tile for Security-Relevant Activities. This function can be used to check the status of authentication, connection, and user related activities required for the effective setup and operation of Solution Manager.

Solution Manager Configuration and Administration also includes a new scenario for setting up and tracking usage logging. Areas such as System Recommendations analyze usage data to identify the impact of changes and corrections on ABAP objects.

SP05 also introduces several functional improvements for System Recommendations. The available filters in System Recommendations now include a selection field for Note Number. This can be used to jump directly to specific Notes.

System Recommendations also includes a new tool for side-effect Notes. The tool was originally introduced in the SAP Marketplace in 2003 and enables users to identify interdependencies between SAP Notes and guard against the known side-effects of applying certain SAP Notes. Note 651948 discusses side-effects Notes.

Interface and Connection Monitoring (ICMon) includes an improved interface to drill down from monitoring overviews and topologies to the details of each interface channel. Users can also now assign severity ratings for ICMon alerts. SP05 widens the coverage for supported interface channels to include the SAP Application Interface Framework, SAP Information Lifecycle Management (SAP ILM) and Ariba Network. It also provides additional metrics for monitoring existing channels such as web services.

The Fiori launchpad for Solution Manager SP05 includes new tiles for the Guided Procedure Framework. The Guided Procedure Catalog can be used to browse available guided procedures. The Guided Procedure Usage tile can be used to access the execution logs for guided procedures. Available filters have also been improved to support selection for guided procedures based on technical systems and hosts.

Full details of the changes introduced with SAP Solution Manager Support Pack 05 are available at the SAP Help Portal.

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.

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.

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.

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.