2.7 KiB
Source PDF download Article in ISACA Journal Author: Stefano Ferroni Date Published: 19 May 2016 Retrieved: July 13, 2022
See also:
The most widely adopted SoD model requires separation between authorization (AUT), custody (CUS), recording (REC) and verification (VER).
Ideally, these duties are performed by different persons (or parties).
This model is consistent with the COBIT 5 view of SoD issues (DSS06.03).
This can be hard, or even impossible to implement in practice.
Often, agents may perform different duties on the same assets as long as they are authorized by a second person. An example is an accounts payable team receiving invoices (REC) and creating payment orders (CUS) after authorization by the manager (AUT).
In the example where an online recording operation creates an automatic payment, such segregation is simply impossible to achieve.
An SOD framework should also make a distinction between management duties (e.g., granting and revoking rights, reporting, and managing exceptions) and governance duties (evaluating, directing and monitoring SoD rules and practices).
Risk assessment
For risk assessment, a matrix can be constructed for every combination of conflicting duties, with associated risk scenario examples:
Scoping rules
- Asset Scoping: different duties may be performed by the same person (or team), as long as they do not involve the same asset (or set of assets).
- Process scoping: for any asset (or set of assets), processes that transform the status of that asset must be segregated.
Role engineering
For defining role-based privileges, as used in Role-based Access Control (RBAC) top-down and bottom-up approaches are used. Top-down means identifying the necessary privileges from the job description, bottom-up means inferring roles by examining existing permissions on systems and applications (also known as role mining).
