Firewalls, intrusion detection systems, and antivirus solutions may not protect SAP systems against advanced cyberattacks. However, this does not necessarily mean that SAP customers have to license third-party vulnerability scanning or threat detection solutions to deal with the risk. The answer to their security questions may be closer than they realize. Bundled with standard and enterprise SAP support agreements, SAP Solution Manager 7.2 includes five integrated applications to safeguard SAP systems against cyber threats:
Service Level Reporting (SLR)
Dashboard Builder
System Recommendations
Interface and Connection Monitoring (ICMon)
and the Monitoring and Alerting Infrastructure (MAI)
Interface Monitoring provides the answer to one of the most vexing questions in SAP security: where are our vulnerable cross-system connections and how do we monitor them to ensure they’re not abused by attackers?
Although Interface Monitoring, also known as Interface Channel Monitoring or ICMon, has been available in SAP Solution Manager since version 7.10 SP05, the application has been completely overhauled in version 7.2, especially in SP05, which has been in general availability since June.
ICMon in SolMan 7.2 includes an SAPUI5 graphical display that automatically maps the entire landscape topology in a single screen (see below). Topologies are generated by ICMon based on so-called monitoring scenarios configured in Integration Monitoring within SolMan configuration.
During scenario creation, you specify the systems and channels to monitor in each scenario. Multiple scenarios can be created to monitor different channels, systems, environments or other variables. Scenarios can also be landscape-wide to include all available systems and even cross-landscape to monitor systems located in different SAP landscapes.
Unlike some third party security tools that focus exclusively on RFC communications, ICMon can support monitoring for any SAP-supported protocol. This includes not only RFC, but HTTP, HTTPS, IDoc and Web Services.
Once the scenarios are configured, you can select from the list of available scenarios from Scope Selection in ICMon to monitor the scenario.
ICMon’s ability to automatically generate a graphical topology of cross-system connections enables users to discover vulnerable interfaces between systems including trust RFC relationships between systems in different environments. Trust relationships and stored credentials in RFC destinations could be exploited by attackers to, for example, pivot from vulnerable development or test systems to productive systems.
However, ICMon doesn’t just generate a static topology of system interfaces. It also continuously collects metrics and usage data for each channel to monitor availability, configuration and performance errors. Errors and warnings are displayed in both the ICMon dashboard (see below) and the topology. Connections with errors or warnings are displayed in red in the topology. Successful connections are displayed in green.
Usage data includes destinations and function modules called through each RFC channel with timestamps.
Alerts configured for metrics and thresholds including security-related scenarios can be viewed in the Alert Ticker from the ICMon home screen. The alerts can also be viewed in the Alert Inbox of SAP Solution Manager. In common with alerts for other application areas, ICMon uses the Monitoring and Alerting Infrastructure (MAI). Therefore, the Guided Procedure Framework can be used to apply standard operating procedures and best practices for incident management and alert handing.
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
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.
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.
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
The decision of the Office of the Comptroller at the U.S Department of Treasury to recognize cyber threats as one of the gravest risks faced by organisations today appears to be vindicated by the disclosure of an unprecedented data breach at Target Corporation shortly after the release of the Comptroller’s report. Specifics of the breach may not be known until the completion of an investigation currently underway by a forensics firm hired by Target to examine the incident. However, early reports suggest that the event may be one of the most devastating data breaches in recent years. According to a statement released by Target yesterday, approximately 40 million credit and debit card accounts may have been impacted between Nov. 27 and Dec. 15, 2013. The breach appears to have involved all of Target’s 1800 stores across the U.S. Based on the current average of $200 per compromised record, some estimates have placed the damage of the breach at $8 billion, almost three times the company’s net earnings in 2012.
The significance of the breach is related not only to the volume of records that have may have been compromised, but the type of data believed to have been extracted from Target. This includes sensitive track data stored within the magnetic stripe of payment cards. The card numbers, expiration dates and verification codes obtained through the track data could enable the perpetrators of the crime to create and sell counterfeit payment cards. There are three primary methods for compromising track data in retail scenarios. The first involves targeting switching and settlement systems. These systems are usually heavily fortified and traffic is commonly encrypted. The second entails the use of card skimmers. However, it is highly unlikely that skimmers could have been successfully installed across Target’s nationwide network of stores without detection. Therefore, the mostly likely method used by the attackers to obtain track data in such large volumes was through the compromise of the software that processes card swipes and PINs within Point-of-Sale (POS) systems at Target. Unfortunately, POS systems are a neglected area of information security, often regarded as little more than ‘dumb terminals’. This point of view could not be further from the truth. Today’s POS systems are sophisticated appliances that often run on Linux and Windows platforms. Furthermore, readily-available software development kits (SDK) for POS systems designed to enable developers to rapidly deploy applications for such systems could be abused to build dangerous forms of malware. This is the most probable cause of the breach at Target. Herein lays the first parallel between POS and ERP systems: although both process large quantities of sensitive information and lay at the core of system landscapes, security efforts are rarely equal to the strategic importance of such systems or aligned to the risks arising from their architecture.
The second parallel relates to the method used at Target to access and install the malware within the POS systems. This could only have been possible if the attackers were part of the software supply chain. Therefore, they mostly took advantage of some form of insider access. The counterpart in ERP systems is the often blind trust placed by organisations in third party developers, consultants and system administrators with broad access privileges.
The final parallel is the use of malware specifically aimed at business systems rather than individuals or consumers. Both POS and ERP systems are witnessing a surge in targeted malware. Systems such as SAP have always contended with this threat. One of the earliest known Trojans for SAP was discovered in 2003: KillSAP targeted SAP clients and, upon execution, would discover and replace SAPGUI and SAPLOGON files. Today’s malware is capable of far more destructive actions such as key logging, capturing screenshots, and attacking SAP servers through instructions received from remote command and control servers. The recently discovered Carberp-based Trojan is an example of such a threat. You can learn more about the risks posed by this Trojan at the Microsoft Malware Protection Center.
This article is an extract from the forthcoming white paper entitled Security in SAP HANA by Layer Seven Security. The paper is scheduled for release in November 2013. Please follow this link to download the publication.
According to research performed by the International Data Corporation (IDC), the volume of digital information in the world is doubling every two years. The digital universe is projected to reach 40,000 exabytes by 2020. This equates to 40 trillion gigabytes or 5200 gigabytes for every human being in the world in 2020. As much as 33 percent of this information is expected to contain analytic value. Presently, only half of one percent of available data is analyzed by organisations.
The extraction of business intelligence from the growing digital universe requires a new generation of technologies capable of analysing large volumes of data in a rapid and economic way. Conventional approaches rely upon clusters of databases that that separate transactional and analytical processing and interact with records stored in secondary or persistent memory formats such as hard disks. Although such formats are non-volatile they create a relatively high level of latency since CPUs lose considerable amounts of time during I/O operations waiting for data from remote mechanical drives. Contemporary persistent databases use complex compression algorithms to maximise data in primary or working memory and reduce latency. Nonetheless, latency times can still range from several minutes to days in high-volume environments. Therefore, persistent databases fail to deliver the real-time analysis on big data demanded by organisations that are experiencing a significant growth in data, a rapidly changing competitive landscape or both.
In-memory databases promise the technological breakthrough to meet the demand for real-time analytics at reduced cost. They leverage faster primary memory formats such as flash and Random Access Memory (RAM) to deliver far superior performance. Primary memory can be read up to 10,000 times faster than secondary memory and generate near-zero latency. While in-memory technology is far from new, it has been made more accessible to organisations by the decline in memory prices, the widespread use of multi-core processors and 64-bit operating systems, and software innovations in database management systems.
The SAP HANA platform includes a database system that processes both OLAP and OLTP transactions completely in-memory. According to performance tests performed by SAP on a 100 TB data set compressed to 3.78 TB in a 16-node cluster of IBM X5 servers with 8 TB of combined RAM, response times vary from a fraction of a second for simple queries to almost 4 seconds for complex queries that span the entire data range. Such performance underlies the appeal and success of SAP HANA. Since its launch in 2010, SAP HANA has been deployed by 2200 organisations across 25 industries to become SAP’s fastest growing product release.
SAP HANA has emerged against a backdrop of rising concern over information security resulting from a series of successful, targeted and well-publicized data breaches. This anxiety has made information security a focal point for business leaders across all industry sectors. Databases are the vessels of business information and therefore, the most important component of the technology stack. Database security represents the last line of defense for enterprise data. It should comprise of a range of interdependent controls across the dual domains of prevention and detection.
The most advanced persistent databases are the product of almost thirty years of product evolution. As a result, today’s persistent databases include the complete suite of controls across both domains to present organisations with a high degree of protection against internal and external threats. In-memory databases are in comparison a nascent technology. Therefore, most do not as yet deliver the range of security countermeasures provided by conventional databases. This includes:
Label based access control;
Data redaction capabilities to protect the display of sensitive data at the application level;
Utilities to apply patches without shutting down databases; and
Policy management tools to detect database vulnerabilities or misconfigurations against generally-accepted security standards.
The performance edge enjoyed by in-memory database solutions should be weighed against the security disadvantages vis-a-vis persistent database systems. However, it should be noted that the disadvantages may be short-lived. Security in in-memory databases has advanced significantly over a relatively short period of time. The most recent release of SAP HANA (SPS 06), for example, introduced a number of security enhancements to SPS 05 released a mere seven months earlier. This includes support for a wider number of authentication schemes, the binding of internal IP addresses and ports to the localhost interface, a secure store for credentials required for outbound connections and more granular access control for database users.
The most crucial challenge to database security presented by the introduction of in-memory databases is not the absence of specific security features but architectural concerns. Server separation is a fundamental principle of information security enshrined in most control frameworks including, most notably, the Payment Card Industry Data Security Standard (PCI DSS). According to this principle, servers must be single purpose and therefore must not perform competing functions such as application and database services. Such functions should be performed by separate physical or virtual machines located in independent network zones due to differing security classifications that require unique host-level configuration settings for each component. This architecture also supports layered defense strategies designed to forestall intrusion attempts by increasing the number of obstacles between attackers and their targets. Implementation scenarios that include the use of in-memory databases such as SAP HANA as the technical infrastructure for native applications challenge the principle of server separation. In contrast to the conventional 3-tier architecture, this scenario involves leveraging application and Web servers built directly into SAP HANA XS (Extended Application Services). Unfortunately, there is no simple solution to the issue of server separation since the optimum levels of performance delivered by in-memory databases rely upon the sharing of hardware resources between application and database components.
Aside from such architectural concerns, the storage of large quantities of data in volatile memory may amplify the impact of RAM-based attacks. Although widely regarded as one of the most dangerous security threats, attacks such as RAM-scrapping are relatively rare but are becoming more prevalent since attackers are increasingly targeting volatile memory to circumvent encrypted data in persistent memory. Another reason that RAM-based attacks are growing in popularity is that they leave virtually no footprint and are therefore extremely difficult to detect. This relative anonymity makes RAM-based attacks the preferred weapon of advanced attackers motivated by commercial or international espionage.
This paper presents a security framework for SAP HANA SPS 06 across the areas of network and communication security, authentication and authorization, data encryption and auditing and logging. It also provides security-related recommendations for the SAP HANA appliance and SAP HANA One. Taken together, the recommendations in this paper should support the confidentiality, integrity and availability of data in the SAP HANA in-memory database.
The results of the 2013 Top Technology Initiatives Survey revealed that securing IT environments against cyber attack and managing IT risks and compliance are rated as two of the three greatest challenges in technology by accounting professionals in North America. The survey was performed jointly by the AICPA and CPA, the largest accounting organisations in the United States and Canada. The survey sampled approximately 2000 members from the public accounting, business and industry, consulting, government and not-for-profit sectors. Members of both the AICPA and CPA placed securing the IT environment as the second highest priority for organisations in the area of information technology. Managing IT risks and compliance was ranked third by AICPA members and fourth by CPA members.
U.S respondents expressed average confidence levels of just 51 percent in organisational initiatives designed to manage IT security and 47 percent in initiatives addressed at managing IT and compliance risks. Confidence levels have fallen drastically in 2013 due to the wave of recent well-publicized data breaches. In 2012, U.S confidence levels for securing IT environments and managing IT risk and compliance were 62 and 65 percent. However, according to the Chair of the AICPA’s Information Management and Technology Assurance (IMTA) Division, The decline in confidence levels may mean professionals are making more knowledgeable assessments of the ability of organizations to achieve technology goals. This more realistic assessment indicates that the goals may be more challenging than originally thought, and that organizations must have the focus, commitment and drive to achieve them.
Layer Seven Security assist organisations worldwide to identify and remove vulnerabilities that expose SAP systems to cyber attack and impact the ability to comply with the requirements of IT control frameworks. To learn how we can assist your organisation manage SAP risks and stay compliant, contact Layer Seven Security.
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.
