Developing Security

Maintaining a long term Application Security Program

I recently read the outstanding paper "Building a Web Application Security Program" by Richard Mogull and Adrian Lane and it made me reflect on our own Application Security Program within Third Brigade.

Developing secure software is an important skill for every architect and engineer, but when you are developing security software, being anything less than an expert is inexcusable. There is nothing worse than being compromised through software that was designed to protect you, and for a security software company I can imagine nothing more embarrassing or detrimental. (I'll leave the digs at competitors out here.)

Building a Security Program is important, including all the aspects of development, deployment and operations that Richard and Adrian cover. Also important is maintaining the program and culture long term. I thought I would share our approach to keeping the program alive.

Early on in the life of the company, we appointed a member from each of the teams to a security council. Their mandate is to develop and maintain the security program. We recognized that the council had to hold a certain weight to it in order for other developers to take it seriously, so this council is more KGB then LOTR. Anyone serving on the council has the power to halt any release they feel hasn't passed the litmus test. This is not unlike the "Security Buddy" in the Microsoft SDL, with the exception that someone from each team in the R&D group is represented rather than a single security expert.

The council mandates policies and procedures found in many other programs including training, design review, threat models, static/dynamic analysis tools, fuzz testing, and peer code review. The product we produce is deployed by our customers, but the council ensured we covered all aspects of the security program by mandating an internal deployment complete with penetration testing and vulnerability assessment. In the end we had a very robust security program, but we needed to ensure that no aspect of it was forgotten as years and releases went by.

Our answer to this problem was threefold:

We started by making all mandatory procedures auditable. Specifications need to include security impact analysis and must be peer reviewed. Code reviews must be recorded in each case. The evaluation of the results from the analysis tools must be processed and signed off in the milestone checklists. The visibility of these procedures being carried out ensure that things don't 'just fall through he cracks'.

Secondly, the council reviews our security program and SDLC quarterly, ensuring that we keep pace with the times and adjust anything that is not working optimally. A good security program is an evolving one.

Finally, over time members of the council are changed to give fresh eyes and drive to the group's mandate. The council not only provides an important steering committee for our secure program, but enrichment for the members as well. Each member is given areas of investigation as side-projects to report on at the next meeting. Having new people on the council brings new ideas and new areas of exploration.

Developing Security

This is my inaugural post in the security Blogosphere and what better place to start than with who am I and why I'm here...

Over the past six years I have been working on information security software. My first project was on an automated certificate renewal system for Entrust. My current project, being developed for my employer Third Brigade, is an enterprise-class server and application protection system called Third Brigade Deep Security. It's a combination host-based Firewall, Deep Packet Inspection, Log Inspection, and Integrity Monitoring system. My role specifically is as the Software Architect for our Manager component, which is responsible for configuring and monitoring thousands of software agents.

To that end, you will likely find posts on this blog relating to secure development, usability, visualization, metrics, virtualization, and the security technologies I mentioned. What you're not likely to see are postings about the latest exploits, compliance, or risk management. These topics are well-covered by many of the existing security blogs.

That brings me to the question: why am I starting a blog? I'm a firm believer in a good challenge. If you're not being challenged, you're probably not growing. Posting interesting and relevant content on my areas of interest in information security is certainly a challenge. Unlike emerging exploits, topics like secure development, usability, visualization and metrics don't move nearly as rapidly, yet I believe there is still a lot to be explored. I'm also here because of people like Jeremiah Grossman, Alan Shimel, Christofer Hoff, Michael Howard, Anton Chuvakin, Joanna Rutkowska and many more of the talented security bloggers out there. They contribute so much of their valuable time educating (and sometimes entertaining) the rest of us, and I find that very inspiring.

I've chosen 'Developing Security' as the blog title because it relates to both development of security software and to the fact that security is an ever-developing topic. I hope to cover topics that not only interest software architects and engineers, but security professionals in general.

And now that the first painful post is done, here I go...