Feeds:
Posts
Comments

Posts Tagged ‘Entitlements’

TRESPASSINGIn the maturity model of identity management, we have been through many stages of evolution and may be on the brink of the final stage – context aware identity management.  First it was centralized authorization (directory), authentication (access managmeent, SSO, STS, federation), identity management (provisioning), roles (RBAC), auditing/regulatory (compliance and analytics), privileged accounts management, and finally centralized policy management (entitlements servers).  

The final frontier, once you have mastered all of the above, is context aware identity management.  The user may have all the rights and privileges to access the resources, but they are doing so in an abnormal way.  Call it behavioral security.  My classic example is a company’s CIO may have access to a sensitive data room and may even have their badges grant them access to the data center floor, but one has to ask why the CIO is entering the sensitive data center at  2 AM.  However, a member of the cleaning staff would have the same privileges and would be expected in at 2 am to do their cleaning.

So its all about context.  Having the right credentials and using them in an manner as expected and flagging when they are used atypically.  As of this writing, Bradley Manning is waiting his sentencing for releasing 700,000 classified documents to Wikileaks.  What many miss in this sad adventure is that Pvt. Manning did not “hack” his way into the systems containing this information.  He was hired/recruited, trained, authorized to have sensitive access, and had his access vouched for in several compliance reviews.  The only question nobody asked was why a low level private with clearance was downloading hundreds of thousands of files at one time.  His behavior with his access level should have sent up warning signs.

This type of behavioral monitoring has been around for years and found some success, particularly in the financial sector.  Banks and investment firms have employed adaptive access management tools to work with their single sign-on front ends to their web sites. You have probably seen them when your bank shows you a confirmation picture first and asks you to set up security questions.  What you may not know is the software also “fingerprints” your system (OS type/version, MAC address, IP location, etc.) and starts building a profile of how you access your account. If you do anything out of the ordinary, it may ask you who your second grade teacher was even though you presented the correct user ID and password. Try logging into your bank from your mother-in-law’s computer in Florida when you visit next and you will most likely have to answer some additional security questions because we need to insure its you.

So buried deep in the latest release of Oracle Entitlements Server (try no to thump my company’s products, but this is the only software I know that can do this at this point) is the ability to add to your enforcement policies to make them context aware. The enforcement policies can look at more than just job title and role, it can also look at location, device, time, organization, etc. to make a more informed decision on whether to grant access.

It may be okay that you have privileged access to mission critical servers to issue a reboot command, but, ya know, we are just not going to allow you to do that if you came in through an external firewall using you iPad.  Just not going to happen. You need to be onsite in the data center to do that.

It is particularly helpful when several users have access to the same system, but need to be limited on what they can see. Just saw a killer demo a few weeks back where users of a military application can see a map of the world showing location of current deployments, but the data is filtered so you can only see resources in your theater of operation.  Europeans can only see assets based in Europe, Africans only see stuff based in Africa, etc.  All controlled centrally with one access policy.

To get to this level of context aware security is not easy to do and represents what I believe is the final frontier in online security.  Its the ability to not only control access and authorization, but understand when and how the proper credentials are being used.  Remember that most damaging breaches are by insiders who have proper access.

Advertisements

Read Full Post »

There. I’ve said it.

Time for developers to stop coding security into their applications and focus more on business functionality of the applications they work on.

Think about it.  One of the first things a developer wrestles with is how to control users within their application.  Day one, they usually build a login screen.  Now where do I put the userID’s? How do I secure that?  And what can this user do?  What security model do I follow?  For this sensitive routine, how to we control who can and who cannot get access?

My personal experience estimation is 25% – 30% of all development efforts are spent rebuilding security and identity.  But as programs become more complex, more and more complexity must be built into the system.  And as we all know, complexity is the Achilles Heel for security.   Don’t even get me started with security and identity in cloud computing.

Instead, security should be thought of as a service. Instead of the programmer trying to learn and then implement security in their programs, they should rely on callable services to provide AuthN and AuthZ decisions.  Instead of building login screens,  a user identity repository, user administration screens, and provisioning sub-systems, the coder should just in calls to a security subsystem and rely on the decisions to be made for them.  Drag and drop in their IDE.

We already have some of this today, but we need to adopt it at a faster pace.  At the macro security level, access management and federation tools can protect an application and authenticate a user.  The programmer does not have to care how the user is authenticated, only that they are authenticated by the powers that be.  The user may have only supplied a user ID and password, used a challenge token, or a retina scan.  The programmer does not care.  It just calls the security service and asks is this user authenticated to use this application. Yes or no?

