Layer Seven Security

Get Ready for SAP Solution Manager 7.2: What to Expect

SAP Solution Manager 7.2

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

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

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

SAP Solution Manager 7.2

SAP Solution Manager 7.2

SAP Solution Manager 7.2

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

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

SAP Solution Manager 7.2

SAP Solution Manager 7.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to Implement Advanced Security Monitoring Without Third-Party Software

The fear and anxiety driven by the wave of cyber attacks in recent years has led many companies to bolster their security programs. It’s also led to a stream of software solutions from third-party developers offering to solve customers’ cyber security challenges. You may have heard the sales spin, watched the demos, and even considered the proposals. But before you launch the purchase order, ask yourself: Is there an alternative? What if the tools you need to secure your SAP systems were available to you at this very moment?

SAP has equipped customers with a variety of tools to protect against even the most advanced forms of cyber threats. The tools are available in SAP Solution Manager and include:

1. Configuration Validation: Implement automated vulnerability checks across your entire SAP landscape

2. System Recommendations: Detect security-relevant SAP patch day and support package notes

3. Change Analysis: Analyze the root cause of changes in your SAP systems

4. End-to-End (E2E) Alerting: Investigate email and SMS alerts for critical SAP security events

5. Security Dashboards: Monitor the health of your SAP systems in near real time

Read more at SAPinsider

Cyber Security Monitoring using SAP Solution Manager

Are 95 percent of SAP systems really vulnerable to cyber attack?

Earlier this month, SAP issued a strongly-worded response to claims made by the software vendor Onapsis in a press release that over 95 percent of SAP systems assessed by Onapsis were exposed to vulnerabilities that could lead to the compromise of SAP systems. According to SAP, “The press release published by Onapsis is aimed at alienating SAP customers while promoting Onapsis’ own products. The assertion that over 95% of SAP systems were exposed to vulnerabilities is false.” In spite of such protests, the claims led to a wave of concern over vulnerabilities in SAP systems. The concerns were deepened by the revelation that the data breach at the government contractor USIS reported in 2014 was caused by a vulnerability in an SAP ERP system. The forensic investigators engaged by USIS to review the breach concluded that attackers were able to gain access to the system by exploiting an undisclosed SAP-level vulnerability or series of vulnerabilities. This assertion was based on evidence contained within SAP application trace logs and other sources. The breach led directly to the leakage of highly sensitive information impacting an estimated 25,000 government employees.

Along with similar incidents experienced by the Greek Ministry of Finance and Nvidia, the breach at USIS has served to illustrate the devastating impact to organizations when SAP systems are not securely configured and monitored to guard against possible cyber attack. Since the news of the source of the breach became public, security researchers have put forward several theories of possible exploits that could have been employed by attackers to compromise SAP systems connected to USIS. The theories include the use of default passwords, vulnerabilities in RFC gateways, remote code execution, and even database-level exploits. The fact that the attackers were presented with such an array of possible vectors is disturbing to say the least and highlights the wide attack surface presented by SAP systems.

Unless the specific SAP vulnerability that was exploited to breach USIS was a zero-day exploit, its likely that the breach could have been prevented through the proper hardening of SAP systems, regular patching, and continuous monitoring using tools provided by SAP in Solution Manager. It should be noted that almost all the attack vectors presented by researchers to explain the attack at USIS can be blocked by either applying applicable SAP patches or by observing the relevant SAP security guidance. This also applies to the so-called ‘Top Three Common Cyber Attack Vectors for SAP Systems’ declared by organizations such as Onapsis. Furthermore, once hardened, SAP systems do not necessarily require third party tools to monitor for possible changes or configuration errors that may expose them to cyber threats. The simplest, quickest and most cost-effective strategy is to leverage tools available in Solution Manager. They include System Recommendations for patch management, Change Analysis for detecting and investigating configuration changes, Alerting for security incident and event management, Dashboards for compliance monitoring and finally, Configuration Validation for comprehensive, automated vulnerability management. In short, both the information and the tools you need to secure your SAP systems against the type of attack that breached USIS are available to you at this very moment.

Discover Security Patches for your SAP Systems using System Recommendations

One of the most startling facts revealed by the 2015 Cyber Risk Report is that over 44 percent of data breaches stem from the exploitation of known vulnerabilities that are over two years old. This suggests that effective patching can dramatically lower the likelihood of a successful data breach and, when employed with other countermeasures such as system hardening to prevent misconfigurations, it can reduce the risk to negligible levels.

Developing a workable patch management process that addresses the numerous threats confronted by SAP systems presents a formidable challenge for organizations. The need to maintain high levels of availability and control changes that may negatively impact system performance or even lead to software regression often delays the implementation of critical patches. In some cases, it prevents the application of security patches altogether.

The risks posed by weaknesses in patching procedures should not be understated and are borne out by the findings of the HP study. Statistics reveal a direct correlation between ineffective patching and significantly higher levels of susceptibility to security threats that lead to data breaches.

Traditionally, SAP customers have relied upon tools such as RSECNOTE and SAP EarlyWatch Alert (EWA) to identify patches and verify their implementation status. RSECNOTE can be executed using transaction SA38 or ST13. It should return relevant Security Notes and convey whether Notes are successfully implemented, require implementation or are manually confirmed.  EWA is a diagnosis report that is run from SAP Solution Manager for managed systems on a weekly schedule. The system configuration checks performed by EWA should include an identification of relevant Security Notes.

EWA, however, no longer performs any meaningful check for security-relevant Notes. Fewer than 10 percent of the 364 Patch Day Notes and Support Pack Notes released by SAP in 2013 were checked and reported through EWA. By 2014, EWA had lost all relevance for security patching: none of the 389 SAP patches released last year were checked by EWA.

RSECNOTE has not fared any better.  According to Note 888889 updated in September 2014, the tool is effectively deprecated by SAP and should no longer be relied upon.

Note 888889

RSECNOTE and EWA have been replaced by tools with more powerful calculation engines capable of supporting more detailed analysis of not just Hot News and Security Notes, but also Java patches and Notes for general, performance and legal areas.

These tools include System Recommendations (SysRec), accessible through the Change Management Work Center of SAP Solution Manager. SysRec uses the SAP-OSS RFC destination to connect directly to SAP Global Support and check the status of Notes in managed systems. The results are based on the specific kernel, patch and support package level of systems maintained in the Solution Manager System Landscape (SMSY). This minimizes the risk of both false positives and false negatives.

SysRec can be filtered by SAP system, component and date range. Only components are that are applicable to the selected system are displayed by SysRec.

SysRec2

Priority levels and the implementation status of each Note are displayed in the returned results. The Download Notes option can be used to download all or selected Notes from the SAP Service Marketplace. Click on the image below to enlarge.

SAP System Recommendations

SysRec can be used to identify both ABAP and Java patches. However, Java patch notes are displayed in the Corrections tab rather than the tab for Security Notes.

The Create Request for Change option is used to trigger a change request to implement the relevant Notes when using ChaRM.

The automated job SM:SYSTEM RECOMMENDATIONS should be scheduled to collect information on the status of implemented Notes from managed systems. The frequency of the automatic check can be set to daily, weekly or monthly.

SysRec4

Once corrections are identified and applied, the implementation status of the Notes should be validated across all systems in your landscape. This can be performed using Configuration Validation. The implementation status of Notes is recorded in the PRSTATUS field of the ABAP_NOTES store. The PRSTATUS of completely implemented notes should be E. Therefore, you can define operators to search for Notes implemented in a reference system with the identical component and release dependencies that have the same PRSTATUS. Based on the example below, for instance, Configuration Validation will check that version 2 of Note 1922205 for component SAP_BASIS  is completely implemented (PRSTATUS = E), taking into account the release dependencies.

SAP System Recommendations

Notes that are not completely implemented in comparison systems are flagged as non-compliant in BW reports generated by Configuration Validation.

SAP System Recommendations

SAP Cybersecurity Framework 2.0: What’s New?

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.

Featured in SAPinsider: How to Build Security using SAP Solution Manager

Data breaches occur all too often and organizations are frequently left blindsided. As a result, cybersecurity has become a board-level issue across all industries. According to a recent survey of global business leaders, cyber risk is regarded as one of the most significant threats faced by corporations today, and is consistently rated higher than legislation, regulation, and other risks.

Even SAP systems are not immune from the anxiety surrounding cybersecurity. The architecture and complexity of SAP landscapes, as well as the form and volume of data typically managed within SAP systems, makes them targets for attackers. This was illustrated by the discovery of a modified Trojan that was targeting SAP clients in 2013. The malware targeted SAP GUI configuration files and was capable of malicious activities such as logging keystrokes; capturing logon credentials; and identifying, copying, and exporting files.

Responding to such threats is a daunting challenge. However, SAP customers do not have to look far for the tools to secure their systems from cyber threats. In fact, SAP offers a variety of tools with standard license agreements that can be leveraged immediately at zero cost.

Read more at SAPinsider

How to Secure SAP Systems from Password Attacks

Exploiting weak password hashes is one of the most common and successful attack scenarios used against SAP systems. The availability of open-source programs such as Hashcat and John the Ripper enables even novice hackers to perform attacks against SAP passwords. In fact, Hashcat is capable of breaking any SAP password encoded using the BCODE hash algorithm in a maximum of 20 hours, regardless of the length and complexity of the password.

SAP systems support a variety of cryptographic algorithms to convert passwords into hash values. These values are stored in table URS02. This is designed to prevent the storage of passwords in clear-text. During the logon procedure, passwords entered by users are converted to a hash value and compared to the value stored for the user in table USR02. The logon is successful if there is match between the two values.

Since hash algorithms are one-way, it is not possible to calculate passwords from hash values. However, it is possible to compare values generated by tools such as Hashcat to the values stored in SAP tables to break passwords providing both are encoded using the identical algorithm.

