All-In-One Identity Management and Cloud Security

As reported at ABC News, "early this morning it was found that Skype's password reset tool had been compromised. Discovered by Russian hackers and first reported by the tech site the Next Web, all that was needed to get into a Skype account was a Skype user name and the associated email address. The typical security roadblocks between getting into an account weren't in place; it didn't ask a user to confirm an email address with an email or answer a security question."

Even these steps aren't as secure as they could be.  Self service password reset rides that delicate balance between productivity and security.  Users will forget passwords and get locked out, to minimize the disruption to their work day, you need to offer self service with as few roadblocks as possible.  However, the bad guys can take advantage of this lack of roadblocks and reset passwords. 

You need to know that the person resetting the password is who they say they are.

As far as I can tell in Skype's case, it wasn't really that they didn't have the technology in place, it was that they went too far towards the productivity scale in specific use cases.  Or they had a technical issue, I'm not a reporter, I don't know.

But there is something you can learn from this.  Let's start with the idea of tipping the scale all the way to security while still living in the world or self service (as opposed to making someone show up at the help desk and do an iris scan).

What can you do to ensure that user is who they say they are?

• Knowledge based questions.  This is the concept of "what you know."  The user's eye color, first make of car, favorite pasta, etc.  On its own, this is completely guessable by looking at pictures in the cube or a FaceBook profile.
• Two factor authentication.  This is the concept of "what you have."  When the user attempts to reset their password, send them a text or have them use an OATH token or take a biometric fingerprint scan.  This piece, in addition to "what you know", is the most important step.
• Periodic forced re-enrollment.  If you can force enrollment in the self service password reset program periodically, the user will remember their questions, update with their new cell phone number, and confirm their identity.
• Identity proofing.  There are two ways to do this.  You know a lot about your users (think of all of your identity stores), make them answer something that you know about them that a hacker might not like their date of hire, amount of last commission check, boss's favorite ice cream.  If you don't have that information, you can utilize services such as Equifax' identity proofing where they will answer the amount of their mortgage or some other information.
• Multiple account management.  Active Directory self service password reset is the key one here but if a system like empowerID can manage passwords in multiple accounts and add password complexity on top of your domain policy, then do it.

If you set these steps as your default policy, you will have gone overboard and tipped the scale too far towards security and have a mob of angry pitchfork wielding users on your hands.  So you have to temper it slightly.

If you are using empowerID for this (and I assume you are because I'm pretty sure nobody else can force enrollment like we can!), you also have roles for your users and security levels for your applications.  You can integrate these factors into your self service password reset program by incorporating any of these features on an as-needed basis.

For example, turn off identity proofing and biometrics unless a user is trying to reset their password for a high security system like the financials database.  If the user's role is sales, resetting their salesforce.com account should involve two factor authentication but should not require it for thei quotation system (assuming they need this right now!).

Mix and match security levels of the system and role of the user to determine how far you need to tip the scale.  If you have multiple factor authentication on the most secure systems, you might be able to dial down the requirements just to reset their Active Directory password.

Many of these features are exclusive to empowerID.  For sure, the integration of password management with other identity and access management features is unique to empowerID.  See how to take advantage of these best practices in self service password reset with a personalized demo today.

Adaptive authentication conjures up images of complexity.  Turning over your identities to HAL 9000 or something equally scary.  But, in reality, it can be simpler than that.  Remember the goal of identity and access management per Gartner is to ensure that "the right people get the right access to the right resources at the right time, enabling the right business outcomes."

Part of compliance to that principle is knowing who the right people are and what the right resources are.  So, let's break out the actors in this adaptive authentication scenario into 2 people and 2 resources.  Then it's simple to determine what the right access is.

People (or roles):  1) marketing manager and 2) finance director.

Resources: 1) salesforce.com, 2) folder containing 10K documents, and 3) internal SharePoint portal.

Each user will dynamically belong to a role based on their title, department and location for example.  In this case, we will consider these users as roles.

Both roles need access to Salesforce.com.  It is considered a security level 2 application when being accessed by any role outside of sales and requires a second factor authentication when accessing.

