return

Patch Management:
8 Steps to Developing an Effective Strategy

When it comes to developing a Patch Management strategy for your organisation, having the right procedures in place to undertake regular scanning and timely remediation are crucial.

The last thing you want to discover is that vulnerabilities identified months or even years ago have been left un-fixed. Unless you develop an effective Patch Management strategy to keep up to date with timely remediations, you risk leaving yourself exposed.

All too often we see hackers target organisations that, for whatever reason, have failed to patch certain known vulnerabilities, even though they may have been identified years earlier. Perhaps the IT team simply overlooked the patch, or maybe they weren’t aware the vulnerability existed.

Either way – developing an effective Patch Management strategy is essential to ensure you’re not left carrying too much risk.

By developing a Patch Management strategy that follows these 8 steps, you’ll be in a strong position to ensure your organisation stays secure.

01 Asset Management: Know What You’ve Got

02 Get Relevant Notifications

03 Determine Which Systems Need Scanning

04 Automation: It’s Your Friend

05 Patching: Where to Begin?

06 Getting Ready to Patch

07 Patching: Just Do It!

08 Validation: Make Sure You’re Getting it Right!

Section 1

STEP 1:
Asset Management: Know What You’ve Got

This may sound obvious, but if you don’t know what you’ve got, you won’t know what might require patching. That’s why comprehensive Asset Management is essential.

Begin by creating an inventory of all computers, systems and software in your network. Include all desktops, laptops, mobile devices, servers, printers, switches, firewalls, containers, virtual machines, operating systems, server applications and desktop applications.

Don’t forget to include any external or third-party systems and software that are connected to your network. These are often overlooked and can be the weakest link in your environment. For example, you may be using a system that in turn relies on a range of other systems, which may in turn be using open source software. If there is a vulnerability in that open source software, it could impact the systems you rely on, without you even being fully aware of your exposure to the threat.

A major challenge facing many organisations is getting a handle on ‘Shadow IT’ exposure. ‘Shadow IT’ is a term for infrastructure or applications that are used by employees within your organisation without the knowledge or approval of the IT team. With a wide-range range of convenient cloud-based tools available, staff often use these without thinking of the potential security or regulatory implications. Whilst they can be great for increasing productivity, they may expose the organisation to potential breaches. Your organisation may be compromised by staff uploading data to third-party tools or applications without taking into consideration information security.

Furthermore, ‘Shadow IT’ also creates a range of regulatory challenges, particularly those handling sensitive data. It often results in confusion around where people within the organisation have stored data.

Staying on top of your ‘Shadow IT’ exposure is a significant challenge, particularly as BYOD (bring-your-own-device) is increasingly common in today’s workplaces. With a significant number of cyber breaches caused by the usage of insecure, misconfigured or unpatched ‘Shadow IT’ hardware and software, it’s something you cannot afford to ignore.

Limit your ‘Shadow IT’ exposure by implementing controls to restrict what devices and applications can be accessed from within your network. Meanwhile, use your Vulnerability Management scanning tools to monitor for ‘Shadow IT’ through careful analysis of network ports and protocols. Importantly, you should embark on a staff education initiative to raise awareness of the potential risks of ‘Shadow IT’. Those of you who wish to be extra vigilant can require staff to obtain authorisation from the IT department before using any external devices or accessing any third-party software.

Wherever possible, streamline your systems. Hardening systems will reduce attack surfaces. Removing unnecessary systems will mean you have less to patch, saving you time and effort.

In most organisations, new devices and software will be added periodically, so it’s essential to update the inventory on a regular basis. Ideally your inventory will be updated automatically any time a device is added or removed, however manual updates should be done at least quarterly.

Return to Menu

Section 1

STEP 2:
Get Relevant Notifications

Unfortunately there isn’t one single source of information for all patches.

Each system you use will probably have its own method for alerting users about updates.

