KRIs for network security

The KRIs in this domain measure the operational health of your network security controls, not the architecture intent (covered in the Security Architecture KRI file), but the runtime state: whether network devices are patched, whether firewall rules are reviewed, whether traffic is being seen and analyzed, whether remote access is actually controlled, and whether the network is configured to contain rather than amplify an incident.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Network device firmware and configuration currency

What to measure. Percentage of network infrastructure devices, firewalls, routers, switches, VPN concentrators, wireless access points, load balancers, running current or N-1 supported firmware versions, and the percentage compliant with organizational hardening baselines (CIS Benchmarks or vendor hardening guides for the device type).

Why it matters. Network device vulnerabilities are among the most exploited in enterprise environments, and among the most consistently deferred. The Fortinet FortiGate, Ivanti Connect Secure, Palo Alto PAN-OS, and Cisco ASA vulnerabilities of the last three years were all actively exploited within days of disclosure, frequently against devices running firmware versions that vendors had patched weeks or months earlier. Network devices are patched less frequently than servers because maintenance windows require traffic impact, upgrade testing is operationally complex, and "if it's working, don't touch it" is the default posture. That default is what nation-state actors and ransomware operators count on.

• Network management platforms (SolarWinds, PRTG, LibreNMS, Auvik, Cisco DNA Center): device inventory with firmware versions; compare against vendor current release
• Vendor security advisories: Fortinet PSIRT, Palo Alto Networks Security Advisories, Cisco Security Advisories, Juniper SIRT, subscribe for devices in inventory
• CISA KEV: cross-reference firmware versions against KEV catalog entries for network device CVEs, these are confirmed actively exploited
• Configuration management database (CMDB): device inventory cross-referenced against firmware version and patch history
• Network configuration management (Rancid, Oxidized, Cisco NSO, Infrahub): configuration snapshots that include version strings

How to calculate.

• Firmware currency: (Network devices on current or N-1 firmware) ÷ (total network devices) × 100
• Hardening compliance: (Network devices passing applicable CIS Benchmark or organizational hardening baseline) ÷ (total network devices) × 100
• KEV exposure: count of network devices running firmware with CVEs in the CISA KEV catalog, should be zero

Status	Criteria
Green	>95% firmware currency; >90% hardening compliance; zero KEV-affected devices; firmware review cadence defined per device class; vendor advisory subscription active
Amber	85–94% currency; or known KEV-affected devices with remediation plan in place; or hardening compliance not measured
Red	<85% currency; or any KEV-affected internet-facing device (VPN concentrator, firewall, load balancer) without remediation; or network device patching on ad-hoc rather than scheduled cadence; or no firmware inventory

2. Firewall rule hygiene score

What to measure. Percentage of firewall rules that are permissive (any/any source or destination), missing logging, without a documented owner, or beyond their documented expiry date, measured across all production firewalls including cloud security groups, network ACLs, and on-premises firewalls.

Why it matters. Firewall rule decay is one of the most reliable indicators of a security program that has prioritized availability over control. Rules accumulate over years: the rule for the vendor who left in 2019 is still there. The temporary rule for the penetration test is still there. The any/any rule that "we'll clean up next week" is still there, six years later. Each unreviewed rule is an unintentional permission. A firewall with a 30% permissive rule rate isn't doing 30% of its job, those permissive rules are doing 100% of nothing and may be doing active harm by creating unexpected access paths. Cloud security groups compound the problem at scale: a medium-sized AWS environment can have tens of thousands of security group rules, most of which nobody has reviewed.

• Firewall management platforms (Algosec, FireMon, Tufin, Skybox): automated rule analysis, any/any detection, logging gaps, owner assignment, shadow rules, redundant rules
• Cloud security groups: AWS security group audit (aws ec2 describe-security-groups filtered for 0.0.0.0/0 ingress); Azure NSG audit; GCP firewall rules audit
• Manual review logs: firewall rule review completion records, which rulesets were reviewed in the last 12 months
• Change management: firewall rule changes with documented owner and business justification, change ticket cross-reference

