The entry below encompasses Ben Hagen’s perspective on securing the code and highlights some recommendations as well as tools applicable for that purpose.
In terms of cloud security, we used AWS for almost everything – that’s Amazon’s cloud solution. I think the most powerful security tool in AWS is AWS itself. If you have the opportunity to design your applications from the ground up to take advantage of this kind of architecture, I think you have some really interesting opportunities to implement security from the ground up, so things like Elastic groups, where machines get deployed automatically based on load and that kind of thing – this presents a lot of interesting security challenges, but opportunities as well.
We ended up deploying Snort as an IDS solution on every instance we deployed. It gets a bit heavy in terms of resource usage, but it was great to have that insight in terms of what kind of activity each machine was seeing. ModSecurity is of course a great Apache application firewall. And again, Nmap is one of my favorite tools of all time.
Application security was a big part of what I did at the campaign. We basically ran through a very quick secure development lifecycle: I would sit down with people when we started projects and kind of discuss what kind of implications it had for security or privacy. We’d talk about how they would be addressing those issues, figure out milestones later on in the process, where we would check in and make sure that if they had any questions I could answer them.
And then, prior to deployment we do a code review or application assessment; typically both, where you have the code on one screen and you’re actually testing the application on the other. Burp is my all-time favorite web application tool. It costs a little bit of money, but I think it’s worth it. It’s a great web application interactive proxy, so if you haven’t checked it out, I really recommend it.
GitHub was our code repository of choice, and I think that really helps you out in doing code reviews, because you can see incremental changes, you can assign ownership to code, who wrote what, and if you know one guy is really bad at sanitizing SQL queries, you can focus on his stuff within the code, as opposed to somebody else who you know is doing stuff pretty well. So, kind of a combination of all that I think was pretty effective (see left-hand image above).
That being said, I think it always helps if you can just break everything you possibly can. And I think you should have no shame if you find a problem; break it as much as you can. I think developing proof of concepts for any issues that you find gives you big points from developers, but also from management, because you can actually prove that something is going on here.
With respect to that, I think it’s really important that developers are proud of the code they write, so if they write really good code, if you don’t find many problems with it, you should also tell them that and you should use them as a reference to other people who might not be developing as secure a code. So make them feel pride in what they’re doing.
If you are responsible for the security of applications on the Internet, you always have work to do. Even if something’s deployed and hasn’t had a problem in the past, you constantly need to keep up to date with what’s going on, researching new security issues and that kind of thing, so you just can’t stop doing anything.
Finally, I think volunteers are incredibly important in this kind of situation. Thankfully, at the Obama campaign we had a lot of people eager to help us out. And again, the community in Chicago is pretty small in terms of technology and even smaller in terms of security. So I invited some of my former coworkers, my friends, people I trusted to come volunteer and spend, like, a weekend with us and help me secure code, so, basically, doing hackathon kind of thing where we bring them in, point them at some applications or IP addresses, and have them hack at it. And the benefit there is you get more than a single set of eyes on stuff, which I think is really helpful.
Read previous: Securing the Campaign 4: Risk Mitigation