While looking into some of the finer points of SSL EV, I landed at Microsoft. Clicking on the fourth search result shown in the adjascent picture (”Extended Validation SSL Sites”) prompted my up-to-date Firefox (and Safari and Opera) to initiate what is without question the single least understandable and therefore the most unforgivable computer/human dialog in the history of technology.

In essence my browser said: “I don’t have a clue about who owns this website, so let me enlighten you with an incomprehensible dissection of its X.509 certificate so you can judge for yourself.”

Ok, this isn’t an EV-specific issue. And sure, I get X.509, but Quintessential Person sure doesn’t. And though I’m not a Microsoft basher these days, they have no business using a certificate authority that only IE 7 knows about. All in all, this qualifies as Bad Security.

1. Great Security • n., see good is as good as it gets

2. Good Security • n., see rare and quiet about it

3. Passable Security • n., see optimistic auditor

4. Weak Security • n., see no, it isn’t a business driver

5. Newsworthy Security • n., see damn, it is a business driver

6. No Security • n., see unlikely despite what security team says

7. Bad Security • n., see anything in the name of security that gives it a bad name

The industry has been buzzing about this possibly acquisition over the last 24 hours.  This article claims a $300-350M purchase price on $30M revenue.

By Kurt Seifried

The phrase “information security” results in about 5 million Google hits.

So why are there so many hits on “information security” I wonder? I suspect because risk management is a whole lot harder than handling income tax. Income tax. although complicated, does actually have a set of acknowledged rules (the tax code for whatever country you live in), and although this set of laws and acts spans a wide variety of topics and several decades (and in some countries centuries) we at least have a set of rules by which we play.

Information security has no set rules. We have guidelines and standards such as PCI, ISO17799 (which is actually a pretty good read) and Common Criteria to name a handful.

We have no widely accepted best practices, just look at the resistance to PCI (the deadline for compliance has been *AHEM* “extended”).

Although information security and risk management shares some tools with the income tax industry (such as auditors and audits) the systems being audited are vastly more complex and difficult to test.

In other words we have all the classic symptoms of a young and immature profession (and some might say ineffective).

So what’s the answer? I think we are making headway with various standards and guidelines, something is definitely better than nothing, and as they become more accepted and mature things should get better. Hopefully some day we’ll have an information security equivalent to GAAP (Generally Accepted Accounting Principles). Of course to have this we need products with reliable and predictable behaviors, especially in abnormal situations (e.g. malicious input such as SQL injection attempts, etc.). In all fairness this probably won’t happen without some significant changes in the way security is built (not a single major method specifically addresses security). So we can add a whole new set of software development paradigms to our wish list.

But like JFK said:

We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.

If we can get to the moon with 60’s technologies we should certainly be able to prevent people’s personal information from being sold in IRC chatrooms.

ITCi invites you to attend this unique education and networking event focused on solving your most complicated and pressing security, audit, content, and risk management challenges.  Expert presentations and networking events will expose you to best practices, peer experiences, and authoritative advice that will give you insight and information on how to create strong and defensible IT compliance programs.

See the Conference at a Glance for more details. RiskBlogger’s very own Jim Reavis is a session chair, and Larry J. Hughes, Jr. is lead presenter for two sessions.

I wrote the other day about what a big fan I am of PCI, and why I’m happy merchants are rebelling against it.

Although this is a win-win of sorts, I nevertheless can’t help but see this playing out in a way that gives security a bad rap:

1. We build and start using pieces of technology under one set of assumptions. “Let’s build us some networks and databases to share information!”
2. Later, we start using that technology more and more under an expanded or different set of assumptions. This is usually a long, iterative process. Eventually, it’s “Let’s transmit credit cards over our networks and store them our databases!”
3. Much later, we recognize that some of our incremental uses have long since introduced serious risks. “Oops!”
4. We ignore those risks as long as we can. “These are not the security ‘droids you’re looking for!”
5. Once our hand is forced — “PCI fines are how big?” — we invest enormous sums retooling technology we created way back in step 1 to support all the new cases we garnered during steps 2-4.

Often step 5 is the right way to go. Business pragmatism has a way of dictating this, as it did the whole process in fact, and generally speaking I don’t have a problem with it. So long as we’re honest about it.

But smokescreens aren’t honest. This is where the credit card companies have failed us. Had they been honest with us a few years ago, they would have mandated a five-year program to wean the industry off of legacy credit card processing and on to SET.

The reason they didn’t, of course, is obvious. With SET, who inherits the burden of liability that results from card theft?

But despair not, merchants. Even without SET there are still plenty of good ways to offload liability from credit card theft. It’ll take strength in numbers to convince the card companies to cooperate though. The technology itself isn’t as revolutionary as you might think, as I can attest from championing preparations for it at Amazon.com.

My latest post at the Entitlement Management Blog is here.  Let’s have a safe and sane migration to Web 2.0 within the enterprise.