CI Fortify and the New Doctrine of Cyber Resilience: Why Prevention Is No Longer Enough + Video

Listen to this Post

🐢▶️ Listen🚀

Introduction

At Black Hat 2026, a panel of senior cyber officials from the United States, United Kingdom, and Canada delivered a stark message to critical infrastructure operators: stop chasing AI-hacking headlines and fix the resilience basics. Acting US Federal CISO Michael Duffy put it bluntly: “Things will go down”. The message wasn’t fatalism—it was a call for a fundamental mindset shift from pure prevention to survivability. The cybersecurity community needs “a new risk calculus for what it means to operate in a contested environment,” Duffy said. This paradigm shift is crystallized in CISA’s newly launched CI Fortify initiative—a doctrine change demanding that critical infrastructure operators plan not just to prevent attacks, but to survive and continue essential operations when networks are compromised and connectivity is severed.

Learning Objectives

• Identify and prioritize minimum viable systems required to sustain essential services during a geopolitical cyber crisis
• Implement isolation and recovery capabilities that allow operational technology (OT) to function autonomously without internet or third-party connectivity
• Develop and rehearse manual fallback procedures and clean restore processes for critical systems under realistic pressure scenarios

You Should Know

1. The Minimum Viable Mindset: Defining Your “Thin Red Line”

The most concrete idea to emerge from the Black Hat panel was CI Fortify—a program DHS is adapting from Australia and echoing through Canada’s “Minimum Vital Canada” initiative. The core question, as articulated by CISA Acting Director Nick Andersen, is: “What is that thin red line of what we absolutely need during our worst times in order to be successful?”

CI Fortify requires critical infrastructure operators to identify the bare minimum systems needed to keep essential services running—and then actually rehearse operating on that minimum. DHS’s Joseph Alm framed it as: “Assume that you’re compromised. How do you make sure critical services continue?”

Step-by-step guide to defining your minimum viable systems:

1. Inventory all OT assets and enabling systems – Document every programmable logic controller (PLC), human-machine interface (HMI), SCADA server, and distributed control system (DCS) controller.

2. Map critical customers and service delivery targets – Identify which customers (military infrastructure, lifeline services, public safety) must receive service and set specific delivery targets.

3. Determine minimum operating requirements – For each critical service, define the absolute minimum resources, staff, and systems required to sustain operations.

4. Map upstream dependencies – Document dependencies on chemical suppliers, fuel deliveries, power grids, water sources, and telecommunications providers.

5. Establish Recovery Time Objectives (RTOs) – For each minimum viable system, document acceptable downtime thresholds.

Linux/Windows command for asset discovery:

 Linux – Scan for OT/ICS devices on a network segment
nmap -sS -p 44818,2222,502,102,2404,4840 192.168.1.0/24 -oG ot_asset_scan.txt

Windows – PowerShell asset inventory
Get-1etIPAddress | Where-Object {$_.InterfaceAlias -like "Ethernet"} | 
Select-Object IPAddress, InterfaceAlias | Export-Csv -Path ot_assets.csv

1. Isolation: Preparing to Operate in a Degraded Communications Environment

CI Fortify’s first pillar is isolation—proactively disconnecting from third-party and business networks to prevent OT cyber impacts and sustain essential operations in a degraded communications environment. The goal is not complete shutdown; it’s ensuring essential service delivery continues for weeks to months while isolated.

CISA’s guidance, published jointly with Australia’s ACSC, the FBI, the UK’s NCSC, and the Canadian Centre for Cyber Security, outlines a graduated isolation approach.

Step-by-step guide to implementing isolation capabilities:

1. Identify vital OT and supporting infrastructure – Determine which systems must continue operating in isolation to meet your minimum service delivery targets.

2. Build separation points – Establish network segmentation between OT and IT/business networks. Implement unidirectional gateways (data diodes) where possible to enforce complete network non-routability.

3. Harden OT boundaries – Remove unnecessary connections, disable unused ports and services, and implement allow-listing for all OT communications.

