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:

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:

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/

Survey your access rights –
Get ready for RBAC,
Identity Auditing &
SOX projects

A CSO & CTO that I worked with were curios to learn about the level of the access rights problems in their systems. As they were not aware of any tools that enable them to actually measure the severity and the magnitude of the problem, they needed to refer to external advisors that could tell them of previous experiences about their systems.

If you are reading this article, you are probably wondering what are the best practice steps one should take, prior throwing $100K over a small IdM or RBAC deployment (services only), $2M of services and more…

My best practice on this issue is to survey your system, using your data, and getting analysis of:

• How much access rights in your business are wrong, or out of business needs. (Industry standard is 40% of your total access rights)?
• How may users are collectors (Users that collect privileges) . (Industry standard is 10% of your total named users)?
• How many resources / applications have suspected access?
  What is the best approach for role engineering?
• How long will it take for my engineers to build roles & certify them? (The roles are discovered by a bottom up algorithm and takes 1-2 days.)
• Can I quickly build and apply business policies?
• and much more…
  
  Keep in mind that this survey will take you out of the dark and into the light, since the analysis will be on YOUR DATA. The information will no longer be unfamiliar. You will be in CONTROL to ask the questions and understand the findings.
  
  As a decision maker, you will be amazed to hear that you can have your system surveyed in 5-10 days. Usually, 1-2 major systems will be surveyed and the rest will be left to the actual project.
  
  The results will be presented from high level pie charts – management level, and detailed reports and examples for the security managers.
  
  For more information about best practices: http://csrc.nist.gov/rbac/RBAC-case-studies.html
  
  Examples of a high level presentation:
  The left pie chart represents the user’s analysis, and shows how many users are considered collectors, how many have suspected access rights, how many are in the system, but not in your HR file etc.
  The right pie chart does a similar analysis to your resources and applications
  
  
  
  
  
  
  
  
  
  
  
  
  
  An example of Role Engineering Analysis report:
  
  This report shows the access rights coverage by different role eng techniques. The roles are discovered by a bottom up algorithm and takes 1-2 days.
  
  
  
  
  
  
  
  
  For more information, questions or ideas - send me your comments
  Ilan Sharoni
  isharoni@eurekify.com
  http://www.eurekify.com/

Role Engineering & Auditing– Proof of concept / Survey

Many security administrators and managers are required to meet industry security standards, together with external or internal auditing compliance guidance.

It is highly recommended that before you decide what your approach is and what are the tools/solutions that you plan to purchase in order to address this challenge, to consult with experts that were involved in many Identity Auditing & RBAC projects and learn from their experiences.

Once you have researched, it is recommended that you test the solution in your labs, and get a true feel of how the solution addresses your business needs, performance, both with short and long term planning.

This engagement should take 5-10 working days. From my experience, if you have in your business up to 40000 employees, 5 days will be enough.

I would like to call this POC, a Survey, due to the fact that during these 5 days, you will actually be testing the product on your real data. Survey your data and experience how that product will work in production.

As part of the Survey, you should analyze 1-2 of the major systems (e.g., mainframe, directory, ERP, etc.), over a period of 5-10 days, and plan to check for the following:

1. Get an enterprise view of users-privileges, and/or users-groups-privileges.
2. Identify some simple exceptions and interesting findings through a visual exploration.
3. Auditing - Perform high level analysis for the following entities:
   a. Users Privileges analysis
   b. Resources Privilege Analysis
   c. Links Analysis (Direct & Dual Links)
   d. Overlapping roles (same users & same resources)
4. Audit – Generate auditing reports for the above entities and other auditing reports.
5. Role Engineering – Perform bottom up role search based on various search methods & techniques. (I will elaborate about this topic in a future article)
6. Create few examples of business constraints such as segregation of duty, and review privileges for compliance. (base on SOX, HIPAA etc)
7. Execute business Work Flows such as user certification workflows, role approval work flow and others.
   
   In my next article, I will address other best practices
   Let me know if you have any questions and will try to address them as soon as possible.
   
   Ilan Sharoni

http://www.eurekify.com/