NIST CSF and SP 800-53 Compliance Assessment

Compliance assessment skill that maps network device configuration and
operational state against NIST SP 800-53 Rev 5 controls and the NIST
Cybersecurity Framework (CSF) 2.0 functions. Assesses 6 of the 20 NIST
800-53 control families that have direct network device relevance:

• - AC — Access Control
• AU — Audit and Accountability
• CM — Configuration Management
• IA — Identification and Authentication
• SC — System and Communications Protection
• SI — System and Information Integrity

The remaining 14 control families (AT, CA, CP, IR, MA, MP, PE, PL, PM, PS,
PT, RA, SA, SR) are outside the scope of network device configuration
assessment — they address organizational processes, physical security,
personnel, supply chain, or system-level concerns not directly observable
in device configuration.

Focuses on CSF Protect (PR) and Detect (DE) functions, which map
most directly to network device hardening and monitoring controls. NIST
SP 800-53 and the CSF are public-domain US government publications.

Consult references/control-reference.md for the full control-to-CSF
mapping table and references/cli-reference.md for per-platform read-only
verification commands.

When to Use

• - Federal agency compliance under FISMA — mapping network infrastructure

controls to NIST 800-53 baselines at Low, Moderate, or High impact levels

• - Government contractor assessments requiring NIST 800-171 or CMMC alignment
• Enterprise NIST CSF adoption — structuring network security posture

assessment around CSF functions (Identify, Protect, Detect, Respond, Recover)

• - Security posture baselining — establishing measurable control compliance

state before and after remediation

• - Audit preparation for NIST-referenced frameworks (FedRAMP, CMMC, state and

local government standards)

• - Risk management input — providing control gap evidence for organizational

risk assessments per NIST RMF

Prerequisites

• - Read-only CLI or API access to target network devices (SSH, console, or

management API with non-modifying privileges)

• - System FIPS 199 security categorization — the impact level (Low, Moderate,

High) determines which 800-53 controls apply as baseline

• - NIST SP 800-53 Rev 5 or CSF 2.0 document for reference (freely available

from csrc.nist.gov)

• - System boundary definition — which devices are within the authorization

boundary

• - Network architecture diagrams showing device roles and trust zones
• Awareness of inherited controls — controls satisfied by the environment

versus controls the device must implement directly

Procedure

Follow this seven-step compliance assessment flow. Steps 2–7 each assess
one NIST 800-53 control family. Within each family, the listed controls are
the subset most relevant to network device configuration — the full family
contains additional controls assessed at the system or organizational level.

Step 1: Assessment Scope and Framework Selection

Define the assessment boundary and select the target framework mapping.

Framework selection: Determine whether mapping to CSF functions
(Identify/Protect/Detect/Respond/Recover) or directly to 800-53 control
families. CSF provides a high-level posture view; 800-53 provides
control-level detail required for FISMA compliance.

Impact level: Identify the system's FIPS 199 categorization:

• - Low — limited adverse effect from loss of confidentiality, integrity,

or availability

• - Moderate — serious adverse effect
• High — severe or catastrophic adverse effect

The impact level determines the control baseline — High-impact systems
require more controls and stricter implementation than Low-impact systems.

System boundary: List all network devices within the authorization
boundary. Record hostname, platform, OS version, and device role (boundary,
core, distribution, access, management).

Step 2: Access Control (AC)

Assess controls governing who and what can access device resources.

AC-2 Account Management: Verify local accounts are documented and
authorized. Check for default, shared, or dormant accounts.

[Cisco] show running-config | include username — list local accounts
and privilege levels.
[JunOS] show configuration system login — review login classes and
user accounts.
[EOS] show running-config section username — list local user accounts.
[PAN-OS] show admins all — list administrative accounts.

AC-3 Access Enforcement: Verify role-based access control separates
read-only, operator, and administrative privileges.

AC-6 Least Privilege: Confirm accounts operate at the minimum privilege
level required. Flag any non-admin account with privilege level 15 (Cisco)
or superuser class (JunOS).

AC-12 Session Termination: Verify idle session timeouts on VTY, console,
and management interfaces.

[Cisco] show running-config | section line — check exec-timeout on
VTY and console lines.
[JunOS] show configuration system login — check idle-timeout value.
[PAN-OS] show config running | match idle-timeout — verify admin
session timeout.

AC-17 Remote Access: Confirm remote management uses encrypted protocols
only (SSH, HTTPS). Verify Telnet and HTTP are disabled. Check source address
restrictions on management access.

[Cisco] show ip ssh — verify SSH version 2, check transport input ssh
on VTY lines.
[EOS] show management ssh — verify SSH configuration and version.

Step 3: Audit and Accountability (AU)

