Migration from RBE data to GRC Action Usage
Sometimes you have an idea that resonates with others but you do not realize the complete requirements until you have exactly what you asked for. Such is the case when GRC Access Control 10 was being developed. I made a request to have the SAP user statistics data summarized into GRC Access Control along with some analysis reports. At the time SAP supported an older process of Reverse Business Engineering (RBE) functionality which we used to support multiple metrics. These reports included inactive transactions, unused roles, transactions most used, and more. Later our business provided requirements using the RBE data to automatically remove roles when a user had not executed a transaction within a role for a specific number of days. We also used this for our quarterly user access review and SOD analysis to determine if roles were no longer relevant or if an SOD violation could be resolved through the removal of an inactive role assignment.
To perform our consolidated user access review we manually exported the RBE data into a Microsoft Access database from each individual SAP system. Some companies also do this by sending the data directly into a BW InfoCube. Once we had this consolidated data we could fulfill the user metrics and related reporting requirements. Since the SAP statistics data is summarized into monthly periods, we only performed this process once a month. Although the batch jobs were scheduled to create the RBE data files, there was still a day of work to summarize all of our production systems into the Access database.
With the enhancements coming in GRC 10 and the delivery of several of our influence items, we built a business case to become a GRC Access Control ramp-up customer. Fortunately, SAP delivered the Action Usage functionality which imports the transactional activity into GRC Access Control. This was exactly what we asked for but, unfortunately not the best solution. We started out performing the same process of exporting data to MS Access but only from GRC.
SAP scheduled a follow up meeting to see how we liked the new functionality. We shared our metrics reporting, user access review process, role metrics details and SOD reduction efforts. Having consolidated data helped us but it was not the best long term solution if we still needed to perform processing in MS Access. We documented detailed requirements and these were delivered in GRC 10.1.
I now sympathize with our business users who provide us functionality requests. Sometimes you do not know phase 2 requirements until you have actually used a system. In the past I have prototyped solutions before documenting the requirements. Sharing story boards and high level process flows would have been helpful here. Once you have an improvement idea, you need to take the next step and document the requirements. When someone only has an idea it leaves room for interpretation. When there are detailed requirements, there are tangible deliverables. Now that we have been using the Action Usage process for multiple GRC processes, additional requirements are being noted.
Across the many GRC 10 and 10.1 implementations there must be other customers that also use the Action Usage data. What are some ways that you are currently using it? Do you use it for UAR? Remediation of SOD risks? Validation before applying a mitigating control? Forensic activity? If you are using this data, how would you improve the process? What reports or functions do you think still need additional development? I am looking forward to your feedback.
"Sometimes you have an idea that resonates with others but you do not realize the complete requirements until you have exactly what you asked for. "
AMEN!!! hahaha
Sounds like you had the perfect opportunity to put some "design thinking" into action. Might have saved you some "coming in next release" waiting.
adding to that, there needs to be a balance in providing requirements without being in solution mode. Sometimes, we limit the possibility of the solution and approach if we put forward the idea and include the technical specs
Part challenge here is a lot of design and implementation is from a project point of view. The feedback and validation needs to come from the support teams who have to perform the repetitive operational activities relating to auditing and monitoring.
I've never been on a customer site where I haven't built an access database to collate security/grc information.
I initially thought, here is the big improvement idea for all users of GRC. Open the idea up for crowdsourcing of the requirements and the requested functionality will be better than one persons dream. The crowdsourcing resulted in support from many customers for the idea but no detailed requirements. I too was concerned that if the requirements were too specific you only get what you ask for. In the end the requested idea was the delivered requirements. Live and learn. I still believe in Influence and customer connection activities as SAP is currently working on 60+ enhancements to GRC Access Control.
I think you hit the nail in the head. Everyone is using the data, but as you said - most are exporting the data and manipulating the data as required. Other companies are buying additional products that integrate with GRC to get the reports that they need, or building their own reports.
In all honesty, I think anyone can take a look any of the Access Risk Analysis reports and find ways to improve them.
A couple examples of improvements:
1. Some reports give you a Risk Id, and you have no option to add a Risk Description column.
2. Do we really need the "Rule" Column in "Remediation View"? How nice of a report would it be if that column could be removed?
3. Why can't we export data from remediation view easily?
4. When you add or remove a column in a report, the reports should "refresh" to remove duplicate line items.
Hello, I am currently using the Action Usage for reverse engineering Job position definitions.
There are no Job Positions here, so I need to remove a "consultant role" (basically a SAP_ALL) and map the tcodes into already available "end-users" roles.
Not only this, but I need to propose what would be the best definition for "Job Positions" given the available end-user roles and the usage.
The level of granularity of the security definition is médium I would say.
On the other had, your GRACACTUSAGE table is about 30 Gb or ~30 million rows, so it is very hard to manipulate the data....
As a global fortune 100 company our table was a little larger than that. We have been working with SAP on the archiving process since we had nearly 2 BILLION records. With the new archiving process we are down to nearly 150 million records.