Only the finance director needs access to the 10K documents but since these are highly secure level 3 security resources, not only is a second factor authentication is needed, but a notification needs to be sent to the CFO every time someone accesses the documents.

And both roles need access to SharePoint; no adaptive authentication needed.

This is what makes adaptive authentication possible.  The empowerID directory is actually an identity provider and users authenticate against it.  Since it supports federation, it will use your Windows authentication, but still be managing all of your application and resource access.

So, in the first scenario, when the two users try to access salesforce.com; empowerID will see that their roles are not in sales and force a second factor authentication before authenticating them to salesforce.com.

The same thing happens when each user tries to access the financial documents in the 10K folder.  empowerID stops the marketing manager dead in his tracks since he doesn't have access to that resource.  When the finance director accesses the folder, empowerID enforces the second factor authentication and sends a notification to the CFO.  In this instance, you could also do identity proofing, have a workflow approval, or even grant only temporary access.

The same two users go to SharePoint and both are already authenticated.  Of course, once in SharePoint, the users have different experiences based on their roles in empowerID, but we aren't forcing any extra authentication here.

Adaptive authentication is a fairly straight forward concept that doesn't have to be any more complicated than what we described above.  You set security levels on your resources (as granular as you would like); you create roles for your users.  Certain roles have more stringent authentication requirements for certain security level resources. 

You are able to improve security without forcing these more strict security measures on every single role and resource.

Cloud provisioning and single sign on go hand in hand.  IT wants only the right users to have the right access to cloud applications.  Users want that access and to not be bothered having to re-authenticate (well, actually, they say things like "why should I have to enter another password" in a nasally voice usually).

The problem is that the Identity Management industry evolved from the on-premise world and is stuck in its own tracks.  Most vendors' provisioning solutions were either developed separately from their single sign-on solutions or just don't exist in one platform.  Most of the federated single sign-on vendors don't even have a provisioning solution.

So how do you get that perfect world of a user being provisioned into a cloud application based on their role (or something you know about them), getting the correct application role, and federating to keep the number of passwords down for your users?  And, to top that off, keep your security team happy by de-provisioning that user when their job changes?

You don't do it with cloud vendors or traditional IAM solutions.  EmpowerID's tagline is a "New breed of Identity Management" and this is why.  The platform was built from the ground up without the burdens of acquisitions or partnerships to create the full suite.  So, the whole product line shares the same RBAC model, the same API layer, the same metadirectory, the same visual workflow designer.  It is a true platform.

What that does for you is allow you to have the same workflow for role based provisioning for both the cloud and on premise applications.  Map your business roles to application roles and then apply those roles to role based authentication.  It means that if you provision a user in salesforce.com, you can federate using empowerID as the identity provider, giving the elusive single sign-on for that user.

And, you can get even more granular than that.  If the user is accessing highly secure resources, you can force two factor authentication only when the user tries to access that resource.  Picture this, your finance director logs in to Windows in the morning and checks her email and browses the internet to see what the markets are doing.  She clicks on the link to look at the accounts receivable report, empowerID sees that is considered highly secure, and sends a text code as a second factor authentication; she simply enters that code and is authenticated for all resources of that access level.  When she goes into salesforce.com to see the forecast, empowerID knows who she is and authenticates her automatically.

You have just increased security and ease for your user.

Now for the fun part.  Your finance director is looking at a commission report and realizes that she should be in sales.  She changes departments which is reflected in Peoplesoft.  EmpowerID inventories the HR system, changes her department and roles, which deprovisions her from access to the finance system and provisions her a new account in the cloud based marketing automation system.  She now has an account in the cloud application and single sign on to that app.

We have all been wanting the complete soup to nuts identity and access management system that handles all of this seamlessly.  The world got more complicated with cloud applications but having the new breed of identity management software allows you to provision to cloud applications, offer single sign on, and achieve your IAM goals.

Take 30 minutes for a personalized demonstration of empowerID and see how we can help you achieve all or some of these lofty goals.

