AI in Network Defense

Why it matters

AI is changing security operations faster than most training material admits. On a growing list of bounded tasks, current models already work faster than a typical analyst and often more accurately. That gap will keep widening, and pretending otherwise does a new analyst no favors.

What does not move to the model is the part of incident response that sits between people and decisions. As models take on more of the analysis, that work becomes a larger share of the job, not a smaller one.

What analysts see

Models already do this work in many SOCs.

• Alert triage and enrichment. First-pass triage is mostly gathering context: is this address known to be malicious, has this account done anything else unusual this week, does this file hash match known malware. Models do this at a volume and speed no team can match, and rank what is left so human attention goes to the alerts most likely to matter.
• Playbook execution. Once an incident is confirmed, much of the response is mechanical: isolate a host, disable an account, collect a defined set of logs. Automation runs those steps in seconds. Deciding whether to run the playbook, and accepting what it will disrupt, stays with a person.
• Detection engineering. Drafting a rule, testing it against history, tuning out false positives and repeating is an iteration loop that models speed up considerably. Deciding what a detection must catch, how much noise the team can live with, and whether it is ready to ship is still an engineering judgment.
• Checking analysis. A model can compare a conclusion against the evidence behind it and flag gaps, contradictions and unsupported claims. It is a fast second reviewer, not the person who signs off on the finding.
• Report drafting. Turning raw notes and a timeline into a clear write-up for engineers or for executives is a separate skill from the investigation, and a strong use for a model. The analyst reviews it, corrects it and owns what it says.

In every one of these, a person still decides, signs off or owns the result.

Core concept

Orchestrating the response. An incident is a coordination problem as much as a technical one. Someone sets priorities, assigns work across the SOC, IT, legal and the business, tracks what is done and what is still open, and decides when the incident is contained and when it is closed.

Working with people. Talking to the people caught up in the incident, explaining risk to a system owner who does not want downtime, briefing leadership, handing over cleanly to the next shift. None of this is a log query, and all of it shapes the outcome.

Knowing the organization. Which systems are critical, which accounts are expected to behave oddly, who can approve isolating a production server, what a regulator needs and by when. Much of this context is not written anywhere a model can read, and what is written is often out of date.

Judgment and accountability. Containment decisions trade security against business disruption, usually with incomplete information and a clock running. A model can recommend. A person decides and answers for the decision.

Validating the output. Models produce wrong answers in the same confident tone as right ones. In security, an unchecked wrong answer means containing the wrong host, missing the real one, or reporting a finding that does not hold up. Adversaries also study these tools and shape their activity to slip past or mislead them. Catching that takes someone who knows what correct looks like in the raw data.

The analysts who stay valuable are the ones who can direct AI tools and catch them when they are wrong. It is not a stance against AI. It builds the foundation that makes AI assistance safe to rely on, and the habits a real response depends on: scoping, evidence and clear conclusions.

Annotated examples

How to investigate

1. 1.

   Read the claim precisely.

   Note exactly what the model asserts: which host, account, time window, and whether it claims something happened or did not.

2. 2.

   Find the records that would prove it.

   Search the raw data for the same host and window yourself.

3. 3.

   Test absence claims hardest.

   "Nothing happened" is the claim most often wrong, and the one most costly to repeat.

4. 4.

   Decide, then own it.

   Accept, correct or reject the claim, and write your conclusion with the evidence behind it.

Common mistakes

• Mistake: Repeating a model's summary in your report unchecked.

  InsteadVerify each factual claim against the records first.

• Mistake: Trusting a confident tone.

  InsteadJudge the claim by the evidence, not by how it is phrased.

• Mistake: Accepting "no activity" without searching.

  InsteadSearch the host and window yourself.

• Mistake: Letting a model decide containment.

  InsteadUse its recommendation as input; the decision stays with a person.

• Mistake: Handing off raw-data work too early in your career.

  InsteadBuild the skill of reading telemetry first, so you can catch the model when it is wrong.

Field references

Apply it in a Case

On your next case, write your conclusion for one objective, then try to disprove it from the raw data before you submit. Treat your own summary the way you would treat a model's.

• CuckooSkills: SIEM searchTelemetry: Windows · Sysmon
• GhostwriterSkills: Evidence and reporting · SIEM searchTelemetry: Windows · Sysmon
• DragnetSkills: Evidence and reporting · SIEM search

References

• AI Risk Management Framework · NIST
• MITRE ATLAS · MITRE
• OWASP Top 10 for LLM Applications · OWASP Gen AI Security Project