Research

With our last post in this series on Understanding and Selecting Cloud Identity and Access Management, we want to help guide you through product selection. No two customer environments or lists of requirements are the same, but key decision criteria will help you narrow down the field to suitable platforms. We will provide questions to help determine which vendors offer solutions that fit your architecture, a set of criteria to measure the appropriateness of a vendor solution to your design goals, and help walk you through the evaluation process. Your mileage WILL vary Spoiler alert – there’s no such thing as plain vanilla IAM. You may need a solution for customers as well as users. You may or may not need to include mobile devices. You may need fine-grained authorization controls for external applications. There are far too many variables in play for IAM evaluation to be fully quantifiable. But to help you weed out some players, to align your needs with product function, and to give you a handle on major product differentiators, we created the table below. You need to make sure products match your goals. Even IAM suites that can do everything on paper have their own strengths and weaknesses, so make sure you know them before leaping in. As we have discussed, prospective buyers should start with understanding their use cases and governance processes before analyzing the IAM marketplace. That said, here is a proposed checklist for beginning to analyze IAM products: Product Architecture What are the product’s key capabilities? What are the internal data models and formats for identity? What are the external data models and formats for identity? How does the product scale, vertically or horizontally? Development What is the development interface for implementing and extending the product? Is development typically performed by the company or third party consultants? Answer for both development and maintenance phases. What integration is available for source code and configuration management? What languages and tools are required to extend the product by with wrappers, adapters, and extensions? Interoperability What IAM standards are supported and where are they available in the product? What interfaces are standards based and what are proprietary? What directories are supported – Active Directory, LDAP …? What application servers are supported – Websphere, IIS, Tomcat, SAP …? Are cloud applications supported? Which ones? Are mobile platforms supported? Which ones? Product Security What is the product security model? Is Role-Based Access Control supported? Where? How is access audited? Use Case Support Describe the product’s support for provisioning uses Describe the product’s support for Singe Sign On uses Describe the product’s support for attribute exchange use cases What user self-service capabilities does the product support? Cost Model How is the product licensed? Does cost scale based on number of users, number of servers, or something else? What is the charge for adapters and extensions? This checklist provides a starting point for analyzing IAM products. As the evaluation unfolds, it is key to remember what matters: integration, standards, and cost. The buying process works much better if the initial step includes an inventory of IAM sources and targets: where identity is used, and what the authoritative sources are. What IAM processes exist currently, and which and are desired in future? POC FTW Securosis highly recommends a Proof-of-Concept (POC) as a final step for IAM buyers. PowerPoint does not crash much, but new implementations do. There is nothing like seeing a product working in your own environment. If there is more than one vendor in play – and there usually is – then bake-offs can be useful to determine the best fit. But we generally do not recommend bake-offs with more than two vendors. Many vendors take widely different conceptual approaches to IAM problems, and in-depth evaluations are too demanding to perform more than once or twice. Start with an initial review, against our checklist, to weed out unsuitable candidates. Then use a proof of concept to test viability and/or a bake-off to compare a couple similar candidates. Share:

As if the IBM Security Systems folks weren’t busy enough with the RSA Conference last week, they flew directly from San Francisco to Vegas for their annual Pulse Conference. Sure it’s a lot of back-patting and antennae rubbing, but there is usually a good nugget or two from their customer presentations. In this photo one of IBM’s companies highlights 7 reasons it is important to decide on the initial use cases for your SIEM before you buy it. I particularly like a few of them: 1. “Help with vendor selection – evaluate competitive SIEMs against use case criteria and forms requirements for purchase.” When I was in the SIEM space, trying to push 7-figure purchases, it was much easier when we could dictate the terms of the proof of concept (PoC). We’d test stuff we knew would work well, and that competitors couldn’t match. Of course that didn’t necessarily involve solve the customer’s problem. Oh, well. Enterprises should be driving the criteria for purchase and the PoC, and you do that by defining the initial set of use cases that drove the funding of the project anyway. 4. “Companies considering a SIEM should build a use case portfolio before even looking at a technology.” 6. “Understand quick wins/short term successes vs. long term roadmap (where do you want to be in two years).” I cannot tell you how many conversations I have had with folks looking at SIEM, who couldn’t tell me specifically what problem they were trying to solve. The initial use cases are really table stakes for SIEM procurement. It is critical not to choose a technology that will prevent you from doing things (like packet capture) in the future, as your program and needs evolve. But if you don’t have a clear idea what you want to do first, you are very unlikely to succeed. Share:

