1 Comment

Summary:

This past weekend, beta-phase PaaS offering PHP Fog was hacked and vandalized by a couple of teenagers, a situation that raises serious questions about cloud security. But the questions aren’t just about technology; the case also raises issues about who’s ultimately responsible for security breaches.

Wisconsin_State_Prison_Cell_BlockWisconsin_State_Prison_Cell_Blocks

This past weekend, beta-phase PaaS offering PHP Fog was hacked and vandalized by a couple of teenagers, a situation that raises serious questions about cloud security. But the questions aren’t just about technology; the case also raises issues about who’s ultimately responsible for security breaches, what the proper consequences should be, and whether an apology and a detailed post-mortem is penance enough for a cloud provider’s mistakes.

PHP Fog Founder and CEO Lucas Carlson explains the details of the hack in a narrative on the company blog, but the gist is that an Australian teenager hacked into the PHP Fog servers and vandalized the service by sending users to an alternate URL, as well as by posting PHP Fog code and intellectual property on Twitter. Any real damage was minimal, and PHP Fog is undertaking a laundry list of steps to ensure this type of thing doesn’t happen again, but that certainly doesn’t close the issue. As the spirited debate in the post’s comments illustrates — a discussion kicked off by the successful hacker’s partner in crime — there isn’t a consensus on who’s really to blame or what should happen to the hackers now. I’m going to punt on the issue of whether jail time should await the 16-year-old alleged hacker — PHP Fog is looking into pressing charges and has contacted the FBI — but I think there’s plenty of blame to go around.

This type of hack seems pretty clearly illegal, so that an agency would at least pursue a criminal investigation shouldn’t be surprising. For the sake of the incredible number of people who conduct business online — a population that spans far beyond PHP developers and their PaaS provider — enforcement is probably necessary, at least to prove a point that malicious hacking won’t be tolerated. But, as many commenters point out, the wrongdoings of the teens involved don’t absolve PHP Fog of responsibility for operating a site apparently full of security holes and questionable practices. The ethical option would have been for the hackers to simply inform PHP Fog of the flaws they discovered so the company could address them, but anyone with a pessismistic bone in his body might have a hard time entirely dismissing the argument that PHP Fog deserved to be called out publicly.

At its core, the situation PHP Fog finds itself in isn’t entirely dissimilar to when cloud computing users don’t properly architect their deployments for maximum availability or performance in case something goes wrong on the provider’s end. It’s hard to feel too much pity when they knew things could have been done better but haven’t yet fixed those problems. After all, it’s safe to assume someone will be trying to hack your cloud service — whether for fun or just to prove that the cloud is insecure — and these concerns probably should have been fixed before opening the site to even private beta users, or at least before publicly announcing its presence and opening up the floodgates of malfeasance. You hate to see it happen, but …

As Carlson wrote in an e-mail to me about his takeaways from this incident, “Never put off security…. We wanted to upgrade our users’ security without causing any downtime for them. We should have moved faster in the name of security.” Yeah, it should have, but does that mean it needed to be outed publicly? Maybe the answer depends on whether PHP Fog, or any other cloud provider, would be as open about the flaws had they been revealed through proper channels as it was when the flaws were revealed publicly. We’ll never know the answer to that, but don’t customers deserve to know what’s being done around issues like security and reliability all along, not just after a successful attack?

There might be something to even proactive disclosure of security issues, actually. As anyone who has followed the spate of cloud outages by providers such as Google, Amazon Web Services and Rackspace over the past few years has seen, customers tend to be forgiving (sub req’d) when there’s a thorough explanation involved. In this instance, Carlson noted that “the PHP community has been very gracious,” possibly as a result of PHP Fog’s openness about what happened. “This is what they responded most positively to,” he added.

Cloud computing — especially PaaS — is still maturing, something users seem willing to accept as long as they get a proper apology and explanation. Why not continually nurture that forgiving spirit, perhaps forming an even tighter bond with users and mitigating negative reaction to future occurrences? After all, with more competition springing up daily and more important applications making their way into the cloud, an after-the-fact apology won’t cut it forever.

  1. Earlier this year the developer behind Duostack discovered a security hole in Heroku’s PaaS. He notified Heroku and it was disclosed. At the time, I suggested a third-party PaaS certification authority was needed.

    Share

Comments have been disabled for this post