Manage sensitive data in Splunk Observability Cloud

About the Splunk Observability Cloud privacy policy, how to use built-in controls to manage sensitive data, and additional OpenTelemetry tools you can use to manage sensitive data.

Sensitive data may fall within the categories of personally identifiable information (PII), customer-identifiable information (CII), cardholder data (CHD), or protected health information (PHI). Protecting these types of data is necessary to ensure compliance with industry requirements.

This topic describes the Splunk Observability Cloud privacy policy, built-in controls to manage sensitive data, and additional OpenTelemetry tools you can use to manage sensitive data.

About the shared responsibility model

Splunk Observability Cloud adheres to a Privacy Policy that employs a shared responsibility model for handling sensitive data during ingestion. This model divides the responsibilities between Splunk and the customer.

The rationale behind this shared model is that the raw data extracted through instrumentation is highly variable and depends on the architecture, design, and implementation of the customer's system. This variability means there is no single deterministic method to identify all potential sensitive data within the exported observability telemetry data, and customers are responsible for assessing their own environment, security policies, and compliance requirements to identify and handle sensitive data.

The following table provides more details about the shared responsibility model.

Splunk responsibilities Customer responsibilities

  • Splunk implements sanitation for certain well-defined data elements that can be deterministically identified as sensitive.

  • Splunk also provides tools and instructions to sanitize other data that is not covered by the automatic sanitation, as described in the following sections of this topic.

  • Customers are responsible for assessing and identifying any additional sensitive information within the data they receive.

  • Customers must use the tools and documentation provided by Splunk to configure further sanitation as needed.

Manage sensitive data in Splunk Observability Cloud

For more information about how the instrumentation libraries sanitize sensitive data, see Sanitize sensitive data with OpenTelemetry instrumentation. To set up zero-code instrumentation, see [NO TITLE FOUND].

Splunk Observability Cloud provides built-in controls to manage sensitive data. For more information, see:

Manage sensitive data with OpenTelemetry

Splunk Observability Cloud natively supports OpenTelemetry and follows its approach to handling sensitive data. See Handling sensitive data in the OpenTelemetry documentation.

The following sections describe how to manage sensitive data with open-source OpenTelemetry resources.

Sanitize sensitive data with OpenTelemetry instrumentation

The OpenTelemetry community provides semantic conventions that guide how telemetry should be captured so that sensitive values are avoided or redacted. These conventions are followed by language SDKs and individual instrumentation libraries. The following sections describe these semantic conventions with examples of how they are implemented in instrumentation libraries.

URL semantic conventions

Instrumentation libraries that are aware of specific sensitive query parameters such as credentials or user location must scrub those values before capturing the following attributes: url.query, url.path, url.full. For more information, see Semantic conventions for URL in the OpenTelemetry documentation.

.NET instrumentation library examples

  • Instrumentation libraries use a shared utility to perform the redaction logic. See RedactionHelper.cs in the open-telemetry/opentelemetry-dotnet-contrib GitHub directory.

  • In the ASP.NET instrumentation, query parameters are redacted when setting the url.query attribute. See HttpInListener.cs. The redaction is controlled by the OTEL_DOTNET_EXPERIMENTAL_ASPNET_DISABLE_URL_QUERY_REDACTION environment variable.

  • The ASP.NET Core instrumentation is handled similarly but uses its own configuration option, AspNetCoreTraceInstrumentationOptions.cs. The redaction is controlled by the OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_DISABLE_URL_QUERY_REDACTION environment variable.

  • The OWIN instrumentation is handled similarly but uses its own configuration option, OwinInstrumentationOptions.cs. The redaction is controlled by the OTEL_DOTNET_EXPERIMENTAL_OWIN_DISABLE_URL_QUERY_REDACTION environment variable.

  • The HttpClient instrumentation redacts the url.full attribute from outbound HTTP requests using HttpTagHelper.GetUriTagValueFromRequestUri(). See HttpWebRequestActivitySource.netfx.cs.

To learn more, see the open-telemetry/opentelemetry-dotnet-contrib GitHub repository.

Database semantic conventions

The db.statement (or db.query.text) must be sanitized so literal values such as passwords, tokens, and user data are not captured. For more information, see Sanitization of db.query.text in the OpenTelemetry documentation.

Java instrumentation library example

The Java agent automatically sanitizes database statements for common drivers by removing literal values and replacing them with placeholders.

For example, SELECT * FROM users WHERE password = ? is used instead of SELECT * FROM users WHERE password = 'secret123'.

For more information, see DB statement sanitization in the OpenTelemetry documentation.

.NET instrumentation library examples

  • A shared utility implements SQL sanitation, which automatically replaces literal values such as strings, numbers, and hex values with ? placeholders. See SqlProcessor.cs and DatabaseSemanticConventionHelper.cs in the open-telemetry/opentelemetry-dotnet-contrib GitHub repository.

  • Starting from 1.11.0-beta.1, the SqlClient instrumentation sanitizes queries to remove sensitive information from traces by default. The sanitation logic is implemented in SqlClientDiagnosticListener.cs. Note that the SetDbStatementForText option, a previous configuration option to control SQL sanitation, was removed in 1.12.0 beta. As a result, sanitation can no longer be deactivated.

  • The EFCore instrumentation implements the utility in EntityFrameworkDiagnosticListener.cs. The SetDbStatementForText option was removed in 1.13.0-beta.1, and the sanitation is enabled by default.

For more information, see the open-telemetry/opentelemetry-dotnet-contrib GitHub repository and Instrumentation options in the .NET OpenTelemetry documentation.

Sanitize sensitive data with OpenTelemetry Collector processors

You can use the following OpenTelemetry Collector processors to sanitize your data before exporting it to Splunk Observability Cloud.

For detailed guidance on using the Splunk Distribution of OpenTelemetry Collector, see Security guidelines, permissions, and dependencies.

Review the open-source codebases

OpenTelemetry components used to collect and process telemetry data, including the OpenTelemetry Collector and language-specific instrumentation SDKs, are open source. The Splunk distributions of these components, including any customization built on top of upstream OpenTelemetry projects, are publicly available for review.

You can audit and verify exactly how telemetry is collected, sanitized, and exported by reviewing the following codebases. You can also fork and run your own code or security scans to validate compliance with your own internal policies.
Note:

The following table does not include deprecated distributions. This table is provided as a point of reference and may not reflect the full list of available distributions. For the latest information, see [NO TITLE FOUND].

Splunk distribution name GitHub repository
Splunk Distribution of the OpenTelemetry Collector signalfx/splunk-otel-collector
Splunk Distribution of OpenTelemetry Java signalfx/splunk-otel-java
Splunk Distribution of OpenTelemetry JavaScript signalfx/splunk-otel-js
Splunk Distribution of OpenTelemetry .NET signalfx/splunk-otel-dotnet
Splunk Distribution of OpenTelemetry Go signalfx/splunk-otel-go
Splunk Distribution of OpenTelemetry Python signalfx/splunk-otel-python