Quotes: Problems, solutions, and change

The solution to any problem is found in the proper definition of the problem

— Doug Hale

Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change

— Kent Beck

Security quotes

“Security systems are never value-neutral; they move power in varying degrees to one set of players from another.” — Bruce Schneier, Beyond Fear p. 35

“People exaggerate spectacular but rare risks and downplay common risks”. — Bruce Schneier, Beyond Fear p. 26

“Technology is generally an enabler, allowing people to do things. Security is the opposite: It tries to prevent something… That’s why technology doesn’t work in security the way it does elsewhere, and why an overreliance on technology often leads to bad security, or even to the opposite of security.” — Bruce Schneier, Beyond Fear p. 13

Stages of Security in the life of computer software

Is your client-server software secure? You may be surprised to find that even mature software, sporting the use of standard encryption, could be putting your mission-critical data at risk. Why is that? It has to do with economics and the lifecycle of software. Here are the stages.

Prototype. No one cares about the security of the client-server communication.

First release. Althought the system (likely little more than an improved prototype) has been shipped, it may not be usable, and if it is, it lacks mission-critical features. Security is low on the priority list. If encryption and authentication were implemented, it is most likely minimal, brittle and insufficient. If the security is robust, the product is not functional and likely never will be because the ISV will go out of business.

Second or third release. If the ISV has survived long enough to release a second or third version, customers likely demanded the use of standard encryption. In the old days (the 1990s), this means the ISV would have switched from XOR “encryption” to DES or 3DES. These days, standard encryption probably means use of SSL/TLS without certificate checks. Note that customers probably won’t ask about the security of the authentication mechanisms.

Unfortunately, use of a standard encryption algorithm doesn’t mean communication is secure. Software is likely to be vulnerable to man-in-the-middle attacks and have authentication bugs. The customer isn’t likely to know this, and neither is the ISV. If the ISV does know, they won’t fix the problems. This shouldn’t be surprising — the risk tolerance is different for the ISV versus their customers. The software vendor isn’t the one that is going to suffer losses due to information disclosure or breach of integrity.

At this stage, customers usually apply more pressure to implement new features than to focus on security. Of course, this is based on ignorance of the actual situation. The vendor isn’t likely to want to pay the price to improve security… unless the customer knows and applies pressure to get it fixed.

Eventually, a security-conscious customer (i.e. a financial institution or a government) hires someone to evaluate the software, and they start asking hard questions of the ISV. Most of the ISV’s software engineers won’t know the answers because the security mechanism is transparent to their daily work — it stays out of sight, and out of mind. Eventually, people figure out that the encryption is vulnerable to man-in-the-middle attacks or authentication bugs. At first, customers may be reluctant to believe that the security holes are serious, and then they will panic. They will apply pressure to the ISV to get it fixed.

Take-away points:

  • SSL without certificate checks is vulnerable to Man in the Middle attacks.
  • Almost no ISV gets encryption right the first time, and they won’t fix problems unless their feet are held to the fire.