How to calculate. (Firewall rules flagged as: any/any OR no logging OR no documented owner OR past expiry) ÷ (total firewall rules) × 100, lower is better Also: percentage of firewall rulesets reviewed by a human in the past 12 months

Status	Criteria
Green	<3% of rules flagged as permissive/undocumented; all flagged rules under active review; firewall ruleset reviewed annually at minimum; cloud security groups audited continuously by CSPM
Amber	3–10% flagged; or rulesets reviewed but flagged rules not actively remediated; or cloud security groups not included in hygiene analysis
Red	>10% flagged; or any any/any rules on segments containing sensitive data or internet-facing systems; or firewall rulesets not reviewed in >24 months; or no firewall rule management tooling

3. Remote access security controls

What to measure. Comprehensive posture of remote access infrastructure, percentage of VPN and zero-trust network access (ZTNA) sessions authenticated with phishing-resistant or strong MFA, device compliance enforcement at access grant time, split-tunnel configuration that routes sensitive traffic through security controls, and remote access software patch currency.

Why it matters. Remote access infrastructure is the highest-exploited attack surface category in enterprise networks. VPN appliance vulnerabilities (Ivanti, Fortinet, Pulse Secure, Cisco ASA) are exploited within days of disclosure at massive scale. Credential stuffing against VPN portals that lack MFA is a commodity attack. Split tunneling that excludes corporate security inspection creates an unmonitored path from remote endpoints to the internet that bypasses your DLP, web filtering, and threat detection. The organization that upgraded its VPN to handle a remote workforce without simultaneously hardening it with MFA and device health checks made a security debt decision that hasn't been paid yet.

• VPN platform (Cisco Anyconnect/ASA, Fortinet FortiClient, Palo Alto GlobalProtect, Ivanti Connect Secure, Zscaler Private Access): session logs with authentication method, device ID, authentication success/failure counts
• Identity provider: MFA method used per remote access session, distinguish SMS (phishable) from hardware token / FIDO2 (phishing-resistant)
• Conditional Access (Entra ID, Okta): device compliance requirement at remote access, is device health checked before granting VPN or ZTNA access?
• VPN firmware version: compare against vendor current release and CISA KEV, internet-facing VPN appliances with unpatched CVEs are a critical risk
• Split tunnel configuration audit: traffic routing tables, which traffic goes through the corporate inspection path vs. direct to internet

How to calculate.

• MFA coverage: (Remote access sessions with MFA) ÷ (total remote access sessions) × 100, should be 100%
• Device compliance enforcement: (Remote sessions with device health verified before access grant) ÷ (total sessions) × 100
• VPN firmware currency: (Internet-facing remote access appliances on current or N-1 firmware) ÷ (total appliances) × 100

Status	Criteria
Green	100% of sessions with MFA; device compliance verified before access; internet-facing VPN/ZTNA appliances on current firmware; no KEV-affected appliances; ZTNA or conditional access for sensitive application access rather than full network access
Amber	95–99% MFA coverage with documented exceptions; or device compliance not enforced at access time; or VPN appliances on N-2 firmware (not current or N-1)
Red	<95% MFA; or any VPN session without MFA for privileged users; or KEV-affected internet-facing VPN without emergency patch or remediation; or split tunnel routing all traffic outside corporate inspection

4. Network detection and response (NDR) coverage

What to measure. Percentage of network segments, including on-premises segments, cloud VPCs/VNets, east-west data center traffic, and OT network boundaries, with active network traffic analysis providing anomaly detection, threat hunting capability, and lateral movement visibility.

Why it matters. Firewalls control what should be allowed. NDR detects what's actually happening. Once an attacker is inside a network segment, they can move laterally between systems without crossing a firewall rule, particularly in flat networks and environments where east-west inspection is absent. NDR provides visibility into that lateral movement, beaconing behavior, unusual data transfer volumes, and protocol anomalies that host-based tools may miss. Most organizations have strong north-south monitoring (internet-facing traffic) and significant blind spots in east-west monitoring (segment-to-segment, server-to-server). That blind spot is where ransomware spends most of its operating time before detonation.

