Robin Varley, our Senior Data Protection Manager, explains how poor passwords and bad patching can expose your business and your customers in ways you can’t imagine … and yet could be so easily avoided!

Unforced error of the cyber world

In sport, we are familiar with the concept of the 'unforced error'. This is where a player loses a point as a result of a personal mistake, rather than the skill of their opponent. In tennis, this is typically where the player misjudges a shot and hits the ball into the net or out of court.

In cybersecurity, the two main unforced errors we come across on a regular basis are poor passwords and bad patching. While it’s possible for these kinds of oversight to seem insignificant, the truth is that they can have catastrophic consequences when the opposition (in this case a cyber criminal) takes advantage of the mistake.

Much has been written about poor password management with 'guessable' or frequently used passwords providing easy entry points for hackers. Patching, however, is equally important and perhaps less well understood.

What is a patch?

Patches are system updates produced in response to the new vulnerabilities or anticipated threats. Patches are sometimes also referred to by software engineers as 'fixes', because they are typically produced to resolve these problems.

New vulnerabilities are discovered on a regular basis and the production of patches is how software providers build in ongoing security for their customers and future-proof the resilience of their products. Many are scheduled to combine improved functionality and features with a regular patch-management programme. However, in some circumstances, they are speedily put together patches designed to respond to a specific and urgent threat.

Why patch?

One example highlights not only the role of patching, but also how an unforced error – failure to implement the patch – can lead to complete system failure.

Back in 2017, a ransomware worm called WannaCry infected computers and encrypted the hard drives so users could no longer access them. The worm, which took advantage of a recently identified vulnerability in Microsoft operating systems, then held those files to ransom demanding payment for their release. Microsoft promptly produced a patch that closed the hole through which the WannaCry worm could gain access. Yet two months after the patch had become available, the NHS suffered a major attack from WannaCry that crippled its system, cancelled more than 19,000 appointments and cost in the region of £92 million to clean up and rectify.

How could this be the case when a patch was available? It was not the failure of the patch, but the fact that people within the organisation had failed to apply it. This begs the question, why would anyone not implement a patch?

What are the reasons for failing to implement patches?

We are all familiar with regular requests for systems updates. They often occur at inconvenient times and, when we are busy, the prospect of shutting down our computers for the update to make changes feels like an unnecessary waste of time. For network systems, the same issues apply and many organisations are reluctant to take their systems or services offline (and therefore unavailable to clients and customers) for the time required to implement the patch.

As with most cybersecurity challenges, the issue of patching needs to be addressed through the assessment of risk or, more accurately, the right balancing of risks. A regular known patch window can assist in this and, as more services are being virtualised, a staged approach to patching may be the answer – one that allows a reduced, interim service to remain in place.

Where an emergency patch appears outside the regular patching schedule, the inconvenience and potential downtime of the system need to be assessed in the context of the potential downtime and loss of revenue incurred by a system failure or breach. A brief pause while the system is made secure is likely to be the lesser of the two evils. However, not all patches require a system to be shut down. Some speedy patching, or 'hotfixes', can resolve vulnerabilities without affecting system uptime at all.

When patching has knock-on implications

System managers may also be reluctant to implement patches because they are concerned about the implications for the rest of the system. This is because, although software developers will test the patch in a variety of settings, they may not have had time to explore exactly what the knock-on effects will be for all systems. There is a chance that an unforeseen chain reaction will cause the patch to break something else within the system, requiring a further investment of time and resource in resolving these issues.

This has, however, become less of a problem over recent years as patches have become more robust. In all but emergency situations, they will have been thoroughly examined and tested. Indeed, many organisations now allow Windows patching, for example, to happen automatically. However, it is good practice to test all patches within a development environment, like User Acceptance Testing (UAT), which is near-identical to the production environment, thus ensuring that that any unforeseen problems with the patch application are found and resolved before it impacts the main system.

In case of an undetected issue getting through, it is also good practice to have a roll-back plan that makes sure that people know how to return their systems to a good state.

Patch management

With a wide range of equipment and operating systems across a number of locations, including home offices, it has never been more important to implement a patch-management plan. Just one failure to patch can have implications across an entire network.

A programme for scheduled updates can take account of the optimum timing of patching. Where a system needs to operate 24/7, a period of downtime can be arranged in advance to cause as little disruption as possible.

A risk assessment will help to prioritise the need for emergency patching. For example, where a vulnerability only applies to a subset of devices, it may be reasonable to delay patching until a convenient time. When a vulnerability requires urgent attention, however, there should be a strategy in place to shut down and implement a patch immediately.

Patch management is not a standalone solution, but an integral aspect of your overall cybersecurity plan. It should be implemented alongside a penetration testing programme to reveal otherwise undetected vulnerabilities for which patches are not applicable or have not yet been produced. Expert professional guidance will help you to develop and implement a pragmatic and effective cybersecurity management plan that includes patch management. In this way, you can avoid the risk of an unforced error gifting a victory to your opponent.

Elavon can help you identify real-time patch issues with your website, including any malicious malware that may be present. We can also support you with any other PCI DSS, GDPR or cybersecurity challenge you may face. Contact us to discuss your data security needs.