Sensitive Data Redaction

Forward Enterprise provides configurable options to redact or mask sensitive information from device configurations during data collection. These controls ensure that sensitive operational details—such as passwords, authentication keys, or SNMP community strings—are securely protected before any configuration data is stored or processed within Forward Enterprise.

Overview

Sensitive data redaction prevents specific information from being collected and stored in snapshots.
Redaction occurs on the collector at collection time, before configuration data is written to disk or uploaded to the Forward Enterprise instance. The Forward Enterprise instance only receives the already-redacted configuration data.

note

Once redacted, the original values cannot be recovered in Forward Enterprise.

Configuration

The redaction options are configured per network under Collection Settings → Advanced → Sensitive data redaction.

Redaction algorithm

You can select one of the following algorithms:

Option	Description	Example Result
None (disabled)	Redaction is turned off. Device configurations are collected as-is, with no masking or hashing.	enable secret 9 $9$ARZqWZRGsp.OuE$VF1epfXv.7
Mask only	The default option. Sensitive fields are replaced with a generic mask (e.g. <redacted>). The configuration structure remains intact.	enable secret 9 <redacted>
MD5 hash (16 digits)	Sensitive values are replaced by an MD5 hash to preserve uniqueness while obscuring the value.	enable secret 9 <redacted:5D965E923B66E538>

Choosing an algorithm

Each option serves different operational and security needs:

• None (disabled)
  Use when full visibility is required — for example, if you rely on Forward Enterprise as a configuration archive or use NQE to index, query, or compare complete device data.
  This option allows all configuration values to remain intact for analysis or backup purposes.

• Mask only
  Use when you want to ensure no trace of authentication or sensitive information appears in collected files.
  This provides maximum data protection but removes the ability to detect or compare changes in those fields.

• MD5 hash (16 digits)
  Use when you want to track or compare changes in sensitive fields without exposing actual values.
  Identical cleartext inputs will always produce the same MD5 hash, allowing Forward Enterprise or external tools to detect when a secret has changed.

note

Some devices and operating systems internally store authentication data as hashes (e.g., SHA256, MD5, or proprietary formats). As a result, even if the same cleartext password is configured on multiple devices, the retrieve encoded forms may be different. When those are re-hashed by the collector, the resulting MD5 hashes may differ — meaning apparent “changes” in sensitive fields may simply reflect different device-side representations.

---

Hierarchical pattern filters

In addition to the built-in vendor-specific redaction rules, you can define your own hierarchical pattern filters to remove specific configuration lines or sections from collection.
These filters are evaluated by the Forward Collector during data collection, allowing you to exclude additional sensitive or irrelevant information before it is stored.

Pattern syntax

Forward Collector supports two types of filters:

• Word globs
• Regular expressions

Both types are case-sensitive by default and not anchored to the beginning or end of a line.

Word globs

Word globs use wildcard characters to match text patterns:

• * — matches any sequence of non-whitespace characters
• ? — matches a single non-whitespace character

A matching line can contain non-matching words before and after the matched portion.

Regular expressions

Regular expressions (regex) can be used for advanced matching:

• Case-sensitive by default; add (?i) at the beginning for case-insensitive matching.
• Not anchored by default; use ^ to anchor to the start of a line, and $ to anchor to the end.

Tree (hierarchical) patterns

Multi-level tree patterns can match hierarchical configuration data (such as indentation-based Cisco syntax or structured Juniper configurations).
Each level is separated by a / in the pattern.

By default, multi-level matching is anchored-inside:

• A match can begin and end at any level in the hierarchy.
• Levels cannot be skipped unless you use ** (wildcard for one or more levels).

Best practices

• Place one expression per line.
• Test filters carefully — filtering out configuration that affects routing or forwarding can alter analysis results.
• Custom filters are applied in addition to built-in vendor/OS redaction patterns.

---

What is considered sensitive data

Forward Collector includes a comprehensive, built-in redaction system with vendor- and OS-specific patterns.
These patterns automatically identify and redact configuration lines that may expose sensitive information, covering a broad range of data types—not just user credentials or management access details.

Sensitive configuration elements include, but are not limited to:

• Authentication and access credentials:
  Passwords, secrets, and shared keys used for device login, AAA, or SNMP access.

• Routing and control-plane security:
  Authentication keys, pre-shared keys, or password fields used in routing protocols (e.g., BGP, OSPF, EIGRP, IS-IS).

• Encryption and certificate material:
  Private keys, crypto configurations, and certificate blocks.

• Management and monitoring data:
  SNMP communities, syslog or NTP authentication keys, and API tokens.

The exact matching patterns are maintained internally by Forward Networks and differ per vendor or OS platform.
They are regularly updated to ensure that any configuration element containing sensitive or secret material is automatically redacted during collection.

---

Summary

Aspect	Description
Where redaction occurs	On the collector, before storage or upload
Cannot recover redacted data	Once masked or hashed, original values are unrecoverable
Custom filters supported	Yes, via hierarchical pattern filters
Effect on analysis	Over-redaction may impact modeling or forwarding analysis