Reading an article by Earl Perkins titled Data Meets Applications in Identity and Access Governance, I was struck by the distinction he makes between application and data access governance.  From an IAM professional's point of view, they should be one and the same thing...access to resources for their users.

But, apparently, our competitors haven't always thought that way.  He talks about how IAM suite vendors (we are one) are squeezing out point solutions by buying companies and product lines to integrate data access governance into traditional IAM.  EmpowerID is one step ahead of that curve (at least one step!).

EmpowerID's platform incorporates role based access control (RBAC) into all aspects of IAM: provisioning, authentication, synchronization, and, yes, access governance.  This ability to manage any IAM workflow based on roles or even attributes (ABAC) and integrate them into any IAM process is what makes our access governance abilities unique.

We don't have to distinguish between data and application access when granting privileges.  Either are simply resources to empowerID.  The same role structure, the same access request workflows, the same user interfaces apply whether asking for access to Salesforce.com or that folder in the Windows file system, or the shared Exchange mailbox. 

If your role has access, you have access.  If you want to request access, it is the same UI and a resource-appopriate approval process.

For data access governance, we have taken it one step further.  Most solutions offer you one of two ways to request access: 1) request access to a file or folder, or 2) request access to the group that is granting access.  EmpowerID adds the option of requesting access to a role.

No two users think of this process in the same way.  Those who prefer option 1 think of it as, "I need access to that data", those who prefer option 2 think, "what do I need to get access to data", and the third think, "who gets access to that data."

An access governance solution should be able to provide all three options (within limits of course) to satisfy the left brain, the right brain and the all brain thinkers.  Not just for data but application access as well. 

I dislike square peg round hole situations.  If you consider your access governance and IAM solution to be a peg, make it malleable to fit your own businesss situations, processes and policies.  Let us show you a personalized demonstration to see how empowerID can fit into your business and improve access governance.

In many ways, identity management in enterprises is back where it was in 2001.  We've spent the last decade cleaning up users and roles and provisioning and single sign-on but then the cloud happened.  Half of the access your users need is outside the enterprise in the cloud (I made up that stat, please don't quote it).  And the cloud isn't quite as easy to control.

The first part that is out of control is that individual business units can go out and contract with a cloud application; they don't necessarily need to rely on IT to install it and configure it.  They usually get a web-based management console and take to doing the provisioning & deprovisioning manually despite there being a much smarter way to handle it.

So your first and biggest challenge is just knowing what applications there are.  Finance is usually the only place that can even help you with that.  Then you need to know who should and shouldn't have access to this application.  Basically, what roles in your organization should have what role in that application.

Then you have to speak to that application.  Thankfully, most cloud applications have APIs but you have to learn all of their APIs and find a way to code the basics of provision, deprovision and roles.  You need to find a way to manage changes in roles and make sure that you aren't paying for users that aren't using the application any more.

And, lastly, the age old password issue.  The most insane downside to the business setting up their own cloud apps is that they will still blame IT for them having to remember another password.

All of the above sounds familiar.  It is exactly the same discussion that was had around whiteboards at the turn of the century, just with the added cloudy complication that IT doesn't control all of the applications.

Rest assured though, some identity and access management vendors have kept up.  EmpowerID's metadirectory connects to cloud or on-premise applications equally.  Managing user provisioning, authentication and role based access control are as simple as mapping our workflow shapes to cloud application APIs. 

Your provisioning and deprovisioning can be handled based on your role within the organization.  Only sales gets an account in Salesforce, marketing to Hubspot, support to Zendesk, everyobody to Office 365.  By managing roles dynamically, if someone moves from sales to marketing, you can deprovision the Salesforce account, improving security and your monthly bill.

And each of these applications has roles within it so not all Sales department roles get the same level of access in Salesforce.  An account executive has a certain level of access, while a sales director has a more robust role.  By incorporating a simple drag and drop visual role mapping capability, EmpowerID allows you to manage application roles in the same way you manage your corporate roles.

