Trust and Assurance Keeping your data secure is our top priority.

Tenable is committed to protecting the confidentiality, integrity and availability of all customer data. Tenable.io 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 datasheet.

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

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

Tenable.io 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.io 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.io data with integrations to third-party products, such as asset management systems and patch management systems, Tenable.io may manage data from those products.

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.

To maintain Tenable.io performance and availability and deliver the best possible user experience, Tenable.io 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.

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.

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

Tenable uses data centers and services from Amazon Web Services (AWS) to provide and deliver Tenable.io 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
• 런던
• Frankfurt
• Sydney
• 싱가포르
• 캐나다
• 일본

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/.

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

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

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

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.

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.io with their SAML deployment. Tenable.io 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.io 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.

All data in all states in the Tenable.io 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.io 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.

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

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.io and Tenable.io WAS

The Tenable.io 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.

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.

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.io 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.

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.io. Tenable.io supports several sensors today: Nessus vulnerability scanners, passive scanners and Nessus Agents.

These sensors connect to the Tenable.io platform after cryptographically authenticating and linking to Tenable.io. Once linked, Tenable.io 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.

The Tenable.io 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.cloud.tenable.com/.

Tenable.io 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

Replicated data is stored within the same region.

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

Tenable.io 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.

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

Tenable.io customer administrators can assign user roles (basic, scan operator, standard, scan manager, administrator and disabled) to manage permissions for major functions in Tenable.io 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.

Yes. Tenable Technical Support restricts the Tenable.io 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.io 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.io 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.io operations staff are also required to pass a third-party background check.

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.io 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.

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.

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.

The data retention policy for Tenable.io 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.

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

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.

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.io service.

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.

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.sc, Nessus Manager, Nessus Agents and Log Correlation Engine (LCE).