co-authored by Jim Kotantoulas, DoD Cisco Security Engineer

Zero Trust depends on a simple but demanding idea: organizations should continually evaluate activity rather than assume that anything inside the network can be trusted. Putting that principle into practice requires more than access policy. Security teams also need broad visibility, reliable telemetry, behavioral context, and the ability to investigate activity that crosses users, devices, workloads, and network boundaries. 

Cisco Secure Network Analytics (SNA) helps provide that visibility by using telemetry from existing network infrastructure – including routers, switches, and firewalls – to establish behavioral baselines and identify suspicious activity. Now, the Defense Information Systems Agency (DISA) has released a product-specific Security Technical Implementation Guide (STIG) for securely configuring the Cisco SNA platform. 

The Cisco Secure Network Analytics STIG Version 1, Release 1, dated June 29, 2026, was developed by Cisco and DISA. The release is significant because it gives defense organizations a common technical baseline for hardening an agentless network detection and response platform that may hold sensitive network telemetry, security findings, and investigative context. 

The STIG does not replace sound architecture or operational judgment. It does something equally practical: it converts cybersecurity policy into specific, testable configuration requirements that administrators and assessors can apply consistently. 

A new product-specific baseline for Cisco SNA 

Version 1, Release 1 is the initial release of the Cisco Secure Network Analytics STIG. The benchmark has 31 requirements: 8 rated as high severity and 23 rated as medium severity. Each requirement provides a vulnerability discussion, assessment procedure, remediation guidance, severity rating, and Control Correlation Identifier that connects the technical check to broader cybersecurity policy. 

The guide is derived from NIST SP 800-53 and related requirements. It supports the evidence-based assessment process used within the Risk Management Framework by giving system owners, engineers, and assessors a shared definition of the expected secure state. 

Unlike a feature checklist for network detection and response, the STIG primarily addresses the security of the SNA appliance and its management functions. That focus is essential. A platform used to observe network behavior and support threat investigations must itself be protected against unauthorized access, insecure communications, configuration drift, audit failure, and unsupported software. 

Protect the platform that protects visibility 

Network telemetry can reveal how an enterprise operates: which systems communicate, how users and devices behave, where critical services reside, and when activity differs from the norm. This makes the integrity and confidentiality of the analytics platform especially important. 

The STIG addresses that responsibility through requirements covering several major areas. 

Identity and administrative access 

The benchmark requires controls for concurrent administrative sessions, role or access-level assignments, failed-login lockouts, and tightly controlled local accounts of last resort. It also addresses multifactor authentication, use of approved public key infrastructure, redundant authentication servers, certificate revocation checking, and approved trust anchors. 

These measures help reduce the risk that a compromised or overly privileged administrative account could alter platform configuration, suppress evidence, or expose sensitive network information. They also reinforce a core Zero Trust practice: administrative access should be explicitly authorized, strongly authenticated, and limited to the privileges required for the role. 

Cryptography and protected communications 

The STIG includes requirements for approved cryptographic algorithms, encrypted information at rest, authenticated SNMP messages, authenticated Network Time Protocol sources, certificate management, and modern web communications. These controls are designed to protect management traffic, stored information, and the trust relationships used by the platform. 

The benchmark also requires SNA to use approved trust anchors and validate certificate status. In an environment where authentication and secure communications depend on PKI, the presence of a certificate is not enough. The certificate chain, issuing authority, validity, and revocation status all contribute to the trust decision. 

Auditability and external accountability 

The guide requires audit records for critical file modifications, real-time alerts for designated audit failures, and forwarding of log data to central logging infrastructure. Boundary-device deployments require additional logging resilience. 

Centralized logs help protect evidence from local loss or manipulation and give security operations teams a broader view of administrative and system activity. For an analytics platform, this creates an important chain of accountability: SNA provides evidence about the network, while its own security and audit records provide evidence about how the platform was accessed and operated. 

Secure operation and lifecycle management 

The benchmark covers disabling unnecessary or insecure services, controlling the flow of management information, terminating inactive sessions, installing security-relevant updates within the defined period, and operating on a Cisco-supported software release. 

These requirements underscore that secure configuration is not a one-time event. A hardened system can drift as accounts change, certificates expire, software ages, integrations are added, and mission requirements evolve. Maintaining the STIG baseline therefore requires disciplined change management and recurring validation. 

How SNA contributes to Zero Trust operations 

