Tenable and Application Patch Management

Tenable Vulnerability Management enables organisations to continuously assess the health and security posture of the network, including identification and monitoring of unsupported software. Quick identification of unsupported applications enables risk managers to see risks associated with End of Life (EoL) software. Identifying exposures provides the operations teams direction to implement, act, and prioritise remediation efforts to mitigate cyber risk. Risk managers and operations teams can communicate to the leadership team how upgrading unsupported applications reduces their network risk.

Tenable Vulnerability Management uses active methods to identify EOL products found in the environment by examining the Microsoft registry, common software installation locations, or using applications utilities such as YUM or APT in Linux systems. Risk managers are able to verify the operation team's activities and identify areas for risk mitigation.

The Unsupported Software dashboard for Tenable Vulnerability Management provides the organisation with a clear and simplified method to identify EOL software and enables security managers to predict where risk will increase and develop a mitigation plan.

The Unsupported Product Summary dashboard for Tenable Security Center, shown in the following image, is similar to the Unsupported Software dashboard for Tenable Vulnerability Management and consists of seven components that report on unsupported (end-of-life) products found in the environment. Components include indicators, bar graphs, pie-charts, and tables to display, track, and report on unsupported applications.

The Historic Patch Mitigation Status dashboard for Tenable Security Center monitors vulnerability mitigation on an organisation’s network in order to help security teams understand the effectiveness of their patch management efforts. Increased visibility into vulnerability mitigation can assist security teams in implementing improved patch application procedures as needed.

By monitoring the patterns of patch application and vulnerability mitigation, security teams can better understand the effectiveness of their efforts and make adjustments as necessary in order to effectively secure their network. ISM-1876 and ISM-1901 involve patches being applied within 48 hours and two weeks, respectively.

The components in this dashboard display data about the mitigation dates of detected vulnerabilities. Two filters are leveraged: “Days to Mitigate” and “Days Since Mitigation.” The components depicting patch rates use the “Days to Mitigate” filter to count vulnerabilities that were mitigated within the specified number of days of initial discovery. The count is based on the difference between the “First Discovered” date and the “Mitigated On” date. The components that depict patch dates use the “Days Since Mitigation” filter to count vulnerabilities that were mitigated within the specified timeframe. The count is based on the number of days between the current date and the “Mitigated On” date. Together, the components in this dashboard can assist security teams with understanding the effectiveness of their patch application and vulnerability remediation efforts.

The manual vulnerability search process works like this. Specific vulnerability data can be found by searching the vulnerability text for keywords, plugin family, severity, or OS CPE strings. For example, perhaps an update was performed on all of the organisation's Ubuntu devices to version 21.04. You want to know if any unsupported devices remain in the inventory. From the Findings tab in Tenable Vulnerability Management (or the Analysis tab in Tenable Security Center), and using a filter based on PluginID = 33850, Unsupported Unix Operating Systems, the number of results returned in this example is 78.

A quick review of the details of these assets reveals several different Unix-based Operating systems. Say for instance, we want to focus solely on Ubuntu, by adding a Plugin Output filter of “Ubuntu” we reduce the number of assets seen in this example to seven. The user should have ‘Plugin Output Search’ Enabled from within the Settings in Tenable Vulnerability Management.

Another quick review of the details of these assets reveals several different Ubuntu OS versions. However, some of the versions, while unsupported, are still covered by extended security maintenance. As of the time of this writing, Ubuntu version 16.04 support ended on 2021-04-30 (end of maintenance), but had extended security maintenance releases available until 2026-04-30. So if we want to focus on patching more vulnerable versions of Ubuntu, by changing the Plugin Output filter to “Ubuntu 17” we are returned with one asset.

Looking at the details of this asset we can verify no support for this version has been available since 2018, effectively rendering this asset unpatched for the last five years. In a matter of minutes, using this type of search methodology we have reduced the immediate patching requirement in this example from 78 assets to just a single asset. While the others are also a priority, this one single asset has floated to the top, and can be dealt with immediately, while a plan is developed to patch the remaining assets.

Using these queries can help an organisation confirm ISM controls similar to ISM-1690, ISM-1901, ISM-1694, ISM-1697, ISM-1902, ISM-1904. These controls involve scanning for updates and ensuring now exploitable or vulnerable assets are present.

Tenable also publishes Security End of Life (SEoL) plugins to detect and assess products in the SEoL state. SEoL is the state in the Security Maintenance Life Cycle when a product no longer receives security updates. The plugins attempt to abstract various terminologies such as End of Life, Unsupported, End of Support, etc. and provide a clear definition that serves as the basis for SEoL detection plugins. There is a difference between plugins with "Unsupported" in the name and those that are SEoL. SEoL plugins are the evolution of the legacy "Unsupported" plugins. Over time, all legacy "Unsupported" plugins will be converted to the SEoL detection plugins or enter the deprecation cycle.

For more information on the SEoL plugins, reference this knowledge document.

Common Platform Enumeration (CPE) strings are also acquired when scanning an asset. The user is able to use these CPE strings to further refine their query to, for example, just focus on assets with application CPEs. CPE strings have the following format:

cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

Within the ‘<part>’ portion of the string will be the target’s type. There are three possible types; ‘/a’ for Applications, ‘/h’ for Hardware, and ‘/o’ for Operating Systems. In relation to these essential strategies we will focus only on /a or /o. The user can further focus the query by using a query similar to `*cpe:/a:microsoft:`.

The user can refine their search of vulnerabilities by searching for only findings that have application CPE strings. The example query can be replicating by selecting ‘Advanced’ and typing “CPE is equal to cpe:/a:* AND Severity is equal to Critical." This query will return findings which have a critical severity value and have an application CPE string. The string can be confirmed by drilling into one of the findings.

When drilling into the findings and selecting See All Details the user is sent to the Finding Details page. The Affect Asset is displayed and the user can scroll through and see the CPE strings within the Installed Software section.

Using the CPE filter can further assist the user in searching for assets that have blacklisted software. This method will be further explained in the Application Controls section of this Cyber Exposure Study.

Note: An important note to take into consideration when using the CPE filter is that a plugin can have both a cpe:/a and a cpe:/o assigned to them.