I just finished my first day of classes with Security and DB. Both sound pretty good, but security should be particularly interesting, educational, and useful. I'm really looking forward to it. Security has course readings, which is somewhat unusual for CS classes, but at least the material is interesting (and very relevant). Here's an example of the first one we need to read: Smashing The Stack.
DB is apparently pretty much a course on making an optimizing compiler, which also sounds pretty promising. :)
Also, I really need to watch the new Sherlock episode soon. If you haven't watched the BBC Sherlock mini-series yet, I very highly recommend it!
All in all, this is shaping up to be a great term. :)
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Tuesday, January 3, 2012
Friday, June 3, 2011
Sony Hacked Again
So it looks like Sony was hacked again. Things are not looking good for Sony. It's been almost two months since the original hack in April. Why does Sony still have unencrypted databases? Didn't they hire a bunch of security consultants after that first security compromise? I would imagine that "Encrypt your freakin' data" wouldn't have been one of the first things that these security experts would have said. So then why is this still a problem?
One of my friends thinks its a size problem. Sony has a lot of systems to fix, and the hackers are working faster than Sony developers. I'm told that things work very slowly in huge companies. While this might be part of the problem, I feel like there must be something else at play here. Sure protecting against SQL injections is hard (ish), but hashing data shouldn't be that bad. Perhaps there code is poorly written, and adding in data encryption is very hard to do. In any good system, there should just be one layer talking to the data directly. In such a system, making this change wouldn't be that hard. They would also have to hash all the existing data, but that is also easy script work.
Maybe it's an IT infrastructure problem. That is, encrypting data makes things much slower (conceivably twice as slow for data access), and maybe the Sony servers can't handle that extra load.
I also think about why this was such a huge security hole in the first place. Is it really because Sony doesn't have any security-conscious developers? I doubt it. It's a pretty popular subtopic in Software Engineering, so I'm sure someone on their payroll took the time to learn about it. It's not like your need a Masters in Security to know to encrypt sensitive data.
I think the developers were just lazy. It's certainly easier to develop and test a system without encryption. It was probably put on some todo list for later, but that later never came. The development team was probably more interested in starting on new projects or features, and they assumed no-one was really trying to break their system anyway. Maybe the developers wanted to implement these security features, but management didn't think it was worth the time and money.
I would really like to know how this all happened, but I don't think Sony will ever reveal the real reasons. I do know that it must be..."fun"...to be working at Sony right now.
One of my friends thinks its a size problem. Sony has a lot of systems to fix, and the hackers are working faster than Sony developers. I'm told that things work very slowly in huge companies. While this might be part of the problem, I feel like there must be something else at play here. Sure protecting against SQL injections is hard (ish), but hashing data shouldn't be that bad. Perhaps there code is poorly written, and adding in data encryption is very hard to do. In any good system, there should just be one layer talking to the data directly. In such a system, making this change wouldn't be that hard. They would also have to hash all the existing data, but that is also easy script work.
Maybe it's an IT infrastructure problem. That is, encrypting data makes things much slower (conceivably twice as slow for data access), and maybe the Sony servers can't handle that extra load.
I also think about why this was such a huge security hole in the first place. Is it really because Sony doesn't have any security-conscious developers? I doubt it. It's a pretty popular subtopic in Software Engineering, so I'm sure someone on their payroll took the time to learn about it. It's not like your need a Masters in Security to know to encrypt sensitive data.
I think the developers were just lazy. It's certainly easier to develop and test a system without encryption. It was probably put on some todo list for later, but that later never came. The development team was probably more interested in starting on new projects or features, and they assumed no-one was really trying to break their system anyway. Maybe the developers wanted to implement these security features, but management didn't think it was worth the time and money.
I would really like to know how this all happened, but I don't think Sony will ever reveal the real reasons. I do know that it must be..."fun"...to be working at Sony right now.
Subscribe to:
Posts (Atom)