• NDR platforms (Darktrace, ExtraHop, Vectra AI, Corelight, Cisco Stealthwatch/Secure Network Analytics): coverage map showing segments with traffic analysis active
• IDS/IPS (Snort, Suricata, Cisco Firepower, Palo Alto Threat Prevention): sensor placement and coverage by segment
• Cloud-native flow analysis: AWS VPC Flow Logs + Traffic Mirroring; Azure NSG Flow Logs + Network Watcher; GCP VPC Flow Logs, coverage per VPC/VNet
• SIEM: network-sourced event volume per segment, segments with no network-layer events are monitoring blind spots
• Packet capture infrastructure: TAPs, span ports, and RSPAN configurations, which segments have traffic copied to analysis infrastructure

How to calculate. (Network segments with active NDR/IDS coverage producing alerts and logs) ÷ (total network segments) × 100 Segment the metric: internet-facing zones, internal server zones, cloud VPCs, OT boundary, remote access zones

Status	Criteria
Green	>90% of segments with active NDR coverage; east-west traffic analyzed within data center segments; cloud VPC flow logs enabled and ingested into SIEM; OT boundary monitored (passive analysis only for OT); NDR alerts integrated into SOC workflow
Amber	70–89% coverage; or strong north-south monitoring but east-west blind spots; or cloud VPC flow logs enabled but not ingested; or NDR alerts generated but not reviewed
Red	<70%; or no NDR/IDS coverage; or significant segments (cloud, internal servers) with no network monitoring; or perimeter-only monitoring with no internal visibility

5. Network traffic flow log coverage and retention

What to measure. Percentage of network segments and cloud environments where network flow logs (NetFlow, IPFIX, IPFIX, sFlow, VPC Flow Logs, NSG Flow Logs) are being collected, centralized, and retained for the minimum period required for threat hunting and incident investigation, with specific attention to coverage of internet egress points, cloud-to-on-premises interconnects, and data center core switches.

Why it matters. Flow logs are the forensic record of network behavior. They answer the investigative questions that follow every incident: what did this compromised host connect to? How much data left the network? What other internal systems did the attacker reach? Organizations that don't have flow logs covering the relevant network paths during an incident discover, in the middle of the investigation, that weeks of attacker activity happened in a logging blind spot. Flow logs also enable retrospective threat hunting, searching historical network behavior for indicators that were discovered after the fact. No flow log retention means no retrospective hunting capability.

• Network management platform: NetFlow/IPFIX export configuration per router, switch, and firewall, which devices are exporting flows vs. not
• Flow collection platform (Elastic, Splunk Stream, ntopng, Kentik, SolarWinds NTA): ingestion source inventory and collection health
• Cloud flow logs: aws ec2 describe-flow-logs for VPC coverage; Azure Network Watcher flow log status per NSG; GCP VPC Flow Logs enablement per subnet
• SIEM: network flow data sources, ingestion volume per source per day; gaps in expected flow volume signal collection failures
• Retention configuration: flow data retention policy in SIEM/storage, minimum 90 days for threat hunting; 12 months for regulatory investigations

How to calculate.

• Coverage: (Network segments and cloud VPCs with flow log collection enabled and flowing to central collection) ÷ (total segments and VPCs) × 100
• Retention compliance: (Flow log sources with retention meeting defined minimum) ÷ (total flow log sources) × 100

Status	Criteria
Green	>95% segment coverage; flow logs centralized in SIEM; minimum 90-day retention; internet egress, data center core, and cloud-to-on-premises interconnects at 100% coverage; flow log gaps monitored with alerting
Amber	80–94% coverage; or flow logs collected but not centralized; or retention <90 days; or cloud environments excluded from flow logging
Red	<80%; or no centralized flow log collection; or critical egress points without flow logging; or retention <30 days (insufficient for most incident investigations)

