The SAP ERP system supports all of your business’s operations. It includes accounting, customer relationship management, and HR functions
The data that your implementation will accumulate during normal operations include information on your product catalog, data on your customers and suppliers, and information about your employees.
The database that lies at the heart of your SAP system contains information about your operations, such as prices, profit margin, and client list. That data would be of value to your business rivals. However, the data in your system that relates to individuals is called “personally identifiable information” (PII). This data is of interest to hackers, and it can be sold on the Dark Web.
PII and trade secrets need to be protected; the loss of either could damage the profitability of your enterprise. Industry standards and government legislation guide the protection of PII. Depending on where your company operates and the industry sector that it is involved in, there are many security standards that you will need to comply with.
SAP security
SAP has threaded security measures through its software package. That security relates both to the behind-the-scenes administrator access and frontend user accounts. As a result, you don’t need to buy third-party systems to secure your SAP implementation, and you just need to properly manage the access controls provided within the SAP package.
You will need to buy specialist software and services to ensure your general system security data governance.
SAP security is complicated because so many different elements need to be secured. To explain the many points of the ERP system where security needs to be managed, SAP produced a graphic called the Secure Operations Map, produced here below.
The Map layers are organized to have factors related to implementation at the bottom of the stack and planning issues at the top.
The number of people involved in implementing SAP security in an organization depends on the size of the business. Ultimately, the System Administrator and the DBA will implement the SAP security strategy.
SAP security vs. system security
When you look at the Secure Operations Map, you will undoubtedly remark that many of those layers relate to system security. Although system security covers SAP along with all other facilities and applications, they aren’t steps that will only be triggered by your project to secure SAP. You will be performing those tasks anyway.
The Secure Operations Map is SAP’s way to provide customers of the ERP with a route to follow by breaking down the tasks of SAP security and making sure all factors are covered. The Organization and Process layers of the Map contain policy tasks. The Environment level and most of the System layer of the Map are general system issues rather than specific matters for SAP security.
The Application layer in the Secure Operations Map is specifically about SAP security. Therefore, it uses native security measures that we will concentrate on when discussing SAP security rather than IT operations security.
Organization and process security
The top two layers of the Secure Operations Map relate to a corporate strategy towards risk management and data protection obligations that are externally enforced.
The Organization layer contains topics necessary to guard the business’s best interests, protecting the organization from loss of operational data. Finally, the Process layer explains systems that can implement the company’s obligations demanded by industry standards and national laws.
The tasks and systems expressed in these two layers are generally expressed under the title GRC. That stands for Governance, Risk, and Compliance. They are business-wide functions and not specific to SAP, although SAP does produce systems that operate in the GRC sphere.
You won’t be implementing GRC for your SAP system in isolation – it needs to be performed in the whole business context. To understand the issues involved in GRC and the types of systems available to support it, take a look at the Best GRC Tools.
Third-party security systems
If you want to try security packages that are produced by other companies, your best option would be to select a SIEM tool or other system-wide threat detection service that will monitor activity in other applications as well as SAP.
Logpoint
An example of a suitable SIEM tool is Logpoint. This is a cloud-based service that collects log messages and also uses integrations to collect activity data from within applications. One of the systems that Logpoint can interface with is SAP.
The Logpoint service is able to interface with security tools on site, such as access rights managers and firewalls to automatically shut down the suspicious activity that it detects.
SAP application security
The four security categories at the Application layer of the Secure Operations Map are:
- User and identity management
- Authentication and single sign-on
- Roles and authorizations
- Custom code security
Down at the System layer, one more security category relates directly to SAP. That is:
- Secure SAP software code
Much of the work you need to perform to set up security in the SAP application is guided. There are specific requirements for an account record, so there is certain information that you cannot avoid entering. The precise structure of your user accounts will be dictated by the planning that you and your colleagues perform when working through organizational security definitions in the Organization and Process layers of the Secure Operations Map.
The five categories fall into two divisions:
- User-related security
- Code security
The responsibility for these two areas can be allocated to two different members of the ITÂ support team, but in small businesses, one person could be tasked with implementing both.
With an ERP system, the user account creation process involves several layers of allocation tasks. This is expressed in the three categories:
- User and identity management
- Authentication and single sign-on
- Roles and authorizations
These three user creation tasks express what name the user has in the system, what screens that user can access and what actions the user can perform on each screen.
User account maintenance in SAP is no different. For example, there the strategies that you already use for other business applications and general network or device access. Creating group identities is commonplace to distinguish between system users and system administrators. However, ERP systems, such as SAP, also require the identification of departmental user groups and then user types within each department.
User and identity management
The main distinction between users in the user and identity management function of SAP security is the built-in categorization between application users and technicians. The backend access allowed to IT supports staff provides a very different view of the SAP system to that permitted to the applications users.
For an application user, the primary task is to provide a username and password. After that, all other considerations are pushed into creating roles and authorization levels.
Authentication and single sign-on
The primary authentication method in an SAP environment is the user account password. This needs to be managed by the user to ensure that system administrators don’t control passwords for user accounts.
The decision to allow a single sign-on environment within the organization moves user account management outside of the SAP administration environment. SAP provides a system called “connectors.” To enable the access rights management functions of the SAP system to be dictated by the settings maintained in external systems, such as Active Directory.
With the AD connector set up and operating, you can rely on Active Directory for your SAP user account management, even for creating or deleting accounts. This centralized strategy outside the SAP application allows a single sign-on strategy to be implemented and fold in SAP security for user accounts with the rest of your user and identity management strategy.
Roles and authorizations
The Security Operations Map lumps roles and authorizations together as one topic. However, these are two huge subjects that will absorb most of your time when setting up your SAP implementation. These two topics are further complicated by the concept of approvals, which is not mentioned explicitly in the SAP literature but fits into the Roles and authorization category.
Implementing roles, profiles, authorizations, and approvals are specific SAP administration tasks. However, the planning that inputs all of the requirements for these topics should come from above and form part of the GRC functions implemented in the Organization and Process layers of the Secure Operations Map.
Fundamentally, when planning and implementing roles and authorizations, you are protecting system data by limiting access to the screens that access those data sources. So, for example, a user that can’t get at the client list can’t steal it.
A role is a user group. You create roles related to departments – HR, Finance, Sales, etc. The screens available to each user can be inherited from the role. That allocation of screens to roles is meant by “authorizations.” The inherited allocation can be refined at the user level, and those lower-level function allocations override inherited authorizations. That user-level authorizations allocation is called a profile.
Approvals relating to the power of each user to operate a budget. Some actions, such as purchases, require clearance from a second user – usually a manager. The approval abilities of each user are defined in the organizational hierarchy, which is part of the HR system of the SAP package.
SAP code security
SAP is a very rigid system, and the creators of the ERP tried to discourage customizations wherever possible. Instead, companies are encouraged to adopt the SAP system by selecting from available settings rather than rewriting screens and functions.
Custom code security
Customizing SAP can be done in two ways, inserting new functions within the system or writing side utilities outside the system. SAPs attitude to either of these two approaches is straightforward: don’t do it.
If you make changes within the system, they could be wiped out with the following software update and will need to be reintegrated. In addition, if you create systems external to the SAP environment that access data from the database, you open up the possibility of sidestepping SAP system security that is structured to restrict access to data.
Secure SAP software code
The main task of implementing SAP code security is to apply software patches whenever they are available. This recommendation can be made of any software packages you run, not just SAP.
To help system administrators in the dilemma of whether to prioritize patches over out-of-hours batch jobs, SAP has implemented Security Patch Day. This is the second Tuesday of the month. The company doesn’t restrict its release of patches to that day. However, you should set up your patching system to run on that day as a minimum.
SAP security systems
The heart of your SAP security lies with the structure of user accounts, your refusal to customize code, and the implementation of Security Patch Day. Outside of the SAP environment, your responsibilities for security systems lie with GRC systems and system protection.
SAP produces GRC packages that are extra services and not part of the ERP environment. However, these tools integrate with the backend services of your SAP ERP to effectively integrate them into your SAP environment.
Here are some SAP security packages that you could consider:
- SAP Financial Compliance Management This package implements automated governance. It applies pre-audit checks on data security and applies the requirements of specific data protection standards within data management processes. In addition, this system provides warnings and guidance and automates workflows to ensure that data access is logged correctly. This is a SaaS platform.
- SAP Risk Management This monitoring package assesses risk levels, risk drivers, and key risk indicators, operating continuously. This system is based on a risk hierarchy, which needs to be set up through a guided process. Available as a SaaS platform or an on-premises software package.
- SAP Process Control This package is suitable for implementing the Process layer of the Secure Operations Map. It provides an overview of data protection standards compliance and financial controls. In addition, this package helps you organize the approvals hierarchy in SAP, and it is available as a SaaS platform and as an on-premises package.
- SAP Data Custodian If you use cloud-based SAP resources, you would benefit from this package, which enforces data controls in cloud-based systems—offered as a SaaS platform.
- SAP Privacy Governance You can use this module for both on-premises and cloud resources to manage the Digital Subject Access Request (DSAR) process. You need to be able to fulfill requests without disclosing information about others. This is a SaaS platform.
