A Review of "Building Secure Products and Solutions"

        Historically speaking, many applications were designed to be overly trusting. For example, early personal computers were not networked and it was assumed whoever was in front of them owned them and should be able to do whatever they wanted with them. Another example is that in the early days of the Internet,
when it was mostly comprised of Universities and research organizations, greater levels of trust were given as it was assumed that most users could be trusted. This legacy has caused many security features to be "tacked on" (the article uses the term "strap-on") as problems were found over time, and not designed into the systems from the beginning. Devices and software such as anti-virus programs, Intrusion Detection Systems and Firewalls can be seen as being examples of such infrastructure "Band-Aids" for deeper design problems.

        The problem with "tacked on" security is that it is rarely efficient or seamless. In the early days, security was not even thought of in the list of "order qualifiers". Now security has begun to take center stage and become an "order winner", with users choosing software that they see as more secure. Apple's OS X based computers are examples of a system some people might buy to feel more secure. Whether that security is because of better design or because OS X is a smaller-niche OS that fewer attackers bother to exploit is a debatable question.

        Many software security problems illustrate the Pareto principle nicely. In this case, a small percentage of the devices and code make up the largest portion of the security problems. The problem is spotting those little bits of code that do cause issues. I disagree with the inference made early in the article that the research group ISS indicated that the number of vulnerabilities were on the rise. What they really indicated was that the number of FOUND vulnerabilities were on the rise. That's a very good thing, because unfound vulnerabilities don't get patched by the vendors, but they may still be known to those who wish to exploit the holes.

        One of the problems with getting organizations to see the benefit of designing security into their systems from the start is that it's hard to correlate security with the bottom line of making money. If getting a product out the door fast is emphasized to make a short term gain, then security is likely to suffer. Some might equate security to health insurance; you hate to pay for it, but you're glad you have it when you need it. The problem is that people don't always see when they needed it. A better analogy, still in the health field, would be eating right. Someone who eats right might say "well, there is no point in me eating health foods since I'm hardly ever sick anyway". The security equivalent would be "Why are we spending so much on security? We've never had a security breach." They are ignoring the fact that the reason they have never had a breach is because they have taken security into account from the beginning. If someone is doing a good job of keeping things secure, then they won't see the problems that come from not being secure and thus may not recognize the benefit.

        I'm not sure that the Bell Labs Security Framework advocated in the article is the the best way to solve the problem, but the article does a good job of making the reader aware of issues concerning security and a product's life cycle. It's far cheaper to design things securely to start with than to have to fix problems later. Unfortunately, organizations can be short sighted and not see potential vulnerabilities (and the costs associated with them) until a system has become a standard, at which point it's hard to make changes.