Trust and assurance

FAQs

How does Tenable protect my data?

Tenable is committed to protecting the confidentiality, integrity and availability of all customer data. Tenable Vulnerability Management data is encrypted in transit and stored using TLS Encryption ciphers. AES-256 Encryption is applied to application infrastructure layers.

The Tenable cloud platform is built on isolated, private networks and uses multiple network controls such as container isolation, inbound/internal traffic restrictions, monitoring of traffic rates, sources and types at multiple network points.

Tenable also implements multiple access controls to help customers control data access and performs frequent vulnerability, docker container and web application scans to conduct periodic security assessments.

For detailed descriptions of the applied security measures, review the Data Security and Privacy data sheet.

Which customer data does Tenable Vulnerability Management manage?

Ultimately, the customer data Tenable Vulnerability Management manages has a single purpose: to deliver an exceptional experience as customers manage assets and vulnerabilities to secure their environments. To that end, Tenable Vulnerability Management manages three categories of customer data:

1. Asset and vulnerability data
2. Environmental performance data
3. Customer usage data

Which customer asset and vulnerability data does Tenable Vulnerability Management manage?

Tenable Vulnerability Management inventories assets on customers’ networks and manages asset attributes that may include IP address, MAC address, NetBIOS name, operating system and version, active ports and more.

Tenable Vulnerability Management collects detailed current and historical vulnerability and configuration data, which may include criticality, exploitability and remediation status and network activity. Additionally, if customers enhance Tenable Vulnerability Management data with integrations to third-party products, such as asset management systems and patch management systems, Tenable Vulnerabilty Management may manage data from those products.

Does Tenable analyze or use customer data?

Tenable anonymizes and analyzes customer data for the purpose of determining trends in the industry, trends in vulnerability growth and mitigation, and trends in security events. For example, correlating the presence of a vulnerability with its exploitation has enormous benefits to Tenable customers. The data collected in our cloud does not include scan data that contains PII or personal data. Data that could potentially identify a customer is anonymized before being ingested into our analytics platform via a one-way salted hash using SHA-256. Additional benefits of Tenable’s data analysis include advanced analytics and improved correlation of customer data with industry and security events and trends. Collecting and analyzing such data also allows customers to baseline themselves against others in the industry or overall. Tenable provides a method for customers to opt out if desired.

Can customers opt out of health and status data collection?

To maintain Tenable Vulnerability Management performance and availability and deliver the best possible user experience, Tenable Vulnerability Management collects customer-specific application status and health information. This includes how often the scanner communicates to the platform, the number of scanned assets and versions of software deployed, as well as other general telemetry to identify and address potential issues as soon as possible.

Tenable uses health and status data to detect and address potential issues in a timely manner, thereby maintaining SLA commitments. Therefore, customers cannot opt out of this data collection.

Which usage data does Tenable Vulnerability Management collect?

To evaluate and improve customer experience, Tenable collects anonymized user usage data. This data includes page access, clicks and other user activity that give the user a voice into streamlining and improving the user experience.

Can users opt out of usage data collection?

Yes. A customer can request their container no longer be part of the collection process.

Where is customer data stored?

Tenable uses data centers and services from Amazon Web Services (AWS) to provide and deliver Tenable Vulnerability Management to customers. Collection and processing of customer scan data occurs inside the Tenable cloud platform within the geographic region where the customer’s account is hosted, unless the customer explicitly selects a different geographic region for the data to reside. Current locations are:

• U.S. East
• U.S West
• U.S Central
• London
• Frankfurt
• Sydney
• Singapore
• Canada
• Japan

Tenable will support additional countries in the future.

As all customer data is stored in secure, regional AWS services. The certifications for EU data protection that AWS maintains apply to the Tenable Cloud. More information is available at https://aws.amazon.com/compliance/eu-data-protection/.

Can a customer force data to remain in a specific location/country?

Yes. Data is stored in the country selected when the account was created.

How is customer data protected within Tenable Vulnerability Management?

Tenable applies multiple security measures to deliver Tenable Vulnerability Management data security and privacy. For a detailed descriptions of the applied security measures, see the Data Security and Privacy data sheet.

How does Tenable perform secure development?

Comprehensive details can be found on the Data Security and Privacy data sheet.

