The CodeGuard Blog

As the field of software security emerges, you will see many people telling you about “the best way” to do security for your organization.  Some of the advice will be very good, but it must also track with your development model.  If you do in-house software development, you come up with a different security design that someone working at a large commercial software developer.  If you develop under contract to another entity (I call this Development For Hire), you may have your own security lifecycle as well.  Today we’ll talk about in-house development.

In House – This kind of software is focused on small teams (relatively) doing work for a specific deployment environment.  You can rely on the fact that your installation has a certain number of deployment parameters.  The software might run on a single mainframe, or on PC’s configured with the organizational configuration.  This simplifies much of your security planning and also reduces the attack surface of the applications you build.  Even if you use the same steps in the lifecycle, you will find that you will make different decisions than other software developers about your security.

You may also find that you can depend on the organization (company or government agency) to custom configure the server hosting your application, to further reduce risk.  Additionally, these apps often operate within a single authentication and user provisioning environment.  All of these controls simplify the security design as you go through development.  If this is the case, you can focus more of your security effort on broadening the reach of security mechanisms and on improving the acceptability of security features.

The down side of in-house development models is that you often have fewer people working on security.  Developer time can be precious as more diverse effort is expected from fewer people.  In that case, you may find that security training is as important as good security design.  Make sure that the developers in your organization can get the knowledge they need quickly and efficiently. 

Another problem you may experience is the problem of legacy controls.  You may have to figure out how to apply security in a shop that uses COBOL for most critical apps.  If that’s the case, don’t despair.  COBOL is not as easy to exploit as software built in C or C++.  Furthermore, as a more verbose and procedural language, it is often easier to spot problems in COBOL than in some of the more modern languages.  If you use COBOL, you may need to implement peer code reviews for security instead of using a static analysis tool.  I’ve heard of a static analysis tool for COBOL, but haven’t had the chance to look it over.  If you have, send me an email and let me know what you think.

As you can see, in-house development carries its own challenges and opportunities.  Even if you only have one part time specialist, you can improve the security of software you develop.  Good luck.

Next week, I’ll talk about software for hire.

Jim Molini, CISSP, CSSLP

No, this is not the beginning – or the end.  However, it really is the end of the beginning.

After more than 35 years of industry research and more than two years of development, we are finally beginning to see software security emerge as a distinct profession.  This is very cool.  The newest manifestation of growth in software security is a professional certification called the Certified Secure Software Lifecycle Professional, or CSSLP.  It’s being offered by (ISC)², a name that many people already know.  I’m a member of the (ISC) ² Advisory Board of the Americas and they list me as a primary architect of the cert.

Don’t get me wrong.  We didn’t invent the concept of software security.  The credit for that goes back to the early 1970s (more here).  But now, there is a real, independent organization that will test and certify your skills as a software lifecycle security professional.  If you don’t know what I’m talking about, here’s the 101.

(ISC)² has been certifying the professional qualifications of information security people for almost 20 years.  The Certified Information Systems Security Professional (CISSP) certification is the most common internationally recognized cert for people who specialize in computer security work.  Now they have released the CSSLP for people who specialize in software security.

Big Deal.  Right?  No, really.  This is important.  I know that a lot of people will be skeptical about this whole thing, but it’s time to finally recognize the people who know how to make software more secure.  A lot of people go through life every day doing the job of “security guy” on a software project, but they get no tangible recognition for their specialized skills. If you are one of those people, you might wonder if you really know enough to be considered a “professional.”  Now, you can see what other experts in the field say about software security.  You can test your skills against a common body of knowledge.  If you want, you can get certified.  This also means that your employer will have tangible proof that you measure up with other experts in this field.  In this game, everyone wins.

That’s why I say that this is the end of the beginning.  From now on, if you do security in a software house, you can measure your skills against a standard.  If you talk to people about the development of secure software, you can verify your advice against the standards established for the industry.  If you test the security of applications, you can measure your own development against a professional standard.  Last year anybody could claim to be a software security expert.  Now we have a measuring stick.  It’s not perfect.  Nothing is at this early date in the lifecycle. But it’s a start.

If you work in the field of software development, this is also an opportunity for you to get recognized.  In fact, this is one of the primary reasons behind all of the work.  We (the volunteers behind the CSSLP) want you to be recognized for all the hard work you do. It’s not easy being the security guy.  You have to learn software skills and then learn security on top of all that.  You have to influence people to do extra work to avoid problems that might never occur.  However, you also have to keep the project on schedule and under budget.  All of this takes a special skill and you should be recognized for that skill.

At the same time, software security is a journey, not a destination.  So this blog is intended to help you navigate the professional hurdles you will face in your journey and to get you thinking.

Software security is still new.  The best techniques are still being imagined.  If you do this for a living, you certainly know that there is plenty of room for improvement.  Let’s start figuring it out now and move the industry along with us.  Good luck in your career and write to me if you have ideas about what I should discuss in a future post of the CodeGuard Blog.

Jim Molini, CISSP, CSSLP