But connectors and APIs don't help with the password problem.  Thankfully, SAML, OAuth, OpenID, WS-Trust and WS-Federation do.  Most cloud applications are SAML-enabled, meaning that you can federate with the cloud applications and offer a single sign on experience.  Users authenticate into your network, click on a link to their cloud application, empowerID's secure token service sends a SAML claim over to the federated application and, boom, single sign on!

EmpowerID's claim to fame in this equation is that it is one single platform handling the provisioning, deprovisioning, RBAC, and federated single sign on.  They can be decoupled, but having a single purpose-built platform handling all of the heavy lifting for on premise and cloud identity management is much more 2013 than 2001.

We learned a lot of lessons in Identity and Access Management (IAM) over the last decade, let's not let the cloud make us forget them.  I've included a few links to whitepapers below, please click on them to see how empowerID embraces the best practices of IAM in the cloud.  And, most importantly, schedule a demo to see how it might fit into your environment.

The biggest benefit to attribute based access control (ABAC) is its flexibility.  You basically are assigning permissions to anyone who meets a certain criteria.  Dynamically.  As soon as you change a person's job, location, employment status, any attribute in any system you want, you are changing their permissions.

Ignoring application based permissions and roles for a moment because if you are reading this you have most likely seen the light in managing permissions in a centralized manner, there are three other main ways to manage permissions.  Users, groups and roles.  To manage permissions user by user would require, literally, a cast of thousands so we can ignore that one as well.

Active Directory security groups are used for permissions quite often.  File systems, SharePoint and some one off applications use AD groups.  Groups are something your users understand; it's just like a distribution group.  But there are limitations.  Not all applications can understand AD groups.  Maintaining group memberships is labor intensive (unless you use EmpowerID Group Manager!).

But one of the biggest issues is nested groups.  If your application is consuming group membership to manage permissions, it has to reach out to AD every time it tries to determine if your user has access and figure out the resultant permissions.  If you nest too deeply, this can take minutes each time (based on a client anecdote, up to 5 minutes).  EmpowerID solves this by inventorying group memberships and storing resultant permissions in the metadirectory but that's a blog post for another day.

Role based access control is more powerful than groups as you can map roles to any connected system or application.  Roles can be dynamic, allowing you to have the immediacy of attribute based access control.  This means that if someone changes departments, their role changes immediately as well.  These new roles can then be mapped to all applications and resources to reach well beyond the scope of AD groups.

But then you sometimes still end up with the square peg round hole syndrome.  You cannot have a role for every single permutation of permissions needed or you might as well go with assigning permissions by user.  Role bloat can be just as bad.  EmpowerID's polyarchical role structure helps solve that by allowing you to assign permissions based on multiple trees (business role and location for example), keeping the number of roles down.

You can still end up with one-offs and that is where ABAC comes to the rescue.  With EmpowerID's metadirectory, you can assign permissions based on attributes in any one of the connected systems (HR, AD, line of business apps, CRM).  Access rights are constantly inventoried so you don't have to hit each application every time someone tries to use that access, speeding up the time to grant access for the user.

When ABAC works best is when it is utilized in conjunction with RBAC.  For example, you have a sales role for account managers in the national accounts segment.  You want to give access to a sales contest reporting tool but only want it available to account managers that are at over 100% of quota. 

You certainly aren't going to create a "national account manager exceeding plan" role but you will have one for "national account manager".  Have EmpowerID check against your commission database to allow access for National Account Manager (role) who are greater than 100% to quota (attribute) and you have RBAC and ABAC synchronicity.

In summary, ABAC and RBAC are both better than group permissions.  There are times to use RBAC exclusively and ABAC exclusively.  But then there are also times to use them together and solve the square peg access problem.

Take a look at our whitepaper on RBAC/ABAC hybrid best practices and schedule a demo of EmpowerID to manage your permissions.

As George Orwell said, "All animals are equal but some animals are more equal than others."  How does this apply to resetting passwords?  Everyone needs passwords reset, but some need a little extra security around their password resetting.

Let's take the scourge of the help desk, active directory password reset.  Everybody has seen the statistics of how expensive it is to have your help desk take these calls, somehow verify that the user is who they say they are and reset the user's AD password.  On average, $35 per call.

