For a manager concerned with using these laws for defense, two of the primary concerns should be risk management and cost/benefit analysis. When you’re presented with a choice, whether it’s about deploying a new service, or about deciding how much time to spend doing security review before rollout, you need to quantify things as much as possible. For example, when you install a new piece of software, you have to know what’s being put at risk. If its destined to hold customer credit card numbers, then a large amount of up-front investment may be war- ranted. If it’s intended to go on an internal server that all employees have access to anyway, it may not matter that it has holes.
Among the items you have to weigh are: What happens if it fails? (What’s the cost?) Is there an easier way to break in? (Take care of the eas- iest ways in first.) What will it cost me to do a security audit of this system? Without performing this analysis, you’ll have to rely on guessing, and you won’t be able to justify your decisions to your employees or your managers.
that something is more secure simply because it’s newer. Possibly the basis for this belief is that people assume that past mistakes are always learned from, and that once something is fixed, it stays fixed forever. That’s just not the case.
Probably the biggest example of this belief in action is Windows NT. For the first couple of years of NT’s existence, many Windows bigots would point at all the known security problems in other operating systems and scoff. They would ask, “Where are the NT holes?” Even Microsoft itself picked up on this for its marketing campaigns. That didn’t last long. Once NT achieved a reasonable degree of success, and people began to become familiar with it, it also caught the attention of the hackers. Now Windows NT gets its fair share of bugs pub- lished, just like any other operating system.
These bugs were always there; they just weren’t known, which is not at all the same as not having been there to begin with. Why does it matter whether the bug is known? How can it be used if it’s not known? The problem is with who knows it exists. “Not publicly known” means that you (and the rest of the world) don’t know about the problem, but I might. I might have discovered it myself, and decided to save it for my own use. Therefore, I’m in possession of a hole that I can exercise at any time, and you will be vulnerable.
Are you secure? No. Do you think you are? Probably. You should train yourself to think the opposite of this “law.” Assume that anything new, that hasn’t stood the test of time and many attacks, is broken, not better.
Applying the Law
This is a specific case of people thinking something is better because it’s new. If it’s security related, the assumption is that it’s more secure.
If you look back to the section on cryptography, you’ll see that this is defi- nitely not always the case. Even in the case in which the item in question is a patch specifically designed to make something more secure, you have to be careful to pay attention to the vendor’s track record; has this vendor reintro- duced errors? Has the vendor had regression problems? For example, a couple of times Microsoft has managed to introduce new errors, or to fail to include a hotfix, in a new service pack. The same goes for several CheckPoint Firewall-1 service packs that have resulted in system instability.
This type of problem leaves administrators in a bad position. Do they leave themselves exposed to the known vulnerability, or do they take a chance that the vendor hasn’t done a good job with testing, and they’ve been handed a worse problem? Of course, it will be up to you to decide which is the lesser of two evils. If you can wait, it is sometimes better to let others experience the pain first. However, if the bug is serious enough, you may have to apply the patch, unless you’re willing to take the machine down in the meantime.
Open source software can have the same problem. Often when a vulnera- bility is announced, people will post patches. The problem becomes evaluating those patches. You may see several different patches for the same problem.
Which is better? Does one of them introduce a new problem? Has the author even tried it? Perhaps a bad guy is taking advantage of the situation, and he’s trying to slip you a bad patch. It’s the same problem as with the commercial vendors. You’ll have to decide whether you want to take your chances with the patches given right away, or wait for something “official.”
Exceptions
Some small communities of people, IT professionals, security people, and cor- porate managers are starting to be more cautious about being the first to try something new (referred to as being on the “bleeding edge”). But, in general, there will always be huge groups of people who will fall for this tactic.
Defense
Keep in mind that new means untested. If you can afford it, give all new systems and software time and a fair evaluation before putting them into production.