Posts Tagged ‘Aveksa’

Best Practice Role Management Methodologies

Tuesday, July 26th, 2011

When developing Roles within an organization it is important to pre-select the proper Role Management Methodology for use on your project and for ongoing operations once your roles are ready to go live.  There are two approaches that can be used when developing access roles for a company or organization:

  • Top down – With this approach uses a pre-defined method of organizing user access based upon known or developed plan.  An example of this would be: defining user access based upon job function and what access that job requires as the method of organizing people into roles.
  • Bottom up -  With this approach you examine what access people currently have and assign roles based upon what rights those users have. An example of this would be: discovering what rights all (or a group) people have and selecting common access rights for the role being developed.

Both of these approaches have merits and drawbacks associated with their use such:

  • Top down

+  Most effective and comprehensive method of role development

+  Aligns access rights and compliance to business goals regarding compliance

-  Requires business and organizational understanding of access rights at the site

-  Requires significant time in role development before implementation

-  Often difficult to quantify all role assignments and proper access

-  Complexity often leads failure role development or “stuck in the weeds”

  • Bottom up

Quick role development

-  Highly difficult to quantify specific access rights for the roles developed

-  Requires access and mining of specific access data

-  Difficult to align business objectives and compliance with developed roles

It is has been my experience that using a hybrid approach using the following methodology will make a role discovery project successful:

  • Top + Bottom Role discovery – This method uses one or more business or organizational top down role methods and follows with a bottom up approach for discovery and verification.  An example of this would be: take employees job codes as the basis for role creation and locate the access rights associated with the job codes.  Use manual or campaign determination of proper access rights for the roles developed.
  • 80 / 20 Rule - The goal should not be to develop roles for every person at the company or organization.  The goal is provide the most role value by locating access right combinations that cover the majority of individuals.  Implement these effective roles quickly.  Address the exception or difficult to quantify roles later (or when possible).  For example: CEO is not a role, it is a unique job function or more accurately an “exception role”.
  • Phased approach – It has been my experience that role implementation encompassing the entire organization often fails due to the time and complexity required to complete.  Political and/or procedural roadblocks appear, addition of access endpoints and role function or purpose questions occur.  You should implement roles across focused areas of the company or organization where goals are well understood and attainable.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Aveksa Post Unification Customization

Wednesday, January 26th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Often times our clients want to create another identity attribute that is “calculated“.  Maybe this is an overall status, or perhaps it’s an overall supervisor.  Either way, you can implement a customization to accomplish this (and it’s a little complicated so I have two sets of instructions, one for the business user, and the other for the technical user).

