Perimeter
9/10/2012
11:44 AM
Gunnar Peterson
Gunnar Peterson
Commentary
Connect Directly
RSS
E-Mail
50%
50%

What Identity And Access Management Can Learn From 'Car Talk'

Compliance-driven IAM results in the enterprise staring at a Chinese menu of options, and all they can do is point to one that they partially understand

In the old, pre-Web days, the cool kids who'd later grow up to be computer hackers worked on cars. While listening to the funny and informative radio talk show "Car Talk," I have often thought that hosts Tom and Ray Magliozzi would be computer geeks instead of car guys if born a decade later. Certainly, their rules apply to today.

During one of the last "Car Talk" shows, the hosts were reminiscing about how they used to open up their garages on the weekends and people could come in and use their tools to work on their cars. Tom and Ray started off each session with a series of rules, saying essentially, "You may think you came here to fix stuff. That is actually the third reason you are here. The first thing you are here to do is not hurt yourself. (Lots of ways to do this in a garage full of heavy cars and power tools). The second thing you are here to do is not break anything that's not already broken (curse of the tinkerer). And then the third thing you are here to do is to fix your car."

The distilled wisdom here is instructive to companies embarking on identity and access management (IAM) projects.

Companies typically launch an IAM effort due to:

A) architecture or design initiative for improvement

and/or

B) compliance makes them

The number of products, protocols, and standards in IAM is pretty staggering at first. Large vendors offer dozens of different IAM products. And all of that is before you get to integration. The end result is that enterprises are left staring at a Chinese menu of options, and all they can do is point one that they partially understand.

The enterprise points at something that looks appealing on the Chinese menu of IAM options; in doing so it thinks it is fixing an architecture and/or compliance problem. But now let's go back to the Car Talk guys' rules: Fixing an IAM problem is the third thing they should be doing.

The first thing is do not hurt yourself, specifically your career. Note, I am not advocating that CYA is the right approach -- people should absolutely take a little career risk when the situation calls for it. What I am talking about here is to understand that not all IAM products and projects have the same scope. They can be quite grandiose in scope, and expensive in time, effort, and complexity terms. Your auditor's recommendation likely does not factor this in, and blindly following that checklist -- without considering long run cost and available options -- can result in the career limiting move: championing expensive shelfware.

The second thing is do not break anything that is not already broken. This applies to integration. Your auditor will not be able to address this either; your architects should. Engage them. Make sure that an IAM solution makes sense for what it's trying to solve and that it works with current and future software. This means not only understanding the IAM solution, but further planning for IAM first-mile and last-mile integration.

On the organizational side it means having teams to support the product from architecture, design, development, deployment, and operations. Key to this is realizing that IAM skill sets are not part of most staffing plans, so consulting is guaranteed to play a role (read: cost). Of course, you don't want to rely only on external, so you will need a skills development program so that internal resources can take ownership.

Finally, who is "the owner?" By its nature, IAM impacts apps, data, business processes, security, usability, and compliance. You cannot simply create the right pragmatic approach to those concerns straight from an auditor checklist. Someone must build the IAM vision and plan how to execute it.

And then you can start fixing your IAM problem.

Gunnar Peterson is a Managing Principal at Arctec Group Gunnar Peterson (@oneraindrop) works on AppSec - Cloud, Mobile and Identity. He maintains a blog at http://1raindrop.typepad.com. View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4973
Published: 2014-09-23
The ESET Personal Firewall NDIS filter (EpFwNdis.sys) driver in the Firewall Module Build 1183 (20140214) and earlier in ESET Smart Security and ESET Endpoint Security products 5.0 through 7.0 allows local users to gain privileges via a crafted argument to a 0x830020CC IOCTL call.

CVE-2014-5392
Published: 2014-09-23
XML External Entity (XXE) vulnerability in JobScheduler before 1.6.4246 and 7.x before 1.7.4241 allows remote attackers to cause a denial of service and read arbitrary files or directories via a request containing an XML external entity declaration in conjunction with an entity reference.

CVE-2014-6646
Published: 2014-09-23
The bellyhoodcom (aka com.tapatalk.bellyhoodcom) application 3.4.23 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2014-6647
Published: 2014-09-23
The ElForro.com (aka com.tapatalk.elforrocom) application 2.4.3.10 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2014-6648
Published: 2014-09-23
The iPhone4.TW (aka com.tapatalk.iPhone4TWforums) application 3.3.20 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

Best of the Web
Dark Reading Radio