Gains:
- Understand that artificial intelligence summarizes and clusters thousands of log lines, establishes a timeline and highlights suspicious patterns, but the analyst decides that the event is a real attack with the raw log
- Ability to apply baseline (normal behavior) when evaluating a SIEM alarm and how to eliminate false positives without context and how the anomaly cannot be interpreted
- Ability to acquire the habit of verifying the chain of events established by artificial intelligence in the raw log and removing spurious correlations
A security analyst spends most of his day reading logs. A log is a line of text that timestamps what happened on a system: who logged in when, which file was accessed, which connection was rejected. The problem is not that there is too little log, it is that there is so much of it that it is suffocating. A medium-sized organization produces hundreds of millions of log lines per day. In this pile, the trace of a real attack is the needle in the haystack. SIEM (Security Information and Event Management - the system that collects and correlates logs from different sources in a single center and produces rule-based alarms) is there to find this needle; but most of the alarms that SIEM generates are also false positives (futile alarms that are not actually threats). The real job of the analyst is to extract the real signal from this noise.
Artificial intelligence is a powerful aid in this sorting. It can read thousands of log lines in seconds and summarize them in human language, cluster recurring patterns, describe a chain of events as "first this happened, then that," and explain why an alarm seems suspicious. But the AI doesn't know what the log means within the context of the institution: "access at 3am" is an attack in one institution, a night shift normal in another. So the AI summarizes and flags the log, but the analyst decides whether an event is a real attack and verifies it with the raw log.
Steps of log analysis
Here's how you run a step-by-step log/SIEM analysis with AI:
- Collect and anonymize. Remove the relevant log fragment; replace actual IPs, usernames, internal hostnames with placeholders (USER_A, IC_IP_1). Never export raw data as is to an external tool.
- Give the context. Tell the AI the source of the log (firewall, Windows event log, web server), what normal behavior is, and what you're looking for. Log analysis without context is misleading.
- Summarize and aggregate. Ask the AI to group thousands of rows by event types, extract occurrence counts, and create a timeline.
- Have suspicious patterns flagged. Highlight patterns such as "one successful login after unsuccessful logins", "many file accesses in a short period of time", "network connection belonging to an unknown process".
- Verify with raw evidence. Find and confirm each pattern that the AI flags in the actual log lines. Also scan for yourself the areas that the AI misses.
- Decision and registration. Declare the actual event as an analyst, open a ticket, and document that the AI is merely an accelerator.
A few terms: Log source is the system that produces the log. Correlation is bringing together events from different sources and making sense of them (VPN login + file access + data transfer = possible leak). A baseline is a measure of the normal behavior of a system; Anomaly only makes sense relative to the baseline. UEBA (User and Entity Behavior Analytics) is an AI-based approach that learns the normal behavior of each user and flags deviation.
comparison chart
Approach
How does it work
strong point
weakness
Rule based SIEM
Fixed "if-then" rules
Transparent, explainable
Misses unknown attack, lots of false positives
Signature based detection
Matches known bad pattern
Fast on known threat
Blind to new/changed attack
Anomaly/UEBA (AI)
Finds deviation from normal
Can capture the unknown
Anomaly = not attack; risk of false positives
Summarization with AI
Summarizes the log in language
Speed, readability
No context, risk of hallucination
Analyst (human)
Comments with context
decision, responsibility
Slow, gets tired, doesn't scale
The right setup is not to pick one but to layer: SIEM and signature roughly filter out the noise, AI summarizes and highlights, analyst verifies and decides.
three mini cases
Case 1 — 50,000 lines, 6 minutes. An analyst anonymizes 50,000 lines of access logs from a web server to the AI. The AI deduces that a single external IP crawled /admin routes with 12,000 requests in 3 hours, tried 480 different parameters, and received 200 responses 3 times. The analyst finds these 3 successful requests in the raw log, verifies it is a real path enumeration attack, and blocks the IP. Reading 50,000 lines by hand would take hours; The summary cut it down to 6 minutes, but it was the analyst's decision.
Case 2 — Contrived correlation. Another analyst tells the AI, “describe the attack chain in this log.” The AI constructs a fluid story: "At 02:11, USER_B elevated privilege and exported the data." The analyst opens the raw log before writing it in the report; whereas in the log there is neither privilege escalation nor data transfer — the model fits a typical chain of events into the “attack story.” The analyst extracts the claim. Lesson: Every chain the AI tells should be verified in the log.
Case 3 — Night shift false positive. A UEBA model flags a user accessing 900 files at 3 a.m. as a "high-risk anomaly." The analyst checks the context: the user is a backup operator and this job runs at 03:00 every night; The baseline was not looked at. The alarm is a false positive. The analyst sets the rule and adds this operator to the exception list. Anomaly is not always an attack; Without context, alarm is noise.
Weak prompt / Strong prompt
Weak prompt:
Examine this log, tell me if there is an attack.[10.14.2.7 - ahmet.yilmaz - 200 - /admin ...]
This prompt contains the real IP and user (privacy violation), does not tell the log source and normal behavior, does not ask the AI for evidence and false positive evaluation. AI can mislead you with a single sentence, "yes, there is an attack."
Powerful prompt:
Your role: Assistant to SOC analyst preparing analysis DRAFT. Don't decide, don't declare an attack. This is an anonymized accesslog of a web server (IPs and users are masked). Normal traffic: 100-300 requests/hour during business hours, mostly /product and /cart routes. Your task: (1) cluster events by type and source, give number of occurrences, (2) flag patterns that deviate from baseline, (3) show for each flag which log lines it is based on, (4) write down the probability of a false positive for each and why. Fitting line/IOC insertion; Mark "[analyst verify]" where you are not sure.[anonymous log here]
The strong claim limits the role, provides context and baseline, and requires engagement with evidence and evaluation of false positives.
Copiable prompt templates
LOG SUMMARY TEMPLATEThe following anonymous [log source: e.g. Summarize the [firewall] log: (1) group by event types and give the number of occurrences of each group, (2) extract the number of unique source/targets, (3) establish a timeline (first-last event, peak hours), (4) list the 5 prominent anomalies with an evidence line. Decision making; just in summary. Log: [paste]
CORRELATION TEMPLATECorrelate anonymous events over time and entity and construct a possible chain of events; BUT, for each step, indicate which log line it is based on, and mark the step that has no basis as "[no basis - must be verified]". Write an alternative well-intentioned explanation as well. Events: [paste]
FALSE POSITIVE ELIMINATION TEMPLATEFor this alarm, generate at least 3 well-intentioned (false positive) explanations for the attack interpretation and write down what additional log/evidence I need to look at to verify each one. Then determine which additional evidence is in favor of the attack and which is against it. Alarm: [paste]
TIMELINE EXTRACTION TEMPLATE: A single chronological timeline is extracted from these anonymous logs: each line in the format [time] [entity] [event] [source log]. Adding an event without a timestamp. Don't make up the gaps; If missing, write "[missing]". Logs: [paste]
Common mistakes
- Analysis without context. Comments made without mentioning the log source and normal behavior (baseline) are misleading; "anomaly" gains meaning with context.
- Not verifying the chain established by the AI. The model can connect ordinary events to an attack story; Confirm each step in the raw log.
- Mistaking an anomaly for an attack. The sign of UEBA is a hypothesis; Eliminate innocent causes such as backup, maintenance, new software.
- Exporting raw data without masking. The real IP/user/host is both a KVKK violation and a network map gift to the attacker.
- Don't trust the negative summary and stop browsing. Run your own systematic query (critical incident types, new IOCs) even if the AI says "nothing important".
Tip: Always ask to "show evidence line" when having the AI summarize the log. Do not take seriously any finding without a line of evidence; This one rule cuts out most hallucinations.
Caution: Dismissing a SIEM alert just because the AI said "false positive" could be covering up a real attack. Also independently check the alarm that the AI calls "unimportant"; The closure decision belongs to the analyst and is recorded.
In summary
The essence of log and SIEM analysis is to extract the real signal from a huge pile of noise. In this sorting, AI summarizes the log in seconds, clusters patterns, establishes a timeline, and highlights the suspect — but does not know the institutional context and can make up events. So the correct setup is layered: the rule/signature roughly sifts, the AI summarizes and flags, the analyst verifies with the raw log and makes a decision. Three principles protect you: context (no anomaly interpreted without baseline), evidence (each finding is tied to the raw log line), independent control (what the AI calls "clean" area is also scanned). And always work anonymized.
Application task
Take a sample log fragment (either anonymized from your own system or from a sample data set). First, summarize it to AI with the "Log Summarization" template. Then apply the “False Positive Elimination” template for each of the three most notable findings and verify each finding yourself in the raw log. Finally, note the differences between the AI's summary and your raw reading: What did the AI miss, what did it make up, what did it get right?
checklist
- [ ] I anonymized the log; real IP/user/host masked.
- [ ] I gave the AI the log source and normal behavior (baseline).
- [ ] I requested an evidence log line for each finding and verified it in the raw log.
- [ ] I confirmed every step of the chain of events established by the AI, weeding out the fabrication.
- [ ] I considered at least one false positive explanation for each alarm.
- [ ] I also scanned the areas that the AI calls "clean/unimportant".
- [ ] As the analyst, I made the decision and the incident record; I documented AI as an accelerator.