Is it recommended to patch announced vulnerability for unused services or features?

Question

Sometimes vendors announce software upgrade to patch some discovered vulnerability in some feature or service which is not enabled in your system. Is it recommended to upgrade your software although you are theoretically not affected by?

Answer 1

This is a risk assessment and threat modelling style question - rather than a hard yes or no.

Do you want to accept the risk of not patching the service, which could be exploited in the future - may be someone runs it later on. Or do you not accept the risk of updating your OS/software which could cause adverse affects on running services.

Only your individual situation will be able to answer those, and often there will be different answers depending on the threat landscape and importance of the server/application in which you are assessing.

Answer 2

The short answer is 'yes' for most people!

This is because it is often hard to isolate features or services as well as you would like to or need to, and it is also time consuming to record and manage unpatched code or services that might be used in a future scenario. Patching even unused features or services avoids the risk of 'forgetting' or mismanaging patches and updates in future architecture or use-case changes.

However, as ISMSDEV points out, the more accurate answer is that it depends on your risk assessment. All remediation work such as patching and update should be managed as part of a risk management process and that's the only effective way of winning in the risk/cost/benefit equation (unless you have uncapped sec resources!) If you decide not to patch update then the least you should do is record the decision, understand the risks stemming from that (how to manage use case changes in future etc) and re-assess based on the new risks introduced by not patching and updating.

So, in short, your ongoing risk assessment process should answer this question for you in each case.

Answer 3

Both answers listed are correct. As a rule, even if a service isn't used, patching it is still a good idea as it helps either reduce or eliminate a vulnerability. Unless you're in a very tightly regulated environment, it's difficult to say for a fact "we don't use that service and never will". Things change, and having to investigate whether to update that service or not, even though it should be part of that rollout, takes time and may not be done. By automatically patching that, you prevent missing that step and also have it patched in case it accidently or maliciously gets turned on.

That said, ISMSDEV's response is also valid. I have yet to work for a company that has unlimited resources. We're all busy and maintaining unused services takes time away from actual production work. If you're in an environment where tight controls over changes need to be maintained, patching an unused service will take effort to validate that the change doesn't affect something else. That causes expense and delay on validating something that isn't used, which might be considered a waste of money unless you can demonstrate a return on that expense.

Where does that leave this response? The question didn't address this larger question: what kind of environment? If it's a bunch of corporate desktops, then the answer is most likely "yes". If it's servers, manufacturing devices, or other devices where condition and reliability are critical, then it may make more sense to manage these more.