Secrets of Google’s Information Security Team
By Daniel Miessler on April 29th, 2008: Tagged as Google | Security
At RSA this year I caught a talk by a Google executive that discussed what makes Google’s Information Security team so unique. I found the talk quite informative and thought it was worth sharing. It would be great if more companies had this perspective.
Everyone on the Security Team is a Programmer
Read that again. Every single person on the team is a coder. This is beautiful. How many times have you heard a security guy say, “Hey, this is code. I don’t know how to code. Send this over to the programmers to look at.” Great, send it over to someone who has no idea whatsoever about security.
It’s my opinion that the security group should be elite within an organization. They should have the most IT experience, the most talent, and the most interest. Why should they not understand code as well? What about programming is so scary that it shouldn’t be included in the high standard that security needs to meet?
Nothing. I think Google is approaching this absolutely correctly. Security engineers should understand programming principles and should be at least moderate programmers themselves, ideally in at least the core languages and frameworks in use at the time.
Google’s Security Team Writes All of Their Security Libraries
Who better to write secure code than the security team, right? You know all of their authentication libraries? All their authorization stuff? Input validation? Output Encoding? Yeah, all of it is done by the security team. All the programming knowledge, all of the security knowledge — all in one place. Then you have the code review.
All Code is Reviewed by Peers
One way to ensure standards is to have not only QA look at your code, but your programming peers as well. While it likely introduces a lot of pressure it also brings a certain social element to the development process. You’re more likely to try and produce quality stuff if you know it’ll be under a microscope later. Not only can bad code be part of your evaluation but it might get you razzed in the cafeteria.
How They Test Code
One of the most interesting things I heard during the talk was a description of how Google tests code before it’s deployed. They essentially capture attacks being thrown at their applications and put them all into a database.
And here’s the cool part — they run the whole list of attacks against their new code while it’s in QA. So, in order to ensure that their new code isn’t vulnerable to ANYTHING they’ve ever seen, they run all the previous attacks against it. Awesome.
But that’s not all. They’re also constantly monitoring production and constantly updating the attack database. So when you test your code in QA you’re not just testing old attacks but rather all attacks they’ve ever seen up to the present. That’s sick.
Summary
Google is insanely successful, and the second best thing to being genius is following the path cleared by it. Anyone interested in doing security right should at least take a look at Google’s approach.:
--
This is not completely true. Everyone on the team that works in that function is/was a developer but not everyone in the umbrella of information security is.
Comment by dale — 4/30/2008 @ 12:45 am
If you mandate that everyone on your security team needs to be a programmer, you’re not going to end up with an elite security team, you’re going to end up with a team of developers who know something about security. Now, security people (especially application security people) must be able to code, but this isn’t the same thing as them needing to be programmers. Security researchers are security researchers because they want to attack stuff, not because they want to code, if they wanted to code they’d be programmers already.
Also, writing all your own security libraries is not inherently a good idea because you lose the benefit of the fact that many eyes can look at and review the code to help improve it, of course so can bad guys, and google is a pretty attractive target, but it’s a trade-off not something inherently good about Google’s policy.
Furthermore, while peer review is good, it should also be reviewed by the security team because that’s why you have them; because you know developers probably don’t know as much about security as the security team. OF course they have less security people than developers, so getting devs to review code makes sense.
Also, throwing all the attacks they’ve ever seen against their code is a stupid idea, let me explain why: - You need to be able to differentiate between what an attack is and what isn’t. The fact that IDS’ and IPS’ suck so much illustrates how hard of a problem this itself is. And if someone’s got an attack that’s interesting enough that the security team can learn from it, they’ve probably got a bunch of ways to evade the IDS that Google is using. And the best case is that you can find known attack variants, all of which the google security team should already know about, and they should keep a database of those, rather than the junk they get sent. - Throwing stuff blindly at apps is what a fuzzer does, and we already know that fuzzers don’t find all the bugs, and on top of that with many non-memory corruption issues it is much more difficult to determine whether an attack was successful or not because there is no crash to notice and debug.
So in conclusion while I’m sure Google’s security team is good, what you’ve described here doesn’t necessarily make it so, though I guess it probably does make them unique.
Comment by kuza55 — 5/3/2008 @ 11:20 pm
They’re writing their own authentication and authorization libraries, not their own encryption algorithms. Do you know of a place where a company is supposed to go to copy and paste these types of libraries? Are you suggesting that everyone who’s doing it is doing it the same? This isn’t encryption; it’s not the same.
Comment by Daniel Miessler — 5/3/2008 @ 11:24 pm
I don’t know of them (I audit code, I try to avoid writing it), but my point was merely that it’s not inherently a good idea; if there is nowhere that these kind of libraries exist, then the discussion of the fact is irrelevant because they have no other choice, but if there is then it’s merely a trade-off rather than something to be held up as something people should be doing.
Comment by kuza55 — 5/4/2008 @ 7:39 pm