I recently wrote an article (June 19, 2024) detailing the importance of patch management related to cyber insurance premiums. Lo and behold, this thought of automated patch management related to updating risks to our systems was brought into question by a global outage, which was the result of a pseudo patch. So, the question becomes, do we change our outlook on automated patch management in light of the CrowdStrike outage?
The “Yes” side. If we control the installation of all patches on our systems, we will be able to control the expected outcome related to the service impact of the patch. This is true. However, the time it will take to review all patches that need to be installed could take days or even weeks. The time that this will take could take us to the next patch cycle, and the next cycle, etc. Therefore, we are constantly behind the 8-ball, attempting to stay ahead.
The “No” side. Staying the course with automated patch management allows us to stay ahead of the threats that may exist to our systems. The caveat with this approach is and always will be that we don’t know the impact of the patch until service restart and/or system reboot. We can test and test, but until the patch is installed in the production environment, we do not know the full impact.
With all the vendors we do not know the extent of a good Software Development Life Cycle (SDLC). All organizations have Commercial Off the Shelf (CoTS) products and applications that exist in our environments. When we purchase these products, we agree, quite often blindly, to the vendor/manufacturers End User License Agreement (EULA). This could give, and we saw this firsthand, the vendor the right to update/upgrade the software in your environment without warning or any notification.
So what do we do…the right approach is a blend of both automated and manual patch management. I will address the CoTS software later. Our patch management solutions need to have the ability to approve patches to systems and automate the deployment. When we have completed a full analysis of all the systems in our environment, and we know the criticality to our business of each system, we can be better informed as to the automation vs. manual process needed. With that said, it is important to know this process should only apply to server and hardware infrastructure; end-user systems should always take patches when they are available. Now I solely mean automation from an operating system perspective.
Now we address 3rd-party applications that reside on our systems. For how many years did we allow Norton, Kaspersky, McAfee, etc., to update, and never an issue? Enter CrowdStrike. I must state, being one who has worked with this solution and been involved with most all of the xDR solutions within the market, this was a fluke. So, what we can learn from it just as we learned from other incidents and disasters that have affected us directly or indirectly for years? First, know your EULA from the vendor or manufacturer. What can they do to your systems and the application which exists and should be maintained by the vendor? Second, effectively manage our systems with software management. This approach allows us to have some say into the 3rd-party patch management schedule.
Information Security is ever-evolving with people, process, and technology changes. As IT staff, we are often encumbered by the need to stay ahead. Are we provided with the right training? Do we have all the right bells and whistles needed? Have we tuned the ‘nerd knobs’ the right way? We have to start with the basics. Patch is always necessary, but the approach can depend on your business and the vertical in which your business resides. Don’t lose sight of the principle that even in a 24 by 7 shop, change windows are still required. If the system needs to stay online, look for redundancy. Know your environment and know your applications.