Tenable has a dedicated cross-functional team that drives the Secure Software Development Lifecycle (SSDLC). To ship secure, high quality products at pace, Tenable leverages automated security testing to identify any potential vulnerabilities within source code, dependencies and underlying infrastructure before releasing to our customers. Tenable utilizes static application security testing (SAST), dependency and third-party library scanning, dynamic application security testing (DAST), and vulnerability testing on container images. Strict scoring criteria is adhered to and is enforced throughout the development process.

Which customer application security is available?

Tenable provides a number of mechanisms to help customers keep their data secure and control access, including:

• Data is encrypted in transit and in storage with AES-256 and TLS Encryption ciphers. Encryption keys are stored securely and access is limited. Encryption is applied to various application infrastructure layers and sharing of keys is prohibited.
• Tenable protects against brute-force attacks by locking accounts out after five (5) failed login attempts.
• Customers can configure two-factor authentication through services provided by Twillo.
• Customers can integrate Tenable Vulnerability Management with their SAML deployment. Tenable Vulnerability Management supports both IdP and SP initiated requests. Lastly, users can reset their password directly inside the application using their email address.
• Customers can build custom connections to Tenable Vulnerability Management using our documented APIs or SDKs. Access can be granted and controlled by the creation of specific APIs “keys.” Using different keys for different integrations is supported without having to share user credentials.
• The data collected in our cloud does not include any scan data containing PII or personal data. Data that could potentially identify a customer is anonymized via a one-way salted hash using SHA-256
• To protect from data interceptions, all communication to the platform is encrypted via SSL (TLS-1.2). Further, older insecure SSL negotiations are rejected to ensure the highest level of protection.

How is data encrypted?

All data in all states in the Tenable Vulnerability Management platform is encrypted with at least one level of encryption, using AES-256 and TLS encryption ciphers.

At Rest: Data is stored on encrypted media using at least one level of AES-256 encryption.

Some data classes include a second-level of per-file encryption.

In Transport: Data is encrypted in transport using TLS v1.2 with a 4096-bit key (this includes internal transports).

Tenable Vulnerability Management Sensor Communication: Traffic from sensors to the platform is always initiated by the sensor and is outbound-only over port 443. Traffic is encrypted via SSL communication using TLS 1.2 with a 4096-bit key. This removes the need for firewall changes and allows the customer to control the connections via firewall rules.

• Scanner-to-platform authentication
• The platform generates a random key of 256 bit length for each scanner connected to the container and passes that key to the scanner during the linking process.
• Scanners use this key to authenticate back to the controller when requesting jobs, plugin updates and updates to the scanner binary.
• Scanner-to-platform job communication
• Scanners contact the platform every 30 seconds.
• If there is a job, the platform generates a random key of 128-bits.
• The scanner requests the policy from the platform.
• The controller uses the key to encrypt the policy, which includes the credentials to be used during the scan.

In Backups/Replication: Volume snapshots and data replicas are stored with the same level of encryption as their source, no less than AES-256. All replication is done via the provider. Tenable does not back up any data to physical off-site media or physical systems.

In Indexes: Index data is stored on encrypted media using at least one level of AES-256 encryption.

Scan Credentials: Are stored inside of a policy that is encrypted within the container’s AES-256 global key. When scans are launched, the policy is encrypted with a one-use random 128-bit key and transported using TLS v1.2 with a 4096-bit key.

Key Management: Keys are stored centrally, encrypted with a role-based key, and access is limited. All the encrypted data stored can be rotated to a new key. The Datafile encryption keys are different on each regional site, as are disk-level keys. Sharing of keys is prohibited and key management procedures are reviewed on a yearly basis.

Can customers upload their own keys?

Key management is not customer configurable. Tenable manages keys and key rotation.

Has Tenable achieved any privacy or security certifications, such as Privacy Shield or CSA STAR?

Tenable has received the following certifications:

• Cloud Security Alliance (CSA) STAR
• Privacy Shield Framework
• ISO 27001
• National Information Assurance Program (NIAP)
• FedRAMP authorization for Tenable Vulnerability Management and Tenable Web App Scanning

How does Tenable protect Personally Identifiable Information (PII)?

The Tenable Vulnerability Management platform makes every effort not to collect PII data types in a format that would require additional certifications or security measures. The data collected in our cloud does not include any scan data that contains PII or personal data. Data that could potentially identify a customer is anonymized before being ingested into our analytics platform via a one-way salted hash using SHA-256. This includes credit card numbers, Social Security numbers and other custom checks. Where Tenable plug-ins capture character strings that may contain sensitive or personal information, the platform will automatically obfuscate at least 50% of the characters to protect data that may be sensitive.