In some cases, you’ll receive notifications via email. For other systems, you may notice a pop-up message letting you know that an update is required. Many systems will prompt you to run updates automatically when necessary.

Using a reputable Vulnerability Management scanning tool will help you as you will receive regular updates from vendors with information about newly identified vulnerabilities and the associated fixes. Running such tools in your environment regularly will help ensure you’re kept up-to-date.

Some vendors, such as Microsoft, release notifications and patches on a regular basis. Microsoft’s Patch Tuesday is a good example. On the second Tuesday of each month, Microsoft releases updates automatically. Other companies, such as Adobe, have begun following a similar practice.

To ensure you stay up to date with newly released patches, it’s worth keeping an eye on databases that regularly publish identified vulnerabilities with associated fixes, such as NIST. Likewise the MITRE CVE database maintains a Twitter feed so you can receive live updates whenever a new one is published. Make sure you also follow on Twitter any vendors whose products are in use in your environment as this is where they often post notifications about newly issued patches.

Return to Menu

Section 1

STEP 3:
Determine Which Systems Need Scanning

Scanning tools are used to help detect and identify vulnerabilities in your IT systems. When it comes to deciding which systems to scan, your entire network is interconnected. Ideally you would scan it all.

That being said, every organisation has critical systems. The risk that running updates or patching might result in downtime, data loss or potentially a crash, is a serious concern. Imagine a power plant or a hospital coming to a halt – it’s not hard to imagine how this could result in some very serious consequences.

However, simply avoiding updates and patches to prevent possible downtime is not the answer, as it could leave your systems dangerously exposed. If a system is ‘critical’, the last thing you want is to leave it open to exploitation by hackers.

Firstly, make sure you have a Disaster Recovery plan in place. Redundancy systems can help you maintain business as usual operations even if the patching results in some down time. Furthermore, ensure all data is backed-up, so if any information is lost, you’ll be able to retrieve it.

Secondly, speak to the vendors of the products that released the update. Find out the likelihood of any downtime or if the update will result in systems automatically rebooting. Ask if there’s any way this can be avoided.

Thirdly, run patches in a test environment prior to rolling it out. This will help you determine if the update will result in any side-effects or downtime. Read ‘Step 6’ below for more details on the importance of testing while you’re getting ready to begin patching.

Fourthly, consider updates and patching at quiet times, such as at night or on weekends. For some businesses, this might be a viable option as their systems are not being heavily used out of regular business hours.

It’s also important to regularly revisit what systems you’re including and excluding from your scanning. Certain systems may have been excluded in the past, as they were not considered high-risk. Over time, hackers may find ways to begin targeting these systems. It would therefore be prudent to begin including them in your scanning activities.

Return to Menu

Section 1

STEP 4:
Automation: It’s Your Friend

a) Vulnerability Management Tools

Vulnerability Management scanning tools are used to detect known vulnerabilities in your environment. They typically consist of a console and scanning engines. When using scanning tools, placement is important. Often when tools return inaccurate findings, it is because of a placement issue. Perhaps a firewall is blocking traffic, or worse, it is providing you with some results, but not the full picture. This can create a false sense of security. Make sure your tool can reach the relevant network segments and devices you are trying to scan. If you get the same results for a number of devices, chances are there is a firewall interfering with the results.

While many scanning tools are similar, they each have unique functionalities. The one you select depends upon your specific circumstances. Look for one where reports are easily accessible. Also consider whether you want to focus on active or passive scanning. Active scanning will collect the results, while passive scanning involves monitoring network traffic and making decisions based on the traffic.

b) Patch Management Tools

With so many patches to roll out across large, distributed networks, having an effective and efficient way to deploy them is essential. Using a Patch Management tool can save you from having to install them all manually, streamlining the process through the use of a centralised server. This enables you to deploy third-party patches from a central point of control.
Used correctly, a Patch Management tool can save your IT team a great deal of time, so they can focus on other priorities.

