Stop software updates after the system is "stable"?

Question

Yesterday morning I had an OS class and we just started the part about OS security.

When the professor was explaining what is a patch manager, he told us that a computer company he knows which deals in securing servers, after the certification (I don't really know how you certify security when you deal with computers), stops the patch manager because they say

we reached a stable situation so updating the software will solve known bugs but could also end up in introducing new security issues so we don't do that

Now, I do not disagree with the logic of it because it's actually true that you can introduce new bugs, but what about solving the existing ones? And what does mean stable when the word is used in this context?

Answer 1

In theory, what your professor is proposing sounds reasonable. But there's a problem in practice. You never get to a stable configuration. Ever.

There is no non-trivial software out there that doesn't have unknown bugs. None. And some percentage of those bugs are security vulnerabilities.

What does the professor propose to do if someone finds a remote code execution vulnerability in the system after certification is complete?

Does he really believe it's safer to keep a system deployed with a known remote code execution vulnerability than to take the risk of a patch?

The answer (surprisingly) might be "yes". And that goes to the heart of real-world security. Security is really about risk management. Every deployed piece of software has a certain amount of risk associated with that software. The newly deployed software might break an existing line-of-business application. It might introduce new vulnerabilities.

There's basically no way of knowing what might happen. So you need to decide what your tolerance for risk is.

For some systems (often systems where someone's life depends on the system), it's actually better to keep the system unchanged (even if there are known vulnerabilities) and mitigate the vulnerabilities outside the system (with a firewall maybe). For other systems, all you need to do is ensure that your line-of-business applications continue to work.

There is no one-size-fits-all solution here. Every enterprise needs to make their own decision about the risk/reward trade-offs associated with a security patch. Some will accept the risk, others won't.

Answer 2

"Stable" means "unchanging". This is different from the other meaning it's sometimes given in software: "not very buggy". Now the situation could be that there are indeed many bugs, but if the system isn't changing rapidly then it's easier to detect and reason about its current security state.

As you correctly note, this is a double-edged sword: you aren't introducing new problems, but similarly you're not dealing with existing ones. Whether this is the correct thing to do depends on the relative risks of the existing problems becoming known to and exploited by attackers, versus the new problems causing some problem supporting the stable situation.

Answer 3

Stable can mean a few different things.

In a managed environment generally, you bring the OS to the latest known good patch level. That might mean it doesn't necessarily have the latest patches, but it has all known security patches (for known vulnerabilities) and it is tested to work with the software that needs to be installed on it. This is a balance between security and usability.

Each time you patch you can create or expose new bugs and vulnerabilities and also break the software that needs to run on the server. If the patch breaks your web server, then the machine is useless anyway.

One way of handling the dilemma you mentioned is to create staging machines. When you want to try out new patches, you install everything on the staging machines and then test to make sure everything works from a functionality and a security point of view. Since this takes time, effort, and resources, it isn't something you want to do often. Depending on the security requirements and resources you might only do this every 6 months (exception being zero day exploits).

If you want to learn more about this look into configuration management

Answer 4

"stable" has two different and slightly contradictory:

http://www.merriam-webster.com/dictionary/stable?show=2&t=1290292919

1a) not changing or fluctuating

2a) steady in purpose : firm in resolution

2b) not subject to insecurity (sane)

Most software use is an extension of the second meaning - stable software is software which doesn't crash.

Debian stable, and the meaning you are talking about here are the first meaning - stable software is software that isn't changing.

This is appealing because you can find out all the bugs and work out work-arounds for them, and the stability means you won't have new bugs to worry about.

However security bugs aren't like most other bugs: How late a normal bug is found is usually proportional to how important it is. By this I mean a bug found during development is likely to affect a large number of usage cases, and users. Whereas a bug found once the product is deployed is likely to be an edge case, or affect only a small proportion of users. (Exceptions for Y2K type bugs, where a change in users' environment caused large problems).

Security bugs are often edge cases, but once they are know about, attacks against them can affect every user in any usage scenario. So the problem suddenly becomes important to fix for everyone.