When is it time to move to Access Control 10.0 or 10.1? How can you make this migration as smooth as possible, with as little disruption to your current rules sets and controls? What will change for your workflows, access policies, and monitoring of authorization risks?
Gary Prewett, senior SAP security consultant at NIMBL and SAP Professional Journal author, took readers' questions on SAP Access Control, including:
- What are the key differences in version 10.1 from 10.0? Any reasons for implementing 10.0 instead of 10.1?
- When upgrading from Access Control 5.3 to 10.1, what will happen to current rule sets/modifications as we add new 10.x rule set updates?
- For Access Controls in a BPC 10.x on NetWeaver scenario, what are challenges and best practices?
- What components must be implemented for a successful upgrade?
- What is implementation time for a separate BRM tool rollout? Should we implement it as part of AC launch?
SAPinsider: We'll be kicking off the live Q&A in just a few minutes, at 1pm Eastern. Post your questions at any time and follow all the discussion. Our moderator today is Financials Experts editor Gary Byrne, and taking questions is author and security expert Gary Prewett. Looking forward to your questions!
Gary Byrne, Financials Expert: Welcome to today’s Q&A on SAP Access Control 10.0 and 10.1. I’m Gary Byrne from SAP Experts and I’m looking forward to your questions today on moving to SAP Access Control. I’m pleased to have author and SAP security expert Gary Prewett taking your questions here today.
Gary Prewett is senior SAP security consultant at NIMBL, and the author of the article “How to Detect BPC Risk in SAP Access Control”. He is also contributor to the new SAP Professional Journal anthology “Mitigating Risk with SAP Access Control.”
Gary, thank you for joining us!
Gary Prewett, NIMBL: Thank you for having me!
Gary Byrne: Gary, before we get to the questions from readers on SAP Access Control 10.x migrations and troubleshooting, I wanted to kick off with this question about upgrading generally: From what I’ve seen, version 10.1 of the SAP Access Control plug-in is only supported on SAP NetWeaver 7.4.
What are the options to integrate older SAP NetWeaver stacks with an SAP Access Control 10.1 landscape?
Gary Prewett: Great question! The 10.1 plugin is not supported on older NetWeaver versions; that said, you can run the 10.0 version (I believe support pack 13 is requred but will confirm later).
Generally speaking, you can run the backward compatible 10.0 plugin on your satellite systems to support older NetWeaver and R/3 versions. Anything older than 4.6C is unsupported by the 10.0 plugin, unfortunately!
Gary Byrne: Thanks, Gary. I know we already have some questions waiting for you. We’ll let you get to those now.
Comment From Chris Anderson
If you're considering an Access Control upgrade, are there any reasons for implementing 10.0 instead of 10.1?
Gary Prewett: Hello Chris! Great question.
I can think of some good reasons to run 10.0 in lieu of 10.1, but not that many. The primary reason I can think of is if a customer is trying to install on an older NetWeaver version (they could be running in a shared landscape – not recommended, or only have older versions of NetWeaver certified to run in their production environments). 10.1 requires NetWeaver 7.4 SP04.
That said, there are a lot of bug fixes in 10.1, and they’ve spent a lot of time enhancing the user interface and on functionality improvements. For these reasons I’d strongly recommend going with 10.1 unless there is a compelling reason not to run NetWeaver 7.4
Comment From Guest
For an upgrade from Access Control 5.3 to 10.1, what will happen to current rule sets/modifications as we add new 10.x rule set updates?
Gary Prewett: This is a common question for users considering an upgrade. You definitely have the ability to export your existing rule set from 5.3 and import that into your 10.1 development system - the migration guide documents the steps needed (Analytics > GRC > Access Control > Release 10.1). You’ll want to make sure that you do this after your 10.1 solution configuration is completed (i.e., well after you BC Set activation which configures the SAP-delivered rule set). The good news is that rule set changes since then are released as incremental changes and should not overwrite your rule set, unless you happen to have caught these fixes independently. In that case you can always extract the incremental updates and validate against your existing rule set.
And if you’ve been applying the Access Risk rule update notes all along in your GRC 5.3 landscape, there should be no need to make rule set changes.
You can check these notes on rule set updates – look for a rule set release early in 2015:
1809810: GRC - Access Control - Access Risk Management Rule Update Q4, 2012
1960531: GRC - Access Control - Access Risk Management Rule Update Q4, 2013
Comment From Guest
We are a green field site and plan to implement GRC - Access Control 10.1. What are some of the pitfalls and challenges?
Gary Prewett: So, great question.
This depends on what's in scope for your implementation, but generally speaking your biggest challenges are more compliance-related than technical.
Common technical challenges are:
1) Sizing - make sure you spend the time to make sure your hardware is sized appropriately.
2) I'd recommend running dedicated hardware. A lot of customers with shared GRC landscapes run into compatibility issues with support packs, notes, etc. issues in a shared landscape.
3) firefighter log sync issues – this is a common problem you need to have roles assigned to firefighter users (or roles, in a role-based EAM scenario) with tcodes defined in the menu's. Granting a firefighter role with S_TCODE = "*" and no menu defined will not sync FF activity. You may need to spend some time redesigning scenarios.
If you are a public company, you may have noticed your external auditors questioning assumptions and findings, this will be extended to your access control environment. Common compliance challenges include:
1) Business requirements. You should definitely spend some time thinking through your business requirements prior to implementing. You may not have the concept of role owners or risk owners or process owners in your organization - be sure to think through these.
2) Change management. Any changes to your rule sets should be appropriately documented and ties to an existing control approved by the auditors, or ties to a risk assessment.
3) Think through your technical controls as well. A lot of your GRC configuration options can adversely impact your GRC-based controls. You probably want to include these in your audit reviews.
GRC config settings are discussed in detail in the Master Guide (available via the instguides link mentioned above).
Comment From Matt
Interested in question about implementing Access Controls in a BPC 10.x on NetWeaver scenario. What are best practices or potential problems here?
Gary Prewett: Your biggest challenges, in my opinion, are in defining the BPC-relevant SOD functions adequately. You'll want to spend some time mapping your BPC task profiles to the appropriate function. You'll also want to spend time documenting these changes to defend them to internal audit.
The other challenge is a sizing issue - flagging risks as cross-system has the potential to greatly increase the memory and storage requirements. Make sure to only flag those risk in scope as cross system. And if you get an ABAP stack dump after making rule set changes and running GRAC_GENERATE_RULES, you might want to go back and only flag in-scope high or medium risks as cross-system risks to save memory/disk storage space.
Comment From Felix Ojo
What are the components that must be implemented correctly to ensure a successful upgrade?
Gary Prewett: This depends on what's in scope - there are a lot of optional components that may be in scope for your scenario (TREX, Adobe Forms, Portal, and yes, Fiori). The components needed depend on your scope.
That said, I don't have any caveats to the current Install Guide available in the Service Marketplace.
The biggest is NetWeaver 7.4 SP04. Apart from that, you'll need the GRC foundation (GRCFND_A), assuming you already have PI_BASIS installed. You'll also need compatible GRCPINW plugins installed on all target systems.
Comment From P
What are the key differences in version 10.1 from 10.0?
Gary Prewett: Great question. If the question is "should I go with 10.0 vs. 10.1", I'd definitely recommend going to 10.1. If your question is "What's my business case to upgrade to 10.1?" that's trickier but generally speaking 10.1 offers:
1) Simplified end user experience for access request management
2) Significant improvements to the ARA/RAR/CC reporting - in my opinion, getting to root cause of an SOD issue is simpler (less time supporting end users).
3) Better dashboard reporting for management
and of course, I'd be remiss if I didn't add:
4) HANA support!
Comment From Guest
From a project planning perspective, what would be the normal implementation timing to complete the BRM tool as a later rollout vs. the extra time required to implement with first launch of AC?
Gary Prewett: I'm putting on my consultant hat here - it depends!
If this is being done in the context of an ERP implementation, BRM can simplify compliance requirements at the end of the project, but requires additional time and effort to the security function (and to business owners) during the project and can pose a significant risk to the project.
For that reason many customers with all four modules in-scope (EAM, ARA, ARM, and BRM) will implement the first three, but opt to postpone implementing BRM until after the project go-live as a phase 2.
Gary Byrne: We’re reaching the end of the hour, so first, I want to say thanks again to Gary Prewett of NIMBL for taking the time for these questions today.
Gary Prewett: Thank you Gary (Byrne!). Thanks again for having me.
I'll continue working through questions - if you have any follow up quesitons please feel free to contact me directly at email@example.com. Have a great afternoon everyone!
Comment From Guest
My company (currently on GRC 5.3) is considering upgrading to 10.x. Our current security design includes a large amount of enabler roles. This means that a user often requires two roles in order to be restricted to a specific org units (1 master single role containing the t-codes and 1 enabler role containing the Auth object values & activities).
I have heard that the enabler role concept can be problematic in GRC 10.x. Are you able to validate this statement? Will we need to redesign our security?
Gary Prewett: Great question.
To be honest, I have not implemented ARA with a customer having enabler roles (yet). We have, however, seen ARA do a great job in detecting cross-role risks (for example, FB50 with park might be in one role, but F_BKPF_BUK might have post access in another role, combining to give you access to the "Process Invoices" function).
ARA should do a great job detecting cross-role risks with enabler roles. That said, you should be able to test this in a lab or sandbox scenario. Please feel free to follow up with me directly at firstname.lastname@example.org if you have follow up questions or would like further clarification.
Comment From Federico
Does 10.1 have any new features to manage the conflict of visibility on OLAP/reporting systems like BW (e.g. highlight if a user could view data of company A and company B)?
Gary Prewett: This is a good question Frederico. I always say that anything is possible if you have access to great developers – but not everything is feasible!
The standard SAP Access Control ruleset generated when you activate your BC Sets during configuration has BW administrative and security functions built-in. For example, RSA1 is part of the ruleset and a user having this will be considered as having Basis Configuration access.
There are two problems with detecting the risk outlined in your scenario:
1. Access Control risks are focused on the ability to materially impact or modify financial data – from a Sarbanes Oxley perspective, having access to reports has no material impact. So any functions and risks you use to detect this risk would need to be developed by yourself.
2. Access Control org rules are focused on standard ERP fields – BUKRS (Company codes), WERKS (plants), etc. Assuming you are running BW version 7+, in the BW concept these are InfoObjects, and you restrict access via analysis authorizations.
Now, that said, you can absolutely set up custom functions to detect this – unfortunately you wouldn’t be able to leverage org rules in Access Control since they are not InfoObject aware. For example, if you had two analysis authorizations named ZCOMP0100 and ZCOMP0200 to restrict view access to company codes 0100 and 0200, respectively, you could then set up two functions, each having this analysis authorization: the action “RRMX”, the permission “S_RS_AUTH” and with the appropriate ZCOMP0100 or ZCOMP0200 value. Then you can combine these functions in a custom risk and set your risk level appropriately.
Whether or not this is feasible depends on your situation. I can’t imagine that this would be an effective way of detecting this type of risk long-term without incorporating the Access Control change into your existing BW change management process (i.e., once your custom risks are in place and effective, any new analysis authorization would need to trigger an appropriate function/risk change in your Access Control landscape).
Comment From Maria Piedra
We haven't applied the rule set updates because it would overwrite our changes. Is there a way to apply as an append and not as an overwrite?
Gary Prewett: Hello Maria! The short answer is yes. A slightly longer answer is, you can either make the modification manually by appending to your existing functions, or you can export your rules from Access Control 10.x using GRAC_DOWNLOAD_RULES, merge the updated values by adding them in Excel, and then re-importing them back in using GRAC_UPLOAD_RULES.
There is an excellent blog out on SNC by a former colleague of mine, Jonathon Pries, outlining in detail the process of exporting and merging with Excel. It’s titled “Download, Modify and Upload the Access Risk Analysis Rule Set in SAP Access Control 10.x.” This blog and walks you through this process of merging rule sets in Excel in detail.
Comment From Felix Ojo
Are there any changes to the workflow in 10.1 or is it possible to upload the existing workflow from the 5.3 tool?
There definitely significant changes in workflow now that Access Control has been migrated back to the ABAP stack - you can use standard ABAP MSMP workflows to create and maintain workflows and use BRF+ to initiate.
That said, you can still migrate existing workflow across – you need to export your existing data in The Configuration and Master Data Export in 5.3, and then import using transaction GRAC_WF_MIG in your Access Control 10.1 system. SAP’s “Migration Guide SAP Access Control from 3.0/5.3 to 10.1” outlines these steps in detail.
Comment From Guest
What new functionalities have been introduced in 10.1 version? My 5.3 system is on SP7 - is it necessary to update to the latest patch level for a Technical Upgrade or can we do a fresh install?
Gary Prewett: So this is a two-part question! First, feature differences. Generally speaking, in my opinion the 10.1 interface is more intuitive for end users than it is in 5.3. From an RAR (now ARA) perspective, the reports are easier to use and you have more reporting options (for example, you can select specific systems, groups, risk levels, and even rule sets, which you couldn’t do in 5.3). And exporting large ARA result sets to Excel is easer – large ARA reports can be downloaded as multiple files to overcome Excel’s 1 million-ish row limit. You also have the capability to drill into management-level reports to get to the relevant detail.
Another key feature for many 10.1 users is centralized firefighter (EAM) management and centralized CUP (ARM) - this can greatly simplify the request and approval process for many organizations with complex landscapes.
The fact that 10.1 is back on the ABAP stack also simplifies system operational management for many SAP customers. Your BASIS team should be very familiar supporting 10.1, with standardized ABAP tools available for background job monitoring, workflow troubleshooting, and database monitoring in place (where they might not be as familiar with these same functions in 5.3).
As for the second part of your question: technical upgrade. Unfortunately because of the aforementioned migration from the Java stack to the ABAP stack, there is no upgrade path from v5.3 to 10.x. You’ll need to migrate to a separate landscape, running NetWeaver 7.4 SP04 at a minimum. The good news your risk of downtime during a 5.3 to 10.1 migration is significantly lower than it would be in an upgrade from 5.2 or 4.0 (which is supported); you can, with some planning on installing compatible plugin versions, run both 5.3 and 10.1 concurrently.
Comment From Bill Weber
Gary, we are in the process of upgrading our Support Packs for Access Control 10.0. As we've applied the Support Packs, the risk simulation function seems to have been broken. If we assign a conflicting t-code, it will report but if we do the simulation before assignment it will come out as no conflicts. Have you heard of this before and, if so, how was it fixed? Thanks.
Gary Prewett: Hello Bill. Fortunately (or unfortunately, depending on your perspective), I have not had a customer run into this specific issue. It doesn’t look like many have – I didn’t see anything in a notes search. You may want to pose this question to the community at large, or open a note with SAP.
Comment From S.Quinn@Hopkins
Any recommendations for managing Action Usage data? Ours is 28.6M records and growing. We had to add an index and ask SAP to make it standard. What are best practices around this large volume area? Oh, and my question is about GRC AC 10.0 (upgraded from 5 last year).
Gary Prewett: Unfortunately, there is no standard report or transaction to archive data in this table, and there is no archiving object available in SARA to manage this data. This unfortunately may be another request you have to submit to SAP. An in order to satisfy this request and meet customer requirements, they may need to split this table and store the user action usage and firefighter transactional activity in separate tables, making it a more complex enhancement.
Comment From Felix Ojo
What are Organization Rules and how does this work when defining risks and mitigating controls?
Gary Prewett: Hello Felix!
Org levels have a limited use case – in some organizations, a person might be able to process invoices for company A and create vendors in Company B. In that scenario, without an org role the user would be flagged as having a high risk separation of duties issue – they can enter invoices and create vendors. However, since they can’t do both in either company, this is a false positive.
In this case, you can create an org rule to suppress this false positive in future reports.
Comment From Guest
Is there any documentation that links HR triggers and workflow configuration?
Gary Prewett: There is! Just in case you don’t have your HR trigger defined - in SPRO, navigate in the SAP Reference IMG to Governance, Risk and Compliance > Access Control > Maintain AC Applications and BRFPlus Function Mapping. You also need to configure your plugin in your HR system to enable HR triggers.
You also need a functional workflow created (in the SAP Reference IMG navigate to Governance, Risk and Compliance > Access Control > Workflow for Access Control > Maintain MSMP Workflows – and you should have at least 10 SAP_delivered workflows to work with).
If you already have your initiator and workflow created – I’d point you to a great wiki article out there on SCN on linking that initiator to a workflow created by Shaily Kulshreshtha, titled “BRF plus Flat Rule – GRC Integration.”
I hope this helps!
Comment From Ravi
For GRC 10.1, we have installed the GRC plug-in GRCPINW version V1100_731 for SAP ECC SAP_BASIS 740. We also want to use GRC AC 10.1 EAM with SAP Solution Manager. SAP Solution manager is on SAP_BASIS 702 and the corresponding GRCPINW is V1000_700.
So my question is whether this version of the plug-in compatible with GRC 10.1?
Or do we want to bring SAP Solution Manager to SAP_BASIS 740 and then install V1100_731?
Gary Prewett: Ravi, thanks for this question. You should be able to stay with V1000_700 – this plugin is compatible with 10.1, as long as you’re running SP 10 of V1000_700 (or higher).
There are a couple of notes available for light reading that relate to this scenario:
- 1590030 – GRC 10.0, 10.1 and AC 5.3 coexistence
- 1680268 – Compatibility of Access Control Packages
SAPinsider: Thanks everyone for joining today’s Q&A! There's more to come in the transcript, and we'll alert you as soon as it is available.
For more on Access Control 10.x, you can read Gary Prewett’s article on BPC and Access Control, as well as other SAP Professional Journal pieces, in the newly published SAP Professional Journal anthology Mitigate Risk with SAP Access Control.
This is our last Q&A of 2014, and thanks again to Gary Prewett of NIMBL and our moderator, Gary Byrne of SAP Experts, for taking the time for these questions today. Happy holidays and all the best in the new year!