The obvious solution is self service AD password reset.  Give the users an easy link to reset their password when it is either forgotten or they are locked out.  They will answer a pre-configured number of knowledge based questions (eye color, favorite pasta noodle, etc); once answered, the software trusts who they are and lets them reset their password.

The issue with this is that some animals are more equal than others.  Do you really want the CFO's password to be compromised because someone read his facebook profile and figured out his eye color and the astounding amount of fusilli that he eats?

The way to solve this is role based Active Directory password reset.  Based on the user's role in your RBAC system, you will require a higher level of authentication before allowing them to reset their password.  Maybe it's just more questions.  Or it could be two factor authentication via SMS.  Or it could be identity proofing.  Or it could require approval by a help desk employee.  The point is, based on a user's role, you can make this password reset more secure.

I have always found it distressing that the higher level of security needed for a user's role, the more likely they are to be violating some basic security rules.  For example, the CFO has a bit of influence in a company; if he hates changing his password, he can talk people into allowing his account to have a "never change" policy.  Same thing for domain admins.

Role based password management should do just the opposite, it should make these more sensitive roles more secure.  Two factor authentication is not that intrusive, just a quick SMS message that your user plugs into a form during password reset.  Identity proofing is even easier, it again is something the user knows like their monthly mortgage payment.  Security doesn't have to be painful.

And by managing security based on role, you don't have to assign this stricter level of authentication if all that role does is punch in and out of the timeclock application.  You still save that $35 per call but can also protect your network with more dexterity.

And here's the best part.  This isn't limited to Active Directory.  If you are managing all of your passwords through EmpowerID, you can reset all of your passwords together or separately.  You can reset your salesforce.com password separate from AD.  And you can do all of this based on your user's role.

EmpowerID password manager utilizes roles and resets passwords, one of the benefits of having a purpose-built integrated IAM platform.  Schedule a demo and see how you can keep your CFO's account more secure.

Your finance department is watching the cloud.  Not because they are tech literate and following IT trends, but because they can cut your budget quickly with cloud applications.  And it's up to you to help them before they help themselves.

In the on premise world, if a user leaves the company and you keep an application account for a few extra weeks, it only hurts your security.  In the cloud world, you just paid an extra month of service for a user account you didn't need to.  Take a look at your internal and external turnover, pull out a calculator and see if you can make a dent in your budget by managing your cloudy accounts better.

The way I see it, you have two simple options to help you reduce your monthly cloud expenditures:

• timely provisioning & deprovisioning of all user accounts
• role based provisioning to the cloud applications

The first is obvious, if a user leaves the company, you need to deprovision ALL of their accounts, on premise and cloud.  A metadirectory that has inventoried all of their accounts from connected systems (AD, HR, ERP, Salesforce, Gotomeeting, etc) can delete or deactivate those accounts quickly and easily.  This is your external turnover.

But what about internal turnover?  That user who moves from marketing to sales and needs new access to some systems (SharePoint sales site and the line of business quote application for example) and different access to other systems (like Salesforce)?  And they certainly don't need access to applications like their cloud based marketing automation software (Hubsport or Eloqua).

They are going to have a different role in your metadirectory (now sales in Iowa instead of marketing in Ohio) and that can trigger the workflows that will provision new user accounts (in that quote application), change access in some (a different native application role in Salesforce), and deprovision access in their marketing automation application (like HubSpot or Eloqua).

Did you see what just happened by managing application access and provisioning by roles?  We just deleted a cloud based application account (the marketing automation account) and saved the company money.  Every single month.  If you are handling this manually or allowing the line of business (marketing department) to manage it, chances are the company is paying for a lot of cobwebbed accounts in your cloud applications.

Keep finance off your back; take a look at empowerID to manage your role based provisioning for the cloud.

The day after the second password was invented, users started to complain.  "How can I remember all of these?"  Insert some whiney noises here and you have the gist of most helpdesk calls.

IT made some progress with single sign on and password vaulting and all was kind of good.  Until the cloud happened.  What the heck are you supposed to do now?  Each user has dozens of cloud applications they need to get to and you don't really control them.

