Transmission security policy
What this page covers
Section titled “What this page covers”Not every channel in an environment is encrypted at the same time: some protocols carry no encryption option, and some targets speak only cleartext. This page brings the encryption state of six channels together and lets you decide, channel by channel, whether to allow, to record, or to refuse.
Six channels and three levels of enforcement
Section titled “Six channels and three levels of enforcement”The policy lives on the Transmission Security page, where each of the six channels has a level key, all shipped as unrestricted:
| Channel | What counts as a risk |
|---|---|
| RDP | Certificate verification off, or a security mode below network level authentication |
| VNC | The protocol carries no encryption (always matches) |
| Database | TLS mode empty or encryption off |
| LDAP | An unencrypted connection or certificate verification skipped |
| syslog | Forwarding that does not use TLS |
| Notifications | A channel address on http |
The three levels:
- Unrestricted: things stay as they are, with no effect.
- Warn and record: on a connection channel the user acknowledges the risk before the connection goes through, and the acknowledgment enters the audit records; on a configuration channel a confirmation is required when saving.
- Strict refusal: a match on a risk refuses, and reports which channel and which items did not pass.
There is also a “transmission risk acknowledgment validity”, shipped as 90 days, where 0 means it does not expire.
How risk acknowledgment works
Section titled “How risk acknowledgment works”At the warn and record level, a “transmission risk confirmation” dialog appears before the connection, listing the risk items of that connection, and the connection ticket is issued once the user presses “I understand the risk and want to continue”. This gate is enforced in the backend, so calling around the interface is stopped just the same.
An acknowledgment is held at the granularity of one user and one asset, and within its validity it is not asked for again. Raising the level from warn to strict invalidates the existing acknowledgments. A change in the set of risk items invalidates the acknowledgment too, while a setting changed away and back to the same set does not ask again.
Channel encryption inventory
Section titled “Channel encryption inventory”The lower half of the same page is the inventory, listing each channel’s policy level, asset count, deviation count, and details. The web layer is marked as managed by the deployer, showing the state and a notice without a switch; see TLS and certificates for how to set it. SSH is marked as encrypted by the protocol itself and falls outside this policy. The LDAP channel shows the encryption state currently configured, with a pointer to its settings page.
Before you switch to strict refusal, the page says how many assets it will affect.
The inventory has an “Export snapshot” button, and the snapshot carries its generation time and the person who generated it.
Risk badges on assets
Section titled “Risk badges on assets”At any policy level the asset list shows a risk badge and a count, so the nature of the channel is visible before anyone connects. The WinRM channel used for password rotation is disclosed permanently under its own risk key and appears in the inventory; see Windows local accounts.
What auditors can see
Section titled “What auditors can see”- Reading and exporting the inventory both leave records.
- A risk acknowledgment is stored and recorded with the user, time, asset, and a snapshot of the risk items.
- A connection stopped by strict refusal leaves a record, and the response names the channel and the items that did not pass.
- At the warn and record level, each directory login leaves a transmission deviation record.
- A change to a policy key leaves a record with the person and the values before and after.