See Previous Issue:  Is Patch management is as Simple as Forwarding an Email?

In my previous article, I talked about how the Equifax Data Breach congressional testimony of former Chairman & CEO, Mr Richard Smith, identified human error (not forwarding an email regarding the Apache Struts vulnerability), combined with a technical error,  as the root cause for the September 2017 Equifax Data Breach.

Patch management – it sounds simple, right? A vulnerability is discovered either by a software vendor or the open-source community, the vendor releases a patch (a new piece of code) that should be installed to address the vulnerability, you apply the patch and, hey presto, your systems are no longer exposed to threat actors who could exploit the vulnerability to gain unauthorized access to your systems.

So why do companies have challenges managing patch management? What makes this process so complex?

In 2018 there were more than 16,000 new reported vulnerabilities

Complexity of IT systems. Modern organizations have complex IT environments. Often there is a mix of older and newer systems. Some systems may be developed in-house, customized or purchased from a third-party software vendor. These systems may run in data centers owned by the company, in someone else’s data center, or in a hosted or cloud environment.  There are high degrees of integration between many of these systems. Finally, as more devices are connected to the network such as IoT or BYOD devices the attack surface and complexity also increases.

Many have Operational Responsibility. Multiple parties may have operational responsibility for different parts of each system. For example, one group may manage the network systems, while another manages databases and yet another manages the application stack. Some of these functions may be outsourced and/or managed by teams in different geographies.

Volume of Vulnerabilities. Then there is the shear number of vulnerabilities and information about them that must be reviewed, analyzed and acted upon. In 2018, over 15,000 new vulnerabilities were reported. Vulnerability information must be reviewed to determine if it is applicable to the organization. It then must be prioritized and instructions on how to address the vulnerability (such as installing a patch) must be distributed to those responsible for taking action.

Unknown impacts. Applying patches in this environment creates risk. The software and hardware could slow down or fail. Key functions of the systems could be disabled or made unavailable to users. The organization could lose the ability to transact or support customers. These are the unintended consequences of patching.

The average time to patch a system is 102 days, according to The Poneman Institute

Given these risks it takes time and resources to test, deploy and document patches. Some patches require systems to be taken offline or restarted, causing interruptions in service which must be planned and scheduled.  According to The Poneman Institute the average time to patch as system is 102 days. That is a long time to be exposed.

Many security companies report that between 70-99% of exploits are based on known vulnerabilities, many of which have patches available to fix the vulnerability. Some report that these vulnerabilities have existed for three of more years. Threat actors continue to quickly develop exploits as vulnerabilities are discovered reducing the mean time for companies to react.  And then we have “zero day vulnerabilities” – zero day means that the exploit is available the same time as the vulnerability is announced.

So this is the reality faced by IT and security teams today – how do you balance cybersecurity risk against the operational commitment and consequences of patching systems?.

There is no silver bullet but here are some key considerations:

• Prioritize – ensure that you have a methodology to prioritize patches for implementation. Not all vulnerabilities are created equal and some will be more important to address now versus later.
• Use automation – the sheer number of vulnerabilities reported require automated processes that do not rely on human effort. This will not necessarily address all issues but it will help.
• Multiple communications – when action is required, there should be multiple communication paths to ensure those responsible to installing patches get the information they need to take action
• Reduce technical debt – the older the systems the likely it will be harder to patch. Executives should be continually reviewing their IT environment to ensure they are reducing risk by retiring and replacing older systems
• Clear roles and responsibilities – operational personnel should understand their role in the patch management process and be trained to be able to execute these responsibilities
• Trust but verify – there should be a process to continually check the patch levels of systems and provide Executives with dashboards on the state of the IT estate.

Patch management can be complex but when Executives make it a priority and establish sound processes it can work. How robust is your patch management?

Next issue:  Who is responsible for Patch Management?

Contact Graeme to schedule a time to speak to your Board or Executive Team.