Past-to-Present SAP Access Management Best Practices

What do you do when what used to be acceptable is no longer adequate? How efficiently is your organization managing SAP ERP access and role-design? How pleased are your auditors with the control and reporting you offer? How pleased are your users with the processes they have to follow to get and retain access? How easy is your role architecture to maintain? How much time does your company spend managing theoretical and academic risks versus real and imminent risks?

How these questions are answered go a long way to determining whether the latest advances in SAP ERP access management are being followed, if the old best practices are starting to get in the way, or if access management has never been a competency.

Read Q&A transcript with SAP and Security Weaver experts Sumit Sanga and Steve DuBravac to get answers to your questions on the current and emerging best practices for SAP ERP access management and role design. They discussed questions such as:

• How has access management changed over the years?
• Does sampling still play a role in SAP access audits?
• What are best practices for SAP access risk mitigation?
• What are some best practices for simplifying role designs?
• Are preventative controls still considered the best way to govern access?
• How have the roles of IT, Audit, and Business users changed over the years with respect to access management?

Matthew Shea: Hello and welcome to today’s chat on SAP access management. I am excited to be joined by Security Weaver’s Sumit Sanga and Steve DuBravac.

Mr. Sangha has been using or developing the technology behind effective and efficient internal controls and security policies since 1997. While working with various organizations who struggled with manual controls for business and technical challenges, he recognized an industry-wide need for automation to address internal controls and compliance mandates.

With experience in designing solutions and cutting-edge applications for SAP systems throughout his career, he co-founded Security Weaver in 2004. Currently, Mr. Sangha is responsible for the company’s portfolio development, strategic vision, and roadmap.

Stephen DuBravac is an enterprise software industry veteran. He has spearheaded successful marketing for a wide variety of solutions including Cloud Management Platforms (CMP), Capacity Management, IT service management (ITSM/ITIL), IT Asset Management (ITAM), Software Asset Management (SAM), IT Process Automation (RBA/ITPA), IT Financial Management (ITFM), and Governance, Risk, and Compliance (GRC: including COBIT and SOX). Prior to joining Security Weaver, he served as a United States Cavalry Officer and held a range of positions at Hewlett Packard Company and CA Technologies Inc. Stephen earned his MBA from UNC Chapel Hill.

Comment From Snehal Pandya: I have been a practicing SAP security and access specialist for over a decade. The best practice philososophy says involve business in the security design. One of the most challenging situations that I have faced in various projects is that business is least interested in the security design and is probably the last thought out aspect in any project. Business is not tech literate enough to understand authorization objects, fields, values etc. How do balance these 2 to achieve the core security objectives and make sure that eventually business takes ownership of the security design and deployment?

Sumit Sangha: Few areas that we see lead to successful projects and happy people:

1)      Nail down the executive sponsorship first and keep them engaged on progress weekly (10 min update)

2)      Get everyone’s agreement on all prioritized key issues to address

3)      Identify business objectives (how will business owner/area benefit from this project?)

4)      Identify what are the key security controls that need to be maintained

5)      No big-bang. Deploy one group/department at a time. Learn from first deployment, adjust, rinse and repeat.

6)      Know the business personnel and if they aren’t SAP inclined don’t talk technical, focus on key security controls

7)      Instead of getting business people involved too much, secure time of SAP functional resources (e.g. consultants), people who support the SAP application.

8)      Don’t discuss technical details (objects, fields, values, etc.), instead ask them to be involved in testing of key security controls in the roles that you’ve designed.

Comment From Denis Hallé: Who should be the owner of a SOD implementation project in a company? And what quality must he have to realize this project.

Sumit Sangha: The executive sponsor (or executive committee) should really be the one who “owns” the decision on whether or not to address segregation of duties (internal controls) issues. The executive sponsor provides the teeth behind the direction. The Project Manager would be responsible to execute the decision. The Project Manager (PM) can be from PMO (if available), SAP Security responsible or Internal Audit.

Most of the SOD implementation projects that we’ve seen are tough projects. Many people who need to participate don’t want to spend time on segregation of duties or be part of a project which limits access from people. A lot of people start dragging their feet at different stages.

In addition to people, the PM needs funds for time, timelines, IT resources, etc. Without a firm executive sponsorship, these projects are sidelined for other projects. It’s the responsibility of the Executive Sponsor to support the PM throughout the project.

Comment From Johannes Koenig: Do other companies really have a compensating control for each SoD conflict – or is there just an acceptance by a “risk owner”/”control monitor” ?

Stephen DuBravac: SOD conflicts have different levels of risk. Some may be very low and are reported on to ensure comprehensiveness but do not merit additional investment to manage. For those immaterial risks no owner or compensating control is assigned. However, for any material risk, yes every risk should have a mitigation assigned and a mitigation should have an owner.

