Adventures of an Eternal Optimist

I am stuck in an interesting dilemma.

I love my web hosting company, I think the people are great, the tools and support are top notch, and the price is right.  I was, in fact, thinking of upgrading my service with them.

But I cannot ignore the fact that on my particular server, they haven’t updated their openssl libraries in 5 YEARS.   Five.  By my count, they are 20 revisions behind the current library version.

This means that there is a list of exploits as long as my arm that can probably be used against the various sites that I sponsor, including the Pamela Project and OSIS. The big problem is that I’m using a shared Apache infrastructure, and while I can recompile PHP and Curl to use up-to-date libraries, Apache does a lot of the heavy lifting when it comes to transport-level security, and as far as I know, I cannot affect the modules that load into that shared webserver environment.

Obviously there are actions that I can take to ensure my own security.  I can change web hosters.  I can upgrade to a server where I have access to my own apache configuration.  The standard answer here is that if I don’t like what I’ve got I should leave.

But – what about the folks on my server who don’t even know they are at risk?  Who are running shopping carts and who just assume that they are on a well-patched, secure server?  By silently walking away from an insecure environment, am I in fact aiding and abetting the web hosting company in their terrible security practices?

I have in the past contacted support about updating SSL libraries when various remote holes were found.  I won’t quote their answer because I don’t have the email to back up my recollection, I didn’t think to save them, but the version number speaks for itself:  0.9.7e.  The current version is 0.9.8k.  I’m not a big customer, and I know that by paying more I could become more secure — but must it follow that by paying less I have to be at risk?   I already pay extra per month for SSL support, and also for the unique IP address that is a pre-requisite.  Do I have to get hacked before I have a case?

So I ask you all — for the small number of us who know better — what’s the right way to proceed?  Do I silently act to ensure that I myself am secure, leaving all those other poor uneducated suckers to continue in ignorance and risk?  Do I make a stink?  I doubt I have the clout to cause this very large company to do anything.  Yet, if I don’t, who will?

Update: I received a response to my separately sent inquiry to the security team just now (told you they are responsive):

We run Debian Linux. Debian does not put new upstream releases, even point releases, into a stable distribution. What happens is that only the security fixes are backported into a package in stable. This minimizes the possibility for the stable release to be de-stabilized by new code introduced upstream.
So while the version of libssl0.9.7-sarge5, it should nevertheless incorporate all the security fixes present in 0.9.8k.

So, the good news is that I’m probably safe, and the team is on top of it.  The bad new is that I simply have to trust it is so, I don’t see a way to easily independently verify.

Glue 2009.  Where to start.   This is the conference entry — learnings and philosophical interpretation to follow separately :)

My impression of the group was that it consisted mostly of the “maker” community — developers, entrepreneurs, and funding bodies working to create solutions in the cloud.   Everyone was bound by a common philosophy driven from a common business model and delivery mechanism.  I loved the esprit de corps that I saw among this diverse group.

Most vendors were new to me, and walking the booths was anything but humdrum. Given that so many of the attendees also had services of their own, I would have loved it if Eric and Kimberly could have set up some kind of fun elevator pitch or Pecha Kucha session where each of the attendees could run up and explain what they were up to, in the constraints of a social, time-boxed, creativity-encouraged event.

Speaking of Kimberly and Eric (the organizers of Glue) — bravo.   This was not a case of catering to a community.  This seemed to me to be a case of creating bonds anew.  It is really easy for conference communities to become inbred – eventually it becomes the same set of people viewing the world all in the same way, and agreeing and disagreeing in unison as if the “truth” was universally obvious.  The great joy of this space is that there is no universally accepted “truth” yet — but the danger is in repeating historical mistakes.   I think that Eric’s agenda choices were calculated to do two things:  to introduce those on the front lines to the cautions of the past but also to introduce those who make their livings through cautionary tales to the infectious optimism of this new generation of solution providers.   The best part about it was seeing just how much fun Eric and Kim have working together to make it happen – it was smooth, but still personal.

I’m really excited about the new people I’ve met, please don’t be strangers, you are are sharp and you are pursuing some incredible opportunities.  I can’t wait to see where you go.

I’ve been listening and watching lately, and there are some interesting independent things happening that I expect could knit into a very entertaining next 3 quarters.  Something is telling me to swing away;  so here goes.

Identity Management Tool Hiatus

The Sun/Oracle takeover has everyone aflutter over which tools will stay and which will go, and what the resulting stuff will look like.  I think the interesting thing is that no matter what happens, you can pretty well guarantee that while Oracle sorts out what to keep and what to shelve, both Oracle Identity Manager and Sun Identity Manager will come to a developmental standstill.   Coincidentally, this matches the Microsoft delay of release to manufacture of MIIS/ILM/FIM.

Navel Gazing

Even before the announcements above, all was very quiet on the home front for IdM.  It seems obvious to me that all the big stack vendors have scurried off into their war rooms and are frantically trying to figure out how to set up their stacks to transparently support the rollout of cloud offerings.  This means there is probably an architectural pause going on, as everyone tries to get from theoretical to concrete with their sanity and business plans intact.

Immediate Status Quo Interruption

Meanwhile back in the real world, cloud mania is causing every Tom Dick and Harry who runs a software shop to ask themselves whether they could offer their product as a service.  While the think tanks are pondering the cloud as a big fat integrated platform offering,  a whole new generation of application vendors are simply putting their software online as services, any which way they can.

Short Cuts and Regretful Choices

The services out there now have not had the benefit any kind of cloud philosophy.  Applications are offering the usual set of poor choices for access and user management, doing the bare minimum so that they can focus on their “core” service.  Lured by attractive cost and immediate gratification,  Enterprises won’t see the risk, and won’t think to do two critical things: track beyond the departmental level what services are engaged, and set policies around minimum security requirements.

Stir it all together and…

So where do all these little tidbits take me when I connect the dots?    I see a big issue looming on the horizon: a proliferation of untracked administrative web interfaces on the open internet, protected by unencrypted and buggy login forms which are open for anyone to probe.  Even in cases where the login process itself is reasonable,  Enterprise assets are at the mercy of the quality of an admin password.   Ask Twitter, it’s a big problem.  Crack one admin password in a poorly-secured application, and you may gain instant access to many other better-secured services – unless of course you really believe administrators will use a different password for each of their multiple services.

With the advent of these kinds of issues,  provisioning could transition from being a back-room necessity with minimal business impact and no real SLA requirements, to being an activity that incurs serious risk for the organization.  Enterprises will realize that they need to do one of two things; add an extra physical layer of security to each and every administration console, or pull those consoles off of the internet altogether, opting instead for an automated API call that can be locked down six ways from Sunday.  You better believe that application vendors will go along for the ride; submitting to one of these choices is a lot better than having Enterprises simply abandon services and return back to intranet solutions.

The big Identity players do not have the agility to respond properly to these kinds of pain points;  but the little guys do.  I think that a few small agile companies are going to swoop in and provide consolidation services for administration console interfaces in the cloud.   Others will create Identity Provider services and products that allow the Enterprise to distribute 2-factor authentication tokens for use at multiple sites on the internet.

Somebody is about to steal home.   Who will it be?   Come to my Glue Talk and we can debate in person…