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

President Obama touted the new U.S. plan for Cybersecurity.  (Cybersecurity is the US government’s term for computer and information security these days.)  The new proposal is based on a Policy Review conducted by the administration and has several important changes for anyone who thinks about security from a global perspective.  In some ways, the bland “bureaucratese” hides a major change in U.S. policy toward the Internet.  Be prepared.

First, this document changes the game in privacy.  The new approach offered by the Obama administration places privacy as a distinct element of the new universal policy.  Notice how the document discussed privacy and tried to reframe the discussion of network monitoring.  It might not be a huge change for many of the federal agencies that deal with information today, but this will begin a major shift in American industry.  My three-word analysis for the IT community in the U.S. is:  “Expect More Offshoring.”

Most U.S. companies have enjoyed a competitive legal advantage over European firms when operating in a privacy-sensitive environment.  Our current laws are not tuned to fully protect the private data of individuals, so US companies had more flexibility in defining the protections for individual privacy.  That will change, if not through legislation, probably through the courts.  This will mean that many companies could end up radically changing the way they handle customer or visitor data.  It is not necessary, but many business people may opt to take the easy way out.

Second, we are finding that the world really is flat.  That could make offshoring a kind of protection against civil suits.  If companies find that offshore firms provide insulation from civil suits, you will see an avalanche in offshore data processing and outsourced jobs.  Add in the new taxes being proposed by the administration and it could make a perfect storm for IT offshoring.

If you’re a US software developer, there are a few things you might do to keep your work closer to home.  First, learn how to develop for a privacy-focused service.  Find an expert to help with the basic policy and tune it to the needs of your organization.  Think about whether you want to be aggressive or conservative in your privacy protection for site visitors.  Privacy is not a switch.  You have many options.

Eliminate unnecessary data and reduce the amount of information you collect from users.  A good way to start is to use federated authentication, like Windows Live ID, or OpenID.  These offerings give you only what you need and reduce your need to protect authentication data.  If you inventory the PII stored by your site, you may find that much of it is required just for authentication purposes.  Why take that risk?

Think about your monitoring options.  If you have a promiscuous network intrusion detection system (NIDS) on your site, you may be collecting too much personal data.  Tune down what you keep and “anonymize” the rest.

Next, consider how you will protect any Personally Identifiable Information (PII) that you do collect.  If you are out to create a community, it’s not necessary to know everything about every member.  Finally, start working on the design changes necessary to reflect an adequate privacy policy.  You will improve your image and your  sessions per unique visitor if you have a respectable privacy policy.  It’s not easy, but it is likely to be important in the next two to three years.

Jim Molini, CISSP, CSSLP