A comprehensive study guide covering SIEM dashboards and KPI metrics, four analysis and detection methods, trend analysis types, correlation rules vs. queries, regular expressions, grep and piping commands, scripting tools, and hands-on log filtering with Security Onion and Squert.
Objective 1.3 — Use tools & techniques to determine malicious activityObjective 4.1 — Vulnerability management reporting & communication
A SIEM dashboard is a console that presents selected security information in an easily digestible visual format. Analysts working in a SOC or CSIRT use it to triage alerts, escalate true positives, dismiss false positives, review data feed health, identify threat hunting opportunities, and track vulnerability posture.
Four visualization widget types
🥧
Pie chart
Relative proportions — e.g. severity class distribution (75% severity-2 events)
📈
Line graph
Log counts or event volumes over time — reveals trends and spikes
📊
Bar graph
Compare categories — critical vs. high vs. medium vs. low urgency event counts
⏱️
Gauge / trending
Current level vs. threshold — e.g. Splunk trending panels showing up/down arrows with a large count and direction indicator
📋
Table
Top N or bottom N events — the highest-volume event types, most active source IPs
Key performance indicators (KPIs) — what to measure
A KPI (Key Performance Indicator) is a quantifiable measure used to evaluate success against defined objectives. Security dashboards surface KPIs relevant to the organisation's threat posture. The right KPIs depend on the viewer's role — an analyst cares about alert queues; a manager cares about training completion rates.
Number of vulnerabilities found
Number of failed logons
Number of vulnerable systems
Number of security incidents
Average incident response time
Average ticket resolution time
Number of outstanding issues
Number of trained employees
Percentage of testing completed
External threat level indicators
Build dashboards per role. An analyst needs real-time alert queues and event details. A manager needs compliance percentages and trend lines. An executive needs aggregate risk posture. Showing irrelevant KPIs is not just useless — it distracts and erodes trust in the dashboard. Most SIEM platforms support role-based dashboard access control.
2
Analysis & Detection — Four Methods
When the SIEM ingests data, it applies rules and algorithms to match events and generate alerts. Analysts then triage these alerts — dismissing false positives and escalating true positives. Four distinct detection methods underpin this process, each with different strengths and limitations.
Conditional
Signature / rules-based
Simple correlation using if/then/and/or logic against exact signatures or rule conditions. Very clear-cut — when a rule fires, the reason is explicit. Dependent on existing signatures.
✅ Fast, explicit, low compute ⚠️ Blind to zero-days, many false positives from generic rules
Heuristic
ML-based / similarity matching
Uses machine learning to detect events that resemble known-bad patterns without requiring an exact signature match. Finds modified or obfuscated attacks that evade exact rules.
✅ Finds near-miss variants, self-improving ⚠️ Requires trained data set, ML overhead
Behavioural
Device-specific baseline
Creates a baseline of normal behaviour for a specific device or user. Alerts when observed behaviour deviates beyond a defined tolerance band from that device's own baseline.
✅ Catches novel attacks on known systems ⚠️ High false positives until model is tuned
Anomaly
RFC / industry standard baseline
Alerts when traffic deviates from published standards (RFCs) or universal industry norms — not the device's personal baseline. Example: a "ping of death" violates ICMP RFC packet size rules.
✅ Protocol-level violation detection ⚠️ Does not adapt to the specific device
Behavioural vs. Anomaly — the key distinction: Behavioural analysis records expected patterns in relation to the specific device being monitored. Anomaly analysis uses prescribed external standards (RFCs, industry norms) that all devices should follow. A behavioural baseline is custom-built per device; an anomaly baseline is universal.
Trend analysis is the process of detecting patterns within a dataset over time and using those patterns to make predictions about future events or understand past ones. A single log event tells you almost nothing — but a series of events over time reveals patterns, anomalies, and attack campaigns that would be invisible in any individual entry.
Frequency-based
Establishes a baseline for how often a given event occurs and monitors for deviations. Example: a shift change at 7 AM shows as a login frequency spike — expected. A spike at 3 AM is not — investigate. Endpoint alerts followed by rising threat counts suggest an active campaign.
Volume-based
Measures the size of something rather than the count — disk usage, network transfer volume, log file size. Example: database server network utilisation jumps from 40 MB to 800 MB (20× increase) without a corresponding business explanation — possible data exfiltration.
Statistical deviation
Uses mean and standard deviation to identify outliers. A data point far outside the expected distribution triggers investigation. Example: a user account logging into 4.5 systems simultaneously when the mean is 1 — statistically anomalous and flagged.
Sparse attacks — why trend analysis matters for slow campaigns
Attackers using a sparse attack technique deliberately spread their activity over long timeframes to stay below detection thresholds. A single failed login per day never triggers a brute-force alert tuned to "3 failures in 30 minutes." Six months later, when the password is guessed and the attacker begins exfiltrating data, the volume spike is what finally reveals them.
The sparse attack lesson: Tuning detection thresholds too aggressively to reduce false positives creates windows for slow attackers. Volume-based trend analysis on data transfer can catch exfiltration even when the initial access used a sparse approach too subtle for threshold-based rules.
Narrative-based threat intelligence as trend analysis
Long-form narrative reports (from Ch.3) are themselves a form of trend analysis — they identify patterns across many observed incidents over time and produce actionable recommendations. Example: researchers observed IRC being used as a C2 mechanism across many attacks → trend report → organisations block IRC → attackers shift to HTTPS tunnels → new report needed. The cycle demonstrates that trend analysis must continuously evolve as adversaries adapt.
4
Correlation Rules vs. SIEM Queries
Two mechanisms drive the analytical capability of a SIEM: rules that watch for conditions in real-time, and queries that search historical stored data on demand. Understanding the difference — and when to use each — is critical for both exam scenarios and real-world analysis.
Correlation rule
Real-time, alert-generating
A statement that matches certain conditions (expressed as logical AND/OR/IF operators with comparison operators) as data is ingested. Fires an alert immediately when the condition is met. Data must be held in memory as persistent state — for a "3 failures within 1 hour" rule, all login events must stay in memory for up to 1 hour. Resource-intensive on large networks.
SIEM query
On-demand, historical search
Searches the stored data repository for matching records. Returns results when you run the query — not in real-time. Can search back minutes, hours, months, or years depending on your retention period. More efficient for long-term historical analysis than correlation rules that must maintain memory state continuously.
Correlation rule example
SIEM correlation rule — brute-force detection
# Alert when a single user has 3+ login failures within 1 hour
IF Error.LogonFailure > 3 AND LoginFailure.User = [same_user] AND Duration < 1 hour THENALERT: Possible brute-force on [user]
# ⚠ Requires login failure events held in memory for up to 1 hour # ⚠ On large networks this rule may need data held for millions of events
SIEM query example
SIEM query — same condition, searched on-demand
# Equivalent search across all stored data
SELECT user WHERE Error.LogonFailure > 3 AND LoginFailure.User = [same_user] AND Duration < 1 hour ORDER BY date, time DESC
# Returns results from the entire data store — days, months, or years back # No persistent memory state required — runs against indexed storage
Which to use: Use correlation rules for threats where immediate alerting is critical (active brute force, C2 beacon). Use queries for hunting — searching historical data for indicators you discovered after the fact, or for trend analysis over long periods. Most mature SIEM deployments use both.
5
Regular Expressions (Regex) — Quick Reference
Regular expressions (regex) are a syntax for describing patterns used to search text. They are used inside SIEM correlation rules, grep commands, and most scripting languages. They allow extremely precise and flexible searches through log data at a scale no human could replicate manually.
Exam scope: You do not need to be a regex expert. You may be shown a regex string and asked to identify what it matches. Read it character by character using the reference below — most exam regex questions are solvable by working through the syntax methodically. Practice at regexr.com.
regex quick reference — CySA+ exam essentials
[a-z]
Single character from range — lowercase letter [A-Z] = uppercase, [0-9] = digit
\s
Single whitespace character (space, tab) \S = non-whitespace
\d
Single digit [0-9] \D = non-digit character
+
Quantifier — one or more of the preceding \d+ = one or more digits
*
Quantifier — zero or more of the preceding \d* = zero or any number of digits
?
Quantifier — zero or one of the preceding \d? = zero or exactly one digit
{n}
Exactly n occurrences \d{3} = exactly 3 digits
{n,m}
Between n and m occurrences \d{7,10} = 7 to 10 digits (US phone)
( )
Capture group — referenced as \1, \2, etc. (\d+) captures a digit sequence as group 1
|
Logical OR — matches either side cat|dog = matches "cat" or "dog"
^
Anchor — match only at start of line ^ERROR = lines beginning with ERROR
$
Anchor — match only at end of line \.log$ = strings ending in .log
\
Escape — treats next char as literal 192\.168 = matches "192.168" (dot = literal)
.
Wildcard — matches any single character Escape with \. to match a literal dot
Reading a complex regex — worked example
regex walkthrough — IP address pattern
# Goal: match 192.168.1.x where x is any valid octet (0-255)
192\.168\.1\.[\d]{1,3}
# Breaking it down: 192← literal "192" \.← escaped dot (literal period, not regex wildcard) 168← literal "168" \.← escaped dot 1← literal "1" \.← escaped dot [\d]{1,3}← any digit [0-9], repeated 1 to 3 times = 0–999
# More precise (valid IP only, restricts to 0-255): 192\.168\.1\.[0-255]
6
grep, cut, sort, head, tail & Piping
These Unix/Linux command-line tools form the analyst's basic toolkit for searching and processing log data outside a SIEM. Understanding them is essential for manual log analysis, threat hunting, and writing scripts. Windows equivalents: find (basic string search) and findstr (regex-capable).
grep — key options reference
Flag
Meaning
Use case
-F
Fixed string — treat search term as literal, no regex
Searching for an IP address without escaping dots
-i
Case-insensitive — matches regardless of capitalisation
Finding "error", "Error", "ERROR" with one command
-v
Invert — returns lines that do NOT match
Find all logins that were NOT the authorised user
-r
Recursive — search in current directory and all subdirs
Searching all log files at once
-w
Word — match only complete words, not substrings
Find "no" without matching "nano", "nowhere"
-x
Count only — returns the number of matches, not the lines
How many times did IP X contact server Y?
-l
File names with matches (lowercase L)
Which files contain this compromised password?
-L
File names WITHOUT matches (uppercase L)
Which log files don't contain this pattern?
Other essential log analysis commands
cut
Extract specific columns
cut -c5 = return character 5 of each line. cut -d" " -f1-4 = return first 4 space-delimited fields. Useful for isolating a specific field (IP, username, timestamp) from structured log lines.
sort
Reorder output
sort = alphabetical (A→Z). sort -r = reverse (Z→A). sort -n = numerical. sort -k2 = sort by column 2. sort -t"," -k2 = sort CSV by field 2. Combine with grep to order results.
head / tail
First or last 10 lines
head file = first 10 lines (oldest entries). tail file = last 10 lines (most recent entries — this is almost always what you want for logs). tail -f = live follow a log file as it grows.
Piping — chaining commands together
The pipe character (|) takes the output of one command and feeds it as input to the next. You can chain as many commands as needed — each one filters or transforms the data further, turning a large log file into exactly the information you need.
# Step 1: grep → find every line containing "NetworkManager" in syslog # Step 2: | cut → from those lines, keep only the first 5 space-delimited fields # Step 3: | sort → sort the trimmed output by the 3rd field (e.g. timestamp)
# Result: a clean, sorted list of NetworkManager events — far more readable # than the raw syslog output, extracted without any dedicated tool
grep — common analyst patterns
# Search current syslog for root access attempts $sudo grep root /var/log/syslog
# Search ALL syslog files (including rotated/gzipped) for root $sudo grep root /var/log/syslog*
# Case-insensitive search for "error" across all syslogs $sudo grep -i "error" /var/log/syslog*
# Find all logins that were NOT the expected user (invert match) $grep -v "jason" /var/log/auth.log
# Windows equivalent for basic string search C:\>find "error" logfile.txt # Windows regex-capable equivalent of grep C:\>findstr /R "192\.168\." access.log
Scripts automate recurring log searches, schedule nightly analysis runs, and encapsulate complex multi-step queries into a single reusable command. Individual commands are useful for one-off analysis; scripts make that analysis repeatable and schedulable.
Exam scope: You will not be asked to write scripts on the CySA+ exam. You may be shown a script snippet and asked to identify what it does. If you can read English, you can read the exam-level scripts — the keywords like grep, get-eventlog, and echo are self-explanatory in context.
Bash
Unix · Linux · macOS
Default shell and scripting language for Unix-like systems. Scripts start with #!/bin/bash (shebang). Supports variables, loops, conditionals, functions. Key for Linux log searching, cron-scheduled tasks, piped commands.
PowerShell
Windows
Windows scripting language with verb-noun cmdlets (Get-EventLog, Write-Host). Connects to Windows Event Logs directly. Windows equivalent of Bash for automation. Event ID 4625 = failed logon — queryable directly via PowerShell.
WMIC
Windows
Windows Management Instrumentation Command-line. Reviews logs on remote Windows machines. Query format: WMIC NTEVENT WHERE "logfile='security' AND eventtype=5" GET sourcename,timegenerated,message. Useful for remote forensics across a domain.
Python
Cross-platform
Interpreted, high-level, general-purpose language. No compilation — source is always readable text. Heavily used by analysts and penetration testers for parsing, searching, and automating complex workflows. PenTest+ goes deeper here.
Ruby
Cross-platform
Interpreted, high-level language. Similar scope to Python. Commonly used in penetration testing tooling (Metasploit modules are written in Ruby). Exam: just know it's a high-level scripting language.
AWK
Unix · Linux · macOS
Specialised scripting engine for extracting and modifying data from files or data streams. Single-purpose: data manipulation and field extraction. Example: awk '/manager/ {print}' employee.txt prints all employee records containing "manager".
Bash script pattern — extract and save log results
bash script — NetworkManager log extraction
#!/bin/bash← shebang: identifies this as a Bash script
echo"Pulling NetworkManager entries..."← print status to screen
grep NetworkManager /var/log/syslog |cut-d" " -f1-5> netman-log.txt # grep: find NetworkManager entries in syslog # | cut: keep only the first 5 fields # > : redirect output to file (save it)
# Get-EventLog: query the Security log, newest 5 entries, event ID 4625 (failed logon) # | Select-Object: keep only timestamp and message # | Out-File: save to text file
Write-Host"log-fail.txt has been created."
8
Filtering Logs with Security Onion & Squert
Squert is a web-based alert management interface bundled with Security Onion. It provides a time-windowed view of IDS/NIDS alerts, allows pivoting between alert data, packet captures, and Kibana, and enables the analyst to drill into specific events and correlate across data sources — all from one interface.
Squert analysis workflow
Step 1 — Events tab
Default view shows queued, unanalysed events. SC (source count) and DC (destination count) columns show event volume per hour. High counts indicate high-priority investigation targets.
Step 2 — Summary tab
Shows the most active signatures, IP addresses, and ports. Includes geolocation for public IPs (source country, destination country). Useful for rapid triage overview.
Step 3 — Drill into event
Click on a high-queue event to expand it and see each of the underlying alerts. Click an individual event ID to open the packet capture in CapMe — inspect the actual HTTP request, file download, or session content.
Step 4 — Pivot to Kibana
From any IP address in Squert, click to open Kibana with that IP as a search filter. This cross-tool pivot shows all data sources (HIDS, network, syslog) associated with that IP — demonstrating the SIEM's correlation value across sources.
The pivot power of a SIEM: In Squert, you see an alert → click the source IP → CapMe shows the packet → click the IP in CapMe → Kibana shows every data source (IDS, HIDS, Bro/Zeek, syslog) that has touched that IP. A single IP click chains across multiple data systems. This is the core value proposition of SIEM correlation that no standalone tool can replicate.
Manual log analysis with grep in Security Onion
terminal — grep workflow in Security Onion
# Navigate to primary Linux log directory $cd /var/log && ls← see all available log files
# Search current syslog for root access/commands $sudo grep root syslog
# Search ALL syslog files including rotated/archived ones # syslog.1 = last rotation, syslog.2.gz = older (gzipped) $sudo grep root syslog*
# Case-insensitive search for "error" across all rotated logs $sudo grep -i "error" syslog*
# Read the grep manual for all options $man grep← q to quit
Log rotation: Linux systems periodically rotate logs — the current file is syslog, the previous is syslog.1, and older files are compressed as syslog.2.gz, syslog.3.gz, etc. Using syslog* in grep searches all of them. If you only search syslog, you miss everything before the last rotation — potentially weeks of data.
Exam
Quick Reference Cheat Sheet
SIEM dashboard
Visualisation types: pie (proportions), line (trends over time), bar (category comparison), gauge/trending (level vs. threshold), table (top N events). Build per role — analyst ≠ manager ≠ executive views.
Four detection methods
Conditional = rules/signatures (explicit, but misses zero-days). Heuristic = ML similarity (catches variants). Behavioural = per-device baseline (custom normal). Anomaly = RFC/industry standard baseline (universal). Behavioural vs. anomaly: whose standard? Device's vs. RFC's.
Trend analysis types
Frequency = how often. Volume = how much (size/bytes). Statistical deviation = how far from mean. Sparse attacks hide in noise — trend analysis catches eventual exfiltration spikes. Narrative reports = longform trend intelligence.
Rules vs. queries
Correlation rule = real-time alert on data ingestion, requires persistent memory state (resource-intensive). SIEM query = on-demand search of historical stored data, no memory state, can search entire retention period.
Regex essentials
[a-z] char range. \d digit. + one+. * zero+. ? zero/one. {n,m} n to m. ( ) group. | OR. ^ start. $ end. \. literal dot. Practice at regexr.com.
grep flags
-F fixed/literal. -i case-insensitive. -v invert (NOT). -r recursive. -w whole word. -x count only. -l file names with matches. -L file names without matches. Windows: find / findstr.
Pipeline commands
cut -d" " -f1-5 = fields 1–5 delimited by space. sort -k2 = sort by column 2. head = first 10 lines. tail = last 10 lines (most recent logs). | = pipe output as input to next command.
Scripting tools
Bash = Unix/Linux/macOS (starts with #!/bin/bash). PowerShell = Windows (verb-noun cmdlets). WMIC = remote Windows log queries. Python/Ruby = interpreted, cross-platform, general purpose. AWK = data extraction from files/streams on Unix systems.
Security Onion / Squert
Squert = web alert console. SC = source count, DC = destination count. Events → Summary → drill into event → CapMe for packet → pivot to Kibana by IP. syslog* wildcard searches all rotated log files. Grep is the manual search fallback.