Securing the Campaign 5: Application Assessment

The entry below encompasses Ben Hagen’s perspective on securing the code and highlights some recommendations as well as tools applicable for that purpose.

Cloud security tools that were used at campaign 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.

The application security part of the process 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.

You should have no shame if you find a problem; break it as much as you can.

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

Some tips from Ben related to application security assurance 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.

If possible, I like to embarrass people with my proof of concepts. My favorite thing we actually did within the campaign was cross-site scripting. I developed a generic proof of concept, where if I was able to include some remote JavaScript, the JavaScript was designed to replace the background image with a big dancing otter, play some music in the background, and then pop up everybody’s cookies. And I would send that to the developer, they would see it, I sat just across the room from them, so I could see them looking perplexed at their screen. I would then send it to everybody else on the team and have them take a look at it also, because nothing motivates somebody to fix a problem more than if all of their friends and peers are looking at their mistake they just made. I think it’s important not to humiliate them, but I think embarrassment is appropriate, so we were using that embarrassment to help everybody learn, and to learn from a mistake and to have that kind of cooperative learning going on.

If you are responsible for the security of applications on the Internet, you always have work to do.

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.

Volunteers are really helpful 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

Read next: Securing the Campaign 6: Relevant Discussion with the Audience

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: