Sunday, March 25, 2007
Cohen on Howard: Chapter 3
Chapter 3 is on good security principles to live by.
Howard:
Cohen:
Nowhere in the text do the authors discourage backwards compatibility. They just point out that it is a major problem when insecure protocols are discovered. They propose a solution: make the newer protcols configurably backwards compatible, such that they can run in the less secure mode in a low-risk environment and in the more secure mode in a high-risk environment.
This is a common problem that people need to face. The book cites attacks on the SMB protocol that required a breaking change to the protocol. Other real-life examples exist as well: SSH1 had a design flaw and needed to be superceded by SSH2.
To say "the lack of backward compatability also implies that they didn't do it right in the first place and won't do it right now" is also incorrect. Sometimes protocols become weak due to unknown flaws in the underlying algorithms becoming known as they are cryptanalyzed by the research community, for example protocols which relied on MD4. At the time of creation, it may have been generally accepted to use these algorithms -- is it fair to say they didn't do it right in the first place? I doubt it.
Howard:
Cohen:
Nowhere does Howard say the most valuable part of a bank is the vault. Rather, he motivates the need for multiple layers of defense in computer programs by relating how other industries protect their assets. It's certainly true that access to the software and data controlling the management of the bank's money is very important -- but this is the very thing he's trying to motivate through his analogy.
Howard:
A protocol you designed is insecure in some manner. Five years and nine versions later, you make an update to the application with a more security protocol. However, the protocol is not backward compatible with the old version of the protocol, and any computer that has upgraded to the current protocl will no longer communicate with any other version of your application. The chances are slim indeed that your clients will upgrade their computers anytime soon, especially as some clients will still be using version 1, others version 2, and so on. Hence, the weak version of the protocol lives forever!
Cohen:
It tells us to remember that backward compatibility will always give you grief, which is why they discourage it. That's right, Microsoft does not want backward compatability, but we all knew that a long time ago. Of course the lack of backward compatability also implies that they didn't do it right in the first place and won't do it right now, or alternatively that there is no right, just eternal change. While this is a good business model, it is a poor information protection approach.
Nowhere in the text do the authors discourage backwards compatibility. They just point out that it is a major problem when insecure protocols are discovered. They propose a solution: make the newer protcols configurably backwards compatible, such that they can run in the less secure mode in a low-risk environment and in the more secure mode in a high-risk environment.
This is a common problem that people need to face. The book cites attacks on the SMB protocol that required a breaking change to the protocol. Other real-life examples exist as well: SSH1 had a design flaw and needed to be superceded by SSH2.
To say "the lack of backward compatability also implies that they didn't do it right in the first place and won't do it right now" is also incorrect. Sometimes protocols become weak due to unknown flaws in the underlying algorithms becoming known as they are cryptanalyzed by the research community, for example protocols which relied on MD4. At the time of creation, it may have been generally accepted to use these algorithms -- is it fair to say they didn't do it right in the first place? I doubt it.
Howard:
When was the last time you entered a bank to see a bank teller sitting on the floor in a huge room next to a massive pile of money. Never! To get to the big money in a bank requires that you get to the bank vault, which requires that you go through multiple layers of defense. Here are some examples of the defensive layers: [...cites examples of multiple layers of defense against vault robbery...]
Cohen:
They tell us that the most valuable part of a bank is its vault - did they miss the information age somewhere? They probably never worked on bank security. These days, the computers have far more value than the vaults (except the vaults that hold the computers of course).
Nowhere does Howard say the most valuable part of a bank is the vault. Rather, he motivates the need for multiple layers of defense in computer programs by relating how other industries protect their assets. It's certainly true that access to the software and data controlling the management of the bank's money is very important -- but this is the very thing he's trying to motivate through his analogy.
