Segregation of Duties is one of those business concepts that’s a bit abstract, but the…
If you run SAP in your organisation, you will be well served by a diligent focus on SAP security and compliance. The current environment of cyber security threats means this is necessary. SAP is the core of a business. The best-run companies use SAP, making the ERP system one of the juiciest targets for today’s advanced attackers.
Some common SAP Security risks
SAP security measures span the complete spectrum of business processes, user identities, roles and permissions, systems, data and underlying infrastructure. Each of these elements expose SAP to threats. All require risk mitigation strategies and countermeasures.
Roles and Access Control Risk Exposure
Who can access SAP? Of those, what functions can each user access? These are the fundamental questions regarding SAP access control. It’s essential to have firm and accurate answers in order to deliver a meaningful level of SAP security. The best practice is to review user access regularly. Reviewers should assess role-based access rules as well as transactions (T-Codes) and authorisation object levels.
User access also figures prominently into Segregation of Duties (SoD), an important control required for compliance with the Sarbanes-Oxley Act. Segregating duties means splitting up access and SAP system privileges in such a way that no single person can perform all the steps in a financial transaction, e.g. issuing a cheque to pay an invoice. If these duties are not segregated, it’s possible for a SAP user to commit fraud. While not inherently a cybersecurity requirement, SoD does depend on access controls, which are necessary for security.
User roles and access controls affect third parties like vendors, business partners and contractors. Allowing outside people to interact or integrate with your SAP system is often essential for doing business in today’s connected, digital world. However, the practice comes with its share of security risks. For example, it may be impossible to know if third-party users are engaged in the insecure habit of sharing passwords. Or, you may not know if an employee of a third party has left his or her company. You don’t want such a person to have access to your SAP data.
The FireFighter temporary user ID is another potential attack surface to guard with strong SAP security policies. Given that it confers elevated access privileges in the event of an issue, it’s a powerful weapon for somebody acting maliciously. A good practice is to limit the number of users who can take advantage of FireFighter. Alternatively, it may be a wise security policy to divide FireFighter use by area. You could have a FireFighter ID for the database, another for application access and so forth.
Systemic SAP Security Issues
The SAP application, data and infrastructure exposes the enterprise to security risks. For example, you might apply an opening or closing period to financial transaction recording. Even with such a simple control, there are a few risks. If there is a change in business processes or workflows, the control might interfere with operations or create poor quality data like a transaction occurring in two separate accounting periods. This isn’t a security issue like vulnerability to a cyberattack, but security is also about ensuring high integrity data to the business. A lapse in controls could affect this pillar of InfoSec.
Alternatively, application controls may open entrances into the back end of SAP that expose the system to threats. Customised objects like forms and interfaces may create unanticipated “back doors” for malicious actors. It’s a good practice to examine any proposed customisations carefully to assess whether they are permitting third parties or unauthorised users (including machines) to access data and invoke procedure calls in the SAP environment.
The basic hardware and network itself can affect the security posture of a SAP instance. This is where highly advanced and persistent threats can make a big impact on organisations that run SAP. Threats include root kits, operating system attacks, firmware-based attacks, data base attacks, ransomware, network-borne malware, and others. The connectors between different parts of the SAP system also factor into risk exposure. If not well protected, they can be vulnerable to unauthorised access that puts system data at risk.
Getting on top of security in SAP environments
There’s a lot to deal with when you confront the full extent of SAP security. To help you cope and achieve the best security posture possible, we developed a three-step series of best practices:
- Establish Baseline Risks –Review your sensitive roles, understanding that the most powerful roles in your system have the greatest vulnerability. Review customised transactions, like those that start with Y or Z. Run an SoD risk analysis, watching if stakeholders are not aligned regarding access needed by specific employees
- Define Controls –Create an audit list that covers user access rights: the where, when and why of access. Assign mitigating controls, including expiration dates so SoD won’t fail due to people moving around the organisation. Verify controls, making sure that they are still active. Do this once or twice a year.
- Perform a System Risk Assessment – Check for simple but serious problems like weak passwords. Verify that profile parameters are consistent across cloud and on-premises deployments, e.g. Lock production systems to prevent accidental or unauthorised changes. Remove all developer keys and limit them during development.
Are managed SAP security services the right option?
Managed Security Services (MSS) provide an alternative to taking care of every element of SAP security on your own. With MSS, you outsource some or all of your security needs to a company like Symmetry. Ensure the provider you choose takes you through the best practices outlined above.