4. Test graduated isolation scenarios – Start with partial isolation (disconnecting non-critical third-party connections) and progress to full isolation (complete internet and telecom disconnection).

5. Document isolation procedures – Create runbooks specifying exactly when and how to initiate isolation, including triggers and communication protocols.

Network isolation verification commands:

 Linux – Verify firewall rules blocking unauthorized outbound connections
iptables -L -1 -v | grep -E "DROP|REJECT"

Linux – Test outbound connectivity from OT segment
curl --connect-timeout 5 -m 10 -I https://8.8.8.8 2>&1 | grep -q "Connected" || 
echo "Isolation successful – no outbound internet"

Windows – Check active connections from OT systems
netstat -an | findstr "ESTABLISHED" | findstr /v "192.168."  Look for non-local connections

3. Recovery: Restoring Vital Systems When Isolation Fails

The second pillar of CI Fortify is recovery—documenting systems, backing up critical files, and practicing the replacement of systems or the transition to manual operations in case isolation fails and components are rendered inoperable.

CISA emphasizes that recovery is not just about having backups; it’s about rehearsing clean restores under pressure. Knowing your minimum viable systems on paper is not the same as having tested a clean restore of exactly those systems.

Step-by-step guide to building recovery capabilities:

1. Maintain offline, immutable backups – Keep trusted, offline backups of firmware, configuration files, and critical processes. Ensure backups are air-gapped and cannot be encrypted by ransomware.

2. Document system configurations – Create detailed documentation for every vital system, including network configurations, software versions, patch levels, and custom settings.

3. Pre-position spare components – Identify and stock critical replacement hardware (PLCs, HMIs, servers, network switches) that would be needed for rapid rebuild.

4. Develop manual fallback procedures – Document step-by-step manual operations that can replace automated digital processes when systems fail.

5. Test recovery under realistic conditions – Schedule regular recovery drills that simulate actual attack scenarios, including complete system rebuilds from offline backups.

Backup and recovery verification commands:

 Linux – Verify integrity of offline backups
sha256sum -c backup_manifest.sha256 /mnt/offline_backup/

Linux – Test restore of critical configuration files
tar -xzf /mnt/offline_backup/ot_configs.tar.gz -C /tmp/test_restore/ && 
diff -r /etc/ /tmp/test_restore/etc/ || echo "Restore validation failed"

Windows – Verify backup integrity using PowerShell
Get-FileHash -Path "E:\OfflineBackup\ot_system.vhdx" -Algorithm SHA256 | 
Compare-Object -ReferenceObject (Get-Content backup_hash.txt)

4. Dependency Mapping: Understanding What Breaks First

One of the most underappreciated aspects of CI Fortify is the requirement to map cross-sector dependencies. Water utilities depend on power; power grids depend on fuel deliveries; fuel depends on transportation; transportation depends on communications. Understanding these cascading dependencies is essential to planning for isolation.

Step-by-step guide to dependency mapping:

1. Map OT connectivity and dependencies – Start with CISA’s core question: how long can you operate without external connectivity?

2. Identify critical customers and upstream dependencies – Document every third-party service, vendor, and upstream provider your minimum viable systems rely on.

3. Build a dependency matrix – Create a tiered map showing what each system depends on and what breaks first when dependencies fail.

4. Assess vendor security posture – Evaluate whether your OT vendors can support isolation scenarios and provide factory acceptance test (FAT) procedures for isolation validation.

5. Address licensing and communication dependencies – Document how licensing servers, business network connections, and cloud services would be affected by isolation.

Dependency mapping script (Linux):

!/bin/bash
 Dependency mapping script – identify critical external connections
echo "Critical System,Dependency Type,External Endpoint,Port,Impact if Lost" > dep_map.csv

ss -tulpn | grep ESTAB | awk '{print $5,$6}' | while read -r line; do
port=$(echo $line | awk '{print $2}' | cut -d: -f2)
dest=$(echo $line | awk '{print $1}')
echo "OT-System-01,Network,$dest,$port,Critical service interruption"
done >> dep_map.csv

