Holy Hash!

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.

Security by …

We know several common buzzwords for determining security strategy of a company (or an individual). Let’s try to define them once again, for completeness sake.

• Security by ignorance
  Easily summed up by “what you do not know cannot hurt you” and is obviously wrong. Typically happens at the early stages of software developer’s career when a person is uneducated about security and simply does not know any better. Blissful ignorance usually ends rather abruptly with a cold shower of security education or a security breach.
• Security by obscurity
  The typical position of most software companies, hiding the secrets somewhere they themselves would not find oblivious to the fact that thieves typically know very well where you stash your money and jewelry. This is an actively negative position asking for trouble that does not take too long to appear usually. In companies, this is often the end result of near-sightedness of management, worried only about their quarterly bonus.
• Security by completeness
  The typical “very advanced security” position of many companies. This approach actually works quite well but only thanks to the fact that there are more companies in the above two categories. Completeness means the company extends the quality assurance by security relevant testing, design and code reviews, vulnerability testing and such things. In the end, one has to remember that correctness is not the same, and cannot be a guarantee of, security. When implemented correctly, can provide a really potent false feeling of security and serve as a shield against charges of incompetence and negligence.
• Security by isolation
  An approach touted by many security and non-security relevant companies as the ultimate solution to security problems of today. The idea being that you run your application in an isolated environment and throw away the application together with the environment afterwards, or whenever you think you have a sight of a security problem. This way, security breaches are contained to a small disposable portion of software and do not cross over to the system at large. There are a few problems here, not the least one being the nurtured feeling of complacency and false security. Breaches can go in from the isolated environment to the system at large, the data is never completely thrown away, for why would you then compute that data in the first place, and so on. This is a  dead-end of false security.
• Security by design
  This is a concept that is most unfamiliar to most of people. Typically, this is the case where the system is specifically designed to be secure. The environment is not taken for granted, malicious abuse is assumed, and care is taken to minimize the impact of the inevitable security breaches. Since this takes a lot of careful planning, thinking ahead, designing and verification, these products are always too late in the market and nearly never succeed. So we have no idea what it is like to use secure systems. Mainframes (that’s what “clouds” were called twenty years ago) were a bit like that, I feel…

So, what’s left then? Is there a practical approach to security that would not be so expensive that the companies would stick a finger to it but still provide a good solid security?