Cyber Incident Response for Defense Contractors

Defense contractors handling Controlled Unclassified Information (CUI) are subject to DFARS 252.204-7012 — the Defense Federal Acquisition Regulation Supplement cybersecurity clause. This clause creates a hard 72-hour deadline for reporting cyber incidents to the DoD, with a specific reporting path through the Defense Industrial Base Cybersecurity (DIBNet) portal.

Most contractors know the rule exists. Fewer have built the infrastructure to actually meet the 72-hour window when something goes wrong at 11 PM on a Saturday.

The DFARS 252.204-7012 Incident Reporting Requirement

The clause is direct: when a contractor discovers a cyber incident affecting covered systems or CUI, they must:

1. Report within 72 hours via DIBNet (or provide notice to the contracting officer if DIBNet is unavailable)
2. Preserve images of compromised systems for at least 90 days
3. Submit a malware sample to the Defense Cyber Crime Center (DC3) if malware was involved
4. Cooperate with DoD damage assessment activities as requested

The 72-hour clock starts at discovery — when a responsible party in the organization first becomes aware of the incident. This creates a detection urgency separate from the incident itself: if you don't know your systems are compromised, you can't report within the window.

The Gap Most Contractors Have

The technical implementation gap isn't usually awareness of the rule — it's the absence of infrastructure that makes detection fast and reporting straightforward.

A contractor with a manual, human-dependent detection process (someone notices anomalous behavior, reports to IT, IT investigates) might take 24–48 hours just to confirm a compromise. That leaves 24–48 hours to generate the report, gather artifacts, and submit — a timeline that requires everything to go right.

Pre-built incident response infrastructure compresses the detection window to minutes and the reporting preparation to hours, not days.

Detection Architecture

CloudTrail + EventBridge for Real-Time Detection

CloudTrail captures every API call in AWS environments. The detection pipeline converts CloudTrail events into real-time alerts on indicators of compromise (IOCs):

# EventBridge rule for high-priority security events
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  RootLoginAlert:
    Type: AWS::Events::Rule
    Properties:
      Name: detect-root-account-usage
      EventPattern:
        source: ["aws.signin"]
        detail-type: ["AWS Console Sign In via CloudTrail"]
        detail:
          userIdentity:
            type: ["Root"]
      Targets:
        - Arn: !GetAtt IncidentResponseFunction.Arn
          Id: IncidentResponseLambda

  IAMPolicyChangeAlert:
    Type: AWS::Events::Rule
    Properties:
      Name: detect-iam-privilege-escalation
      EventPattern:
        source: ["aws.iam"]
        detail:
          eventName:
            - "AttachUserPolicy"
            - "AttachRolePolicy"
            - "CreatePolicyVersion"
            - "PutUserPolicy"
            - "SetDefaultPolicyVersion"
      Targets:
        - Arn: !GetAtt IncidentResponseFunction.Arn
          Id: IncidentResponseLambda

These EventBridge rules trigger a Lambda function that sends an alert, begins evidence preservation, and starts the incident clock. IAM privilege escalation events are among the most reliable early indicators of a serious compromise.

GuardDuty for Threat Intelligence

AWS GuardDuty provides continuous threat detection using machine learning and threat intelligence feeds. For GovCloud environments, GuardDuty is integrated and generates findings for:

• Unusual API call patterns from unexpected locations
• Instance communicating with known malicious IP addresses
• Credential exfiltration patterns
• Port scanning activity from within the environment

GuardDuty findings feed to Security Hub, which aggregates and prioritizes across all services.

VPC Flow Logs for Network-Level Evidence

VPC Flow Logs capture network traffic metadata for every flow within the VPC. During incident investigation, flow logs answer questions about lateral movement — what connected to what, when, and for how long.

resource "aws_flow_log" "cui_vpc" {
  vpc_id          = aws_vpc.cui_enclave.id
  traffic_type    = "ALL"
  iam_role_arn    = aws_iam_role.flow_log.arn
  log_destination = aws_cloudwatch_log_group.flow_logs.arn

  tags = {
    Purpose = "incident-response-evidence"
    RetentionDays = "90"
  }
}

Note the 90-day retention — matching the DFARS requirement to preserve images for 90 days post-incident.

The Incident Response Lambda: Automated Containment and Notification

When a high-confidence IOC triggers, the first automated response runs in seconds — before a human has been notified:

import boto3
import json
import os
from datetime import datetime

def handler(event, context):
    ec2 = boto3.client('ec2', region_name='us-gov-west-1')
    sns = boto3.client('sns', region_name='us-gov-west-1')
    
    incident_id = f"IR-{datetime.utcnow().strftime('%Y%m%d-%H%M%S')}"
    incident_time = datetime.utcnow().isoformat()
    
    # Extract affected resource from the event
    detail = event.get('detail', {})
    affected_instance = detail.get('instanceId')
    
    if affected_instance:
        # Isolate the instance immediately
        ec2.modify_instance_attribute(
            InstanceId=affected_instance,
            Groups=[os.environ['ISOLATION_SECURITY_GROUP_ID']]
        )
        
        # Create forensic snapshot before containment changes anything
        volumes = ec2.describe_instance_attribute(
            InstanceId=affected_instance,
            Attribute='blockDeviceMapping'
        )
        for vol in volumes['BlockDeviceMappings']:
            ec2.create_snapshot(
                VolumeId=vol['Ebs']['VolumeId'],
                Description=f'{incident_id}-forensic-snapshot',
                TagSpecifications=[{
                    'ResourceType': 'snapshot',
                    'Tags': [{'Key': 'IncidentId', 'Value': incident_id}]
                }]
            )
    
    # Notify the incident response team
    sns.publish(
        TopicArn=os.environ['IR_TEAM_TOPIC'],
        Subject=f'INCIDENT DETECTED: {incident_id}',
        Message=json.dumps({
            'incident_id': incident_id,
            'detection_time': incident_time,
            'event_source': event.get('source'),
            'detail': detail,
            'dfars_deadline': 'Report to DIBNet within 72 hours of this timestamp'
        })
    )
    
    return {'incident_id': incident_id, 'status': 'contained_and_notified'}

This function isolates the affected instance by replacing its security group with an isolation group (all traffic denied) and creates a forensic snapshot — preserving the system state as required by DFARS before any cleanup or remediation.

The 72-Hour Reporting Package

The DIBNet reporting form (DD Form 1494 equivalent for cyber incidents) requires:

• Company CAGE code and contract number(s) affected
• Date/time of incident discovery
• Systems affected (by IP, hostname, and function)
• Type of compromise (ransomware, data exfiltration, unauthorized access, etc.)
• CUI categories affected (if known)
• Actions taken to contain the incident

Pre-populating a reporting template with your CAGE code, contract numbers, and system inventory means the human effort during an incident is filling in event-specific details, not hunting for baseline information. Rutagon holds CAGE code 19ZR7 and maintains this kind of pre-prepared package for its own systems.

Connecting Incident Response to CMMC Assessment

DIBCAC (Defense Industrial Base Cybersecurity Assessment Center) assessors look at incident response capability as part of CMMC Level 2 assessments. NIST 800-171 IR family requirements include:

• 3.6.1: Establish an incident handling capability — documented IR plan, not just ad-hoc response
• 3.6.2: Track, document, and report incidents — tooling that creates an audit trail
• 3.6.3: Test incident response — tabletop exercises or simulation runs documented

An automated detection-to-containment pipeline addresses 3.6.1 and 3.6.2 concretely. Documented test runs address 3.6.3. All three should be referenced in your System Security Plan.

For more on building CMMC-ready infrastructure, see our guides on CMMC Level 2 cloud architecture and DFARS 252.204-7012 compliance architecture.

Discuss building pre-positioned incident response infrastructure → rutagon.com/government

Frequently Asked Questions

When does the 72-hour DFARS reporting clock start?

The 72-hour clock starts at discovery — when a person responsible for the covered contractor information system first becomes aware that a cyber incident has occurred. It does not start at confirmation or remediation — early awareness triggers the clock. This is why fast automated detection is critical.

What is DIBNet and how do I access it?

DIBNet (Defense Industrial Base Network) is the DoD portal for contractor cybersecurity reporting. Reporting an incident under DFARS 252.204-7012 is done through the DIBNet portal at dibnet.dod.mil. Access requires registration and DoD-accepted credentials (CAC or PKI certificate).

Does DFARS incident reporting apply to all defense contractors?

DFARS 252.204-7012 applies to contracts that involve safeguarding covered defense information (CDI) or operationally critical support. If your contract includes the DFARS 252.204-7012 clause, you're covered. Review your contract clauses — the clause's presence, not contract size, determines applicability.

What happens if I miss the 72-hour reporting window?

Late reporting can result in contract termination, suspension or debarment proceedings, and potential False Claims Act liability if the government determines you misrepresented your cybersecurity posture. In practice, good-faith late reporting with a documented explanation of why detection was delayed is treated differently than willful non-reporting — but the standard is still met only by reporting on time.

Is a SIEM required for DFARS incident response?

No specific tool is required. What's required is the capability to detect incidents, collect and preserve evidence, and report within 72 hours. A SIEM (Security Information and Event Management system) is the most common way to achieve this at scale, but CloudTrail + GuardDuty + EventBridge + S3 provides equivalent capability for cloud-native environments.