Is customer data separated?

Each customer’s data is marked with a “container ID” that corresponds to a specific customer subscription. This container ID assures access to a customer’s data is limited to only that customer.

Which security controls protect Tenable Vulnerability Management?

Tenable leverages its own solutions to conduct daily, weekly or monthly scans of all corporate laptops, infrastructure and cloud environments. All findings are analyzed, ticketed and tracked in accordance with the Tenable Vulnerability Management policy. Tenable’s vulnerability management program encompases authenticed, agent, web application and database scanning. In addition, the following controls are in place:

• Firewalls and network segmentation control access.
• Automated tools and processes monitor the Tenable Vulnerability Management platform for uptime, performance and to detect anomalous behavior.
• Logs are monitored with automation 24/7/365 and Tenable staff are available 24/7/365 to respond to events.
• Third-party penetration tests of our applications, services and businesses as a whole.
• Tenable leverages a vulnerability report board to receive and respond to any weakness or vulnerabilities identified from the broad security researcher community. As identified reports are triaged and responded to, Tenable releases security advisories for the benefit of customers, prospects and the wider community.
• Tenable reviews every third-party vendor through a rigorous risk management program.

How are Tenable Vulnerability Management sensors secured?

The sensors that connect to the platform play a major role in a customer’s security, collecting vulnerability and asset information. Protecting this data and ensuring the communication paths are secure is a core function of Tenable Vulnerability Management. Tenable Vulnerability Management supports several sensors today: Nessus vulnerability scanners, passive scanners and Nessus Agents.

These sensors connect to the Tenable Vulnerability Management platform after cryptographically authenticating and linking to Tenable Vulnerability Management. Once linked, Tenable Vulnerability Management manages all updates (plugins, code, etc.) to ensure the sensors are always up to date.

Traffic from the sensors to the platform is always initiated by the sensor and is outbound-only over port 443. Traffic is encrypted via SSL communication using TLS 1.2 with a 4096-bit key. This removes the need for firewall changes and allows the customer to control the connections via firewall rules.

• Scanner-to-platform authentication
• The platform generates a random key of 256 bit length for each scanner connected to the container and passes that key to the scanner during the linking process.
• Scanners use this key to authenticate back to the controller when requesting jobs, plugin updates and updates to the scanner binary.
• Scanner-to-platform job communication
• Scanners contact the platform every 30 seconds.
• If there is a job, the platform generates a random key of 128-bits.
• The scanner requests the policy from the platform.
• The controller uses the key to encrypt the policy, which includes the credentials to be used during the scan.

How is Tenable Vulnerability Management availability managed?

The Tenable Vulnerability Management services strive to provide a 99.95% or better uptime, and have delivered 100% uptime on the majority of services. Tenable has published an SLA that describes our commitment to ensure the platform is available to all users and how we credit customers in the event of unplanned downtime.

“Up” status is determined simply by public availability tests hosted by a third party that regularly tests the availability of all services. The uptime for services (both current and historical) is available at https://status.tenable.com/.

Tenable Vulnerability Management makes extensive use of the AWS platform and other leading technologies to ensure our customers experience the best possible service and overall quality. Below is a partial list of the solutions deployed and benefits to customers:

• Elasticsearch Clusters: Elasticsearch clusters are highly available and can recover from the loss of master nodes, lb nodes and at least one (1) data node, without impacting service availability.
• Elastic Block Stores: Used to take daily snapshots and store eight (8) copies
• Kafka ecosystem: Kafka and Zookeeper both replicate data across the cluster to provide fault tolerance given catastrophic failure of any node.
• Postgres Instances: Manage the back end microservice framework to keep 30 days of snapshots

Where is data replicated?

Replicated data is stored within the same region.

Which disaster recovery capabilities are in place?

Disasters are events that result in the unrecoverable loss of data or equipment in one or more regions.

Tenable Vulnerability Management disaster recovery procedures have several levels and are designed to react to situations that may occur from anywhere between once in five years to once in 50 years. Depending on the scope of the disaster, the recovery procedures vary in time from 60 minutes to 24 hours.

Who can access customer data?

Customers control who has access to their data, including assigning roles and permissions to their personnel and temporarily granting access from Tenable support staff.

How are user roles and permissions managed?

Tenable Vulnerability Management customer administrators can assign user roles (basic, scan operator, standard, scan manager, administrator and disabled) to manage permissions for major functions in Tenable Vulnerability Management such as access to scans, policies, scanners, agents and asset lists. Customers can also assign access groups to allow groups in their organization to view specific assets and related vulnerabilities in aggregated scan results and to run scans against specific targets and view individual scan results.

Can Tenable staff access customer data?

Yes. Tenable Technical Support restricts the Tenable Vulnerability Management impersonation privilege to a subset of authorized senior roles. With customer permission, authorized senior members of Tenable’s global support staff can impersonate user accounts, which allows them to perform operations in Tenable Vulnerability Management as another user without needing to obtain that user's password.

Tenable support staff, or the customer, can make the request to activate the feature. If Tenable Technical Support needs to impersonate a Tenable Vulnerability Management user, a ticket is opened and tracked until closure. Technical Support will send an email to the customer after identifying the business need to impersonate. The customer is required to confirm via email that Technical Support is approved to impersonate the user. Technical Support will not impersonate the user until approval is received from the customer. Permission must be granted for every issue logged with support. Approvals are tracked within the initial ticket. Tenable will not operate on a blanket “OK” to impersonate at any time.

Tenable has a defined hiring and termination process. All employees are required to sign non-disclosure agreements as a part of their hiring, and all accounts and access keys are immediately revoked upon termination. All Tenable Vulnerability Management operations staff are also required to pass a third-party background check.

Who can use the impersonate function?

Only the account administrator and authorized Tenable senior support staff members are allowed to use the impersonate function. All accounts with the ability to perform impersonations require two-factor authentication for security purposes. Tenable audits impersonations internally and each customer can also audit impersonations performed to their account. All impersonations are logged in audit logs, and all Tenable Vulnerability Management customers can audit impersonations through the API. Tenable documents how to pull the audit logs in the following public document, https://developer.tenable.com/reference#audit-log. Please note that there is an automated account, ([email protected]), that may show at times in these audit logs.

Does the data leave the country when Tenable is troubleshooting a technical issue?

Tenable is making every effort to ensure that customer data is protected and we ensure that their policies are being followed by working with customers to ensure data remains in the region required. However, user impersonation may result in data leaving the primary location. There are instances where cases need to use the Follow-the-Sun process when casework needs to continue beyond local business hours. There are also instances where customers could email a report to Tenable or otherwise break their own policy by emailing outside of their region.

For customers using a FedRamp authorized Tenable product, this data always stays within the U.S.

Will Tenable support staff have access to a customer’s internal network?

No. All traffic is initiated by the scanner and is outbound only. The scanners are installed behind the customer’s firewall and customers can control access of the scanners via their firewall.

What is the Tenable Vulnerability Management Data Retention Policy?

The data retention policy for Tenable Vulnerability Management and other Tenable-hosted products is 12 months of retention for existing customers. For customers that terminate a product subscription, customer data will be retained for 30 days from the termination date. Tenable’s data retention policy with respect to PCI scans matches then-current requirements set forth by the PCI Security Standards Council.

How long is active scan data retained?

The ability to measure progress over time is a core function of the Tenable Vulnerability Management platform. Tenable Vulnerability Management will automatically store customer data for 12 months to allow customers to report over a one (1) year period of time.

If a customer discontinues the Tenable Vulnerability Management service, how long is data retained?

Should a customer's account expire or terminate, Tenable will retain the data, as it was at the time of expiration, for no more than 30 days. After that time, this data may be deleted and cannot be recovered.

How long is PCI-related data retained?

Data involved in a PCI compliance validation process is not deleted until at least three years after the date of the PCI attestation, as required by PCI regulations. Tenable retains this data for this time period, even if the customer chooses to delete their scans or account or terminates their Tenable Vulnerability Management service.

How long is Tenable Vulnerability Management usage data retained?

To ensure the best possible experience, Tenable collects this information as long as a customer container remains active. Once a customer discontinues the service, the data will be retained for no more than 30 days.

Does Tenable Vulnerability Management have Common Criteria certification?

Common Criteria certification is generally not applied to a SaaS solution, as the frequency of updates does not lend itself to a certification process that takes six to nine (6-9) months to complete. Tenable has achieved Common Criteria certification for Tenable Security Center, Nessus Manager, Nessus Agents and Log Correlation Engine (LCE).