The STIG focuses on securely configuring the platform. Cisco SNA’s operational role is broader: it uses network telemetry and behavioral analytics to help teams understand what is communicating, identify changes from established behavior, investigate suspicious activity, and preserve context for response. 

This capability can support Zero Trust operations in several ways: 

• Continuous visibility: Agentless telemetry helps reveal activity across devices and workloads without depending solely on endpoint software.
  
• Behavioral context: Analytics establish patterns of normal activity and highlight meaningful deviations that warrant investigation.
  
• East-west monitoring: Network visibility can help expose lateral movement and internal activity that perimeter-focused controls may not see.
  
• Investigation evidence: Historical telemetry and contextual alerts can help analysts reconstruct events, understand scope, and make better-informed response decisions.
  
• Policy validation: Observed traffic can help teams identify unexpected communications and investigate potential segmentation or access-policy violations.
  
• Security ecosystem integration: SNA can enrich broader detection and response workflows by sharing network context with other Cisco and third-party security capabilities. 

The relationship between these capabilities and the STIG is straightforward: organizations can place greater confidence in security telemetry when the system collecting, analyzing, presenting, and preserving that information is itself securely configured and auditable. 

A practical implementation approach 

The new benchmark can become the foundation of a repeatable hardening and assessment program. 

1. Establishthe Baseline: Download the latest benchmark package from the DoD Cyber Exchange. Record the version, release number, benchmark date, and file integrity hashes, and preserve the original archive with your assessment evidence.  
2. Define the Deployment Boundary: Inventory all SNA components, physical/virtual appliances, management interfaces, authentication services, telemetry sources, PKI dependencies, NTP time sources, and central logging destinations.  
3. Align Controls & Ownership: Map benchmark requirements to functional teams—assign identity and authentication checks to Identity teams, PKI requirements to Certificate Admins, syslog forwarding to SecOps, and platform hardening to SNA Admins. Ensure shared responsibilities are clearly defined.  
4. Document Site-Specific Policies: Capture organization-defined values, concurrent-session limits, alert recipients, approved trust anchors, central logging targets, and any mission-justified timeout exceptions in your System Security Plan (SSP).  
5. Validatein Staging First: Test configuration changes in a representative lab environment to verify both security posture and operational impact before production rollout.
6. Collect Durable Evidence: Archive configuration exports, screenshots, PKI/auth records, log-forwarding verification tests, update records, and formal approvals to demonstrate both configured state and dependent service health.  
7. Plan for Continuous Compliance: Reassess your deployment following software upgrades, certificate renewals, IdP/logging changes, and new STIG releases to prevent configuration drift between formal audit cycles.
   

What the SNA STIG does – and does not – mean 

A product-specific STIG provides authoritative operational security guidance for configuring a product used in a defense environment. It does not constitute DISA endorsement, certify the accuracy of every threat detection, approve a particular deployment, or make a system fully secure. 

The STIG is one input to assessment and authorization. The responsible authorizing official determines product use and accepts system risk through the Risk Management Framework. Applicable NIST SP 800-53 controls must still be evaluated across the complete system and architecture, including external identity, PKI, logging, time, network, backup, and incident-response dependencies. 

That boundary is important because the 31 checks focus mainly on protecting and administering the SNA platform. They should not be presented as proof that every monitoring objective, detection use case, telemetry source, retention requirement, or response workflow has been implemented. Those outcomes depend on deployment design, data coverage, tuning, integrations, staffing, and operational processes. 

From network telemetry to repeatable security practice 

Zero Trust architecture asks organizations to make better decisions from identity, device, workload, and behavioral context. Cisco Secure Network Analytics helps security teams turn the network into a source of that context. The Secure Network Analytics Disa STIG Version 1 adds a repeatable baseline for protecting the platform on which those observations and investigations depend. 

For defense and federal organizations, the opportunity is to integrate the guide into architecture reviews, deployment standards, change control, evidence collection, and continuous monitoring. Used this way, the STIG becomes more than an assessment checklist. It becomes part of an operating discipline that protects the integrity of security visibility itself.  

The goal is not simply to complete 31 checks. It is to maintain a trusted analytics platform that can help defenders see network activity, investigate risk, and explain security decisions with credible evidence. 

Calls to action 

• Explore Cisco Secure Network Analytics
• Learn more about network traffic analysis and network detection and response
• Obtain current security guidance from the DoD Cyber Exchange STIG Document Library