Fine grain entitlements are another matter.  These too should be handled via a security service.  Instead of writing convoluted security logic (lets see, if the user has this role and this entitlement, then let them do this, etc.), they should just insert a policy enforcement point (PEP).  This is a call out to the security service at the start of the subsystem logic.  Can the user do what they are about to try and do?  The programmer does not have to worry about why the user is approved,  just that they are approved.

Policy entitlement servers, which can support this PEP model, are available, but not enough applications are built using this decentralized security approach.  As an enterprise continues to grow in security maturity, the benefit of this approach becomes apparent.  Security policies become centralized across applications and can be managed with role based approaches.  Gone are the days when security is baked into a system and the original team leaves, leaving the organization with questions on how the security in the application works or how to change it to meet new policies.

Brittle security code is a thing of the past when all a programmer has to do is treat security as a service.  Does the user have a valid session to use this application?  Yes/No. Drag authorization point in the IDE into the program’s workflow and not worry how the user is validated.  Can the user run this report?  Yes/No.  Cut a check and pay a vendor?  Yes/No.  Much simpler when this is removed from the code and PEP’s inserted.

New regulation passed by who know who?  Change in the security policy of the company?  Much easier to manage with all user information and security policies in a central location.  Change the policy and the applications behavior is changed without recoding and testing (well, you want to test the policy changes in UAT first, just to be safe).

Instead of 25% of the development effort spent on security issues, less than 5% of a programmer’s time is dedicated to it.  Allowing them more time to focus on the functionality of the program.

So, I say, its time to get programmers out of the security business.

 

 

Read Full Post »

Whats on your keychain?Simple question: who in your organization has the most entitlements in your organization and is that dangerous?

This entry is in response to a new tactic one of our competitors is using to convince prospective customers that the way to detect what employees are the most dangerous is to scan through all of entitlements and count who has the most entitlements.  That will point to users who have too many entitlements, so they must be abusing the system.  “Mary has 54 Active Directory Groups tied to her userid, so she must be up to no good”.  The competition says this is the person you need to vet and keep under strict survellance.

Too bad the client bought it.   They are going to spend a lot of time tracking the wrong people.

So I ask the question, if you treat entitlements like keys on a keychain, who has the most keys on their keychain (save the security guards)?  According to this bent logic, the one with the most keys is the one most likely to be up to no good.

The answer is quite simple: the cleaning staff.

Have keys (or security Java card) that allows them to wander throughout your building pretty much anywhere.  The data center. The backup generator room. The CEO’s office.

So lets clamp down on the janitor and get approvals/certifications for every key they have on their key chain.

Too bad you would miss the administrative assistant to the CEO who only has three keys, but one is to the backup server room.

You see, its not the number of keys you have on your keychain, but why you have a particular key on the key chain at all. If you scan Active Directory, you will probably find Mary in our example does have 54 groups assigned to her, but her role is managing user group meetings for the company and 46 of these AD groups are old distribution lists (email lists) from old shows past that are no longer of much use and were not considered a security risk even when they were in play.

Congratulations.  You have found Mary is not a security risk, just lazy about deleting old meeting email aliases at the company.

So its not the number of entitlements, but what the entitlement is in context. Its entirely proper for the cleaning staff to have a key to the backup server room; they have to enter to clean the room.

However, what you would find suspicious is doing a role scan and finding all administrative assistants to directors,  AVP’s,  and higher in the finance department all have the same 5 entitlements (keys) but one admin assistant has a sixth key the others in her role does not. She too has a key to the back up server room.

That should raise a yellow flag and trigger an investigation.  Why does the admin need access to the backup server room?  Used to work there and nobody got her key when she transferred?  She made a copy so she can download client information after hours to sell on the black market? She found it one day in the lunch room and never gave it back?

A quick follow up investigation with the manager of the backup server room might find out that, yes, one financial administrator assistant has the key to allow her to drop off a copy of the CEO’s external back up drive once a week as a security precaution.  Or pick up the CxO’s private faxes that happen to come into a printer in that room.

Its okay then. Its an anomaly,  but every agrees that its okay.

Which then begs the question should other administrators also have access to the back up server room in case Mary is on vacation or ends up on leave?  Perhaps others should have this privileged key as well, now that we know its part of their needed entitlements.

The key here is not to count number of entitlements or keys, but use analytics to identify those critical keys and anyone in the organization who has abnormal access to the privileged key.  That is an effective identity management approach.

