Learn patch management—part 1, the basics

There is no escape from the need for patch management and updates. It is true that operating systems and software vendors are getting better, faster, and more efficient about how they make and deploy patches. However, for businesses, patch management remains a time-consuming necessity that has big impacts on security, compliance, and day-to-day operations for IT teams and the businesses they serve.

The reality of patch management is that some planning along with automation is not just nice to have, but rather a need for businesses of any size. The U.S. government’s National Institute of Standards and Technology (NIST) tracks reported vulnerabilities and the “severity” of each. Their report shows that there is a new “here to stay” trend in the growing number of vulnerabilities that IT teams cannot keep up with on their own.

The need to understand patch management and how to create a patch management solutions is critical, and no matter what stage in your career, it never hurts to learn and re-learn the best practices and strategies. Therefore, I’m kicking off this multi-part series on patch management with a look at the basics. Yes, this starts off at the beginner level, but stay tuned for deeper insights as we go.

What is patch management?

Simply stated, it’s the process of applying updates to software. Though if we are to dig deeper, what is important is the motivation of an update. Meaning, what is the intended update from the vendor? Most commonly this is:

• New versions with new features
• Bugs being fixed
• Security vulnerabilities that need correcting from their own code or provided by third-party code that is integrated into their software.

No matter the motivation of the software vendor (including operating system vendors), they all tend to include multiple types of updates into a single “patch”.

Fun fact: the term “patch” in the IT world comes from days when computers used punch cards as their set of inputs. When a card was damaged or inputs changed, it could then get a “patch” to restore the card to working order.

Related Product

N‑sight RMM

Comece a operar rapidamente, contando com o RMM, projetado para MSPs e departamentos de TI de pequeno porte.

Find out more

What software and devices need patches?

My first response to this question is all of them! However, this is not extremely helpful, so let’s expand on this.

For many years patch management was limited to servers and workstations. Today this is extended to IOT devices, mobile devices/applications, and even appliances. If the word “smart” is in front of a product, then there is a good chance it will need updates. For businesses, there should be a focus on:

• Windows and Mac operating systems
• On-premises software
• Cloud-based applications require patches (even if conducted by the vendor)
• Microservices

The thought that a cloud or SaaS application means you do not need to worry about patches and updates is not true. When selecting providers and tools, it is always important to keep in mind the level of security that you expect from the vendor, and it should be factored into your selection.

After all, the cloud is simply somebody else’s computer!

What types of patches are there?

There is no straight forward answer to the names or labels that various vendors place on the types of patches, or even severity of patches. However, there is a common-sense approach to this. To begin we will go back to the list we provided on the “motivations” of a patch.

Non-security-related patches—these will typically split based on the size of the patch/update

• Patch—would fix a single issue or bug
• Bug fix—is usually an update with multiple bugs being addressed
• Minor release—is typically a roll-up of minor feature changes and bug fixes
• Major release—Contains major feature work as well as all other updates up to this point, including bug fixes.

Security-related patches

NOTE: security patches can be released on their own separate from non-security-related patches, however they are often bundled together.

• Zero day—these are emergency patches which require immediate deployment based on the severity and the volume of attacks which are exploiting it. These tend to be rare.
• Critical Security Patches—these are major security updates that should be taken very seriously and should be the first to be deployed and should protect your most critical devices.
• Important Security Patches—these patches tend to hold less severe consequences than critical but otherwise are still worth deploying and treating with the same care as critical patches.
• Moderate—these are typically minor security updates or fixes that affect very few or are limited in the gains that an attack may get from exploiting it.
• Low—these are very minor security issues that typically have low gains from attackers and high levels of effort to exploit. Meaning, if they are already this far, it might be too late.

Now some may believe that the above list is not perfect or is not how XYZ vendor sees the world and that may be true. Though the point here is to simply use a common-sense approach on how to untangle the multitude of naming conventions so that you can relate to what each vendor uses.

For example, if you click on this link you’ll see the Windows 10 software update types. They make sense for Microsoft, but they do not apply to all software providers.

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

Find out more

What is the difference between patch management and vulnerability management?

There are a lot of terms used in the industry to describe the same things and it can get a bit confusing. So, getting a strong understanding of them can help you translate the day-to-day usage that varies from one IT professional to another.

