Since the events of May 12th; where the WannaCry ransomware attack caused major disruption to the NHS, Telefónica, FedEx and many, many others; there have been thousands upon thousands of online articles written about the incident and what can be done to stop it happening to you. Security vendors have been quick to position their technologies as the silver bullet response to the problem, which has some merit. We know that some anti-malware vendors, Cylance as an example, would have stopped this cryptoworm from executing. A review of security posture is inevitable when a cyber-attack of this scale affects so many people and businesses across such a wide geography (last count 230,000+ machines in 150 countries).
The fact is that in this instance an up-to-date, properly patched system would not have been affected, the security patch for this was released by Microsoft back in March. That being the case, it’s hard to believe so many machines were infected…or is it?
Patching gets neglected for several reasons:
Troy Hunt a Microsoft Regional Director writes about his experiences with system patching whilst working at Pfizer in his blog; one of their biggest and painful challenges was that of compatibility. These points alone suggest that it was only a matter of time before an attack of this magnitude hit the shore and with more than 5000 new vulnerabilities emerging each year; it is impossible for CIO’s and their teams to plug every gap. It can’t however be ignored and a more proactive and consistent approach to patch management is required to reduce the risk.
The process can be broken down into four distinct phases which become cyclical: –
1. Assess
Assess what you have in your production environment, what security threats and vulnerabilities might affect you, do you have the resources and a clear process for applying software updates A) in a scheduled manner and B) in the event of an urgent security patch. You should aim to have an inventory that is well suited to this specific process; with details of the mission critical systems, OS versions, applications, software dependencies and so on. This should lead to an appropriate baseline configuration for your environment.
2. Identify
Establish a method to identify when new software updates are made available, whether these updates are relevant to your environment and whether it needs to be deployed as part of the patching cycle or warrant emergency deployment.
3. Evaluate and Plan
Make decisions over which updates need to be deployed and what is needed to deploy the update. Test the update in a production-like environment to ensure that it will not adversely affect business operations. Create a plan for how and when the patch should be employed (i.e. the workstation needs to be logged on and the machine needs a reboot). The plan should also include how machines are rolled back should there be problems with the installation.
4. Deploy
The obvious aim is to ensure that patches are successfully deployed. This starts with communicating with the groups of people within the business that might be affected by the update (application owners, workstation owners etc). It is important that they know what the schedule looks like, when the patch will arrive and the conditions that need to exist for the patch to install (i.e. machines left on). You can then stage the update across the environment; monitor the progress of the deployment and remediate any failed deployments. You can then assess the success of the roll out, update baselines and prepare to start the process again.
Proactive patch management forms part of our managed service offering; we remove some of the housekeeping burden to allow our clients to focus on other priorities. More about the SMB Remote Code Execution vulnerability can be found on a previous blog posting here