Sam Harris Says We Shouldn’t Call Ourselves Atheists

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