Every organisation has its own requirements and this will influence your choice of tool. At a minimum, it should be able to apply patches across every major operating system, including Windows, Mac and Linux. It should also be able to apply patches to different types of endpoints including desktops, laptops, servers etc.
It should also allow patching to third-party applications and provide real-time reporting on the status of updates.

For those using Microsoft, Windows Server Update Services (WSUS) is a Patch Management tool that allows administrators to manage the distribution of software updates across a network. Microsoft’s Endpoint Configuration Manager (previously known as SCCM) is another tool that allows administrators to roll out patches across a large number of computers running on various operating systems.

Return to Menu

Section 1

STEP 5:
Patching: Where to Begin?

Once you’ve undertaken your Vulnerability Management scanning, and you have a report of all the known vulnerabilities in your environment, you need to devise a plan for tackling them.

A common challenge faced by many organisations is getting to grips with large numbers of vulnerabilities. Confronting a scanning report with thousands of entries, each requiring a patch, can be a daunting task for a busy IT department. Often resources are stretched, so dedicating IT staff exclusively to the task of rolling out thousands of patches will inevitably mean other IT priorities are neglected.

To help manage large volumes of patches, we recommend following these three steps:

Categorise

To begin, you need oversight of what you’re dealing with. This is best achieved by sorting the vulnerabilities into manageable categories such as:

Missing patches – Some organisations only patch forward, neglecting to apply past patches on those systems that may have changed over time or changed purpose.
Configuration issues – When scans show many different vulnerabilities on similar devices it can be an indication that build standards or hardening guides are not being adhered to.
Outdated software – Scans may highlight vulnerabilities in devices that exist in your network, but had been forgotten.
False positives – It’s important to identify any false positives in your scanning reports, so these can be weeded out so you’re able to focus on real vulnerabilities in your environment.
Don’t care/low risk – Vulnerabilities that are detected that are likely to have no or minimum impact on your environment should be in their own category, so they allow you to focus on more important vulnerabilities.

Prioritise

Once you have categorised your vulnerabilities, it’s important to prioritise those that are most critical. While ideally every vulnerability would be patched, the reality is you need to focus on the most critical ones first. Not all vulnerabilities need to be fixed urgently.

Context is key. If a vulnerability is found in an asset that is internet-facing or in a critical server, it will be more urgent to fix than a vulnerability in a rarely used internal communications functionality that is only accessed by a limited number of users within your organisation.

To prioritise your vulnerabilities, consider the following:

Importance of asset
The risks of not remediating
Ease and/or difficulty of remediation
Accuracy of vulnerability

Bite-Size

Scanning reports can include thousands of vulnerabilities in need of patching.

Simply instructing your IT department to patch them all will be overwhelming. The job is simply to big to tackle all at once.

For this reason, we recommend breaking the vulnerabilities down into bite-sized sections. This makes it easier for your IT team to begin tackling the task, one section at a time.

We recommend breaking the list into sections by following these steps:

Select what aligns with the organisation’s priorities. You should maximise the use of valuable resources.
Checking that the task is achievable. This helps to determine the sort of support you need.
Identify the quick wins. Will the completion of one simple task resolve a widespread issue?

Return to Menu

Section 1

STEP 6:
Getting Ready to Patch

Testing patches before rolling them out is essential.

Depending on the criticality of the system you’re patching, the amount of testing you undertake can vary.

If you have access to a non-prod (non-production) environment, you should ensure patches are tested there. This is where you can undertake extensive testing of systems, integrations, performance, staging and more, in ways that closely resemble your live, or production, environment.

If possible, you can also choose to test patches in SIT or UAT environments.

A SIT (System Integration Testing) environment is where you can verify that all related systems within the same environment are able to maintain data integrity and operate in coordination with each other. A UAT (User Acceptance Testing) environment is when an end-user performs tests to ensure the system works correctly before going live.

Not all organisations have access to non-prod, SIT or UAT environments. In such circumstances, you can still undertake ‘pilot’ or ‘canary’ testing.

