Stop Treating AI Like It's the Next Code Red

The Conventional Wisdom

Security teams are revisiting their incident response playbooks from the worm era, convinced that lessons from Code Red, Nimda, and Slammer will help secure AI systems. The idea is compelling: just as we learned to patch faster and segment networks after those outbreaks, we should apply similar defensive strategies to AI deployments.

Marc Maiffret, known for analyzing Code Red's impact, has considered how those security lessons can help organizations manage AI risk today. The security industry has embraced this parallel, treating AI vulnerabilities like another category of exploitable code.

Why This Approach Falls Short

AI security isn't about patching known vulnerabilities in deterministic code. It's about managing systems whose behavior you can't fully predict or test.

Code Red exploited a buffer overflow in IIS. You could write a signature for it, patch the specific function, and verify the fix. The attack surface was defined by the codebase, and the remediation was technical and measurable.

AI models don't work that way. A prompt injection vulnerability isn't a bug in line 347 of a source file. It's an emergent property of how the model generalizes from training data. You can't patch it out or write a CVE for "model sometimes ignores system instructions when user input resembles training examples."

The worm-era playbook teaches you to:

• Identify vulnerable code paths
• Deploy patches within defined SLAs
• Verify remediation through testing
• Monitor for known attack signatures

None of these steps map cleanly to AI systems. You're securing a probability distribution, not a call stack.

The Evidence

Consider how organizations handle AI security incidents versus traditional vulnerabilities. When a SQL injection vulnerability appears, you:

1. Identify the specific code location
2. Write a test case that reproduces it
3. Implement a fix
4. Verify the test case now passes
5. Deploy to production
6. Confirm no regression

When someone demonstrates a jailbreak against your AI-powered chatbot, you:

1. Document the specific prompt that worked
2. Add it to your filter list
3. Hope the model doesn't respond to slight variations
4. Monitor for similar patterns
5. Accept that you're defending against an infinite input space

This isn't just a technical distinction. It changes your entire risk model. PCI DSS v4.0.1 Requirement 6.3.2 mandates reviewing custom code prior to release to identify security vulnerabilities. But what does "review" mean when your system's behavior emerges from 175 billion parameters rather than explicit logic?

The NIST Cybersecurity Framework talks about identifying and managing vulnerabilities. That framework assumes you can enumerate your attack surface. AI systems have attack surfaces that expand with every new use case and user interaction.

What to Do Instead

Stop trying to secure AI like it's vulnerable code. Start treating it like you're managing operational risk in a system with inherent uncertainty.

Build Guardrails, Not Patches. Your AI security architecture should assume the model will occasionally fail in unexpected ways. Design your integration so that when it does, the blast radius is contained. If your AI assistant can query your customer database, don't rely on prompt engineering to prevent data exfiltration. Enforce query limits, output filtering, and access controls at the infrastructure layer.

Instrument Everything. You can't predict what will go wrong, but you can detect when something unusual happens. Log every input, output, and decision point. Monitor for statistical anomalies in how the model is being used. When someone finds a jailbreak, you want telemetry showing whether anyone else discovered it first.

Define Acceptable Failure Modes. Code Red either infected your server or it didn't. AI systems fail on a spectrum. Your security program needs explicit thresholds for what constitutes a security incident versus expected model limitations. Document scenarios like: "If the model reveals PII in fewer than 0.1% of interactions, that's a monitoring alert. If it exceeds 1%, that's an incident."

Test for Resilience, Not Correctness. Traditional security testing looks for specific vulnerabilities. AI security testing should verify that your controls degrade gracefully under adversarial conditions. Can an attacker make your chatbot slow enough to cause a denial of service? Can they extract training data through carefully crafted queries? Your test plan should explore the boundaries of model behavior, not just check for known exploits.

Separate Model Risk from Integration Risk. You can't fully control what the model does, but you can control how it connects to your systems. Apply the same rigor to your AI integration layer that you would to any third-party API. Rate limiting, input validation, output sanitization, and least-privilege access all apply. ISO 27001 Control 8.3 (information security in supplier relationships) is more relevant here than most AI-specific guidance.

When the Conventional Wisdom Is Right

The worm-era lessons aren't useless. They're just not sufficient.

Speed matters. When you discover that your AI system is leaking sensitive data or can be manipulated to bypass access controls, your incident response needs to be as fast as it was when Code Red was spreading across your network. Having runbooks, communication channels, and rollback procedures ready is still essential.

Defense in depth works. Just as you didn't rely solely on perimeter firewalls to stop worms, you shouldn't rely solely on prompt engineering to secure AI. Layer your controls: input filtering, output validation, runtime monitoring, and manual review for high-risk actions.

Patching fundamentals still apply. Your AI system runs on infrastructure with known vulnerabilities. The model might be probabilistic, but the containers, APIs, and databases supporting it are deterministic code that needs regular updates. Don't get so focused on novel AI risks that you ignore the SQL injection vulnerability in your model feedback collection endpoint.

The real lesson from Code Red isn't about specific defensive techniques. It's about staying ahead of threats that evolve faster than your security program. That mindset absolutely applies to AI. Just don't expect the same tactical playbook to work against a fundamentally different kind of risk.