To start, let’s cover what are “vulnerabilities”, as this is the broader term. Vulnerabilities are weaknesses in the IT environment. Those weaknesses can come from a multitude of places. While we are not diving deep on vulnerability management, it is important to understand a few examples:

• Configurations: how we configure software such as firewalls, how logins are managed, or where data is stored with what permissions are all “configurations” that, if not set correctly or protected properly, can leave a network vulnerable. Why have Simple Mail Transfer Protocol (SMTP) installed or port 25 open on a server if no email messages need to be sent or received?
• Firmware updates for appliances: these are often forgotten, however, appliances simply run operating systems and software just like any other device. As such they too need updated.
• Security patches: these are specific patches that software vendors release to correct security problems in their code that would otherwise leave a company vulnerable to be exploited.

Security patches are where vulnerability management and patch management overlap and where most of the “jargon” amongst IT professionals comes from. While we learned earlier that the motivation of a “patch” can vary, the security patches are meant to resolve and protect weaknesses that exist in the software that could be exploited by threat actors. This sounds very similar to what a “vulnerability” is.

In the end, vulnerabilities cover a broad range of weaknesses in a network, while patch management is specific to software updates, fixes, and security patches.

How do threat actors use unpatched software?

To understand how threat actors use unpatched software, it is helpful to remind ourselves of the objectives threat actors hold and their motivations. Long gone are the days when threat actors were simply vandals; they are now sophisticated, financially backed criminal organizations that are run like a business. Like any business, they identify their target market with their product or service and attempt to reach as many of those targets as possible. When they do find one, they would like to maximize the value of that target.

As it relates to patching, the following is a quick list of how unpatched software plays into this:

• Reaching a wide audience
  Threat actors will look for software applications that are the most widely used by most companies, such as Microsoft OS, Office, Adobe, web browsers, and more.
• Find the easy “wins”
  They tend to prey on the most vulnerable software, which often is legacy unsupported/nearly unsupported software and operating systems. Windows 7, or Exchange 2003, are a bit long in the tooth and are prime targets.
• Gain access and persist
  There are many ways that unpatched software can leave an environment vulnerable to security threats, of which those that provide elevated permissions or access to multiple devices are valuable to threat actors. They will use this access to continue their process and spread out across the network, giving them a better chance of not being caught and access to more data.

What are the major parts that make up a good patch-management program?

As mentioned, this is part one of a multi-part series, therefore we will not go into much more detail on all the bits and bobs of a good patch program. However, the following will provide you with a good place to start that can even be beneficial to those who have been running a program for many years—there are always ways to improve.

• Scope and visibility
  A good patch program needs to start out with the scope of the network you wish to patch. This should include which devices, by group, with some level of importance that relates to reducing the risk of business downtime. The visibility portion should include a plan that continuously allows you to discover devices entering and exiting the business.
• Policies
  Based on the importance of a device or group of devices, or based on the severity of a patch, you should plan out and maintain documentation of your desired policies for when and which patches are deployed.
• Patch operations
  While patch operations are very close to policies, the major difference here is this is all about how you and your teams will manage the day-to-day of patching. Not all patches will work correctly and not all devices need or want the latest patches due to conflicts or legacy application dependance. What is important here is not to overload yourself with all the devices all at once.
• Patch testing and vetting
  Ensure there is a pilot group of devices that you test that contains a mix of non-critical devices (servers, workstations, etc). This could give you insights into how well or poor your next roll-out might be.
• Reporting
  Often overlooked, reporting before and after roll-outs is important and should contain the data you need for your security program, your operations, and any compliance regulations you might have. (These are often multiple reports). This will give you a sense of your progress on minimizing risk to your company.
• Governance
  As we see from the NIST report, more and more security patches are needed each year and there is really no way to keep up manually. It is important that only software that is needed is installed on company devices. This means setting governance and monitoring up to identify and remove any unauthorized software.

After reading through this article, you should be in a better position to understand what patch management is, the difference between patches and vulnerabilities, the types of patches, and the major components of a good patch-management program. In part two, we will explore why organizations need a patch-management solution and what to look for when deciding what to use.

Joe Kern is senior product manager at N‑able