The CodeGuard Blog

I’m in Boston to speak at the Embedded Systems Conference and it will give me a chance to talk about security with a variety of software developers.  Reaching devs and dev managers is important, since they are critical to the success of any security program.  Here are a few of the questions I’ll try to answer:

1. We’ve been writing software for more than 50 years.  Why haven’t we made more progress on the security problem?  Security is one of the most difficult software problems we will face in the next 40 years.  This is primarily because security is not just about telling a computer how to behave.  If it were, we’d have solved it by now.  Instead, security is a constantly changing battle with intelligent humans who are working to break what we have in place today.  If it were just about telling a computer to behave in a specific way, we would be finished by now.  However, we find that there are other smart people trying to defeat any new mechanisms we implement.
2. Why are there so many security bugs in software today?  I believe that security bugs reflect our security development practices of the last 15 years.  Most developers weren’t trained to design or build secure software, so it was easy for them to make mistakes.  That is an education problem.  Additionally, most of our security work has been focused on testing (pen testing, ethical hacking, system security scanning, etc.).  In short we have built an industry around the concept of “penetrate and patch.”  That’s no way to build secure software.
3. What can we do now?  In the US, there’s an old saying that goes “When you’re up to your ass in alligators, it’s hard to remember that you originally came in to drain the swamp.”  In other words, urgent problems often distract you from important problems.  We need to continue killing alligators while we spend time draining the swamp.  In software terms, we should continue testing, since that’s what we are good at.  However, we must also build the long term fundamentals of a strong software security program.  In my talk I will describe four basic steps.  Those steps are:
   1. Assess the security risk of any software you develop
   2. Define a baseline set of security standards that will guide software development inside your organization
   3. Implement security testing for code that could be exposed to attack
   4. Foster a baseline set of professional security skills that are appropriate to the risk level inside your organization

This may be a lot to say in a 1 hour presentation, but awareness is one of the best tools in our arsenal. For most security people, it’s probably not rocket science.  The rocket science will kick in as we translate traditional information security concepts to the world of software development.  Stay tuned.

Jim Molini, CISSP, CSSLP

The Internet turned 40 years old this month. Back on Sept. 2nd, 1969 several people at UCLA began the first test of a networking protocol for the US Department of Defense that would later become ARPANET and then Internet. You can read more about it: (less technical and more technical). The big surprise in this announcement is the fact that most people reading this post can remember a time when long distance communication meant picking up a telephone handset and paying a lot of money. More impressive is the thought that most of us can hardly remember how we managed to live without “the net.”

With the Internet came Internet crime. The first wakeup call for most of us came with the Morris Worm in 1988. In my experience, that worm came closest to shutting down the net – the entire net. At the time I was doing computer security at a government research facility and our best estimate came in at 4000 infected machines, all running SunOS. It took 4 days and a lot of work to correct the problem, but the world moved on and Robert Morris, Jr. honorably paid his debt to society. Oh, those were the good old days.

Today, my own back of the envelope estimate shows that we spend more than $54 billion annually on protecting ourselves from Internet borne threats. The cost in time and aggravation is many times that amount.

So the next time some hacker claims that he is doing something good for the little man by raging against the machine, writing malware, or building rootkits, you can tell him for me that he is also costing the world more than 100 million hours every year that could be used for better things. If the criminals would stop building software to harm the rest of us, I would happily donate 3 hours every year and the money I spend on security software to help make the world a better place. Wouldn’t you?

Jim Molini, CSSLP

I just took one of those online “spot the security bug” challenges they offer here at Microsoft. It was written by Michael Howard and Bryan Sullivan.  You can find it here if you would like to test your knowledge of code security.  I don’t write code for a living, but wondered how I’d stack up against the experts. 

So how did I do?  Uhhh… I didn’t get a zero, but let’s just say that I still have some homework to do if I ever want to work for Michael.

I wondered about that for a while, because I’m really not that bad at security.  I can find a few of my peers who will say I did pretty well writing questions for the CSSLP exam.  So why did I tank this test?  It distracted me for a bit.

Then I went back to look over the questions again and found that many of them were targeted at Web developers.  I’m not complaining about the test.  It’s a great way to raise awareness among the community and I really appreciate the work they did in preparing it.  However, I’m starting to see that some of my skills are becoming stale.  Like some of you who may be reading this, I haven’t been keeping up with the very latest software development technology.  Sure, I still write code in C# or Java.  I still read and write C/C++, but I’m not that clear on the intricacies of Web form injection vulnerabilities.  Never mind Adobe Flash® or Microsoft SilverLight®.

As I started imagining retirement, I thought back to the places I’d worked over the past 10 years.  Most of them still used COBOL for critical business applications.  (That’s good because COBOL was the first programming language I learned.)  All of them had a few servers running Windows NT or Solaris 2.x somewhere on the network because they were unable to upgrade the software.  From that perspective, maybe I can still be of some use to society.  To preserve at least a little bit of my pride, I told myself there were still places around the world that could use my skills.  (BTW, here’s the original Dilbert comic on COBOL and dinosaurs.)

Believe it or not, I expect to see more innovation around software security for legacy apps.  As organizations port more legacy applications to the Web via SOA, source code analysis will become more important for applications written in COBOL and C.  My quick Web search turned up only one tool for analyzing the security of COBOL code.  That came from Fortify Software. 

As I continued to look around, I saw a large open space for software security professionals of every type.  The software world is not monolithic.  We need people who understand Web Services as well as those who are focused on internal apps for corporations.  We also need people who can apply security concepts across a range of software implementations.  As we are seeing throughout the industry, security problems start well before the coding phase.  Poor security requirements lead to poor software security just as poor design leads to a poor implementation.

I’m not saying that anyone can become a software security professional.  If you’ve never written any code, you will spend lots of time learning the craft.  However, it’s also clear that good security goes beyond good code.  Maybe there’s still hope for someone like me.