Clearing up the Sony FUD

OK listen, it sucks that some thieves stole your name, address and hashed passwords. I get that. Sony should be held accountable on some level, though I’d say the thieves more so.

But I’m so SICK and TIRED of the professional game bloggers making everything look so much worse than it is, spinning things to make it seem like Sony all but rolled out the red carpet for the thieves. I’ve seen it on Destructoid (though to their credit, they went back and updated the post later), Kotaku, Joystiq, Gamespot, Massively… all saying some variety of “Experts say that Sony had unpatched servers and no firewall, and knew about it.”

This is all coming from Dr. Gene Spafford, from Purdue University. Or so the spun stories will tell you. Most of these stories even link to the written testimonial. Which actually says:

In the Sony case, the majority of the victims are likely young people whose sense of risk, privacy and
consequence are not yet fully developed, and thus they may also not understand the full
ramifications of what has happened. Presumably, both companies are large enough that they
could have afforded to spend an appropriate amount on security and privacy protections of
their data; I have no information about what protections they had in place, although some
news reports indicate that Sony was running software that was badly out of date, and had
been warned about that risk.

(emphasis mine)

Most of the testimony is really basic stuff about how bad having data stolen is and what “phishing” means and other stuff that 99.99% of the people reading this blog already understand. As for the spoken testimonial, here that is:

There’s your expert and you can hear it for yourself. Basically he read a mailing list where someone claims to know that Sony had an out of date version of Apache (no details on how out of date) and no firewall (this is clearly bullshit…there’s no way they didn’t have a load balancer in place to distribute 77 million users across their servers, and pretty much every load balancer is also a firewall; between the apache servers and the application servers there needs to be some kind of firewall to handle NAT or something…unless all of Sony’s servers were on public facing machines, which is very very VERY hard to imagine) and claims that Sony reads the same mailing list and knew all about it.

That’s not exactly compelling testimony to me… people say all kinds of random shit on mailing lists and forums. Also note that in his written testimony he refers to news reports, leading me to wonder if he even reads the mailing lists in question.

Now whatever security measures Sony had in place, they were clearly not up to the task at hand, and shame on them for not having beefier security. We’re all paying the price for that mistake. But there’s a big difference between “not enough security” and what this expert is saying, which is essentially “there was no security at all.”

Add to that the fact that Sony says the breach occurred via an application server, not a web server, and with all the security people looking over their shoulders, the FBI involved and the intense scrutiny they’re under, I find it a stretch to think they’re going to try to pull off a lie right now.

And yet.. every one of these posts have commenters nodding their heads and dragging out the pitchforks and torches and assuming that yup, everything this old gentleman has to say must be 100% true.

I’ve never been more ashamed of the community of professional bloggers out there.

9 thoughts on “Clearing up the Sony FUD

  1. The load balancers I’ve used have had some kind of firewall functionality ‘bundled in’. Maybe they all don’t? Traffic comes in and the load balancer routes it to a specific server. If the traffic is coming in through an unapproved port it doesn’t get routed. If a flood from a specific IP hits, the load balancer stops routing it all. Stuff like that.

    They weren’t our only security and we had a dedicated firewall between web servers and backend servers, but they formed an initial line of defense.

    (We used F5s – http://en.wikipedia.org/wiki/F5_Networks )

    This was a good 5-6 years ago (my current company offloads this stuff to a 3rd party) so maybe technology has changed.

    Feel free to educate if you know more than I do, next time. There are a gazillion people in the world who know more about this stuff than I do. Dialog is appreciated.

  2. @Pete: It’s been an ongoing problem with security that NAT is often treated as an inherent firewall.

    I’m sure none of this is a surprise to you, but for your readers as well:

    The point of a firewall is to create a one-way gate / a wall between an open network and an internal closed network. NAT is often / usually involved. But plenty of NAT scenarios (load-balancing for instance) just use filters for two-way. That’s only a partial firewall (and by most security experts, partial = compromised) and significantly reduced, security-wise.

    Compromised security is no security at all. That’s a mantra in security. It goes along with security through obscurity.

    What’s unfathomable in both Sony’s case and now EIDOS is the sheer stupidity of leaving critical data in two-way channels. That’s done for convenience, for themselves and customers, but it’s still such a huge mistake just waiting for this sort of end result. =/

    That Sony’s breach occurred on an application server should be a bright big warning bulb. That should never happen unless it’s an inside-job. There’s a bridge / two-way channel somewhere that was exploited.

    The other problem is turn-key security solutions, because (again, for convenience) much of the data that should be secured ends up stored in the wrong place, because things like email addresss, phone numbers, resumes (Eidos’ problem) and even credit card numbers don’t get flagged as items that should be treated as “store, don’t hold on the network”.

    Websites and other online services can take credit cards and personal data, while keeping them much more secure. They have that ability, it’s just going to be A: more expensive. and B: less convenient.

    The old adage is that Sony jumped off a building because everyone else was doing it too. You should not excuse them for this. That’s a mistake and just encouraging more stupidty.

  3. Summing that up: Securing stored data should be child’s play. That data should never be so exposed.

    The real issue that’s impossible for anyone to avoid is securing the initial channel obtaining that data. That would be exusable, because that’s the situation that cannot feasibly be resolved. That’s not where Sony’s breach was tho, so no, they shouldn’t get a pass.

    The saddest part of this situation to me is how quickly people want to just let them get back up and running, so they can chalk up poor security to a cost-benefit ratio. Sony needs to be penalized in a big way so that cost-benefit ratio lands on the side of something that resembles security.

  4. I’m a web developer, not a sysadmin, so I’m not as well informed as you are (though I probably should be) so thanks for elaborating.

    I’d actually love to learn more about this; you have any good reference links? Particularly how you accomplish these 1-way gates and still check log-ins and stuff.

    Anyway, thanks very much for coming back and elaborating. It’s very much appreciated.

  5. Most of my knowledge on the topic is from security courses from over a decade ago that I was required to take while working for a bank. Most of that is still relevant now, but the particulars are no-doubt outdated. I’m just above layman I’d say, I’m no expert but this particular situation doesn’t need one.

    I do have a couple of contacts in that industry and I’d love to say more but ugh (and this is one thing that’s bothersome to me in security) I am still under NDA.

    I’ll say this much: Banks have security issues too, but at least they customize their solutions and maintain good security teams. Sometimes because they’re legally required to.

    Without digging for links, off the top of my head any actual properly working firewall should provide 1-way traffic. The problem is pseudo firewalls, or maybe even the definition of firewalls has changed to accomodate the exceptions until they’ve become the rule.

    To the point: You should not be able to generically login through a firewall. Data goes in, only very specific data should go out. A whole stream of everyone’s personal data shouldn’t be remotely possible.

    The most secure method of course is to take data obtained, leave it some reference (hash, etc.) and actually take the data offline or to a secure internal network. This sounds terribly inconvenient, especially for a large corporation with high data turnover daily, but not too many years ago it was still expected in regards to credit cards. There are even some laws (depending on where you reside) that require this, but of course none of them are being adhered to. This is what approval codes, etc. were designed for.

    An application server should not be something that can be logged into via the outside network. That’s the major lapse here from Sony. I don’t know if they were configured poorly, or if it was some sort of buffer overflow exploit, who knows unless Sony releases their particulars.

    Unfortunately, Sony themselves have admitted to poor logging, which is astonishing. So it’s quite likely they are not absolutely certain how the breach occured. That’s what’s really led to my assumption that they’re using turn-key solutions. =(

Comments are closed.