Assess controls governing event logging, log protection, and time accuracy.

AU-2 Audit Events: Verify logging captures security-relevant events
including login attempts, configuration changes, privilege escalation,
and ACL matches.

[Cisco] show logging — verify buffer level and remote syslog servers.
[JunOS] show configuration system syslog — verify log targets and
facility/severity mappings.
[EOS] show logging — check logging hosts and severity levels.
[PAN-OS] show logging-status — verify log forwarding to Panorama
or external SIEM.

AU-3 Content of Audit Records: Confirm log entries include timestamp,
event type, source, outcome (success/failure), and identity of subject.

AU-4 Audit Log Storage: Verify local log buffer capacity and remote
log destination redundancy. Check that log storage does not auto-overwrite
before offload.

AU-6 Audit Review and Analysis: Confirm logs are forwarded to a central
analysis platform (SIEM) where correlation and alerting are possible.

AU-8 Time Stamps: Verify NTP synchronization with authenticated, trusted
time sources. Timestamps must be accurate for log correlation across devices.

[Cisco] show ntp associations and show ntp status — verify NTP
peers and synchronization state.
[JunOS] show ntp associations — verify NTP peer reachability and
stratum.
[PAN-OS] show ntp — verify NTP server configuration and sync status.

Step 4: Configuration Management (CM)

Assess controls governing configuration integrity and change control.

CM-2 Baseline Configuration: Compare running configuration against an
approved baseline. Any drift indicates unauthorized or undocumented changes.

[Cisco] show archive config differences — diff running vs startup
configuration.
[JunOS] show system rollback compare 0 1 — compare current config
with prior version.
[EOS] show running-config diffs — review configuration changes.

CM-3 Configuration Change Control: Verify configuration archive and
rollback capability. Check whether change history is preserved.

CM-6 Configuration Settings: Verify device configuration matches
organizational security configuration checklists. Check for hardened
settings per device role.

CM-7 Least Functionality: Confirm unnecessary services are disabled.

[Cisco] show running-config | include ^service|^no service — verify
disabled services (finger, pad, tcp-small-servers, udp-small-servers,
ip source-route, LLDP/CDP where not needed).
[JunOS] show configuration system services — verify only required
services (SSH, NetConf) are enabled.
[EOS] show running-config | include management|service — check for
unnecessary services.
[PAN-OS] show running management-profile — verify management profiles
expose only required services.

Step 5: Identification and Authentication (IA)

Assess controls governing identity verification and credential management.

IA-2 Identification and Authentication (Organizational Users): Verify
centralized authentication via AAA (TACACS+/RADIUS). Confirm local fallback
accounts exist but are not the primary authentication method.

[Cisco] show running-config | section aaa — verify aaa new-model,
TACACS+/RADIUS server groups, method lists.
[JunOS] show configuration system authentication-order — verify
TACACS+/RADIUS is first in authentication order.
[EOS] show running-config section aaa — verify AAA configuration.

IA-3 Device Identification and Authentication: Verify device-to-device
authentication for routing protocol peers and management connections.
Check 802.1X on access ports where applicable.

IA-5 Authenticator Management: Verify password complexity enforcement,
credential hashing strength, and SSH key management.

[Cisco] show running-config | include username — verify secret 9
(scrypt) or algorithm-type scrypt hashing.
[JunOS] show configuration system login password — check password
requirements.
[PAN-OS] show config running | match password-complexity — verify
complexity profile exists and is enforced.

Check SNMP credentials — SNMP v3 with authentication and encryption (authPriv)
should replace SNMP v1/v2c community strings.

[Cisco] show snmp user — verify SNMPv3 users with authPriv security.
[JunOS] show configuration snmp v3 — verify v3 USM configuration.

Step 6: System and Communications Protection (SC)

Assess controls governing boundary defense and data transmission security.

SC-7 Boundary Protection: Verify ACLs enforce traffic filtering at
network boundaries. Check that infrastructure addresses are protected from
data plane access.

[Cisco] show ip access-lists — review boundary ACLs for explicit deny
and logging.
[JunOS] show configuration firewall family inet — review filter rules
on boundary interfaces.
[EOS] show ip access-lists — review ACL configuration.
[PAN-OS] show running security-policy — review zone-based policies on
boundary zones.

SC-8 Transmission Confidentiality and Integrity: Verify management and
control plane traffic uses encryption in transit (SSH, TLS, IPsec, MACsec).
Check that no cleartext protocols (Telnet, HTTP, SNMPv1/v2c) carry
sensitive data.

SC-10 Network Disconnect: Verify session timeout on inactive management
connections and VPN tunnels. Dead peer detection on IPsec tunnels should
terminate stale sessions.

