Courion Corporation

Cloud Security Alliance – Helping Secure the Nebulous Cloud

It's no mystery that cloud computing is the current hot topic in the industry.  Whether it's the next major "paradigm shift" (I shudder at the mere use of the term) or it's merely enjoying its 15 minutes of fame, it clearly has industry buzz.  Cloud computing security is riding this wave as well, with much discussion, focus, and vendor marketing aimed at the subject at the most recent RSA Security Conference in California last week.

In good timing, the Cloud Security Alliance recently published its initial report, "Security Guidance for Critical Areas of Focus in Cloud Computing".  I agree with the alliance's belief that cloud computing represents an important trend that has the potential for major change in business with its increased adoption.  I think the alliance is spot on that the basic tenants of security:  good governance, managing risks, and common sense, do not change.  But, it's paramount that security professionals get ahead of the curve to address the security issues as the business adopt cloud computing.

The mission of the Cloud Security Alliance is to provide best practices to secure cloud computing.  Its initial report makes great strides by outlining areas of concern and guidance for organizations adopting cloud computing.  Key areas identified include governance, audit and compliance, and Identity and Access Management (IAM).

While we are encouraged to see IAM addressed in this initial report, the primary focus is on the need for a robust federated identity management architecture, its insistence on standards such as SAML, WS-Federation, and Liberty ID-FF. and authentication.  The governance and audit sections also highlight important best practices.  While we wholeheartedly agree that these are important tenants, it's also important to address other key areas of IAM focused on identity administration and audit and instilling a strong Access Assurance framework.

The complexities of ensuring that the right users have the right access to the right resources and are doing the right things with them are increased with cloud computing.  Just as the alliance states, strong security practices do not change with cloud computing.  This applies to access assurances issues as well.  But, managing them can be more complex, time consuming, and open to error and oversight.  Access Assurance best practices are a critical component to managing this increasingly important computing (dare I say it) paradigm.

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.... 

FUD in the Sun

Following the recent announcement of Oracle's Sun acquisition, Ashraf Motiwala has a good post in his blog describing how Sun convinced a client that a "boutique vendor" was risky as it was more likely to fail or be acquired. Now that client is worried about what's going to happen to their investment, "because of the heavy overlap between the Sun and Oracle product lines".

Oracle Buying Sun: Defining IAM Vendor Viability