To get to this level, the first step would be to eliminate SOD issues as much as possible. Most companies prioritize the outstanding issues. Based on the priority of issue they assign varying levels of mitigation and ownership.

Comment From Laurie Zuelke: Over the past few years of growth through acquisitions, we find ourselves with multiple platforms/instances of production SAP environments. We are currently working on a project to standardize our employee “usernames” so they will be consistent across all platforms. I’m interested to know what “best practice” is for username creation?

Sumit Sangha: This question isn’t specific to SAP, but more of a network question. All of the following should be discussed with your corporate network team. What we’ve seen is they are the ones determining the best naming standard for user IDs, since they usually have the largest user base.

The answer really depends on the number of employees and number of IT systems you have in place. If you are talking about 200 employees, perhaps first initial and last name would suffice. If you are talking about 500,000 employees then it will be best to use incremental number (or employee number) after a general category (full time, part-time, contractor, department, etc.).

Your user ID naming standard should be based on employees (and their count), instead of current users of your SAP system. The naming standard should be robust enough to handle next 10 years of expected growth.

First character of first name and 5 or 6 characters from Last name is the format very widely used for small environments.

If you are considering any non-SAP systems then consider possible allowed max field length of the user IDs of ALL of those systems. Possibly some systems have smaller user ID field than 12. Consider all possible scenarios for a long-term solution.

Comment From Johannes Koenig: Who is (in other companies) approving role assignments? The superior, a key-user, a role-owner, a user administrator ?

Sumit Sangha: It depends on how much control the business owners want to participate in. What we normally see are two levels for approvals.

First is supervisorial approval, which confirms the user’s request is valid. If a Supervisor doesn’t see the request to be valid, then the request doesn’t need to go anywhere. For example, Mary manages a group of sales associates. Mary can approve access for a new sales (Peter) associate to be set up and, for example, to maintain his/her health benefits and insurance beneficiaries.

Second is the approval from specific data steward (i.e. “role owner”). This approval is for anyone’s access to data that I’m responsible for. For example, John is part of HR. If Peter is requesting access to view HR data then John would want to make sure only HR employees have access to HR data of other employees.

This is a simple example, but generally speaking we see two approvals. We only see user administrators being involved in approving role assignments where the business is not equipped/trained/interested in taking ownership of their employee/data. Best practice would be to not have the user administrator to make approval decisions.

Comment From Sreevani: Best practices for Ownership of Risks and automated risk library approvals. Is it better to have ownership at Risks? but since there are shared functions between risks how can that work with workflow approval?

Sumit Sangha: Although there are shared functions (among multiple conflicts), but generally speaking the shared functions are within an application area. The ownership of risks can still be delegated to one person.

For cross-functional issues, the ownership of the risk would lie with the area that is significantly impacted financially.

Comment From DianeS: We currently use a role design of simple roles (master and derived) grouped into composite roles. We are currently planning a role re-design, and considering large job roles (simple, not composite), with only a few smaller, critical access roles to be assigned to only limited users. Any comments for or against this plan?

Sumit Sangha: What are the reasons why you are switching from smaller (I’m assuming) functional roles to larger job roles? For most environments, smaller functional roles are a big lift (change in thinking) initially, but in the long run it is better/easier for maintenance and have ability to provide sufficient controls for changing business. Smaller functional roles are also (generally) in line with SOD functions, which makes the SOD resolution easier.

Larger roles based on jobs work just fine in smaller environments where there will be smaller roles and employees.

Comment From Guest: Can you please share best practices to be considered while assessing the scope and implementing GRC?

Sumit Sangha: Providing the right access to perform business functions without SoD issues are like a double-edged sword that impacts the business either way.

An effective compliance monitoring program really requires good software support. A well knowledgeable team and planned execution with more discussions and participations from various teams like Business, Technical and Audit will improve audit-readiness by keeping track of all compliance-related activities: testing, assessments, monitoring, and remediation.

Start with small workable steps, eg. if needed to address SOD issues then pick HIGH impacts and resolve.

Comment From Kelly Webber: We do an annual user access review performed by managers. But, these managers only see the single technical roles their direct reports are currently provisioned within the environment (even though when they request access, they request a “bundle” of roles and don’t ever see the single technical roles that actually get provisioned to the user). I have seen in other companies where the annual user access reviews are done by the role approvers where each role approver is given a list of users who currently have access to their roles. This can also limit the review because the role approvers don’t always know what other roles each user has. In your opinion, which of these methodologies is best used to do a real user access review?

Sumit Sangha: Best would be both. From access review standpoint, similar to role approvals, there would be two levels. A supervisory approval to confirm user’s access still within the scope of person’s work and role owner approval who confirms the sensitive access is only, still, granted to appropriate users.

Comment From Sreevani: Are other companies using FIORI Mobile Access Request Approval? Is it user Friendly? Can they Approve and reject requests through FIORI?

