Winning Over Developers

One of my favorite memories of living through Microsoft’s adoption of secure development was sitting in a hacking demo by Foundstone for a lot of the Windows development team. The network security team were invited over to watch as well. The Foundstone guys demonstrated hacking an unpatched Windows 2000 system. As they got in to one part of the system I watched a developer hang his head and say “I wrote that code.” I think that moment probably did more for software security with that developer than any other single thing. From that moment on he knew security features did not make code secure. He was won over.

During my SAIC days, all our customers were developing software for DoD. One of the fun parts of being a security guy in a DoD world is the reaction of people when you arrive. There are so many IA guys (DoDspeak for security folks, IA stands for Information Assurance) who think their job is to always say no that security guys who arrive to help are viewed with suspicion until they show they are different. Showing that could be a lot of fun.

Early on one of the teams we were called in to help were not too happy to see us. In the initial meeting, the dev lead sat in the back corner, leaning back with his arms crossed. He clearly didn’t want us to be there. The team happened to be wrestling with a memory leak they could not find and we were able to find it via the static analysis tool we were using at the time. Solving that problem for them made them more receptive but not welcoming yet. As we passed on the results, and there were a lot since there was a lot of legacy C/C++ code that had been around for a long time, things looked grim until we set their priorities and waved them off worrying about fixing everything right away. Since their schedule permitted it, we sent them off on some easy to fix low hanging fruit that allowed a very large, quick win. We then sung their praises to their boss. From then on out we were greeted pretty well as we looked at all their changes periodically every year. Continue reading “Winning Over Developers”

Learning to do Secure Code Review – Thrown to the Wolves

Kind of a longer version of the intro and a 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 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 their 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. Continue reading “Learning to do Secure Code Review – Thrown to the Wolves”