- User sends email to IT requesting additional authorization to perform activity.
- IT transfers request to relevant manager, who approves required authorization (at times without even inspecting the real intention of the request).
- IT allocates the required authorization to user.
Check out the following case:
- John from the finance department requests an additional authorization for the purpose of changing a vendor’s details.
- Barbara from IT receives the request (which makes sense to her) and she grants John the required authorization.
- John receives an email from Barbara informing him that he was granted the requested authorization.
John is very happy. The auditor is not.
What Upset the Auditor?
Flaws! Auditors do not like potential for flaws and misuse in the authorization request process.
First, the request was made by email and not via an automated workflow tool – the use of emails increases the chances of requests falling between the cracks.
Second, the process cannot be easily monitored and therefore is unlikely to improve accordingly.
Third, Barbara, who happens to be friendly with John, approved his request without further looking into the reason of the request. Even if John is totally honest, a hacker might pretend to be John, taking advantage of the fact that John is friendly with Barbara, and attempt to perform a fraud using John’s account.
Finally, the sensitivity rate of the request was not taken into account. If a request is for a sensitive activity (like changing vendor details) or entails a violation of SoD (Segregation of Duties) rules, at least one additional approval should be required, such as by the security team or SoD manager.
What Would Please the Auditor?
Responsibility! Auditors like a clear process with the right responsible owner. Clearly in this case, Barbara decided to grant a user an authorization based on a good feeling or friendship, and this is exactly what auditors do not like. We do not recommend that IT personnel be responsible for granting authorizations. The way we perceive things: business personnel should approve granting authorizations for business activities; IT should perform the task; security teams should monitor the task.
So what could and should have been performed differently? The process needs to be automated as much as possible, allowing further investigations when required.
I want to suggest the following alternative:
- John requests additional authorization for changing a vendor’s details.
- His direct manager approves the request.
- A sensitivity check is performed, and since changing a vendor’s details is considered a sensitive activity, additional approval is required from the financial data owner.
- A reasonability check (explained below) is performed, based on John’s business profile.
- IT person in charge of the finance module chooses the required authorization.
- A SoD check is performed; as John is able to open invoices changing vendor details, he is also violating a SoD rule. In such a case, additional approval is required from the risk assessment manager.
- The system grants the required authorization to John and notifies him accordingly. Alternatively, the system opens a task for granting John the authorization, and IT closes it after updating John’s authorization status.
This process is fully automated and can be re-inspected anytime. This kind of process would surely please your auditors.
What is it and why should you perform it? A reasonability check is a unique technique for identifying potential business risk situations at a dynamic level. Basically, a set of tests and business rules are applied to determine whether a request for a specific authorization is reasonable or not. Even if one test fails (indicating that the authorization request is not reasonable), then additional approval is required by the security team.
Reasonability Checks – Examples
- A user should request authorizations within the practical usage zone. If a user who normally executes financial activities asks for authorizations to perform activities in the arena of human resources, additional approval will be required.
- Request for additional authorization should be submitted from the user’s regular computer. If a request was submitted from a totally different segment of computers (such as from a different branch of the company), this will demand another hierarchy of approval.
Remember, identifying risky situations is critical from fraud-detection point-of-view. Use a smart automated tool and keep your auditors happy.