Yesterday Oracle announced it had agreed to acquire Sun Microsystems.  My friend Dave Kearns sent an email asking for reaction (for those of you unfamiliar with Dave's work, I strongly suggest you subscribe to his blog and identity management newsletter) and it got me thinking.  Oracle's positioning is talking about providing an integrated system from "application to disk" and also lauds the merits of having Solaris and Java at its disposal.  But, nowhere do you hear anything about identity management.  This is of no surprise as the acquisition was not motivated by a strategy of combining identity management solutions.  However, if you're a Sun identity management customer, you have to be concerned due to the significant overlap between Oracle's and Sun's IAM product lines.

So, this got me thinking about the importance of the "new" vendor viability.  As an independent player who is a wee bit smaller than some of the companies we compete with in the IAM market, Courion sees vendor viability thrown in our faces at times in competitive situations.  Although we've demonstrated product innovation and leadership (according to Gartner and Burton Group among others) and are recognized for a strong track record of customer success at a fraction of the overall implementation and service costs, our competition (including Sun) would throw the viability FUD in there to try to wrestle deals away.  Comments such as "They're too small"; "They're not going to be around much longer"; "We're going to crush them" have all been things we've heard in selling cycles for a long time.

Well, I believe the Oracle Sun acquisition highlights where the real viability concerns lie.  Clearly the IAM business was not a consideration of Oracle when acquiring Sun.  There is tremendous overlap between the product sets and one can only suspect that Oracle will be announcing an end of life plan for the Sun Identity Manager products before too long. 

Consider other announcements over the last few years.  HP acquires Trulogica as an entry into the identity management market only to announce a few years later that HP was getting out of the business.  Similarly BMC announced it was dropping traditional identity management.  After acquiring Netegrity, much of the original Business Layers identity management products have been "evolved" by CA under a completely different architecture.  It sure appears to me that size has nothing to do with IAM vendor viability.

IAM is what Courion does.  We can't afford to give away hardware, operating systems, databases, or anything else if the project goes bad.  We must have customer success for each and every project as there is no other way for Courion to "make it up" to the customer.  Clearly a company like Courion is not planning on getting out of the IAM business.

IAM is a strong and growing market, and is still a top priority in even the current economic climate.  But, when vendors use their IAM business as a way to help pull other products and push infrastructure on customers, success is measured in more than pure IAM revenue.  True vendor viability concerns should be focused on these larger organizations and prospective customers need to look carefully at the nature of their commitment and the viability of their overall business.   The commitment these organizations have to IAM should be a major concern.  Courion's focus for IAM is to solve real, critical business problems.  Its purpose is not to sell other pieces of infrastructure.  This is what we do and we like to think we're doing it pretty well.  We're growing.  We're profitable.  We've got a customer base full of happy customers.  That all sounds pretty viable to me.

What are your thoughts?  

Biggest Data Theft Threat?

A couple of newly released studies on data theft are contradicting the avalanche of recent data suggesting that "insider" security attacks were more prevalent in 2008 than external hacking.  While it's interesting to note that insider breaches continue to be much more damaging, the 2^nd annual Verizon Business Breach study (a complete PDF copy of which is available here: http://tinyurl.com/c59gjo) found that 64% of breaches were external hacks that resulted from third-party remote access of default credentials.   The Verizon Business study includes recommendations for bolstering access controls, including frequent changes to default credentials, limiting shared credentials, regular review of user account privileges, and ensuring effective termination procedures.

In addition, the Computing Technology Industry Association's (CompTIA) 7^th annual security research study revealed that while a significant number (31%) of respondents said their breaches came from inside their companies (whether accidental or malicious), the majority of breaches were still caused by external attacks. 

It's interesting to note that after all the increases in security spending, businesses are still finding themselves vulnerable when it comes to their ability to prevent unauthorized access.  As the Verizon Business study points out, "87% [of breaches] were considered avoidable through simple or intermediate controls." 

The bottom line here is that whether you're talking about internal or external threats to corporate data, companies need to be sure to constantly review their access assurance policies and identify the right processes to ensure that access to default credentials are locked down.  After all, criminals will usually take the path of least resistance, and unfettered access fits that description all too well.

ESSO and Access Assurance

Sometimes customers tell us they're considering implementing enterprise single sign-on (ESSO) and that this is going to solve their IAM problems. After all, all the user has to do is sign on once to the SSO system and it will automatically log them onto all the other systems the user needs access to, right?

Not so fast... ESSO is a great tool for delivering a high level of convenience for users, especially those who need to log on and log off various systems quickly. The classic example is a doctor in a hospital moving around from patient to patient. Doctors are notoriously busy and can't be expected to log on to a dozen or so applications every time they need to electronically review a lab result, order a test, or fill out a prescription.

However, implementing an ESSO solution doesn't mean that's all you need. In fact, implementing an Access Assurance strategy is the best way to gain the most effectiveness and efficiency from your ESSO solution.

Why?

Because ESSO is primarily focused on access authentication. Transparently authenticating a user to multiple back end systems with one log on definitely provides value. But, who configures and manages the accounts and access rights on the target systems? Not the ESSO system; it handles authentication (and password resets, when required.)

In order to create and manage IT accounts and access rights in the first place, you need an Access Assurance strategy, which includes:

• Access Governance- defining enterprise roles, using role management software, and corporate access policies for the various systems that users need to access. Access Governance lets you define what systems the user needs access to, and what his/her access rights should be-in other words, making sure the right person have the right access to the right resources.
• Access Provisioning-once you have defined the accounts (whether through policy or more explicitly using role management), access provisioning is used to implement the policy by creating accounts on target systems and configuring user access rights.
• Access Compliance-if the organization needs to demonstrate that personnel have access rights that are consistent with policy or regulations, access compliance drives compliance attestation and reporting.

An important practical consideration to remember is that a provisioning solution can also provision the ESSO system directly-essentially opting in a new user by default. Otherwise, the first time a user tries to log on, the ESSO system must walk them through a registration process, where the user provides the ESSO software with the username, password and other authentication information required for each target system. If you have 15 or more target systems (email servers, applications, databases, enterprise directories, desktop PCs, etc.), the ESSO system has to capture the user's access information for all 15 systems before it can log them on. Provisioning eliminates this hassle, since the ESSO system can be initially provisioned with all the data (user name/password, etc.) required for authentication.

And, of course, it's important to ensure users have the appropriate access rights before you go making it easier for them to access systems or applications they shouldn't have. This is why security policies must be enforced every time you add or change user access rights.

ESSO is important to many customers, but don't forget that an effective Access Assurance strategy will help you get the most value from your ESSO system.

Privileged User Access Assurance

Adam Bosnian recently noted in an article he penned in SC Magazine the importance of privileged user access and the risk of poor controls around privileged users.  We clearly see this as a critical issue that our customers and prospective customers are trying to get their hands around, and it's critical that privileged accounts are considered as part of a broader access assurance strategy.

Access assurance, for those not familiar with the term, is ensuring that the right users have the right access to the right resources, and are doing the right things with it.  One of the most popular questions I get when I'm on the road talking to companies is, "Where should we start?"  We often find organizations taking a tactical jump into access assurance.  Often it's driven by an audit finding.  So, if it's a SOX audit, it's the key financial apps they start with.  If HIPAA it may be clinical applications.  If it's a finding around accounts still in place for users that left the organization, it's a focus on disabling user access.

Organization need to take a step back and prepare a comprehensive access assurance strategy.  The key is to look across the environment and build a phased plan with some key initial wins.  This should be driven by the highest areas of the risk in the organization.  You should try to avoid the fire fighting approach trying to stomp out little fires all over the place.  Build a plan and make sure to include privileged user access as part of the broader identity and access management program.

It's important to take this comprehensive view to lay out a continual process for access assurance.  Define who should have access to what.  Enforce and apply that access.  Detect when access or activity is beyond the scope of policy.  Correct variances from policy and coutinously evaluate if the policy is appropriate.  This applies to privileged and common users alike.

Bringing Clarity to the Cloud (Manifesto)

Earlier this week, the Open Cloud Manifesto was announced by a number of major vendors. The cloud computing movement (if that's the right word) has tremendous potential, but our customers have told us time and again that before they can seriously consider moving mission-critical applications and data onto cloud-based platforms, they will need the same levels of access assurance that they require for internal applications. As a result, we were pleased to see the Manifesto authors specifically point out that security, including identity and access management, is essential for cloud-based applications to be successful, "Many organizations are uncomfortable with the idea of storing their data and applications on systems they do not control. Consistency around authentication, identity management, compliance, and access technologies will become increasingly important."

It has always been Courion's view that all companies have heterogeneous environments and their IAM solutions must be able to interoperate seamlessly across their entire range of enterprise applications, regardless of where they are relative to the corporate firewall.

Octomom Patient Privacy Breach

It was reported yesterday that 15 hospital employees were fired, and another eight disciplined, for viewing patient records without permission.  It appears that the employees of Kaiser Permanente Bellflower Medical Center viewed the patient records of infamous octuplet mother Nadya Suleman, (aka  Octomom) without a medical reason.

This is just the latest incident in which private patient records have been accessed by employees in violation of hospital policy and healthcare privacy laws.  A similar story broke last year at UCLA hospitals where medical records were violated for various celebrities including Britney Spears and Farrah Fawcett leading to firing, suspensions, and warning for approximately 175 hospital employees.

It's critical that organizations truly understand who has access to what.  Is this access appropriate?  Is it within hospital policy?  Does it violate HIPAA policy?  As may, or may not, be the case here, the access itself may be appropriate, but the activity was not.  These employees may have had valid access, but they had no right snooping into Octomom's medical information.  It's critical that organizations gain control not only on access, but on user activity as well, and ensure this is within policy.

Today's healthcare organizations can't be too careful when it comes to ensuring that their users only have access to what they need in order to properly perform their jobs.  As I discussed in a recent blog posting (HIPAA Compliance - This Time We Mean It)   The Department of Health & Human Services has really stepped up their enforcement of privacy laws recently and it's more important than ever that hospitals employ every tool at their disposal to protect patient data from such breaches - or risk severe penalties."   This is going to be particularly important for California hospitals like UCLA and Kaiser since California Gov. Arnold Schwarzenegger recently signed into law legislation that increase state fines for security and privacy violations involving patient health information. The bills include mandate security controls for preventing unauthorized access to patient data.

Developing an access assurance strategy can provide strong controls for protecting privacy information and complying with regulations like HIPAA.  It's imperative that organizations take steps to properly define the policy around who should have access to what, ensure they have the ability to enforce this policy, continuously monitor and detect when access and actions are inconsistent with that policy, and remediate and document when policy violations occur.