Tenable architecture

The solution is based on a cloud-hosted platform that connects via API to the major public cloud service providers. To form a complete picture of your cloud infrastructure security, Tenable integrates with your identity and cloud providers. also integrates with third-party ticketing, notification, and SIEM tools to provide additional visibility and facilitate remediation.

The following diagram displays the flow of communication between and your integrations.

Platform Components

The platform consists of the following components:

• Service

• Console

• Public API

Service

is a multi-tenant service hosted on AWS. The service integrates with your organization’s IdP and cloud infrastructure environments to continuously collect the configuration metadata of identities, entitlements, resources, network and activity logs. The data collected is processed and stored in unique, proprietary data structures to provide deep visibility into identities’ privileges and activities, allow advanced identity analytics processes, and support remediation of access-related threats and excessive privileges. Tenable Cloud Security generates right-sized IAM configuration recommendations to eliminate any such risks. supports both fully and semi-automated, scalable and continuous risk remediation processes. By integrating with ticketing, notification, and SIEM tools such as Jira, Slack, and Splunk, embeds risk remediation into your organization’s natural workflows.

Console

The Console is the management application that supports:

• Onboarding of your organization’s cloud infrastructure accounts.

• Easy integration with your cloud identity providers and third party workflow products.

• Identifying, monitoring, enforcing, managing, investigating, and remediating risks and threats in your cloud infrastructure environment.

Public API

The public API allows you to work programmatically with the service to onboard your cloud environment, export access permissions, risks and threats, and enrich the platform with more context.

How Your Environment Is Analyzed

To detect and resolve security issues in your environment, performs the following operations:

1. Takes a full snapshot of the environment, including resources, identities, permissions, and connections.        

   • This process requires querying every identity, account, service, and resource in the environment via API.

   • Many of the services don’t support bulk operations, and therefore require that separate API calls are triggered for every resource in the environment.

   • Customer environments can contain anywhere from hundreds, to millions of deployed resources.

   • All cloud service provider (CSP) APIs are subject to quotas and throttling. As a security tool, does its best to optimize API calls so that throttling doesn’t affect customer environments.

   • To make sure customer-generated API calls aren’t affected by throttling, implements mechanisms that control the rate of API calls.

2. Analyzes all resources against all available policies, including those related to misconfigurations and overprivilege.        

   • For example, to determine whether or not an identity is overprivileged, takes into account a wide range of contextual information, such as:

     1. Mechanisms/policies that grant permissions to the identity.

     2. All of the activity performed by the identity in the past.

     3. To determine which resource-based permissions are available, pulls all information about every resource in the environment.

   • The evaluation process is done for every identity, service, resource, and action available in the CSP, including cross-account access.

   • Without analyzing the necessary context, there is no way to determine whether or not an identity is overprivileged.

3. Following the analysis, the platform is able to determine which issues have been created, fixed, partially fixed, or are unchanged, and the Console is updated accordingly to reflect these changes.

How Often is Data Synced and Updated

periodically synchronizes data across your multi-cloud environment, ensuring that all cloud security insights are up-to-date and in-line with the current state of your assets. Depending on the size of your cloud environment, and the amount of analysis required (see How Your Environment Is Analyzed for more information) this process may take anywhere from one to several hours.

Data Retention and Learning Periods

Data Retention

retains data for a select group of data objects, as follows:

• Findings: Indefinitely

• Audit Log: Indefinitely

• Configuration snapshots (IAM resources): Indefinitely

• Activity Log:

  • up to 30 days: CIEM or Standard license

  • up to 90 days: Enterprise license

  See Licensing for more information.

Excessive Permissions

triggers an analysis period (learning period) for the following activities, during which no new findings (related to excessive permissions) are created:

• AWS:

  • When a new human identity is created - 180 days

  • When a new service/machine identity is created - 90 days

• Azure/GCP:

  • When a new identity is created - 90 days

• All cloud providers:

  • When the permissions of an identity are changed - 30 days

    • If the identity is inactive:

      • When the first permission is added, will enforce the 30 day learning period

      • Upon subsequent permission changes, no additional learning periods will be enforced.

    • If the identity is active:

      • For any permission change, will enforce the 30 day learning period, or invoke a new learning period for an additional 30 days

  (Azure) For permission changes, the analysis/learning period is calculated per subscription.

Activity Log and Anomalous Behavior

analyzes up to 12 months of user activity. alerts about anomalous behavior after learning about identities for at least 30 days. After an anomaly finding is opened for a specific behavior, any similar anomalous behavior discovered is handled as follows:

• Within 30 days - the behavior will be added to the existing finding, and the finding will be reopened if it was previously marked as resolved.

• After 30 days - a new finding will be opened.

Tenable IP Addresses to Allow

There are a number of situations where, in order to grant network access, you need to allow IP addresses associated with your region in your firewall. For example:

• If you use on-premises development tools, such as Jira.

• When you connect your Kubernetes clusters to . See Kubernetes Requirements per Cloud for more information.

• If you use VPC Service Controls to restrict access to Google-managed services in the project/organization that you want to onboard. See Add VPC Service Control Exceptions for more information.

• To display Azure container repositories associated with container registries that have restricted network access. In the registry's Networking settings, configure the public network access to allow access from Selected networks, and add the relevant addresses, as described below. Refer to the relevant Microsoft documentation for more information.

In any of the above situations, you need to add all IP addresses associated with the region, as listed in the table below. Where relevant, follow the steps in the linked documentation mentioned above for complete details.

You can identify your region based on the URL you use to log in to the Tenable Cloud Security Console.

Tenable Account IDs to Allow

uses several account IDs to make API requests. Being aware of these IDs ensures that:

• You can validate any incoming API requests coming from these IDs as trustworthy. Such requests are used by Tenable to, for example, assume roles in your account/s to connect to your environment for onboarding purposes.

• If you use Workload Protection, consider excluding these ID from any alerting/blocking mechanisms, since shares snapshots with these accounts for scanning purposes.