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