Tenable One Cloud Exposure 2024 Completed Changes

What’s Changing?

Policy Name Changes

The policy name for Vulnerabilities-related policies is changing, as follows.

Motivation and Value

Grant users control over how vulnerability findings are created, by allowing you to configure the minimum severity when findings are created.

Backward Compatibility

N/A

What’s Changing?

GraphQL API Changes

The following changes related to Custom Properties are being made in the GraphQL API:

Deprecated Fields

New Fields

New Sample Query and Response

The following example query shows the new PrincipalCustomPropertyValue field being used in the Findings query.

query  {
  Findings(filter:{}) {
    nodes {
      Resources {
        CustomProperties {
          Name
          Values {
            ... on PrincipalCustomPropertyValue {
              Principal {
                Name,
                Mail
              }
            }
          }
        }
      }
    }
  }
}

{
  "data": {
    "Findings": {
      "nodes": [
        {
          "Resources": [
            {
              "CustomProperties": [
                {
                  "Name": "Environment",
                  "Values": [
                    {}
                  ]
                },
                {
                  "Name": "Owner",
                  "Values": [
                    {
                      "Principal": {
                        "Name": "John Doe",
                        "Mail": "[email protected]"
                      }
                    },
                    {
                      "Principal": {
                        "Name": "Jane Doe",
                        "Mail": "[email protected]"
                      }
                    }
                  ]
                }
              ]
            }
          ]
        },
        {

SIEM Integrations Changes

The following SIEM integration property related to Custom Properties has been added:

Motivation and Value

Ensure consistency and alignment across Cloud Exposure properties.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API to send data to business intelligence tools, your workflow may be affected by the following changes.

What’s Changing?

The following GraphQL API and SIEM integration inventory field will deleted:

{

  AzureAuthorizationRoleAssignmentResources {


    edges {
      node {
        Name
        Pim

        PrincipalReference {
          Principal {
            Name
          }
        }
      }
    }
  }
  }

Motivation and Value

Query this value in a more detailed way via the Azure Role Assignment Page or via the API per specific Role Assignment.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API or use SIEM integrations to send data to business intelligence tools, your workflow may be affected by these following changes.

• GraphQL API:
  Request (query): The old field, AssignedPrincipals will be deprecated in one month. After this time, you will need to ensure that you delete the relevant queries.
• SIEM integrations:
  Make sure to configure your SIEM tool in advance to expect the new type names.

What’s Changing?

The Bindings table will be removed from GCP Role profiles in Role Bindings, and the Assignments table will be removed from Azure Role profiles in Role Assignments.

Motivation and Value

The full capability of Role Binding and Role Assignment for each GCP and Azure Role will be supported on a dedicated page. This page will include advanced features such as identifying unused bindings and locating assignments that are redundant due to being covered by higher-scope assignments.

Backward Compatibility

No action requires

What’s Changing?

Cloud Exposure currently provides visibility into one type of AWS organization policy via the Inventory:

• Service control policies (SCP)

On November 10, 2024, another type of organization policy will also be supported:

• Resource control policies (RCP)

Both policy types will be visible within a new Organization Policies resource (IAM category). As a result, the following GraphQL API and SIEM integration inventory types are changing:

Motivation and Value

Ensure support for visibility into AWS resource control policies (RCP) via the Cloud Exposure Inventory page.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API or use SIEM integrations to send data to business intelligence tools, your workflow may be affected by these following changes.

• GraphQL API:
  • Request (query): The old type, AwsOrganizationsServiceControlPolicy will be deprecated in one month. After this time, you will need to ensure that you change relevant queries to use the new type name - AwsOrganizationsPolicy.
• SIEM integrations:
  • Make sure to configure your SIEM tool in advance to expect the new type names.
  • Best practice — Add configuration for the new types before deleting the old types. After the feature is released and you have verified that data in your workflow is still ingested successfully, you can remove the old/legacy types.

What’s Changing?

The previous CI/CD image repo used by Cloud Exposure is being deprecated. Tenable has already transitioned to use the new image repo, but will continue to support the old repo until the Deprecation Date of November 1, 2024. This means that if you connected your pipeline to Tenable and used the old repo name in the relevant step, scanning will still be supported until this time. See CI/CD Image Repo Deprecated (November 1, 2024) for more information about required action.

This repo is used for the following features:

• IaC CI/CD Scanning
• IaC Trace Issues Back to Code (Cloud to Code)
• Container Image CI/CD Scanning

This change impacts customers using any of the following pipelines:

• Jenkins
• GitLab
• Generic (Docker)

Motivation and Value

To ensure stability and reliability for Cloud Exposure customers, and to use consist naming conventions across the platform.

Backward Compatibility (Requires Action)

If you currently reference the deprecated repo name in your pipeline:
To ensure the uninterrupted continuity of the CI/CD Image Repo Deprecated (November 1, 2024), you need to update the relevant step in your pipeline/s to use the new repo name before November 1, 2024.

• You can copy the relevant step with the new name from the Cloud Exposure Console by editing the relevant pipeline integration via Settings > Integrations > CI/CD, and then use it to replace the step with the old name. For example, here you can see the updated repo name reflected in the step, both for Generic (Docker) and for GitLab.

  

  

• If you appended/altered content within the step, you can simply replace the old repo path with the new one, without copying the entire step from the Console.

What’s Changing?

Cloud Exposure alerts on operating systems that are at or nearing end of life. For Windows OS, this was previously based on the latest date for which extended security updates were available. However, because Microsoft charges extra for extended support, Tenable is updating the logic for Windows machines in AWS and GCP to use the standard end-of-support date.

As a result, you may see new findings opened for the following policies, which were previously evaluated based on the extended support date:

• EC2 instance has an operating system which is at or nearing End-of-Life
• VM instance has an operating system which is at or nearing End-of-Life

For Azure resources running Windows Server, the extended support date will continue to be used, as the cost is included in Azure pricing.

Motivation and Value

Since most customers don't pay for extended support, Tenable considers the standard end-of-support date more relevant.

Backward Compatibility (Requires Action)

N/A

What’s Changing?

The following additional permissions need to be added, depending on your cloud provider. See the documentation for more information.

Motivation and Value

Lay the groundwork for future support of data scanning for data storage resources.

Backward Compatibility (Requires Action)

To ensure the uninterrupted continuity of data scanning across all resource types, add the additional permissions mentioned in Permission Changes for Data Protection (October 13, 2024) as soon as possible before October 13, 2024.

What’s Changing?

As a result of the New Logic for Inactive Identities (August 12, 2024), GraphQL API and SIEM integration properties are also changing. The following sections list the relevant changes for each cloud provider / identity provider.

AWS

Azure

GCP

Google Workspace

Microsoft Entra ID

Motivation and Value

Ensure consistency and alignment across Cloud Exposure finding properties.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API or use SIEM integrations to send data to business intelligence tools, your workflow may be affected by these following changes.

What’s Changing?

How Cloud Exposure handles findings for inactive identities.

Updated IAM Policies

Inactive IAM policies have been updated with new logic, as described in New Logic for Inactive Identities (August 12, 2024). Some of these policies have new names. Deprecated policies which use the old logic will continue to exist in the Console (with an indication that they are deprecated) until a week after the release date, at which point they will be removed.

Updated IAM Dashboard

The IAM Dashboard has been improved and updated. Some of the highlights include:

• Overprivileged Trend — Single trend graph for overprivileged identities (including inactive identities with permissions). Added groups and permission sets.
• Changes By Account — Unifies all data into one widget, with a breakdown by users, service identities, groups, and AWS permission sets.
• 3rd Parties — New widget, showing a summary of roles per vendor. Currently only AWS 3rd party roles are displayed.
• Toxic Combinations — New widget showing toxic combinations (resources with multiple risks that, when combined, are both hard-to-spot and pose a greater threat to your organization) related to IAM.

Motivation and Value

Cloud Exposure’s IAM functionality is focused on providing visibility into cloud permissions risk, and helping remove unneeded permissions. Tenable is now making a clearer separation between issues related to inactive identities (and how they're managed) and the cloud permissions associated with those identities.

IAM risk is a combination of:

• Risk associated with the permissions assigned to identities that operate in the cloud.
• Risk associated with the identities themselves (and the groups they may or may not belong to).

Previously, Tenable addresses these two components in the following way:

• Permissions: Overprivileged findings opened on active identities focus on cloud permissions that can be removed.
• Identities: Inactive findings opened on inactive identities with unneeded permissions, which can also recommend measures such as removing these identities altogether, or removing them from relevant groups.

This can be somewhat confusing, as the teams responsible for managing cloud identities as well as the related processes and KPIs, are often very different and separate from those that relate to managing cloud permissions assigned to those identities.

See New Logic for Inactive Identities (August 12, 2024) for details.

Backward Compatibility (Requires Action)

• If you rely on Trends graphs in the IAM Dashboard for tracking progress related to inactive identities, you will need to adapt your processes to leverage the Overprivileged Trend graph, filtered on inactive identities.
• If you track progress based on the number of findings per type, you will need to adjust your metrics, since findings for inactive identities with unused permissions will now appear under the corresponding overprivileged findings.
• IAM policy configuration:
  • Depending on whether or not you use IdP groups dedicated to cloud permissions, consider whether you want to keep the option for recommending removal of identities from IdP groups (in the configuration for overprivileged policies). See Remove inactive principals from groups.
  • Similarly, consider whether you want alerts on disabled identities. Create findings for disabled identities.

What’s Changing?

The JSON output format generated by the Cloud Exposure container image scanner within CI/CD pipelines.

Tenable recommends reviewing and updating your workflows/integrations to accommodate the new format to avoid any disruptions. See Container Image CI/CD Scanning JSON Output (August 5, 2024) for more information.

See Example JSON Output for an updated example, using the new format.

Motivation and Value

• Align JSON naming conventions with the Workload Protection API.

Backward Compatibility (Requires Action)

This change affects any processes or scripts that consume this JSON output. Immediately after the change occurs, all JSON responses will by default include the Container Image CI/CD Scanning JSON Output (August 5, 2024), meaning that any workflows that leverage these values will stop working. You can still retrieve the previous output for 30 days from the release date by passing the --json-version-legacy parameter via the Tenable Docker image CLI.

Best practice: To avoid disruptions, add the --json-version-legacy parameter to your existing workflow. After the feature is released, and you have verified that your workflow is aligned with the new field names, you can remove the old/legacy field names.

What’s Changing?

The following additional permissions need to be added, depending on your cloud provider. See the documentation for more information.

Impact and Value

• Tenable now encrypts KMS secrets, as per best practices.
• If you are using Marketplace images (AMI), Tenable highly recommends that you add the license-manager:ListReceivedLicenses permission. This allows Tenable to see which licenses are associated with the dedicated scanning account, in order to scan any licensed images.

Backward Compatibility (Requires Action)

To ensure the uninterrupted continuity of onsite scanning, Tenable highly recommends adding the Permission Changes for Onsite Workload Scanning (August 5, 2024) before August 4, 2024.

What’s Changing?

The following GraphQL API and SIEM integration finding properties are changing:

Motivation and Value

Ensure consistency and alignment across Cloud Exposure finding properties.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API or use SIEM integrations to send data to business intelligence tools, your workflow may be affected by these following changes.

What’s Changing?

The following GraphQL API property is changing:

query {
  VirtualMachines {
    edges {
      node {
        Name
        Id
        Software {
          Name
          Version
          Paths
        }
      }
    }
  }
}

Motivation and Value

Support querying for multiple paths for a given software package.

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API to send data to business intelligence tools, your workflow may be affected by these changes:

• Request (query) / Response (JSON): The old field, path will be deprecated on July 21, 2024. After this time, you will need to ensure that you change relevant queries to use the new field name - paths.

What’s Changing?

Significant changes to how security Findings are managed in Cloud Exposure.
These changes affect the finding lifecycle in the system, and make it much easier to understand the flow and progress of issues detected in your environment as they are opened and closed (Learn more about the Finding Lifecycle (July 7, 2024)).

Updated Statuses and Sub-Statuses

This table shows a mapping of the new sub-statuses to their parent status. Descriptions of each sub-status will be available in the documentation after the feature is released.

¹ Ignored findings:

• Findings will now be opened on excluded resources as well, unlike today where such findings are closed. These findings will be assigned a status of Ignored. This change ensures continued visibility into all excluded resources, in one centralized location, preventing potential blind spots.

² Closed findings:

• Resources recommended for deletion will be assigned the sub-status Fixed rather than Resource deleted. For example, an Unused Security Group which is recommended to be deleted. This change provides visibility into the actual work that has been done.

Impact and Value

• Increased visibility into your cloud security posture, by allowing you to better track the work you do and the progress you make resolving and closing findings.
• Clearly understand why findings were open/resolved, and see a clear breakdown of findings based on these reasons.
• Learn about finding trends that help you answer questions such as, "How many findings have been reopened in the last month?"

Backward Compatibility (Requires Action)

If you use the Cloud Exposure GraphQL API or use SIEM integrations to send data to business intelligence tools, your workflow may be affected by the following changes.

• GraphQL API:

  • Request (query): Filtering findings by status via the Statuses filter using the old values of Snoozed or Resolved will be deprecated. After the change occurs, the old values will continue to be supported for a period of one month, after which you will need to ensure that you change relevant queries to use the new values.
    • Old value: Snoozed. New value: Ignored
    • Old value: Resolved. New value: Closed

  

  • Response (payload): Immediately after the change occurs, all API responses will include the new status values, meaning that any workflows that leverage these values will stop working. Best practice: Add configuration for the new value/s before deleting the old value/s. After the feature is released and you have verified that data in your workflow is still ingested successfully, you can remove the old/legacy value.

• SIEM integrations:
  Make sure to configure your SIEM tool in advance to expect the following new payload values:

  • Old value: Snoozed. New value: Ignored
  • Old value: Resolved. New value: Closed

  Immediately after the change occurs, all payloads will include the new status values, meaning that any workflows that leverage these values will stop working. Best practice: Add configuration for the new value/s before deleting the old value/s. After the feature is released and you have verified that data in your workflow is still ingested successfully, you can remove the old/legacy value.