Business Instructions:

  1. Inventory the custom attributes that you would like to aggregate / evaluate (typically in the form of CUS_ATTR_CAS_1##)
  2. Develop a SQL query that does what you need to do with these attributes
  3. Put the SQL query in the correct package file
  4. Import the changes into the database
  5. Test your changes

Technical Instructions:

  1. Login to your database instance, query the database to find out the names of the attributes that you’re interested in:
  2. e.g. select * from t_extensible_schema_columns where display_name like'%status%';
  3. Develop the SQL query based on these attributes that does what you need.
  4. Create the following directory
    ~oracle/database/packages/custom
  5. Copy over the .pkb and .pks files into this custom directory and add your changes to the .pkb file
  6. Launch sqlplus from the custom directory and login as AVUSER
  7. Now import the .pkb and .pks scripts as follows:
  8. @'your_package_name'_Pkg.pks;
    
    @'your_package_name'_Pkg.pkb;
  9. Now you can log back into the GUI and test your changes

For further information or to arrange an initial consultation, contact IDMWorks to discuss how we can help with a solution to address your needs.

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!

State of the Union

Saturday, October 9th, 2010

Last week Oracle announced they had purchased Passlogix (best known for the V-GO ESSO application) and this got me thinking about the changes in the last 10 years in the Identity Industry.

A decade ago you had start-ups galore.  Business Layers (eProvisioning), Netegrity (SiteMinder), Access360, Thor (Xellerate), Waveset, Oblix, Trulogica, M-Tech and Courion, too name a few, almost all of which were acquired.

Business Layers got acquired by Netegrity who got subsequently acquired by CA.  Access360 got acquired by IBM as part of the Tivoli Identity Manager product.  Thor got acquired by Oracle, Waveset by Sun and subsequently Oracle, Oblix by Oracle as well (I am sensing a trend here by the way).  Trulogica got acquired by HP where it saw its demise.  M-Tech became Hitachi and Courion bucked the trend and stayed Courion.  Even the smaller space tools like Maxware got picked up by SAP.  In fact, up until the last few years, we have remained in the land of the Big Company Identity Stack.

So how did we get there?

Back in the day IDM was slowly being looked at as the next wave in Risk and security.  The issue at the time was that the products were very green and lacked the technical maturity to make implementation a worthwhile process.  Sure, the low hanging fruit of automagically creating an Active Directory or Netware account was a breeze but the implementation around single sign-on, strategic workflows and approval/escalation to a host of applications was not a smooth process.  In fact in the early 2000s the process involved prior to the technology was still being ironed out.  Many of the projects we worked on required a high level of customization and as a result the time to implement took in some cases years to complete.  During these multi-year engagements a good number of projects failed to get off the ground or changed scope so many times that in the end the effort was deemed a failure or not what is was originally sold as.

Eventually sanity won out and most organizations realized that Web Access Management, Provisioning and further more Federation and Role Management were separate sides of the Identity Management box.  Instead of one large “Big Bang” a step by step approach gained traction as a method to actual success.  Many of the larger organizations even split Access Management and Identity Management into strongly separate buckets with their own teams and infrastructure.  Gone are the days where Access Manager and Identity Manager are viewed as the same application.  Today the products are treated as interconnected but individual pieces complimenting each other even when they fall into the same stack.  This can be seen in the job reqs that many organizations release when looking for a technical resource.  5 years back recruiters were still looking for the Jack-of-All trades Engineer/Developer/Architect/PM that knew the SSO, Provisioning, Federation, Role Management and Password Management tools from the 4 different vendors (my personal favorite being when the recruiter would then say a “junior” resource for said position was OK as a method to justify the sub-par rate, as if such a “junior” person existed with that level of knowledge).

The big company buy-up of the old Venture Capital backed firms yielded a greater maturity in the market and a fierce rivalry in the market place.  In fact the biggest players are now Oracle, IBM, CA, Novell, and to a lesser extent BMC and a hard charging Microsoft.  What is interesting though is as of a few years back the next generation of VC based IAM start-ups popped up and we are seeing history repeat itself with the next wave of industry consolidation.

For instance, take a look at the Role Management and Identity Governance market place.

Bridgestream Roles and Vaau RBACx got scooped up by Oracle and Sun and subsequently Vaau won the application war as Oracle’s preferred Role application (under the unfortunately named Identity Analytics banner).

Aveksa and Sailpoint popped up to not only compete in the same space but to offer superior products to manage compliance with HIPAA, SarBox and the like moving beyond solely role management into the governance and compliance management space.

Eventually, as is the case in the IAM space one, one or both companies are likely to be acquired.  Where they will land is open to conjecture but like all Venture Capital based opportunities you are either a resounding success in the sales game or you are a cheap acquisition target.  I have my own guesses as to what comes next for both companies but alas that is a topic for another blog entry.

As for the announcement of Passlogix being acquired, Oracle has a strong set of tools in the space covering all facets of Identity and Access Management.  They are truly becoming the Walmart of the Identity World.

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.

.

Aveksa upgrade from 4.0.1 to 4.1

Thursday, September 23rd, 2010

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

If you ever wondered how easy it is to upgrade Aveksa Compliance Manager (ACM), here’s the step-by-step:

  1. As Oracle, backup your database
    • There’s a script called AVDB_Export_AVUSER.sh in the directory/home/oracle/database/DBA/AVDB/scripts
    • Make sure you get a message stating “Done !”
    • e.g. $script_path/AVDB_Export_AVUSER.sh -t_401_upgrade_backup
  2. As root, copy over the following files to /tmp/aveksa/packages
    • jdk1.6.0_18_x64.tar.bz2
    • asmlib-004-x64.tar.gz2
    • oraApplication.10.2.0.4_p9119284.x64.tar.bz2
    • aveksa-4.1.tar.bz2
  3. Create a staging directory
  4. e.g. mkdir /tmp/aveksa/staging
  5. Extract the new Avkesa tar ball into this directory
  6. e.g. tar -jxvf $tmp_path/aveksa-4.1.tar.bz2
  7. Execute the script called install.sh
  8. e.g. ./install.sh
  9. Next, answer the installer questions:
    • An existing database was found.  Do you want to keep this database [Y]? Y
    • Migration is necessary when upgrading.  Do you want to migrate the database [Y]? Y
  10. Reboot and you should be good to go.

This is probably one of the best/easiest upgrades I’ve done in a couple of years.

Questions? Feel free to reach out to us at IDMWorks.

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.