6. Secure network management protocol compliance

What to measure. Percentage of network devices managed exclusively through encrypted, authenticated management protocols, specifically: SSH (not Telnet), HTTPS (not HTTP), SNMPv3 (not SNMPv1/v2c), and out-of-band management where applicable, and whether management interfaces are isolated from production networks.

Why it matters. Telnet, HTTP, and SNMPv1/v2c transmit credentials and configuration data in cleartext. Any attacker with a foothold on the same network segment as a managed network device, through lateral movement, a compromised server, or an uncontrolled access path, can capture management credentials with a passive packet capture. Network device takeover through captured management credentials is a high-capability attack that becomes trivial when cleartext management protocols are in use. SNMPv2c community strings harvested from network traffic have been used in multiple documented incidents to exfiltrate network topology information used in subsequent attacks.

• Network configuration management (Rancid, Oxidized, Cisco NSO): parse device configurations for management protocol settings, transport input on Cisco IOS (should not include telnet); HTTP server status (no ip http server); SNMP version in use
• Network scanning: scan management IP ranges for open TCP 23 (Telnet), TCP 80 (HTTP management), UDP 161 (SNMP), responsive services identify insecure management
• Firewall/ACL audit: management access control lists, are management protocols restricted to a dedicated management network, or accessible from any segment?
• Out-of-band management: dedicated management network / console server coverage, what percentage of critical network devices can be managed without using the production network

How to calculate.

• Protocol compliance: (Network devices with only encrypted/authenticated management protocols enabled) ÷ (total network devices) × 100
• Management isolation: (Critical network devices with management interface on isolated management network) ÷ (total critical network devices) × 100

Status	Criteria
Green	100% SSH/HTTPS/SNMPv3, zero Telnet, HTTP, or SNMPv1/v2c on any managed device; management interfaces restricted to dedicated management VLAN/network; out-of-band management for critical devices
Amber	>95% compliant with known legacy exceptions in remediation; or management interfaces not isolated (management on production network but access-controlled via ACL)
Red	Any Telnet or SNMPv1/v2c in active use on managed devices; or management interfaces accessible from production segments without dedicated ACL; or cleartext protocol compliance not inventoried

7. Network access control (NAC) and 802.1x coverage

What to measure. Percentage of wired and wireless network ports enforcing 802.1x port-based access control or equivalent NAC policy, requiring device authentication before network access is granted, with automated quarantine for non-authenticating or non-compliant devices.

Why it matters. A network without 802.1x enforcement grants full network access to any device physically connected to a switch port or connecting to a wireless network. That includes a contractor laptop, an attacker with physical access, an IoT device plugged into a conference room port, and an employee's personal device bypassing the VPN. 802.1x provides the enforcement mechanism that makes every physical connection point a security boundary rather than an open door. Most organizations have 802.1x configured for wireless but not for wired ethernet, which is where the highest-risk connections (server rooms, data center ports, physical security systems) occur.

• 802.1x/NAC platform (Cisco ISE, Aruba ClearPass, Microsoft NPS, Forescout): authentication coverage report, ports with 802.1x vs. total active ports
• Switch configuration: show authentication sessions (Cisco IOS) or equivalent, authenticated vs. unauthenticated active sessions
• Wireless infrastructure: RADIUS authentication configuration per SSID, corporate SSID should enforce 802.1x, not pre-shared key
• Network discovery: devices on the network without valid authentication, detected through NAC posture assessment
• DHCP logs: devices receiving IP addresses from non-802.1x-authenticated ports, proxy for non-compliant access

How to calculate.

• Wired 802.1x coverage: (Wired ports with 802.1x enforced) ÷ (total active wired ports) × 100
• Wireless authentication: (Corporate SSIDs using 802.1x/EAP) ÷ (total corporate SSIDs) × 100, pre-shared key corporate SSIDs = 0%