Stephen DuBravac: Yes companies are using the apps. Is it user friendly? That depends on your process and the data and complications you require in order to meet your provisioning requirements.

Comment From Sreevani: What are the disadvantages of using the BRM in AC? Can we use Business Roles without implementing BRM just so End user can familiarize their roles?

Stephen DuBravac: Operationally, business roles are very similar to composite roles, in fact we have seen companies with a one to one mapping of composite roles to business roles. For example, using Security Weaver’s Role Management product you can design composite roles that meet your business role requirements. For implementation related questions for BRM within AC, I recommend talking with your SAP account lead.

Comment From DianeS: We have found that the smaller roles are used in so many different composites that when we want to make a change to one composite, we don’t always want that change in other composites. Role management has become very unwieldy.

Sumit Sangha: Sounds like the smaller roles in your environment possibly aren’t small any more. The smaller roles should really be around a functional task. So, any composite role that needs to perform that function/task would really need the update (change) made to underlying single role.

A bulk of “role management” is really around managing the definition of single roles. Changes to single roles should be evaluated carefully along with it’s potential impact.

Large roles based on “jobs” will be more complex in large environments and are impractical to maintain after certain number of changes.

Comment From Catherine Shi-Wolan: If migrating a non-SAP ERP to SAP at an international location. what are the key elements the project needs to focus on for a successful migration from security perspective

Sumit Sangha: Focus on:

• Map existing functionality of non-SAP application to SAP functionality
• Define specific (key) security controls (international regulation, internal controls, etc.)

General comments for you to consider as you go through the transition:

While implementing the SAP modules, you can categorize the transaction codes to be rolled out into functional roles for your role design. This exercise is grouping transaction codes according to what they do and where they have similar objects & values checked. Then, determine what business function each user would need to do and map that that to a functional role and then into Composite role structure for your different job roles/positions in your organization. Specifically for an international location, you may need to work with your business divisions and internal audit to make a decision on access that needs to be restricted. You may need to secure access at the organizational levels (Company Code, Purchasing Organization, Sales Organization, Plant, Personnel Area, etc) and even other lower level object levels (such as account type, document type, order types, etc.) to separate out the security for your businesses in different countries, for example. There are generally other regulations and guidelines to consider for personal data access in international countries.

Having smaller functional role design may help in this as you can create derived roles for the different organizational level combinations as needed to secure the areas. You can also determine any lower level objects that need to be restricted across the organization and remove those objects from the “master” functional role. Then you can create “data roles” for each value (singly or grouping values) and assign this “Data role” along with the Derived role that is restricted at the Organizational level.

Comment From Guest: Could you please provide some guidance regarding role design and also the best practices to simplify the role design processes?

Stephen DuBravac: Not to sound facetious, but a great practice for role design work is to avoid the big bang design projects so many organizations face every 5-7 years as much as possible. You can reduce the risk of having to have these kinds of expensive projects by thinking about role design and role management as a software development exercise where requirements gathering is key and a stable workflow (that includes design reviews and end user testing) during the design process is also important. Continuing with the metaphor of treating a role redesign project as a software project, instead of rewriting your entire code base (your entire role architecture) it is a better practice to refactor your design a little at a time so that you remove the “technical debt” from your architecture. Technical debt is when your organization changes or your requirements change and instead of doing a great answer, you do a quick answer. After enough “quick answers” the character of the design becomes increasingly difficult to manage. By refactoring the design continuously and removing this technical debt you can avoid or at least postpone a major role redesign project in the future.

Another good practice for role design is to assess the stability of your user community. Is it a large community that is multinational or a small group and relatively stable? Depending on how you answer this question you can make an informed decision to go with a 3 tier model or a 4 tier role architecture.

Stakeholder involvement is also critical as different organizations will interact with SAP differently, have different levels of functional spans of work and will face different regulations and audit requirements, as well as may assign different decision rights to users and have different levels of data controls which will impact the role design. Also, going back to the idea of refactoring, staying on top of organizational changes will help minimize issues overtime.

One of the more important and often unsung best practices for role design is to get data on user activities. The more use activity is understood the better you can identify where roles need to be changed and where they are adequate. The best time to surface user data and organizational changes in order to understand how these might impact a future role design is during access recertification processes.

One other best practice recommendation is to not try to solve everything with your role redesign. More and more companies are recognizing that controlling for all your SODs through the preventative use of roles is problematic. Instead of designing roles for complex cases, have a strong transaction monitoring solution in place that looks for suspicious transaction pairs and alerts risk owners in real time or near-real time. For example Security Weaver offers a solution called Automated Mitigations(™) which uses your SOD ruleset (regardless of what vendor is providing the ruleset) and monitors the entire transaction set of the enterprise.

Matthew Shea: Thank you everyone who posted a question today!

Thank you Steve and Sumit for all your in-depth answers today.