Therefore, it is critical to restrict the ability to read and extract password hash values in table USR02. This can be achieved by controlling direct access to database tables through SQL statements using firewall rules. The ability to read tables using generic table browsing tools accessible through transactions SE16, SE17 and SE11 should also be restricted and monitored.

Note that USR02 is not the only table containing password hash values. In some releases, hashes can also be found in tables USH02, USH02_ARC_TMP, VUSER001 and VUSR02_PWD. Such tables should be assigned to the authorization group SPWD (refer to Note 1484692). Access to table USRPWDHISTORY should also be restricted since attackers are often able to guess current passwords based on former passwords if users employ variations of the same password.

There should be similar restrictions on debugging and transport authorizations since these can also be used to access or export SAP tables containing password hashes.

Users with access to multiple systems or systems in different environments should be required to use different passwords for each system and environment. Passwords for productive systems should not be identical to those used to access development or test systems.

SAP password code versions A-E are based on the MD5 hashing algorithm. The hash values generated through this mechanism are stored in the table column BCODE. All MD5 hashes are susceptible to brute force and other password attacks. Code versions F and G use the SHA1 algorithm. SHA1 hashes are stored in the PASSCODE column. They are less vulnerable than MD5 hashes but can be broken if passwords are short and relatively non-complex. The most secure hashing algorithm supported by SAP systems is iterated salted SHA-1 in code version H. This mechanism uses random salts and a higher number of iterations to mitigate password attacks. Iterated salted SHA-1 hash values are stored in PWDSALTEDHASH.

SAP kernels should be upgraded to 7.02 or higher to support PWDSALTEDHASH hash values. For added security, default iterations and salt sizes can be increased using the login/password_hash_algorithm parameter.

Once this is performed, the profile parameter login/password_downwards_compatibility should be set to 0 to ensure only the strongest possible hash values are generated. CUA systems can be excluded from this requirement if they are connected to systems that do not support PWDSALTEDHASH.

The report CLEANUP_PASSWORD_HASH_VALUES should then be run to discover and remove redundant password hashes. There is a clear security risk if this is not performed. Attackers may be able to use passwords encoded in BCODE and PASSCODE hashes if users employ identical or similar passwords encoded in PWDSALTEDHASH.

Enforcing single sign-on (SSO) for all dialog users provides the optimal level of protection against password attacks by removing the need to store hashes altogether. However, once SSO is enabled, direct logons should be blocked through the parameter snc/accept_insecure_gui=U and by ensuring users are not exempted from SSO through settings in user records maintained in the SNC tab of SU01.

Taken together, these countermeasures should safeguard systems from dangerous password attacks aided by well-known and easily accessible tools that can be leveraged to take full control of SAP systems.

Update: A new version of Hashcat capable of cracking SAP code version H password hashes encoded using SHA-1 is currently in beta testing. You can learn more at http://hashcat.net/forum/thread-3804.html

A Five Step Guide to Securing SAP Systems from Cyber Attack Without Breaking the Bank

With SAP solutions deployed by 85 percent of Forbes 500 companies, they are a prized target for cyber attackers. Watch our Webinar playback to discover how to secure your SAP systems against targeted cyber attacks that could lead to denial of service, financial fraud or intellectual property theft. The Webinar is hosted by John Corvin, a Senior SAP Security Architect at Layer Seven Security. The insights delivered during the Webinar are based on lessons learned from hundreds of front-line engagements, aligned with leading practices and SAP recommendations and delivered by experienced SAP security consultants. Learn how to:

Secure SAP networks and communications
Protect remote function calls
Control critical user authorizations
Build log forensics
Configure security-relevant parameters

The Webinar will also enable you to identify opportunities for your organization to continuously monitor the security of SAP systems using standard tools and components available in SAP Solution Manager without licensing costly third party software. This will empower your organization to unlock the potential of SAP software and maximize the ROI of SAP licensing, while minimizing software-related capex and opex.

 

Can’t access YouTube? Watch on Vimeo: https://vimeo.com/107386560

A Dangerous Flaw in the SAP User Information System (SUIM)

Customers that have yet to implement Security Note 1844202 released by SAP on June 10 should do so immediately. The Note deals with a vulnerability that could be exploited to bypass monitoring controls designed to detect users with privileged access, including the SAP_ALL profile. This profile can be used to provide users with almost all authorizations in SAP systems. The vulnerability arises from a flaw in the coding of the RSUSR002 report accessible through the SAP User Information System (SUIM) or transaction SA38. RSUSR002 is a standard built-in tool used by security administrators and auditors to analyse user authorizations. A side-effect of Note 694250 was the insertion of the following line into the algorithm for RSUSR002:

DELETE userlist WHERE bname = “”

As a result of the insertion, users assigned the name “” are excluded from the search results generated by RSUSR002. This could lead to a scenario in which users are assigned SAP_ALL or equivalent authorizations without detection through regular monitoring protocols. However, the user “” would remain visible in UST04 and other user tables. The implementation of Note 1844202 will close the vulnerability in RSUSR002. Customers can also prevent the assignment of the username “” using customizing lists. For detailed instructions, refer to Note 1731549.