SC-13 Cryptographic Protection: Audit cryptographic algorithms in use.
Flag deprecated algorithms: DES, 3DES, RC4, MD5 for authentication.
Verify minimum standards (AES-128+, SHA-256+).

[Cisco] show crypto ipsec sa — check encryption and hash algorithms
on active tunnels.
[JunOS] show security ike security-associations — review IKE
proposal algorithms.
[PAN-OS] show vpn ipsec-sa — verify tunnel encryption parameters.

Step 7: System and Information Integrity (SI)

Assess controls governing flaw remediation, monitoring, and software
integrity.

SI-2 Flaw Remediation: Check device OS version against vendor security
advisories. Verify the device is running a version with no known critical
vulnerabilities.

[Cisco] show version — capture IOS/IOS-XE version for advisory check.
[JunOS] show version — capture Junos version for CVE review.
[EOS] show version — capture EOS version.
[PAN-OS] show system info — capture PAN-OS version and content updates.

SI-4 System Monitoring: Verify IDS/IPS, NetFlow, or traffic monitoring
is active on critical segments.

SI-5 Security Alerts and Advisories: Confirm subscription to vendor
security advisory channels (Cisco PSIRT, Juniper, Palo Alto, Arista).

SI-7 Software, Firmware, and Information Integrity: Verify device image
integrity where supported.

[Cisco] show software authenticity running — verify image digital
signature (IOS-XE).
[JunOS] show system storage and show system license — verify system
integrity indicators.
[PAN-OS] show system info | match sw-version — check against known-good
version hash from vendor.

Threshold Tables

Control Gap Severity

Severity	Impact Level	Condition	Examples
Critical	High-impact baseline	Baseline control gap on boundary or critical infrastructure device	AC-2 no account management on internet-facing router, SC-7 no boundary ACLs, IA-2 no authentication on management access
High

Moderate-impact baseline | Required baseline control missing or partially implemented | AU-2 no security event logging, IA-2 no MFA for privileged access, SC-8 cleartext management protocols in use | | Medium | Low-impact baseline | Baseline control gap with limited exposure | CM-7 unnecessary services enabled on internal device, AU-8 NTP not authenticated, AC-12 no idle session timeout | | Low | Enhancement gap | Control beyond required baseline not implemented | Advanced NetFlow analytics, MACsec on internal links, granular RBAC beyond baseline requirement |

Compliance Posture by Impact Level

Score Range	Posture	Guidance
90–100%	Satisfactory	Address residual gaps in next assessment cycle
70–89%

Conditional | Develop POA&M for remaining gaps, prioritize High-impact families | | 50–69% | Deficient | Immediate remediation plan required, escalate to ISSO/AO | | <50% | Unsatisfactory | System may not meet authorization threshold, consider risk acceptance or isolation |

Decision Trees

Control Gap Remediation Priority

CODEBLOCK0

Report Template

CODEBLOCK1

Troubleshooting

Mapping CSF Subcategories to 800-53 Controls

CSF subcategories (e.g., PR.AC-1, DE.CM-1) map to multiple 800-53 controls.
Use the NIST SP 800-53 Rev 5 crosswalk (in the control catalog appendices)
to translate between frameworks. When assessing CSF compliance, aggregate
800-53 control results per CSF subcategory — a single control failure does
not necessarily mean the subcategory is fully non-compliant.

Inherited Controls vs Device-Specific Controls

In shared infrastructure, some controls are inherited from the hosting
environment (e.g., PE controls from a data center, PS controls from the
organization). Distinguish between controls the device implements directly
and controls inherited from external providers. Document inherited controls
with the responsible entity and verification method.

Multi-Device Scope Aggregation

When multiple devices share an authorization boundary, aggregate findings at
the system level. A control is only fully satisfied when all in-scope devices
implement it — one device failing AC-2 means the system has an AC-2 gap.
Roll up device-level results into the system POA&M.

Rev 4 vs Rev 5 Differences

NIST 800-53 Rev 5 (2020) restructured controls from Rev 4: controls are no
longer scoped to federal systems only, the Privacy (PT) family was added,
and many controls were consolidated. When working with Rev 4 baselines, use
the NIST-published crosswalk to map Rev 4 IDs to Rev 5 equivalents. Key
network-relevant changes: AC-2 and AU-2 gained enhancements, SC-7 expanded.

System Categorization Uncertainty

If the system's FIPS 199 categorization is unknown or disputed, the assessor
cannot determine the correct control baseline. Escalate to the system owner
or Information System Security Officer (ISSO) to confirm categorization
before proceeding. Assessing against the wrong impact level produces either
false confidence (Low baseline applied to a High system) or unnecessary
effort (High baseline applied to a Low system).