Status	Criteria
Green	>90% of wired ports with 802.1x enforced; 100% of corporate SSIDs using 802.1x; automatic quarantine for failed authentication; guest SSID isolated from corporate network
Amber	802.1x on wireless but not wired; or wired enforcement in data center but not in office spaces; or quarantine not automatic
Red	Corporate wireless using pre-shared key; or no 802.1x anywhere; or 802.1x configured in monitor mode only (not enforcing); or no visibility into unauthenticated network connections

8. External attack surface management (Network layer)

What to measure. The delta between internet-facing services known to and approved by the security team versus services actually reachable from the internet, measured through continuous external scanning, including unauthorized open ports, expired or misconfigured services, and internet-facing management interfaces.

Why it matters. Shadow external exposure is the network-layer equivalent of shadow IT. VPN portals opened by network engineers during remote work expansion. Development environments exposed for "just this sprint." A firewall rule change made during an outage that was never reverted. Each represents an internet-facing service the security team doesn't know about, hasn't assessed, and hasn't protected, but attackers are continuously scanning for. Continuous external attack surface monitoring detects these deviations from the approved baseline in hours rather than after a breach.

• Attack surface management (Censys, Shodan, Tenable Attack Surface Management, CyCognito, Runzero): continuous external scan results, open ports, service fingerprints, TLS configuration, certificate status
• Internal network scan: cross-reference with authorized external service inventory, any service in external scan not in approved inventory is a deviation
• Firewall change log: changes that add inbound permit rules without security review, leading indicator of exposure before external scanner detects it
• Cloud egress: cloud provider internet-facing resources (internet-facing EC2 instances, public-IP load balancers, internet-facing database endpoints), frequently outside the scope of traditional external scan tools

How to calculate.

• Attack surface delta: (Internet-facing services detected by external scanning) − (services in approved external service inventory) = shadow exposure count
• Acceptable target: zero delta; any positive delta is a finding requiring immediate review
• Time-to-detection: hours from external exposure creation (firewall rule change, cloud instance launch) to detection by external scanning

Status	Criteria
Green	External scan continuous or daily; delta against approved inventory reviewed within 24 hours of new exposure; cloud-based exposure included in scan scope; time-to-detection <4 hours for new internet-facing services
Amber	Weekly external scan; or delta reviewed within 72 hours; or cloud exposure not included; or approved inventory stale (not updated when authorized changes are made)
Red	No continuous external scanning; or delta not reviewed; or unauthorized internet-facing services discovered during incident investigation rather than proactively; or no approved service inventory to compare against

Deriving these KRIs by source type

From Network Configuration Management (Rancid, Oxidized, Cisco NSO)

git -C /var/lib/oxidized/configs log --oneline | head -20

grep -r "^Version\|^Cisco IOS" /var/lib/oxidized/configs/ | \
  grep -oP "Version \K[\d.]+" | sort | uniq -c

grep -r "Cisco Internetwork Operating System Software" /var/rancid/configs/ | \
  grep -oP "Version \K[^,]+" | sort | uniq -c

grep "^#config-version" /path/to/fortigate-backup.conf | \
  grep -oP "FGT.*-v\K[\d.]+"

grep -r "transport input" /var/lib/oxidized/configs/ | \
  grep -v "ssh" | grep "telnet\|all\|none"

grep -r "ip http server$" /var/lib/oxidized/configs/

grep -r "snmp-server community" /var/lib/oxidized/configs/ | \
  grep -v "snmp-server group\|snmp-server user"  # v1/v2c uses community strings

grep -r "snmp-server group.*v3\|snmp-server user.*v3" /var/lib/oxidized/configs/

From Firewall Management Platforms (Algosec, FireMon, Tufin)

curl -u "user:pass" -X POST \
  "https://algosec-server/algosec/rest/latest/queries/analyze" \
  -H "Content-Type: application/json" \
  -d '{"query": {"type": "rule_analysis", "rule_filter": "any_any_rules"}}'

curl -H "X-FM-Auth-Token: $FM_TOKEN" \
  "https://firemon-server/securitymanager/api/domain/1/rule/search?ruleStatus=UNCERTIFIED" | \
  jq '.results | length'

show running security-policy | match "from any to any"

From AWS (Network Controls)

aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName,Description]' \
  --output table

aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`] && (FromPort==`22` || FromPort==`3389` || FromPort==`23`)]].[GroupId,GroupName]' \
  --output table

aws ec2 describe-flow-logs \
  --query 'FlowLogs[*].[ResourceId,FlowLogStatus,TrafficType,LogDestinationType]' \
  --output table

aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text | tr '\t' '\n' > all_vpcs.txt
aws ec2 describe-flow-logs --query 'FlowLogs[*].ResourceId' --output text | tr '\t' '\n' | sort > logged_vpcs.txt
comm -23 <(sort all_vpcs.txt) logged_vpcs.txt  # VPCs without flow logs

From Azure (Network Security Groups, Network Watcher)

az network nsg list --query '[*].{Name:name, RG:resourceGroup}' -o tsv | \
  while read name rg; do
    az network nsg rule list --nsg-name "$name" --resource-group "$rg" \
      --query '[?access==`Allow` && direction==`Inbound` && (sourceAddressPrefix==`*` || sourceAddressPrefix==`Any`)].[name, destinationPortRange]' \
      -o tsv | while read rule port; do echo "$name/$rule: port $port"; done
  done

az network watcher flow-log list --location eastus \
  --query '[*].{NSG:targetResourceId, Enabled:enabled, RetentionDays:retentionPolicy.days}' \
  -o table

From Cisco ISE (802.1x / NAC)

curl -k -u "admin:password" -H "Accept: application/json" \
  "https://ise-server/ers/config/activesessions" | \
  jq '.SearchResult.resources | length'

curl -k -u "admin:password" -H "Accept: application/json" \
  "https://ise-server/ers/config/authorizationfailure" | \
  jq '.SearchResult.total'

From External Attack Surface Management (Censys, Shodan)

curl -H "Censys-Api-Id: $CENSYS_ID" -H "Censys-Api-Secret: $CENSYS_SECRET" \
  "https://search.censys.io/api/v2/hosts/search?q=autonomous_system.asn:$YOUR_ASN" | \
  jq '.result.hits[] | {ip: .ip, services: [.services[] | {port: .port, service: .service_name}]}'

curl "https://api.shodan.io/shodan/host/search?key=$SHODAN_KEY&query=net:10.0.0.0/8" | \
  jq '.matches[] | {ip: .ip_str, port: .port, product: .product, version: .version}'

python3 << 'PYEOF'
import json

with open('censys_results.json') as f:
    external_scan = json.load(f)

with open('approved_services.json') as f:
    approved = {(s['ip'], s['port']) for s in json.load(f)}

shadow_exposure = [
    s for s in external_scan
    if (s['ip'], s['port']) not in approved
]

print(f"Shadow exposure count: {len(shadow_exposure)}")
for s in shadow_exposure:
    print(f"  UNAUTHORIZED: {s['ip']}:{s['port']} ({s.get('service', 'unknown')})")
PYEOF

From SIEM (Network Monitoring Blind Spot Detection)

index=network_flows earliest=-24h
| stats count by src_network_segment
| join type=outer src_network_segment 
    [| inputlookup network_segments.csv | rename segment as src_network_segment | eval expected=1]
| where isnull(count) OR count < 100
| table src_network_segment, count, expected

NetworkMonitor_CL
| where TimeGenerated > ago(24h)
| summarize FlowCount=count() by SourceNetwork
| join kind=rightouter (
    externaldata(NetworkSegment: string) [@'https://your-storage/network-segments.csv']
    | project NetworkSegment
) on $left.SourceNetwork == $right.NetworkSegment
| where isnull(FlowCount)
| project NetworkSegment, Status="No Flow Data - Blind Spot"