Control Compliance and Business Risk with Streamlined Role Maintenance: Q&A on BRM Functionality and Configuration

A critical element of an efficient and compliant SAP system is control over user access to your business systems. The Business Role Management (BRM) component of SAP Access Control 10.0 provides SAP customers with comprehensive, centralized monitoring and maintenance of the role definitions that determine this access. BRM offers not only a single repository for managing your company’s security roles, but also functionality that simplifies compliance.

On February 18, GRC 2016 speaker James Roeske, took readers’ questions on how BRM helps manage access across an SAP system landscape, and how it enables control over compliance and business risk. To hear how he responded to questions on BRM functionality, configuration, and use, we invite you to check out the chat replay in the window below. You can also read through the entire, edited transcript, which is located just after the chat window.

Meet the panelist: 

James Roeske, CEO and co-founder of the Customer Advisory Group, LLC
James has over 22 years of SAP security, audit, GRC, and executive management experience. Over those years, James has had a professional focus on technical configuration of SAP R/3 Security, segregation of duty design, user provisioning solutions, GRC software solution design, and corporate compliance implementations for companies around the world. Previous to founding the Customer Advisory Group, James held strategic positions at Virsa Systems, SAP America, and SAP Canada. This has allowed him to lead, plan, and participate in over 200 SAP GRC and security projects for some of the largest and most complex compliance environments across the globe.

Transcript

Natalie Miller, SAPinsider: Hello, and welcome to today’s live Q&A on streamlining role maintenance and managing access across your SAP landscape. I’m Natalie Miller, features editor of SAPinsider and insiderPROFILES, and I’m happy to introduce today’s panelist, James Roeske, CEO and co-founder of the Customer Advisory Group, LLC.

James has over 22 years of SAP security, audit, GRC, and executive management experience. Previous to founding the Customer Advisory Group, James held strategic positions at Virsa Systems, SAP America, and SAP Canada. This has allowed him to lead, plan, and participate in over 200 SAP GRC and security projects for some of the largest and most complex compliance environments across the globe.

Hi, James, thank you so much for being here today!

James Roeske, Customer Advisory Group: Hello, thank you for having me! I look forward to answering all the great questions on BRM today from our attendees.

Natalie Miller: James is also a speaking at our upcoming GRC 2016 event. We are excited to have him here today to answer all your questions. There are some great questions from readers already coming in so, James, I will let you get right to those.

Comment from vilon: What is the best approach to implement BRM across a 3-tier landscape consisting of development, QA, and production systems?

James Roeske: There are a couple of things to consider here when you refer to a “landscape.” The first is the SAP GRC landscape itself. It is recommended that your SAP GRC production environment be the source for BRM management. That means that all role changes would originate from BRP production. The next is your back end systems; BRM PRD would facilitate the role change process, make the change, and generate the role in the development back end system, just like all security changes happen today. Then I recommend that the standard change control process (transport) be used to move that role change up your environment to QA and PRD. I do not advocate that BRM have the ability to generate roles in a QA or PRD.

Comment from William: If the role change is from DEV to QAS/PRD and is managed by CHARM, is there any conflict when implementing BRM in terms of change workflow?

James Roeske: BRM is not a replacement to proper change control and transports. Therefore, based on what I advocate to customers, all BRM-initiated role changes would still occur in the DEV back end system, and you could use your existing process to move those changes up the environment.

Comment from Guest: Is BRM a workflow control?

James Roeske: Yes, BRM uses workflow to facilitate the many steps necessary in the lifecycle of a role change. This includes getting approvals for the change, etc. — all utilizing BRF and MSMP workflow tailored for SAP GRC.

Comment from Miha: With SAP GRC AC 10.1 SP11 (Note 2171091), SAP added the ability to attach a ticket number for role changes. My question is about how to use this feature. Should this ticket number be generated in the GRC system via ARM?

James Roeske: Although I don’t have the OSS note you are referring to in front of me, if I recall correctly, this additional functionality provides the new “documentation field,” which allows entry of an external ticket number, not one from GRC itself. As you know, many customers leverage external ticketing systems like Remedy, Service Now, etc., and this field provides a way to tie that ticket with the SAP GRC BRM process to close the audit loop.

Comment from Prashant: SAP GRC Access Control has been in the market since 2006, but we see very few BRM implementations apart from integration with ABAP stack. Is SAP planning to integrate BRM functionality for other applications like Ariba, SuccessFactors, BPC, EP, etc.?

James Roeske: Yes, you are very correct. BRM is usually implemented later on in the lifecycle of a GRC roadmap by customers. As a result, fewer customers use BRM compared with ARA or EAM, which are usually the first applications needed by a customer. Plus, the functionality and ROI of the application has changed significantly over the years as well. Therefore, several customers made the decision not to use it several years ago based on past limitations. But the product can do a lot more now, and I always recommend customers reevaluate BRM as it could potentially solve audit and compliance issues, lessen documentation deficiencies, and provide some automation that could give additional ROI.

As for compatibility with other applications like Ariba, I’m unfortunately not able to comment on that since SAP has not shared that type of product roadmap information at this time. But I do agree with you that it would be very helpful if SAP covered all areas with a consistent BRM process.

Comment from Nicholas: Hello, James. Could you tell me the biggest differences between the 5.3 version and the 10.1 version of GRC?

James Roeske: The biggest differences between 5.3 and 10.1 BRM, from my perspective, are the following:

1. Workflow engine: 10.1 now uses SAP workflow requiring BRF configuration, compared to the internal engine it had before in GRC 5.3
2. Ability to have business roles: This is the biggest and most value-added change, in my opinion. Business roles allow you to build what I call “Cross System Composites,” which is basically a new way to bundle access together for your end users. This business role concept also allows ARA to run SoD against a business role, and ARM can now provision business roles, too. This can be a game changer for some companies.

Comment from Mehul Shah: Hi, James. How are you doing? Good to meet you again!

James Roeske: Thanks for attending today! Hope to see you at the GRC 2016 conference in Las Vegas.

Comment from ThomasR: We are just starting a new SAP ERP ECC 6 EHP7 on HANA project. We will have a GRC 10.1 system. When is the best starting point to implement BRM? Blueprinting and configuration are just starting. Can we use it for development roles also?

James Roeske: As I mentioned before, most customers wait for the later part of their GRC roadmap to implement BRM. But that does not mean that is the right thing to do. There can be great benefits to having BRM working for you at the early stages of your project. This includes having clear and consistent documentation of your roles from the very start of your project if you had BRM running, plus the ability to build roles with consistently executed SoD analysis (if you also had ARA running at the beginning too).

The only downside and feedback I have received from some customers who use BRM during the initial stages of their project is that it can slow down the security development process. What I mean by this is that BRM enforces proper role creation and change process. This is usually great, but during the initial part of your SAP implementation, security admins usually have significant volumes of roles to build and want to build them en masse as quickly as possible to hit project deadlines. This means simple extra clicks in the process can be a pain point and complaint of a security admin in those early stages.

Long story short, you need to determine what about using BRM would add the most value. If it’s having this consistent process, detailed documentations from the beginning, enforced SoD analysis during the role development process, and workflow controlled role content approvals, then I would consider using it sooner rather than later.

Comment from Sri: Can you point to and elaborate on what you would consider ‘lessons learned’ in a BRM implementation?

James Roeske: That is a good question. I strongly suggest people focus on two things:

1. Establishing role ownership: This means that this is not just a tool for security admins, but rather a way to have proper role content owners involved in the process via the BRM workflow approval stage. It is very rare that I see a customer with an existing role owner concept and list that can be automatically added into BRM. Therefore, make sure you get the right people who will truly look at content and can provide proper valid approvals or feedback. It is so important and usually overlooked. The “security team” usually has to do this on their own, which leaves them at risk.
2. Focus on the process: BRM enforces a consistent process for role creation and maintenance, which is great. But if you have a complex process or one that is not adding value, BRM will be enforcing those problems too. As I say, the clicky clicky is simple in GRC, but the thinky thinky is the hard part. You need to focus on defining a realistic role creation and maintenance process, documentation standards, and approval/ownership, and BRM will add significant value, especially when audit time comes around.

Comment from Guest: Hello. We are currently on ECC 6.0 and will soon migrate to ECC on HANA (EHP7). Do you think GRC 5.3 can continue to work with HANA? Is there an upgrade/patch for GRC 5.3 for HANA? Or do we have no option but to upgrade to 10.1? We use CUP, RAR, and SPM modules.

James Roeske: First off, version 5.3 is now out of SAP support (as of December 2015). So no matter if you are HANA or non-HANA, I suggest that you consider utilizing SAP supported software, which would be 10.0 or 10.1.

Comment from PT: What are some cons of using BRM, such as adding an unnecessary layer of complexity to a simple process of role change, and why should BRM be used in spite of the cons?

James Roeske: As you know, pros and cons can be relative depending on your perspective. From a security admins perspective, the con would be having to perform additional steps and clicks to create or maintain a role in the system, compared to just using PFCG directly. But from the perspective of the auditor and potentially the role content owner, this is a pro, since those extra steps are related to better documentation, detailed approval audit trails directly stored in GRC, enforced consistent SoD analysis for roles, etc.

Therefore, it is really up to each customer to see what the benefits are for them to use BRM, rather than saying, “I now have to click 10 additional times as a security admin using BRM compared to the old way.”

Comment from PT: Thanks, makes sense.

Comment from Terry: Hi, James. What’s your opinion on having a standard role naming convention across the production tier, i.e., the same in ECC, HR, GRC, CRM, APO BW, etc.?

James Roeske: Hi Terry. I might need some additional clarification on your question here. Naming conventions are a very critical foundation in SAP security (as you know). I’ve been doing SAP security now for 23 years, and I have had to change my thinking around naming conventions many times over the years as our SAP landscapes have grown and gotten more complex. But with that said, I will give you my personal opinion on the matter.

I believe that having a portion of your naming convention to indicate what platform the role belongs too is a good thing. But I also understand that things like basis roles, which potentially can be universal across all systems like ECC, BW, GRC, etc., should not have to be replicated multiple times for the sake of a naming convention. Therefore, I try to find a happy medium by having a character indicator in my naming conventions to indicate if it belongs to ECC, BW, etc., as well as having a cross platform value for those universal roles applicable in all systems.

I hope that helps. If I misunderstood your question please let me know and I would be happy to try and answer your specific question.

Natalie Miller: As we come to the end of today’s Q&A, I’d like to thank you all for joining us and for all these great questions! What an interesting discussion today.

James, a special thanks to you for your time today and for all these insightful answers!

Comment from Guest: Thank you! Thank you for all your help.

James Roeske: Thank you it was my pleasure. If any customers are thinking about implementing BRM and would like to get additional information of what it takes, please feel free to reach out to me at james.roeske@CustomerAdvisoryGroup.com. We here at CAG specialize in SAP GRC implementations.

I will also be presenting at the GRC 2016 conference again this year and would love meet you all there. Click here for some additional information on the sessions I will be presenting.