Thankfully, SAML and federation have happened.  You can federate these external cloud applications with your internal authentication and users can access all of their cloud applications right from the comfort and sanctity of their own desk with just one password.

Your users authenticate into the network once, you present them this fantastic SSO dashboard for all of their federated cloud applications (or on-premise, never forget on-premise) and they are off to the races, being productive and not calling IT.  Keep in mind that each tile above is a URL so they can bookmark them or you can present them on any intranet page you desire.

If your user has another federated application, they go to add application and you present them a new tile.

We call this Scenario 1 in our whitepaper on the Top 5 Federated Single Sign-on Scenarios, Corporate login to cloud application.  Some of the benefits to this approach with EmpowerID are:

• EmpowerID provides connectors and workflows to quickly and cost effectively provision application access in Cloud hosted or SaaS applications as part of the normal onboarding process
• EmpowerID maintains auditing and reporting of Cloud application login history as well as who has access to which Cloud applications
• The EmpowerID Login Workflow provides adaptive authentication security to consistently enforce strong authentication standards such as two-factor authentication and also device registration policies to control access from non-corporate devices
• Users only need to know one password

Chances are that your users are using many SAML enabled applications.  You can easily control their usage, provision and deprovision users, and provide seamless SSO.  This will save you money on your monthly SaaS bills, enhance productivity for the users, and provide security and auditing around the wild west of cloud applications.

Take a look at our whitepaper for more details or schedule a demo and get your users the one password they've been wanting.

Security and auditing are two of the main driving forces in Identity & Access Management (IAM).  Remember the definition of identity management: giving the right people access to the right resources at the right time.  But it's like Schrödinger's cat, both alive and dead until you observe and measure it.

Until you observe and measure your IAM practices and policies, you don't know if the right people have the right access.  And you don't know if the wrong people got the wrong access.  That is where auditing actually helps your business, not just satisfying a regulatory requirement.

Auditing and security is a mix of proactive design and reactive reporting.  You design your workflows in a way that ensures the right people have access, set up alerts for exceptions to these rights, and have a helpful reporting interface for your quarterly or yearly audits.  In our view, if you do the proactive part right, the reactive part becomes a rubber stamp.

We look at a few main categories for your proactive access control design:

• RBAC & ABAC access control
• Native system permissions inventory
• Separation of Duties (SOD) policy
• Attestation and access recertification
• EmpowerID Operations audit log

By allowing a hybrid of role based access control (RBAC) and attribute based access control (ABAC), you can achieve a finer level of granularity around your access without role bloat.  Basically, any time a role needs a finer grain control, you add an attribute check from any connected system and access is only granted if the user is in the right role and has the right attribute.

Native tools are a problem in IAM.  If you can circumvent your identity management platform to change attributes, roles or access, what's the point?  EmpowerIDs will continuously inventory native systems, detect changes and report on changes in the native tool.  It can be configured to alert someone, roll it back or just report on it.

Separation of Duties is an oft-overlooked aspect of IAM.  Basically, there are mutually exclusive roles.  If you are allowed to sign a check, you should not be able to issue a PO.  If you are in the research department in a bank, you should not have access to the retail banking systems.  Again, report on it, set alerts or just plain not allow these conflicting roles or group memberships or access rights.

There are also many cases where users have the right access but should not have this access forever.  Attestation and access re-certification solves this.  You can have resource owners (role owner, group owner, app owner, compliance officer) periodically attest that this access is correct.  Even if this access is managed dynamically, you should still have periodic attestation.

All of these GRC factors are stored in an audit log.  But that doesn't do you any good unless there is a strong vehicle to present these actions and access to the appropriate business owner and/or auditor.  Having an online view, a powerful report generator, and most importantly, a method to take action on any red flags is key.

You want to know who made a change, when it was made, what tool was used, and who approved it.  These changes can be in multiple applications and a centralized metadirectory helps keep it all in one place.

Some of the largest most regulated corporations in the world use EmpowerID to solve these access problems, let us demonstrate how EmpowerID can work in your environment.