The recent attack experienced by Sony Pictures Entertainment may well prove to be the most significant breach of the year. By all measures, the impact has been devastating for the organization, leading to the loss of almost 40GB of data to attackers. This includes not only proprietary intellectual property such as digital media, blueprints and schedules, but also social security numbers, bank accounts and payroll information. The loss of some of this information has led directly to several lawsuits against the company. It has also severely damaged and undermined the Sony brand. The attack has illustrated the vulnerability and unpreparedness of organizations in the face of sophisticated, targeted cyber threats.
The most surprising fact about the breach is that it is the second time in three years that Sony has been the victim of such a destructive attack. Therefore, the company has drawn has a great deal of criticism for alleged security practices that arguably should have been stamped out following the previous breach in 2011. In terms of the monetary impact of the recent attack, many experts estimate that impairment charges could range between $70M-$80M for Sony. Some place the cost closer to $100M.
The attackers compromised digital certificates used to authenticate Sony’s servers and released information related to over 1600 Linux/ Unix and 800 Windows servers at the company, as well as IP and MAC addresses and computer names of over 10,000 PCs within its network. This includes many SAP servers. An analysis of the leaked data performed by Joris van de Vis available on the SAP Community Network revealed that the data includes SAP server hostnames, IP addresses, SAP System IDs (SIDs), and version information for operating systems and databases. It also includes username and password combinations stored in unencrypted files. However, the most damaging revelation is that the leaked data includes the results of security assessments performed for SAP systems at Sony. Such reports could provide attackers with insights into vulnerabilities impacting these systems.
This particular revelation leads to the first recommendation for how to prevent a Sony-scale breach of your SAP systems. It is suspected that the attackers targeted security groups and users at Sony in order to access information that could be used to aid their attack. Therefore, it is imperative to secure such information within your network. The use of desktop-based tools to audit SAP systems and the circulation of the output from such tools in common file formats such as Excel and PDF can pose a serious security risk. You can remove this risk by ensuring that security-related data never leaves your SAP systems. This can be achieved by avoiding the use of third-party tools. A more secure option is to leverage vulnerability management components in Solution Manager such as Configuration Validation. This will ensure that access to security-related data on managed systems is secured using the SAP authorization concept directly within SAP systems.
The second recommendation is to reexamine your current cost-benefit calculations or risk-reward ratios when determining resource requirements and spend levels for security countermeasures. Sony’s experience has illustrated that traditional assumptions no longer apply. The impact of a breach is not just technical or even financial but strategic and can cause far-reaching harm to your organization. Security is no longer a question of ‘just enough’. It’s all or nothing.
Our final suggestion is not to focus exclusively on your network security. The most effective strategies are designed from inside-out rather than outside-in. According to a recent survey published by the Ponemon Institute, most organizations allocate 40% of their security budget to network security. In contrast, database security receives an average of just 19%. These ratios should change to reflect a greater emphasis at the application, host and database level for defense in depth.
In the view of McAfee Labs, we can expect to see more headline-capturing attacks next year. The research group’s 2015 Threat Predictions report forecasts an increase in cyber attacks as state-affiliated, criminal and terrorist actors grow in number and employ ever more sophisticated and stealthier techniques against their targets. You can read the report at McAfee for Business.
Some of the most critical recommendations issued by SAP in the recently released paper Securing Remote Function Calls include the use of configuration validation in Solution Manager to monitor RFC destination settings. This includes checks for destinations with stored credentials, trusted connections, and authorizations granted to RFC users in target systems. It also includes the review of profile parameters for RFC and secure network communication, as well as access control lists for RFC gateways. The SAP paper lends support for other security functions in Solution Manager such as management dashboards and alerts by pointing out that “an overview of the current security status can be provided in a security dashboard and alerts on noncompliance can be collected in the alert in-box” (p33).
The paper draws together leading practices and SAP recommendations into a single reference document for protecting one of the most vulnerable areas in SAP landscapes that is often targeted by remote attackers. RFC is a proprietary SAP technology that drives cross-system integration. Misconfigurations in RFC destinations and gateways that manage RFC communications can lead to the complete compromise of not just individual SAP systems but entire landscapes. Common mistakes include using destinations with stored logon credentials or trusted connections between systems with differing security classifications, using service or communication user types for RFC destinations rather than system users, granting excessive authorizations to RFC users, failing to limit access to remote-enabled function modules, and non-existent access control lists to control the registration and starting of external RFC servers.
The paper emphasizes the importance of established and well-known counter measures for securing RFCs based on the authorization concept. This includes not granting full access to objects such as R_RFC_ADM, S_RFC_TT, S_ADMI_FCD used to administer RFC destinations and other objects such as S_RFC , S_ICF and S_RFCACL that control access to remote-enabled function modules and logons in trusting systems. The paper also discusses enhancements delivered by SAP in the most recent release of NetWeaver AS ABAP, including unified connectivity (UCON). UCON blocks access to remote-enabled function modules using whitelists configured in so-called communication assemblies. According to SAP, “Typically, less than 5% of all available RFC function modules are used in customer software systems for remote RFC communication” (p14). It also outlines methods for performing short-term and long-term traces to identify authorizations checks performed during the execution of RFC-enabled function modules called remotely. This should be used to reign in access privileges for RFC users. Finally, the paper outlines how to control dangerous RFC callbacks and activate switchable authorization checks that are only enabled in specific RFC scenarios.
Contact an SAP Security Architect at Layer Seven Security for professional services to implement these and related SAP recommendations. Our SAP Cybersecurity Solution includes a gap assessment for all of the recommendations on RFC security issued by SAP in the paper.
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.
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
You’ve read the data sheet. You’ve listened to the sales spin. You’ve even seen the demo. But before you fire off the PO, ask yourself one question: Is there an alternative?
In recent years, there have emerged a wide number of third party security tools for SAP systems. Such tools perform vulnerability checks for SAP systems and enable customers to detect and remove security weaknesses primarily within the NetWeaver application server layer. Most, if not all, are capable of reviewing areas such as default ICF services, security-relevant profile parameters, password policies, RFC trust relationships and destinations with stored logon credentials.
The need to secure and continuously monitor such areas for changes that expose SAP systems to cyber threats is clear and well-documented. However, the real question is do organisations really need such solutions? In 2012, the answer was a resounding yes. In 2013, the argument for such solutions began to waiver and was, at best, an unsure yes with many caveats. By 2014, the case for licensing third party tools has virtually disappeared. There are convincing reasons to believe that such tools no longer offer the most effective and cost-efficient solution to the security needs of SAP customers.
The trigger for this change has been the rapid evolution of standard SAP components capable of detecting misconfigurations that lead to potential security risks. The most prominent of these components is Configuration Validation, packaged in SAP Solution Manager 7.0 and above and delivered to SAP customers with standard license agreements. Configuration Validation continuously monitors critical security settings within SAP systems and automatically generates alerts for changes that may expose systems to cyber attack. Since third party scanners are typically priced based on number of target IPs, Configuration Validation can directly save customers hundreds of thousands of dollars per year in large landscapes. The standard Solution Manager setup process will meet most of the prerequisites for using the component. For customers that choose to engage professional services to enable and configure security monitoring using Solution Manager, the cost of such one-off services is far less than the annual licenses and maintenance fees for third party tools.
The second reason for the decline in the appeal of non-SAP delivered security solutions is a lack of support for custom security checks. Most checks are hard-coded, meaning customers are unable to modify validation rules to match their specific security policies. In reality, it is impossible to apply a vanilla security standard to all SAP systems. Configuration standards can differ by the environment, the applications supported by the target systems, whether the systems are internal or external facing and a variety of other factors. Therefore, it is critical to leverage a security tool capable of supporting multiple security policies. This requirement is currently only fully met by Configuration Validation.
The third reason is security alerting. While some third party solutions support automated scheduled checks, none can match native capabilities in Solution Manager capable of the near-instant alerting through channels such as email and SMS.
The fourth and fifth reasons are shortcomings in reporting and product support when compared to the powerful analytical capabilities available through SAP Business Warehouse integrated within Solution Manager and the reach of SAP Active Global Support.
More information is available in the Solutions section including a short introductory video and a detailed Solution Brief that summarizes the benefits of Configuration Validation and professional services delivered by Layer Seven to enable the solution in your landscape. To schedule a demo, contact us at info@layersevensecurity.com.
The disclosure of up to 200,000 classified documents belonging to the NSA by Edward Snowden in 2013, together with the release of over 750,000 U.S Army cables, reports and other sensitive information by Bradley Manning in 2010, has drawn attention to the need to control and monitor access to confidential data in corporate systems. For this reason, the general availability of the latest version of the SAP NetWeaver Application Server in May could not have been more well-timed.
NetWeaver AS ABAP 7.40 includes a new component known as Read Access Logging (RAL) to register and review user access to sensitive data. The momentum for RAL is driven not only by well-publicised information leakages but data protection requirements impacting industries such as e-commerce, healthcare and financial services. RAL is also in demand with organisations that have a relatively open authorization concept and therefore are more susceptible to data misuse. Aside from enabling organisations to verify user access to sensitive data and respond to potential abuses before they lead to the mass exfiltration of information, RAL acts as a deterrent for such abuse if users are aware that their actions are logged and monitored.
RAL supports calls though RFC, Dynpro, Web Dynpro and Web service channels. It is not enabled by default and therefore must be activated by selecting the Enable Read Access Logging in Client parameter in the Administration tab of the RAL Manager accessed via transaction SRALMANAGER. However, prior to enabling RAL, customers should follow several predefined configuration steps using the SAP_BC_RAL_CONFIGURATOR and SAP_BC_RAL_ADMIN_BIZ roles and associated authorization objects delivered by SAP. The first involves defining logging purposes to create logical groupings of log events based on the specific requirements of the organisation. Â The second step is creating log domains to group related fields. For example, a domain for customer-specific information could be created to band together fields such as address, date-of-birth, SSN, etc.
Steps one and two establish the overarching structure for log information. The actual fields to be logged are identified during step three through recordings of sessions in supported user interfaces. Once identified, fields are assigned to log conditions and domains in step four. SAP will initiate RAL when the Enable Read Access Logging in Client parameter is selected which represents the final step of the configuration process.
Logs can be accessed through transaction SRALMONITOR or the Monitor tab of SRALMANAGER. Log entries include attributes such as time of the entry, user name, channel, software component, read status, client IP address and details of the relevant application server. Extended views provide more detail of log events than default views. The log monitor supports complex searches of events and filtering by multiple parameters.
RAL configuration settings can be exported to other systems through an integrated transport manager accessed through transaction SRAL_TRANS. Furthermore, logs can be archived using standard Archive Administrative functions in SAP NetWeaver via transaction SARA.
Although RAL is currently only available in NetWeaver AS ABAP 7.40, a release is planned for version 7.31 in the near future. Layer Seven Security can enable your organisation to leverage the full benefits of Read Access Logging and safeguard confidential information in SAP systems. To learn more, contact our SAP Security Architects at info@layersevensecurity.com or call 1-888-995-0993.
The ABAP Test Cockpit (ATC) is SAP’s new framework for Quality Assurance. It performs static and unit tests for custom ABAP programs and introduces Quality-Gates (Q-Gates) for transport requests.
ATC was unveiled at last year’s SAP TechEd. The entire session including a live demo can be viewed below. Following a successful pilot, it was released for NetWeaver 7.0 SP12 and NetWeaver AS ABAP 7.03 SP05 in September and October 2012, respectively. General guidelines for configuring and running ATC are available at the SAP Community Network for both developers and quality managers.
ATC integrates directly with the ABAP Workbench and is accessible through SE80, SE24, SE38, SE11 and other Workbench tools. The existing iteration of the tool focuses almost exclusively on performance checks for exceptions such as runtime errors. However, SAP has revealed plans to deliver a new Security Scan Solution (SLIN_SEC) as an add-on for the Extended Program Check (SLIN) in ATC. This will enable security vulnerability checks for custom code. The introduction of the Security Scan Solution should improve the general security of ABAP programs and lower the risk of code-level vulnerabilities in ABAP systems including insufficient authority checks and code injections arising from uncontrolled input. You can learn more about the solution at session SIS261 scheduled on October 24 during this year’s SAP TechEd.
The alternative to the SAP Security Scan Solution is Virtual Forge CodeProfiler. CodeProfiler also integrates with ATC and performs a patented static code analysis for any type of ABAP program. CodeProfiler provides comprehensive performance and quality testing and is SAP-certified for integration with SAP NetWeaver.
The Brand-New ABAP Test Cockpit: A New Level of ABAP Quality Assurance
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.
One of the most memorable events at last year’s BruCON in Belgium was Martin Gallo’s expose of the SAP DIAG protocol. The session can be viewed in its entirety below. DIAG (Dynamic Information and Action Gateway) is a proprietary protocol supporting client-server communication and links the presentation (SAP GUI) and application (NetWeaver) layer in SAP systems. During the conference, Gallo presented the findings of his ground-breaking research that led directly to the identification of several denial-of-service and code injection vulnerabilities arising from security flaws in the DIAG protocol, patched by SAP in 2012.
Most researchers have focused on identifying weaknesses in the compression algorithm that scrambles payloads and other data transmitted through DIAG. The most notable research in this area was performed by Secaron in 2009. Secaron demonstrated that it is possible to intercept and decompress DIAG client-server requests including usernames and passwords. Subsequent research performed by SensePost revealed that the LZC and LZH compression methods used by SAP for DIAG are variants of the Lempel-Ziv algorithm. Furthermore, since both methods are also used in the open-source SAP MaxDB, the compression and decompression code-base is publically available. SensePost created a custom protocol analysis tool in Java using MaxDB code capable of compressing and decompressing DIAG messages. The tool could be used to intercept, read and modify client-server traffic in SAP.
Gallo’s research provides an unprecedented insight into the inner workings of the DIAG protocol. The vulnerabilities revealed by the research can be exploited through both client and server-side attacks. Deep inspection of DIAG packets can be performed through the SAP Dissection plug-in developed by Gallo for Wireshark, a popular network protocol analyzer. The research underscores the importance of strong countermeasures in SAP systems. This includes restricting access to the Dispatcher service responsible for managing user requests, SNC encryption for client-server communication, disabling SAP GUI shortcuts used by attackers to execute commands in target systems, effective patch management, and periodic vulnerability assessment and penetration testing.
According to the Privacy Rights Clearinghouse (PRC), there were 680 reported data breaches in 2012 covering all forms of commercial, governmental, educational, medical and non-profit organizations. The breaches are estimated to have compromised over 27M data records.
The most significant breach occurred at VeriSign. Although the extent of the breach has never been disclosed nor, for that matter, the cause, the breach could potentially have an enormous impact on the ability of companies to establish secure connections to intended servers and verify the identity of those servers. This is because VeriSign is one of the principal issuers of SSL certificates used for encryption and mutual authentication. VeriSign also manages 2 of the world’s 13 root DNS servers, which control the complete database of Internet domain names and corresponding IP addresses. Although the breaches occurred during 2010, they were not disclosed by VeriSign until late 2011 when the company reported the incidents in public filings to the SEC. Guidelines issued by the SEC in 2011 now require registrants to “disclose the risk of cyber incidents if these issues are among the most significant factors that make an investment in the company speculative or risky“. A similar breach at the Dutch certificate authority Diginotar led the authority to file for bankruptcy in September 2011.
The second most significant data breach in 2012 was experienced by Global Payments, a large credit and debit card payments processor. The breach appeared to have stemmed from the compromise of servers in the company’s North American network but quickly spread to other areas of the network. According to initial estimates, approximately 1.5M records including Track 2 credit card data (card expiration date and credit card number) were directly exposed by the breach. This was later revised to 7M. Details on the cause of the breach have never been released by Global Payments. However, the company has disclosed that it has invested almost $85M on measures to improve security following the incident.
In the third major breach of 2012, a targeted phishing attack against employees at the South Carolina Department of Revenue led to the theft of usernames and passwords which were used by foreign attackers to access internal systems and other resources through remote services. Shortly thereafter, the attackers extracted over 8GB of data from the company through compressed database backup files. The files contained an estimated 5M social security numbers, 3M bank accounts and almost 400,000 credit card numbers. The attack may have been prevented through two factor authentication on remote access points. Furthermore, the damage would have been far lower had all the targeted data been encrypted.
Personal and financial records were also breached at the University of Nebraska, the fourth incident in the list. Banking information, social security numbers, addresses, grades and transcripts belonging to current and former students may have been compromised during a targeted attack against some of the organization’s databases.
The fifth and sixth incidents in the list did not involve the breach of financial data. However, they did involve the loss of hundred of thousands of customer records including social security numbers, drivers license numbers, dates of birth and employer information. Both breaches were caused by improperly configured servers. In the case of the Utah Department of Health, a default password had not been changed on one of the compromised servers. In both cases, the effected data had not been encrypted.
In the seventh most important data breach of 2012, an undisclosed vulnerability is suspected to have enabled unauthorized read-level access to a subscriber database at Intel. The database stored sensitive customer-related information including passwords, social security and credit card numbers in plain-text. However, there is reason to believe that the vulnerability was relatively short-lived and did not lead to the leakage of mass amounts of data, explaining the relatively low ranking of the incident. The group suspected to be responsible for the breach is also linked to similar breaches at NASA and US Bank in the same year.
The remaining incidents in the list involved the breach of large volumes of customer-specific data including names, addresses, phone numbers and email addresses from well-known e-commerce companies. In some cases, credit card data and passwords were also effected but the difference between these incidents and those placed higher on the list lies in the fact that sensitive data was encrypted. LinkedIn, for example, used SHA-1 to encrypt passwords. The exception is Yahoo!: over 400,000 were extracted from the company’s servers in plain-text through a SQL injection attack. All three organizations, Zappos, LinkedIn and Yahoo!, are subject to lawsuits for allegedly failing to properly safeguard user data.
Defense-in-Depth for SAP Systems
The incidents reviewed in this article cover a broad spectrum of organizations and industries. Clearly, the risk of data breach is no longer the sole preserve of e-commerce companies running custom-developed programs accessible to the general public through Web application servers. In fact, the most significant breaches effected enterprise systems designed principally for internal use. This should come as no surprise. Most system landscapes are highly integrated with multiple access points. This presents a large attack surface and provides opportunities to vault from compromised systems to connected systems by exploiting trust relationships and communication pathways required to successfully integrate applications in such landscapes.
SAP landscapes are a prime example of highly integrated environments supporting a variety of services through ports and protocols that include HTTP (80), HTTPS (443) and SMTP (25), commonly used by Web application servers. Therefore, SAP systems must be protected against the identical attack vectors that led to many of the data breaches discussed above. This includes methods such as SQL injection, exploitation of default passwords and configurations, and insecure system interfaces.
Protection should be applied at four distinct levels. The first is the authorization level. SAP systems contain thousands of authorizations that control access to various functions and resources. The improper assignment of authorizations can lead to the accumulation of access rights that may provide users with privileges beyond role requirements. Such privileges may be abused to compromise the confidentiality and integrity of information in SAP systems. Therefore, the proper assignment of authorizations and the maintenance of an adequate segregation of duties is the first pillar of SAP security.
The second area is the platform level which is comprised of two components. Â The first component is the secure configuration of the SAP NetWeaver Application Server. This includes network filters that restrict access to SAP services accessible from end-user networks, configuring ACL files for SAP Gateways and Message Servers, enabling SNC and SSL to encrypt network communications, robust password policies, the use of the latest password hashing algorithms, disabling and/or changing passwords for default users, disabling dangerous Web services, securing RFC connections, and regularly patching SAP systems.
The second component of platform level security is the configuration of underlying databases and operating systems in accordance with vendor-specific recommendations or generally-accepted security benchmarks. For example, Oracle databases supporting SAP systems should be secured in accordance with the comprehensive security guides issued by Oracle for each database version. In some cases, vendor-specific recommendations may conflict with SAP requirements. Therefore, recommendations must be applied carefully and selectively, wherever appropriate.
The third area is the program level. SAP programs should be protected against unauthorized changes. Furthermore, custom programs should be developed, tested and deployed in a secure manner to ensure they are not susceptible to code-level vulnerabilities. This includes missing or broken authorization checks, backdoors and rootkits, injection flaws, cross-site scripting, buffer overflows and directory traversals. An effective software development process including requirements for code reviews by appropriately trained resources could meet part of this requirement. However, SAP programs are more effectively controlled through tools that act as a firewall to prevent the deployment of vulnerable code and tools that detect and auto-correct suspicious statements in ABAP code. Currently, the only solution capable of performing both functions is CodeProfiler, developed by Virtual Forge.
The final area of a complete SAP security framework is client-level protection. For SAP GUI, this should include disabling scripting and recording, enabling SNC encryption, and appropriate security module settings. For browser-based access, SAP applications should be located in a trusted zone with less restrictive security settings. This will enable active scripting of Java applets required for certain SAP components without lowering the general security profile of browsers for untrusted connections. Client-level security should also include malware protection, Web filtering and restrictions on the administrative privileges of end-users.
The appropriate management of risks at all four levels in contemporary SAP environments (authorization, platform, program and client) will provide the defense-in-depth required to withstand sophisticated and determined attacks against SAP systems and minimize the risk of a data breach.
