Earlier this month, Layer Seven Security released the new whitepaper Securing the Journey to SAP S/4HANA: A Security Framework for S/4HANA Migrations. The whitepaper provides a comprehensive guide to S/4HANA security to support the transition from SAP ERP to S/4HANA.
Mainstream maintenance for ERP will end in December 2027. Therefore, organizations must migrate to S/4HANA by the beginning of 2028. To date, only one third of organizations have migrated to S/4HANA. Therefore, the majority of SAP customers will be migrating over the next five years.
Security is one of the largest roadblocks to successful migrations. This is due to significant differences between ERP and S/4HANA that require the restructuring of access and technical controls. It is also due to concerns related to cloud security since almost 70% of organizations are electing to migrate to cloud-based S/4HANA installations. Other security concerns arise from the migration of custom SAP programs from ERP to S/4HANA. These programs often contain hidden and unresolved security vulnerabilities since they were never subject to in depth code vulnerability analysis.
The whitepaper includes detailed recommendations across twelve domains to deal with these and other security concerns and facilitate the smooth transition to S/4HANA. The recommendations are aligned to best practices in the SAP S/4HANA Security Guide. The whitepaper also includes guidance for automating pre and post go-live security checks for S/4HANA migrations using SAP Solution Manager and the Cybersecurity Extension for SAP.
Security monitoring using SAP Solution Manager is driven by a series of background jobs that automate data collection and analysis for system vulnerabilities, security notes, and event logs. Vulnerability data is extracted daily, notes information is collected weekly, and event data can be collected as frequently as every minute. Any interruption to the background jobs for these areas could impact the coverage of security monitoring.
SAP Solution Manager supports centralized monitoring for jobs in SAP systems with automated detection and alerting for job errors. Monitoring for scheduled jobs is setup using a guided procedure that includes steps for selecting relevant jobs, activating alerts, and enabling email/ SMS notifications for alerts.
You can access Job Monitoring from Application Operations in SAP Solution Manager Configuration.
Steps 1-3 of the guided procedure prepare the infrastructure for job monitoring including setup of the required users. Steps 4-6 involve the selection of scheduled jobs for monitoring and configuring alerts and notifications. In the following example, we will create a monitoring scenario for the standard job SM:SYSTEM RECOMMENDATIONS. This job connects to SAP Support on a weekly schedule to calculate required security, correction, performance, legal, and other notes for systems. It also connects to managed systems to determine the implementation status of calculated notes.
In the first step of the scenario configuration, we define a name and description for the scenario.
During the second step, we select the systems for the scenario. Since SM:SYSTEM RECOMMENDATIONS runs from Solution Manager, we will select a SolMan installation.
Next, we maintain the scope for the scenario in terms of the specific job.
Once the job is selected, we can adjust the metric settings including thresholds for job errors, processing times, terminations and warnings.
Finally, we activate the alerting and select the required language, severity and description for the alert.
Recipients for email notifications triggered for alerts can be maintained in the Incident and Notifications tab.
Once the scenario is activated in the final step, we will be immediately alerted and notified by Solution Manager for any issue that interrupts the successful execution of the system recommendations job. The steps can be repeated for other scheduled jobs in SAP Solution Manager and managed systems.
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
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.
SAP HANA is now deployed by over 7,500 organizations worldwide. While this represents only a fraction of the 300,000 companies that use SAP software globally, adoption is growing rapidly, doubling in 2015 alone. As expected, the introduction of SAP Business Suite 4 SAP HANA (S/4HANA) has accelerated this growth by widening the use-case for SAP HANA from analytics to transactional processing for core business processes.
While the performance and administrative benefits of SAP HANA are clear-cut, the benefits for security are more questionable. Unlike conventional persistent databases, HANA does not provide any native capability for label-based access control, data discovery and classification, data redaction and masking, or database firewalls. HANA also presents an architectural challenge for security engineers since some implementation scenarios integrate application and database layers that are traditionally hosted in separate physical or virtual servers.
SAP has addressed some of these concerns in later releases of HANA. SPS 12 includes features to isolate databases in multi-tenant environments to prevent cross-database attacks. It also includes more advanced logging capabilities to support multiple log formats and fine-grained audit policies. This is discussed in the newly updated whitepaper Security in SAP HANA, available in the resources section. The whitepaper provides a framework for securing HANA systems including network security, authentication and authorization, encryption for data in transit and at rest, and OS-level security for SUSE Linux Enterprise (SLES) and Red Hat Enterprise Linux (RHEL).
HANA vulnerabilities such as potential misconfigurations in database parameters or users with special privileges should be monitored using SAP Solution Manager (SolMan). In common with other SAP systems, HANA is connected to and monitored by SolMan. Security-relevant data is extracted by agents from HANA and transmitted to SolMan for analysis. SolMan analyzes the data using rulesets to identify potential vulnerabilities that could be exploited by attackers. The results are accessible through BW or BI including Lumira and Crystal Reports.
Rulesets benchmarked against best practices and SAP recommendations can be licensed from Layer Seven Security and imported directly into your Solution Manager platforms. To learn more, contact us.
In November, SAP released an unusually high number of Security Notes to patch various forms of injection vulnerabilities in it’s software. The trend continued in December with the release of several patches for code injection flaws in the Computer Center Management System (BC-CCM), Project System (PS-IS), Transport Organizer (BC-CTS-ORG) and work processes in Application Servers responsible for executing ABAP programs (BC-CST). Given this alarming trend, this article is focused on discussing the challenges of developing secure ABAP programs for SAP systems, free of common vulnerabilities including not only injection flaws, but cross-site scripting errors, buffer overflows, directory traversals and backdoors and rootkits.
There are three attack surfaces in SAP systems. The first is through improperly defined and controlled application-level access. This attack surface is the most commonly known and understood by SAP customers. Today, most SAP clients deploy any one of a variety of access management tools to control access to sensitive functions and maintain a strict segregation of duties in their ERP systems. This manages the risk of unauthorized access through inadequate authorization structures that grant excessive or conflicting privileges to users and administrators.
The second attack surface lies at the platform level. This generally refers to components of the NetWeaver Application Server, also referred to as the Basis area of SAP systems. The NetWeaver AS is the technical foundation of the entire SAP software stack. It provides the runtime environment for SAP applications and includes work processes for ABAP and Java programs, gateways and modules for managing RFC, Web-based and other forms of communication protocols, tools to manage user roles, profiles and authorizations, and utilities that control certain database and operating system functions. The secure configuration and management of the NetWeaver AS is a vital component of a comprehensive SAP security strategy. However, the results of our security assessments repeatedly reveal common vulnerabilities in basis settings in most SAP environments. This provides a lush attack surface to internal and external attackers looking for an avenue to manipulate or appropriate business data or deliberately disrupt the availability of SAP systems.
The third and final attack surface in SAP provides an even greater array of opportunities for attackers. This surface exists at the program level. ERP systems such as SAP are designed to perform thousands of distinct functions ranging from, for example, adding a vendor to a list of approved suppliers, performing a transport to implement a change in a specific system, or encrypting/ decrypting traffic between servers or clients. These functions are performed by programs stored in the database table known as REPOSRC that are called when requested by work processes in the NetWeaver AS.
SAP programs are developed using two distinct programming languages: Advanced Business Application Programming (ABAP) and Java. Both are vulnerable to coding errors that could expose SAP programs to exploits such as code, OS and SQL injection, cross-site scripting, cross-site request forgery, buffer overflow, directory traversal and denial of service. SAP programs are also susceptible to missing or broken authority-checks that could lead to unauthorized execution of programs. Finally, SAP programs can contain backdoors through hardcoded credentials that bypass regular authentication and authorization controls, as well as malware known as rootkits that provide attackers with remote, privileged access to system functions and resources.
SAP performs a rigorous code review for all standard or delivered programs prior to release. However, some of the vulnerabilities present in the code base are not detected and patched until after release. Security Notes are therefore an important mechanism used by SAP to patch vulnerabilities arising from programming errors.
Custom programs are rarely subject to the same level of scrutiny applied by SAP to standard programs. Programs developed by in-house or off-shore developers to meet the needs of customers not met by standard SAP functionality are often laden with vulnerabilities that, when exploited, undermine the integrity of entire SAP landscapes. Such landscapes are only as strong as their weakest point. A robust application layer fortified with GRC tools has led attackers to shift their focus to the platform and code level. Given the relative openness of most SAP systems at the technical level, the strategy is proving to be profitable.
However, understandably SAP is less vocal on development procedures for custom programs since this is generally the responsibility of each SAP customer. The challenge should not be underestimated. Although manual code reviews to detect common vulnerabilities are theoretically possible, the skill-set to effectively review custom code is not only rare but expensive. Furthermore, it often leads to an increase in development time. Customers should consider investing in code scanning tools that are tuned to detect suspicious statements in ABAP code and integrate directly into the SAP Transport Management System (TMS). Such tools should also be capable of auto-correcting ABAP statements to minimize resource requirements and the impact on existing development times. Presently, the only tool capable of detecting and auto-correcting vulnerabilities in custom ABAP programs, with direct integration with SAP TMS, is Virtual Forge CodeProfiler. To arrange a security scan of custom programs in your SAP environment using CodeProfiler, please contact a representative at Layer Seven Security.
There are several myths in ERP security. One of the most common is that security is largely a matter of controlling access and segregation of duties. Another is that business applications are accessible only within internal networks. Yet another is that such applications are not a target for attack. All three are based on a simplistic and misguided take on today’s ERP systems.
The reality is that contemporary ERP systems have a highly complex structure. Complexity is the enemy of security. Vulnerabilities can be found not only in the business or application layer (which is the traditional area of focus for ERP security practitioners) but the technical layer that includes database, operating system and network components. A Fort Knox approach for the application level will provide a false sense of security if architectural, configuration and programming flaws are not addressed at the technical level.
This is compounded by the fact that most ERP instances have more than one attack surface. Almost all have direct or indirect connections to the Internet. The former includes connections to external offices, suppliers, vendors or other partners and to SAP services. The latter can include connections to user workstations with Web access. ERP resources are increasingly designed to be accessible by mobile users using Web-based protocols, ports and services. The isolated mainframes of yesteryear are a distant memory in our era of global communications.
Vectors for attack surfaces in ERP systems are generally well-known. What’s more, most can be performed with low-spec laptops and minimal technical knowledge. The idea that very few people have any motive to attack such information-rich systems is one of the most disturbing and perplexing myths in ERP security. I’m reminded of a comment that was made to me by a prominent partner in a well-known consulting firm. The partner was engaged as a security advisor by a large meat processing company during an otherwise successful SAP implementation. In his view, the client had a relatively low risk profile which justified a ‘vanilla’ security framework for its SAP systems. As a result, the company was urged to stick with SAP defaults, wherever possible.
The leads to the fourth and most damaging myth in ERP security: the notion that systems are securely configured by default and, where they are not, it’s the responsibility of the vendor to secure the system. ERP systems are designed to be flexible. They have to be capable of meeting the diverse needs of every imaginable business in all industries and sectors. As a result, there is no standard configuration that can meet the requirements of every business. Security has to be enabled. Default security settings are often highly dangerous and can leave organizations open to internal and external attacks. For this reason, SAP has issued numerous white papers, security guides and other publications to support the secure configuration of its software during and after implementation. This should be required reading for all security professionals specializing in SAP.
SAP does not take responsibility for security issues arising from architectural flaws, misconfigurations and inadequate patching. Customers are expected to design, manage and maintain their systems in a secure manner. This can prove to be a challenge in companies where there is no clear ownership over SAP resources or in cases where systems are owned by business departments that lack the technical skills to effectively manage ERP security. In these scenarios, business owners should take steps to share ownership with IT functions, especially technical resources within their organization that are more accustomed to dealing with infrastructure or platform-level security. There is often a strong relationship between the strength of SAP security in organizations and the degree of partnership between business and IT.
On January 16, SAP issued a revamped version of the whitepaper Secure Configuration of SAP Netweaver Application Server using ABAP, which is rapidly becoming the de-facto standard for securing the technical components of SAP. According to SAP, the guidance provided in the whitepaper is intended to help customers protect ABAP systems against unauthorized access within the corporate network. In fact, many of the recommendations can also be used to protect SAP systems against remote attacks originating outside such a network. These attacks are targeted at the technical components of SAP Netweaver that are responsible for managing user authentication, authorization, encryption, passwords and system interfaces, as well as underlying databases and operating systems. Breaches in these components can enable attackers to take complete control of an SAP environment.
The following is a quick guide to help you comply with SAP’s recommendations.
1. Disable unnecessary network ports and services. In most cases, this means blocking all connections between end user networks and ABAP systems other than those required by the Dispatcher (port 32NN), Gateway (33NN), Message Server (36NN) and HTTPS (443NN). NN is a placeholder for your SAP instance number. Administrative access should only be allowed through secure protocols such as SSH and restricted to dedicated subnets or workstations through properly configured firewall rules.
2. Install the latest version of SAP GUI. This should be 7.10 or 7.20 with activated security rules configured with the ‘Customized’ setting and the ‘Ask’ default action.
3. Implement strong password policies, restrict access to password hashes in tables and activate the latest hashing algorithms. SAP does not specify the exact settings for password policy parameters but you should use frameworks such as the PCI DSS as a proxy. Refer to section 8.5 of the standard. Default passwords should be changed for standard users and the password hashing mechanism should be upgraded to the latest version available for your system. Wherever possible, downward-compatible hashes should be removed from the database.
4. Enable SNC and SSL. SAP client and server communication traffic is not cryptographically authenticated or encrypted. Therefore, data transmitted within SAP networks can be intercepted and modified through Man-In-The-Middle attacks. Secure Network Communication (SNC) should be used for mutual authentication and strong encryption. This can be performed natively if both servers and clients run on Windows. You will need to use a third party product to secure connections between heterogeneous environments such as AIX to Windows.
SNC will secure network communication using the SAP DIAG and RFC protocols. For Web-based communication, you should switch to HTTPS/ SSL and restrict access to the relevant cryptographic keys.
5. Restrict ICF services. Many of the services enabled by default in the Internet Communication Framework (ICF) are open to abuse and could enable unauthorized and malicious access to SAP systems and resources. At a very minimum, you should deactivate the dozen or so services mentioned by SAP in the white paper. This can be performed through transaction SICF.
6. Secure Remote Function Calls (RFC). Wherever possible, remove trust relationships between systems with differing security classifications and hardcoded user credentials in RFC destinations. The belief that RFC connections using SAP_ALL privileges is fine as long as the user type is not set to dialog is a myth. This represents a serious risk to the integrity of information in SAP systems.
7. Secure the SAP Gateway. The Gateway is used to manage RFC communications which support SAP interfaces such as BAPI, ALE and IDoc. Access Control Lists (ACL) should be created to prevent the registration of rogue or malicious RFC servers which can lead to the interruption of SAP services and compromise data during transit. You should also enable Gateway logging and disable remote access.
8. Secure the SAP Message Server. The Message Server is primarily a load balancer for SAP network communications. Similar to the Gateway, it has no default ACL which means it is open to the same type of attacks. You should filter access to the Message Server port using a firewall and create an ACL for all required interfaces.
9. Regularly patch SAP systems. Implement missing SAP Security Notes and patch systems at least once a month. Security Notes can be downloaded from the SAP Service Market Place.
10. Regularly monitor the SAP security configuration. Standard SAP services such as EarlyWatch (EWA) and the Computing Center Management System (CCMS) can be used to monitor some security-relevant configurations. However, they do not provide the same coverage as professional-grade security tools such as those used by Layer Seven Security. You can learn more about SAP security monitoring through vulnerability assessment here. To discover why vulnerability assessments should be an integral component of your SAP security framework, click here.
After recently losing Beneficial Mutual as an audit client, Deloitte suffered another major setback last week. While a U.S District Court Judge dismissed racketeering and other claims against the firm made by Marin County as a result of what the Californian authority considered a botched implementation of SAP for Public Sector, the court declared that the county had a plausible claim of bribery against Deloitte.
In the $30M complaint against Deloitte attached below, Marin County alleged that Deloitte had misrepresented its skill and experience to obtain the contract for the implementation, staffed the project with inexperienced consultants and deliberately concealed issues and risks arising during the implementation from the county. This included a practice of under-testing and “truncated, simplistic and incomplete tests that were intended to produce positive results to create the false impression, prior to the go-lives, that the SAP system was in fact ready for production”. It also included alleged bribing of the county official overseeing the project. After the implementation failed to support basic financial, payroll and HR functions, Deloitte offered costly post-production support to the county to address the problems plaguing the system.
The county eventually scrapped the implementation, despite paying $11M in consulting fees, and alleged that Deloitte’s conduct was consistent with the approach used by the firm during similar SAP implementations for public organisations in Los Angeles, San Antonio, Colorado and Miami-Dade.
During initial hearings, SAP declared that it had expressed concerns with Deloitte’s blueprint designs which put the county “at risk of an improperly designed system which could lead to substantial rework … or a re-implementation after go live”. However, this did not appear to have led SAP to question earlier accolades it had made regarding Deloitte’s ‘depth and breadth of skills and services’ or Service Partner Awards bestowed by SAP to Deloitte.
Commenting on the Court’s decision, County Counsel Jack Govi stated that “the county is confident that Deloitte will be held accountable for its misconduct, which has cost the county of Marin taxpayers millions of dollars”.
The case highlights the importance of selecting the right system integrators for SAP implementations and the problems that arise from misaligned objectives between business partners during transformations. Customers, vendors and system integrators should remain focused on shared objectives rather than their own specific goals which often conflict with those of the project.
Does anyone remember the world before GRC? I know it seems like decades ago but the fact is solutions such as SAP GRC are a relatively new phenomenon. Until recently, most of us were working with SU01 and SUIM. While such tools have undoubtedly made life easier for administrators and auditors alike, there’s a hidden danger associated with their use that I’ve observed over and over again when clients rely too heavily on them to secure their environments.
Before we get to that, here’s a brief survey of GRC platforms for readers looking to adopt or switch solutions:
Today’s GRC landscape is far more complex than a simple toss-up between Approva and SAP GRC (formerly Virsa). Although these platforms remain the most popular among large companies with thousands or even tens of thousands of users, the market includes a number of new upstarts that are worth considering if you’re looking to save some serious dollars without sacrificing functionality. This includes Alert Enterprise, Security Weaver, Xpandion and CSI Tools (the links are provided below). All of these vendors offer a suite of scalable applications designed to provision user access, monitor segregation of duties in real time and automate user access reviews.
The pros and cons of the different platforms depend upon what you’re looking for. However, one very important piece of advice is to define your requirements very clearly and stick to them throughout the selection process. This way, you won’t be swayed by clever marketing that offers you bells and whistles you’ll never use. I’ve lost count of the number of times I’ve seen security and audit groups buy vast GRC suites to monitor everything in sight when in fact all they really needed was a basic tool to check their authorizations once a year or, at best, every quarter. Truth be told, if this is what you’re looking for, you should consider sticking with SAP SUIM. It may be so slow and cumbersome, but it gets the job done for next to nothing.
There’s also another important benefit to persevering with standard SAP functions that’s often overlooked: working directly with SAP builds a familiarity and depth of understanding of your environment that’s hard to form when you’re dealing with SAP through GRC tools. It also requires more intellectual effort and therefore forces users to develop their investigative skills rather than rely upon canned queries and reports.
In the grand scheme of things, these are minor drawbacks. We could just as easily argue that the enormous time and effort freed up by GRC tools allows resources to be devoted to more value-added areas. True, but there is a far bigger concern that can’t be so easily dismissed.
In the minds of those that administer GRC tools, the very notion of what is and isn’t SAP security is closely associated with the scope of the software they use. In other words, these tools shape our conception of security. Time and again, we are lulled into a false sense of security because of the rosy picture painted by GRC software. Often, this turns out be a mirage when we are forced to widen our paradigm to include the security of technical components of SAP that are beyond the scope of these programs. SAP security is about more than authorizations. It’s even deeper than Basis. In fact, it reaches down into the very kernel of SAP. It includes areas that are new to the SAP landscape and others that are often simply overlooked or underestimated. Many of these areas are discussed in our whitepaperPerfect Storm: The Brave New World of SAP Security. The moral of the story is that the results of GRC tools should be taken with a pinch of salt. Locking down critical authorizations, users and configurables doesn’t mean that your SAP systems are secure or even compliant with SOX, PCI or other standards. It’s only a small part of a broader security strategy that should include managing the technical components of SAP Netweaver that can be highly vulnerable to internal and external attack.
