Security professionals feel no great joy in being right about patching.  The past two months have been a period of “I told you so” moments for anyone who has ever had to have the conversation with a sys  admin about the importance of patching (it’s been a long time for me but the memory lingers).  Still  security professionals care more about being safe than being right so, as I say, there’s no great joy.  But, now that we’ve had two months of ugly exploits that were very much enabled by unpatched systems and everyone appears to be paying attention, we should take a few moments to review the excuses we’ve heard for why it was not important to patch.  We should be able to finally de-bunk the excuses and I think I speak for everyone in security when I say we hope to never hear them again.  Consider this a proactive set of canned responses to be used to reply to sys admins and their managers who, at some future time, somehow forget about the WannaCry-Petya attacks.

1. “Patching takes time and my staff is busy.” So the question then is: are you sure keeping the infrastructure secure is part of your department’s mandate? Go check.  If you did check and if keeping the infrastructure secure is not included in it, then find the folks who are responsible for keeping the infrastructure secure and make sure they’re patching. But, on the other hand, if keeping the infrastructure secure IS your responsibility then the question becomes: does your staff have something more important to do and who made the decision that it was more important than patching?  Perhaps the person who made that decision should reconsider.  Finally, if keeping the infrastructure secure is not anyone’s responsibility, jump up and down waving your arms until it is.  Security will be there jumping up and down  and waving with you.
2. “These machines don’t connect to the internet so they don’t need to be patched that often.” These latest attacks made it abundantly clear that malware is capable of spreading like a weed. And it doesn’t matter if the weed first started in your neighbor’s backyard; once it jumps to yours, anything can happen. Not to mention the fact that some of your most important machines may not ever connect to the internet but may bring the business to a halt if they get infected. So maybe whether or not something connects to the internet is not as important to patching as whether or not something is important (or connected to something important).
3. “Patching can break something.” You mean what if patching breaks a test machine as opposed to not patching and finding that an outbreak of malware was so severe that you have to send everyone home?   Patches should be tested.  If patches DO break something on a test machine, then some level of effort or risk must be taken on.  But make those decisions explicit, not a matter of inertia.
4. “My staff will get to patching as soon as they’re done with the nextthingmobilecloudIOTbigdata project.” Patching is boring.  When faced with the choice between working on that sexy new deliverable that is super high profile and patching the system, we are all tempted to work on the shiny stuff.  See #1 above for more on this.

Security and IT Ops are good partners in most organizations but the time and attention commitment involved in  patching often challenges IT Ops who are being asked to make EVERYBODY happy.  If there is one learning that came out of the past two months it’s that your organization de-prioritizes basic system hardening at its own risk.  And if anyone wants to understand just what that risk is, they can type “WannaCry” in their search engine of choice and hit ENTER.