5. Testing and Rehearsal: The Missing Piece

As Jack McMichael noted in his Black Hat post, “That’s a rehearsal problem as much as a technology one.” Knowing your minimum viable systems on paper is not the same as having tested a clean restore under pressure. CISA explicitly requires operators to practice local and manual operations as part of their recovery planning.

Step-by-step guide to testing and rehearsal:

1. Schedule regular isolation exercises – Run tabletop exercises and live drills that simulate complete loss of internet and telecommunications.

2. Test manual fallback procedures – Verify that staff can execute manual operations without digital systems, using printed runbooks and paper-based workflows.

3. Validate recovery procedures – Perform full system rebuilds from offline backups in a test environment, measuring time to restore.

4. Document lessons learned – After each exercise, update procedures based on what failed or took too long.

5. Track quantifiable resilience outcomes – Measure whether critical infrastructure can sustain minimum service delivery requirements during simulated crises.

Exercise validation checklist:

 Linux – Pre-exercise validation script
echo "=== CI Fortify Readiness Check ==="
 Check backup integrity
find /mnt/offline_backup/ -type f -mtime +30 -exec echo "WARNING: Backup older than 30 days: {}" \;
 Check network isolation rules
iptables -L -1 | grep -q "DROP.any/any" || echo "WARNING: Default drop rule missing"
 Check manual runbook availability
find /opt/runbooks/ -1ame ".pdf" -mtime -90 | wc -l | 
awk '{if ($1 < 10) print "WARNING: Fewer than 10 updated runbooks found"}'
echo "=== Check Complete ==="

What Undercode Say

• Prevention is dead; survivability is the new imperative. The Black Hat 2026 panel and CI Fortify initiative mark a definitive shift from “how do we stop attacks” to “how do we keep running when attacks succeed.” Organizations still investing exclusively in prevention are already behind.

• Resilience requires rehearsal, not just documentation. The gap between having a plan on paper and successfully executing it under pressure is where most organizations fail. CI Fortify’s emphasis on testing, drilling, and rehearsing is not optional—it’s the core of the doctrine. As DHS’s Joseph Alm put it, resilience means “intentionally spending resources on harm reduction, not just risk reduction”.

The CI Fortify initiative represents a strategic inflection point for any CISO or security engineering leader in critical infrastructure. CISA has already begun targeted compliance assessments under a pilot phase, with results expected to drive tighter regulatory requirements throughout 2026. Organizations not prepared will fail federal contracts or lose licenses. This is not a return to 1990s air-gapped systems—it’s resilient hybrid architecture that can operate autonomously but sync back when connectivity returns, which is technically harder and requires architectural redesign, not just firewall rules.

Prediction

• +1 CI Fortify will become the de facto global standard for critical infrastructure resilience within 24 months, with Five Eyes nations and NATO allies adopting similar frameworks.

• +1 Organizations that begin CI Fortify implementation now will gain significant competitive advantage in federal contracting and regulatory compliance, while laggards face operational and financial penalties.

• -1 The majority of critical infrastructure operators currently lack the dependency maps, offline backups, and tested manual procedures required by CI Fortify—creating a dangerous window of vulnerability as adversaries continue to pre-position inside OT networks.

• -1 Vendor lock-in and supply chain dependencies will emerge as major obstacles, as many OT vendors do not yet support isolation scenarios or provide the documentation required for CI Fortify compliance.

• +1 The “Minimum Vital” approach will expand beyond critical infrastructure to enterprise IT, with organizations adopting minimum viable business (MVB) frameworks for cyber resilience across all sectors.

The message from Black Hat 2026 is clear: the era of prevention-only cybersecurity is over. The question is no longer if your systems will be compromised, but whether you can keep the lights on when they are. CI Fortify provides the roadmap—now it’s time to rehearse.

▶️ Related Video (78% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: https://lnkd.in/p/eCxhD4QB – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky