Software updates are just a part of normal life. When installing your next set of updates, it will contain multiple security patches, which are needed to help keep the system safe. Applying these patches generally fix bugs in software that can be exploited for harm. Without regularly applied security updates, the risk of suffering damages from harmful programs is much higher.
An organization that does not prioritize applying software updates will create excessive risks to a business. In fact, if the business has to comply with any of the common audits, it is a requirement to keep systems updated, in the interest of protecting customers.
In the most simple form, a (Windows) computer is kept up to date by making sure automatic updates are turned on, which means they are automatically downloaded from Microsoft and applied to a system. However, in an organization, automatic updates are not always the best approach, especially when considering server platforms. Servers that run production applications will require planned updates. Unexpected interruptions from system restarts are not desirable in this type of environment.
Instead of just turning on cruise control, letting systems update and restart themselves whenever updates are released, we use a set of steps that allow for managing vulnerabilities in overall environments.
In order to run a successful vulnerability management program, the first step is to have an accurate inventory of all the computers in the organization. If this step is skipped, the chances of having success at vulnerability management are lessened a great deal. Consider this: If not all the computers in the organization are fully documented it is very easy to miss scanning and patching a system. Just because a system isn’t known about doesn’t automatically make it immune to viruses or malware. Starting off with an accurate inventory of all systems should be the first step in managing vulnerabilities.
The next step in Vulnerability Management is to identify the vulnerabilities as soon as possible after being identified as such. This identification can be performed in a number of ways:
- Scanning systems
- Patchng systems have a built-in scanner to identify software updates are needed before applying. Often these systems provide reporting that reflect the scan results of a system. Centralized reporting with this solution is not always available so reports are usually generalted after targeted on-demand scans are run. It is also not a good practice to have the same system identifiying the vulnerabilities that is used to remediate with. However, in smaller orginaizations – sometimes this is the necessary method to get started.
- Purpose built scanners that have only one job, which is to scan systems, detect the vulnerabilities, and report to a central console.
- Agent based software that runs on each system and inventories/reports all vulnerabilites to a central console . Most dectections are based on ‘signatures’. A common signature used to identify a vulnerability would be the version of an execuatable installed on a system.
Evaluation & Prioritization
Once vulnerabilities are identified, someone has to evaluate all the vulnerabilities identified and make a decision on when to remediate them. One of the most common systems to calculate the severity of a vulnerability is the CVSS system. The assigned CVSS score for a particular vulnerability reflects the potential risk. It is good practice for a security department to set an SLA for patching vulnerabilities in an organization. To tie all this together, an I.T. organization might be expected to patch any vulnerability with a CVSS score of 7 or higher in 30 days. Vulnerabilities with a lesser score might have more time allowed for remediation.
Remediation of a vulnerability usually consists of applying a software update. However, that is not the only way to remediate a vulnerability. Consider this: An application that a company has discontinued using is still installed on a system. A vulnerability is identified and a software update is released to fix it. If the software is known to no longer be used, instead of applying the update a better approach at remediation would be to uninstall the software completely, which would prevent having to apply further updates in the future.
When remediating vulnerabilities by applying software updates, a purpose-built system to scan and apply the updates is typically used. These systems are designed with the ability to deploy many updates at one time to multiple systems. In large-scale environments, this could be as many as tens of updates (or more) to thousands of systems at one time. The system will deploy the updates while displaying a status. Reviewing reports after deployment is necessary to identify any failures.
In certain situations, a software update can’t be applied without breaking the system. Obviously, this puts the system at risk due to the fact the vulnerability can’t be removed. When this happens, the best course of action is to apply some type of mitigating control. For example, say you have a physical server with the Linux operating system installed and a new kernel vulnerability is discovered. However, the server is older and has a proprietary storage controller whose drivers are dependant on a particular version of the kernel. Often times as the hardware ages out, the vendor will no longer support updated drivers to support newer versions of the kernel or operating system. A mitigation tactic would be to use another control, such as a host-based firewall, intrusion prevention system, or other software that can protect against attacks on the kernel. This type of scenario is best addressed with an effective lifecycle management program, which will be discussed in another article.
Validation after updates are applied is necessary to ensure vulnerabilities no longer exist. This validation is best done by going back to the original system used to identify the vulnerability. By relying on a separate system to identify the vulnerability than the system used to apply the updates, it ensures you have proper coverage to safely say the system has been remediated. Oftentimes, a system can have patches deployed to fix a vulnerability only to still exist due to an associated configuration that is additionally required. Often a deployment system is either incapable of doing this part or fails to do so properly.
Vulnerability management is a big topic, however, I have attempted to explain the main parts here to make it a little less overwhelming. As I release more articles that support this topic, I’ll come back and add additional internal links that expand on a subject.
Leave a comment below on things you would like me to cover in the future.