AppProfileSafe - Support Portal

Redaction & Data Protection

Before an event is delivered to a sink, the redaction engine can mask, hash, or remove sensitive fields. Different sinks can use different redaction policies — for example, external SIEM endpoints may use strict redaction while the local Windows Event Log receives unredacted events. Configuration is stored in `redaction.xml`.

Redaction Types

Three redaction rules are available:

Type	Description	Example
`Suppress`	Removes the field value entirely (sets to null)	`"Details": "Exported 42 files"` → `"Details": null`
`Hash`	Replaces the value with a truncated SHA-256 hash (32 hex characters) for pseudonymization	`"UserName": "jsmith"` → `"UserName": "a1b2c3d4e5f6..."`
`PartialMask`	Keeps the first N path segments and replaces the rest with `***`. The `keep` attribute specifies how many segments to preserve.	`"FilePath": "C:\Users\jsmith\AppData\config.xml"` → `"FilePath": "C:\Users\*\\**"` (keep=2)

Defining Policies

Policies are named groups of field-level rules. Define them in the <Policies> section:

<Policies>
  <Policy name="strict">
    <Rule field="UserName"    type="Hash" />
    <Rule field="MachineName" type="Hash" />
    <Rule field="FilePath"    type="PartialMask" keep="2" />
    <Rule field="RegistryKey" type="PartialMask" keep="3" />
    <Rule field="Detail"      type="Suppress" />
  </Policy>

  <Policy name="moderate">
    <Rule field="UserName"    type="Hash" />
    <Rule field="MachineName" type="PartialMask" keep="4" />
  </Policy>

  <Policy name="none" />
</Policies>

The field attribute uses dot-notation to target nested properties (e.g. Context.UserName). An empty policy (like none) means no redaction is applied.

Sink-to-Policy Mapping

The <SinkMappings> section assigns a policy to each sink. Sinks not listed receive no redaction:

<SinkMappings>
  <Sink id="siem-http"       policy="strict" />
  <Sink id="siem-syslog"     policy="strict" />
  <Sink id="webhook-primary" policy="moderate" />
  <Sink id="eventlog"        policy="none" />
</SinkMappings>

Redaction is applied per-sink at delivery time. The original event in the queue is never modified — a deep clone is created for each sink, ensuring that different sinks can receive different views of the same event.

Processing Order

Rules within a policy are applied sequentially in the order they are defined. Each rule operates on a specific field. If the field does not exist on the event (or is already null), the rule is silently skipped. This means you can safely define broad policies without needing to check whether every event type contains every field.