The GRC journey continues… I’m trying to figure out how to effectively implement the Audit and Evidence collection capabilities in eramba using one control as an example:
We have a control activity that says we review user access to key systems at least annually. Of course we have many “key systems”, and I conduct these reviews by collecting users lists and using eramba’s Account Reviews tool.
I’m thinking I want to use eramba’s Audit function to reach out to various system owners on a regular basis to collect the user lists, which I can then use to conduct the reviews (I collect many user lists automatically using scripts, but a few I have to collect from a sys admin manually).
The problem I’m seeing is I need to collect “evidence” (i.e. user lists) from different people for each system throughout the year, so I don’t think I want to populate the audit evidence owner field with a bunch of names, or everyone will get every request throughout the year.
I also don’t know that I want to add a new control for each system, as the control is the same, it applies to each of the systems. Multiply the control by 30-40+ systems?
What am I doing wrong with this approach? How have others approached this kind of issue (both from a process perspective, and with eramba)?
in eramba “world” you would then have one or more “Control Catalogue / Internal Controls” that describe each system review:
Linux account Reviews
SAP Application Administrator Account Review
Remember - controls are the “solution” to “problems” , you should again in eramba little world link those controls to what originates teh problem…a risk, a compliance requirement, a data flow.
You refer to Security Operations / Account reviews i guess ? that functionality will collect evidence from the output of your scripts (that do the actual collection of user accounts) and store the review records. On the Internal Control side i would typically assign the audit to myself and simply complete the audit records with the result of the review from Security Operations / Account reviews
The only reason you create a control is to attempt solving a problem … if the problem is the same across 15 system (risk of unuathorized access in the form of a risk in eramba or a compliance requirement) then you most likely can do with 1 solution … which is great you kill two birds with one stone … BUT is not always the case, look at demo-e.eramba.org , we have multiple account reviews:
the reason for having more than one control could be:
that is that the procedure for testing each one of this system is VERY different
you want to highlight accountability for handling account assignments (say each system has its own provisioning process and you want to test each process)
putting all systems reviews into 1 control would not resemble the reaality of the control…say you have one control to test 5 systems account reviews … during the testing one out of five is wrong … you call the control “pass” or “fail” ? … eramba is binary when it comes to testing results
generality speaking more controls are more time and that costs more money:
hope this helps! your questions are good in the sense that many times i see people is not asking this sort of things which are key to make an efficient grc design in a tool like eramba.
Actually, no. I’m referring here to the audit or maintenance of a control. In one example I need to manually collect a user list from one system as it isn’t currently possible to automate, so I was thinking of using notifications to reach out to the audit evidence owner to get them to upload the user list to me, so I can take it and initiate the review with Account Reviews. That’s where I saw the problem.
That would appear to be the right answer, I was just hoping it wouldn’t come to that, because as you said, it’s more work, more time, more money. I will review the list of guidelines you shared to see if I can reasonably limited the number of controls vs the number of systems.
You’re telling me what I think I already knew, but perhaps didn’t want to accept!
