IAM for the smaller enterprise

My clients find identity solutions to be complex and costly to implement.  For mature and/or large enterprises, these issues are simply a cost of doing business — and compliance or online strategic drivers are usually sufficient to fund and launch an IAM initiative.

For the smaller enterprise there appear to be two paths followed: do nothing or do it poorly.  When done poorly, shoddy IAM implementations  can result in poor credential management, lousy availability and inappropriate access controls.

So how does a smaller company or organization deal with identity properly? How can users be efficiently identified online without building expensive, custom solutions? What service levels and supports are possible for a login service when staff go home at 5pm? How can niche needs like strong authentication be met without excessive server license costs and complex implementations?

Enter the cloud.  Cloud-based IAM service providers are maturing and there are a number of solutions that offer the smaller organization solutions.  For example:

• Symplified offers a full IAM service that promises plug-and-play integration with surprising depth, including support for mobile devices and apps.
• PhoneFactor has a slick and secure solution for two-factor authentication that can be licensed on a per-use basis.
• TransUnion have a robust identity proofing service for the critical process of confirming the identity of an online visitor.

Using one or more of these solutions allows for rapid deployment of IAM for smaller organizations.  The cost savings are considerable and services levels are beyond what most companies could hope to provide on their own.  There still remains integration work — applications need to be ‘plumbed’ to inter-operate with the cloud solutions — but all the heavy-lifting of designing and configuring a solution is eliminated.

The maturation of cloud IAM solutions means an increased number of companies can implement secure and compliant solutions without the long lead-times and high cost of traditional product-based offerings.  In this age of rampant data breaches and increased focus on compliance, this is a welcomed development.

Mike

Authenticating those youngsters

Why can't a device replace a password?

I had a really interesting conversation with a client last Friday.  I’ve helped them to build a public-facing identity management system for access to a range of web applications.  It has been running for over two years and has (literally) hundreds of thousands of users.

The chat went something like this…

CIO: As you know, our users are a bit of a younger demographic, and we’ve been noticing lately that they are having trouble remembering their usernames and passwords.

Me: Well, we’d expect them to use the forgot user ID or forgot password links on our login page…

CIO: But they don’t. Or if they do use those links it is confusing to them. We are seeing a spike in help desk calls.

Me (mystified a bit): Ummm… why is that? We use a pretty standard web page with links for these functions.

CIO: Yes we do. However, an increasingly large segment of our user base has grown up with smartphones, not browsers. They are used to apps and auto-remembered credentials.

Me (feeling elderly): Oh.

CIO: So what we need is a way to login to both web apps and device apps using just the mobile phone.

Okay, so it took a few minutes for this to sink it, but I get this. Younger users use mobile phones and apps predominantly, and the web browser experience is not the same for them as it is for us oldsters.

My own teen-age kids are proof of this — texting is definitely preferred over email, and I think I saw my 15-year old daughter tear-up last year when I upgraded her iPhone to a full data plan…

Teens, it seems, are most comfortable with a device.  And that device presents information and services differently than a web page does.  So differently in fact that it poses problems for authentication. This is really interesting…

There are two use cases to explore here.

• The first is the identity-aware app.  The app needs to authenticate the user in a way that is consistent with best-practices for protecting sensitive information.  It can’t just provide access without authentication because that would be against policy and create risks of breach that aren’t acceptable.  But it does need to be seamless and easy — because that is the way of the app, right?
• The second case is web login without username and password… Interestingly, a user ID / password combination is only single factor (something-you-know).  The replacement of this standard approach with something-you-have, i.e. a mobile device, shouldn’t be that hard.  For example, a user who has pre-registered their phone with us could get a one-time code sent via SMS to the phone.  They could then enter the code in order to authenticate.  No more forgotten passwords, no need to remember what username I picked.

Can these use cases be met within the policies and best practices established by enterprises? Or do we need to reconsider our approaches in light of a changing demographic?

Mike

Authentication issue at heart of lawsuit

If you have followed this blog for any length of time you’ll know that I often return to issues and opportunities related to strong authentication.  Last week’s news from eastern Texas is therefore of interest…

Apparently a customer of the PlainsCapital Bank lost $200,000 through one or more electronic transfers.  The bank offers what they claimed to be a ‘two-factor’ authentication service.  After a user name and password are entered, the ‘second factor’ for authentication is an access code that is sent to the registered user’s email address.  The access code is entered by the user and their computer’s IP address is recorded (presumably to protect the session and for audit purposes).  Unfortunately for the bank and its customer, the emailed code was intercepted by what appears to be a Romanian hacker and the money was stolen via an unauthorized funds transfer.

By definition two-factor authentication must include two of three different factors: something owned, something known or something inherent (e.g. a biometric).  The first factor in this case is the user name/password combination, which is something known.  The second factor, the access code, is also something known.

Because both of these are in the ‘something known’ category, this is not two-factor authentication.  It may be stronger authentication that user name/password alone, but it is NOT two-factor.

