# The Eight Iron Rules - Implementation Checklist

## How to Use This Document

Each Iron Rule has:
- **Core Principle**: The rule itself
- **Why It Matters**: CCDC-specific reasoning
- **Implementation Checklist**: Actions to take
- **Verification Steps**: How to confirm compliance
- **Common Violations**: What NOT to do

---

## Rule 1: Service Priority Is Absolute

### Core Principle
> Scored services are sacred. Never take actions that break what's being tested.

### Why It Matters
- Service uptime is ~50% of your score
- Red Team penalties can be reduced; service downtime cannot
- Every minute of downtime costs points

### Implementation Checklist

**Before Competition:**
- [ ] Know ALL scored services and their dependencies
- [ ] Have service-specific recovery procedures documented
- [ ] Assign primary and backup owner for each service
- [ ] Test service restart procedures

**During Competition:**
- [ ] Check service status every 5 minutes minimum
- [ ] Before ANY change, ask: "Will this affect scored services?"
- [ ] Have rollback plan before making changes
- [ ] Communicate service changes to team

**Service Health Monitoring:**
```bash
# Windows - Check critical services
Get-Service | Where-Object {$_.Name -match "w3svc|dns|smtp"}

# Linux - Check web, db, email
systemctl status nginx apache2 mysql postfix named
```

### Verification Steps
- [ ] Scoring engine shows green for all services
- [ ] Can manually verify service responds (curl, telnet)
- [ ] Team knows who owns each service

### Common Violations
- Stopping a service "temporarily" and forgetting
- Firewall rule that blocks scoring engine
- Changing service account password and breaking service
- Rebooting without checking service dependencies

---

## Rule 2: No Lone Wolf Operations

### Core Principle
> All changes must be announced before execution and confirmed after.

### Why It Matters
- Prevents stepping on teammates' work
- Creates accountability trail
- Speeds up incident investigation
- Required for professional documentation

### Implementation Checklist

**Communication Protocol:**
- [ ] Establish team communication channel
- [ ] Define change announcement format
- [ ] Captain must acknowledge major changes
- [ ] Log ALL changes in Change Log

**Before Any Change:**
1. [ ] Announce: "I am about to [change] on [system]"
2. [ ] Wait for acknowledgment from Captain/relevant owner
3. [ ] Document current state
4. [ ] Make the change
5. [ ] Verify success
6. [ ] Announce: "[Change] complete, verified working"

**Announcement Template:**
```
[TIME] [NAME]: Planning to [ACTION] on [SYSTEM]
Reason: [WHY]
Impact: [EXPECTED EFFECT]
Rollback: [HOW TO UNDO]
```

### Verification Steps
- [ ] Change log has entry for every change
- [ ] No surprises when teammates check systems
- [ ] Can explain any change found during investigation

### Common Violations
- "Quick fix" without telling anyone
- Changing passwords without updating credential log
- Modifying firewall rules silently
- Restarting services without announcement

---

## Rule 3: Identity Over Surface

### Core Principle
> Credential hygiene supersedes superficial hardening. Change defaults first.

### Why It Matters
- Red Team tries default creds in first 5 minutes
- One compromised credential = full network access
- Credential attacks are #1 initial access method

### Implementation Checklist

**First 15 Minutes (PRIORITY):**
- [ ] Change ALL default administrator passwords
- [ ] Change root/Administrator password on all systems
- [ ] Change service account passwords (carefully!)
- [ ] Disable Guest accounts everywhere

**Within First Hour:**
- [ ] Document ALL credential changes
- [ ] Remove/disable unused accounts
- [ ] Check for unauthorized admin accounts
- [ ] Verify no shared credentials

**Credential Standards:**
- [ ] Minimum 12 characters
- [ ] Different password for each system
- [ ] Documented in secure credential log
- [ ] Known only to those who need it

**Credential Change Commands:**
```powershell
# Windows - Change local admin
net user Administrator [NewPassword]

# Windows - Change domain account
Set-ADAccountPassword -Identity [user] -Reset -NewPassword (ConvertTo-SecureString "[pass]" -AsPlainText -Force)
```

```bash
# Linux - Change password
passwd [username]

# Linux - Change root
sudo passwd root
```

### Verification Steps
- [ ] Cannot login with default credentials
- [ ] Credential log is complete and accurate
- [ ] No unknown accounts exist

