Archive for the ‘Aveksa’ Category
Monday, September 19th, 2011
I was in a conversation recently in regards to Extensible Access Control Mark-up Language (XACML) and Attribute Based Access Control’s (ABAC) role in Role Based Access Control (RBAC), Risk Adaptable Based Access Control (RAdAC) and Security Access Mark-up Language (SAML). The question surrounded whether ABAC can or should replace the other Access Control models and/or the open standard languages.
The short answer is no, and well, kind of yes.
Let me expound upon my vagary if you will.
Role Based Access Control (RBAC)
To start with Role Based Access Control we should start with what works. The RBAC tools on the market have an advantage of tying the Identity to a Role that can be used for high level access rights that don’t need to change all that often. Aveksa, Sailpoint, Oracle Identity Analytics, etc. pride themselves on the ability to role mine your application stack and set the role to the associated entitlements. This allows the organization to fulfill most security audits and allows for easy re-certification of said roles quarterly, bi-annually, annually or whatever the requirement states. The failing, if you were to call it such, is that to change the entitlements typically becomes very intricate as the roles the organization has explodes. This forces the governance model to keep roles shallow at best.
Where ABAC shines is by allowing a deeper, more fine-grained authorization model by using policy combined with attribute values in order to allow a level of authorization commensurate with the values presented. To do this, ABAC essentially strips out the Identity and relies solely on those attribute values to make a decision. This can extend an RBAC separation of duty (SOD) policy greatly and alleviate a lot of risk while making SOD decisions in real time.
So while “yes”, you can replace your RBAC vendor’s toolset with an ABAC solution the real question is why would you? The tools work very well together and allow for a greater sum of their parts as opposed to their own private silos. If I had my druthers within my customer sites I would have an Identity Provisioning system (to automate Identity creation and management) that ties into my RBAC vendor tool (to grant high-level entitlements and set automated recertification policy) that leverages my ABAC tool to authorize application access at a fine grained level (with perhaps an SSO tool to manage Authentication, which XACML/ABAC does not).
Risk Adaptive Based Access Control (RAdAC)
Ah RAdAC, the grand unknown! RAdAC essentially is the process of taking information we know about the user, whether that is attributes, meta-data or some other method of taking a plethora (hopefully) of information, running said data into a risk engine algorithm and spitting out data to make a much more informed decision. This is particularly important on highly classified systems. In this case ABAC is a natural fit in conjunction with a RAdAC tool in which the RAdAC tool becomes the defacto decision engine with ABAC the data provider (potentially as this can be some data aggregator like a virtual directory) and the authorization enforcer. ABAC vendors can enforce based on classifications (such as meta-tagging your data as “Secret”, “Top Secret” and “Confidential”) and can run policy based on location or various credentials much in the same way a RAdAC system so you can replace but again the why comes into play here. RAdAC vendor tools typically have a better risk engine to help you define the risk algorithms instead of having to determine the set, write the policy and hope it doesn’t change. Once again ABAC plays nicely with the additional Access Control method.
Secure Access Mark-up Language (SAML)
This time let’s dissect Extensible Access Control Mark-up Language (XACML ) vs. SAML. This really isn’t a “Vs.” situation. SAML tends to be used in the Authentication side of the house with limits on how deep it can go into Authorization. Try locking down individual attribute lines in a web based widget framework with SAML. It isn’t going to happen, but that is OK. The point to XACML when used in conjunction with SAML is that it can extend the security framework by providing a more robust Authorization framework (i.e. fine-grained). So don’t throw away your Web SSO vendor integration yet. Can you? Well, once again the answer is “yes”, but why would you? Keep your infrastructure and expand. ABAC should not be used as a rip and replace technology, it is a flexible architecture that can “add to” instead of “take away”.
Long story short, ABAC is the nice kid on the playground that plays by himself until someone walks up and asks him to play. Then he plays well with others.
Questions, comments or concerns? Feel free to reach out to us at IDMWorks.
Tags: ABAC, Access Control, Attribute Based Access Control, extensible access control markup language, RAdAC, RBAC, Risk adaptive access control, Role Based Access Control, Rossin, SAML, secure access markup language, Todd, Todd Rossin, XACML
Posted in Access Management, Attribute Based Access Control (ABAC), Aveksa, Axiomatics, Best Practices, BiTKOO, Oracle Entitlements Server (OES), Oracle Identity Analytics, RAdAC, RBAC, Risk & Compliance, SAML, Single Sign On (SSO), XACML | No Comments »
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:
+ 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”
+ 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.
Tags: Aveksa, Bridgestream, CA Role and Compliance Manager, Oracle Identity Analytics, Oracle Role Manager, RBAC, RBACx, RCM, Role Based Access Control, Role Management, SailPoint, Vaau
Posted in Aveksa, Best Practices, CA, CA Role & Compliance Manager (RCM), Novell Role Based Provisioning, Oracle Identity Analytics, Oracle Role Manager, RBAC, Role Management, SailPoint, Vaau | No Comments »
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:
- Inventory the custom attributes that you would like to aggregate / evaluate (typically in the form of CUS_ATTR_CAS_1##)
- Develop a SQL query that does what you need to do with these attributes
- Put the SQL query in the correct package file
- Import the changes into the database
- Test your changes
Technical Instructions:
- Login to your database instance, query the database to find out the names of the attributes that you’re interested in:
e.g. select * from t_extensible_schema_columns where display_name like'%status%';
- Develop the SQL query based on these attributes that does what you need.
- Create the following directory
~oracle/database/packages/custom
- Copy over the .pkb and .pks files into this custom directory and add your changes to the .pkb file
- Launch sqlplus from the custom directory and login as AVUSER
- Now import the .pkb and .pks scripts as follows:
@'your_package_name'_Pkg.pks;
@'your_package_name'_Pkg.pkb;
- 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.
Tags: Aveksa, Governance, GRC, IAM, Paul, Paul Bedi, Role Management
Posted in Access Management, Aveksa, Best Practices, Role Management, Security & Risk, Tips & Tricks | No Comments »
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:
- 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.
- 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).
- 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!
Tags: Aveksa, Paul, Paul Bedi, RBAC, Role Management, Roles
Posted in Aveksa, Best Practices, RBAC, Role Management | 1 Comment »
Monday, November 15th, 2010
Interestingly enough I have been asked many times as to what exactly IDMWorks is and what it is that we do (and I don’t just mean the wife and kids). As such it seems time to do the quasi-annual blog sales pitch. I think most of our readers have an idea what we do and have perused the site to better inform themselves but there are some that don’t tread any farther than this here blog. So in keeping with the simplicity of blogvertising I present you IDMWorks.
Subject: Enterprise Identity & Access Management and Governance, Risk & Compliance
You may be aware of many of the issues organizations are facing today around the various challenges and aspects of Identity Management and Information Security.
At IDMWORKS we understand the problems that many of you are facing and are positioned to help. IDMWORKS is a vendor agnostic, Identity Management, Access Management, and Governance, Risk and Compliance Management Consultancy. We have consultants and engineers across the United States and North America that specialize helping clients with most aspects of Identity, Access Management, and GRC issues, including the following:
- Identity and Access Management technology evaluations and POCs
- Identity Management strategy creation, Integration and Deployment
- Identity Management / IT Security Technologies Assessment, Evaluation, and Planning
- Identity Management / IT Security Education
- Pre & Post Identity Management project Support Services
- Identity Federation
- PCI Compliance
- Governance, Risk and Compliance Management , Provisioning
- Single Sign-on and Web Access management
- Data Loss Prevention
IDMWORKS has been built upon the skills and experience of dedicated IDM professionals and specialist with a customer base that includes Government, Healthcare, Education, Financial Services, Energy, Manufacturing and Retail clients.
IDMWORKS has experience with the integration and implementation of the market leading Identity & Access Management, and GRC solutions and technologies – CA, Oracle/Sun, Novell, IBM, Aveksa, Citrix, Passlogix, and Sailpoint, to name a few – and would welcome the opportunity to discuss your IT Security needs to determine how we can help.
We would like to offer you the opportunity to take advantage of an initial Identity Management, and Compliance Assessment. The results of the assessment will include recommendations on potential solutions to address your current Identity management and GRC related issues.
For further information or to arrange an initial consultation, contact IDMWorks to discuss how we can help with a solution to address your needs.
Tags: Access Management, Compliance, Governance, GRC, Identity Management, idmworks, PCI Compliance, Risk, Role Management, Rossin, Todd, Todd Rossin
Posted in Access Management, Aveksa, Best Practices, CA, CA Identity Manager, CA SiteMinder, Citrix, Citrix Password Manager, Citrix XenApp, Cloud Computing, Enterprise Single Sign On (ESSO), Governance, GRC, Identity Management, Identity Provisioning, Novell, Novell Access Manager, Novell Identity Manager, Oracle Access Manager, Oracle Fusion Middleware, Oracle Identity Manager, Oracle Role Manager, Password Management, PCI Compliance, RBAC, Risk & Compliance, Roadmap, Role Management, SailPoint, Security & Risk, Single Sign On (SSO), SOA, SRM, Sun Identity & Access Management, Sun Identity Manager | No Comments »
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.
Tags: Aveksa, Federation, Governance, GRC, IAM, Identity, Identity Manager, IDM, Password Management, Rossin, SailPoint, Todd, Todd Rossin
Posted in Access Management, Aveksa, Enterprise Single Sign On (ESSO), Governance, GRC, Identity Management, Identity Provisioning, Novell, Password Management, RBAC, Role Management, SailPoint, Security & Risk, Sun Identity & Access Management, Vaau | 1 Comment »
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.
.
Tags: Aveksa, Governance, GRC, RBAC, Roles
Posted in Aveksa, GRC, Role Management, SailPoint | 1 Comment »
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:
- 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
- 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
- Create a staging directory
- e.g. mkdir /tmp/aveksa/staging
- Extract the new Avkesa tar ball into this directory
- e.g. tar -jxvf $tmp_path/aveksa-4.1.tar.bz2
- Execute the script called install.sh
- e.g. ./install.sh
- 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
- 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.
Tags: Aveksa, Novell, Paul, Paul Bedi, SUSE
Posted in Aveksa, PCI Compliance, Role Management, Tips & Tricks | No Comments »
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:
- 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.
- 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.
- Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
- 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.
Tags: Aveksa, Bedi, Governance, Paul Bedi, RBAC, Roles, SailPoint
Posted in Aveksa, Governance, RBAC | No Comments »
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.
Tags: Aveksa, Eurekify, Oracle Role Manager, RBAC, Role Management, Roles, Rossin, SailPoint, SRM, Todd, Todd Rossin, Vaau
Posted in Aveksa, GRC, Oracle Role Manager, RBAC, Role Management, SailPoint, SRM, Vaau | No Comments »
