In his session at GRC 2013, compliance and security Marc Jackson makes the case for auditing your SAP GRC systems – something not to be overlooked in your system audits.
In a recent online Q&A on Insider Learning Network, Turnkey Consulting's Marc Jackson took questions on GRC audits, useful transactions and tools, auditing performance and transport paths, the affect of the ABAP stack now in release 10.0, Firefighter audits, and other topics.
Read the Q&A in our Compliance Forum, or review our edited transcript here:
Matt Moore, GRC 2013: Welcome to today's forum on strategies and tools to audit your SAP GRC system. I’m pleased that we have Marc Jackson from Turnkey Consulting here to take your questions.
Marc is a Manager with Turnkey and is responsible for delivering and developing their Audit and Risk Management services.
Marc will also be speaking at GRC 2013 in Amsterdam in June on the topics of auditing GRC systems, AB&C compliance, and SoD management.
Welcome, Marc, and thanks very much for joining us today! It was great to have you as a speaker at GRC 2013 in Las Vegas last month. I see a number of advance questions here already, so I’ll let you tackle those.
Marc Jackson, Turnkey Consulting: Hi Matt,
Thanks for the introduction, and welcome to everyone for my Q&A session on auditing GRC systems.
I see there has been quite a bit of activity on the posting already so I'll make a start on replying straight away.
Thanks,
Marc
Ken Murphy: Hi Marc, can you suggest any steps to simplify audits of change management/transport paths? Thanks, Ken.
Marc Jackson: Hi Ken,
This is a good starter, as Change Management is just as significant for GRC systems as it is for any other SAP systems in your landscape.
If unauthorised changes are taking place in your GRC system then this could undermine the integrity of the controls and compliance related data coming out of it.
The key thing to remember around the transport path is that your GRC system should ideally have a 3-tier landscape - DEV, QA & PROD. Therefore, a quick way to check this in your system is to use transaction STMS and then hit the "Transport Routes" icon. This will provide you with a graphical illustration of the GRC systems defined as part of the transport route.
There are many other areas of Change Management which can and should be covered as part of your GRC review, such as the procedural elements which are followed when making changes to the system (e.g. change request procedure, testing steps, migration to production approval etc). The procedure should be tested using traditional sampling techniques.
You should also look for any GRC-related changes which have been made directly in the QA or production environments rather than via the Dev system (use table E070 and look at the system identifier in the initial 3 characters of the transport request name).
There's much more to talk about but I hope that helps as a starter!
malinirao: How to audit SAP GRC Process controls? What are the things to check apart from the controls library?
Marc Jackson: Hi Malinirao,
GRC Process Controls (PC) is quite a unique system to audit but there are some specific parts which need a certain level of attention.
The master data should be checked for appropriateness and completeness (i.e. has your organisation's control framework been reflected accurately within the tool, have the relevant risks been assigned to the correct sub-processes, control and control objectives etc).
However, if your organisation is using PC to automatically monitor the operating effectiveness of controls then you must get assurance over the logic and data held within the related business rules and data sources. The primary purpose of this is to ensure they will accurately reflect the status of the control it is monitoring.
You can do this by looking in the Rule Set-up work area, and select business rules within the Continuous Monitoring section.
AlexanderHartwig: Hi,
I have some questions on GRC v10.0. My clients are now moving into v10.0 and I would like to know what are the key differences between AC5.3 and v10.0 and what would be the implications to an audit.
Are there additional risks that would need to be addressed as a result of the version (and platform) changes?
Marc Jackson: Hi Alexander,
The big difference between the 2 versions is that 10.0 uses an ABAP stack, which actually makes auditing AC easier and reduces the risk in my view!
For example, in 10.0 all non master data-related changes should use the standard SAP Transport Management System. So this means, as is the case in standard ECC systems, that a change can be made in the development system and be migrated through all of the other GRC systems along the transport path in a controlled manner. No need to manually re-apply everything which can easily lead to mistakes, as well as providing some standard tools to help protect the process.
It also means that access is assigned using standard PFCG roles as well. Therefore, it makes it easier to review and understand who has access to specific GRC functionality using traditional techniques such as SUIM reports, or even using the ruleset itself to monitor GRC access.
Another big difference is the integration between the GRC applications. So you might want to check if AC & PC are being used in this way (e.g. managing mitigating controls in PC etc).
malinirao:
- What are the available tools to audit SAP GRC?
- What are the best practices that need to be followed to ensure SAP GRC is compliant with the organization security policies and procedures?
Marc Jackson: Hi Malinirao,There aren't any specific dedicated tools to use as such when auditing GRC systems. The tools which you can use either exist in the GRC back-end system itself (i.e. reporting tools such as SUIM, displaying relevant tables, displaying PFCG, SU01d etc.)Or you should use the tools and techniques available in the GRC system for the purposes of auditing it (e.g. defining GRC-specific sensitive access in your ruleset so you can report against it, using Process Control reports to identify any risks which haven't got a control assigned against them in the control framework, digging into the business rules to understand the logic and whether it would accurately identify a control deficiency or not etc.).You can also use traditional interview techniques as well and speak to the people that own and maintain these systems.
charukesh: Hi Marc,What are the best practices for auditing the SOD rule sets?If a landscape has multiple systems like ECC, SRM , HR and no Logical Systems/Cross-systems are defined, how do we highlight the inefficiencies?Best regards,CharukeshMarc Jackson: Hi Charukesh,When auditing the GRC rulesets there are a few things to keep in mind. The ruleset is there to define those access risks that are deemed significant to the business and translates them into SAP authorizations, so that offending users can be identified as part of detective or preventative controls.Therefore, the identification of SOD & SA risks is heavily dependent upon accuracy and completeness of the ruleset. So you need to review the ruleset content, which includes:
- Risks
- Functions
- Actions
- Permissions
Now, you won't be able to say on your own whether everything is OK or not. You also need to talk to the relevant people to understand the process taken during construction of the ruleset to ensure that the right people were included in the design workshops, so that the risks are relevant to the organisation and not just out-of-the-box.
You should also ensure custom functionality has been included where it could help contribute towards a risk.
I'm not sure I completely understand the 2nd part of your question - could you please elaborate? Thanks.
charukesh: Thanks for your reply Marc.
Let me rephrase the question. Maybe now I am asking a slightly different question:
If 2 systems connected to RAR have conflicting functions (Analysis Scope for function is set to cross system) and if no cross system rules are generated, will the system detect/show correct results?
Marc Jackson: Hi Charukesh,
Thanks for your follow-up post.
Regarding your question, I haven't actually used RAR with the cross-system function as yet, but logically I would expect that if no cross system rules are generated then a 'no access rule' selected error would result. However, I can't confirm this for sure based on my lack of exposure to these situations.
Apologies I couldn't be more conclusive for you, but hopefully it's provided a little bit of help for you.
Thanks,
Marc
D.J.: We will be upgrading from GRC v5.3 to v10 later in the year. What is the best approach for migrating our rulesets, workflows, and settings from one version to another? Any other tips for upgrading?
Marc Jackson: Hi DJ,
This question is a little "off topic" as it's related to GRC upgrades rather than tips and techniques to audit your GRC system. Therefore, it's a little bit out of my own subject area and I don't want to give you any false advice.
However, I have colleagues who would be able to provide you with a full and accurate answer to these upgrade queries. Could you please email one or both of the following contacts: Simon Persin Kehind Eseyinkehinde.eseyin@turnkeyconsulting.com
Thanks,
Marc
JuneChandler: Hi Marc, In order to fully audit the usage of Fire Fighter in GRC10 is it possible to track from the FF log report right through the documents posted or data changed in the back end system?
We are in the process of upgrading from 5.3 and this is one of our key challenges as we end up running numerous reports in our backend ECC system to identify the impact of the FF usage.
Thanks, June
Marc Jackson: Hi June,
This is quite a common problem, so you're not alone with your challenges! Unfortunately, you are going to encounter the same problems in 10.0 as you're currently experiencing in 5.3.
The good thing is that SAP are aware of these limitations and are currently trying to enhance this transparency within the audit log of FF usage report to more explicitly tell you what actions have actually been performed with the FF user.
I hope that helps ease your frustrations a little. Although it's encouraging you are being so diligent!
Thanks.
JuneChandler: Hi Marc,
Thanks for the response. It's great to hear that SAP are aware and looking into it. I will keep an eye out for developments from them. Thanks for answering the questions. Some extremely useful information for us.
Kind Regards, June
Dave Hannon: Marc, thanks for taking our questions today.
A person I spoke with recently brought up the performance of their GRC system, so I'm wondering if GRC auditing can have any implication on the overall performance of the GRC system, for better or worse? Thanks.
Marc Jackson: Hi Dave,
That's a good question to ask. Because the common techniques which you will be using to audit your GRC system tend to be quite traditional methods such as running reports, or displaying tables in the back-end, or checking parameter settings etc., then there is no impact at all.
Even when you're actually doing stuff in the front-end, it tends to be navigating around to relevant parts of the tool to check master data, ruleset content, business rule logic, assignment of mitigating controls etc., all of which require no "heavy lifting" on system performance.
The only impact I can foresee is when you are using the ruleset to run risk analysis reports as part of your investigation, but these can be done smartly to avoid any detrimental impact (e.g., running it for targeted user groups at a time, running them in the background, etc.).
It might also mean you may need to set up an extra user or two on your GRC system for the auditors to use, unless you already have such users set up.
Thanks,
Marc
Matt Moore: Thanks to all who posted questions and followed the discussion!
A full summary of all the questions will be available here in the Compliance Forum. And of course, I invite you to our annual GRC 2013 conference in Amsterdam, June 11-13.
Marc will present three sessions, and we hope you have the chance to see at least one of them in person!
You can get updates on the conference by following me on Twitter at @mattmoorewis, and you can discuss the event using the hashtag #grc2013
And finally, thank you to Turnkey Consulting’s Marc Jackson for taking the time to respond to these questions.
Marc Jackson: Thanks Matt. I'd also like to quickly thank all of you for posting questions or following the session. Please don't hesitate to contact me if you have any further questions on this topic area. You can e-mail me at marc.jackson@turnkeyconsulting.commarc.jackson@turnkeyconsulting.com
Thanks,
Marc
