Challenge 3: Deploy Logging and Auditing¶
Objective: Understand what security-relevant events are logged, analyse audit trails to detect attacks, and use log analysis tools to investigate incidents.
Category: Detection & Incident Response
Difficulty: Beginner-Intermediate
Time Required: 30-45 minutes
Learning outcomes¶
By completing this challenge, you will:
Understand what security-relevant events are logged in ICS environments
Query and filter audit logs to find specific events
Analyze log patterns to detect reconnaissance and attacks
Use log statistics to understand system activity
Export logs for external analysis
Balance signal vs noise in security logging
ICS logging¶
The Problem: You can’t detect attacks you don’t log. Without audit trails, incidents leave no forensic evidence.
What to Log:
Security Events: Authentication attempts (success/failure), authorisation failures, credential access
Operational Events: Setpoint changes, mode changes, alarms, system starts/stops
Control Operations: All write operations (Modbus, OPC UA, S7), safety system interactions
User Actions: Who did what, when, to which device, with what result
ICS Event Classification:
Severity: CRITICAL, ALERT, ERROR, WARNING, NOTICE, INFO, DEBUG
Category: security, safety, process, alarm, audit, system, communication, diagnostic
Current state¶
The simulation already has comprehensive logging integrated:
ICSLogger: Fully integrated across all 19 devices
Security Events: Auth attempts, write operations, safety bypasses
Operational Events: Setpoint changes, mode changes, alarms
Audit Trails: User attribution, before/after values, success/failure
Central Storage: All events stored in SystemState.audit_log
Learning to use the logging system to detect attacks.
Part 1: Understanding What’s Logged¶
Step 1.1: View Recent Audit Logs¶
Query the last 20 audit events:
python tools/blue_team.py audit query --limit 20
Example output:
Audit Log (20 entries):
========================
[ 15.2s] [ NOTICE] [ audit] [turbine_plc_1 ] operator1: Setpoint changed: speed_setpoint 1500.0 -> 1600.0
[ 14.8s] [ NOTICE] [ audit] [scada_server_1 ] operator1: SCADA tag configured: turbine_1_speed
[ 12.5s] [ WARNING] [security] [turbine_plc_1 ] 192.168.1.100: MODBUS WRITE: FC 06 to turbine_plc_1
[ 10.1s] [ NOTICE] [ audit] [engineering_ws_1 ] engineer1: PLC PROGRAMMING: programming turbine_plc_1
What to look for:
simulation_time: When the event occurred (simulation seconds)severity: How important is this event?category: What type of event is it?device: Which device generated the event?user: Who performed the action?message: What happened?
Step 1.2: Filter by Category¶
View only security events:
python tools/blue_team.py audit query --category security --limit 30
View only audit trail events (user actions):
python tools/blue_team.py audit query --category audit --limit 30
Step 1.3: Filter by Device¶
View events from a specific PLC:
python tools/blue_team.py audit query --device turbine_plc_1 --limit 30
View events from SCADA server:
python tools/blue_team.py audit query --device scada_server_1 --limit 30
Step 1.4: Filter by Severity¶
View only critical events:
python tools/blue_team.py audit query --severity CRITICAL --limit 50
View warnings and above:
python tools/blue_team.py audit query --severity WARNING --limit 50
Part 2: Detecting attacks in logs¶
Step 2.1: Test attack: Turbine overspeed¶
Run the turbine overspeed attack:
# Terminal 1: Start simulation
python simulation.py
# Terminal 2: Run attack
python scripts/exploitation/turbine_overspeed_attack.py
Question: Can you see the attack in the logs?
Query logs to find the attack:
python tools/blue_team.py audit query --device turbine_plc_1 --limit 50
What to Look For:
Unusual setpoint changes (speed > 1800 RPM)
Write operations from unexpected sources
Safety alarm triggers
Rapid sequence of changes (attack automation)
Step 2.2: Search for attack patterns¶
Search for “setpoint” changes:
python tools/blue_team.py audit search "setpoint"
Search for “write” operations:
python tools/blue_team.py audit search "write|WRITE"
Search for specific device or user:
python tools/blue_team.py audit search "turbine_plc"
python tools/blue_team.py audit search "operator1|engineer1"
Step 2.3: Filter by User¶
Who is modifying the turbine?
python tools/blue_team.py audit query --device turbine_plc_1 --user-filter operator1
Look for operations without a user (system/automated):
python tools/blue_team.py audit query --device turbine_plc_1 | grep -v "operator\|engineer"
Step 2.4: Time-based analysis¶
View events in a specific time window:
# Events after simulation time 100 seconds
python tools/blue_team.py audit query --since 100 --limit 100
# Events between 50-150 seconds
python tools/blue_team.py audit query --since 50 --until 150 --limit 200
Part 3: Log analysis and statistics¶
Step 3.1: View log statistics¶
Get overview of all logged activity:
python tools/blue_team.py audit stats
Example output:
Audit Log Statistics
======================================================================
Total Events: 1,247
Events by Category:
audit : 584 ( 46.8%)
security : 312 ( 25.0%)
process : 201 ( 16.1%)
alarm : 150 ( 12.0%)
Events by Severity:
CRITICAL : 12 ( 1.0%)
WARNING : 156 ( 12.5%)
NOTICE : 589 ( 47.2%)
INFO : 490 ( 39.3%)
Top 10 Devices by Event Count:
turbine_plc_1 : 287 ( 23.0%)
reactor_plc_1 : 198 ( 15.9%)
scada_server_1 : 156 ( 12.5%)
Top 10 Users by Event Count:
operator1 : 289 ( 23.2%)
engineer1 : 142 ( 11.4%)
security_admin : 67 ( 5.4%)
Analysis Questions:
Which devices generate the most events?
Which users are most active?
What percentage of events are security-related?
Are there any CRITICAL events that need investigation?
Step 3.2: Identify anomalies¶
Compare normal vs attack statistics:
# Baseline (before attack)
python tools/blue_team.py audit stats | grep -A 20 "Events by Category"
# During/after attack: run your attack, then check again
python tools/blue_team.py audit stats
Look for:
Sudden spike in security events
Increase in WARNING/CRITICAL severity
New devices or users appearing
Unusual event category distribution
Part 4: Exporting Logs for External Analysis¶
Step 4.1: Export to JSON¶
Export all logs to JSON for programmatic analysis:
python tools/blue_team.py audit export --format json
Output: audit_log_YYYYMMDD_HHMMSS.json
Export specific device:
python tools/blue_team.py audit export --format json --device turbine_plc_1
Step 4.2: Export to CSV¶
Export to CSV for spreadsheet analysis:
python tools/blue_team.py audit export --format csv
Output: audit_log_YYYYMMDD_HHMMSS.csv
Use Cases:
Excel/LibreOffice analysis
SIEM import
Timeline visualization
Compliance reporting
Step 4.3: Limited export¶
Export only recent events:
python tools/blue_team.py audit export --format json --limit 100
Export only security category:
python tools/blue_team.py audit export --format csv --category security
Part 5: Advanced detection scenarios¶
Scenario 1: Reconnaissance detection¶
Attack Pattern: Attacker scans devices, reads configurations, enumerates tags.
Detection:
Look for rapid sequence of read operations from same source
Multiple devices accessed in short time
Unusual device/tag enumeration
# Search for read operations
python tools/blue_team.py audit search "Read|read" --limit 100
# Filter by time window (reconnaissance phase)
python tools/blue_team.py audit query --since 0 --until 60 --category security
Scenario 2: Credential theft detection¶
Attack Pattern: Access to legacy systems with plaintext credentials.
Detection:
Search for credential extraction attempts
Check for SMB share access
Look for file access on legacy workstations
# Search for credential-related events
python tools/blue_team.py audit search "credential|password|SMB"
# Check legacy workstation activity
python tools/blue_team.py audit query --device legacy_workstation_1
Scenario 3: Safety system bypass¶
Attack Pattern: Disable safety interlocks, bypass emergency trips.
Detection:
Look for safety system interactions
Check for CRITICAL alarms
Find SCRAM or trip events
# Search for safety-related events
python tools/blue_team.py audit search "safety|SCRAM|trip|bypass"
# View critical events
python tools/blue_team.py audit query --severity CRITICAL
Scenario 4: Unauthorised PLC programming¶
Attack Pattern: Upload malicious logic to PLC.
Detection:
Search for PLC programming operations
Check engineering workstation activity
Look for unexpected DB/tag creation
# Find PLC programming events
python tools/blue_team.py audit search "PLC PROGRAMMING|program|upload"
# Check engineering workstation
python tools/blue_team.py audit query --device engineering_ws_1 --category audit
Part 6: Attack progression analysis¶
Exercise: Full attack chain detection¶
Run a multi-stage attack:
# Reconnaissance python scripts/exploitation/device_enumeration.py # Credential theft python scripts/exploitation/legacy_credential_harvest.py # Control manipulation python scripts/exploitation/turbine_overspeed_attack.pyAnalyse the attack timeline:
# View all recent events python tools/blue_team.py audit query --limit 200Build attack timeline:
Phase 1: What devices were scanned? (security events)
Phase 2: Were credentials accessed? (search “credential”)
Phase 3: What control actions were taken? (audit events)
Phase 4: Were alarms triggered? (category alarm)
Export for incident report:
python tools/blue_team.py audit export --format csv --since <attack_start_time>
Learning reflection¶
What? When? How?¶
Log Coverage:
What events are logged automatically?
What categories and severities exist?
Which devices generate the most logs?
Detection Capabilities:
Can you detect reconnaissance?
Can you detect credential theft?
Can you detect control manipulation?
Can you detect safety bypasses?
Analysis Skills:
Filter logs by device, category, severity, user
Search for patterns with regex
Correlate events across multiple devices
Build attack timelines
Trade-offs:
Log volume vs storage
Signal vs noise
Real-time vs batch analysis
Local vs centralized logging
Discussion¶
What to Log:
Is everything currently logged necessary?
Is anything missing from the logs?
How do you balance completeness vs performance?
Log Retention:
How long should logs be kept?
What if an attack isn’t detected for months?
How much storage is needed?
Real-Time Detection:
How would you detect attacks in real-time?
What events trigger immediate alerts?
How do you reduce false positives?
Integration:
How would you integrate with a SIEM?
What about correlation with IT security logs?
How do you protect logs from tampering?
Challenge success criteria¶
You can query audit logs with filters
You can detect reconnaissance in logs
You can detect credential theft attempts
You can detect control manipulation
You can build attack timelines
You can export logs for analysis
You understand log analysis trade-offs
Next steps¶
Challenge 4: Anomaly detection
Deploy automated anomaly detection
Detect abnormal turbine behaviour
Configure detection thresholds
Integrate with logging system
Challenge 6: Session management & dual authorisation
Implement session timeout
Require two-person rule for critical operations
Audit dual authorisation events
Integration:
Connect logs to SIEM system
Create real-time detection rules
Develop automated alerting
Implement log integrity checking
References¶
Log Analysis Best Practices:
ISA 62443-3-3: Security technologies for IACS
NIST SP 800-92: Guide to Computer Security Log Management
IEC 62443-4-2: Technical security requirements for IACS components
Tools:
Blue Team CLI:
python tools/blue_team.py audit --helpDataStore API:
data_store.get_audit_log()ICSLogger:
components/security/logging_system.py