As a vital piece of your overall cybersecurity strategy, here are 8 best practices for patch management.
When you receive a message to update the software on your personal computer, updating to the latest version is a simple click of the button and a possible reboot is painless and quick. For network administrators, however, patching software can cause numerous issues and must be carefully scheduled. Patching critical infrastructure can introduce bugs, and rebooting could potentially cause downtime. It’s necessary for network administrators to patch systems, so following some best practices will help alleviate many of the issues experienced when indiscriminately updating software without testing and scheduled deployments.
Why Patch Servers Quickly after a Software Release?
It’s not uncommon for administrators to schedule server and firmware patches several weeks or months after updates are released by software vendors. The issue with this type of patch management is that every day the system is unpatched leaving it open to the latest vulnerabilities. Most patches address zero-day vulnerabilities reported to software developers or found by researchers. The findings are published publicly, and the patch is released on the same day that the vulnerability is listed in the Common Vulnerabilities and Exposures (CVE) database.
After a vulnerability is public, hackers create scripts and exploits against it. In some cases, the vulnerability is published along with sample exploit code for researchers to study and understand. This gives anyone the ability to exploit the vulnerability without requiring any coding time. With exploit code, an attacker can begin finding vulnerable systems and exploiting them immediately. The exploit depends on the vulnerability, but a critical vulnerability could give the attacker remote control of the system or allow an attacker to execute code. Unpatched systems have been responsible for numerous large data breaches, so this wait time is dangerous for the cybersecurity and health of the environment.
The longer an administrator waits to patch a system, the larger the window of availability for attackers. Public-facing systems are especially vulnerable and should be patched immediately. Unfortunately, many administrators must test patches before installing them and schedule a patch when a server can be reboot. In addition, rebooting a server can have its own issues where a smooth process is not always guaranteed. For example, if other systems rely on the rebooted machine, it could cause issues such as corrupted data or downtime for anyone using the system for productivity.
Perform an Audit on the Network Environment
To know what must be patched, you first need to audit the network. Auditing the network tells administrators the number of devices connected to the environment and determines if any systems are currently outdated. It also helps administrators prioritize systems so that they know which servers and network appliances need attention the quickest.
Test Thoroughly
Installing anything on a critical infrastructure component should never be done without testing. This can be expensive but is necessary for enterprise environments. Most large environments have a staging environment that mirrors production. A staging environment is the best way to test, but if no staging system exists then make sure there is a solid rollback plan and procedures to test in a similar environment.
Create a Rollback Plan
What happens if patching fails or creates failure during reboots? Most operating systems have a way to keep a system restore point available should any updates fail. For database servers, a backup of the database should also be available. A rollback plan allows you to restore the system back to its original state and restore it to production so that patches can be retested before attempting the install again.
Use Central Deploying Dashboards
In a large enterprise environment, there could be hundreds of servers patching at any given time. If patching fails for one server, other servers could still be functional with the latest patch. It’s possible to have servers with different installed versions, and administrators must be able to organize and audit systems across the environment.
Centralized dashboards perform patch management by allowing administrators to deploy scheduled updates, monitor currently installed versions, get feedback on the patching process, and display errors. With hundreds of servers scheduled for patch deployment, a centralized dashboard specifically designed for patch management organizes updates and provides information to audit the network.
Monitor Patches and CVE Releases
Either with a third-party solution or manually reviewed, the CVE database should be monitored for any vulnerabilities related to system software. Software developers also publish any related vulnerabilities warning users that they should patch their software. Always stay updated on the latest versions and releases so that they can be quickly tested and a patch deployed.
Plan for Errors
As much as you try to avoid issues, errors occur and will impede progress. In a large environment, at least one server will be unsuccessfully patched. Administrators should plan for these issues with follow-up testing, troubleshooting, and a retry of the patching process again. If errors cause the system to crash, the rollback plan must be executed. In some scenarios, errors can be bypassed, and the patch can be installed anyway. If using a central dashboard, the feedback tells administrators about any failed installations to help them organize the update process.
Use Live Patching Services
Several software vendors offer live patching solutions. Live patching is a specialized service that will update the software in memory while the server remains active, and then no reboot is required after installation completes. Several Linux operating system vendors have this software available for their distributions. Third-party vendors also offer live patching across multiple distributions.
Don’t Forget User Devices
Most patching focuses on critical systems such as servers and network appliances, but user devices can also become a target for hackers. Outdated software on user devices could be vulnerable to sophisticated attacks that give attackers remote control or code execution privileges. When the user connects to the network, the right exploit could give an attacker access to the environment. For example, some ransomware scans network connections to make copies of itself to store on remote storage locations.
Conclusion
Consider Vulnerability Management from Cybriant
An asset is no longer just a laptop or server. It’s now a complex mix of digital computing platforms and assets which represent your modern attack surface, including cloud, containers, web applications, and mobile devices. The time between each scan is all an attacker needs to compromise a network. With continuous scanning, our security experts automatically have visibility to assess where each asset is secure or exposed. By using risk prioritization, our security experts have the skills to understand exposures in context. They will prioritize remediation based on asset criticality, threat context, and vulnerability severity.
Related: Protect Your Business with Cybriant’s IT Security Best Practices Checklist