One last question: does it bother anyone other than me that I never have seen a pilot of a commercial airliner pull out a set of keys to fly the airplane?

Read Full Post »

Grad Student Roles

“All the world’s a stage,
And all the men and women merely players;
They have their exits and their entrances;
And one man in his time plays many parts,

-Shakespeare, As You Like it

A case study to illustrate multi-role RBAC engineering design

There are many challenges in defining roles within an enterprise, but I think trying to define the role of a grad student poses unique challenges and points out some of the shortcomings in role definition organizations run into when they try to simplify the role definition process.

We just finished a review with one of our higher education clients who has implemented a first try at role definition across the university.  They did a good job, can count on many successes, but some of the early role decisions are coming back to bite them. Thought sharing the challenge of the grad student should help illustrate some of the basics of role design and engineering.

So first, the challenge.

The university wanted to implement a Role Based Access Control (RBAC) scheme where everyone was going to be assigned a role to gain access to different university resources on the network.  The decision that is coming back to bite them is, in order to simplify the role engineering and the administration of those roles, every user on the school’s network was to have only one role and one minor role.  If you were a student, you were assigned the role of STUDENT and that created an email box, home directory, home printer, etc. across the variety of platforms on the university network.  Professors and teachers (Role::FACULTY) got pretty much the same access (email, home directory, etc.) but also to the grading system and online research repositories.

Access to specific systems, like Chem Lab servers, were created as separate roles from the basic STUDENT/FACULTY roles and could be assigned as well as a minor role. The University developed this second level of roles to help gain some finer granularity around system entitlements, but it meant these secondary roles had to be mutually exclusive of the entitlements set covered under the STUDENT/FACULTY roles.  Everyone could have two roles that did not conflict with each other. A student could be a STUDENT and a CHEMISTRY major and get access to almost all of the systems they needed on campus. A simple role design (major role and minor role) that was simple to create and administer.

This approach greatly simplified the management of roles (still, lots of spreadsheets, emails, phone calls, and home grown databases), but it breaks down when it comes to the grad student.

STUDENTs had been migrated over to Google mail accounts, but FACULTY still had an internal Sun mail server, due to in part to the confidential nature of some of the faculty’s research.  Every time you switched from STUDENT to FACULTY or back again, the user had to switch mail servers and in boxes, disrupting their work spaces and their work. A side effect of this was the explosion of minor roles, where roles were created almost as one-offs to get around the limitations of this two role approach.  Administration did not go down with this two role design, it actually increased, as new roles had to be created and approved to get everyone proper access to the university’s resources. Thus the call for a review by our identity team.

Pity the poor graduate student.  They are students, yes, but most of them also act as teacher assistants, so that makes them faculty as well.  In this particular University, many of the faculty are taking graduate courses as well, so that makes a FACULTY member a STUDENT as well. Many students become grad students and then become teachers.  With this rigid major/minor role approach, the poor grad students were getting thrashed when gaining access to basic university resources.

A grad student:

  1. Is a student, so should have access to student resources
  2. A graduate student, who may need additional privileges as a graduate student
  3. An employee, who needs to pay tuition and receive a paycheck for teaching
  4. A research assistant who may need access across departments to support research work for the university
  5. May work on external projects with corporations or government based research
  6. Eventually, become an alumni and need residual access to the school the know and love

So, as Shakespeare pointed out centuries ago, a role management system has to handle the changes a user might go through during their relationship with the university.  This points out the need to adopt a more sophisticated, multi-tiered, multi node hierarchical role structure.   Roles should contain entitlements specific for the individual and access to resources needs to be on a highest privilege  (versus the more traditional least privileged) assignment scheme.  As a student, the user should get access to the grading system to see their posted grades, but as a member of the faculty, they should also get access to the grading system to enter grades from the classes they teach in, something an average student is not entitled to do. But not to change their own grades.

So a much better approach to role design is to get more sophisticated.  Users should get assigned roles they need and these roles assessed as a whole group to determine highest privilege access to the various systems and to check for separation of duty (SOD) conflicts.  A grad student should have the role of STUDENT, the role of FACULTY and additional roles, like CHEMISTRY DEPARTMENT and RESEARCHER, that are evaluated as a group to determine the final access to the university systems. Roles don’t explode, because the current set of roles are evaluated as a group and a blended entitlement set is determined for the user.

