An NDR platform sees a copy of your most sensitive network traffic and can often push blocks to firewalls and switches, so an attacker who controls it can read what crosses the wire, blind your monitoring and cut off legitimate services. Sensors sit on taps and mirror ports beside domain controllers, data centre spines and management networks; packet stores keep payloads that may include cleartext credentials; and response integrations hold API keys into firewalls, endpoint tools and network access control. This guide is for network security engineers, SOC leads and platform owners who run an NDR, whether on appliances, virtual sensors or cloud traffic mirroring. It covers admin roles, the sensor management plane, the service accounts and keys the platform holds, packet and decryption key handling, the platform's own logs, response guardrails and the lifecycle. It is vendor-neutral: confirm exact setting names in your vendor's documentation. For what NDR detects and where to place sensors, see the NDR Guide.
Key takeaways
- Keep sensor management off the monitored network. Capture interfaces receive traffic only; management goes over a separate management network or, at minimum, a management VLAN with encrypted sessions, as NIST SP 800-94 describes for intrusion detection components.
- Treat the packet store as a sensitive data store. Full packets and extracted files can contain passwords, tokens and personal data; restrict who can download them and for how long they are kept.
- Guard decryption keys like the services they belong to. If the NDR decrypts TLS with server private keys or session secrets, it holds keys that can impersonate those services.
- Scope response integrations tightly. Keys into firewalls and endpoint tools should allow only the specific block or quarantine actions used, with protected lists and caps.
- Alert on silence from outside the NDR. A stopped sensor or a dead mirror port looks exactly like a quiet network.
Why the NDR is a high-value target
NIST SP 800-94, the US guide to intrusion detection and prevention systems, notes that these systems often hold sensitive data such as host configurations and known vulnerabilities, which makes them attractive targets, and that a compromised system could alter or destroy its own logs. NDR adds packet capture, decryption and automated response to that picture.
The component table reflects a common architecture and is NHI Mgmt Group's view, not a sourced description of any one product; your platform may name, merge or split these components differently.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Central console or cloud tenant | Detections, allow lists, sensor configuration, response playbooks, user roles | Allow-lists their command and control, silences alerts, triggers blocks | SSO with phishing-resistant MFA, least-privilege roles, admin from privileged access workstations |
| Physical and virtual sensors | Copies of traffic, local metadata and packet buffers, update channel | Reads traffic, stops capture, uses the sensor as a foothold on a sensitive segment | Management network, hardened OS, signed updates, heartbeat alerting |
| Packet and file store | Payloads, extracted files, sometimes cleartext credentials | Harvests secrets and personal data in bulk | Role-limited download, short retention, encryption at rest |
| Decryption material | Server private keys or session key logs | Impersonates or decrypts the affected services (T1552.004) | Hardware-backed key storage, minimum key set, rotation |
| Cloud traffic mirroring identity | Rights to create mirror sessions and read flow logs | Mirrors traffic to their own target, or stops mirroring | Narrow role, alert on mirror session changes |
| Response integrations | API keys into firewalls, endpoint, network access control, SOAR | Blocks administrators or critical services, or covers tracks | Scoped keys, protected lists, approval for high-impact actions |
Admin roles and console access
- Separate accounts and least privilege: NIST SP 800-94 advises a separate account for each user and administrator with only the privileges they need. Define at least platform administrator (sensors, integrations, roles), detection engineer (rules, allow lists), analyst (triage and metadata search), packet analyst (payload and file access) and responder (approve or run response actions).
- Packet access is its own privilege: analysts can usually work from metadata. Grant payload download and file extraction to a smaller group and log every download.
- Allow lists are as sensitive as admin rights: an allow-listed destination is a permanent blind spot. Require a ticket, an owner and an expiry for each entry; 90 days is our suggested default.
- Authentication: sign in with SSO and phishing-resistant MFA. NIST SP 800-94 notes that some organisations require strong authentication such as two-factor for remote access to components. The CISA and FBI Secure by Demand guide asks vendors to offer standards-based SSO at no additional cost and MFA by default. Keep one documented break-glass account. See the Break-Glass Account Guide.
- Admin devices: follow the NCSC secure system administration principles: trusted management devices, protected admin interfaces and logged admin activity. See the Privileged Access Workstations Guide.
The sensor management plane
NIST SP 800-94 describes two options for managing intrusion detection components: a separate management network, where each sensor has a dedicated management interface that cannot pass traffic to its monitoring interfaces, or a management VLAN, which it says protects communications but not as well as a separate network. The same logic applies to NDR sensors.
| Design | Protection | Trade-off | When to choose |
|---|---|---|---|
| Separate physical management network | Strongest: hides sensors, keeps bandwidth during floods, isolates management | Cabling and switch cost | Data centres, sensors on tier 0 segments, OT networks |
| Management VLAN | Logical separation; a VLAN misconfiguration can expose sensor data | Shares devices that may saturate under attack | Branch sites and smaller estates |
| Encrypted management over the production network | Protects sessions in transit only | Sensor is reachable from production hosts | Only where neither option above is possible; add tight filtering |
| Cloud sensors | Management through the provider's control plane and a dedicated subnet | Relies on cloud identity controls | Cloud workloads with traffic mirroring |
- Restrict who can reach sensors: NIST SP 800-94 advises limiting direct access to components to the hosts that need it, using firewalls and packet filters. Allow SSH or HTTPS management only from the console and privileged access workstations.
- Encrypt management traffic: use TLS 1.2 or later between sensors and console, with certificate validation (our recommendation); NIST SP 800-94 asks for FIPS-approved algorithms where encryption is used.
- Harden the sensor OS: NIST SP 800-94 says software components should be hardened and kept fully up to date. Disable unused services, change any vendor default credentials on first boot and turn on any tamper protection the sensor offers.
- Verify updates: compare vendor checksums or signatures before applying software and signature updates, back up configuration first, and test on a pilot sensor, as NIST SP 800-94 recommends. Apply vendor security updates promptly and subscribe to the vendor's security advisories page.
- Protect the mirror source: the switch SPAN or tap configuration and cloud mirror sessions decide what the sensor sees. Treat changes to them as security changes and alert on them. See the Network Device Management Plane Hardening Guide.
Service accounts, keys and integrations
| Identity | Needs | Avoid | Credential pattern |
|---|---|---|---|
| Cloud mirroring and flow log reader | Create and read mirror sessions, read flow logs in defined accounts | Account-wide network administrator or owner roles | Workload identity federation or cross-account role with conditions |
| Directory and asset enrichment | Read users, groups and asset records | Privileged group membership, interactive logon | Managed service account or certificate, logon limited to the collector |
| Firewall or network access control response key | Add and remove entries in one dedicated block list or quarantine group | Full firewall administrator rights | Dedicated API role, source address restriction, expiry |
| Endpoint response key | Isolate a host on request | Rights to uninstall agents or change endpoint policy | Scoped API client, separate from read access |
| SIEM and SOAR integration | Send alerts; SOAR may query metadata | One key reused for inbound and outbound integrations | One key per direction and integration |
- Separate read from act: a leaked enrichment or SIEM key should never be able to block traffic.
- Write-only block lists: give the NDR its own dynamic block list or address group in the firewall, so it can never edit other policy.
- Rotation: rotate any static API key at least every 90 days where federation or certificates are not available (our recommendation), and record every NDR identity in your NHI inventory. See the Service Account Security Guide and the API Key Management Guide.
Packets, files and decryption keys
Network capture collects data nobody chose to collect. Cleartext protocols carry passwords, internal APIs carry bearer tokens, and extracted files can include personal data. Decide what you keep before you turn capture on.
- Capture by policy: keep metadata broadly and full packets selectively (alert-triggered or for defined segments). Shorter packet retention reduces exposure; set it by investigation need and record the decision. See the Network Monitoring and Packet Capture Guide.
- Find and fix cleartext secrets: use NDR detections for credentials in cleartext protocols to drive remediation at the source, then rotate those credentials; do not let the packet store become the place they live.
- Encrypt and restrict the store: encrypt packet and file storage at rest, limit download to the packet analyst role and alert on bulk download.
- Decryption keys: if the platform decrypts traffic with server private keys, hold only the keys you need, store them in hardware-backed or platform key storage, rotate them when the certificate changes and remove them when the service is decommissioned. If a key may have leaked, follow the Leaked TLS Private Key Response. Where decryption happens at a separate inspection point instead, see the TLS Inspection Guide.
- Privacy: document the lawful basis and purpose for capture, and exclude categories you do not need, such as known health or HR systems, where your policy requires it.
The NDR's own logs and time
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role change, new local user, SSO setting change | Persistence in the console | Always |
| New or widened allow list or suppression | Permanent blind spot | Always, with approver |
| Detection disabled or severity lowered | Reduced coverage (T1685) | Always for high-severity detections |
| Sensor offline, capture interface down, packet drop above threshold | Loss of visibility | Always |
| Packet or file download, especially bulk | Data theft through the console | Above a set volume |
| Response action run or approved | Accountability and misuse detection | Bulk actions and any action on protected assets |
| Cloud mirror session created, changed or deleted | Traffic diverted or monitoring stopped | Always |
NIST SP 800-94 recommends storing logs both locally and centrally so that a compromised component cannot destroy the only copy, and synchronising clocks with NTP. Forward the platform audit log to a SIEM or archive that NDR administrators cannot alter (NIST SP 800-53 AU-9(2)), and alert on missed sensor heartbeats from that system rather than from the NDR alone.
Response guardrails
- Protected assets: keep a list of addresses and hosts automation can never block or isolate: domain controllers, DNS resolvers, identity providers, management networks, the NDR's own sensors and the console.
- Caps: limit automated blocks per hour, for example ten without a human (our suggested starting point), and fall back to alert-only when the cap is hit.
- Expiring blocks: automated blocks should expire unless an analyst confirms them, so a poisoned detection cannot leave permanent damage.
- Kill switch: document how to pause all automated response in one step and test it twice a year (our recommendation). See the SOAR and Security Automation Guide.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO, MFA by default, no default passwords, security logs in the base product, vulnerability disclosure policy, SBOM). Ask where packet data is stored, who at the vendor can see it, and how sensor updates are signed. See the NDR Buyer's Guide and NDR RFP Template. |
| Deploy | Build the management network first; change default credentials before connecting sensors; enable SSO and audit log export on day one; start response in alert-only mode. |
| Run | Quarterly reviews of roles, keys, allow lists and decryption keys; verified updates on a pilot sensor first; configuration backups before every update; packet retention checks. |
| Retire | Remove mirror sessions and SPAN configuration; revoke API keys and cloud roles; delete decryption keys; securely wipe sensor disks and packet stores and record it; obtain written confirmation of deletion for any vendor-held data. |
Roll back a change such as narrowing a response key by keeping the previous permission set documented and re-granting only the specific right a failing action reports as missing.
Detection and measurement
- Percentage of sensors managed only over a management network or VLAN, with no management service reachable from monitored segments.
- Number of users with packet download rights, and downloads per month with a case reference.
- Allow-list entries past their expiry without re-approval (target: zero).
- Sensor coverage and health: percentage of planned capture points with a healthy sensor and packet drop below threshold.
- Measured time to detect a stopped sensor or deleted mirror session.
- Percentage of NDR integration keys that are scoped, owned and within their rotation date.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and packet access | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Management plane separation | SC-7, SC-8, CM-6 | PR.PS-04, DE.CM-01 | T1040 Network Sniffing |
| Keys and decryption material | IA-5, SC-12 | PR.AA-01 | T1552.004 Private Keys, T1098.001 Additional Cloud Credentials |
| Audit log and sensor health | AU-6, AU-8, AU-9(2), AC-6(9), SI-4 | PR.PS-04, DE.CM-01 | T1685 Disable or Modify Tools |
| Vendor updates and supply chain | SA-9, SR-3 | GV.SC-07 | T1195 Supply Chain Compromise |
Common failure patterns
- Management on the capture network: the sensor's web interface is reachable from the segment it monitors, so any host there can attack it.
- Everyone can download packets: broad analyst roles turn the packet store into an easy source of credentials.
- Full firewall admin for blocking: the response key can rewrite any rule, not just add blocks.
- Stale decryption keys: private keys for retired or renewed services stay on the platform for years.
- Silent mirror ports: a switch change drops a SPAN session and nobody notices because the NDR reports only on what it sees.
- Permanent allow lists: a noisy backup server is allow-listed during tuning and later becomes the exfiltration path.
Practitioner checklist
- Put sensor management on a separate management network or VLAN, reachable only from the console and privileged access workstations.
- Change all default credentials and enforce SSO with phishing-resistant MFA for the console.
- Separate admin, detection, analyst, packet analyst and responder roles.
- Limit packet download to a small group, log it and set packet retention by policy.
- Keep decryption keys to the minimum set, in protected storage, and remove them when services change.
- Scope response keys to dedicated block lists and quarantine groups, with protected assets and caps.
- Verify every software and signature update, back up configuration first and pilot on one sensor.
- Export the platform audit log off the NDR and alert on sensor and mirror silence from another system.
- Review roles, keys, allow lists and mirror sessions every quarter and keep a decommissioning checklist.
Standards and references
- NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS)
- NCSC: Secure system administration
- NCSC: Introduction to logging for security purposes
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1685 Disable or Modify Tools
Related NHI Mgmt Group resources: NDR Guide · NDR Buyer's Guide · TLS Inspection Guide · Securing the PAM Vault Itself · Securing the identity threat detection and response (ITDR) tool itself