The Infra Team's CyberDrill Guide: Technical Readiness Beyond Tabletop

CISOs run the tabletop. Auditors read the report. But when a real incident hits at 2 AM, it is the infrastructure team that runs the actual commands. This guide covers what infra teams must test, prove, and fix — before a drill makes it a finding.

Why Infra Teams Are the Bottleneck in Every Drill

Tabletop exercises are designed by security teams and facilitated for management. The infrastructure team typically attends, agrees to action items, and then discovers during the next real incident that none of the technical sequencing was actually tested. The containment took 4 hours because the isolation procedure was never rehearsed. The DR failover took 90 minutes because the runbook hadn't been updated since last year's infrastructure migration. The volatile forensic evidence was gone because nobody had practised the RAM capture sequence before isolating the compromised host.

The infra team's obligation in a CyberDrill is not passive. It is to test, document, and prove technical readiness against three hard requirements: CERT-In's 13-log-source retention obligation, the sub-6-hour isolation and evidence preservation sequence, and the DR invocation RTO that appears in your SEBI CSCRF posture.

The Three Technical Tests That Must Happen in Every Drill

The first is log availability and extraction. Can your team extract 30 days of logs across all 13 CERT-In-mandated source types within 2 hours of an incident declaration? This is a hard technical test — not a policy question. The answer must be demonstrated in the drill, not assumed.

The second is evidence preservation before isolation. The sequence is: RAM dump, active session capture, then network isolation. Reversing this order destroys volatile evidence that is irreplaceable. The drill must include an explicit inject forcing this decision under time pressure, because under real pressure the team defaults to isolation first.

The third is DR failover to documented RTO. Not "DR is available" but "DR was activated and the target service was accessible within the documented RTO." The difference between a theoretical RTO and a tested RTO is typically 40–80 minutes of additional downtime in a real incident.

CERT-In Technical Obligations: The 13 Log Sources

CERT-In's April 2022 Directions require organisations to maintain logs from 13 specific source types for 180 days, in a format that can be produced to CERT-In on demand. Most infra teams are aware of this requirement at a policy level. Fewer have actually tested whether they can produce a 30-day extract from all 13 sources within the time pressure of an active incident.

Evidence Preservation: The Sequence That Most Teams Get Wrong

Under pressure, infra teams isolate compromised systems first. This is the natural instinct — stop the bleeding. It is also the action that destroys the volatile forensic evidence needed to understand what happened, confirm scope, and satisfy CERT-In's technical evidence requirements.

The correct sequence for a compromised host is non-negotiable: capture first, isolate second. This must be practised under drill conditions because instinct will reverse it in a real incident.

# Drill checklist — evidence capture before isolation
# 1. RAM dump — winpmem (Windows) or LiME (Linux)
winpmem_mini.exe memory.raw
# or: sudo insmod lime.ko "path=/mnt/secure/memory.lime format=lime"

# 2. Active sessions
netstat -ano > connections_T0.txt
tasklist /v > processes_T0.txt
who -a > sessions_T0.txt    # Linux

# 3. Network capture (60-second window)
tcpdump -i eth0 -w capture_T0.pcap -G 60 -W 1

# 4. Isolate ONLY after above complete
# [firewall rule / VLAN change / physical disconnect]

DR Failover: Testing the RTO You've Promised SEBI

SEBI CSCRF requires Qualified Regulated Entities to maintain documented Recovery Time Objectives for Tier 1 systems — and to demonstrate those RTOs are achievable. "Achievable" means tested. An untested RTO is not an RTO; it is an aspiration.

Most infra teams know their documented RTO. Fewer have activated the DR site and measured actual recovery time under conditions that simulate a real incident — where the production environment is unavailable, the failover runbook was last updated 18 months ago, and two key engineers are not available because it is 3 AM on a Saturday.

What a Functional DR Drill Looks Like

We had a documented RTO of 30 minutes. The drill took 78 minutes. The 48-minute gap came from three sources: the runbook referenced a backup server that was decommissioned 8 months ago, DNS cutover took 20 minutes because the TTL hadn't been pre-reduced, and the authorisation chain to invoke DR required the CTO to call the MD — who was unreachable for 15 minutes.

— Infrastructure Lead, Tier-2 Private Bank, Southern India

NTP Synchronisation: The Silent Compliance Failure

CERT-In's 2022 Directions explicitly require all ICT infrastructure to synchronise time with the National Informatics Centre (NIC) or NPL NTP servers. This requirement is overlooked by a surprisingly high proportion of BFSI infra teams — particularly for legacy systems, network devices, and recently-migrated cloud workloads.

The consequence is not merely regulatory: inconsistent timestamps across log sources make forensic reconstruction unreliable, correlation across SIEM impossible, and CERT-In evidence contestable. A 15-second timestamp discrepancy between your firewall and your Active Directory controller can obscure the entire attack sequence.

The Infra Team's Pre-Drill Technical Checklist

Run this 72 hours before any CyberDrill to validate technical readiness. Every item that fails is a finding before the drill begins — which means it can be fixed before the SEBI ID.5 report records it as a gap.

What Infra Teams Must Produce for the SEBI ID.5 Drill Report

The drill report is owned by the CISO, but the technical evidence within it must come from the infra team. Specifically, the infra team must produce documentation of the following for each drill:

• Log availability confirmation: Which sources were verified, extraction time, any gaps identified
• Evidence preservation sequence adherence: Was the correct sequence followed? If not, what was the deviation and why?
• DR activation time vs. documented RTO: Actual time measured from invocation to service availability
• NTP compliance status: Timestamp delta across log sources at time of drill
• Technical findings: Any configuration gaps, runbook inaccuracies, or tool failures identified during the drill
• Action items: Named owner, remediation action, deadline — for each technical finding