### Common Violations
- Changing admin password but not service accounts
- Using same password across multiple systems
- Forgetting to document password changes
- Leaving default credentials on "less important" systems

---

## Rule 4: Logs Are Not Optional

### Core Principle
> If it's not logged, you cannot prove it happened—or didn't.

### Why It Matters
- Incident reports require evidence
- Can reduce Red Team penalties with good documentation
- Enables proactive threat detection
- White Team values thorough documentation

### Implementation Checklist

**Enable Logging Immediately:**
- [ ] Windows Security Event Log enabled
- [ ] Windows PowerShell logging enabled
- [ ] Linux auth.log accessible and rotating
- [ ] Web server access/error logs enabled
- [ ] Database query logging if needed

**Critical Events to Log:**
- [ ] All authentication (success and failure)
- [ ] Account changes (create, delete, modify)
- [ ] Service start/stop events
- [ ] Firewall rule changes
- [ ] Process creation (if Sysmon available)

**Log Review Schedule:**
- [ ] Continuous monitoring by designated person
- [ ] Full review every 30 minutes minimum
- [ ] Immediate review after any incident

**Windows Logging Setup:**
```powershell
# Enable PowerShell logging
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1

# Audit policy
auditpol /set /category:"Account Logon" /success:enable /failure:enable
auditpol /set /category:"Account Management" /success:enable /failure:enable
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
```

**Linux Logging Setup:**
```bash
# Verify logging service
systemctl status rsyslog

# Watch auth log
tail -f /var/log/auth.log

# Enable more detailed logging
# Edit /etc/rsyslog.conf as needed
```

### Verification Steps
- [ ] Can retrieve logs for any system
- [ ] Logs show recent authentication events
- [ ] Log storage is not full

### Common Violations
- Disabling logging to "improve performance"
- Not checking logs until after an incident
- Logs filling up and rotating away evidence
- No centralized log collection

---

## Rule 5: Every Anomaly Gets a Ticket

### Core Principle
> Suspicious? Write it down. Incidents emerge from ignored warnings.

### Why It Matters
- Small anomalies often precede major compromises
- Documentation helps identify patterns
- Creates evidence trail for incident reports
- Ensures nothing falls through cracks

### Implementation Checklist

**Anomaly Documentation:**
- [ ] Have incident log ready from start
- [ ] Designate someone to triage anomalies
- [ ] Low threshold for logging - when in doubt, write it down
- [ ] Include timestamp, system, observation, action taken

**What Counts as Anomaly:**
- [ ] Failed login attempts (any)
- [ ] Unknown processes running
- [ ] Unexpected network connections
- [ ] Files modified unexpectedly
- [ ] Services stopped/started unexpectedly
- [ ] New user accounts
- [ ] Unusual scheduled tasks
- [ ] High CPU/memory/network usage

**Anomaly Log Format:**
```
TIME: [HH:MM]
SYSTEM: [hostname/IP]
OBSERVED: [what you saw]
SEVERITY: [LOW/MEDIUM/HIGH/CRITICAL]
ACTION: [what you did]
STATUS: [OPEN/INVESTIGATING/RESOLVED]
```

### Verification Steps
- [ ] Anomaly log exists and is being used
- [ ] All team members know how to report anomalies
- [ ] Captain reviews anomaly log regularly

### Common Violations
- "It's probably nothing" mentality
- Investigating but not documenting
- Only logging confirmed incidents
- Not following up on logged anomalies

---

## Rule 6: Contain First, Diagnose Later

### Core Principle
> Stop the bleeding. Elegant fixes lose points; quick containment wins.

### Why It Matters
- Every second of active compromise costs points
- Full forensics can wait; stopping damage cannot
- Quick containment reduces Red Team penalties
- Investigation is easier after threat is contained

### Implementation Checklist

**Containment Actions (in order):**
1. [ ] Isolate affected system (network or disable NIC)
2. [ ] Kill malicious processes
3. [ ] Disable compromised accounts
4. [ ] Block attacker IPs
5. [ ] Then investigate

**Quick Containment Commands:**
```powershell
# Windows - Disable network adapter
Disable-NetAdapter -Name "Ethernet"

# Windows - Kill process
taskkill /PID [PID] /F

# Windows - Disable account
net user [username] /active:no

# Windows - Block IP
netsh advfirewall firewall add rule name="Block Attacker" dir=in action=block remoteip=[IP]
```

```bash
# Linux - Kill process
kill -9 [PID]

# Linux - Lock account
usermod -L [username]

# Linux - Block IP
iptables -A INPUT -s [IP] -j DROP

# Linux - Disable network (careful!)
ip link set [interface] down
```

**After Containment:**
- [ ] Verify services still running
- [ ] Document containment actions
- [ ] Begin investigation
- [ ] Prepare incident report

### Verification Steps
- [ ] Team knows containment procedures
- [ ] Can execute containment in < 2 minutes
- [ ] Containment doesn't break services

### Common Violations
- Spending 30 minutes investigating before acting
- Trying to understand attack fully before containing
- Containment that breaks scored services
- Not documenting containment actions

---

## Rule 7: Scorched Earth Is Defeat

### Core Principle
> Service destruction to deny Red Team is a failed strategy. Defend, don't delete.

### Why It Matters
- Destroying services = losing points
- Red Team still gets points for forcing you to destroy
- Rebuilding takes time away from defense
- White Team penalizes destructive tactics

### Implementation Checklist

**What NOT To Do:**
- [ ] Never delete critical system files
- [ ] Never format drives as "defense"
- [ ] Never disable all network access
- [ ] Never "scorched earth" any service

**Defensive Alternatives:**
- [ ] Block specific attacker IPs (not all IPs)
- [ ] Disable compromised accounts (not all accounts)
- [ ] Restart services (not uninstall them)
- [ ] Restore from backup (not delete data)

**Recovery Over Destruction:**
- [ ] Have backups of critical configs
- [ ] Know how to restore services quickly
- [ ] Practice recovery procedures
- [ ] Keep service running even while defending

### Verification Steps
- [ ] All defenses are targeted, not blanket
- [ ] Services remain operational
- [ ] Recovery plan exists for each service

### Common Violations
- "Nuke it from orbit" mentality
- Disabling too many accounts
- Firewall rules that block legitimate traffic
- Deleting suspicious files that are actually needed

---

## Rule 8: Injects Are Not Optional

### Core Principle
> Business tasks carry weight. Ignoring injects for "security" still loses.

### Why It Matters
- Injects are ~50% of your score
- Technical excellence means nothing without inject completion
- White Team specifically watches inject response quality
- Professional communication is a competitive advantage

### Implementation Checklist

**Inject Process:**
1. [ ] Receive inject → Log immediately
2. [ ] Assign to appropriate team member
3. [ ] Note deadline prominently
4. [ ] Begin work immediately or schedule appropriately
5. [ ] Quality check before submission
6. [ ] Submit with time buffer
7. [ ] Confirm submission received

**Inject Roles:**
- [ ] Inject Lead assigned
- [ ] Inject Lead monitors queue constantly
- [ ] Technical members support inject completion
- [ ] Captain prioritizes when conflicts arise

**Quality Standards:**
- [ ] Professional formatting
- [ ] Complete answer to all requirements
- [ ] Proofread for errors
- [ ] Evidence/documentation attached
- [ ] Submitted before deadline

**Template Inject Response:**
```
INJECT: [ID]
SUBMITTED BY: [Name]
DATE/TIME: [Timestamp]

EXECUTIVE SUMMARY:
[Brief overview]

RESPONSE:
[Detailed answer addressing all requirements]

ATTACHMENTS:
[List any supporting documentation]

SUBMITTED VIA: [Portal/Email/Paper]
CONFIRMATION: [Yes/No]
```

### Verification Steps
- [ ] Inject queue is monitored continuously
- [ ] All injects have assigned owner
- [ ] No injects submitted late
- [ ] Quality review before submission

### Common Violations
- Ignoring injects during incident response
- Late submissions
- Incomplete responses
- Poor formatting or professionalism
- "Technical work is more important" attitude

---

## Summary: The Eight Iron Rules

| # | Rule | One-Line Summary |
|---|------|------------------|
| 1 | Service Priority | Scored services are sacred - never break them |
| 2 | No Lone Wolf | Announce all changes, document everything |
| 3 | Identity Over Surface | Change credentials before fancy hardening |
| 4 | Logs Are Required | Enable logging immediately, review constantly |
| 5 | Document Anomalies | Write down anything suspicious |
| 6 | Contain First | Stop the attack, then investigate |
| 7 | No Scorched Earth | Defend services, don't destroy them |
| 8 | Injects Matter | Business tasks are half your score |

---

_Checklist by CCDC.x1000.ai - Elite Blue Team Training Platform_