Courion Corporation

CSO Magazine Takes Me Back To The Early Days Of Passwords

CSO Magazine's June 2009 article, Undercover: A Case of Help Desk Failure takes me back to the early days when Courion was working with early adopters of automated password reset solutions.

The article describes how social engineering was used to gain access to another person's password through the helpdesk... highlighting the need (and difficulty) in challenging helpdesk callers with a set of questions that correctly authenticate the individual but yet are easy for the individual to remember.

In the early days of Courion, we heard similar stories about weak authentication processes at the helpdesk. The most memorable was the helpdesk whose reps recognized the voice of the caller... and this was not an isolated case, several companies used this "authentication mechanism".

The article goes on to emphasize the importance of security, compliance, and controls from the perspective of the business rather than just from the IT frame of reference. Security and Compliance should be part of the business, enabling it go move faster... making it easy for a worker to perform their job securely, and difficult to take risky actions.

Not Just Technology... It's Also About People, Policies and Process

I recently read a report, sponsored by Symantec, on DLP...and part of the executive summary caught my eye,

"If there ever was a problem that could be solved purely by the appropriate deployment of technology, data loss prevention isn't it. People, policies, and products must all work together, or the exodus of information will surely continue."

This is an interesting article that discusses the increased risk of theft/loss of your data, in part, because a market exists for things like stolen credit card data or personal information.  Here's a synopsis...

In the past locked down perimeters and datacenters were the norm, but the "line" is blurring....workers are accessing systems from home, from hotels, on the road.  Your IT organization may be blurring the line as well, moving applications into the "cloud".  The enterprise infrastructure of your business is expanding to include partners and customers.  Businesses continue to have a need to balance how they manage security against how they allow the business to run.  Today's work environment, more than ever, expects to have data easily available at any time, from anywhere...the security model needs to protect data (no matter where it is) in addition to protecting systems.

The article then goes on to describe how Network Access Control complements DLP.  Basically, ensuring that any device that is connected to the network meets the policies of the business.  (Ex: require antivirus, encryption, up to date patches, etc.)

Another key component is people and education.  Teach them how to make the right business decisions with security in mind, AND, make it "easy" to do the right thing.

Ensure that people have the right access to the right data at the right time.  Good people doing unintentional things can introduce as much risk as a malicious hacker.   Reduce your exposure by removing access to sensitive data that is not needed by the business.

NIST Guide to Enterprise Password Management

NIST Special Publication (SP) 800-118 - DRAFT (PDF)

NIST has published a DRAFT Guide to Enterprise Password Management.  Network World has commented on the draft standard.  After skimming both articles, here are some additional thoughts.   The Network World article starts off by describing why passwords are bad, difficult to use, written down etc.  With any form of authentication, we could come up with things that we don't like about them.  Hard tokens are expensive and I have to carry around another device.  Or WebSSO is great, but I can't afford to refactor my legacy applications to use a new authentication model.  ESSO makes systems easy to use but has a "keys to the kingdom" consideration.  Fundamentally, this comes down to a trade-off between security and the service/cost that's appropriate for the business.  You can't make everything bulletproof, so mitigate your risk.   The content of the NIST guide has many best practice recommendations for companies to evaluate for their business:

• strong authentication 2 or 3 factor
• password policies (strength, expiration, lockout)
• securely storing passwords
• combating password cracking/guessing attacks
• education to combat social engineering

The guide also discusses password management as a broad topic, encompassing many products that relate to passwords (rather than the traditional password reset products)

• ESSO
• password synchronization
• local password management (local password vault)

I agree, that "password management" is broadening to include these capabilities, one might extend the notion of password management farther, also incorporating:

• Web Access Management
• Federation
• Privileged User (administrators) management

What are your thoughts?

Identity Challenge in the Cloud - RSA Conference

I was at the RSA conference last week and out of all the sessions I attended, the most packed room was a session about Cloud and identity challenges.  The presenter discussed the subtleties between Cloud, SaaS, hosted, grid, etc, the presenter talked about the pain points in the consumer and enterprise worlds.  A common theme was security, and managing identity (provisioning), identifying the need for access assurance solutions able to address this new segment.

Identity as a Service (IDaaS) was discussed along with Authentication as a Service (AaaS).  While we'd all like to get to a single identity and pass claims and assertions around, this seems unlikely.  It will be difficult to get all parties involved to use the same technologies, standards, and more importantly, agree to trust each other.  It reminds me of SSO and centralized directories.  ESSO was supposed to get rid of all enterprise passwords.  Centralized directories were going to consolidate directories.  In the end businesses will get some consolidation, but still have a handful.

Whether applications are in the cloud or in house, it seems likely that the same needs and concepts will apply.  You'll need to manage access through its lifecycle (hire, change, terminate).  You'll need to get access set up properly, and with least privilege.  Check policy, enforce policy, etc.... 

The REAL Challenge of Cross Domain IdM

Government Computer News published an interesting article on cross domain identity management.  The benefits of federated identity are clear, one identity, a single sign on experience, authorization decisions made at the service provider (relying party).