And this approach allows for more flexibility without complexity.  Access to sports facilities can be added as a separate “line item” role, controlling who has access to the sports facilities around campus.  And a good role management system allows for individual “tweaks”, such as giving a chem student access to the lemur research cages just because they want to help a friend at night. Additional roles do not have to be created for these one off scenarios.

Role management software is available today to help better engineer and design these blended roles and to evaluate final entitlement sets.  They can even be integrated into provisioning systems to automatically set account access for the user.

So, look at your current approach to role design and see if it can pass the Grad Student Test. If there are built in limitations that would not support the entitlements assignment of a graduate student, you might have a time bomb waiting to go off sometime in the future.    If not, might be time to go back and rethink the approach to roles being used in your organization.


Read Full Post »

http://en.wikipedia.org/wiki/Pogo_(comics)Famous words from Pogo and Mort Kelly, which was actually a jab at McCarthyism in its day.  But these words also apply to identity management.

Time and again, when truing up user accounts and security policies, the many of the offending accounts are the cleaning lady category. They are the admin and IT management accounts, the very accounts used to manage security and identity in the enterprise.

Oh, and you can add the audit team and senior management.

And what I usually hear is “well we need to have access to manage everyone’s security”.

No you don’t.

It was this kind of thinking that caused all of the problems with root account access in UNIX getting out of hand.  Privileged users are a unique use case, but they must have the most policies and security controls on them.

Think of this scenario (has happened). A new IT manager is hired (the last one failed to implement identity management correctly, could not take it serious).  Peoplesoft creates the user, the IDM system provisions the user.   Based on  the need to manage IT resources, the role they are assigned gives that brand new user the right to manage the process that granted them the right in the first place.

Look Pogo, a user granted the right to create more privileged users at their level.  The enemy is us.

Granted the workflow may include one or more approval steps. But once that provisioning is completed, what additional steps are being done to insure the safety of the overall system?  Who is checking this new user does not alter the workflow to add additional privileges?  Who is following up on a regular basis to insure the workflow has not been altered or used by a hacker to create additional privileged accounts?

Think about who is your IT organization is “The Cleaning Lady”. You know, the low paid, low esteemed worker whom most people ignore, but provides an invaluable service doing the dirty jobs (aka, IT administration).  And who, because of the job she needs to do, has keys to all of the most secure areas of the office.  Who in your organization has a keychain full of top level keys?

What about auditors?  DBA’s?  UNIX admins?  The security team itself?

Can you tell us right now who these people are, who is monitoring their access?  Where are the exception policies that insure these high value target accounts are regularly audited and renewed?

One of my favorite stories is how a head of compliance  got gobsmacked several years ago.  He was an early adopter who got upper management approval to push through an IDM project for SOX compliance.  Had a strict policy adopted that any rogue or orphan accounts could not have an email box (makes sure it is not used as a spam source).

When the rogue account reconcillation pulled up a variety of unclaimed privileged accounts and the workflow promptly deleted the email account in Exchange, removed the home directory, and deactivated  across a variety of systems.

Problem was, one of those accounts was the CEO’s.  Everything got trashed.

Seems the CEO had been given super human, almost god like privileges to most of the companies sensitive systems.  Any time IT admin added the CEO’s account to a system, they gave him admin/root access privileges. After all, Toto, he/she is the CEO.

When the reconcile missed linking up the CEO’s account to a known HR account, it was deemed a rogue account with high entitlements and was promptly dispatched.

Needless to say, there was no joy in Mudville that day.

Truth is, other than blowing away the email account, the CEO should not have accumulated the excess entitlements.  Remember, over 85% of security breaches are believed to be from internal employees.

So, consider the extra effort needed do Privileged User Management.  It will take a lot more time than you originally estimate.  Make sure you get all the cleaning ladies handled properly…

Read Full Post »

Be Seeing YouTime to start down the path of entitlements.  And right off the bat, we run into our first problem.   What exactly is an entitlement?

True story: several years ago, I was facilitating a discussion on a client site between the business owner, who saw value in rolling out identity management, the IT project manager, who was tasked with rolling out the first automated provisioning system in the company, and the financial auditor responsible for insuring the project was safe from a security standpoint.

We were now in our third one hour meeting and we were going around in circles.  Seems we were going over the same arguments again and again. You know how it is; you reach a point where everyone repeats their pet concerns and doesn’t seem to be listening to the others, who are doing the same.

