Cheap security in real life?

Security concerns are on the rise, companies are beginning to worry about the software they use. I received again a question that bears answering for all the people and all the companies out there because this is a situation that happens often nowadays. So here is my answer to the question that can be formulated thus:

“We are making a software product and our customer became interested in security. They are asking questions and offer to audit our code. We never did anything specifically for security so we worry what they might find in our code. How can we convince the customer that our product security is ok?”

There are, basically, three approaches to demonstrating your product security if we take that question as meaning “how can we make sure our software is secure?” Unfortunately, the question is not meant that way. Unfortunately, the company producing the software is not interested in security and the meaning of the question is rather “how can we make the customer get off our backs while we keep producing insecure software?”

That boils down to the switch from “security by ignorance” to “security by obscurity”, as I explained in one of my earlier posts titled “Security by …”. That is, of course, the cheapest possible solution in the short run. However, it does not eliminate the risk of company suddenly going bankrupt due to a catastrophic security breach in one of its products. Sony Corporation lost $190 million during their PlayStation Network hiccup a few years back. Can your company survive this kind of sudden loss? Would it not be better to invest a few hundred thousand in product security to ensure the continuity of your business in the long run?

But nevertheless the question was asked and what is a company to do when it is not willing to invest in a security program? When a company insists on a quick and dirty fix?

The advice in this case is to go along with your customer’s wishes. They want to audit your code? Excellent, take the opportunity. A code audit, or, rather, they more likely mean “white box penetration testing” in this case, is an expensive effort. At a bare minimum, you are looking at about forty man-hours of skilled labor, or fifty thousand euro or dollar net expense. Are they willing to expend that kind of money for you? Great. Take them up on their offer.

Oh, of course, they will find all sorts of bugs, security holes and simply ugly code. Take it all in with thanks and fix it pronto. You will get a loyal customer and a reputation for, frankly, the work that you should have done from the beginning anyhow.

Now, the important thing is going to be the handling of those findings. Here many companies go wrong. It is not good enough for your business to just fix the reported problems. Studies show that the developers never learn. That means your next release will have all those problems in the code again.

To do things right, you must set a special task to your development or testing – they must find ways to discover those problems during the development cycle. They must be able to discover the types of problems that were reported to you before they can be detected by the customer. Then, your code will improve and you will be able to lower the effort to fix for the next time.

And there you are, a quick and dirty fix, as promised. Just don’t fall for the fallacy of thinking that you have security now. You don’t. To get proper security into your products and life cycle will take a different order of effort.