Products and technologies are available today that make these benefits possible.  Legal and political challenges are often the more difficult part, in the article, Roger Sullivan states, "Working out the business procedures is 90 percent of the problem".

I'd love to have a single identity that transitions between our corporate servers, 401K provider, travel agent, expense tracking, healthcare, and other systems that we use.  Ideally, I'd logon to my desktop and seamlessly transition between the systems.

Take the perspective of the 401K provider.  They will require both technical and legal contracts with my employer to make this happen.  Then to assure that they are properly managing and vetting identities, they may require periodic audit and monitoring, and they will want to minimize their exposure in the event of a breach.  Now repeat this process to reach all the customers of the 401K provider.

Take the perspective of my employer, we'll want to do the same on our end, making sure that the 401K provider, travel agent, etc are properly controlling and managing access.  Again, making sure that the company is protected, and the exposure and risk is minimized.

We'll need to deal with these issues soon.  In Massachusetts, the upcoming Standards for the Protection of Personal information (MA 201 CMR 17.00) are going to require policies, processes, and systems to be put in place for both business and for services that are outsourced to vendors such as the 401K provider.  These are proactive regulation intended to protect personal information (PI) about MA residents.  The company will be required to review (and even amend) the legal contracts with vendors who manage or have access to MA PI.

As Applications Externalize Authentication and Authorization...

Overview:  Many systems and applications are adopting a model where they rely on an external system for their authentication, authorization and audit (AAA) requirements which raises a few security concerns.  Perhaps the most common example is applications that control access based on Active Directory (AD) accounts and Active Directory Security Groups.  While Active Directory may be the most common example, other vendors offer products and solutions that make authentication (is this person really Bob?) and authorization (can Bob access this resource?) decisions.

Vendors:  Other vendors include Cisco (via the Securent acquisition), RSA Entitlement Policy Manager (EPM), BitKoo, Rohati, Quest (Vintela), and even Microsoft has another technology called Authorization Manager (AzMan).

The Value of Externalizing AAA:  This approach is advantageous to software vendors and developers.  It allows them to concentrate on the core competencies of their application, while relying on the expertise of another vendor for authentication and authorization.  While externalizing AAA is powerful, it can introduce complexities in the way that permissions are assigned and audited.

Example:  Let's look at an example that I've experienced as a site owner in SharePoint.  SharePoint has a permissions model that is built on top of Active Directory groups and accounts.  As a site owner, I assign and control access via our corporate AD groups.  The challenge that I have is that I don't have visibility into the AD group membership, so I'm unable to easily figure out who can get to my site at a certain permission level (read versus write).

Sprawl:  The problem grows more complex as more systems (in this case) use AD for AAA.  For example, I just found that our corporate VMware vCenter security model is tied into Active Directory.  The group membership of my corporate account potentially grants me access to both SharePoint and VMware.  In fact, looking across all systems in the enterprise, here's what comes to mind for systems that are using an external system (AD) for AAA:

• SharePoint (over 100 sites)
• SQL Server databases
• Spam Quarantine
• VMware vCenter
• Corporate Intranet
• Citrix License Server
• Citrix Password Manager
• Citrix XenApp
• Windows Shares
• And more....

Challenges:

Visibility:  Given an entitlement in AD (or any other system), it is difficult to determine the systems and resources that it governs.

Unintended consequences: I assign Bob group membership in Grp Y to grants him read access to SharePoint....what else does Grp Y control?  Is Bob also getting access to VMware?

Proliferation: to avoid the unintended consequences above, one might define an AD group per applications.....however, this can lead to a proliferation of AD groups.

Terminology:  "Grp Y" may make sense to a technical person in IT, but it's not intuitive to business users.

Multiple Administrators: Multiple administrators and multiple systems need to be looked at to determine who can get to what. 

• The VMware vCenter Admins can determine which AD groups control permissions in vCenter. 
• The AD administrators can tell you who is a member of the AD group , taking into consideration nested groups, dynamic groups, etc in AD.

Market Needs:  Companies need solutions that provide visibility into the business functions that are assigned to people, rather than the low level IT attributes such as AD group membership.  The IT department is capable of making the connection between the application and the externalized AAA system (such as Active Directory).  Business users often cannot make the connection and hence don't have the visibility to fully understand the business functions assigned to workers.  Ideally a business would manage the assignment of permissions in terms of the application in a single step (Ex: Make Bob a Power User in VMware vCenter).  At the time of assignment, you could see the other business application permissions that would be carried along with the change (unintended consequences).  At any point, you could look at the infrastructure from the perspective of a person, a system, or an application permission to get the full picture of who is assigned which permissions:

• Connect a person to permissions in various systems
• Look at a system, view all permissions for all people
• Look at a permission on a system, determine people who have it assigned
• Look at the AD group (AAA resource) and determine what it controls (systems) and who has access (people)

With these capabilities in place activities such as assigning and managing access are simplified and the business has visibility into who is assigned which kind of access.