Finally, I called them out on it and said we were all talking about the same thing, but had a different viewpoint on it.   It was about determining who go the power to cut up to $5,000 checks to vendors. The business owner wanted someone with accounts payable ability to be able to order supplies on short notice to keep things moving. Someone who had “accounts payable power”.  The IT owner said “that would be the PAYVEND role in such and such package” and wanted to know what the qualifiers were. And the audit person wanted to know who could cut a $5,000 and who would be responsible to monitor that person’s access to that system (funny thing SOX).

It was pointed out they were all looking at the same issue, but had a different viewpoint.  It all boiled down to giving certain employee accounts the entitlement to issue a corporate check to a vendor for up to $5,000.  But each saw it differently. Business owner wanted business function. The IT manager was trying to slot the user account into the correct responsibilities in the ERP system. And the auditor only cared about who would have the rights to cut a $5,000 check. She did not care how the entitlement was assigned, but wanted to be sure it was assigned by the right person and was being monitored.

They were all talking about the same thing. Just had different viewpoints on it. Once this was pointed out, we got the discussion off the sandbar it had been stuck on and we were able to make some progress.

So here is the first problem with entitlements – point of view and definition.

What an entitlement is depends on your point of view and it will have to be meshed to what others feel entitlements mean to them.  What entitlements mean to a owner of an Oracle ERP system is different from what an SAP ERP owners thinks they are. And both are probably different from the DBA and the business executive.

And that means you need a strong glossary.  Probably weapon number one in tackling entitlements.  Before any entitlements discussion, start developing your company entitlement glossary.  You will need to refer to it on a regular basis.  You will most likely need a software tool to keep track of the definitions (more than a spreadsheet).  Many role management and GRC tools have a glossary function, but I always feel they are not given enough center stage play.

A good glossary is the first step on tackling entitlements, so be sure to thoroughly vet your software tools for a robust and open glossary.

Did I mention some parts of the world also speak a different language?

Read Full Post »

Welcome back from the holidays.

Been busy around here with getting ready to join Oracle (granted, its an acquisition, but in the end, I can choose to accept a position, if offered).  Oh, and lets get the 2010 thing out of the way (its twenty-ten, just like nineteen sixty three, not twenty-ought-ten). And remember back in 1984?  This was the year Arthur C. Clarke said we would make contact. Let me know how that works out for you.

So were do we stand looking forward to the new year?  That’s been a focus of mine recently and quite a few others out there.  Central repositories – been there, upgraded that.  Access Management – transitional year as it takes on more significance, but not the big mover this year.  Provisioning – deployed, upgraded, and looking to reach deeper into the organization (more on this in a future blog).  Role Management – good stuff, good market, and tools maturing.

My personal focus is on entitlements this year. Its their time.  To date, all identity projects really have eventually dealt with entitlements – who has access to what and what can they do with it.  But we never have really gotten down to where the “rubber meets the road”. The actual security attributes on a resource (files, dbs, ports, devices, sockets, pipes, queues, applications, etc.) can be many and numerous.

Accounts have entitlements and roles are a way of grouping accounts and entitlements into a more manageable form.  Accounts and roles have full life cycle management. They are defined, approved, deployed, certified, and retired. As such,we have been managing entitlements all along. But now, specific life cycle management of the entitlements themselves is being asked for.  For example, the specific entitlement “transfer up to $100K to a vendor” will need to be identified as critical to the organization, will need an owner, will need to have a regular certification cycles, and will need to be fully life cycled. Not the account, not the role, but the entitlement specifically.

So how big is this elephant?

Take Solaris’ file system.  Many think there are four entitlements to the file (read, write, execute, denied). But they are combined into eight permissions (No permissions, execute only, write only, write/execute, read only, read/write, read/execute, read/write/execute).  And these permissions are grouped into three permission sets based on who is trying to access the file – owner, group, and other.  This leads to actually:

8 owner X 8 group X 8 other = 512 permission possibilities on file

Now add the fact the file resides somewhere inside a directory that has its own set of permissions:

512 file permissions X 512 directory permissions = 262,144  permission combinations

So every file has over a quarter of a million ways of securing access to it. Granted having full permissions to a file in a directory that has no permissions is a little self defeating (actually, it is meant to defeat unauthorized access), you get the idea of how quickly entitlements management can get out of hand.

Add to that ERP GRC, SOA web services entitlement, and the need to expand identity to virtual and federated resources and you may start to understand the gravity of the situation.

So, we are going to start this year focusing on entitlement management in the next few blogs, if for no other reason to scare the pants off of anyone who currently works in the identity field.

Be seeing you.

Read Full Post »