I think I’m finally waking up. After a week at RSA where I basically don’t sleep – not all bad, mind you – it takes a while to recover. In fact Monday might as well not have happened – I certainly got nothing done. It was not for lack of trying, but I was simply part of the zombie apocalypse – but I don’t want brains, just some Captain Crunch and sleep. Today I had the ‘Oh crap!’ realization – I promised people things last week, and I need to deliver. As much as I’d like to shuffle this stuff onto Rich, he has got a new baby and won’t take my calls. Something about taking it easy and enjoying time with the family. On the subject of the RSA Conference, I have to confess I’m not usually surprised by trends at RSA. If you read out pre-RSAC stuff, you noticed it was clear to us that Big Data and malware were going to take center stage, and those trends did not disappoint. But we are never quite sure whether we are going to run into grumpy vendors spewing forth about their dissatisfaction with foot traffic, booth space, and the lack of quality leads. This year … none of that. In fact most vendors told me traffic was up and, more importantly, prospects were seeking them out. They were happy. It certainly made the week a lot more fun, but happy are a bit like Mike Rothman’s smile – rare and it makes me nervous. The other thing that really surprised me was that every single vendor seemed to be asking for help locating talent. Penetration testers, product managers, marketing managers, engineering managers, researchers – you name it. But I am not aware of any seasoned security people who are looking – quite the opposite. I did not anticipate the security industry hiring so heavily, but that’s a good thing, and another sign that things are humming along. Let the good times roll. You know what else surprised me? The force field surrounding the Huawei booth. Okay, maybe there was no actual force field, but people walking the show floor acted like there was. They kept a curious 2-3’ distance from the booth. Maybe their schwag sucked. Or perhaps it was Huawei’s lack of booth babes. Or maybe people are pissed about the Mandiant report and think of Huawei as part of that whole fiasco. I don’t really know, but most vendors were humming with activity, yet the half-dozen times I went by their booth they were noticeably un-busy. –Adrian On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Our own ‘Mark’ Rothman’s DR post: You’re A Piece Of Conference Meat. snort Adrian’s Pragmatic Database Security Presentation. Favorite Securosis Posts Adrian Lane: Karmic Balance. I have witnessed 25 years of shenanigans, and it has turned out that most wrongs met their karmic opposite at some point. David Mortman: Flash! And it’s gone…. Mike Rothman: Karmic Balance. Yeah, I’m a homer for favoriting my own Incite this week. But it sums up what I’m about. Like most folk I have been scarred and battered and bruised. But I try to make those negatives into positives whenever I can. Other Securosis Posts Understanding Cloud IAM: Buyers Guide. Use cases are your friends. Isolating the Security Skills Gap. Be Careful What You Wish for…Now You’re CISO. Announcing the CCSK UK Train the Trainer Class in April. New Paper: Network-based Threat Intelligence. Friday Summary, RSA Edition: March 1, 2012. Favorite Outside Posts Dave Lewis: Time Stamp Bug in Sudo Could Have Allowed Code Entry. Gunnar: Google services should not require real names – Vint Cerf. Two years back Bob Blakley brought us on a quick tour of the weak points of Google requiring real names, in a word: insane. Adrian Lane: Creating and Validating a Sock Puppet. Everyone should have a couple of these. They come in handy. David Mortman: Barn Doors. “Mobile is just an amplification of all the insecure practices you and your company have been using for decades.” – Sing it, sister! Mike Rothman: Cisco CEO: We’re All In On Internet Of Everything. In the NSS (No Sh*t Sherlock) list this week, Cisco decides it’s in their best interest to drive “The Internet of Things.” Duh. But as we wrote in the RSAC Guide, the Internet of Things is something to keep an eye on. Check it out for the hype, but stay around because there will be all sorts of devices connecting to your stuff. Project Quant Posts Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. Top News and Posts Appsec at RSA 2013: nice recap. Oracle Issues Emergency Java Update via Krebs. Details of the February 22nd 2013 Windows Azure Storage Disruption HP Exec: We’re Investing $1 Billion in Big Data This Year Understanding iOS passcode security The Phoenix Project Critics: Substandard crypto needlessly puts Evernote accounts at risk Evernote plans two-factor authentication following last week’s hack Recent 10-Ks mentioning “cyber” incidents Java malware spotted using stolen certificate Google+ Can Be A Social Network Or The Name Police – Not Both Blog Comment of the Week This week’s best comment goes to Matt, in response to Attribution Meh. Indicators YEAH! if for no other reason than becausae he put a lot of thought and effort into it. The greatest significance can be found in this report’s overarching message to China: we see you and we’re doing something about it. This may well represent the catalyst for major geopolitical change. The value of this report is that it will likely disrupt the adversary’s operational capability for some time as corporations bolster defenses. The adversary is no longer a vague term referring to an unknown group somewhere in the world. We’re talking about the government of China. We’re talking about disrupting their