‘Pilot’ testing involves rolling-out the patch to a select group of people in your organisation. This allows you to test how the patch affects other systems before extending it to the rest of the organisation. End-users are aware that you have updated their systems with a patch, so they can report any functionality difficulties they experience in the hours and days after the patch is deployed.

Alternatively, you can also conduct ‘canary’ testing. It is similar to ‘pilot’ testing, except the end-users are unaware that the patch has been deployed. In both testing modes, end-users should be selected that have lower levels of privileges so any negative consequences are less likely to affect critical systems.

Whatever type of testing you conduct, you should test rigorously. Make sure you test all the functionalities of all the applications thoroughly before rolling the patch out to the live environment.

This level of testing is essential to ensure the patches do not inadvertently result in unforeseen consequences that could damage systems your organisation relies on.

Whilst undertaking testing, you will be able to determine whether computers will require rebooting, and whether this will occur automatically or not. This is important to know so you can plan when to roll out patches. Allowing for a maintenance window during which you apply patches in the production environment will help you avoid unexpected reboots that could lead to downtime, or possibly damage databases.

Bear in mind that the majority of patches will require computers to reboot.

Another consideration as you’re preparing to start patching is whether you need to follow rules-based IT workflows, also known as Change Management procedures. These can include obtaining authorisation from management prior to patching. They should be followed whenever the addition, modification, or removal of anything could affect IT systems.

While an organisation probably wouldn’t be expected to follow strict Change Management procedures every time a minor patch is rolled out, they should when the update is substantial or risks business as usual operations.

The objective of Change Management procedures, such as those established by ITIL (Information Technology Infrastructure Library), is to ensure that rules are established and followed so changes to IT infrastructure are efficient and reduce the likelihood of any potential problems.

In addition, make sure you have your redundancy plans in place. This includes ensuring all data is backed-up. In the event an update does result in any negative side-effects, you will have the ability to roll-back, or uninstall, the patch. You will also be able to retrieve lost data. It is recommended that you document any anticipated changes to your IT environment that will occur as a result of the patching. This will help you in the event of any unforeseen problems resulting from the deployment.

Importantly, make sure you notify people within your organisation that you are planning to roll-out patches and how this could affect the systems they use. They should be advised to save and backup any work. Other people in your organisation can also help you notice any performance issues or problems once a patch is rolled-out.

Return to Menu

Section 1

STEP 7:
Patching: Just Do It!

When it comes to rolling out your patches, there’s much to be said for adopting an Aggressive Patching style.

Whereas in the past, many organisations adopted a cautious patching approach in order to avoid causing unforeseen repercussions, times have now changed. The major vendors have mature patch creation processes. Generally speaking, they have become adept at developing and rolling out patches without negative side-effects. That’s not to say there will NEVER be any problems with patches, but thankfully these are becoming rarer.

So, what is Aggressive Patching?

Aggressive Patching adopts an ad-hoc approach, rather than relying on cyclical patching timetables. It emphasises patching regularly, whenever an update is released. Patches are rolled out in an ongoing and timely manner.

Organisations that perform cyclical patching, where many updates are done at once, but on a less frequent basis, may find they experience a range of problems that can be avoided with ad-hoc patching.

If you’re regularly rolling out patches, then you should be able to avoid having to fix a large number of vulnerabilities at any one time. Often, when organisations undertake infrequent, but large-scale, patching cycles, various systems begin to experience difficulties. Managing the roll-out of a large number of patches at one time can be more challenging and prone to difficulties than regularly implementing one or two updates.

Naturally, every organisation’s patching approach will vary depending upon its risk appetite and how it handles its critical assets. However, the current trend is towards Aggressive Patching as it avoids many of the issues with cyclical approaches.

When it comes to the automatic updates that third party vendors prompt you to run, the message is clear – Just do it!

Return to Menu

Section 1

