Network Monitoring Tool Security Requirements

A network monitoring tool holds read access, and often write access, to every router, switch, firewall and server it watches, so buying one means buying a privileged identity that reaches the whole estate. The SolarWinds Orion compromise showed what happens when that tool is turned against its owner: one trojanised update gave attackers a trusted foothold on the server that already held credentials for the network. This vendor-neutral guide sets out the security requirements to write into a selection for network performance, availability and infrastructure monitoring tools, whether self-hosted or SaaS. It covers credential storage, polling protocols, collector design, platform hardening, supplier assurance, evaluation criteria, vendor questions, red flags and a proof of concept plan. It is for network, infrastructure and security teams and the procurement staff who run the RFP. Detection-focused products are covered in the NDR Buyer's Guide; this page is about the monitoring platform itself.

Key takeaways

Treat the tool as tier zero. Whatever credentials it stores, an attacker who owns the server or SaaS tenant owns too, so score credential handling before dashboards.
Insist on secure polling by default. SNMPv3 authPriv with SHA-2 authentication and AES privacy, SSH and TLS APIs, and no fallback to SNMPv1 or v2c community strings without an explicit, logged exception.
Read-only should be the norm. Configuration push, script execution and remote shell features belong behind separate roles, approval and audit, or switched off.
Collectors are where the risk concentrates. Ask how remote pollers authenticate to the core, which ports they open, how they are updated and what they cache.
Supplier assurance is a requirement, not a questionnaire. Signed updates, a build provenance story, an SBOM, a public vulnerability disclosure policy and timely CVE records decide whether you can trust the next update.

Define requirements

Start from what the tool will touch, not from feature lists. A short scoping exercise with network, server, cloud and security owners prevents a product being chosen for its maps and then quietly given domain admin to poll Windows hosts.

Estate and protocols: list device families and how each must be monitored: SNMP polling and traps, flow export (NetFlow v9, IPFIX, sFlow), syslog, streaming telemetry, WMI or WinRM for Windows, SSH for Linux and network operating systems, and cloud provider APIs. See the NetFlow and IPFIX Flow Telemetry Guide for what flow data can and cannot show.
Write actions: decide whether the tool may change anything. Configuration backup is read-only; configuration push, automated remediation, script execution and "run command" features are write actions with blast radius across the estate.
Deployment model: self-hosted on your servers, a vendor-managed SaaS core with on-premises collectors, or hybrid. Each moves where credentials live and who can reach them.
Segmentation: where the core, the collectors and the management network sit, and which flows between them must cross a firewall. See the Network Segmentation Guide.
Data held: device configurations (which can contain password hashes, keys and shared secrets), topology, interface names, flow records with internal addresses, and possibly packet captures. Classify it as sensitive.
Operators: who logs in (NOC, network engineers, managed service provider staff), from where, and with which identity provider.
Regulatory drivers: supplier risk requirements such as NIST CSF 2.0 GV.SC-05 (security requirements in supplier contracts) and GV.SC-06 (due diligence before the relationship), plus any sector rules that apply to your network.

Capability areas

These are the security capability areas to score. They sit alongside, not instead of, functional requirements such as discovery, alerting and capacity reporting.

Area	What good looks like	Why it matters
Credential storage	Credentials encrypted at rest with keys outside the application database; option to retrieve from an external secrets manager or PAM vault at poll time; credentials never shown back in the UI or exported in backups	The credential store is the prize: ED 21-01 told agencies to reset all credentials used by or stored in the compromised software
SNMP security	SNMPv3 USM with HMAC-SHA-2 authentication (RFC 7860, for example usmHMAC192SHA256AuthProtocol) and AES privacy (RFC 3826); per-device or per-group users; v1 and v2c disabled unless explicitly enabled	Community strings travel in cleartext and SNMP write access lets an attacker change device configuration (ATT&CK T1602.001 covers MIB dumping)
Other polling	SSH with host key verification, TLS with certificate validation for APIs and WinRM, scoped API tokens for cloud and SaaS sources	Disabled host key or certificate checks turn polling credentials into a gift for anyone in the path (T1557)
Least privilege	Documented minimum rights per source: SNMP read-only views, non-admin Windows monitoring rights where the platform supports them, read-only cloud roles	Many deployments run on domain admin or enable secret because the vendor guide said so
Collector security	Mutual TLS or signed enrolment between collectors and core, outbound-only connections where possible, signed collector updates, minimal local cache	Remote pollers sit in branch and DMZ networks with the same credentials as the core
Operator access	SAML or OIDC single sign-on, MFA enforced, role-based access with separate roles for viewing, configuring and write actions, SCIM or group-driven provisioning	A shared local admin on the monitoring console is a common foothold
Audit logging	Logs of logins, credential changes, discovery scopes, alert and script changes and every write action; export to SIEM over syslog TLS (RFC 5425, TCP 6514) or API; tamper-evident retention	You need evidence of what the tool did on the network, not just what it saw
Platform hardening	Supported OS and database versions, published hardening guide, no default passwords, least-privilege service accounts, TLS 1.2 or higher on all interfaces	Self-hosted cores are often installed once and never hardened
Supplier assurance	Signed updates verified before install, SBOM on request, public vulnerability disclosure policy, CVE records with CWE and CPE fields, security patch cadence	Software supply chain compromise (T1195.002) arrives through trusted updates
Data protection	Encryption of stored configs and flow data, retention controls, redaction of secrets in stored device configurations, tenant isolation for SaaS	Stored configs leak shared secrets and keys even when the tool itself is secure

