It's Friday morning. Birds are chirping, bees are buzzing, and you're quietly sitting at your desk enjoying your favorite beverage while reading the latest tech news. Suddenly, panic sets in as you read that the recent update of "software x," which you just distributed to your endpoints, introduced a severe vulnerability. Obviously, your rigorous testing can't be to blame; sometimes, these things just slip through the cracks. But, now that your adrenaline has kicked you into high alert, what do you do? Let's discuss.
When a vulnerability is discovered in a piece of software that is utilized on your network, you generally have four options:
1. Roll back the software to an earlier version
2. Implement a workaround
3. Ignore the vulnerability and accept the risk
4. Uninstall the software
Let's briefly go over each of these options.
When an update introduces a vulnerability, often the best solution — and the one that has the least negative impact on users and operations — is to roll back the software, restoring it to its last known good configuration.
When an update introduces a vulnerability, it's common for the developer to quickly provide a workaround to negate the vulnerability while they work on a patch to patch the patch (what a fun phrase). Sometimes workarounds are easy to implement, but occasionally they require drastic changes that could impact functionality.
This is a do-at-your-own-risk type of solution. Obviously, having a vulnerable system on your network is a no-no, but occasionally you don't have any other choice. When a system is critical to operations and rolling back or implementing a workaround isn't an option, then accepting the risk is all you can do. In these situations, you'll still want to do whatever possible to minimize the risk. Additionally, sacrificing old computer equipment to the sysadmin god of your choice may or may not reduce your chances of the vulnerability being targeted by cybercriminals.
Uninstalling software that has been impacted by a vulnerability is an obvious solution, though not feasible in many situations. Organizations aren't in the habit of installing unnecessary software. I think you'll find that most users are unwilling to let go of applications they depend on to get their jobs done.
Determining how to handle a vulnerable application on your network isn't always easy, but there's really no right or wrong answer. It all depends on your network and your organization's needs. Here are some guidelines.
In most cases, you'll want to try to either roll back the software or implement a workaround. Rolling back software often has the least negative impact on an environment. Keep in mind that this option may delay the adoption of new features and security fixes, so you must consider those things compared to the severity of the vulnerability.
Implementing a workaround is also a good option if one is available. Some workarounds are easy to implement and won't impact usage. However, some can be difficult to implement or require that you modify features or settings, which would negatively impact the usefulness of an application.
If rolling back the software or implementing a workaround aren’t options, then your last-resort options are ignoring the vulnerability and accepting the risk while waiting for a new update or uninstalling the impacted application. You should only consider accepting the risk if the affected application is a critical system of the organization. Uninstalling the software is drastic, but it is worth considering if the software isn't vital and users can live without it until a new patch is released.
So you've recently rolled out a new version of an application to hundreds of endpoints only to discover that the latest update included a pretty severe vulnerability. As panic starts to set in, you remember that you're using PDQ Deploy and Inventory, so you can easily revert to a vulnerability-free version of the application. Let's look at a couple of examples to demonstrate how to do it. Keep in mind that the applications targeted in these examples are only being used as examples and do not necessarily have a known vulnerability at this time.
For this first example, we'll be using Java 8, which has a prebuilt uninstall package included in the Package Library. The Package Library contains uninstall packages for tons of mainstream applications, making rolling back software super easy. We'll also use the version history feature in the Package Library to download and deploy an older, stable version of an application.
1. With PDQ Deploy open, click on Collection Library.
2. In the search box, enter Java 8.
3. Double-click the Uninstall Java 8 package to download it to your console.
4. Once the uninstall package has been downloaded onto your console, right-click it and select Deploy Once.
5. In the deployment windows, click Choose Targets > PDQ Inventory > Collection.
6. Locate the collection you need. For the latest Java 8 collection, expand Collection Library > Runtimes > Java (JRE) > Java 8 > Java 8 32-bit > Java 8 32-bit (Latest), then click OK.
7. Back at the Deploy Once window, click Deploy Now to deploy the uninstall package.
Once the package has been deployed and Java has been uninstalled, we'll return to the Package Library to download an earlier version of Java.
1. In the Package Library window, enter Java into the search field.
2. Click on the Java 8 package.
3. In the Package Details window, scroll down to view the previous releases.
4. Click Download Now next to the version you wish to download.
Once the package is downloaded, you can deploy it to the workstations that need it.
While there are a ton of uninstall packages available in the Package Library, you may come across an application that doesn't have one. If you need to revert software that doesn't have an uninstall package in the Package Library, we can use PDQ Inventory to generate one. Let's demonstrate the process using OpenOffice as our example application.
1. In PDQ Inventory, double-click on a computer that contains the application that you need to remove.
2. Click on the Applications page
3. Right-click on the application you want to build an uninstall package for, then click Create Uninstall Package in PDQ Deploy.
4. PDQ Deploy will open, and the new uninstall package window will appear. Review the package, and click Save. Keep in mind that you'll want to ensure that the silent parameters have been configured correctly in the package.
Once the package has been saved, it's ready to deploy to the computers from which you need to remove the application. Afterward, follow the steps in the previous section to download and deploy an earlier version of the application from the Package Library.
Unfortunately, vendors don't have the best track record of releasing vulnerability- and bug-free updates. While we always recommend proper testing, it won't catch everything. Don't let vulnerabilities ruin your day. PDQ Deploy and Inventory make it easy to roll back software, keeping your environment vulnerability free and leaving you plenty of time to do what you love most, like arguing with strangers on the internet.
If you're not already using PDQ Deploy and Inventory, what's the holdup? You can try it out for yourself and see how much time it saves you with a 14-day free trial. Within minutes, you'll be ready to start managing systems and deploying packages.
Born in the '80s and raised by his NES, Brock quickly fell in love with everything tech. With over 15 years of IT experience, Brock now enjoys the life of luxury as a renowned tech blogger and receiver of many Dundie Awards. In his free time, Brock enjoys adventuring with his wife, kids, and dogs, while dreaming of retirement.