STEP 8:
Validation: Make Sure You’re Getting it Right!

Effective patching requires ongoing diligence.

Whilst there are tools that can help automate parts of the process, it still requires significant human effort. Ultimately, Patch Management is about mitigating your organisation’s risks.

It’s essential that you constantly keep an eye on new threats in the wild that are seeking to exploit vulnerabilities.

You should regularly audit your Patch Management strategy, not only to ensure that you are rolling out the latest patches, but that you are revisiting the range of assets you’re scanning, that you are hardening your infrastructure to reduce the likelihood of vulnerabilities, and that you’re protected against older exploits that may have been missed.

After you roll-out patches, you should check to ensure the roll-out didn’t fail. You should also regularly check for pending patches.

In the hours and days after you roll-out a patch, keep an eye on systems to identify any signs of incompatibility or performance issues. Importantly, make sure you communicate the fact that you’ve rolled-out patches to users within your organisation so they’ll know to report any potential problems they encounter.

By following these 8 steps, you’ll be able to implement and effective and comprehensive Patch Management strategy in your organisation, ensuring you’re protected from an ever-growing list of exploitable threats.

Return to Menu

Vulnerability Management Best Practice

LIVE in the HOT SEAT

When it comes to maturing your organisation’s Vulnerability Management strategy, Mark Hofman provides the expert advice you need to ensure you’re on the right path. Click below to listen to all of Mark’s insights about Vulnerability Management.

VIEW RECORDING

Questions & More Information

Do you have a question about vulnerability management? Contact us today to speak to one of Shearwater’s certified consultants. They have extensive experience in conducting vulnerability assessments and assisting clients to meet their vulnerability management goals.

GET IN TOUCH

Patch Management:
8 Steps to Developing an Effective Strategy

STEP 1:
Asset Management: Know What You’ve Got

STEP 2:
Get Relevant Notifications

STEP 3:
Determine Which Systems Need Scanning

STEP 4:
Automation: It’s Your Friend

STEP 5:
Patching: Where to Begin?

STEP 6:
Getting Ready to Patch

STEP 7:
Patching: Just Do It!

STEP 8:
Validation: Make Sure You’re Getting it Right!

Vulnerability Management Best Practice

LIVE in the HOT SEAT

When it comes to maturing your organisation’s Vulnerability Management strategy, Mark Hofman provides the expert advice you need to ensure you’re on the right path. Click below to listen to all of Mark’s insights about Vulnerability Management.

Questions & More Information

Consulting & Compliance

Penetration Testing

Managed Services

Training & Education

Subscribe to Our Security Updates

Patch Management: 8 Steps to Developing an Effective Strategy

STEP 1: Asset Management: Know What You’ve Got

STEP 2: Get Relevant Notifications

STEP 3: Determine Which Systems Need Scanning

STEP 4: Automation: It’s Your Friend

STEP 5: Patching: Where to Begin?

STEP 6: Getting Ready to Patch

STEP 7: Patching: Just Do It!

STEP 8: Validation: Make Sure You’re Getting it Right!

Vulnerability Management Best Practice

LIVE in the HOT SEAT

When it comes to maturing your organisation’s Vulnerability Management strategy, Mark Hofman provides the expert advice you need to ensure you’re on the right path. Click below to listen to all of Mark’s insights about Vulnerability Management.

Questions & More Information

Consulting & Compliance

Penetration Testing

Managed Services

Training & Education

Subscribe to Our Security Updates

Patch Management:
8 Steps to Developing an Effective Strategy

STEP 1:
Asset Management: Know What You’ve Got

STEP 2:
Get Relevant Notifications

STEP 3:
Determine Which Systems Need Scanning

STEP 4:
Automation: It’s Your Friend

STEP 5:
Patching: Where to Begin?

STEP 6:
Getting Ready to Patch

STEP 7:
Patching: Just Do It!

STEP 8:
Validation: Make Sure You’re Getting it Right!