[blog] Add Security For Legacy Environments Blog Post

[luke6Lh43]

• I have read and followed the Contributing docs, especially the "First-time contributing?" section.
• This PR has content that I did not fully write myself.
  • I used AI and I have read and followed the Generative AI Contribution Policy.
• I have the experience and knowledge necessary to understand, review, and validate all content in this PR.¹

---

Description

This PR adds a new blog post: Security in OpenTelemetry for Legacy Traditional Environments.

The article provides high-level guidance for securing OpenTelemetry deployments in traditional and manufacturing environments, where legacy systems, older operating systems, and limited network segmentation create unique security challenges.

Content overview

The blog post covers the following topics, mapped to OpenTelemetry's core security concepts and documentation:

• Understanding security risks specific to legacy and manufacturing environments
• Monitoring CVEs and incident response readiness for OpenTelemetry components
• Securing the OpenTelemetry Collector, including:
  • Secure configuration storage
  • Enabling TLS encryption and authentication
  • Minimizing attack surface
  • Applying the principle of least privilege
• Handling sensitive data through data minimization and Collector processors (attribute, transform, and redaction processors), with practical YAML examples
• Protecting against denial of service and resource exhaustion, with configuration examples for endpoint binding, queue sizing, compression, and filtering
• Compliance and ongoing governance considerations

Related references

• OpenTelemetry Security Documentation
• Collector Configuration Best Practices
• Collector Hosting Best Practices
• Handling Sensitive Data
• Community Incident Response Guidelines
• OpenTelemetry CVE List

Closes #9724

Footnotes

1. Yes, I can answer maintainer questions about the content of this PR, without using AI. ↩

[tiffany76]

Looking good! I especially like the flow chart.

Could you update all the bulleted lists so the first word starts with a capital letter?

I'm traveling this week, so we'll aim to publish the week after.

Thanks, @luke6Lh43!

[tiffany76]

@open-telemetry/sig-security-approvers, we now have a draft of the blog. Could one of you review? Thanks.

[reyang]

How do we verify this statement? I see the opposite frequently - legacy systems run on a long list of legacy protocols and deeply nested networks.

[luke6Lh43]

Good point! Legacy environments vary widely. Some have flat networks while others have deeply nested, protocol-specific segmentation. Updated the section to acknowledge both scenarios and focus on the core risk: that introducing telemetry collection requires careful consideration of network architecture regardless of topology.

[reyang]

How to interpret this?

[luke6Lh43]

Sure, please see below what I meant for each bullet:

"avoid capturing full payloads" — e.g. don't capture entire HTTP request/response bodies or full MQTT message payloads in span attributes when only the metadata (method, status, topic) is needed for observability
"prefer aggregated signals over raw data" — e.g. use metrics (counters, histograms) to track request rates or error rates rather than recording every individual event as a span or log entry
"review collected attributes regularly" — periodically audit which span/log/metric attributes are being captured to ensure no sensitive or unnecessary data has crept in over time

Happy to add brief clarifying examples inline if that would help readability. Let me know if you'd prefer that or if this explanation is sufficient context.

[reyang]

For "review collected attributes regularly", I guess this assumes that by default new/unknown data will be collected and sent?

A different way to do this is to enforce policy and schema. Related to open-telemetry/opentelemetry-specification#4738 and the Weaver project.

@lquerel FYI.

[reyang]

Does this document suggest that the collector should be part of the industrial system, or it should be modeled as a bridge which can be immediately patched when there are supply chain security issues?

I feel it is important to clarify two scenarios:

1. I have a legacy system, I need to collect and send telemetry to another system - I use Collector as a bridge and the system is designed with the assumption that the Collector can be patched frequently.
2. I have a legacy system, I need to collect and send telemetry to another system - I throw the collector into my legacy system with the assumption that I'll be running outdated version of collector(s) for most of the time.

[luke6Lh43]

I love this idea! I'll rework this section to clearly differentiate between the two deployment models and their implications for patching and security posture.

[luke6Lh43]

Thanks for the thorough review, @reyang! I've pushed a new commit addressing all the feedback. Let me know if anything needs further revision.

[reyang]

LGTM based on the following understanding:

1. This document is trying to raise the awareness of telemetry collection security. It helps the reader understand the balance between observability and security. It has provided some principles and a thinking process that can be applied while trying to find a good balance.
2. This document is NOT suggesting the best practice (which is aligned with the document title).

Since the goal/scope changed, I'll take another look at the latest PR.

[tiffany76]

@luke6Lh43 I think you might have missed my earlier comment. Please change all bullet points to sentence case (so they begin with a capital letter). Thanks!

[luke6Lh43]

@luke6Lh43 I think you might have missed my earlier comment. Please change all bullet points to sentence case (so they begin with a capital letter). Thanks!

you're right @tiffany76 , I missed your previous comment :) it is now updated!

[reyang]

LGTM. Thanks @luke6Lh43!

[tiffany76]

LGTM! I've scheduled publication for Tuesday, May 19. Thanks, @luke6Lh43!