Unsupervised Learning
Posts
Secrets of Google’s Information Security Team

Secrets of Google’s Information Security Team

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.: