Netskope One DSPM 10.2 Release Notes

Major New Features

Discover Unmanaged Data Stores in AWS Volumes

Netskope One DSPM now performs daily scans of AWS Elastic File System (EFS) and AWS Elastic Block Storage (EBS) volumes to identify and display unmanaged data stores, such as MySQL, PostgreSQL, MariaDB, Oracle and SQL Server, within these volumes.

By identifying hidden shadow databases within these volumes, this capability enhances visibility into your data estate, strengthening security and compliance. With proactive discovery and risk detection, you can optimize costs, prevent data breaches, and mitigate shadow data risks. Ensure regulatory compliance and safeguard sensitive data across your entire infrastructure with continuous monitoring and protection.

Discovery and Classification for GCP Persistent Disks

Netskope DSPM now automatically discovers GCP Persistent Disks across connected Google Cloud projects and organizations, providing seamless visibility into your cloud data landscape. In addition, you can connect these Persistent Disks for advanced data classification, allowing for deeper insights into data types and usage patterns.

This enables you to identify and classify sensitive data, ensuring compliance with regulatory requirements and internal policies. With continuous discovery and classification, you can reduce security risks, optimize cloud costs, and enhance data governance across your Google Cloud environment.

Discover Unmanaged Data Stores in GCP Persistent Disks

Netskope DSPM now performs daily scans of GCP Persistent Disks to identify and display unmanaged data stores, such as MySQL, PostgreSQL, MariaDB, Oracle and SQL Server, within these volumes.

Improvements and Updates

Improvements for Unstructured Policies and New Signals for Policy Conditions

The Netskope One DSPM policy engine has been upgraded to provide better support for executing policies against unstructured data stores of all services. In addition, new signals have been added, allowing you to construct a wider variety of data store-specific policies.

More specifically:

The existing Misconfiguration type policy has been transformed into a new policy type called Data Store Posture. Any policies built using this new type will evaluate data that resides at, or rolls up to, the data store level.
The Data Store Posture policy will evaluate against both structured and unstructured data equally.
In addition to the existing signals (Misconfiguration Risk, Encryption, Backup, and Publicly Inaccessible), the following new signals are available for use in Data Store Posture policy conditions:
- Data Tags: Any Data Tags that are applied at the data store level.
- Contained Data Tags: Any Data Tags applied at levels below the data store, including database, schema, table, field and file.
- Contained Data Types: All sensitive data types found within the data store.
- Platform: The parent CSP that powers the data store, such as AWS, GCP, etc.
- Service: The engine behind the data store, such as Redshift, S3, PostgreSQL, etc.
- Field / File Count: The total object count for structured (fields)/unstructured (files), which can be used as criteria to limit policies from firing too frequently.
- Sensitive Field / File Count: Similar to the above, but only for the objects that have been classified (like deemed sensitive).

Examples of new policies you can build using these new signals include:

Tagging within the cloud service provider may be the authoritative answer of which data stores are considered production vs. non-production. Use ingested infrastructure tags in your policies to notify when PII is found unexpectedly within data stores not tagged as production within the CSP.
Using the newly-available Service signal, you can now trigger data hygiene workflows when data stores of a certain type (like Redshift) are missing specific data tags like HIPAA, etc.

Due to the above changes:

Any existing policies using Misconfiguration as their policy type will be automatically-switched to use the Data Store Posture policy type. They will continue to work as currently configured and only require editing to take advantage of the new signals.
The portion of the Alerts UI that displayed the before/after for misconfiguration-only values will be deprecated.

Service Principal Support for Databricks Connections

In addition to using Databricks user accounts, Netskope One DSPM now supports the use of Databricks service principals for connecting your Databricks data stores to the DSPM application.

Service principals are often used to provide API-only access to your automated tools, jobs, and applications, without the need to associate them to individual persons. This new flexibility in the connection method can be used for both standard Databricks and Azure Databricks connections.

Netskope One DSPM 10.2 Release Notes