Updated functionality - OpenSSL local detections and...
Updated functionality - OpenSSL local detections and vulnerability plugins Background Most instances of OpenSSL are not compiled from source - rather, they are installed as part of another package or library. In such cases, it is not the responsibility of the OpenSSL Project to provide updates and/or patches directly to the end user for these installs. Rather, it is the responsibility of the vendor in question. Take for example Tenable Nessus as an application. It is Tenable’s responsibility to decide if a given vulnerability applies to its implementation of OpenSSL and to provide patches and a Security Advisory, such as TNS-2023-27, if needed. Changes 1.) Plugin 168007, "OpenSSL Installed (Linux)", will have the ability to correlate an OpenSSL package to the file or library that installed it, giving users more control over whether or not generic OpenSSL vulnerability plugins (i.e. those found in the "Web Servers" family, listed here) should fire against those installs, or if the scan should solely rely on the vendor’s specific advisory for the OpenSSL packaged with their software. Such detections will now be marked as “managed” software. 2.) Plugin 168149, "OpenSSL Installed (Windows)", will now enumerate OpenSSL installs as “managed” software. 3.) The changes outlined in the Research Release Highlight, here, will be reverted, allowing our generic OpenSSL vulnerability checks to ingest data obtained via the aforementioned local detections. Impact Users will now see the OpenSSL binary and path, its version, and its associated package (when possible) in the output of plugin 168007. There are no aesthetic changes to the output of plugin 168149, which also includes the detected version and path. The generic OpenSSL vulnerability checks found in the "Web Servers" plugin family will only fire against these locally-detected installs when a scan is launched with increased paranoia and/or the detected OpenSSL package(s) are not managed by the OS, or third party software. This will result in even more accurate findings with fewer false positives from these plugins. We expect the vast majority of OpenSSL detections to be categorized as “managed”. As a result, if you want to see all potential OpenSSL vulnerabilities in your scan result, we recommend running a separate scan with the relevant OpenSSL plugins enabled, in paranoid mode. This can be configured in the Assessment Scan Settings of your scan policy. Documentation linked below; Tenable Nessus Tenable Security Center Tenable Vulnerability Management Please note, the paranoia settings will not affect the initial detections via plugins 168007 and 168149. These will always function the same, regardless of paranoia settings. Users should always be aware of the potential impact paranoia may have on the remediations, if not all scans are run in paranoid mode. Impacted Plugins 168007 ‘OpenSSL Installed (Linux)’ 168149 ‘OpenSSL Installed (Windows)’ Downstream impact on generic OpenSSL vulnerability plugins Target Release Date January 8th, 2024
Tenable Coverage for Ripple20 Vulnerabilities - Treck TCP/IP
Tenable Coverage for Ripple20 Vulnerabilities - Treck TCP/IP Stack Detection The Treck stack has been around for over 20 years and integrated into hundreds of products in many different ways. It is at the heart of the Ripple20 vulnerabilities. The stack has been modified based on each vendor / product's needs. Some products further have been acquired by other companies, End Of Life (EOL), End Of Support (EOS), etc. thereby adding to the complexity of the situation. Tenable has adopted multiple approaches to detecting the Treck stack in a vendor agnostic way while trying our best to ensure the plugins are not destructive to the assets being scanned. Using multiple approaches helps enhance coverage of the diverse Treck stacks out there. However, depending on the changes the vendors have made to the Treck stack or the way it has been integrated into their products, it may not be possible to detect all instances of the Treck stack remotely in a non-destructive way. As vendors are releasing patches for the Ripple20 vulnerabilities in their products, we are looking into adding additional coverage on a product. For the time being, using the recast functionality on vulnerability check for plugin ID 137702 Treck TCP/IP stack multiple vulnerabilities. (Ripple20) can help teams to acknowledge and accept the risk on the report. Vulnerability Recast Tenable.io - https://docs.tenable.com/tenableio/vulnerabilitymanagement/Content/Settings/AboutRecastRules.htm Tenable.sc - https://docs.tenable.com/tenablesc/Content/RecastRiskRules.htm Detection Plugins 138614 Treck/Kasago Network Stack Detection 138615 Treck/Kasago Network Stack Detection With IP Option. 137703 Treck/Kasago Network Stack Detection Vulnerability Detection Plugins 137702 Treck TCP/IP stack multiple vulnerabilities. (Ripple20)Tenable.io API Rate Limit Enforcement Notice To ensure a...
Tenable.io API Rate Limit Enforcement Notice To ensure a great experience for all our customers, Tenable will introduce request rate limits to all our REST API endpoints that communicate with the Tenable.io platform. These changes will ensure over extensive API calls from one customer won't have any impact on the overall experience of others. Tenable.io will calculate the number of API calls it accepts from a single user per minute based on current processing load. Individual users are identified by the API key used in each request. If you send a request after the processing limit is reached, Tenable.io returns an HTTP response message with a 429 (Too Many Requests) code and a Retry-After header element that specifies the number of seconds to wait before retrying. The new limits will go in the effect on Wednesday, November 14th, 2018. We strongly encourage customers who use the REST API to modify their code to be able to handle these new sets of restrictions gracefully. Customers using the tenbale.io SDK or PyTenable don’t need to take further actions. Customers not using either library need to handle rate limits in their code. In python, for example, this can be done as follows: import requests from requests.packages.urllib3.util.retry import Retry retries = Retry( total=3, status_forcelist=[429, 501, 502, 503, 504], backoff_factor=1, respect_retry_after_header=True ) adapter = requests.adapters.HTTPAdapter(max_retries=retries) session = requests.Session() session.mount('https://', adapter) Please refer to our documentation for more details at https://cloud.tenable.com/api#/ratelimiting For more information, please contact support@tenable.com or log a Case.Tenable.io will undergo infrastructure upgrades to improve...
Tenable.io will undergo infrastructure upgrades to improve site performance and reliability throughout September. This planned maintenance window is scheduled to take no more than 4 hours to perform. If you have questions regarding the specific timing of the maintenance period, that affects you and you have not already received an email, please email your Customer Success Manager or create a Case with Tenable Customer Support or email support@tenable.com. This maintenance window only affects Tenable.io cloud and SecurityCenter customers who use Tenable.io to perform scans. During this time: Your Tenable.io URL will redirect you to a maintenance page, and you will not be able to access your Tenable.io account at https://cloud.tenable.com/. The Tenable.io API will be unavailable during this time. We expect most scans that are already running when the maintenance window begins to complete successfully after the window closes. We recommend that you verify this. Scans scheduled to start during the maintenance window are not likely to be initiated. Please check if they have run and if not, consider either scanning manually or at your next scheduled time. Agents will not be able to check into the Tenable.io platform during this time. Once services resume, agents will retain their data until the next check in. SecurityCenter management consoles with a Tenable.io scanner in their configuration will begin producing log messages indicating SecurityCenter cannot connect to the scanner. This will not impact SecurityCenter performance or stability, and the log messages will stop once the maintenance window is complete. This maintenance window does not affect Tenable.io on-prem, Nessus Home, Nessus Professional, Nessus Manager deployments or SecurityCenter consoles without a Tenable.io scanner. Please understand that routine maintenance and upgrades are a necessary part of our service delivery to you and we make every effort to perform these at the least disruptive times. We apologize for any inconvenience this planned maintenance outage may cause. We will do our absolute best to perform these upgrades as fast as possible and with minimal impact.