If you’re in IT, and even if you’re not, you already know it’s critical that your networks and endpoints be protected from cyberthreats.  Nor is there any need to share yet another scary stat related to cyberattacks – especially since last week’s CrowdStrike “incident” (though how anyone can call a problem of that magnitude an incident, is beyond comprehension), made global headlines as it wreaked international havoc.

In the blog post released late on Friday, July 20, the day after millions of computers around the world could no longer connect to the World Wide Web, nor access Microsoft applications, CrowdStrike said, “the programming error was triggered by a sensor configuration update to Falcon, which is a frequent type of update.” Reports today suggest that insufficient testing was done in its sandbox, before the update was rolled out.

Regardless, airlines, banks, hospitals and other critical services were impacted as they weren’t prepared to respond. Could some companies have remained operational with good breach preparedness plans in place?  Experts are divided in the response to this question – but you should still have plans and backup and remediation protocols in place.

For many companies, the impact was severe. It is estimated that in the United States, Fortune 500 companies lost over $5 billion in revenues and gross profit.

Once the dust settles, and the finger-pointing stops, it will boil down to one simple thing: An error was made in terms of how one update was pushed out to users.

Updates and patches have traditionally been problematic. Five years ago, nearly 60% of breaches were linked to vulnerabilities created where patches were available, but not applied.

Today, with more and more applications residing the cloud, the onus is on providers to patch is required. However, patching is not yet a thing of the past. For widely distributed networks, patching can be an arduous and sometimes complex job for IT departments.

Why?

Despite so much having the to the cloud, the number of applications and OSes requiring patches continues to increase, as that the frequency with which vendors need to release new patches to added features, address glitches and reduce/eliminate security vulnerabilities. But increasingly diverse, and sometimes siloed, networks, along with myriad devices which may need to be patched differently, it is no wonder that IT employees can feel overwhelmed, and patches fall through the cracks.

Bottom line, no matter how good your firewall, or internal protocols, if you fail to patch properly in a timely manner, it can be all for naught.

So, given recent events, it seemed like a good time to revisit good patching protocols.

10 Steps for Successful Patch Management

1. Take stock and catalogue

Start by taking inventory of i) all firmware, along with corresponding “end of support” and “end of life” dates, and the software that is running in each endpoint, ii) all operating systems and their version codes, iii) applications, being used along with the contact details for all providers.

If you have a many devices and solutions running, you may need to invest in an automated patch management solution; many of these are able to do this inventory in your behalf.

2. Assess Status Quo

When taking stock, nearly 50% of organisations discover that some of their systems are running outdated applications. In these instances, patching will not work. The solutions will likely need to be upgraded, which may require new licensing. Depending on the scope, it may be worth considering an Enterprise Agreement for the new licenses.

3. Assign Priorities

In most instances, it is not feasible to upgrade and/or patch all systems and applications simultaneously. Not only is it unmanageable, the resulting chaos would leave you vulnerable to attack – and to missing threat vector alarms.

Instead, categorize each component, assigning a risk value to each piece of equipment, operating system, security solution and other applications. Determine which are most critical, and start there.

4. Develop a Strategic Approach for Standardizing Systems

When you are running different versions of an application, or Operating System, it can increase costs and security risks. Standardization can help ensure smooth, seamless network operations and user experiences, but you can’t simply decide to upgrade. You need to factor in your priorities, starting first with the mission-critical ones.

You also need to consider in the hardware upgrades that may be required, and budget for those, too.

5. Test Out Each New Patch in an Isolated, Secure Sandbox or Lab

Every time you deploy a patch, there is a possibility that something will go awry. Even software companies can sometimes release problematic software. Last week’s CrowdStrike fiasco, makes this a gross understatement.

By testing the new patch in an isolated environment, you can identify any impact it is going to have on your current environment. Sometimes, applications that are dependent on and/or interface with a solution that is being upgraded, can be negatively impacted by the change. This is particularly true of customs/proprietary software.

Lastly, under the category of “obvious”: When the security team tests the patch, table top exercises should be run to ensure the patch actually does correct the function-related problem and/ or security weakness it was intended to address – without introducing new vulnerabilities.

6. Document Your System’s State Pre-and Post Patch

It’s important to document the state of your systems before any patch is applied. After the pre-determined amount of time has passed (i.e. how long you want the patch to remain in place before assessing its impact), document the state of your system post patch. If there are problems down the road, this will help you determine if there is any correlation between when the problem began, and a particular patch that was deployed.

7. Identify Endpoints/ Firmware That Need Patching

Next, following your strategic plan (from Point 4 above), start to implement the endpoint patches. Remember to update the master inventory catalogue.

8. Keep Track of What Has Been Updated or Patched

Each time a patch is tested, update the master catalogue, indicating what patches were tested, when – and what outcome was observed. Include any notes or recommendations that will help the next team, with the next phase.

9. Implement a Formal Patch Management Process

Even if you decide to adopt an automated patch management solution, you will need to develop protocols for determining whether or not a patch should be deployed. Safeguards should be created to prevent patches from being deployed accidentally.

10. Rinse and Repeat

Performing regular patch audits can help sure your systems remain secure and robust, offering a good user experience for all stakeholders, whether working remotely or on premises.

Remember:  Patches are your friends but can quickly turn foe if ignore!

If you’d like to discuss patch automation, or a manages services approach to you patching and other network needs, please reach out: [email protected] or call us at 416.429.0796 or 1.877.238.9944 (toll free).