Insider Fraud – Segregation of Duties (SoD)
In last Blog Abhishek has discussed about how we can use Oracle Vault to fight with Insider fraud. But is that all? Will that be able to tackle all the problems of insider fraud? What about the stealing of personal information of customer? What about use of logs, or in-process transaction? Oracle Data vault will solve the problem of information stored in database but other systems like servers, file system, storage, logs are still vulnerable and can be attacked by insider fraud. To avoid these glitches of the system we need to design our system by segregating the duties.
What is segregation of Duties? Segregation of duties (SoD) is an internal control designed to prevent error and fraud by ensuring that at least two individuals are responsible for the different parts of any task.
SoD involves breaking down tasks that might reasonably be completed by a single individual into multiple tasks so that no one person is solely in control. Financial management, for example, is an administrative area in which both fraud and error are risks. A common segregation of duties for financial management is to have one person responsible for the accounting part of the job and someone else responsible for distribution of the same.
Although it improves security, breaking tasks down into separate components can sometime negatively impact business efficiency and increase costs, complexity and staffing requirements. But in IT industry, financial system where security has prime importance and these are most vulnerable. Also it contains the information/asset of customer, system provider is only the custodian of asset which belong to different stakeholders.
Now let?s take the typical example of a three tier architecture deployment of application where all the layers has some users which will have their own roles and responsibilities.
In the above system few roles are shown, let?s see in details.
|Users||Roles||Access to system|
|Administrator||Administrative Roles, Creation of users, assigning roles, managing admin tasks.||Read, Write Execute, Owner Role, Role Permissions|
|Application users||These users are responsible for the setup and patch of application they has read write and execute rights at specific folders and applications||Read, Write, Execute on application and it’s folders but not on log folders that will be provided by applications only|
|Backup Users||These users are responsible for the backup of system, logs, data, files etc.||Backup permissions for logs, application, database no write and no execute permission.|
|Log users||These users analyse the logs for various system patterns||read logs and and it’s folders|
|Support Users (L1, L2, L3)||These users support application for any issues and have limited access to applications||Read logs, system health, system parameters collections and execute the scripts commands for support activity|
|Operator Users||These users have specific roles to run the applications but can not control entire system||Execute and write permission of application and some special folders|
|Security Admin||Security Admins defines the roles, provide the access to roles, etc||Access for Read, Write and execute command for users and roles no access to application, database, and logs|
|Auditors||Audits the system for activities, logs, database, data, files changes etc.||Access for read, application logs, applications, database, files user activity, system logs, user logs etc.|
If we decide the different roles to different user and without overlapping responsibilities and duties we can control and have checks on various users. This SoD should be applied to all the equipment in system like servers, database, network elements, storage, etc.
By this way we can control the fraud carried out by internal users. Typically banks, telecoms, payments and other similar systems where customer data is of prime importance should apply proper SOD(above is just to explain can not be taken as baseline).
by Daya Shanker