Posts Tagged ‘Roles’

The Do’s and Do Not’s of Role Management & Mining with Aveksa

Sunday, January 2nd, 2011

My last blog post about Role Based Access Control (RBAC) had to do with Role Mining specifically around techniques used in larger firms.

Recently, I’ve been working with Aveksa Compliance Manager (ACM) to develop roles for an up-coming certification and I have a few thoughts to share:

  1. Have a good understanding of your data, or find somebody that does. ACM gives you so much flexibility that unless you have a firm grasp on your data, you will not chose the right path.
  2. ACM breaks down roles into three distinct categories
    • Global Roles
    • Business Roles
    • Technical Roles

    DRAW out how you want these to be used first (see recommendations below).

  3. Configure ACM to work within the constraints developed in Step #2. (Roles -> Configuration).  This interface will allow you to configure Global, Business and Technical Roles and their membership constraints.

Now that you have made sense of your data and configured ACM to work within the boundaries of your Role Model, you can start creating or generating roles!

As I indicated above, I have some recommendations for you (not in any particular order):

  • Group collected entitlements into Technical Roles. DO NOT add members to your Technical Roles.
  • Create a Technical Role for any entitlement that you want to manage separately.  In other words, if you want to create a Technical Role for Active Directory Administrators, great, but if you want to manage Schema Admins and Domain Admins separately then these should be in different Roles.
  • Users will request access using the Business Role Name, so create Business Roles using names that make sense to Business users.
  • Along those same lines, don’t rely on your glossary to make up for your cryptic naming conventions.
  • Create a customer User View (Requests -> Configuration -> User Views) which lists all Business Roles when users request access.
  • When role mining, DO NOT create roles based on an attribute (say Department) for a large set of data without testing with a few departments first as roles can only be deleted one at a time!
  • Backup your database before you do any of this (this applies to all vendor tools btw, you will thank me for this later).

There’s probably 50 other things that I have learned in my RBAC travels; I’d love to share them with you and ensure that your ACM project is successful.  Don’t hesitate to give us a call here at IDMWorks, the Identity (and RBAC) Professionals!

The Case for Access Governance

Thursday, September 30th, 2010

Well, if you are a CISO, CRO, CCO, CFO, CTO, a Business Manager, the VP of Enterprise Security, the VP of Internal Audit or in the IT Governance Audit department YOU DO………

Here are just a few of the reasons WHY

The CFO concentrates on expenditure….. As CFO you will want to keep the internal and external audit costs to a minimum as well as making sure that the finance department is compliant with regulations.

The CTO has to focus on the overall management of IT… As CTO you don’t want to worry about access rights and policies. You want an appropriate system to manage that for you.

The Business Manager is just that, all about the business…As part of the Business management team you want to do your job efficiently and profitably by making sure that users get the correct permissions and that the certification process is easy for you to understand without wasting your valuable time.

As for the rest of the illustrious cast, you all want to achieve sustainable audit worthy compliance processes that are effective in minimizing costs and exposure to business risk with timely, accurate delivery of appropriate access to users.

OK so that’s the who needs section and why you need it……now for some key reasons that may influence your decision to purchase and implement an access governance solution across your enterprise.

  • Are you facing an upcoming audit?
  • Do you have Audit issues related to access (SOX 404 segregation of duties and privileged account access issues – access risks that create GLBA/Basel/Solvency violations)?
  • Do you need to contain or reduce the costs of compliance?
  • Do you want to  implement enterprise roles to simplify and streamline the access request and delivery process?
  • Do you have a complex manual approach for access review and certification that uses multiple spreadsheets and is labor intensive?
  • Have you  experienced a data loss or a negative impact on the business due to misuse of access?

So what’s the next step?

If you realize that you are facing one or more of the above challenges may I respectfully suggest that you contact IDMWORKS to work out the finer details. We have a dedicated team of Identity and Access Management  professionals who will provide full program management services to incorporate new process, technology and functionality, ensuring success throughout the project lifecycle.

And the step after?

So now that you have recognized that there may be some issues that need addressing it’s time to think about product. IDMWORKS is ideally positioned to guide you through that selection and deploy the solution on your behalf.

.

The truth about Roles, what people won’t tell you about RBAC

Monday, August 2nd, 2010

I have been at three separate companies as of late  that all strive to have the “perfect role model” for their enterprise. This desire is usually coupled with the desire to have some irrational number of roles to show that their role model was successful.

<Sidebar> Let’s say your company has 100,000 people worldwide, how on earth could you believe that you’re going to end up with 10 roles?

The answer to the number of roles is generally a product of how you want to create enterprise roles (this includes Business and/or IT roles). There are few options when it comes to designing roles, to list a few:

  1. Bottom-up, Top-down and Intersection Analysis (yawn, that’s so 2009)… and the result being a set of IT roles that map to resources, and business roles that map to the IT roles.
  2. Allow Supervisors to control # of roles, they decide what goes in their roles, and your systems make sure that they haven’t put any “toxic combinations” in their roles.
  3. Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
  4. Allow a product to analyze your data and suggest candidate roles.

(All of these mean nothing unless your roles are “in-context”… to be covered in my next post.)

Now comes the part where I give my prescriptive advice on which of the 4 options to use. The answer: RBAC is art, not science, you should try all of the above, at least see if they pass the litmus test for your organization (better yet, call IDMWorks and we can help you figure it out).

Once you’ve figured out what direction you are going with roles, the next step is to stuff all of that in a product. Might I suggest Aveksa as it is the one of the best products in the industry, and use it to manage your roles, entitlements, segregation of duties rules and certifications.

Do I really need Role Management? Yes you do (aka I pity the fool that don’t have Role Management)!

Friday, June 11th, 2010

Enterprise role management is a critical technology for allowing organizations to verify and enforce regulatory mandates and to audit the effectiveness of user access policies. Role management facilitates business and IT policy alignment by helping you translate business policy into technical IT controls such as separation-of-duty rules. With reporting and identity analytics capabilities, you have easy access to a variety of audit data and compliance metrics.

Role management is a critical component in addressing governance and compliance requirements for user access to mission-critical applications and data. Roles support compliance by aligning access privileges to user job functions within the organization and by providing business context to lower-level entitlements and permissions, which need to be reviewed by business managers and compliance staff.

Role lifecycle management must let you create, enforce, and verify role-based access across enterprise applications. Aggregating user access privileges under roles lets you improve entitlement management and ensure that access rights adhere to business and regulatory policies. Ensuring adherence to these policies requires that business managers and auditors review and certify that user access privileges are appropriate within the organization. Role Management should enable you to identify policy violations and inappropriate access and take corrective actions when necessary.