Code Red Scenario: State University System Crisis
Planning Resources
Scenario Details for IMs
State University System: Web Infrastructure Crisis During Fall Registration
Detailed Context
Organization Profile
Type: Major state university system serving as flagship research institution, land-grant university providing undergraduate and graduate education across 12 academic colleges, operating R1 research programs (highest research activity designation), delivering statewide public service mission.
Size: 50,000 enrolled students (42,000 undergraduates, 8,000 graduate/professional students), 8,000 employees including 3,200 faculty members teaching courses and conducting research, 2,400 administrative staff managing enrollment services, student affairs, facilities, business operations, 1,200 IT personnel supporting campus technology infrastructure, 800 research staff, 400 support personnel.
Operations: Academic instruction across 180 degree programs, research expenditures totaling $420 million annually from federal agencies (NSF, NIH, DoD, DOE), private foundations, and industry partnerships, fall semester registration processing 50,000 student course enrollments generating $180 million tuition revenue, student services including on-campus housing (18,000 residents), dining operations, health services, recreation facilities, library system, operating 200+ IIS-based web servers across decentralized departmental infrastructure hosting academic content, research project sites, administrative portals, student information systems.
Critical Services: Fall registration system (48-hour enrollment window determining student access to courses, graduation timeline impacts), course catalog and scheduling database, housing assignment portal (18,000 on-campus residents), financial aid application and award notification system, student billing and payment processing, health services appointment scheduling, library resources and research databases.
Technology Infrastructure: Highly decentralized IT architecture—12 academic colleges independently manage departmental web servers with minimal central oversight, IIS adopted widely for “Windows Active Directory integration” and “ease of use for non-technical faculty,” legacy systems running varied IIS versions from 4.0 to 6.0, limited standardization across 200+ independently administered servers, campus network connecting distributed infrastructure through backbone routers.
Current Critical Period: 72 hours before fall semester registration window opens—student services preparing for peak demand, IT resources focused on registration system stability, course scheduling finalized by academic departments, faculty preparing syllabi requiring web publication, new student orientation concurrent with registration requiring functional campus technology.
Key Assets & Impact
Student Services & Registration Systems: Fall registration determines course enrollment for 50,000 students within 48-hour window—registration system downtime prevents students from securing required courses for degree progression, popular classes fill within hours creating sequence bottlenecks (prerequisite chains mean missing one course delays graduation), housing assignment system coordinates 18,000 on-campus residents (room assignments, meal plans, move-in logistics), financial aid portal distributes $280M in federal grants and loans requiring timely disbursement, international students on F-1 visas need course registration to maintain status, Code Red worm degrading server performance threatens registration window creating academic progression disruptions and student financial consequences.
Academic Research Infrastructure: 200+ research labs depend on departmental web servers for grant-funded project collaboration—NIH clinical trial data repositories serve multi-institution research networks, DoD-funded defense research requires secure project communication platforms, NSF collaborative grants link researchers across universities depending on data sharing infrastructure, industry-sponsored research projects deliver quarterly progress reports through web portals, server disruption delays research deliverables risking grant compliance and continued funding, graduate student dissertation work depends on research data access (graduation timeline impacts), $420M annual research enterprise faces operational disruption during emergency patching.
University Reputation & Public Safety: State flagship university serves as technology leader for higher education sector—infected servers participating in coordinated attacks against government and educational institutions create national media coverage, prospective students and parents evaluating university based on technology capabilities and campus safety, state legislators questioning university IT leadership and budget allocation, alumni donors concerned about institutional competence, Department of Homeland Security monitoring university as source of attack traffic, federal research sponsors reviewing cybersecurity posture for classified and sensitive research authorization, reputational damage affects student recruitment, research competitiveness, public trust in state’s premier educational institution.
Immediate Business Pressure
Monday Morning, 72 Hours Before Registration Opens:
University CIO Dr. Michael Chen discovered Code Red worm had infected approximately 200 of the university’s 220 IIS web servers across 12 academic colleges during weekend. Worm actively scanning internet addresses, participating in coordinated DDoS attacks, degrading server performance affecting registration system, course catalog, housing portal, financial aid services.
Network monitoring team traced infection to departmental servers with inconsistent patching—Biology Department server infected first Friday evening, lateral spread through campus network infected College of Engineering (28 servers), Business School (18 servers), Liberal Arts departments (45 servers), Student Affairs web infrastructure (12 servers), Housing and Residential Life (8 servers). Registration system backend affected, response times degraded 400%, system stability threatened.
University President’s office received inquiries from state Governor’s education advisor—news reports identifying university servers as attack sources, questions about state investment in university IT security, concerns about 50,000 students’ academic progression if registration fails. Student Government Association president emailed demanding registration system guarantee. Parents calling admissions office asking if enrollment secure.
Critical Timeline: - Current moment (Monday 9am): 200+ servers infected, registration opens Thursday 8am (72 hours), worm participating in attacks - Stakes: 50,000 students need course registration, $180M tuition revenue, $420M research operations, national reputation crisis - Dependencies: Decentralized IT means coordinating 12 college IT departments, registration window is absolute deadline (academic calendar printed, faculty schedules set), federal financial aid disbursement timeline tied to enrollment status
Cultural & Organizational Factors
Registration period operational priority delayed security patching: University culture prioritizes “student service continuity above all else”—when central IT proposed taking registration infrastructure offline for IIS security patches during late summer, Registrar’s office refused citing “registration readiness” and “cannot risk system instability during enrollment window.” Student Affairs leadership decision: maintain registration system availability (mission-critical student service) over applying patches (security team theoretical concerns). Decision made organizational sense—registration determines student course access affecting degree completion, enrollment drives tuition revenue ($180M), system downtime during registration creates immediate crisis affecting 50,000 students. Patches deferred until “after fall registration completes.” Servers remained vulnerable during Code Red emergence.
Academic college autonomy prevents centralized IT security: University governance model distributes technology authority to academic colleges—colleges control own IT budgets from tuition revenue shares, hire own IT staff, purchase and manage own infrastructure independently. When central IT proposed mandatory security standards and centralized patch management, college deans rejected citing “academic autonomy” and “college-specific needs.” Colleges defended: research computing requirements differ by discipline, central policies slow innovation, faculty need IT flexibility for specialized academic software. Result: 200+ servers managed by 12 independent college IT teams with inconsistent security practices, no central enforcement authority, patching decisions made at college level based on competing academic priorities. Code Red exploited decentralized architecture lacking coordinated defens
Research computing priorities compete with security maintenance: Faculty performance measured by research grants, publications, student graduation rates—cybersecurity compliance not factor in tenure/promotion decisions. Research labs prioritize computing uptime for grant-funded experiments over security updates causing experimental interruptions. When IT staff proposed research server patching schedules, principal investigators (PIs) rejected: “experiments running 24/7 cannot be interrupted,” “grant deliverable deadline next week, patch after submission,” “research timeline doesn’t accommodate IT maintenance windows.” Faculty authority over research computing meant security teams lacked power to enforce patches on research infrastructure. University values (research excellence, faculty autonomy, grant success) took precedence over IT security requirements. Vulnerable servers supported active research projects.
Student services operational model creates single points of failure: Budget constraints drove server consolidation—registration system, housing portal, financial aid database, course catalog all hosted on shared IIS infrastructure to “maximize resource efficiency” and “reduce hardware costs.” Business Affairs rejected proposals for redundant systems as “duplicative spending,” questioned return on investment for backup infrastructure “sitting idle most of year.” Decision reflected budget reality—state funding per student declined 22% over decade, administrative costs scrutinized by legislature, IT infrastructure competes with faculty salaries and student services for limited resources. Consolidation created dependencies: one compromised server affected multiple critical services, no backup capacity for emergency failover, patching required taking all student services offline simultaneously. Code Red worm exploited consolidated architecture.
Operational Context
Large state universities operate under complex competing pressures—flagship research mission, public service to 50,000 students, state legislative accountability, federal research compliance, tuition revenue dependence, enrollment competition. IT security competes against immediate operational needs: keeping registration running, supporting active research, maintaining student services, meeting academic calendar deadlines.
Decentralized governance reflects academic tradition—colleges control own budgets and operations, faculty governance prevents administrative mandates, departmental autonomy protects academic freedom. Central IT provides network backbone and recommendations, lacks authority to enforce security standards on college-managed infrastructure. Result: 200+ servers with 12 different patching policies, security decisions made by college IT directors balancing academic priorities against security requirements.
Registration period creates annual vulnerability window—late summer preparation means IT changes frozen to ensure system stability, all resources focused on registration readiness, security updates deferred until “after critical period.” Annual cycle: spring semester focus (January-May), summer reduced operations (June-July), fall registration prep (August), freeze on changes. Security maintenance perpetually postponed for “next quarter after critical deadline passes.”
Research culture prioritizes discovery over security—faculty evaluated on grants and publications, research computing uptime enables experiments, security interruptions threaten deliverables and funding renewals. PIs control lab infrastructure through grant budgets, central IT serves research needs, security teams lack authority to mandate patches disrupting active research. University mission (advancing knowledge, serving state through research) creates operational environment where research continuity outweighs cybersecurity concerns.
Code Red struck during perfect storm—72 hours before registration, research labs at full capacity with summer grant deadline work, decentralized IT preventing coordinated response, no redundant infrastructure allowing graceful failover, student services consolidation creating cascading failure potential. Worm exploited institutional governance model not designed for rapid cybersecurity response.
Key Stakeholders
- Dr. Michael Chen (University CIO) - Coordinating emergency response across 12 autonomous college IT departments while protecting registration system for 50,000 students
- Dr. Patricia Williams (Provost and Executive VP for Academic Affairs) - Balancing academic mission continuity with institutional reputation crisis, managing college deans’ resistance to emergency IT mandates
- Robert Martinez (University Registrar) - Protecting fall registration window critical for student academic progression and university tuition revenue, no authority to delay registration (academic calendar published)
- Dr. Sarah Johnson (VP for Research) - Defending $420M research enterprise requiring server uptime for active grants with federal deliverable deadlines
- David Foster (VP for Student Affairs) - Maintaining housing, financial aid, health services for 50,000 students depending on affected web infrastructure during peak demand period
- Jennifer Chang (President) - Managing state Governor’s inquiries about university cybersecurity, media crisis from attack participation, Board of Trustees emergency briefing
Why This Matters
You’re not just responding to worm outbreak—you’re managing crisis in complex academic institution where decentralized governance, competing academic priorities, student service obligations, research mission requirements, and public accountability create impossible choices during emergency cybersecurity response. Your incident response decisions determine whether 50,000 students access fall courses affecting graduation timelines and financial aid eligibility, whether $420M research enterprise maintains grant compliance, whether state flagship university manages reputational crisis from participating in attacks against government infrastructure.
There’s no solution satisfying all stakeholders: emergency patch all servers (72-hour outage prevents registration, research disruption, student service failure), maintain operations through registration (continued attack participation damages reputation and federal relationships), coordinate response across 12 autonomous colleges (slow consensus-building during active attack). This scenario demonstrates how university governance structures designed for academic freedom and faculty autonomy create cybersecurity response challenges—distributed authority prevents rapid coordinated action, research and educational missions compete with security requirements, public service obligations to students conflict with infrastructure protection needs, budget constraints eliminate redundancy enabling graceful degradation.
IM Facilitation Notes
Emphasize decentralized governance as feature, not bug: University academic colleges have budget autonomy, faculty governance, mission differentiation—this isn’t “bad management,” it’s deliberate structure protecting academic freedom and research independence. Central IT cannot simply “mandate” compliance across autonomous colleges. Help players understand why coordinated response requires negotiation, not command authority.
Registration window is immovable constraint: Academic calendar printed and distributed, faculty schedules set, classroom assignments made, financial aid disbursement tied to enrollment dates—registration cannot be postponed without cascading effects across entire institution. This isn’t arbitrary deadline, it’s coordinated commitment across complex organization. Delaying registration affects 50,000 students’ course access and graduation timelines.
Research mission creates legitimate IT uptime pressures: Faculty evaluated on research productivity, grant deliverables have contractual deadlines, experiments require continuous computing, research funding drives university revenue and reputation—security interruptions compete against core academic mission. Don’t let players dismiss research requirements as “excuses.” PIs have fiduciary responsibilities to funding agencies.
Student service consolidation reflects budget constraints: State funding per student declined over decade, legislature scrutinizes administrative spending, IT competes with faculty positions and student programs—infrastructure redundancy is “luxury” when choosing between backup servers or hiring advisors helping students graduate. Budget decisions reflect resource scarcity, not negligence.
University reputation affects multiple stakeholders: Prospective students and parents making enrollment decisions, federal research sponsors evaluating security posture for classified work, state legislators controlling appropriations, alumni donors assessing institutional competence—reputational damage from attack participation has real consequences for enrollment, research authorization, public funding, community trust in state’s flagship educational institution.
Academic culture values accessibility over restrictions: Universities exist to share knowledge, research collaboration requires open connectivity, educational mission emphasizes access—security restrictions that enhance corporate environments may conflict with academic values. Help players navigate tension between openness (core mission) and security (operational requirement).
Scale creates coordination complexity: 200+ servers across 12 colleges, 8,000 employees, 50,000 students, $420M research, $180M tuition—emergency response in large institution requires coordinating many independent actors with different priorities. Quick decisions possible in small organizations become negotiation processes in complex universities.
Hook
“It’s Monday morning during State University’s peak fall registration period, and 50,000 students are trying to access course registration, student services, and departmental websites. Instead of academic content, hundreds of university web pages are displaying ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ Network administrators discover that the university’s IIS servers are generating massive scanning traffic, effectively turning the institution’s infrastructure into part of a global attack network.”
Initial Symptoms to Present:
Key Discovery Paths:
Detective Investigation Leads:
Protector System Analysis:
Tracker Network Investigation:
Communicator Stakeholder Interviews:
Mid-Scenario Pressure Points:
- Hour 1: 10,000 students unable to complete course registration due to defaced enrollment portal
- Hour 2: Faculty research data becomes inaccessible through compromised departmental websites
- Hour 3: Other universities report that State University servers are attacking their infrastructure
- Hour 4: University administration faces media questions about academic data security and internet responsibility
Evolution Triggers:
- If response exceeds 8 hours, university misses registration deadline affecting student academic progress
- If worm containment fails, infection spreads to other universities through academic collaboration networks
- If patch deployment is delayed, university continues participating in coordinated attacks against educational infrastructure
Resolution Pathways:
Technical Success Indicators:
- Emergency patch deployment stops worm propagation across university web infrastructure
- Student services restored through secure backup systems while maintaining registration deadline
- University servers removed from coordinated attack network through network isolation and system restart
Business Success Indicators:
- Academic operations maintained with minimal impact on student registration and faculty research
- University reputation protected through transparent communication and responsible incident response
- Academic community relationships maintained through coordinated response and information sharing
Learning Success Indicators:
- Team understands university’s dual role as service provider and internet infrastructure participant
- Participants recognize academic institution cybersecurity responsibilities during critical operational periods
- Group demonstrates coordination between academic mission priorities and internet security obligations
Common IM Facilitation Challenges:
If Academic Mission Is Ignored:
“Your technical analysis is excellent, but Lisa reports that 10,000 students can’t register for classes and the registration deadline is tomorrow. How do you balance worm response with critical academic deadlines?”
If Internet Responsibility Is Missed:
“While you’re restoring student services, Professor Davis just received calls from three other universities saying that State University servers are attacking their infrastructure. How does this change your response approach?”
If Research Data Impact Is Overlooked:
“Robert discovered that some of the compromised servers host faculty research data and collaboration portals. How do you assess whether sensitive academic research has been exposed?”
Success Metrics for Session:
Template Compatibility
Quick Demo (35-40 min)
- Rounds: 1
- Actions per Player: 1
- Investigation: Guided
- Response: Pre-defined
- Focus: Use the “Hook” and “Initial Symptoms” to quickly establish university registration crisis. Present the “Guided Investigation Clues” at 5-minute intervals. Offer the “Pre-Defined Response Options” for the team to choose from. Quick debrief should focus on recognizing worm propagation patterns and academic institution infrastructure vulnerabilities.
Lunch & Learn (75-90 min)
- Rounds: 2
- Actions per Player: 2
- Investigation: Guided
- Response: Pre-defined
- Focus: This template allows for deeper exploration of academic institution cybersecurity challenges. Use the full set of NPCs to create realistic registration period pressures. The two rounds allow Code Red to spread affecting more academic services, raising stakes. Debrief can explore balance between student services and internet infrastructure responsibility.
Full Game (120-140 min)
- Rounds: 3
- Actions per Player: 2
- Investigation: Open
- Response: Creative
- Focus: Players have freedom to investigate using the “Key Discovery Paths” as IM guidance. They must develop response strategies balancing student registration deadlines, faculty research data, academic reputation, and internet security responsibilities. The three rounds allow for full narrative arc including worm’s academic-institution-specific impact and coordinated attack participation.
Advanced Challenge (150-170 min)
- Rounds: 3
- Actions per Player: 2
- Investigation: Open
- Response: Creative
- Complexity: Add red herrings (e.g., legitimate university system updates causing unrelated service disruptions). Make containment ambiguous, requiring players to justify academic-facing decisions with incomplete information. Remove access to reference materials to test knowledge recall of worm behavior and university infrastructure security principles.
Quick Demo Materials (35-40 min)
Guided Investigation Clues
Clue 1 (Minute 5): “Web server forensics reveal Code Red worm exploiting IIS buffer overflow vulnerability in servers hosting 200+ departmental websites, student services, and research portals. The memory-only worm is spreading autonomously through State University’s infrastructure, defacing academic websites with ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ messages during peak fall registration period.”
Clue 2 (Minute 10): “Campus network monitoring reveals infected university servers generating massive internet scanning traffic and participating in coordinated attacks against other educational and government institutions. Registration system logs indicate the compromise occurred during peak student access when IIS patches were delayed to avoid disrupting critical academic services affecting 50,000 students.”
Clue 3 (Minute 15): “Internet traffic analysis shows State University’s infected servers attacking other universities through academic collaboration networks. Web server vulnerability assessment reveals 10,000 students unable to complete course registration with the deadline approaching, and faculty research data is potentially exposed through compromised departmental web services.”
Pre-Defined Response Options
Option A: Emergency IIS Patching & Academic Network Isolation
- Action: Immediately deploy emergency IIS patches to all university web servers, isolate infected systems from internet to stop coordinated attacks, restore student services from secure backups, coordinate with academic security community about internet threat.
- Pros: Completely stops worm propagation and ends university participation in internet attacks; enables rapid student service restoration for registration deadline; demonstrates responsible internet citizenship.
- Cons: Requires complete web infrastructure patching affecting all 200+ departmental websites temporarily; some academic services experience brief downtime during registration period.
- Type Effectiveness: Super effective against Worm type malmons like Code Red; memory-only worm is eliminated through reboot after patching.
Option B: Prioritized Service Restoration & Student Focus
- Action: Quarantine confirmed infected servers, implement prioritized restoration for student registration and critical academic services first, maintain research services for unaffected departments while accelerating university-wide remediation.
- Pros: Allows continued student registration and academic operations for high-priority services; protects registration deadline and student academic progress.
- Cons: Risks continued worm propagation in non-prioritized infrastructure; university continues participating in internet attacks during selective restoration; may affect research data security.
- Type Effectiveness: Moderately effective against Worm threats; reduces but doesn’t eliminate worm presence or attack participation.
Option C: Mass Server Reboot & Academic Coordination
- Action: Perform coordinated university-wide server reboot to eliminate memory-only worm, rapidly restore all academic services simultaneously from backups, coordinate with other affected universities about shared response and internet security communication.
- Pros: Fastest technical solution eliminating worm through memory clearing; demonstrates academic community leadership through coordinated response and information sharing.
- Cons: Requires complete academic web infrastructure downtime affecting all students and faculty simultaneously during registration period; doesn’t address underlying IIS vulnerability enabling future reinfection.
- Type Effectiveness: Partially effective against Worm malmon type; eliminates current infection but leaves vulnerability for rapid reinfection.
Lunch & Learn Materials (75-90 min, 2 rounds)
Round 1: Discovery & Identification (30-35 min)
Investigation Clues:
- Clue 1 (Minute 5): Student Services Director Lisa Chang reports that 10,000 students trying to register for fall courses are seeing defacement messages instead of the enrollment portal. “The entire registration system is down during our busiest week!”
- Clue 2 (Minute 10): Web server forensics reveal Code Red worm exploiting IIS buffer overflow vulnerability. The memory-only worm is spreading autonomously through 200+ departmental web servers, defacing academic websites with “HELLO! Welcome to http://www.worm.com! Hacked By Chinese!” messages.
- Clue 3 (Minute 15): Campus network monitoring shows infected university servers generating massive internet scanning traffic. The university’s infrastructure is participating in coordinated attacks against other educational and government institutions.
- Clue 4 (Minute 20): Web Services Director Robert Garcia reveals that IIS patches were delayed during registration period to avoid disrupting critical student services. “We couldn’t risk taking down systems during our busiest time of year.”
Response Options:
- Option A: Emergency Reboot & Service Restoration - Immediately reboot all infected web servers to clear memory-only worm, restore student services from backups, delay comprehensive patching until after registration period.
- Pros: Fastest path to student service restoration; minimal registration disruption; maintains academic deadline.
- Cons: Doesn’t patch underlying IIS vulnerability; servers will be reinfected within hours; continues attack participation risk.
- Type Effectiveness: Partially effective - clears current infection but leaves reinfection vector open.
- Option B: Prioritized Patching - Patch critical student-facing systems first (registration, course management), quarantine remaining infected servers, restore services in priority order.
- Pros: Protects highest-priority academic services; balances security with operational needs; enables controlled restoration.
- Cons: Some academic services remain compromised; research data potentially exposed; partial attack participation continues.
- Type Effectiveness: Moderately effective - stops propagation in patched systems but worm remains active in others.
- Option C: Monitor & Contain - Isolate infected servers from internet to stop attack participation, maintain student services on uninfected backup systems, implement gradual patching schedule.
- Pros: Stops university’s attack participation immediately; maintains registration capability; allows careful systematic patching.
- Cons: Significant academic service disruption; faculty research access limited; extended recovery timeline during critical period.
- Type Effectiveness: Moderately effective - contains threat but delays eradication.
Round 2: Scope Assessment & Response (30-35 min)
Investigation Clues:
- Clue 5 (Minute 30): If Option A (reboot only) was chosen: Within 2 hours, servers are reinfected. Internet traffic analysis shows State University attacking partner universities through academic collaboration networks. “MIT’s security team just called - our servers are hitting them hard.”
- Clue 5 (Minute 30): If Option B or C was chosen: Registration system analysis shows 5,000 students successfully enrolled using restored services. However, 15 departmental research servers remain compromised with faculty data potentially exposed.
- Clue 6 (Minute 40): Professor Alan Davis from Computer Science reports that academic security researchers have identified Code Red as a global threat. “Three other major universities are experiencing identical attacks. This is internet-wide.”
- Clue 7 (Minute 50): CIO Dr. Patricia Moore receives call from university president about media inquiries regarding academic data security and the university’s role in internet attacks. “We need to demonstrate responsible cybersecurity leadership to the academic community.”
- Clue 8 (Minute 55): Registration deadline is 24 hours away. Current status shows either: [A: reinfected infrastructure attacking internet] OR [B/C: partial services with contained threat]. Faculty senate demands explanation about research data exposure.
Response Options:
- Option A: Emergency University-Wide Patching - Deploy emergency IIS patches to all 200+ departmental web servers simultaneously, coordinate with academic security community, issue transparency statement about incident and response.
- Pros: Completely stops worm propagation; ends attack participation; demonstrates academic leadership; protects university reputation.
- Cons: Requires brief downtime for all academic web services during patching; intensive coordination across departments; high resource demand.
- Type Effectiveness: Super effective against Worm type - eliminates vulnerability and current infection.
- Option B: Phased Remediation with Academic Coordination - Continue prioritized patching while maintaining critical student services, coordinate with other affected universities on shared response, implement enhanced monitoring for research data exposure.
- Pros: Balances security remediation with academic mission continuity; builds academic community collaboration; maintains registration capability.
- Cons: Extended remediation timeline; some systems remain vulnerable temporarily; requires careful resource management.
- Type Effectiveness: Moderately effective - progressive improvement but temporary exposure remains.
- Option C: External Security Support & Comprehensive Audit - Bring in academic security consultants for immediate assistance, conduct comprehensive research data exposure assessment, implement emergency backup systems for registration completion.
- Pros: Expert assistance accelerates response; thorough data exposure analysis protects research integrity; ensures registration deadline is met.
- Cons: Expensive external support; potential academic data exposure to consultants; admission that internal capability was insufficient.
- Type Effectiveness: Moderately effective - improves response quality but extends timeline.
Round Transition Narrative
After Round 1 → Round 2:
The team’s initial response determines whether the university continues participating in internet-wide attacks (if they chose quick fixes without patching) or successfully contains the immediate threat but faces the challenge of comprehensive remediation during a critical academic period (if they chose containment and patching). Either way, the situation escalates as media attention increases, other universities report being attacked, and the registration deadline looms. The team must now balance complete security remediation with the university’s academic mission and reputation in the educational community.
Full Game Materials (120-140 min, 3 rounds)
Investigation Sources Catalog
System Logs:
- IIS Server Logs: Buffer overflow exploitation patterns, defacement timestamps showing rapid autonomous spreading, memory utilization spikes indicating worm infection
- Campus Network Logs: Massive scanning traffic from infected servers to internet IP ranges, coordinated attack patterns against educational and government institutions
- Registration System Logs: Service disruption timeline correlating with worm spread, 10,000 failed student enrollment attempts during peak registration period
- Key Discovery: Worm exploits IIS vulnerability that was identified but patching was delayed during critical registration period
Email/Communications:
- Help Desk Tickets: 500+ reports from students about defaced websites and registration failures, faculty complaints about research portal inaccessibility
- IT Management Emails: Discussions about delaying IIS patches to avoid disrupting registration period, risk assessment conversations showing awareness of vulnerability
- External Communications: Messages from other university security teams reporting attacks from State University IP addresses
- Key Discovery: Management consciously delayed patches due to academic mission priorities, creating vulnerability window
Interviews (NPCs):
- Dr. Patricia Moore (CIO): “We had to choose between student registration and applying patches. We chose the students. Was that wrong?”
- Robert Garcia (Web Services): “I’ve been warning about the patch delay, but registration is sacred here. Now we’re attacking other universities.”
- Lisa Chang (Student Services): “10,000 students can’t register and the deadline is tomorrow. I don’t care about worms, I care about students’ academic futures.”
- Professor Alan Davis (Computer Science): “This is a global threat. I’m getting calls from researchers worldwide. We need to share information, not hide.”
- Key Insights: Tension between academic mission and security priorities, organizational culture prioritizing student services over infrastructure security
System Analysis:
- Memory Forensics: Code Red worm resident in IIS process memory, no disk persistence indicating memory-only infection
- Vulnerability Assessment: 200+ departmental web servers running vulnerable IIS versions, patch deployment delayed by 14 days during registration period
- Malware Analysis: Worm propagates autonomously through TCP port 80 scanning, defaces web root with signature message, participates in coordinated DDoS against government targets
- Key Discovery: Memory-only nature means simple reboot clears infection BUT reinfection occurs immediately if vulnerability not patched
Network Traffic:
- Outbound Scanning: Infected servers systematically scanning internet IP ranges on TCP port 80, attempting to exploit IIS buffer overflow in other systems
- Attack Participation: University infrastructure participating in coordinated attacks against White House (www.whitehouse.gov) and other government/educational targets
- Academic Network Patterns: Infection spreading to partner universities through research collaboration connections and academic network trusts
- Key Discovery: University’s role as internet infrastructure provider means attacks have high visibility and impact on academic community reputation
External Research:
- Security Advisory: Microsoft IIS Code Red buffer overflow (CVE-2001-0500), multiple variants identified with different payload behavior
- Internet-Wide Scope: eEye Digital Security and CERT/CC reporting 359,000 infected systems worldwide, academic institutions disproportionately affected
- Academic Impact: Major universities experiencing simultaneous infections, coordinated attack disrupting educational technology infrastructure
- Key Insights: Part of larger internet-wide event requiring academic community coordination, university reputation at stake beyond just technical response
Response Evaluation Criteria
Type-Effective Approaches:
- Worm Containment: Network isolation stops propagation, memory clearing (reboot) eliminates current infection, vulnerability patching prevents reinfection
- Worm Eradication: Requires patching vulnerable systems - rebooting alone provides only temporary relief before automatic reinfection
- Super Effective: Combined network isolation + emergency patching + coordinated reboot eliminates threat completely
Common Effective Strategies:
- Immediate Isolation: Disconnect infected servers from internet to stop attack participation and worm spread
- Emergency Patching: Deploy IIS security updates to vulnerable systems before restoring connectivity
- Service Restoration: Restore student-facing services from secure backups or alternate infrastructure while remediating infected systems
- Academic Coordination: Share information with other affected universities, coordinate response across educational institutions
- Transparent Communication: Proactive disclosure to academic community demonstrates responsible cybersecurity leadership
Common Pitfalls:
- Reboot Without Patching: Clears current infection but allows immediate reinfection from internet scanning - temporary fix only
- Prioritizing Speed Over Security: Rushing to restore student services without patching leads to continued vulnerability and attack participation
- Ignoring Internet Responsibility: Focusing only on internal operations while university infrastructure attacks other institutions damages academic reputation
- Delayed Response: Waiting to respond during registration period allows continued attack participation and greater academic service disruption
- Inadequate Research Data Assessment: Failing to evaluate potential faculty research data exposure through compromised departmental servers
Adjudicating Novel Approaches:
Hybrid Solutions (Encourage with Guidance):
- “We’ll create isolated registration environment while patching infrastructure” → “Yes, and… how do you ensure the isolated environment has the registration data and can synchronize back after patching?”
- “We’ll coordinate with other universities on simultaneous patching” → “Yes, and… excellent academic community thinking. What coordination mechanisms and timeline do you propose?”
- “We’ll restore from backups while patching infected systems offline” → “Yes, and… good approach. How do you verify backups aren’t from after initial compromise?”
Creative But Problematic (Redirect Thoughtfully):
- “We’ll keep systems offline until after registration deadline” → “That solves the attack participation problem, but Lisa reports students will miss registration. How do you maintain academic mission?”
- “We’ll just block outbound port 80 traffic” → “That stops attack participation, but how do students and faculty access external web resources for academic work? What’s the operational impact?”
- “We’ll replace all IIS servers with Apache during registration period” → “Bold idea, but that’s a massive infrastructure migration. Do you have the time and expertise during your busiest operational period?”
Risk Assessment Framework:
- Low Risk Solutions: Memory clearing + patching + restoration from verified backups → Encourage and approve
- Medium Risk Solutions: Partial patching + prioritized service restoration + enhanced monitoring → Approve with contingencies
- High Risk Solutions: Quick fixes without vulnerability remediation + minimal service disruption → Challenge with reinfection scenarios
Advanced Challenge Materials (150-170 min, 3 rounds)
Investigation Sources WITH Complexity
Base Evidence Sources: [Same as Full Game catalog above]
Subtle Evidence Layer:
- Ambiguous Patch Status: Some servers show partial IIS updates from weeks earlier, requiring detailed analysis to determine if specific buffer overflow vulnerability is addressed - not immediately obvious which systems are truly vulnerable
- Research Data Exposure Patterns: Faculty research servers showing access patterns that could be legitimate international collaboration OR data exfiltration - requires correlation across multiple log sources and understanding of academic workflow patterns
- Worm Variant Identification: Multiple Code Red variants with subtle behavior differences - requires recognizing whether defacement pattern, scanning behavior, or payload indicates CodeRed.A, CodeRed.B, or CodeRed.II
- Network Performance Baseline: Difficulty distinguishing worm scanning traffic from legitimate academic research network activity (bioinformatics, astronomical data, distributed computing projects all generate massive network traffic)
Red Herrings:
- Legitimate System Updates: University IT scheduled automated Windows updates for departmental servers starting the same day - generates system restarts and service disruptions unrelated to worm
- Research Project Traffic: Computer Science department running legitimate security research project scanning campus network for vulnerability assessment - generates alerts similar to worm propagation
- Previous Web Defacement: 3 weeks ago, student hackers defaced single departmental website as prank - creates confusion about whether current incident is related or coincidental timing
- Bandwidth Crisis: University network experiencing legitimate bandwidth saturation from students downloading course materials at semester start - makes it harder to identify worm scanning traffic impact
Expert-Level Insights:
- Memory-Only Persistence Strategy: Recognizing that Code Red’s lack of disk persistence is both a weakness (cleared by reboot) and a strength (minimal forensic footprint, difficult to detect with traditional antivirus)
- Academic Calendar Exploitation: Understanding that attacker (or automated worm timing) likely didn’t target registration period deliberately - but the coincidental timing reveals university’s vulnerability prioritization patterns
- Internet Infrastructure Role: Recognizing that university’s position as academic network hub means infected systems have disproportionate impact on educational technology infrastructure globally
- Worm Evolution Pattern: Understanding Code Red’s progression from .A (scanning, defacing) to .B (DDoS payload) to .II (backdoor installation) indicates need to identify specific variant for appropriate response
Response Evaluation with Innovation Requirements
Standard Approaches (Baseline):
- Isolate infected servers to stop propagation
- Deploy emergency IIS patches to vulnerable systems
- Reboot servers to clear memory-only infection
- Restore services from backups
- Monitor for reinfection
Why Standard Approaches Are Insufficient:
- Academic Mission Constraints: Standard “isolate everything” approach conflicts with 10,000 students needing registration access during time-sensitive deadline - requires creative service continuity
- Distributed Ownership: 200+ departmental websites managed by different academic units with varying technical expertise - centralized patching approach may not account for departmental autonomy and custom configurations
- Research Data Sensitivity: Standard backup restoration doesn’t address potential research data exposure requiring forensic analysis and faculty notification - compliance and academic integrity considerations
- Internet Reputation Impact: Standard incident response focuses on internal operations but doesn’t address university’s role as responsible internet infrastructure provider - requires proactive academic community engagement
- Time Pressure: Registration deadline creates pressure to restore services quickly, potentially leading to insecure shortcuts - need innovation in balancing speed with security
Innovation Required:
Hybrid Service Architecture:
- Creative Approach Needed: Design temporary isolated registration environment using non-IIS technology while remediating main infrastructure - requires rapid deployment of parallel systems
- Evaluation Criteria: Does the solution maintain registration capability while preventing continued attack participation? Is data synchronization strategy viable? Can it be implemented within available timeframe?
Distributed Response Coordination:
- Creative Approach Needed: Develop federated patching approach that respects departmental autonomy while ensuring comprehensive vulnerability remediation - possibly department-by-department coordination with central oversight
- Evaluation Criteria: Does the approach balance centralized security needs with decentralized academic culture? Are departmental web administrators equipped to execute? What fallback exists for non-compliant departments?
Academic Community Leadership:
- Creative Approach Needed: Position response as academic cybersecurity research contribution - share findings with CERT/CC and other universities, publish post-incident analysis for educational community benefit
- Evaluation Criteria: Does the approach transform reputation risk into academic leadership opportunity? Are information sharing mechanisms appropriate (timing, detail level, audience)? Does it support other universities facing similar challenges?
Forensic Research Data Assessment:
- Creative Approach Needed: Develop rapid triage approach to assess 15 departmental research servers for potential data exposure - balance thoroughness with time constraints, determine faculty notification triggers
- Evaluation Criteria: Is the assessment methodology sound given time pressure? Are notification criteria appropriate for academic research sensitivity? Does approach protect research integrity while respecting faculty ownership?
Network Security Status Tracking
Initial State (100%):
- 200+ departmental web servers running IIS during fall registration period
- Vulnerability known but patches delayed for operational reasons
- Normal academic network traffic patterns with high student access
Degradation Triggers:
- Hour 0-2: Initial infection spreads autonomously through vulnerable IIS servers (-20% per hour unchecked)
- Hour 2-4: Infected servers begin participating in coordinated internet attacks (-10% per hour of reputation)
- Hour 4-8: Media attention and academic community awareness of university as attack source (-15% reputation)
- Hour 8+: Registration deadline pressure increases, student impact grows (-10% per hour of academic mission capability)
Recovery Mechanisms:
- Network Isolation: Stops propagation and attack participation (+30% containment, -15% service availability)
- Emergency Patching: Prevents reinfection of remediated systems (+40% security, -10% service availability during deployment)
- Memory Clearing (Reboot): Eliminates current infection (+20% immediate improvement, -5% service availability, BUT -30% security if done without patching)
- Service Restoration: Returns academic capability (+25% mission success, requires secure baseline)
- Academic Coordination: Shares information with educational community (+15% reputation, demonstrates leadership)
Critical Thresholds:
- Below 70% Security: University continues attack participation, reputation damage accelerates
- Below 50% Service: Registration deadline jeopardized, student academic progress at risk
- Below 40% Security: Reinfection cycle established, response effectiveness declining
- Below 30% Reputation: Academic community trust damaged, partnership impact extends beyond technical incident
Consequences:
- Excellent Response (>80% across metrics): Registration completed successfully, vulnerability eliminated, academic community leadership demonstrated, incident becomes cybersecurity education case study
- Good Response (60-80%): Services restored with some disruption, vulnerability addressed, reputation maintained with minor damage
- Adequate Response (40-60%): Extended service disruption but registration salvaged, security improved but trust damaged
- Poor Response (<40%): Registration deadline missed, continued vulnerability, significant reputation damage in academic community