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-2006-1318
Published: 2014-09-19
Microsoft Office 2003 SP1 and SP2, Office XP SP3, Office 2000 SP3, Office 2004 for Mac, and Office X for Mac do not properly parse record lengths, which allows remote attackers to execute arbitrary code via a malformed control in an Office document, aka "Microsoft Office Control Vulnerability."

CVE-2012-2588
Published: 2014-09-19
Multiple cross-site scripting (XSS) vulnerabilities in MailEnable Enterprise 6.5 allow remote attackers to inject arbitrary web script or HTML via the (1) From, (2) To, or (3) Subject header or (4) body in an SMTP e-mail message.

CVE-2012-6659
Published: 2014-09-19
Cross-site scripting (XSS) vulnerability in the admin interface in Phorum before 5.2.19 allows remote attackers to inject arbitrary web script or HTML via a crafted URL.

CVE-2014-1391
Published: 2014-09-19
QT Media Foundation in Apple OS X before 10.9.5 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted movie file with RLE encoding.

CVE-2014-3614
Published: 2014-09-19
Unspecified vulnerability in PowerDNS Recursor (aka pdns_recursor) 3.6.x before 3.6.1 allows remote attackers to cause a denial of service (crash) via an unknown sequence of malformed packets.

Best of the Web
Dark Reading Radio