7.2 Logging, Monitoring & Threat Detection
7.2 Logging, Monitoring & Threat Detection
Security operations depend on visibility.
Systems generate events, logs and telemetry that can reveal attacks, misuse, failures and changes in security state.
The challenge is not simply collecting more data.
The challenge is collecting the right data, protecting it, analysing it, detecting meaningful activity and tuning monitoring so defenders can recognise important events quickly.
Log
Record security-relevant activity from systems, identities, applications, networks and services.
WHAT HAPPENED?Monitor
Observe activity and security state across the environment.
WHAT IS HAPPENING?Detect
Identify activity that may require investigation or response.
WHAT NEEDS ATTENTION?Conduct Logging & Monitoring Activities
Detect potentially malicious activity and, where designed to do so, take preventative action.
Centralise, analyse and correlate security information from multiple sources.
Maintain ongoing awareness and continually improve detection quality.
Observe outbound activity for suspicious communications and possible data loss.
Generate, transmit, store, access, analyse, retain and dispose of log information appropriately.
Use threat information, feeds and proactive threat hunting to improve security awareness and detection.
Analyse behavioural patterns to identify potentially significant deviations.
7.2 Official Topics
The Big Idea
Logging creates visibility.
Monitoring uses that visibility.
Detection identifies activity that deserves attention.
Detection Flow
Event vs Log vs Alert vs Incident
Something happened within a system, application, network or service.
User authenticates to an application.
A recorded representation of an event.
Authentication log records the user, time, source and result.
A notification that monitoring logic identified something potentially important.
Successful administrator login from an unusual country.
A security event or collection of events determined to require incident-management action.
Investigation confirms administrator credentials were compromised.
Event → Incident
Security Telemetry Sources
Effective monitoring combines evidence from different parts of the environment.
What Should a Useful Log Tell You?
User, service, device, process or identity involved.
Action or event that occurred.
Accurate timestamp.
Source and destination system, address or service.
Resource or object affected.
Success, failure, denial, error or other result.
Additional information needed to interpret the event.
Useful Log
📝 Logging Something Is Not Enough The record must contain enough context to be useful
"Login failed."
User: admin01
Time: 02:13:44 UTC
Source: 198.51.100.20
Application: Payment Admin Portal
Authentication: Password accepted · MFA failed
Time Synchronisation
Security monitoring relies on the ability to correlate events from different systems.
If their clocks disagree, the apparent sequence of events may be wrong.
Login: 14:01
Data transfer: 13:58
It appears that data transfer occurred before authentication.
Investigation discovers Server B's clock is:
seven minutes slow.
Time
Log Management
Log management covers the lifecycle of security and operational event information.
Log Lifecycle
🗃️ Centralised Logging Move important evidence away from the system that produced it
An attacker compromises Server A and gains administrator privileges.
The attacker deletes:
Server A's local security logs.
Server A had already forwarded important events to a separate protected logging platform.
Identity, endpoint, network, application and cloud activity can be analysed together instead of as isolated evidence.
Protect the Logs
Logs are security evidence and should themselves be protected.
Logs may contain identities, addresses, sensitive data and security architecture information.
Attackers should not be able to silently alter historical evidence.
Relevant logs must remain accessible when investigation or monitoring requires them.
Limit access according to operational need and responsibility.
Preserve logs long enough to satisfy security, business, legal and regulatory requirements.
Remove logs appropriately when retention requirements expire.
🛡️ Log Integrity Attackers often benefit from destroying the evidence of their own activity
Useful Protections
A privileged user clears an operating-system event log.
The act of:
clearing the log
may itself be a high-value security event.
🕒 Log Retention Retain long enough to support the purpose of the logs
Retention requirements may depend on:
Threat intelligence reveals that attackers commonly remain undetected for several months.
The organisation retains critical authentication logs for:
seven days.
Should We Log Everything?
More logging can improve visibility, but unlimited logging creates its own problems.
High-volume telemetry can be expensive to retain.
Excessive logging may affect applications and infrastructure.
Important activity can become buried inside enormous event volumes.
Logs can contain sensitive information about users and customers.
Highly detailed logs may reveal credentials, tokens or architecture if poorly designed.
Collection, indexing, analysis and retention all consume resources.
🔐 Do Not Log Secrets Unnecessarily Observability should not become a new data leak
Avoid Unnecessary Logging of
Login failure:
username=alice password=Summer2026!
Security Information & Event Management - SIEM
A SIEM brings security information from many sources together so it can be searched, correlated, analysed and used for detection and investigation.
SIEM
🔄 Normalisation Different products describe the same concepts differently
src_ip=10.5.1.20
sourceAddress=10.5.1.20
client.ip=10.5.1.20
A SIEM can map these different fields to a common concept such as:
source IP address.
➕ Event Enrichment Add context that helps an analyst understand significance
Source: 10.5.1.20
Host: PAYMENTS-DB-01
Owner: Payments Technology
Criticality: Critical
Environment: Production
One Event Looks Normal
🪄 SIEM ≠ Automatic Security A SIEM only sees what reaches it and detects what it knows how to detect
No telemetry means no SIEM visibility.
Events may be collected but interpreted incorrectly.
Important activity may never trigger an alert.
Analysts may overlook meaningful alerts.
Alerts may lack enough information for prioritisation.
Detecting an attack without acting on it provides limited value.
SIEM vs SOAR
Primarily aggregates and analyses security information and events to support detection, investigation and reporting.
SEE + DETECT
Security Orchestration, Automation and Response coordinates security tools and workflows and can automate defined response actions.
ORCHESTRATE + ACT
SIEM detects: possible compromised account.
SOAR workflow:
SIEM vs SOAR
Intrusion Detection & Prevention Systems - IDPS
IDPS technologies identify activity that may represent attacks, violations or suspicious behaviour.
Detects suspicious activity and typically generates alerts or other evidence.
DETECT + ALERT
Detects suspicious activity and can take preventative action such as blocking traffic.
DETECT + ACT
IDS vs IPS
🛡️ Network vs Host-Based Detection Observe different parts of the attack
Observes network activity.
Observes activity occurring on an individual endpoint or host.
📍 IDS / IPS Placement Where the sensor sits determines what it can see
May receive a copy of traffic for analysis without sitting directly in the traffic path.
Generally needs to be positioned so traffic passes through the prevention mechanism if it is expected to block that traffic.
How Detection Systems Recognise Suspicious Activity
Looks for known patterns associated with attacks or malicious activity.
KNOWN BAD
Identifies significant deviation from expected or established behaviour.
DIFFERENT FROM NORMAL
Examines whether communications follow expected protocol behaviour and state.
EXPECTED PROTOCOL
Uses rules, characteristics or multiple signals to estimate whether activity is suspicious.
SUSPICIOUS CHARACTERISTICS
🧬 Signature vs Anomaly Detection Known attack patterns versus deviations from expected behaviour
| Signature | Anomaly | |
|---|---|---|
| Looks For | Known malicious patterns | Deviation from baseline |
| Known Attacks | Strong | Can detect |
| Novel Activity | May miss | May identify |
| False Positives | Can occur | Often requires careful tuning |
| Needs Baseline | Not necessarily | Usually important |
Detection Method
True & False Detection Results
| Threat Exists | No Threat | |
|---|---|---|
| Alert | True Positive | False Positive |
| No Alert | False Negative | True Negative |
Attack occurs and detection alerts.
Legitimate activity incorrectly triggers detection.
Attack occurs but detection fails to alert.
Legitimate activity occurs and correctly generates no alert.
Detection Outcomes
Continuous Monitoring & Tuning
Detection systems should evolve as systems, users, applications and threats change.
Detection Tuning
♾️ "Continuous" Does Not Necessarily Mean Every Millisecond Monitoring frequency should support timely risk decisions
Baselines
Behaviour-based monitoring needs some understanding of what expected activity looks like.
Authenticates: every 10 minutes.
Source: two known application servers.
Data access: predictable application tables.
Account authenticates: interactively from a workstation.
At: 03:00.
Then: downloads employee records.
😵 Alert Fatigue More alerts can make detection less effective
Detection platform generates:
28,000 alerts per day.
Analysts can realistically investigate:
600.
Important alerts are now competing with:
27,400 alerts that cannot receive meaningful attention.
Tune noisy detections, improve context, adjust thresholds and prioritise according to risk.
🎚️ Tuning ≠ Hiding the Problem Reduce noise without creating blind spots
Approved vulnerability scanner triggers:
thousands of port-scan alerts every night.
Disable all:
port-scan detection.
Suppress or appropriately classify expected scanner activity while retaining visibility for unexpected sources.
Detection Engineering Lifecycle
Good detections are managed like security controls rather than written once and forgotten.
Detection Engineering
🗺️ Detection Coverage A detection programme should understand what it can and cannot see
Which adversary behaviour are we concerned about?
Which logs or sensors reveal the behaviour?
Is logic implemented to recognise it?
Have we demonstrated that detection actually works?
Organisation has excellent endpoint monitoring on laptops.
Its production cloud environment generates:
no administrative activity logs.
Egress Monitoring
Egress monitoring examines traffic and activity leaving an environment.
Many attacks are discovered by observing what compromised systems attempt to communicate with or send outside the organisation.
Compromised systems communicating with attacker infrastructure.
Sensitive information leaving approved environments.
Internal hosts retrieving additional malicious tooling.
Unusual DNS behaviour that may indicate tunnelling or attacker communication.
Sensitive information being sent to unauthorised external platforms.
Systems communicating with locations or services inconsistent with their business role.
Egress
↔️ Ingress vs Egress Watch what enters and what leaves
Traffic entering an environment.
INBOUND
Traffic leaving an environment.
OUTBOUND
Ingress: phishing payload enters.
Egress: malware calls attacker infrastructure.
Egress Monitoring vs Egress Filtering
Observes outbound communications.
DETECTIVE
Restricts which outbound communications are permitted.
PREVENTIVE
A database server should only communicate with approved internal services.
Egress filtering: blocks direct internet access.
Egress monitoring: alerts if the server attempts unexpected external communication.
🔐 Encryption Changes Visibility You may see the communication without seeing its contents
When network traffic is encrypted, monitoring may still be able to observe useful metadata such as:
Threat Intelligence
Threat intelligence helps security teams understand threats that may affect their organisation and use that information to improve detection, prioritisation and response.
Observable technical information associated with potentially malicious activity.
Information about how threat actors operate.
Information about adversary motivations, capabilities and targets.
Related malicious activity occurring over time.
Information about weaknesses being targeted or exploited.
Detection, mitigation and response information derived from threat analysis.
📡 Threat Feed vs Threat Intelligence Raw indicators are not automatically meaningful intelligence
A stream of threat-related information such as domains, addresses, file hashes or indicators.
DATA
Threat information analysed and placed into context so it can support security decisions.
CONTEXT + MEANING
203.0.113.77
Address is associated with infrastructure used in a campaign targeting financial institutions through credential theft.
The organisation observed: three outbound connections to it yesterday.
Threat Intelligence at Different Levels
A useful way to think about threat intelligence is according to the type of decision it supports.
High-level threat trends, motivations and business implications for leadership.
Information about campaigns, actors and planned or ongoing malicious activity.
How adversaries operate, including common techniques and behaviours.
Observable information such as malicious addresses, domains, hashes and infrastructure.
Threat Intelligence
🎯 Indicators vs Behaviour Indicators often change faster than attacker techniques
Observable evidence associated with potentially malicious activity.
Describes how an adversary operates.
Defender blocks malicious IP: 203.0.113.77.
Attacker moves to: a new IP address.
The attack technique may remain the same even though the technical indicator changed.
Not All Intelligence Is Equally Useful
Does it matter to the organisation?
Is it current enough to support action?
Can the source and analysis reasonably be trusted?
Do we know what the information means?
Can defenders use it to improve security?
Does it support detection or decision-making without creating excessive noise?
Import: 10 million unverified indicators.
Result: thousands of low-confidence alerts.
Threat Hunting
Threat hunting proactively searches for evidence of malicious activity that existing automated detection may not have identified.
Threat Hunting
🔍 Threat Hunting vs Alert Investigation One begins with an alert; the other begins with a question or hypothesis
Detection fires first.
Analyst investigates: "Why did this alert trigger?"
Analyst starts proactively.
Hunter asks: "Could this attacker behaviour already exist in our environment?"
Threat Intelligence Reveals a New Technique
Intelligence reports that attackers targeting the organisation's sector are using compromised service accounts for interactive login.
User & Entity Behavior Analytics - UEBA
UEBA examines behavioural information associated with users and other entities and looks for patterns that may indicate abnormal or risky activity.
UEBA
The Database Administrator
Login: 07:00 - 18:00 UK time.
Source: corporate laptop.
Data access: administrative queries.
Login: 03:14.
Source: previously unseen device.
Action: exports 20 GB of customer information.
⚠️ Anomaly ≠ Malicious Unusual behaviour requires context
Employee accesses corporate systems from:
a new country.
Possible explanations:
👤 UEBA & Insider Risk Credentials may be valid while behaviour is still dangerous
Correct password: Yes.
Correct MFA: Yes.
Authorised account: Yes.
Behaviour: downloads 50 times normal data volume before resignation.
SOC Detection Workflow
SOC Flow
🚑 Alert Triage Determine whether the alert deserves deeper investigation
Ask
PowerShell executed encoded command.
Approved automation server running authorised maintenance.
Finance user's laptop immediately after opening a suspicious email.
Alert Severity vs Alert Priority
Technical detection severity is useful, but operational priority should consider context.
How likely is the activity genuinely malicious?
What business service is affected?
Does the account have powerful access?
Is the affected resource externally accessible?
Is the activity associated with known current attacks?
What could happen if the alert represents a real attack?
Monitoring Blind Spots
Security teams cannot detect activity they cannot observe.
Relevant events are never generated.
Evidence exists locally but never reaches central monitoring.
Logs arrive but are interpreted incorrectly.
Evidence disappears before detection or investigation.
Security team does not know the system exists.
Service launched without onboarding telemetry.
Some network content may not be directly observable.
Provider may control the required evidence.
Visibility
❤️ Monitor the Monitoring Silence can mean "nothing happened" or "the sensor stopped working"
Domain controller sends: 30,000 security events per hour.
Events received: zero.
Possible explanation:
Cloud & SaaS Monitoring
Cloud services produce important telemetry outside traditional on-premises network boundaries.
Authentication, MFA and privilege events.
Administrative and API actions against cloud resources.
Flows, security groups and connectivity.
Access, sharing and configuration events.
User actions, file sharing and administrative changes.
Endpoint, application and container telemetry where applicable.
☁️ Ephemeral Systems Need External Telemetry The workload may disappear before the investigation begins
Starts: 10:00.
Compromised: 10:14.
Automatically destroyed: 10:30.
If relevant logs remained only inside the container:
the evidence may disappear with it.
Monitoring & Privacy
Security monitoring can expose substantial information about employees, customers and system users.
Monitoring should follow applicable legal, contractual, privacy, policy and retention requirements.
Password Spraying
An attacker tries one commonly used password against many accounts.
Impossible Travel?
Possible explanations include:
Customer Database Exfiltration
Compromised Service Account
Account: svc-payments-api
Source: Application Servers A + B
Authentication: non-interactive
Source: employee laptop
Authentication: interactive
Action: privileged file access
The Attacker Deletes the Logs
An attacker compromises a Windows administrator account and clears local security logs.
🎓 CISSP Scenarios Recognise the monitoring and detection principle being tested
A user authenticates successfully.
What is this?
An event.
The authentication system writes the user, source, timestamp and result to storage.
What was created?
A log record.
Detection logic identifies the login as unusual and notifies the SOC.
What was generated?
An alert.
Investigation confirms the account was compromised.
What may now be declared?
A security incident.
A security team receives millions of logs but important events lack usernames and source addresses.
Primary problem?
Poor log quality / insufficient context.
Two systems show apparently contradictory event sequences because their clocks differ.
What control helps?
Time synchronisation.
An attacker compromises a server and deletes the local logs.
Which architecture could improve evidence preservation?
Centralised / remote logging.
Logs contain passwords in clear text.
Primary concern?
Logging has created a sensitive-data exposure.
Logs are deleted after seven days, but incidents often remain undetected for months.
Which issue?
Inadequate retention.
Security wants to analyse identity, network and endpoint activity in one place.
Which technology is particularly relevant?
SIEM.
Three vendors use different field names for source IP address.
Which SIEM function helps?
Normalisation / parsing.
A raw security event is combined with asset criticality and threat intelligence.
Which concept?
Enrichment.
Several individually ordinary events together indicate account takeover.
Which SIEM function?
Correlation.
An IDS identifies suspicious traffic and alerts the SOC.
Primary role?
Detection.
An IPS identifies an exploit attempt and blocks the connection.
Primary distinction?
It can take preventative action.
Security wants to detect malicious processes running directly on a server.
Network or host monitoring?
Host-based monitoring.
Security wants visibility into attacks crossing a network segment.
Which technology?
Network-based IDS / IPS.
A detection mechanism searches for a known malicious byte pattern.
Which method?
Signature-based detection.
A system alerts because an account behaves very differently from its normal pattern.
Which approach?
Anomaly / behaviour-based detection.
Legitimate backup software repeatedly triggers a malware alert.
Which detection outcome?
False positive.
Malware runs but generates no alert.
Which detection outcome?
False negative.
A genuine attack triggers a detection rule.
Which outcome?
True positive.
The SOC receives so many false alarms that analysts ignore alerts.
Which problem?
Alert fatigue / poor signal-to-noise ratio.
Security modifies noisy detection thresholds after analysing false positives.
Which activity?
Detection tuning.
Security disables an entire category of detection because one approved scanner causes noise.
Primary risk?
Creating a monitoring blind spot.
A server suddenly stops transmitting logs.
Should the SOC assume nothing happened?
No. Monitor logging-system health.
Security monitors outbound connections for communication with attacker infrastructure.
Which activity?
Egress monitoring.
A firewall blocks all unauthorised outbound internet connections from a database server.
Monitoring or filtering?
Egress filtering.
A compromised workstation transfers large amounts of information to a new external destination.
Which monitoring area is particularly relevant?
Egress monitoring.
A threat feed provides a list of malicious domains.
Does that automatically make the information relevant?
No. It requires context and evaluation.
Threat information is analysed in the context of attacks targeting the organisation's industry.
What has been added?
Context and intelligence value.
Defenders search historical logs for attacker behaviour even though no alert fired.
Which activity?
Threat hunting.
A hunt discovers a previously undetected attacker technique.
What useful next step?
Create or improve an automated detection.
Security detects an account logging in from an unusual location.
Does this prove account compromise?
No. It is an anomaly requiring context.
Security models user and service-account behaviour to identify deviations.
Which technology?
UEBA.
A service account normally runs only from two servers but suddenly authenticates interactively from a laptop.
Why is this interesting?
Behaviour deviates from the established pattern.
A SIEM contains logs from every server except the newly deployed payment platform.
Primary issue?
Telemetry coverage gap.
The payment platform sends logs, but its format changed after an upgrade and parsing stopped.
Primary issue?
Monitoring pipeline / parsing failure.
A cloud workload exists for twenty minutes and then is automatically destroyed.
Where should important telemetry ideally exist?
Outside the ephemeral workload in durable monitoring systems.
Security records employee browsing activity for monitoring.
Which nontechnical concern remains important?
Privacy, policy and legal requirements.
A detection rule alerts on every administrator login.
Why might this be ineffective?
It may produce excessive noise without useful risk context.
Security modifies the rule to alert only when privileged login also involves an unmanaged device or unusual source.
What improved?
Detection context and signal quality.
A threat indicator matches a connection from a critical production server.
What should happen next?
Validate and investigate the surrounding activity.
A threat feed reports an IP as malicious but the indicator is three years old.
Which intelligence property is questionable?
Timeliness / current relevance.
Security knows attackers use credential dumping but collects no endpoint telemetry capable of revealing it.
What is missing?
Detection telemetry / coverage.
A detection rule exists but has never been tested.
Can the organisation confidently claim detection capability?
No. Detection should be validated.
The SIEM generates an alert but nobody is responsible for reviewing it.
Primary weakness?
Detection exists without operational response ownership.
A database server connects to the internet for the first time in its history.
Which concept may identify this?
Behaviour / anomaly detection and egress monitoring.
Security sees encrypted outbound traffic to an unusual destination but cannot inspect the payload.
Is the connection still useful telemetry?
Yes. Metadata and behaviour can remain valuable.
Management asks why logging and monitoring exist.
Best overall answer?
To maintain visibility into security-relevant activity and enable timely detection, investigation and risk decisions.
7.2 vs 7.6 vs 7.7
Observe activity and generate detection.
SEE IT
Manage a security incident through response, mitigation, recovery and lessons learned.
HANDLE IT
Operate technologies such as firewalls, IDS/IPS, anti-malware, sandboxing and other protection mechanisms.
OPERATE THE CONTROLS
Domain 7 Distinction
Recognise the Clue Words
Something Happened
Activity.
EventActivity Recorded
Evidence.
LogDetection Fires
Needs review.
AlertConfirmed Security Problem
Manage it.
IncidentMany Log Sources
Central analysis.
SIEMDifferent Log Formats
Common fields.
NormaliseAdd Asset + Threat Context
More meaning.
EnrichConnect Several Events
Pattern.
CorrelateDetect + Alert
Observe attack.
IDSDetect + Block
Prevent.
IPSKnown Attack Pattern
Match.
SignatureDifferent From Normal
Behaviour.
AnomalyAlarm · No Attack
Noise.
False PositiveNo Alarm · Real Attack
Miss.
False NegativeToo Many Alerts
Analyst overload.
Alert FatigueReduce Detection Noise
Improve quality.
TuningWatch Traffic Leaving
Outbound.
Egress MonitoringBlock Traffic Leaving
Preventive.
Egress FilteringMalicious IP List
Raw threat data.
Threat FeedThreat Data + Context
Decision value.
Threat IntelligenceSearch Before Alert
Proactive.
Threat HuntingUser Behaviour Changes
Baseline deviation.
UEBANew Country Login
Not automatically malicious.
Investigate AnomalyNo Logs Arriving
Sensor health?
Monitor MonitoringLogs Deleted Too Soon
Historical blind spot.
RetentionCorrect Event Sequence
Clocks.
Time SynchronisationTemporary Cloud Workload
Preserve externally.
Central LoggingDetection Exists but No Data
Can't see it.
Telemetry Gap⚠️ Common CISSP Mistakes Visibility does not automatically mean effective detection
Events happen constantly.
Alerts are generated when monitoring logic identifies something worth attention.
Alerts normally require validation and investigation.
An event sitting inside an unread file provides little active detection value.
Detective controls identify activity.
Preventive controls attempt to stop it.
Collect security-relevant information with sufficient context.
Excessive noise can reduce analyst effectiveness.
Telemetry, parsing, detection content, tuning and operational response all matter.
SIEM focuses on security information and event analysis.
SOAR focuses on orchestration, automation and response workflows.
IDS primarily detects and alerts.
IPS can take preventative action.
They observe different evidence sources.
Signature looks for recognised patterns.
Anomaly detection looks for deviation from expected behaviour.
Legitimate activity can also be unusual.
False positive = alarm without attack.
False negative = attack without alarm.
A system that never alerts can have very few false positives while missing every attack.
Reduce known noise without creating dangerous blind spots.
Monitoring frequency should support timely risk decisions.
Detection systems and telemetry pipelines may themselves have failed.
A compromised host may allow attackers to alter local logs.
Retention should align with security, legal, privacy and business requirements.
Cost, performance, noise, privacy and sensitivity matter.
Avoid unnecessary secrets and sensitive information.
Monitoring observes.
Filtering restricts.
Connection metadata and behavioural information may still be available.
Intelligence requires useful analysis and context.
Validate the surrounding activity.
Intelligence has a relevance and timeliness dimension.
Hunting proactively searches for attacker behaviour.
Behavioural anomalies require investigation and context.
Stolen credentials and insider misuse can involve successful authentication.
Cloud and SaaS activity require appropriate cloud telemetry.
Detection capability should be tested and maintained.
Monitor collection and parsing health.
Privacy, authority and data-governance requirements still apply.
Quick Reference
| If you see... | Think... |
|---|---|
| Something happened | Event |
| Event recorded | Log |
| Detection notification | Alert |
| Confirmed security problem | Incident |
| Many logs, one platform | SIEM |
| Different fields, common meaning | Normalisation |
| Add asset / identity / threat context | Enrichment |
| Combine related events | Correlation |
| Detect and alert | IDS |
| Detect and prevent | IPS |
| Observe network traffic | Network IDPS |
| Observe endpoint activity | Host IDPS |
| Known malicious pattern | Signature Detection |
| Deviation from normal | Anomaly Detection |
| Alarm, no attack | False Positive |
| Attack, no alarm | False Negative |
| Too many alerts | Alert Fatigue |
| Improve detection quality | Tuning |
| Watch outbound traffic | Egress Monitoring |
| Restrict outbound traffic | Egress Filtering |
| Threat-related data stream | Threat Feed |
| Threat data with meaning and context | Threat Intelligence |
| Actor behaviour | TTP |
| Proactively search for attacker activity | Threat Hunting |
| User / system behaviour baseline | UEBA |
| Unusual behaviour | Investigate, Not Automatically Malicious |
| Logs stop arriving | Monitoring Health |
| Temporary cloud workload | External / Central Telemetry |
| Different system clocks | Time Synchronisation |
| Old logs unavailable | Retention Problem |
| Logs modified by attacker | Integrity Problem |
| Secrets written to logs | Logging Design Problem |
IDPS Memory Aid
Detection Outcome Memory Aid
SIEM Memory Aid
Threat Intelligence Memory Aid
UEBA Memory Aid
7.2 Master Memory Aid
Generate → Collect → Correlate → Detect → Triage → Tune
The Monitoring Analyst's Questions
Key Takeaways
CISSP 7.2 focuses on conducting logging and monitoring activities.
The current CISSP scope explicitly includes IDPS, SIEM, continuous monitoring and tuning, egress monitoring, log management, threat intelligence including threat feeds and threat hunting, and UEBA.
Logging records activity.
Monitoring observes security-relevant activity and system state.
Detection identifies events or patterns that may require investigation.
Log → Monitor → Detect.
An event is something that occurs.
A log record records an event.
An alert indicates that detection logic identified something potentially significant.
An incident is a security event or group of events determined to require incident-management action.
Event ≠ alert. Alert ≠ incident.
Useful security telemetry may come from identity systems, endpoints, networks, firewalls, DNS, proxies, email, databases, applications, cloud services and SaaS platforms.
A good log should provide enough context to understand who performed an action, what occurred, when it happened, where it happened and what the result was.
Logging enormous volumes of poorly structured information does not automatically improve security visibility.
Log volume ≠ log value.
Accurate time is important because detection and investigation frequently correlate events from multiple systems.
Time synchronisation and time-zone normalisation help build reliable timelines.
Log management covers the creation, transmission, storage, access, analysis, retention and eventual disposal of log information.
Centralised logging can preserve evidence away from compromised systems and enable correlation across multiple data sources.
Logs should be protected for confidentiality, integrity and availability.
Attackers may attempt to alter or destroy logs to hide their activity.
Remote forwarding, appropriate access controls and protected or immutable storage can strengthen log integrity.
Log retention should support security, forensic, business, legal and regulatory needs.
A log deleted before the investigation begins cannot help the investigation.
Logging everything indefinitely is not automatically desirable because storage cost, operational performance, privacy, noise and data sensitivity must also be considered.
Sensitive credentials and secrets should not be unnecessarily written to logs.
A SIEM centralises security information and can parse, normalise, enrich, correlate, search and analyse security events.
Normalisation maps different representations to common security concepts.
Enrichment adds context such as asset criticality, identity information, vulnerabilities or threat intelligence.
Correlation connects related events to reveal patterns that individual log entries may not show.
Several weak signals can form one strong detection.
A SIEM does not automatically create an effective detection capability.
Logging coverage, parsing, detection logic, tuning, analyst processes and incident response all contribute to operational effectiveness.
SIEM and SOAR are related but different.
SIEM focuses primarily on security information and event analysis.
SOAR focuses on orchestration, automation and response workflows.
Intrusion Detection Systems identify suspicious activity and typically alert.
Intrusion Prevention Systems can additionally take preventative action.
IDS = detect. IPS = detect + act.
Network-based detection examines network activity.
Host-based detection examines activity on an individual system.
Signature-based detection identifies known patterns.
Anomaly-based detection identifies significant deviations from expected behaviour.
Signature techniques can be effective against recognised attacks but may miss novel behaviour.
Anomaly techniques can reveal previously unknown behaviour but commonly require careful baseline development and tuning.
A true positive occurs when a real attack triggers an alert.
A false positive occurs when legitimate activity incorrectly triggers an alert.
A false negative occurs when malicious activity occurs without the expected alert.
False positive = alarm without attack. False negative = attack without alarm.
Continuous monitoring maintains ongoing security awareness at a frequency sufficient to support risk decisions.
It does not necessarily mean every security control must be measured every millisecond.
Detection tuning is required because environments, normal behaviour and threats change.
Tuning should reduce noise without creating unnecessary blind spots.
Alert fatigue occurs when excessive alerts reduce analysts' ability to recognise and investigate important events.
More alerts ≠ better detection.
Detection engineering should begin with a threat or security objective, identify the telemetry required to observe it, create detection logic, test that logic and tune it based on operational results.
Detection coverage depends on telemetry coverage.
A detection cannot identify behaviour that produces no observable information available to the monitoring system.
Monitoring systems themselves should be monitored.
A sudden absence of logs may indicate a broken agent, network failure, configuration error or attacker interference.
No alerts ≠ no attacks.
Egress monitoring examines outbound traffic and can help identify command-and-control communication, exfiltration, unusual destinations, DNS abuse and unauthorised cloud use.
Egress monitoring and egress filtering are distinct.
Monitoring observes outbound activity.
Filtering restricts outbound activity.
Egress monitoring = detective. Egress filtering = preventive.
Encryption may reduce visibility into communication contents, but metadata such as endpoints, timing, volume and behavioural patterns can still provide useful detection information.
Threat intelligence provides information that can help organisations identify, assess, monitor and respond to cyber threats.
Threat information may include indicators, attacker TTPs, threat actors, campaigns, vulnerabilities and recommended defensive actions.
A threat feed supplies threat-related data.
Threat intelligence adds analysis, context and relevance to support decisions.
Feed = data. Intelligence = data + context + meaning.
Threat indicators such as IP addresses and file hashes can change quickly.
Understanding attacker behaviour and TTPs can provide more durable detection opportunities.
Threat intelligence should be evaluated for relevance, timeliness, reliability, context and actionability.
Importing huge quantities of low-quality indicators can increase noise rather than improve security.
Threat hunting proactively searches for malicious activity that automated detection may not have identified.
Hunts can begin from threat intelligence, hypotheses, suspicious patterns or known adversary behaviour.
Successful threat hunts can be converted into automated detection logic, strengthening future monitoring.
Hunt → learn → detect better.
UEBA analyses behavioural patterns associated with users and other entities such as endpoints, servers, applications and service accounts.
It can identify deviations from expected behaviour that warrant further investigation.
Behavioural anomalies do not automatically prove malicious intent.
Business travel, VPNs, system changes and legitimate unusual work can produce abnormal-looking activity.
Anomaly = investigate. Anomaly ≠ guilty.
UEBA can be particularly useful where valid credentials are being misused, because successful authentication does not guarantee legitimate behaviour.
Cloud and SaaS environments require monitoring of identity, control-plane, storage, network, administrative and service activity.
Ephemeral workloads make durable central telemetry especially important because the original resource may disappear before an investigation begins.
Security monitoring can contain substantial personal and sensitive information, so privacy, authority, retention and access-control requirements remain important.
Detection is most effective when technical signals are combined with business and threat context.
The central CISSP principle is: collect trustworthy security telemetry, protect it, correlate it, detect meaningful activity, investigate in context and continually tune the monitoring capability as systems and threats change.
📚 Sources & Further Reading Logging, monitoring, detection and threat-intelligence references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-92 - Guide to Computer Security Log Management
View NIST log-management guidance - NIST SP 800-92 Rev. 1 - Cybersecurity Log Management Planning Guide - Initial Public Draft
View the current NIST revision draft - NIST SP 800-137 - Information Security Continuous Monitoring
View NIST continuous-monitoring guidance - NIST SP 800-94 - Guide to Intrusion Detection and Prevention Systems
View NIST IDPS guidance - NIST SP 800-150 - Guide to Cyber Threat Information Sharing
View NIST threat-information guidance - NIST SP 800-215 - Guide to a Secure Enterprise Network Landscape
View NIST modern enterprise security guidance - NIST Cybersecurity Framework - Detect
View the NIST Cybersecurity Framework