Kind of a longer version of the intro and how I learned to do secure code review.

I fell in love with programming in high school in the early 80s so I studied computer science in college at West Point. After active duty as an officer in the Army, I got out and became a defense contractor in Huntsville, AL. There I did some general engineering and software development at AEgis Research (now AEgis Technologies) and helped build out their corporate network and get on the Internet for the first time. In 1997 a fellow West Point graduate recruited me to join him in doing network security at Microsoft. Figuring security would be important in the age of the Internet I made the change.

Those were wild and woolly days of network security as we figured out how to secure a globe-spanning network that was a major target. I was on the incident response team fighting worms, viruses, and hackers long before today's tools for that came into existence. I got to see how hackers thought and how they worked. I was there when Microsoft had its great security awakening after things like Code Red and Nimda. I watched their management and developers gain security religion and start to change their ways.

In 2003 I returned to Huntsville to work at SAIC building various solutions for government customers and continuing to do security work. In 2007 I was at the right place at the right time as one of the local managers won a task to do a secure code review of a web application for a government customer and on the very same morning the person slated to do the work became unavailable. I jumped right in.

This was the very first effort like this we'd done so there were no processes or procedures and DoD had yet to release any software development Security Technical Implementation Guides (STIG) so there were no formal standards to look to. I pulled Mike Howard's and David LeBlanc's Writing Secure Code off my bookshelf, hit the web and started to figure out how to do a secure code review. We started by conducting some security awareness training for the development team to include general stuff and some early efforts at secure development training. From there I dove into the code for a pure manual secure code review. I mapped out the code, created a tracking process and dug it. After the first pass, I compiled the results and prepared a briefing for the team showing them their common security bugs. I included a "spot the bug" session where we displayed code snippets and helped the developers find the bugs and suggested fixes. The customer loved it and thought we had very mature processes and procedures and a polished product. The dev team worked on the fixes and added features and a while later we did our second pass on the code to see how they had done. Lather, rinse, repeat.

One of the interesting lessons learned was we did not limit the introductory training to the team on the application nor did we on the presentation of the results. Other related teams were allowed to sit in. Despite no formal efforts, when we were called in to look at their code they were ahead of where the original team had been when we first started.

Nothing like being thrown to the wolves to do something you were not part of planning and selling to force you to learn fast. I can't recall specific ways I learned to do things back then but learn I did. The business expanded to other reviews of other code for other local DoD customers. We added other folks doing the secure code review and added in static analysis tools as we were able to license them and bring them into play. We never were able to do as much as we wanted to do because of the classic time and budget issues so many efforts face but despite rarely having specific money in the budget for software security efforts, customers found a way to get us in.

Now, seven years later an opportunity to join Cigital came along and I jumped at the chance to work with and learn from some of the pioneers of software security. I figure I'll blog as I learn and see what others have to say and we'll learn together.