When searching for the culprits responsible for SAP access risk, look in your application security architecture and design. The composition of the security model, the maintenance, and provisioning of security are all critical components to minimizing access risk across your environment(s). Without an overarching governance process and key design principles, the security model could be the root of a multitude of challenges, including:
To start, an intra-role segregation of duties (SoD) conflict is when two or more conflicting permissions coexist in the same role. This means every time the role is assigned so is the conflict. This is a critical concept and often the starting point for many security remediation or redesign projects. Oddly enough, this is a common finding following an implementation or an upgrade to an existing ERP. This could derive from deprioritizing security so as not to jeopardize the go-live, copying the standard SAP roles for user assignments, or simply inadequate controls and governance of the security design. It is imperative that the security roles are designed without intra-role SoD conflicts to facilitate compliant user assignments.
Excessive or unintended access can also stem from a variety of sources. This can exist due to poor role design or a collection of role assignments to a single user. From a role perspective, the composition and maintenance of permissions is the foundation of a compliant security design. Some of the common violations we see are asterisk (*) values being maintained which is equivalent to all permissions within that respective object field. The ‘*’ value is a common culprit for many access risks even being used for S_TCODE access in some cases. Other common findings include roles defined as display containing access beyond read-only privileges or roles containing cross-functional access.
From a user perspective, a single role or multiple roles assigned can lead to excessive or unintended access. As an example, when multiple roles are assigned, they could have object collision resulting in unintended results. Perhaps the most common role assignment activity leading to risk is the statement, “copy <insert colleague’s name here> access”. Far too often, this statement is used, resulting in an assignment of roles that may or may not align with that person’s job responsibilities. Not only does this pose a risk, but it is often compounded as the existing access is overlooked and not removed from the user. Organizations with a mature security and compliance program utilize tools such as Fastpath Assure to implement automated provisioning processes that are driven by workflow and consist of SoD and critical access checks. This is a critical preventive control for maintaining a compliant environment.
Sensitive and critical access can have a different meaning to each organization as they span across a variety of industries, geographies, regulatory landscapes, and more. Within SAP there are standard transactions and authorizations that can be deemed sensitive. A transaction could be defined as critical or sensitive as it is the gatekeeper for customer information or even intellectual property. Not only is it important to know who is accessing your critical data, but organizations must also be concerned with where they keep that information. GDPR, CCPA, and other regulations impose strict guidelines on how to collect, manage, and access customer information.
Below are a couple of examples of authorizations that an organization may deem sensitive:
There are many different approaches and standards which can be leveraged when defining security architecture. The one constant each organization should strive for is a compliant security model. This can be achieved irrespective of a task-based, job-based, master-derived, or an enabler architecture is implemented. Some of the key elements to implementing a compliant security model are:
Key Stakeholders – Stakeholders should be identified from the onset and consist of executive sponsorship, business, IT, compliance, SMEs, and other team members. Buy-in from the top is a key success factor. Keep in mind that implementing a compliant security model could impact existing processes, be resource demanding, and potentially result in organizational change. These can pose many challenges for organizations without the appropriate stakeholders.
Ownership and Accountability – Top-down buy-in is critical to empowering team members, establishing accountability, and defining metrics is vital to the success of an access management program. Ownership throughout the lifecycle facilitates buy-in and thoughtful input for defining and sustaining the security model.
Compliant and Scalable Design – Ensure the architecture facilitates the day-to-day operations seamlessly to end users and is constructed in a compliant and scalable manner. The architecture should consider things like industry, geography, organizational structure, and much more. “Key design principles” should be established and documented for ongoing governance. This could include approaches like the principle of least privilege as well as specifics to avoid SoD and critical access conflicts as highlighted above.
Defined SoD and Critical Access Ruleset – Establishing an SoD and critical access ruleset is the foundation to monitoring and managing access risk across the landscape. The ruleset should be tailored to be reflective of the organization’s risk universe and appetite. It should include defined risk criticalities, consist of customizations, established framework of when violations should be mitigated or remediation, and much more. The ruleset should be validated and approved across the business and IT, and even reviewed with internal/external audit partners for future reliance.
There is a one-size-fits-all approach for the “culprits”. The considerations remain the same: control framework(s), policies and procedures of a compliance program, the people/owners/approvers accountable, and the technology to improve the efficiency and effectiveness of overall operations. Below are some approaches to managing these associated risks for System Authorizations and Accounts: