The Equifax breach and hack occurred because of an un-patched Apache server. Recently a manufacturing plant was disrupted because of a VPN vulnerability, one for which a patch was available. There are no shortage of similar stories, where a patch wasn't applied, and a hacker took advantage of the vulnerability. It seems that social engineering was a huge problem a decade ago, but not un-patched systems are becoming more of an issue.

In the case of the manufacturing plant, the hackers seemed to have spent time using the vulnerability to explore the network and eventually attacked database servers, seeing these as the systems that would most likely disrupt the operations and get the company to pay a ransom.

While ransomware is in the news, I find many more "quiet" stories passed among professionals that had to deal with an attack and recover systems. We know that database systems are incredibly valuable and they often provide the information that drives other systems. If you were going to attack a system and stop operations, those might be the servers you look to find on a network.

Many of us that manage database servers aren't also responsible for other systems. We are responsible for our database systems, but do we patch them regularly? I've always been a little more conservative, but the last few years I've looked to patch my own systems more often. In fact, I also want to be sure we are patching production servers on a regular basis, even if they are running well. The quality of Microsoft Cumulative Updates has improved, though they are not perfect. Make sure you test, and keep an eye out for news of issues with patches.

I would also say that regular patching is a good habit to get into for all administrators. You want to be confident you can test and patch systems if needed. This is especially true for known security vulnerabilities. Even if you can't patch other servers, you can set a good example and request others patch to be sure that you don't wind up the subject of a story like the one linked above.