I4.8 Log Review Lab
Apply the full Module I4 workflow to a fictional multi-source case: define scope, inventory evidence, normalize timestamps, correlate events, classify patterns, build findings, prioritize action, and write a professional defensive report.
Lesson Progress
Log Review Lab
High School Intermediate • I4: Logs and Event Monitoring • Lesson 8 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Good Analyst Can Separate One Busy Time Window into Several Accurate Stories
Multiple alerts can appear close together without sharing one cause. The professional task is not to force them into one dramatic incident. It is to determine which records belong together, which are parallel, which are expected, which require escalation, and which remain evidence-incomplete.
Weak response
“Several alerts happened this morning, so they must be one coordinated attack.”
Strong response
“Build separate evidence chains, test shared identifiers, compare owners and changes, classify relationships, and merge events only when the evidence supports it.”
Objective 1
Apply the complete fictional log-review workflow from scoping and source inventory through normalization, correlation, pattern analysis, timeline construction, findings, and safe recommendations.
Objective 2
Interpret authentication, system, application, network, web, endpoint, change, support, and monitoring evidence as one connected defensive case.
Objective 3
Separate confirmed facts, corroborated facts, reasonable conclusions, alternate explanations, evidence gaps, unsupported claims, confidence, impact, and residual risk.
Objective 4
Prioritize findings using evidence strength, privilege, scope, persistence, business impact, control outcome, owner context, and time sensitivity.
Objective 5
Create a professional fictional Multi-Source Log Review Report that is clear, reproducible, privacy-protective, and suitable for a student cybersecurity portfolio.
Why This Matters
Integrated Log Review Turns Separate Technical Clues into Defensible Decisions
Real defensive work often combines identity, endpoint, system, application, network, web, change, support, and monitoring evidence. The reviewer must explain what happened, what did not happen, what remains unknown, and what action is justified.
Case Snapshot
Understand the Fictional Review Before Reading the Events
Environment
Fictional Northstar Learning Services training environment with identity, Windows-style endpoint, application, DNS, firewall, proxy, endpoint protection, change, support, and monitoring records.
Primary question
Did the repeated failures, unusual web request, endpoint alert, and application outage represent one connected security event or several separate operational patterns?
Time window
08:00–10:30 UTC, including thirty minutes before the first alert and thirty minutes after recovery validation.
Important assets
training-laptop-52, report-app-2, identity-platform, proxy-1, firewall-1, endpoint-monitor, and the fictional cloud-report service.
Important identities
training-user-52, svc-report-training, support-owner-4, and application-owner-2.
Safety boundary
All users, devices, addresses, domains, paths, event IDs, tickets, alerts, and organizations are fictional and used only for read-only defensive analysis.
Source Inventory
Know What Each Evidence Source Can and Cannot Answer
Source
Identity platform
Owner
Identity team
Useful for
Password reset, sign-in success and failure, MFA, lockout, policy outcome, session creation, and account state.
Limitations
Does not prove physical identity, endpoint process, application purpose, or every later session action.
Source
Windows-style endpoint logs
Owner
Endpoint team
Useful for
Process, service, startup, update, local user, file, path, application, device health, and protection state.
Limitations
One six-minute segment is missing because the device was offline from the collector.
Source
Report application logs
Owner
Application team
Useful for
Report job, service identity, file access, configuration, database call, export request, error, and recovery.
Limitations
Uses local time and records only whole seconds.
Source
DNS logs
Owner
Network team
Useful for
Client, query, record type, answer, result, resolver, and request timing.
Limitations
A query does not prove a connection or user intent.
Source
Firewall and proxy logs
Owner
Network security team
Useful for
Connection decision, source, destination, port, protocol, method, path, response, bytes, duration, rule, and request ID.
Limitations
Shared gateway addresses can hide original client context from downstream sources.
Source
Endpoint protection logs
Owner
Security operations
Useful for
Detection, process, path, publisher, action, quarantine, device, user, and protection status.
Limitations
One alert name is generic and requires process, path, publisher, action, and related activity.
Source
Change and support records
Owner
Service management
Useful for
Approved password reset, software deployment, maintenance, owner, user report, expected result, rollback, and validation.
Limitations
Human-entered times are approximate and may not exactly match technical activity.
Source
Monitoring dashboard
Owner
Operations
Useful for
Alert timing, service health, error rate, authentication trend, transfer volume, and recovery validation.
Limitations
Dashboard labels summarize underlying records and should not replace source evidence.
Lab Workflow
Complete the Review in Six Phases
Phase 1
Define the scope and question
Required tasks
- • Identify the fictional systems, accounts, applications, time window, owners, and observed impact.
- • Write one neutral review question that does not assume compromise, innocence, or one shared cause.
- • Record the safety and privacy boundary before reading the evidence packet.
Required output
A one-paragraph Scope Statement and one-sentence Primary Review Question.
Phase 2
Inventory the evidence
Required tasks
- • List every available source, owner, time format, useful fields, retention condition, and known limitation.
- • Mark missing sources, delayed batches, approximate human times, and absent request or session identifiers.
- • Separate direct technical evidence from owner statements, tickets, dashboards, and baseline records.
Required output
A complete Source Inventory with availability, value, and limitation columns.
Phase 3
Normalize time and fields
Required tasks
- • Preserve original timestamps and convert all events to fictional UTC.
- • Document the report application’s two-minute slow clock and the endpoint collector delay.
- • Align device names, users, application names, paths, addresses, domains, source labels, and request IDs.
Required output
A Normalization Log showing each transformation and its confidence.
Phase 4
Build the event timeline
Required tasks
- • Place all relevant records in normalized time order.
- • Correlate using account, device, process, service, path, application, destination, request ID, and ticket evidence.
- • Mark order and relationship as confirmed, likely, uncertain, parallel, or unsupported.
Required output
A twenty-four-event Multi-Source Timeline with meaning and limitation notes.
Phase 5
Analyze patterns and findings
Required tasks
- • Compare failures, rare requests, endpoint alerts, application errors, and transfers with approved baselines.
- • Separate one connected sequence from unrelated or parallel activity.
- • Write facts, conclusions, alternate explanations, evidence gaps, confidence, impact, and priority.
Required output
A Finding Matrix with classification, confidence, owner, and next action.
Phase 6
Recommend and validate
Required tasks
- • Recommend only narrow, authorized, reversible defensive actions supported by the evidence.
- • Assign owners, validation steps, monitoring, rollback, and residual-risk statements.
- • Create an executive summary that protects fictional privacy and avoids unsupported claims.
Required output
A final Multi-Source Log Review Report and Executive Summary.
Core Concept
Build Separate Evidence Chains Before Building One Final Narrative
Begin with each observed pattern independently. Correlate only when time, account, device, process, service, application, request, destination, path, owner, or change evidence supports a relationship. This prevents operational failures, expected activity, and contained alerts from being merged incorrectly.
Scope
What systems, accounts, applications, sources, and time window are included?
Normalize
Which timestamps, names, fields, and collection delays must be aligned?
Correlate
Which users, devices, processes, sessions, requests, paths, destinations, and tickets connect?
Evaluate
Which facts, conclusions, alternates, gaps, confidence, impact, and priorities apply?
Report
Which owner, narrow action, validation, monitoring, and residual-risk statement are justified?
Fictional Evidence Packet
Twenty-Four Events for Multi-Source Review
ID
E01
Time
08:00:00
Source
Change
Event
Approved password reset begins for training-user-52.
Direct support
The reset was authorized and had an assigned support owner.
Limitation
Does not prove that all applications immediately updated saved credentials.
ID
E02
Time
08:02:11
Source
Identity
Event
Password reset completes successfully.
Direct support
The identity platform recorded successful credential replacement.
Limitation
Does not prove the physical person or every later authentication event.
ID
E03
Time
08:03:04
Source
Application
Event
Mail client reports stored credential rejected on training-laptop-52.
Direct support
The application attempted a saved credential that was not accepted.
Limitation
The application record alone does not prove the identity reason code.
ID
E04
Time
08:03:06
Source
Authentication
Event
Sign-in fails for training-user-52 from expected laptop.
Direct support
The identity platform recorded an unsuccessful attempt from the expected device.
Limitation
The exact sub-second order with E03 is unavailable.
ID
E05
Time
08:03:22
Source
Authentication
Event
Second sign-in failure from the same device and application.
Direct support
The failure repeated under the same source context.
Limitation
No endpoint process record is available for this exact second.
ID
E06
Time
08:04:02
Source
Support
Event
User reports the mail client still has the old password.
Direct support
The report matches the application and authentication sequence.
Limitation
The time is approximate and user-provided.
ID
E07
Time
08:04:28
Source
Application
Event
Stored mail credential updated.
Direct support
The application configuration changed before successful authentication.
Limitation
Does not prove who physically entered the new value.
ID
E08
Time
08:04:32
Source
Authentication
Event
Sign-in succeeds from the expected laptop.
Direct support
The authentication workflow completed after the credential update.
Limitation
Success does not prove every later action was approved.
ID
E09
Time
08:04:36
Source
MFA
Event
MFA challenge approved for session-5201.
Direct support
An additional verification factor completed for the same session.
Limitation
Does not prove the user understood every later application action.
ID
E10
Time
08:04:41
Source
Application
Event
Mail session created successfully.
Direct support
The application created a session after authentication and MFA.
Limitation
Does not list every activity inside the session.
ID
E11
Time
08:20:00
Source
Change
Event
Approved report application update begins.
Direct support
The deployment has an owner, maintenance window, test, and rollback plan.
Limitation
Does not prove the technical implementation matched the plan.
ID
E12
Time
08:24:13
Source
Update
Event
Report application package installs successfully; restart required.
Direct support
The installation completed but the intended running state may not yet be active.
Limitation
Installed does not mean validated.
ID
E13
Time
08:31:05
Source
Application
Event
Report module returns access denied for a configuration file.
Direct support
The application could not read the named fictional configuration path.
Limitation
The application record does not identify who changed the permission.
ID
E14
Time
08:31:06
Source
System
Event
svc-report-training receives access denied on the same path.
Direct support
A second source corroborates the permission failure.
Limitation
Does not prove whether the update caused the permission state.
ID
E15
Time
08:33:00
Source
Permission review
Event
Required inherited read permission is missing after package installation.
Direct support
The service identity lacks the access required by the report module.
Limitation
The review shows current state, not the exact moment or actor that changed it.
ID
E16
Time
08:36:00
Source
Approved change
Event
Required read permission restored with rollback prepared.
Direct support
A narrow authorized correction was applied.
Limitation
Recovery still requires functional validation and recurrence monitoring.
ID
E17
Time
08:36:18
Source
Application
Event
Report module opens the configuration file successfully.
Direct support
The immediate application function works after the correction.
Limitation
Does not prove every report workflow is healthy.
ID
E18
Time
08:45:00
Source
Monitoring
Event
No additional access-denied errors; owner validation passes.
Direct support
The observed error pattern stopped and the owner confirms the required function.
Limitation
Longer-term monitoring remains necessary.
ID
E19
Time
09:05:14
Source
DNS
Event
training-laptop-52 requests cdn.training-update.test.
Direct support
The laptop or one of its applications requested resolution for the fictional name.
Limitation
Does not prove a connection, user intent, or content.
ID
E20
Time
09:05:16
Source
Endpoint
Event
Approved browser process requests the same destination.
Direct support
The DNS activity is connected to the expected browser and user session.
Limitation
Does not prove what content the user viewed.
ID
E21
Time
09:05:17
Source
Proxy
Event
GET request to /training-assets returns success under approved category.
Direct support
The proxy allowed a web request from the expected user and browser.
Limitation
A successful response does not prove the user completed any business action.
ID
E22
Time
09:07:30
Source
Endpoint protection
Event
Generic alert on cached training archive; file quarantined before execution.
Direct support
The endpoint tool detected and quarantined the supplied fictional file.
Limitation
The generic alert name does not prove compromise or execution.
ID
E23
Time
09:07:32
Source
Endpoint
Event
No process execution or persistence event follows the quarantine.
Direct support
No supplied endpoint evidence shows execution or persistence.
Limitation
The conclusion applies only to available telemetry and the review window.
ID
E24
Time
09:20:00
Source
Monitoring
Event
No related alerts, sessions, network connections, or additional files appear.
Direct support
The observed pattern remains limited and contained under the available evidence.
Limitation
Continued monitoring is still appropriate.
Finding Matrix
Five Evidence-Based Findings
F1
Mail authentication failures after approved password reset
Confirmed facts
Approved reset, expected laptop, stored credential rejection, user report, credential update, later sign-in success, MFA approval, and no additional failures.
Best-supported conclusion
The failures most likely came from the mail client retrying an old saved password.
Alternate or limitation
A separate automated application retry could have contributed, but no conflicting source is supplied.
Impact and action
Impact: Temporary mail access disruption for one fictional user.
Action: Document the stale credential, confirm recovery, and monitor for recurrence.
F2
Report application access denied after approved update
Confirmed facts
Approved deployment, successful package install, matching application and system access-denied events, missing required read access, narrow restoration, and successful validation.
Best-supported conclusion
Missing required read permission most likely caused the report module failure.
Alternate or limitation
The update may have contributed to the permission state, but the exact actor and mechanism are not directly recorded.
Impact and action
Impact: Short report-generation outage during the maintenance window.
Action: Close the immediate outage after monitoring, then review packaging and permission-preservation controls.
F3
Rare web request to fictional training content destination
Confirmed facts
Expected user session, approved browser, approved proxy category, training-assets path, successful response, and no concerning related activity.
Best-supported conclusion
The request most likely represents approved training content delivery.
Alternate or limitation
The exact user intent and viewed content are not established by metadata alone.
Impact and action
Impact: No observed operational or security impact.
Action: Document the approved context and continue routine monitoring.
F4
Generic endpoint alert on cached archive
Confirmed facts
The fictional file was detected and quarantined before execution, with no later process, persistence, session, connection, or related alert evidence.
Best-supported conclusion
The available evidence supports successful prevention and containment rather than confirmed device compromise.
Alternate or limitation
The missing endpoint segment prevents absolute certainty about unrelated activity before collection resumed.
Impact and action
Impact: One cached file removed; no confirmed execution or persistence.
Action: Preserve alert details, confirm protection state, validate no recurrence, and document the telemetry gap.
F5
Relationship among the four observed patterns
Confirmed facts
The authentication issue, application permission failure, approved web request, and contained endpoint alert involve different times, processes, owners, causes, and evidence chains.
Best-supported conclusion
The evidence does not support one connected security incident.
Alternate or limitation
A hidden relationship is theoretically possible, but no shared session, process, request, destination, path, or change evidence supports it.
Impact and action
Impact: Two operational issues, one expected web request, and one contained security alert.
Action: Track each finding under its correct owner and avoid merging unrelated events into one incident narrative.
Prioritization Matrix
Prioritize by Evidence, Impact, Privilege, and Persistence
Finding
F1 Mail authentication failures
Evidence
Strong
Impact
Low
Privilege and persistence
Standard user; Stopped after correction
Priority
Routine documentation
Finding
F2 Report application outage
Evidence
Strong
Impact
Moderate
Privilege and persistence
Service identity; Stopped after approved correction
Priority
Operational follow-up
Finding
F3 Training-content web request
Evidence
Strong
Impact
None observed
Privilege and persistence
Standard user; Single expected request
Priority
Routine monitoring
Finding
F4 Contained endpoint alert
Evidence
Moderate
Impact
Low under available evidence
Privilege and persistence
Standard user; No recurrence observed
Priority
Security documentation and validation
Finding
F5 Combined-incident theory
Evidence
Weak
Impact
Would be broad if true
Privilege and persistence
Mixed; No shared sequence
Priority
Reject unsupported merger
Final Report Structure
Eight Sections of a Professional Log Review Report
Executive summary
Include
Primary question, overall conclusion, highest-priority findings, confidence, impact, and immediate next actions.
Avoid
Technical overload, unsupported blame, or claims that every event was connected.
Scope and safety boundary
Include
Systems, accounts, applications, time window, owners, supplied evidence, exclusions, and fictional-data statement.
Avoid
Suggesting the review covered real systems or evidence outside the supplied packet.
Source inventory
Include
Source, owner, useful fields, time format, retention, collection state, and limitation.
Avoid
Treating dashboards or alert labels as substitutes for original records.
Normalization notes
Include
Original values, UTC conversion, known clock offset, collection delay, name mapping, field alignment, and assumptions.
Avoid
Changing evidence silently or removing the original source values.
Event timeline
Include
Normalized time, source, event, related entity, evidence status, meaning, limitation, and correlation key.
Avoid
Using time proximity as automatic proof of causation.
Findings
Include
Facts, conclusion, alternates, gaps, confidence, impact, priority, owner, and safe next action.
Avoid
Mixing facts and conclusions or hiding uncertainty.
Recommendations
Include
Authorized owner, narrow action, rollback, validation, monitoring, documentation, and baseline improvement.
Avoid
Disruptive changes that are broader than the evidence supports.
Residual risk and closure
Include
What remains unknown, what will be monitored, closure criteria, and when the finding should be reopened.
Avoid
Claiming permanent resolution without sufficient monitoring.
Key Vocabulary
Integrated Log Review Terms
Scope
The systems, accounts, applications, time window, evidence sources, and defensive question included in a review.
Evidence packet
The fictional collection of logs, tickets, inventories, diagrams, baselines, and owner statements supplied for analysis.
Source inventory
A record of which evidence sources are available, who owns them, what they record, and what limitations apply.
Normalization
The documented process of aligning timestamps, names, identities, fields, formats, and source labels.
Correlation
Connecting related records using time, user, device, process, service, application, session, request, address, path, or ticket evidence.
Finding
A clearly stated defensive conclusion supported by evidence, confidence, impact, limitations, ownership, and next action.
Confidence
The reviewer’s stated certainty based on source quality, agreement, timing accuracy, completeness, and remaining gaps.
Impact
The observed or potential effect on users, systems, applications, services, data, operations, or security controls.
Residual risk
The risk that remains after immediate correction, containment, validation, or monitoring.
Escalation
The approved process for transferring a finding to the appropriate owner or response team.
Validation
Evidence that a correction, recovery, change, or control produced the intended result.
Executive summary
A short explanation of what happened, why it matters, confidence, impact, and the most important next actions.
Fake Dashboard
Fake Multi-Source Review Dashboard
Training dashboard for the fictional Northstar Learning Services lab case.
Evidence sources
8
Identity, endpoint, application, DNS, firewall and proxy, protection, change and support, and monitoring records.
Events reviewed
24
Four evidence chains were analyzed across authentication, application, web, endpoint, and operational activity.
Final findings
5
Two operational findings, one expected web pattern, one contained security alert, and one relationship finding.
Fake SOC Alert
Multiple Alerts Occur During the Same Morning Review Window
Source: Fake Correlation Dashboard • Time: 09:25 AM
Fake Log Panel
Fake Integrated Evidence Summary
08:00:00 CHANGE account='training-user-52' action='password_reset_started' approved='true' 08:03:04 APPLICATION device='training-laptop-52' event='stored_credential_rejected' 08:04:32 AUTH account='training-user-52' result='success' after='credential_update' 08:20:00 CHANGE app='report-app-2' action='approved_update_started' 08:31:05 APPLICATION component='report-module' result='access_denied' 08:36:18 APPLICATION component='report-module' result='configuration_opened' 09:05:14 DNS client='training-laptop-52' query='cdn.training-update.test' 09:05:17 PROXY method='GET' path='/training-assets' result='success' 09:07:30 ENDPOINT alert='generic_archive_detection' action='quarantined_before_execution' 09:20:00 MONITOR related_execution='0' persistence='0' additional_alerts='0'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Should the Four Observed Patterns Be Treated as One Incident?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken an Integrated Log Review
Hands-On Lab
Complete the Full Fictional Log Review
Required Deliverables
- Scope Statement and Primary Review Question
- Source Inventory
- Normalization Log
- Twenty-Four-Event Timeline
- Pattern and Finding Matrix
- Prioritization Matrix
- Recommendations and Validation Plan
- Executive Summary
Completion Standard
- • Every conclusion cites at least two supporting fictional sources when available.
- • Every finding includes confidence, impact, owner, limitation, and safe next action.
- • Original evidence remains visible beside normalized values.
- • Separate events are not merged without shared evidence.
- • The report contains no real identifiers, logs, screenshots, or internal data.
Scenario Decision Lab
The Dashboard Groups All Four Patterns into One Incident
A fictional dashboard automatically groups authentication failures, an application error, a web request, and an endpoint alert because they occur within ninety minutes on the same laptop.
Scenario Decision Lab
One Endpoint Segment Is Missing
The fictional endpoint collector has no events from 09:00 to 09:06 because the laptop was briefly offline. DNS and proxy evidence still show the training-content request during that period.
Defender Habits
Log Review Lab Checklist
Check Your Understanding
I4.8 Mini Quiz: Log Review Lab
Choose your answers first. Explanations appear only after submission.
1. What is the best first step in a multi-source log review?
2. Why is a source inventory important?
3. What is the strongest conclusion about the authentication failures in the lab?
4. Why should the web request and endpoint alert not automatically be merged?
5. What does quarantine before execution support?
6. Which recommendation is strongest after the application permission failure?
7. What belongs in the final executive summary?
Portfolio Prompt
Portfolio Prompt
Create a complete fictional Multi-Source Log Review Report for the I4.8 case. Include an executive summary, scope statement, source inventory, normalization log, twenty-four-event timeline, five-finding matrix, prioritization matrix, evidence gaps, confidence statements, impact, owners, authorized recommendations, validation plan, monitoring plan, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation