Shorten your Identity Auditing & Cleansing Project Time Frame with Eurekify

Shorten your Identity Auditing & Cleansing Project Time Frame with Eurekify

Last week I was in the US, visiting a new customer and helping them to roll their Identity Auditing/Cleansing and Role Engineering project.

Their original project time frame was planned to span from mid 2007 until end of 2009, with each atomic action as “generating one report”, which would take anywhere between a half to full day! As opposed to Eurekify/Sage where each atomic action takes approximately 5 to 10 minutes to generate a report.

Since they were not so familiar with the new product they had acquired, we spent the time generating cleansing reports. Within a couple of days, our working office looked like an “Auditing Command Room” where people were coming in and out to ask and get reports in order to cleanup old and potentially excess access rights and privileges.

The original scope for this week was one system: Active Directory, but as Active directory cleansing reports were generated in a matter of days, we quickly moved to cover 2 other major systems:
1. RACF
2. TAM (IBM)

The import of data from each system took a few hours, but the results were quite interesting and extremely fruitful.

We managed to:
1. Generate many different privileges cleanup reports for RACF and TAM
2. Evaluate the existing groups coverage and overlap of the RACF system
3. Re-engineer some of the groups (roles) of the RACF and prove that the RACF system can be optimized through this process.

In addition we began a mini compliance project in order to create the first set of compliance rules (SoD, SOX related rules), which produced an impressive list of violations to be cleaned.

The auditors were in cloud nine. Using this new solution gave them full control of their data and a quick way to generate reports and follow up on the cleansing process.

The Identify Auditing Management team, involved in this process, is now able to reassess the project time frame and of course reduce it substantially due to the implementation of Eurekify’s Sage.

Example of data preparation project layout:





If you want to talk with me about your Identity Auditing and Cleansing projects, feel free to contact me at:
isharoni@eurekify.com

Ilan Sharoni
http://www.eurekify.com/

Re-Engineering SAP Complex roles

Last week I visited a large European telecomm company in order to assist and consult them on their SAP system access rights.

In the first couple of days, we dedicated the time to analyze the data that was imported into Eurekify/Sage and generate many cleansing reports. A cleansing project is an essential process before any RBAC project.

By the way, the import of data was done by using the Eurekify built-in connectors to SAP.

The cleansing analysis was done on 2 levels:
1. Roles (complex and simple)
2. Authorization objects and fields.

The second phase of the analysis revealed astounding facts about their current roles:

1. The complex roles covered only 2% of the users!!
2. Most of the access rights were not via complex roles, but rather directly to simple roles. Only 4% of the access rights to simple roles where via complex roles.
3. They had many dual access rights to “simple role” which means that a user had access to the simple role directly and also via a complex role.
4. They found that they had many simple roles that could be merged.
5. Many simple roles could be deleted since they were not used any more.

The highlight of the project was the SAP complex role re-engineering. We reversed engineered the “complex roles” and deleted the roles.

Within 1 day of (partial!!) role engineering, we managed to create new complex roles (less than what they had before by 20%), however:
1. The new roles covered 40% of the users!!
2. The new roles covered 26% of the access rights to “Simple Roles”!!

In the upcoming weeks the project will continue in 2 layers:
1. Cleansing the SAP access rights data from complex roles down to the fields.
2. Continuing with the Role Engineering in order to create a full model of complex roles.

Are you interested in applying this experience to your SAP system?
If yes, feel free to contact me.

Ilan Sharoni
http://www.eurekify.com/

When was the last time you ran a “health check” on privileges in your Top Secret system ?

I was driven to write this short article due to a recent visit I made to a large bank that has been using TSS for over 20 years. This short questionnaire is designed for Top Secret administrators and Security Directors.

Below, you will find Eurekify’s average statistics for some of the questions.

1. Do you know how many dead accounts you have in your TSS system?

2. Do you know how many dead transactions you have in your TSS system?

3. Do you know how many dead profiles you have in your TSS system?

4. Do you know how many profiles have exactly the same users, or overlap in 80%? Would it be interesting to try and merge a few of them?

5. Do you know how many profiles provide access to exactly the same transactions or data sets, or overlap by 80%? Would it be nice to try and merge them?

6. Do you know how many users have direct access rights to transactions (not via a profile)? In addition how many direct links does each user have? Would you like to get this detailed report?

7. Do you want to quickly figure out profiles to which direct access rights may be assigned?

8. Do you know how many users have “dual access” rights to transactions (i.e., via a profile as well as directly)? How many dual links does each user have? Would you like to get this detailed report?


