Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Welcome back to the wondrous world of patch management. Today we’re going to clear the air a bit by deliberating about hotfixes (not hot flashes). So, what is a hotfix? A hotfix can be regarded as a patch, but a patch is not a hotfix – makes a whole lot of sense, doesn’t it? Not to worry; all will be clear faster than you can say “quick-fix engineering update”. Enjoy and don’t forget to subscribe.
What is a Hotfix? Definition and Examples
A hotfix is a software update designed to remediate a very specific operational or security issue. Paging all PC gamers out there – back in 2009, the gaming community lashed out at Gears of War developers due to the game becoming unplayable. Long story short, GOW clocked out on the 28th of January 2009, which meant that customers would have had to MacGyver the PC’s clock to be able to play the game. And because this is the kind of thing that could make a company go out in flames, the developers released a hotfix that solved the issue. That’s just one example and plenty more where that one came from. Let’s get back to the topic at hand.
From a technical standpoint, there’s no difference between an update, patch, or hotfix meaning that, deep down, at the code level, they are, more or less, very similar. Take a moment to consider CUs (i.e., Cumulative Updates) – new and old updates bundled together that help us improve security, gain access to new features, and remove deprecated or vulnerable applications. In CUs, developers are also careful to pack all the hotfixes released to date, ensuring their availability through later iterations. Okay, so far, we’ve established the following facts: hotfixes are updates (but not exactly) meant to address very specific issues (remains to be seen), and they may be bundled together with other types of updates. So, who’s to say that a hotfix is any different than, say, an optional update? Let’s take this a notch higher.
The “hot” part of hotfix means that this improvements-carrying package was designed to deal with a ‘live’ app. Basically, patching it on the move – it’s like being in a hot-air balloon and using a needle and thread to stitch up all the small holes that may appear during your journey. Believe it or not, live app hotfixing is just like that; after finding code flaws that may impact the app’s stability and/or security you quickly push out a hotfix to address the issue and, of course, ensure that the fix will become a part of the next update bout.
If it’s so straightforward, why do we need update bundles and bug fixes? Because they often tend to cause more problems, than actually solve them. For instance, a hotfix for a major security issue may severely impact the application’s performance (i.e., the app becoming sluggish, unresponsive, crash more often, experiencing Read/write issues, etc.). That’s why it’s always a good idea to bench-test these fixes before pushing them to your applications. We’ll talk more about that in the upcoming section dedicated to the hotfix lifecycle (management).
Another thing worth mentioning is that the term “hotfix” was coined by Microsoft. Although it’s their brainchild, it does not have exclusive rights to it, meaning that any developer can push out a hotfix.
Anyway, not that you have an idea about what a hotfix is, let’s see a couple of examples.
- KB5006943. This is an on-demand (please commit this memory) hotfix update package for MS’s SQL Server 2016 SP3 which addresses two issues: an access violation when using the FileTable in SQL Server 2016 and an error message that pops up when performing change tracking cleanup.
- Hotfix Package 4 for Microsoft Application Virtualization 5.0 SP2. This right here is a collection of hotfixes that are meant to solve various Application Virtualization issues (e.g., low detection diagnosis, poor performance, incompatibilities, deployment-related bugs, shortcutting, and registry-related issues).
- Running the BDD hotfix. This improvements-carrying package for Oracle’s Big Data Discovery (BDD) app allows the user to restore scrips and install the backup when upgrading from v. 1.1.0 to v.1.1.1.
Hotfix Lifecycle Management
Just because hotfixes are meant to mend specific issues, it doesn’t mean that they are excluded from the regular patch management process. Let’s consider the following diagram from SQLShack:
Photo courtesy of SQLShack
Allow me to break it down for you. This hotfix lifecycle management representation is related to an SQL Production Database. At some point in time, someone would find a bug nesting in this database. The next step would be to analyze the bug and develop a functional hotfix than can resolve the issues. Once the hotfix’s up and about, it will be subjected to various stress tests to ensure app integrity and stability. If the hotfix passes the test, it will be applied to the Production. If not, then it’s back to square one, with another round of tweaking and testing. Now, if you’re interested in getting your hands ‘dirty’ with some hotfix testing, do pay a visit to SQLShacks’s official website.
As you can see, when it comes down to management, hotfixes receive the same ‘treatment’ as patches and updates. One more thing to discuss here: can a hotfix be requested by a party other than the developers/QA team? The answer is “yes” and here’s a shocker for you – most of the time, the hotfix requests come from end-users – customers who stumble upon these bugs and call upon the devs to fix the issue as fast as (humanly) possible.
On-demand hotfix development & testing is a different breed, one that plays by its own rules. According to this blog post by Techno Trice, there are 8 steps to testing and releasing a hotfix.
As to the mechanics, on-demand hotfix development, testing, and deployment, it goes something like this. First, the customer will signal the bug. The request is then processed by QA and the Dev team, checking its validity. When that’s done, the Dev team will begin working on the hotfix which they will later ship to the QA Environment for a battery of tests. If the hotfix passes the test, it’s then delivered to the customer who, in turn, deploys it in a test environment of his own. Should everything check out okay, the hotfix will be deployed (Production) and the QA + Dev ticket closed. However, if the customer turns down the hotfix for whatever reason, the process starts all over.
Hotfix Deployment Tips, Tricks, Hacks, and More
This about wraps up my article on what is a hotfix. Hope you’ve enjoyed my writing and, as always, I’m going to leave you with a couple of nifty tips and tricks on how to handle your hotfixes.
- Automatic hotfix deployment. The best way to ensure that all your apps receive the much-needed hotfixes or updates or patches is by using an automatic patching solution. Heimdal™ Security’s Patch & Asset Management can help you quickly deploy hotfixes on all your machines, regardless if you’re running Windows or Linux.
- Backups or restore points. Don’t forget to back up your soon-to-be-hotfixed apps; or create a restore point. You really don’t want to lose your data if something goes haywire.
- To hotfix or not to hotfix. That is indeed THE question; keep in mind that some issues require hotfixing (e.g., critical security-related bugs) and some do not. Make a habit out of balancing your gains against your losses; the hotfix could mend an issue, but create another.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