Where identity fits

A monitoring platform is a cluster of non-human identities: polling accounts on every device class, SNMPv3 users, API tokens for cloud accounts, service accounts for its own database and Windows services, and collector enrolment credentials. Ask for an inventory of every identity the product needs and the rights each requires, then register them with owners. Where Windows polling needs a domain account, prefer a Group Managed Service Account (gMSA) or a dedicated non-admin account, and alert on interactive logons by it. ED 21-01 specifically called for moving service accounts to gMSA and enforcing AES256 for Kerberos to blunt Kerberoasting after the Orion compromise. See the Service Account Security Guide and How to detect interactive logons by service accounts.

Deployment models compared

Model	Where credentials live	Main security advantage	Main security concern	Fits best
Self-hosted core and collectors	Your servers and database	Full control over network placement, patching and keys	You own hardening, patching and backup security; updates still come from the vendor	Regulated or air-gapped networks with mature server operations
SaaS core with on-premises collectors	Usually collectors, sometimes the vendor cloud	Vendor patches the core; collectors can be outbound only	Vendor tenant compromise, data residency, collector enrolment security	Distributed estates, smaller teams
Agent-based	Agents on each host, minimal central credentials	Fewer stored polling credentials	Every agent is privileged software that must be updated safely	Server-heavy estates where agents are acceptable
Managed service provider operated	Provider systems	Specialist operation	Third-party access to the whole network (T1199 Trusted Relationship)	Organisations without a NOC; require strong contract terms

Small vs large organisations: a small organisation gains most from a SaaS core with outbound-only collectors, SSO with MFA and read-only polling, because it cannot harden and patch a self-hosted server well. A large or regulated organisation can justify self-hosting on a dedicated management network, with credentials pulled from a PAM vault and changes approved through ITSM.

Evaluation criteria

Weight the criteria to your risk. A suggested starting weighting for security scoring is below; adjust for write actions in scope.

Criterion	Weight	Evidence to request
Credential protection and vault integration	20%	Architecture document, key management description, live demo of vault retrieval
Secure protocols by default	15%	Default configuration export showing SNMPv3 algorithms, SSH host key and TLS validation settings
Least privilege and write-action control	15%	Minimum-rights documentation per source, RBAC model, approval workflow for write actions
Operator authentication and RBAC	10%	SSO and MFA configuration, local account break-glass design
Audit logging and SIEM export	10%	Sample log events, field list, export formats, retention
Supplier assurance and update integrity	15%	Signing process, SBOM, VDP URL, CVE history and time to fix
Collector and platform hardening	10%	Hardening guide, port list, supported OS matrix
Data protection and residency	5%	Encryption at rest, retention settings, hosting regions

Questions to ask vendors

Where are polling credentials stored, how are they encrypted, where is the key held, and can an administrator read a stored credential back in clear text?
Can the product fetch credentials from our secrets manager or PAM vault at poll time instead of storing them?
Which SNMPv3 authentication and privacy protocols do you support? Do you support the RFC 7860 SHA-2 protocols and AES privacy, and can SNMPv1 and v2c be disabled globally?
Does every SSH connection verify host keys, and every API or WinRM connection validate certificates by default? Can an operator turn validation off without an audit record?
What are the minimum rights needed to monitor Windows, Linux, each network operating system and each cloud provider? Show us the documentation.
Which features can change device state (configuration push, scripts, remote commands)? Can they be disabled entirely or restricted to a separate role with approval?
How do collectors authenticate to the core, which direction do connections go, which ports are required, and how are collectors updated?
How are product updates signed and verified before installation? What build integrity and provenance controls do you apply to your own build pipeline?
Will you provide a machine-readable SBOM, and do you have a public vulnerability disclosure policy? How long did your last three critical vulnerabilities take to fix?
Are security audit logs included at no extra cost, and for SaaS how long are they retained? CISA's Secure by Demand guide asks for at least six months.
Do you support SSO with SAML or OIDC and enforce MFA for all console users without an extra licence tier?
Do stored device configurations have secrets redacted or encrypted, and who at your company can access customer tenant data?

