10 Habits of Highly Effective Security Vendors #1-3


In observance of the hallowed RSA conference going on this month at the Moscone Center in San Francisco, I have crafted some blog entries covering my thoughts on the industry, the market space and the state of affairs in identity security technology. My previous blog explored what it means to be a security vendor or purveyor in the current marketplace. This installment covers what I believe to be the first three of ten top habits of highly effective security providers and their solutions.

HABIT #1: Solve the problem, don't just sell a solution.

Twitter doesn't have to advertise. YouTube does not need to hammer users about why their video codecs are better, or not. But everyone still beats a path to their doors. Why? Because they solve problems - they don't sell solutions. You are always tainted when you have to sell your solution - so be extra vigilant that your solution actually does what it says on the tin as well as solves the customers' problems. If so, they will sell it for you. Sell them a security solution that you'd want to buy. Sell them one they'd get anyway - even if it was free - because its effectiveness is inevitable and incontrovertible. Rethink security as a product.

In case you want to argue with me that Apple still markets and sells their wares - and people clamor to get them - as some sort of causal relationship, I say - whatever. It's Apple. You go figure out how to be the "Apple of security" and I'll send you my resume.

HABIT #2: Stop relying on the user for their security. Nice to meet you (for the first time)!

Reality check: in the modern, social, mobile and long-tail Internet world, chances are your customers will never have met their users before they enter into the first transaction or session with them. These are not banks with branches or mail-order houses with catalog subscribers. Reality check #2: users are naive, and the sites or apps they use are often not much better at security. I don't mean that sentiment to be crass - what I mean is they are not "skilled in the art and science of self-protection when it comes to security, identity and general technology guile." Does that sound better? Either way, we must assume a lower degree of skill than our own (as security vendors) and no pre-relationship between our customers and their users. Why do so many security solutions rely on the user or the site so much? Dongles? Downloads? Tokens? Images? Secret questions? Password management? Come on.

The main failure point in most identity and security offerings is user choice. Educating the user helps, but not very much. Research has proven that identity solutions that rely solely upon user recognition, recall, or custody are simply flawed. Security is like a symphony - just one note can sour an otherwise perfectly executed piece of complex music. Password01 simply becomes password02 when you bother or force users to change it. Relying on the user for security is like putting a championship-winning coach in the Superbowl, and asking him to pick 12 random people from the stadium crowd to suit up, take the field and execute his well-thought out plays against a real professional team (hackers). Fans are not players. Equipment does not equal talent. Knowledge is not the same as skill.

Identity solutions need to "include" or "involve" the user (as well as the site) but not rely solely upon them as a single point of failure in the chain. The traditional shared-secret or 50/50 security puzzle between site and user needs to be reinvented.

HABIT #3 Get out of the browser business. Seriously.

SSL (secure socket layers) and TLS (transport layer security) are here to stay. Most online transactions, whether web or mobile-based, traffic over SSL using very strong keys that are rarely compromised or reverse-engineered and tampered with in real time. In reality, the most effective hacks happen either before or after the SSL layer, completely off CPU (social engineering), or deal with a different stye of attack entirely. A majority of identity solutions out there rely heavily on the browser for their operation - involving javascript fingerprinting, cookies, bookmarklets and other visual clues/cues, etc. When employing these techniques, one is merely using the browser to establish trust with the browser. This fallacious reasoning would fail the most naive test in any other scientific or logical rigor where integrity is the goal. You are using the very vehicle not yet trusted, to establish the trust. I could go on with other analogies, but you get the point.

However, as I am a strong opponent of the speaking in the abstract when discussing architectures and anecdotes, I'll offer a few practical examples. A majority of web, mobile and app-style functionality on the Internet today happens outside the browser anyway - in the grey net. What about these applications like Skype, iChat or GoToMeeting? Cookies and password forms are useless here as well. It's just bad business to rely on the browser for identity security. Let's say you deploy a very expensive token-based reverse-password generator solution. At the critical moment in the plot, the humble user merely types the critical 4, 6 or 8 character alpha-numeric code right into the good old browser (from their good old keyboard). The browser is a brochure, a TV screen that tells you what is about to happen, and what did just happen - it should not be relied up for establishing initial or ongoing trust. To achieve real trust, you must step outside the browser and independently triangulate the authenticity of the user, their device, the site/app and the session in context. How does one do that? There are a number of ways to accomplish this, including: OOB (out of band), separate communication channels, physical devices and the like. I won't discuss the merits or deficiencies of each - I will merely extol the virtues of doing something outside the browser. Just keep it usable. You don't want users crawling through layers of awful security muck like Andy Dufresne on his way out of Shawshank prison. But usability should not come at the cost of actual security effectiveness. If I see another SAML/javascript fingerprinting, cookie-based wrapper product touted as a "multi-factor authentication" solution, I just might hurl.

The users deserve something stronger, the hackers are smarter, and we can do better. Moving on.

Stay tuned for habits #4-6 in the next installment...