The bank seems to have made an assumption that this code is ‘something owned’ because it was delivered to an email address that is controlled by the registered user.  The problem with this is that the email account itself is very likely protected by a single factor (a user name/password) that can easily be collected by any garden-variety keystroke logger.  The very idea that email is a suitable platform for sending secure access codes is odd to me — surely by now we all recognize the flaws in sending sensitive information via email?

An appropriate solution would include two unique factors combined with ‘security in layers’.  A user name/password plus a code sent to a registered mobile phone would be one example.  But I also like the suggestion in the article that layering good process — such as contacting the client (via phone) before such a large transaction was processed — would have also prevented this incident from occurring.

Perhaps it’s time to revisit what our Canadian banks are telling us about their security controls before casting stones towards our southern neighbours. It seems to me that without both strong authentication and security in layers, we — and our proud, large and stable financial institutions — are just as likely to suffer from this type of loss as this Texas bank.

Mike

Why invest in IAM?

I find myself being asked this question, indirectly or directly, by clients and prospective clients alike.  With all the demands on IT infrastructure spending and business application development (and integration), and with all the information security risks out there waiting for solutions to be implemented, why should an investment in IAM be a priority?

From the well-respected Kuppinger Cole blog comes this view:

Part of IAM’s job is protecting data, either directly or by protecting the systems that use and store data. That is also the backdrop against which compliance regulation, both internal and external, must be viewed. That also means that it is much easier to talk with business people about “access” rather than about “identity”. The big question is how do we control and monitor access to information and systems? To do that, we need to know who is allowed to do what – and who isn’t. The only way to achieve that goal is through true digital Identity Management. Anyone who thinks he can do it by granting rights and approvals based on IP addresses or MAC numbers is seriously kidding himself.

It strikes me as odd that there are still IT and information security professionals that believe IP and MAC access controls are sufficient, but it appears that this myth persists in enterprises.

Worse, I believe, is the view that the home-spun access control that has been built into legacy applications is ‘good enough’.  Why replumb our existing enterprise and customer-facing systems with a new-fangled IAM solution when we have the problem solved already?

This is a powerful myth that can be hard to overcome. But compared to application-specific controls, IAM has some significant advantages:

• Compliance – Organizations today must comply with legislation and their own policies.  The access control sub-systems built-in to many legacy applications are simply not compliant, and it may require significant rework and duplicated processes to remedy.  Conversely, an enterprise IAM solution can be implemented to be compliant from the start, and a single set of processes can be created to maintain identity and access information.
  • Example: Privacy Impact Assessments (required in Canada for all projects that deal with personal information) can be done once and shared across all applications.
• Audit Support — ‘Siloed’ access control systems are very difficult to report on at audit time.  With IAM, consolidating information is much easier and correlating a user’s access through multiple systems can be achieved.
  • Example:  A single reporting tool or sub-system can meet most (if not all) auditor reporting needs.
• Help Desk Efficiency — With IAM, a single console for Help Desk agents can be implemented for end-user support purposes.  Naturally, a single system will offer improved efficiency and better service to end-users than multiple, application-based systems.
  • Example: Help Desk lookup tools can be standardized and easily learned by new staff. Password policies become consistent. Access to multiple systems can be suspended or revoked from a central point. Service to end-users improves.
• Leverage and Speed – New applications, especially e-business and e-government systems that have to deal with privacy and security issues, can be readily designed around a common IAM solution.  Deployments can be rapid due to standardized interfaces and re-use of common templates.  Processes can be leveraged, not rewritten from scratch, making the transition to a production environment more seamless.
  • Example: Strategic applications that need to be implemented ‘right now’ can be rolled-out quickly with high security, advanced features and appropriate user privacy protection. Decisions can be made with confidence that the common IAM solution will meet both enterprise and line-of-business requirements.

Real IAM solutions offer real value, making business case development easier and more compelling.  However, widely-held myths about the effectiveness of network and application-specific controls need to be dealt with if broader IAM implementations are to be approved, funded and supported.

Mike

v[ep_!)7@=2n9B

Yep, that’s the password my wife and food blogger Foodiesuz received from Food Network Canada last night.  Via plain-text email of course…

Lucky for her, Foodiesuz was not destined to use good ol’ v[ep_!)7@=2n9B forever.  (She’s busy! Who has 3 minutes to type a password anyway?) There was a link to change the password to something more friendly.  But the user selected password had no rules for composition as far as we could tell, i.e. it could be a simple dictionary word.

Perhaps most strangely, the new password takes time to be activated:

User Password Reset
You have requested that a new password be generated and sent to your email address(zzz@yourdomain.ca). Please allow up to 15 minutes for it to take effect.

What is the point you Food Network Canada people?!?  You’ve seriously missed the boat here with your password policy and subsystem:

• The value of the information being protected is nominal.  You don’t need a strong password, let alone the abomination v[ep_!)7@=2n9B…
• If you think the account needs such a strong password, why send it in plain text email? And why do you allow dictionary words when the user resets the password?
• And just what is happening in those 15 minutes anyway? This is very curious… Do you have someone typing a memo to be authorized by management?

Truly odd.

Mike