Many organizations seem to apply a sensible heuristic to patching: patch the systems that are most exposed and valuable first, in descending order of exposure and importance. The heuristic usually looks something like this:
- Internet facing systems – patch first
- Critical internal production systems – patch second
- Other production systems – patch third
- Development, test, and other lab systems, patch last
Workstation patching usually ends up in there somewhere, but is usually performed by a different team and different processes and so a bit orthogonal to this scenario.
The reason for this prioritization of patching is that most organizations don’t apply patches automatically to servers and other infrastructure. Generally, even when automation is used, there is some amount of testing and sequencing applied to the process. It makes sense to apply patches in a manner that reduces risk from greatest to least.
I’ve noticed a potential problem with this strategy in the aftermath of the MS17-010 patch in March, 2017, and in the recent Microsoft Security Advisory 4025685.
First, organizations should be assessing whether a new vulnerability is wormable, Generally the condition for that is remote, unauthenticated code execution over a network network on some kind of system or service that is common enough for a worm to be a threat.
Second, some consideration for the attack vector should be factored in. If, as was the case with MS17-010, the vulnerability is in SMB (TCP/445), but none of your Internet facing systems have TCP/445 exposed, prioritizing patches for Internet facing systems over other systems likely doesn’t make sense. Patching the most critical systems that are the most exposed to that vulnerability should be the heuristic used. That can be complicated, though. In the case of something like an SMB vulnerability, the most exposed servers are likely going to be those servers that are accessed by the organization’s workstations via SMB.
And certainly we should be proactively limiting our exposure by following more fundamental best practices, such as not permitting inbound TCP/445 access to systems and disabling SMBv1 in the case of MS17-010.
To sum up, a single heuristic model for prioritizing patches is sub-optimal when trying to reduce risk. Some additional thought may be required.
P.S., MS Advisory 4025685 appears, to me anyhow, to have the potential to lead to some significant attacks in the near future. Hopefully you are already limit TCP/445 where possible and are in process of applying the patches.