I4.6 Normal vs Suspicious Patterns
Learn how defenders compare fictional activity with baselines, ownership, schedules, roles, applications, destinations, privilege, change records, and multi-source evidence before deciding what deserves escalation.
Lesson Progress
Normal vs Suspicious Patterns
High School Intermediate • I4: Logs and Event Monitoring • Lesson 6 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
Unusual Does Not Automatically Mean Malicious
A late-night sign-in, large transfer, rare destination, repeated error, new process, high-severity alert, or denied connection may be normal in one environment and concerning in another. Defenders compare the pattern with role, ownership, purpose, schedule, privilege, baseline, and corroborating evidence.
Weak response
“It has never happened before, so it must be malicious.”
Strong response
“Measure the deviation, identify the baseline, add role and owner context, correlate related sources, and state the classification with confidence and limitations.”
Objective 1
Explain the difference between normal, expected, unusual, suspicious, administrative, failed, and evidence-incomplete activity.
Objective 2
Use baselines, asset role, user role, schedule, frequency, volume, source, destination, privilege, change, and owner context to evaluate fictional patterns.
Objective 3
Recognize why rare activity, high severity, denied actions, failed sign-ins, large transfers, and unusual times do not automatically prove malicious intent.
Objective 4
Prioritize fictional patterns by evidence strength, potential impact, confidence, urgency, and safe next action.
Objective 5
Create a professional fictional Pattern Analysis Matrix that separates confirmed facts, reasonable conclusions, alternate explanations, evidence gaps, and escalation decisions.
Why This Matters
Good Pattern Analysis Reduces Both Missed Risk and Unnecessary Escalation
Weak analysis can ignore important combinations of signals or overwhelm teams with false alarms. Strong analysis uses updated baselines, multi-source evidence, context, confidence, impact, and safe prioritization.
Pattern Dimensions
Ten Questions That Change Pattern Meaning
Time
Did the activity occur during normal hours, an approved maintenance window, travel, backup, deadline work, or scheduled automation?
Frequency
Did the event happen once, repeatedly, on a fixed schedule, in a burst, or across many accounts and devices?
Volume
Did the amount of data, requests, errors, sign-ins, changes, or alerts differ significantly from the approved baseline?
Source
Did the activity come from an expected device, user, process, service, network, VPN, gateway, or management system?
Destination
Did the activity reach an approved application, server, cloud service, vendor, update source, or internal zone?
Privilege
Was the activity performed by a standard user, administrator, service identity, temporary role, or highly privileged account?
Result
Did the action succeed, fail, get denied, get blocked, time out, retry, or partially complete?
Change context
Was there an approved deployment, password reset, update, rule change, test, migration, restart, or support action?
Asset role
Is the device a workstation, server, backup system, management platform, kiosk, lab machine, or public-facing service?
Historical pattern
Has the same user, application, process, destination, or schedule appeared before under approved conditions?
Classification Model
Seven Defensive Classification Labels
Normal
Meaning
Matches an established baseline with expected users, devices, applications, timing, destinations, volume, and results.
Example
A backup server transfers its usual nightly volume to the approved storage destination during the documented window.
Strong action
Document the match and continue routine monitoring.
Expected
Meaning
May be new or rare but is supported by a valid owner, business purpose, change record, schedule, or approved workflow.
Example
A new vendor destination appears during an approved application migration with owner and validation evidence.
Strong action
Confirm the approved context and monitor the new baseline.
Unusual
Meaning
Differs from the baseline but currently lacks enough evidence to call suspicious.
Example
A user signs in two hours later than usual from the same managed device and approved application.
Strong action
Add user, device, schedule, application, and owner context before deciding.
Suspicious
Meaning
Contains multiple concerning signals or corroborating evidence that justify focused defensive review.
Example
A privileged account authenticates from a new device, receives denied MFA prompts, and creates an unexpected session outside the approved schedule.
Strong action
Preserve evidence, verify through approved channels, and escalate according to policy.
Administrative
Meaning
Represents approved management, maintenance, support, monitoring, configuration, deployment, testing, or recovery activity.
Example
A management server connects to many internal systems during a documented patching window.
Strong action
Confirm ownership, scope, schedule, results, and change closure.
Failed
Meaning
An attempted action did not complete successfully and requires cause and impact context.
Example
A retired application repeatedly attempts a denied connection to an old server address.
Strong action
Identify the source process and owner, correct the stale configuration, and validate recovery.
Evidence-incomplete
Meaning
The available records are insufficient to classify the pattern responsibly.
Example
A DNS request appears, but endpoint, firewall, proxy, application, and owner records are missing.
Strong action
Preserve the confirmed event, identify the gaps, and request authorized supporting evidence.
Core Concept
Patterns Become Meaningful When Multiple Dimensions Agree
Time, frequency, volume, source, destination, privilege, result, asset role, history, and change context each provide part of the picture. The strongest classifications explain how those parts connect and what evidence remains missing.
Measure
What exactly changed from the approved baseline?
Contextualize
Which user, device, application, owner, schedule, and purpose apply?
Correlate
Which independent sources agree or conflict?
Classify
Is the activity normal, expected, unusual, suspicious, administrative, failed, or incomplete?
Act
What is the safest authorized next step, and how will it be validated?
Signal Combinations
One Signal Is Weak; Combined Context Is Stronger
One unusual sign-in outside normal hours
Lower-risk context
Expected device, expected application, approved travel, successful MFA, no sensitive activity, and owner confirmation.
Higher-risk context
New device, privileged account, repeated failures, denied MFA, sensitive application, and no owner explanation.
Defensive lesson
Time alone is weak; combined identity, device, privilege, MFA, and application context changes priority.
Large outbound transfer
Lower-risk context
Approved backup, report export, migration, cloud synchronization, known process, expected destination, and change ticket.
Higher-risk context
Unknown process, sensitive source, unfamiliar destination, unusual time, no owner, and policy bypass.
Defensive lesson
Volume becomes more meaningful when process, data role, destination, owner, and change evidence agree.
Repeated failed sign-ins
Lower-risk context
Same expected device, stale saved credential, recent password reset, application retry, and failures stop after update.
Higher-risk context
Many accounts, many sources, unfamiliar devices, lockouts, later success elsewhere, and failed MFA.
Defensive lesson
Failure count alone is not enough; distribution, device, application, reset, and later-success context matter.
One device connects to many internal systems
Lower-risk context
Approved inventory, monitoring, patching, backup, or management server during a documented window.
Higher-risk context
User workstation, unknown process, unusual ports, sensitive zones, no management role, and failed authentication.
Defensive lesson
Asset role and process ownership can completely change how the pattern is interpreted.
High-severity endpoint alert
Lower-risk context
Known test file, approved administrative tool, expected lab activity, completed remediation, and no related events.
Higher-risk context
Successful execution, new persistence, broad exclusion, privileged account, network activity, and multiple devices.
Defensive lesson
Severity is one clue; process, action, scope, remediation, persistence, and correlation determine urgency.
Many web errors
Lower-risk context
Old bookmark, expired session, application deployment, maintenance window, or temporary back-end restart.
Higher-risk context
Sensitive path, unusual method, many sources, growing rate, no maintenance, and repeated successful access attempts.
Defensive lesson
Error counts need path, method, source, application, maintenance, and response-sequence context.
New scheduled task or startup item
Lower-risk context
Approved software deployment, known publisher, expected path, owner, change record, and successful validation.
Higher-risk context
Unknown publisher, user-writable path, privileged account, no owner, repeated network activity, and no change record.
Defensive lesson
Newness becomes more concerning when path, publisher, privilege, owner, and related activity are also unusual.
Missing logs from one device
Lower-risk context
Device powered off, traveling, sleeping, offline, agent upgrade, or documented collector maintenance.
Higher-risk context
Device reported online, sensitive role, repeated collection failure, local logs unavailable, and protection state unknown.
Defensive lesson
Missing telemetry confirms a visibility gap; device state and collection evidence shape urgency.
Evidence Matrix
What Pattern Evidence Can and Cannot Prove
Evidence source
Baseline record
Can support
Expected users, devices, schedules, applications, destinations, volume, frequency, and normal results.
Limitation
Baselines can be stale, incomplete, seasonal, or too broad.
Evidence source
Asset inventory
Can support
Device role, owner, operating system, exposure, sensitivity, management status, and approved software.
Limitation
Inventory can lag behind actual configuration or ownership changes.
Evidence source
Identity context
Can support
Account role, privilege, groups, MFA, expected devices, schedule, lifecycle, and owner.
Limitation
Account context does not prove the physical person or every action.
Evidence source
Technical event records
Can support
Observed time, source, destination, process, action, result, severity, volume, and sequence.
Limitation
Technical events may not explain purpose, authorization, or business impact.
Evidence source
Change record
Can support
Approved owner, reason, scope, schedule, test, rollback, expected behavior, and validation.
Limitation
The documented change may not match the exact technical activity.
Evidence source
User or owner report
Can support
Expected activity, observed impact, travel, device use, business need, and timing.
Limitation
Reports can be incomplete, delayed, approximate, or mistaken.
Evidence source
Historical comparison
Can support
Whether the same user, device, process, destination, volume, or schedule appeared before.
Limitation
Past normality does not guarantee current safety or approval.
Evidence source
Correlated multi-source evidence
Can support
Agreement across authentication, endpoint, system, application, network, web, and change records.
Limitation
Correlation quality depends on time accuracy, field consistency, retention, and source coverage.
Prioritization
Eight Factors That Shape Review Priority
Evidence strength
How many independent fictional sources support the pattern, and how direct are they?
Potential impact
Could the activity affect a sensitive account, critical service, large user group, protected data set, or important business function?
Privilege
Does the pattern involve an administrator, service identity, security control, management platform, or broad-access role?
Scope
Does the pattern affect one event, one user, one device, many systems, many accounts, or multiple network zones?
Persistence
Did the pattern happen once, stop after correction, repeat regularly, or continue despite remediation?
Control outcome
Was the action allowed, denied, blocked, quarantined, contained, retried, or successful?
Context quality
Are owner, baseline, change, schedule, device, application, destination, and user details available?
Time sensitivity
Is the activity ongoing, recent, recurring, or tied to an active user, service, or business disruption?
Defensive Workflow
Classify Patterns in Six Steps
Define the pattern
State exactly what changed in time, frequency, volume, source, destination, privilege, result, or behavior.
Identify the baseline
Find the approved users, devices, applications, schedules, destinations, volumes, and normal results.
Add context
Compare asset role, identity role, owner, change, travel, maintenance, application purpose, and business need.
Correlate sources
Connect authentication, endpoint, system, application, network, web, ticket, owner, and monitoring evidence.
Classify and prioritize
Choose normal, expected, unusual, suspicious, administrative, failed, or evidence-incomplete and state confidence.
Respond and improve
Preserve evidence, assign an owner, take the safest authorized action, validate the result, and update the baseline.
Example Findings
Classification Should Be Evidence-Based and Actionable
Finding
Late-night sign-in from an expected device
Supporting facts
Same managed laptop, approved application, successful MFA, no sensitive changes, and user confirms deadline work.
Classification
Expected
Confidence
High
Strong action
Document owner confirmation and include the approved late-work pattern in the baseline review.
Finding
Repeated failed sign-ins after password reset
Supporting facts
Same device, mail client reports stale credential, failures stop after update, and later MFA succeeds.
Classification
Expected failure pattern
Confidence
High
Strong action
Document stale credential, validate recovery, and monitor for recurrence.
Finding
Rare DNS request without endpoint or connection evidence
Supporting facts
One query appears, but process, firewall, proxy, application, and owner records are unavailable.
Classification
Evidence-incomplete
Confidence
High
Strong action
Preserve the DNS event and request authorized supporting evidence before deciding.
Finding
Privileged sign-in from new device with denied MFA prompts
Supporting facts
New device, unusual time, privileged account, two denied prompts, no travel record, and no owner confirmation.
Classification
Suspicious
Confidence
Medium
Strong action
Preserve evidence, verify through approved channels, review sessions and device state, and escalate promptly.
Finding
Management server connects to many endpoints
Supporting facts
Known management asset, approved patching window, expected ports, named owner, and successful patch validation.
Classification
Administrative
Confidence
High
Strong action
Confirm scope and change closure, then continue routine monitoring.
Finding
Large approved report upload
Supporting facts
Known process, expected destination, approved change, matching volume, successful application result, and owner validation.
Classification
Expected
Confidence
High
Strong action
Document the new approved destination and continue monitoring.
Key Vocabulary
Pattern Analysis Terms
Baseline
An approved description of expected users, devices, applications, destinations, schedules, volumes, and behaviors.
Normal
Activity that matches an established and approved pattern for the system, user, application, or business process.
Expected
Activity that is justified by role, owner, schedule, change, ticket, workflow, or documented purpose.
Unusual
Activity that differs from the known baseline but is not automatically harmful.
Suspicious
Activity with enough concerning context or corroboration to justify focused defensive review.
Administrative
Authorized management, maintenance, support, configuration, deployment, monitoring, or recovery activity.
Failed
An attempted action that did not complete successfully.
Evidence-incomplete
Activity that cannot be classified confidently because important records or context are missing.
Frequency
How often an event or pattern occurs within a defined period.
Volume
How much activity, data, traffic, or change occurred within a defined period.
Deviation
A measurable difference from an approved baseline.
False positive
An alert or pattern that appears concerning but is explained by expected or benign activity after review.
Fake Dashboard
Fake Pattern Analysis Dashboard
Training dashboard for the fictional Northstar Learning Services monitoring environment.
Expected patterns
31
Validated backups, updates, patching, report exports, travel, and scheduled support activity.
Unusual patterns
9
Five have reasonable owner explanations, while four still require supporting evidence.
Suspicious patterns
3
All involve combined identity, device, privilege, MFA, or persistence signals and have been escalated.
Fake SOC Alert
Privileged Sign-In from a New Device with Denied MFA Prompts
Source: Fake Pattern Correlation Platform • Time: 07:42 PM
Fake Log Panel
Fake Pattern Evidence
19:40:08 AUTH account='training-admin-6' device='unknown-device-91' result='failed' reason='mfa_required' 19:40:16 MFA account='training-admin-6' result='denied' source='unknown-device-91' 19:40:29 AUTH account='training-admin-6' device='unknown-device-91' result='failed' reason='mfa_denied' 19:41:03 MFA account='training-admin-6' result='denied' source='unknown-device-91' 19:41:45 SESSION app='admin-portal' result='not_created' 19:42:00 BASELINE account='training-admin-6' normal_hours='08:00-17:00' managed_devices='2' 19:42:05 INVENTORY device='unknown-device-91' status='not_found' 19:42:10 CHANGE approved_travel='none' support_ticket='none' 19:42:18 OWNER confirmation='not_yet_available' 19:42:30 CLASSIFICATION label='suspicious' confidence='medium' escalation='required'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Pattern Classification Is Best Supported?
Which classification is strongest?
Common Mistakes
Mistakes That Weaken Pattern Analysis
Safe Practice Lab
Classify a Fictional Pattern Set
Fictional Environment
Meadowbrook Pattern Review
Review sixteen fictional patterns involving authentication, endpoint, system, application, network, web, change, support, inventory, and baseline evidence.
Required Analysis
- State the exact deviation in time, frequency, volume, source, destination, privilege, or result.
- Identify the relevant baseline and whether it is current.
- Add asset, identity, application, owner, schedule, destination, and change context.
- Correlate at least two independent evidence sources.
- Classify each pattern using one of the seven labels.
- Assign confidence, impact, urgency, owner, and safe next action.
- Explain what evidence would change the classification.
Scenario Decision Lab
A Large Transfer Occurs During an Approved Backup Window
A fictional server transfers three times its usual volume to the approved backup destination. The backup owner confirms a full monthly archive, but file-level validation is still pending.
Scenario Decision Lab
A New Startup Item Appears After Approved Software Deployment
A fictional managed workstation gains a new startup item from the approved application folder. The publisher, path, owner, and change record match the deployment, and no unusual network or account activity follows.
Defender Habits
Normal vs Suspicious Patterns Checklist
Check Your Understanding
I4.6 Mini Quiz: Normal vs Suspicious Patterns
Choose your answers first. Explanations appear only after submission.
1. What makes unusual activity different from suspicious activity?
2. Why is a baseline important?
3. What does a rare DNS request directly prove?
4. Which pattern deserves the highest review priority?
5. What should happen when evidence is incomplete?
6. Why can a large outbound transfer be expected?
7. What should happen after an expected new pattern is validated?
Portfolio Prompt
Portfolio Prompt
Create a fictional Pattern Analysis Matrix containing at least sixteen patterns across authentication, endpoint, system, application, network, web, inventory, baseline, change, and support evidence. For each pattern, include deviation, baseline, asset role, identity role, application, time, frequency, volume, source, destination, privilege, result, owner, change context, corroborating sources, classification, confidence, potential impact, urgency, evidence gaps, safe next action, and validation plan.
Key Takeaways
What You Should Remember
Navigation