Red flags

Installation guides that require domain admin, enable secret or root for routine polling.
SNMPv2c with a default community string enabled out of the box, or SNMPv3 limited to MD5 and DES.
Host key or certificate validation disabled by default "for ease of onboarding".
Credentials exportable in plain text through the UI, reports or backup files.
Default administrator passwords on the console or database, or MFA only in a premium tier.
Collectors that require inbound connections from the internet or from the SaaS core.
Unsigned updates, update servers without TLS, or advice to exclude the product folder from endpoint protection without a narrow rationale.
No public vulnerability disclosure policy and no history of published security advisories.

Common failure patterns

Trusting the update channel completely: in the SolarWinds supply chain compromise, a trojanised Orion update reached thousands of customers, and recovery meant rebuilding hosts and resetting every credential the platform stored or used. Buy with update integrity and credential blast radius in mind.
Over-privileged polling accounts: one domain admin account used for every Windows host means compromise of the monitoring server is compromise of the domain.
Legacy SNMP left on: v2c read-write communities enabled for an old use case and never removed. See the SNMP Security Guide.
Monitoring server on the user network: the console reachable from every workstation, with a local admin account and no MFA.
Stored configurations as a credential source: backed-up device configs holding weak password hashes and shared secrets, readable by every console user (T1552.001 Credentials In Files describes the general technique).
Write features enabled by default: remote command or script features used by an attacker for lateral movement through a trusted tool.

Proof of concept

Build an isolated test segment with representative devices: a router, a switch, a firewall, a Windows and a Linux server, and one cloud account with a read-only role.
Configure least privilege first: SNMPv3 authPriv users with read-only views, non-admin Windows rights, read-only cloud roles. Record every place the product fails or asks for more rights.
Test credential handling: try to retrieve a stored credential through the UI, API, report export and backup file. Test retrieval from your vault if supported.
Test protocol enforcement: present a device with a changed SSH host key and an API endpoint with an invalid certificate; the product should refuse and alert.
Test write-action controls: confirm configuration push and scripts can be disabled or require a separate role and approval, and that each action is logged with the operator identity.
Test collector security: capture collector traffic to confirm mutual TLS and outbound-only connections; revoke a collector and confirm it can no longer report.
Test operator access: SSO with MFA, role separation, and the behaviour of break-glass local accounts.
Test logging: forward audit logs to your SIEM and confirm logins, credential changes and write actions arrive with usable fields.
Test update and rollback: apply an update, verify the signature check, and roll back to the previous version from a known-good backup.

Detection and measurement after selection

Once deployed, monitor the monitor. Alert on new administrator accounts in the console, credential changes, discovery scope changes, any write action, polling account logons outside the expected source addresses, and interactive logons by polling accounts. Watch the monitoring server for unexpected outbound connections, which was the key indicator of the Orion backdoor. Useful measures:

Percentage of devices polled over secure protocols (SNMPv3 authPriv, SSH, TLS), target 100%.
Number of polling identities with administrative rights, trending to zero.
Days to apply vendor security updates after release.
Percentage of console users authenticating through SSO with MFA.
Time to rotate all monitoring credentials, tested at least once a year (an NHI Mgmt Group recommendation).

Framework mapping

Requirement	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK technique addressed
Security requirements in the purchase	SA-4 Acquisition Process, SR-6 Supplier Assessments and Reviews	GV.SC-05, GV.SC-06	T1195.002 Compromise Software Supply Chain
Update integrity and provenance	SI-7 Software, Firmware, and Information Integrity, SR-4 Provenance	GV.SC-07	T1195.002
Credential protection	IA-5 Authenticator Management	PR.AA-01	T1552.001 Credentials In Files, T1078 Valid Accounts
Least privilege polling	AC-6 Least Privilege	PR.AA-05	T1078
Encrypted management protocols	SC-8 Transmission Confidentiality and Integrity	PR.DS-02	T1040 Network Sniffing, T1602.001 SNMP (MIB Dump)
Audit of tool actions	AU-2 Event Logging, AU-9 Protection of Audit Information	DE.CM-09	T1199 Trusted Relationship

The NCSC secure system administration principles (protect administration interfaces, tier administration, use privileged access management, log and audit administration) apply directly to a monitoring platform because it is an administration tool. CIS Controls v8.1 Control 12 (Network Infrastructure Management) and Control 15 (Service Provider Management) are the closest control-level fits.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support, with a focus on the non-human identities that infrastructure tools create and hold. Browse vendors in our products directory or contact us about independent evaluation support.

Security Requirements for Selecting a Network Monitoring Tool: Criteria, Vendor Questions and Proof of Concept Tests