9. Do you know how many users have out-of-pattern privileges to profiles or direct access rights? For example, analysis of HR attributes and other access rights may reveal people that moved to a new job, but retained access rights.


10. Over the years, you have probably established a few “rules” to govern the distribution of access rights in your TSS. Do you want to automatically verify that these rules are upheld?

11. Your auditors probably ask you to implement a few other rules such as segregation of duty and other constraints on the assignment of privileges, especially to sensitive and high-risk transactions and data. Do you want to automatically verify that these rules are upheld, and to be able to easily provide them with a report that proves so?

12. Would it be nice to be able to answer complex queries on access rights with a few clicks in a visual browser?


On a higher level:
1. Would you be interested to design and implement a role-based access control (RBAC) framework within TSS across TSS and other enterprise platforms?
2. Would you be interested to establish and manage a governance, risk, and compliance management framework within TSS and across TSS and other enterprise platforms?

Eurekify estimations for an average TSS:

# of dead accounts: 5%-15%
# of dead transactions: 10%-40%
# of overlapping profiles: 30%
# of users that have direct access rights: 50%
# of users that have out-of-pattern access rights: 20%-40%


For TSS, we built a special connector that makes it easy to run an initial evaluation in a matter of 3-5 days. You will usually start to see substantial results in the FIRST day.
Let me know if you want a demo on your own TSS system.

Ilan Sharoni
http://www.eurekify.com/

Bottom up discover your IT business policies (SoD rules) that comply with your HR data

A customer needed to define and create IT business compliance rules, in order to be prepared before receiving a visit from external auditors that may discover violations of industry regulations and fine them.

Another company in the same business was audited 8 weeks prior and was fined by $1 Mil. This company did use internal auditors, however the amount of data that they had to process was overwhelming and despite having many people working and spending a lot time on this, it was simply not enough.

The IT internal auditors received a presentation on Eurekify’s solution and quickly grasped that the solution can:
1. Create all the type of business rules that they need
2. Easily load all the current rules that they have defined
3. BOTTOM-UP DISCOVERY of many potential new business compliance rules that are base on HR data

The next step which took only a couple of days, the IT auditors were able to load the IT access rights data and the HR data into Eurekify data warehouse, and used Eurekify to discover and review many new rules that are sensitive to HR attributes, such as:

Only people that hold the following HR attributes:
1. Division = Corporate
2. Department = Finance
3. Title = Account

Can have access to:
1. SAP Finance Application
2. Finance Shared folders

And many other rules…

For more information, questions or ideas - send me your comments

Ilan Sharoni
isharoni@eurekify.com
http://www.eurekify.com/

SoD mass rules import (best practices)

The major challenge in many compliance projects that I was involved with in the past 2 years were around:
How to discover the SoD rules (bottom up discovery)
How to load many rules into the compliance solution

As for the “How to discover the rules”, this I will discuss in a separate article.

How to load many rules into the compliance solution:

Most SoD solutions provide an editor that enables the end user to feed in the SoD rules and then test these rules.
This editor allows the Auditor to define his/her SoD rules manually.

However, in reality, a business with 100k users, may have thousands of SoD rules that need to be fed into the SoD solution.

The challenge: to upload all those SoD rules.

Most auditors keep the SoD rules in a spreadsheet that look like the figure below:
The X represents a “collision” which means that if a user has access to a role from the “green” list, he can not have access to a role from the “yellow” list.
This example is for role to role but it can be applied to any type of objects as: resource to resource, role to resource, user attribute to role .. etc.



This is usually an XLS file that can be converted to a CSV file in the following text layout that includes the list of couple of roles (objects) that should be segregated:

The next step is to use the loader utility that is supplied with the SoD solution that can read and load the text file and convert it into SoD rules.

In projects that I have been involved with, we have managed, in a matter of hours (max 1 day) to cover the following:
Get the XLS file from the auditors
Convert the file to a TEXT file by xls experts
Load the file into the SoD solution
Generate a list of violations

In these projects, customers were using Eurekify’s solution for Auditors.

Eurekify/Sage SoD solution is an overall solution that addressed all aspects of SoD management, reports and other requirements for complete and extensive SoD projects (SOX, HIPAA, FERC, GLB, BASEL II, GAO, FFIEC, OMB, IRS Regulations, Fed Rules, UETA, ESign, NARA, FISMA, FISCAM and more..)



Ilan Sharoni
Director Eurekify

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/