Understanding SAP Security

[integritty]

As cyber threats grow more dangerous and frequent, the once clear boundaries between SAP security, cyber security and compliance have started to blur. Traditionally, SAP security comprised the tools and processes that controlled what users can access inside an SAP landscape. With malicious actors now penetrating and lurking deep inside corporate networks, SAP security must go far beyond its basic access control function.

Why Does an SAP Landscape Need Protection?

Strong security countermeasures more critical than ever to protect SAP landscapes from threats that range from cyber criminals, industrial spies and nation state actors to malicious insiders. There are two primary reasons to implement rigorous defensive measures. First, the data held in the SAP landscape is attractive to hackers. Your SAP hosting environment contains lots of confidential information (such as financial records) and sensitive procedures (such as paying inventory). It may contain personal information about customers as well as bank account data and intellectual property. Data from an SAP system could be used for identity theft, fraud, industrial espionage and international espionage as well as “CEO frauds,” which involve hackers tricking employees into wiring funds to offshore bank accounts.

The other risk has to do with disruption. Malicious actors can cause your business to cease operations through Denial of Service (DoS) attacks, root access abuse and ransomware. Without proper countermeasures and controls, your business is vulnerable.

What is SAP Security vs. Cyber Security?

The answer to this question used to be simple. Cyber security services primarily protected organizations against external threats and SAP security, in contrast, focused on internal risks. Perimeter-oriented, cyber security countermeasures used to concentrate on keeping bad actors out of the network and away from SAP systems. This involved activities like intrusion detection, firewall monitoring and Identity and Access Management (IAM). If there was suspicious behavior, the Security Operations (SecOps) team would detect and investigate the issue and if it appeared to pose a threat – neutralize it.

The assumption of SAP security was that any user on the network was allowed to be there. The goal was to ensure that users had a level of access appropriate to their role, and in compliance with the company’s SAP Governance, Risk Management and Compliance (GRC) program. Segregation of Duties (SoD) offers an example. If an employee has the ability to create vendors in the SAP accounting system, he or she should not have the power to pay vendors as well. Having this SoD risk would create a compliance problem and expose the company to fraud.

THOUGH ALWAYS INTERDEPENDENT, CYBER SECURITY AND SAP SECURITY ARE NOW MUCH MORE CLOSELY LINKED.

If an employee’s SAP access patterns raise suspicions, SecOps should investigate to see if the person is doing something wrong or if a hacker is impersonating the user with stolen credentials. However, SecOps has to notice the problematic behavior, which doesn’t always happen. This overlap has grown far more intense.

Highly sophisticated hackers, sometimes even from foreign intelligence services, can lurk inside SAP landscapes for months, amassing information on who’s who and where the most valuable data is located. Then, using encryption, they can exfiltrate massive amounts of confidential data before being discovered. That is, if they’re discovered at all. For this reason, organizations benefit more than ever from an integrated security and compliance model that addresses insider, outsider and regulatory risks.

SAP Security Concepts

SAP security encompasses three core areas of cyber security: access control, data security and application security. To be secure, an SAP landscape is subject to strict access controls, and the system data should be protected as well as possible. Finally, the application itself should be subject to strong security safeguards.

In practice, getting all three of these SAP security concepts to work in harmony means applying the best available security tools and practices to the SAP landscape. For example, if the organization uses Multi-Factor Authentication (MFA) to grant network access permission to external, mobile users, that control should also be applied to anyone else wishing to access the SAP systems.

Then, within SAP, a data security policy should enforce restrictions on data access by role. Securing the application involves patch management and strict Privileged Access Management (PAM) controls to ensure that no unauthorized person can get administrative access to the SAP back end.

What is SAP Security and Authorization?

Controlling access to data on an SAP system, or any system, for that matter, is a process with three elements. First is identity. The user must establish his or her identity to gain access to the data. This might mean being an employee or showing credentials like a driver’s license to get permission to log on. Then, there is authentication, the step where the SAP system checks to see if the user is really who they say they are. This is typically a username and password. After authentication comes authorization.

Authorization is a step in access control that matches the user with the systemic and data access privileges held by the user. For example, an accounting department staff member should only have permission to use the accounting module and make use of (appropriate) accounting data.

It’s a balancing act. The system should be open enough to enable efficient work. At the same time, too much access increases risks. Managing access controls can be an administrative burden. The best practice is to govern authorization by role.

How Does SAP Security Work?

SAP security works effectively when the security controls embedded in SAP are well-integrated with the organization’s broader cyber security and GRC functions. For example, if you’re using SAP NetWeaver Identity Management, it’s best to federate it with your core IAM system, e.g. Microsoft Active Directory. That way, if an employee leaves the company, he or she will be locked out of the SAP system, too. You would be amazed how many ex-employees retain access to critical systems due to security policy enforcement lapses.

It’s a bigger picture than that, of course. Security is a sprawling, complex set of activities that spans IT, governance and business operations. We developed three best practice steps to help you cope with implementing SAP security:

• Establish Baseline Risks—Review your sensitive roles with the understanding that the most powerful roles in your system create the greatest risk exposure. Similarly, take a careful look at custom transactions, e.g. those starting with Y or Z. Run an SoD risk analysis, watching if stakeholders are misaligned 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 organization. Verify controls, making sure they are still active 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 unauthorized changes. Remove all developer keys and limit them during development.

How does SAP security work with GRC?

GRC looks at what users can do (and are doing) in the system, then creates policies to remediate risks and meet regulatory compliance requirements. SAP security implements those policies on a day-to-day basis — for example, by provisioning new users and investigating signs that the system is not operating in accordance with GRC requirements. GRC software helps both the GRC team and the SAP security team do their job more efficiently and effectively.

Roles and Access Control Risk Exposure

Our suggested best practice, enabled by our GRC tool, is to create clear roles, each with unique access privileges. It is then possible to check for SoD conflicts and remediate them quickly. This practice reduces access control risk exposure.

However, there will also be emergencies that require employees be given access permissions outside their roles.  It may even be to outside consultants to fix code problems.  This requires a well-developed emergency access management (EAM) plan to address and monitor the risks that may arise when dealing with what are often called ‘fire call’ situations within the SAP environment.

Even with the proper role, access controls and meaningful segregation in place, these SAP security basics must run smoothly day in and day out, keeping process owners informed and adaptable as the organization changes.  This poses a big challenge to SAP security and IT staff.

Managed Security Services for SAP

More than ever, organizations are facing a wide range of SAP security risks, cyber security vulnerabilities and regulatory requirements. Addressing these challenges requires a diverse and highly trained team of IT security and compliance professionals. Most enterprises struggle just to successfully remediate poor audit findings, much less provide continuous monitoring and incident response. Typically, only the largest can field an internal team capable of constructing and maintaining an adequate GRC program.

Working with a complete security and compliance partner provides superior protection and risk mitigation while controlling costs. We can audit your current business practices, revamp your security model to reduce internal and external risks, bring you into full compliance, and provide around-the-clock incident detection and mitigation.

.