Building Your RBAC
Compliance Policies for
SOX, HIPAA, FERC etc…
Companies that face the need to audit their IT access rights and build a set a business policies compliance rules, are facing a huge challenge.
The need may come from different sources:
Management wants to apply policies
Internal Auditors
External Auditors
Stock market regulations (SOX)
and more..
The issues that you may face are:
1. The data (enterprise access rights repository) is not available
2. If there is data, it may be partial
3. Policies are not defined yet, or only few of them
4. Policies are defined, but in a language that should be translated to analytic software
5. Company politics prevents from defining good policies
6. and more..
However, when you have defined your first set of rules, and if you have your database ready, you can start your compliance or SOX project and apply the rules.
What type of rules can you define ?
Here is the list of common rules:
- Only employees that work in departments finance or HR, “may have access to” to role “PeopleSoft HR”.
In this rule we have 2 type of objects, users & role. And there is a restriction defined between the objects.
- People that have access to role “Tetra Development” “must have access” to role “Tetra Testing”.
In this example we have relations between roles.
- People can not access to more than 1 of this roles: “write a check”, “approve a check”, “sign a check”, “pay a check” (segregation to duty)
You must have the ability to define and code any type of business rule and then, import/export rules into your compliance system.
Your source rules are usually written in a spread sheet in which you define your restrictions.
Example of role/role restriction table, where the X represents that user can not have access to the 2 roles:
Workflow: The list of exceptions can be distributed to managers that will be required to review and if needed, approve the violations
For more information, questions or ideas - send your comments
Ilan Sharoni
http://www.eurekify.com/
Compliance Policies for
SOX, HIPAA, FERC etc…
Companies that face the need to audit their IT access rights and build a set a business policies compliance rules, are facing a huge challenge.
The need may come from different sources:
Management wants to apply policies
Internal Auditors
External Auditors
Stock market regulations (SOX)
and more..
The issues that you may face are:
1. The data (enterprise access rights repository) is not available
2. If there is data, it may be partial
3. Policies are not defined yet, or only few of them
4. Policies are defined, but in a language that should be translated to analytic software
5. Company politics prevents from defining good policies
6. and more..
However, when you have defined your first set of rules, and if you have your database ready, you can start your compliance or SOX project and apply the rules.
What type of rules can you define ?
Here is the list of common rules:
- Only employees that work in departments finance or HR, “may have access to” to role “PeopleSoft HR”.
In this rule we have 2 type of objects, users & role. And there is a restriction defined between the objects.
- People that have access to role “Tetra Development” “must have access” to role “Tetra Testing”.
In this example we have relations between roles.
- People can not access to more than 1 of this roles: “write a check”, “approve a check”, “sign a check”, “pay a check” (segregation to duty)
You must have the ability to define and code any type of business rule and then, import/export rules into your compliance system.
Your source rules are usually written in a spread sheet in which you define your restrictions.
Example of role/role restriction table, where the X represents that user can not have access to the 2 roles:
In the example above:
User that has access to Role A can not have access to Role B
Etc…
The next step is to upload this into your compliance analytics engine.
Most compliance analytics engine support XML format and the conversion steps are easy and may take 1-4 hours.
Tentative steps:
Convert the above XLS table into a csv file , one line per rule:
· Role A, Role B, not allowed
· Role A, Role D, not allowed
· Role B, Role C, not allowed
· Role C, Role D, not allowed
· Convert the CSV table into XML format
· Load the XML file into your analytics engine
· Execute the check and review the results
Reports:
You may use a set of reports to track your rules from a high level view, into a detailed list.
An example of high level reports:
User that has access to Role A can not have access to Role B
Etc…
The next step is to upload this into your compliance analytics engine.
Most compliance analytics engine support XML format and the conversion steps are easy and may take 1-4 hours.
Tentative steps:
Convert the above XLS table into a csv file , one line per rule:
· Role A, Role B, not allowed
· Role A, Role D, not allowed
· Role B, Role C, not allowed
· Role C, Role D, not allowed
· Convert the CSV table into XML format
· Load the XML file into your analytics engine
· Execute the check and review the results
Reports:
You may use a set of reports to track your rules from a high level view, into a detailed list.
An example of high level reports:
For more information, questions or ideas - send your comments
Ilan Sharoni
http://www.eurekify.com/
