Implementing Layered Security for SAP

Since the Sarbanes-Oxley (SOX) Act passed in 2002, an organizations' emphasis on their internal controls and risk management has increased significantly. United States Federal Law set new standards for all publicly traded US company’s boards, management and for public accounting firms. As a result of SOX, top management of these companies must individually certify the accuracy of their reported financial information.

Different software has been developed in order to meet these new requirements. One of the most famous is the module designed by SAP, known as SAP GRC Access Control. The driving idea behind this Security module is to ensure segregation of duties (SoD), by defining an SoD Matrix and allowing risk analysis reports to be periodically generated. It also helps organizations detect if they have Super User accounts in Production Systems, a finding usually flagged during any traditional audit as this violation implies there is no controlled environment for the use of emergency users. The SAP GRC Access Control module ties into workflows for creating new users or modifying existing users, allowing the workflow to interact with the SoD Matrix and alerting administrators if they are granting accesses that would represent an SoD conflict as they grant that access. Finally, the design and configuration of users’ roles can be broken out into several approval steps. This means that risk analysis can also be made at the role level.

For several years, these features have really helped companies to automate many of their internal controls and to mitigate known risks at the user level. However, in this new era of cyber-attacks, SoD internal controls represent an incomplete security matrix and do not allow companies to achieve a holistic view of their SAP Security and existing risks.

Consider the following quandary; SOX requires the organizational management to individually sign that the financial statements and information published are accurate. But if your SAP systems allow an unauthenticated attacker to modify any financial information processed or stored by the SAP systems, how confident could the organization be in the accuracy of their financial information?

In 2012, Cybercrime costs rose nearly 40 percent and attack frequency doubled, and there is no signs of any reduction in attacks. In the last few years, organizations have become aware of this new problem and are investing increasing amounts of time, money and energy in trying to ensure their SAP Systems meet evolving compliance mandates. Having a developed, documented and tested internal control system for users and being Sarbanes-Oxley Compliant is no longer enough. Organizations must not only maintain proper segregation of duties but also maintain and protect their Netweaver framework, in order to audit and secure not just the Business Logic Layer but also the Application Layer.

As a reminder and an explanation of our terms a SAP system can be divided in several layers:

SoD controls are only protecting the Business Logic layer! The SAP Application Layer (NetWeaver®/BASIS) is critical, and has been traditionally overlooked. It handles critical tasks and components such as authentication, authorization, interfacing, audit logging, etc. Successful attacks to this layer would result in a complete compromise of the SAP system (SAP_ALL or equivalent).

Onapsis X1 is an automated SAP auditing product that has the ability to identify and analyze vulnerabilities in this Netweaver Framework. How does it work? First, it maps out entire SAP landscapes, displaying any insecure configurations on the individual elements of the SAP assets. Once the discovery has finished, the testing can begin. Either manual tests or a pre-scripted set of tests are available. Once you find the vulnerabilities present in the SAP system, you can drill down for specifics and you will even get concise remediation steps. There are numerous types of reports – from high-level executive summaries to detailed compliance reports to the far more complicated technical details for the IT folks. Standard policies are included, but you can create your own as well.

Another excellent capability of X1 is the RFC Topology Map. This could be thought of as a communications map of VPNs between SAP elements. It shows how each is communicating with the others and helps point out rogue communications. A worthwhile feature of the maps is that they can be run and understood by IT network folks who do not have a deep knowledge of SAP. This is secure networking – pure and simple. But rogue communications can be, as we know from recent breaches, a very real danger. SAP and X1 work together to ensure that these rogue paths are identified for remediation. You can read more about these RFC Connections in this blog post here.

To sum up, Auditing & Enforcing SoD controls is a critical piece of ensuring the SAP platform’s security. The only problem is that it is not enough! If not properly protected across all layers, SAP systems can be prone to espionage, sabotage and fraud attacks resulting from cyber security breaches.

Leave a comment