Security Operations, Monitoring and Analytics

Introduction

Cybersecurity is not achieved solely by installing preventive controls. Even well-designed systems may be misconfigured, exploited through unknown vulnerabilities, or compromised through stolen credentials. Security operations therefore provide the continuous capability to observe, detect, investigate, contain and learn from security events.

A modern security operations capability combines several technologies and practices. Security information and event management (SIEM) platforms collect and correlate logs. Endpoint detection and response (EDR) systems monitor computers and servers in detail. Security orchestration, automation and response (SOAR) platforms coordinate investigations and execute approved actions. Threat hunting searches proactively for evidence of compromise, including activity that has not triggered an existing alert. Analytics, baselines and metrics help analysts distinguish normal behaviour from suspicious activity and evaluate whether the operation is effective.

The central challenge is not simply collecting more data. It is producing reliable, timely and explainable evidence that supports appropriate decisions. Excessive alerts create analyst fatigue, while weak monitoring leaves attackers undetected. Artificial intelligence can improve prioritisation and detection, but it can also introduce opacity, bias, privacy risks and new avenues for adversarial manipulation.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain the purpose and architecture of security operations.
2. Distinguish SIEM, EDR, SOAR and threat-hunting functions.
3. Assess the quality, context and limitations of logs and telemetry.
4. Design detection rules, behavioural baselines and investigation workflows.
5. Calculate and interpret security operations metrics.
6. Evaluate automation, false positives and AI-assisted detection.
7. Identify adversarial AI risks and governance requirements.
8. Apply these concepts to an incident-response scenario.

1. Security Operations as a Socio-Technical System

A security operations centre (SOC) is a socio-technical system: people, processes, technology and governance work together to reduce cyber risk. Technology supplies observations and recommended actions, but analysts provide interpretation, judgement and accountability.

A simplified operational cycle is:

Prepare → Collect → Detect → Triage → Investigate → Respond → Recover → Learn

Preparation includes asset inventory, time synchronisation, logging standards, access control and playbooks. Collection gathers events from endpoints, networks, applications, identity systems, cloud services and security devices. Detection converts observations into alerts. Triage determines priority and whether an alert is credible. Investigation establishes scope, cause and impact. Response contains the threat and restores safe operation. Lessons learned improve controls and detection logic.

Security operations should be risk-based. A failed login to a low-value public service may deserve less attention than a successful login to a privileged administrator account from an unusual country. Consequently, a useful event record contains not only what happened, but also who, where, when, on which asset, using what identity, and with what business significance.

Important terminology

• Event: A recorded occurrence, such as a login or process start.
• Log: A structured or unstructured record of events generated by a system.
• Telemetry: Measurements and observations collected continuously from systems.
• Alert: A notification that activity may satisfy suspicious conditions.
• Incident: A confirmed or suspected event requiring investigation or response.
• Indicator of compromise (IOC): Evidence associated with malicious activity, such as a hash or domain.
• Tactic: An adversary’s broad objective, such as credential access.
• Technique: A method used to achieve a tactic, such as credential dumping.
• Use case: A defined monitoring and detection requirement.
• Playbook: A documented sequence of investigation or response actions.

2. Data Sources, Log Quality and Telemetry Design

Effective monitoring begins with a logging strategy rather than indiscriminate collection. Common sources include:

A logging decision should consider the threat being detected, the required fields, retention period, collection cost, privacy implications and operational owner. Logs should be centralised or made available to investigators, protected from unauthorised alteration and associated with reliable timestamps.

Log quality dimensions

1. Completeness: Whether relevant events are recorded.
2. Accuracy: Whether records represent what actually occurred.
3. Timeliness: How quickly events become available for analysis.
4. Consistency: Whether fields use stable names, formats and meanings.
5. Context: Whether identity, asset criticality and location are included.
6. Integrity: Whether records are protected against tampering.
7. Retention: Whether data remains available for the required period.

Time synchronisation is especially important. If endpoint clocks differ substantially, an analyst may infer an incorrect sequence of events. Network Time Protocol should be securely configured, and systems should record timezone or use a consistent standard such as Coordinated Universal Time.

Data minimisation is also necessary. Monitoring should collect information relevant to a legitimate security purpose and restrict access to sensitive content. Logs can contain personal data, credentials accidentally placed in URLs, medical information or confidential business records. Encryption, role-based access, retention limits and audit trails reduce associated risks.

3. SIEM: Correlation and Security Analytics

A SIEM platform aggregates, normalises, searches and correlates security-relevant events. Its major functions are:

• ingestion from diverse sources;
• parsing and field normalisation;
• enrichment with asset, identity, geolocation or threat-intelligence data;
• rule-based and statistical detection;
• dashboards, search and case management;
• alert prioritisation and reporting.

A typical data path is:

Source systems → Collectors → Parsing and normalisation → Enrichment → Detection and correlation → Alert and case → Investigation

SIEM does not automatically make poor data useful. Missing endpoint coverage, inconsistent identity fields and excessive duplicate events can undermine detection. Cost is another constraint: high-volume telemetry may require filtering, tiered storage or sampling. Filtering must be designed carefully because removing an apparently unimportant field may prevent future investigations.

Correlation and detection rules

A rule translates a security hypothesis into observable conditions. For example:

Alert when a privileged account successfully authenticates from a new country and, within 15 minutes, creates a new administrator account on a critical server.

This rule combines identity, geography, time, privilege and asset context. A robust rule should specify its data sources, required fields, threshold, severity, exclusions, response action, owner and validation method.

Detection rules may be:

• Signature-based: Match a known hash, domain, command or pattern.
• Threshold-based: Alert when an event count exceeds a limit.
• Sequence-based: Detect events occurring in a meaningful order.
• Correlation-based: Combine evidence from multiple systems.
• Behavioural: Identify deviation from an established pattern.
• Risk-based: Combine event severity with asset and identity context.

Rules should be tested against historical data and benign examples. They also require version control, peer review, documentation and periodic retirement. Attackers change techniques, and business processes change normal behaviour.

4. EDR and Endpoint-Centred Visibility

EDR agents observe endpoint activity and provide investigation and response functions. Depending on the platform and operating system, telemetry may include process trees, command-line arguments, loaded modules, persistence mechanisms, file modifications, registry changes, user sessions and network connections.

The process tree is particularly valuable. A word processor launching a shell, which launches a scripting interpreter that downloads an executable, conveys more meaning than any individual event. EDR can support actions such as isolating a host from the network, terminating a process, quarantining a file and collecting forensic evidence.

EDR has limitations. Agents may be disabled, bypassed or absent from unmanaged devices. Kernel-level visibility may vary by operating system. High-volume process telemetry creates storage and privacy challenges. Isolation can also interrupt essential business activity. Response actions should therefore be authorised, logged and reversible where possible.

SIEM and EDR are complementary. EDR supplies detailed endpoint evidence; SIEM relates that evidence to identity, network, cloud and business context. An EDR alert about suspicious PowerShell activity becomes more significant when the same account accessed a sensitive database and generated unusual outbound traffic.

5. SOAR and Security Automation

SOAR platforms connect tools through integrations and execute workflows. A playbook might receive an alert, enrich an IP address with threat intelligence, retrieve asset ownership, search for related events, open a case and request approval before isolating a device.

Automation can be classified as:

1. Informational: Collect evidence and present it to an analyst.
2. Assistive: Recommend an action or prepare a response.
3. Conditional: Execute an action only when defined conditions are met.
4. Autonomous: Act without human approval.

The more disruptive or irreversible the action, the stronger the case for human approval. Automatically deleting files or disabling an account can cause operational harm if the alert is wrong. Safe automation uses least privilege, explicit conditions, rate limits, audit logging, rollback procedures and testing in a controlled environment.

Automation should reduce repetitive work rather than conceal uncertainty. A playbook should state what it assumes, what evidence it collects, when it stops, who is notified and how errors are handled.

6. Threat Hunting

Threat hunting is a proactive, hypothesis-driven search for suspicious activity. It differs from routine alert handling because the hunter begins with a question rather than a generated notification. Examples include:

• Are any service accounts performing interactive logins?
• Which hosts executed unsigned scripts from user-writable directories?
• Did a newly registered domain receive connections from internal systems?
• Are there signs of lateral movement that bypassed existing rules?

A hunt commonly follows these stages:

1. Define a hypothesis based on threat intelligence, incidents or system knowledge.
2. Identify required data and assess its reliability.
3. Search broadly, then refine using context and exclusions.
4. Examine timelines, relationships and outliers.
5. Determine whether findings indicate malicious activity, benign activity or a data gap.
6. Convert validated findings into detections, controls or collection improvements.

Threat hunting is not merely searching for known IOCs. It may use adversary behaviours, attack paths, unusual relationships and weak signals. However, hunting conclusions must be evidence-based. An unusual event is not automatically malicious, and absence of evidence is not evidence of absence when telemetry is incomplete.

7. Baselines and Anomaly Detection

A baseline describes expected behaviour for an entity, time period or process. Examples include a user’s normal login locations, a server’s usual outbound destinations or a service account’s expected API calls.

A simple count baseline can use the mean and standard deviation of observations. If x_t is the event count during period t, the sample mean is:

Here, n is the number of observation periods and x̄ is the average count. The sample standard deviation is:

A basic standardised score for a new observation x is:

The score is dimensionless because the numerator and denominator have the same units. This approach assumes observations are sufficiently comparable and that the mean and standard deviation are meaningful. It can perform poorly with seasonal, heavily skewed or contaminated data. A high score is an investigation signal, not proof of an attack.

For a small worked example, suppose daily failed-login counts are 2, 3, 2, 4 and 4. The mean is x̄ = 3. The squared deviations sum to 4, so the sample standard deviation is s = √(4/4) = 1. If the next day has 7 failures, z = (7 − 3)/1 = 4. This is unusual relative to the small sample, but the analyst must still check scheduled testing, password resets, shared devices and other explanations.

Baselines should be segmented where appropriate. A global baseline may incorrectly label a help-desk employee’s activity as anomalous because it compares the employee with all users. Role, department, shift, asset type and seasonality can improve accuracy. Baselines must also be retrained cautiously after an incident; otherwise malicious behaviour may become absorbed as “normal.”

8. Detection Quality and Security Metrics

Metrics should support decisions rather than reward superficial activity. Useful measures include coverage, timeliness, effectiveness, workload and resilience.

Classification measures

For a detection system, a true positive is malicious activity correctly detected; a false positive is benign activity incorrectly flagged; a true negative is benign activity correctly ignored; and a false negative is malicious activity missed.

Precision measures the proportion of alerts that are correct:

Recall, also called sensitivity, measures the proportion of malicious cases detected:

The F1 score is the harmonic mean of precision and recall:

These measures require labelled cases and can be misleading when the base rate of genuine attacks is very low. A detector can have apparently high accuracy by classifying nearly everything as benign. For operational use, analysts should also examine alert volume, investigation time, severity distribution and missed incidents.

Worked metric example

Assume a review identifies 40 true positives, 10 false positives and 20 false negatives. Precision is 40/(40 + 10) = 0.80, or 80%. Recall is 40/(40 + 20) ≈ 0.667, or 66.7%. The F1 score is approximately 2 × (0.80 × 0.667)/(0.80 + 0.667) ≈ 0.727, or 72.7%. The result indicates reasonably precise alerts but important missed activity.

Other practical metrics include:

Metrics should be reported with definitions, scope, time period and data limitations. Management should avoid using them as simplistic individual performance quotas, which may encourage closing cases prematurely.

9. False Positives, False Negatives and Alert Prioritisation

A false positive consumes investigation time and may cause alert fatigue. A false negative allows harmful activity to remain undetected. The appropriate balance depends on business impact, attack likelihood, response cost and the reversibility of harm.

False positives commonly arise from broad rules, shared accounts, automated administration, vulnerability scanning, software updates and incomplete asset context. Reduction techniques include allow-listing with expiry dates, role-aware thresholds, asset criticality, event deduplication, sequence correlation and feedback from investigations.

Allow-lists require governance. A permanent exception for a known scanner can conceal a compromised scanner account. Each exception should have an owner, reason, scope, expiration date and review record.

Prioritisation can combine technical severity with context. A low-confidence event on a domain controller may deserve more attention than a high-confidence event on an isolated test machine. Risk scores should be explainable enough that analysts can challenge them.

10. AI-Assisted Detection and Adversarial AI Risks

AI and machine learning may assist with classification, clustering, entity profiling, natural-language search, alert summarisation and anomaly detection. These capabilities are valuable when telemetry is high-volume and relationships are difficult to express through fixed rules.

AI-assisted detection introduces several risks:

• Concept drift: Normal behaviour changes as systems, users and threats change.
• Training-data bias: Historical labels may reflect inconsistent investigation practices.
• Lack of explainability: Analysts may not understand why a score was assigned.
• Data leakage: Sensitive logs may be sent to an unauthorised model or provider.
• Automation bias: Analysts may accept model output without sufficient verification.
• Adversarial manipulation: Attackers may craft activity to evade or poison a model.
• Model supply-chain risk: A compromised dependency or update can alter behaviour.

Adversarial examples may involve small changes to commands, timing, filenames or network patterns that move activity below a detection threshold. Data poisoning occurs when an attacker injects misleading training or feedback data. Prompt injection is relevant where a language model reads attacker-controlled content and is connected to tools; untrusted text must not be treated as an instruction with authority.

Responsible deployment requires data classification, access control, model evaluation, monitoring for drift, independent validation, human review for high-impact actions, secure model-update processes and records of model version and evidence. AI should augment analysts rather than become an unaccountable decision-maker. Detection performance should be tested on realistic, time-separated data, including evasive and previously unseen behaviour.

11. Governance, Ethics and Legal Considerations

Security monitoring can affect privacy, employment, freedom of expression and due process. Governance should define the legitimate purpose of monitoring, authorised users, retention periods, escalation rules and procedures for handling personal data. Employees should receive appropriate notice where required by law and organisational policy.

Evidence handling matters in disciplinary and legal contexts. Logs should preserve provenance, access history and integrity controls. Analysts should distinguish observed facts from assumptions and document uncertainty. Monitoring must not be used to target individuals unlawfully or discriminate against groups based on protected characteristics.

Common governance references include an organisation’s incident-response policy, privacy requirements, records-retention rules, contractual obligations and applicable cybersecurity frameworks. Framework alignment is useful, but compliance does not guarantee effective detection. Controls must be tested in the actual operational environment.

12. Illustrative Case: Compromised Cloud Administrator

Background

A fictional online retailer operates a hybrid environment with cloud applications, Windows endpoints, an identity provider and a central SIEM. EDR covers corporate laptops and production servers. The SOC has two analysts on each shift and uses a SOAR platform for enrichment and ticket creation.

Problem

The identity provider reports a successful login to a cloud administrator account from an unfamiliar country at 02:14 UTC. A second event shows creation of an access key. The initial rule generated a medium-priority alert, but similar alerts had often resulted from travelling administrators.

Analysis

The analyst correlates identity, asset and cloud telemetry. The account normally performs interactive logins from one region and uses MFA. The new login used a new device fingerprint. Within six minutes, the account accessed storage containing customer-export files and altered a logging configuration. EDR then records a command-line tool on a server using the new access key. The combination of unusual login, privilege change, sensitive-data access and logging modification raises confidence substantially.

The analyst checks whether the user was travelling, verifies the event with the identity owner through an independent channel and confirms that the activity was not authorised. A threat hunt searches for use of the access key across cloud accounts and looks for downloads, persistence and additional identity changes.

Approach and solution

The SOAR playbook automatically collects related cloud events, identifies affected resources and opens an incident. Because disabling the administrator account could interrupt production, the playbook requests analyst approval. After confirmation, the team disables the access key, revokes active sessions, resets credentials, restores logging configuration and isolates the server associated with the command-line activity. Cloud audit logs are preserved, and affected data access is reviewed.

Detection engineering then improves the rule by adding device novelty, MFA context, asset criticality, access-key creation and sensitive-storage access. The rule is tested against historical administrator travel and approved automation to limit false positives. A new hunt examines other privileged accounts for similar access-key behaviour.

Outcome

The investigation determines that credentials were stolen through a phishing attack. No evidence confirms large-scale data exfiltration, but access to sensitive files occurred. The organisation introduces phishing-resistant authentication for privileged users, short-lived cloud credentials, stricter key monitoring and a reviewed emergency-access procedure.

Learning points

1. A single unusual login was ambiguous; correlated evidence made it significant.
2. Identity, cloud, endpoint and configuration telemetry were all necessary.
3. Automation accelerated evidence collection without making an irreversible decision automatically.
4. Detection rules should account for legitimate exceptions but not rely on permanent allow-lists.
5. Incident findings should improve both controls and future hunting hypotheses.

13. Contemporary Practice and Best Practices

Current security operations increasingly involve cloud-native logging, identity-centric detection, extended detection and response, attack-path analysis and continuous control validation. Organisations are also adopting detection-as-code: rules are stored in version-controlled repositories, tested automatically and deployed through controlled pipelines.

Effective practice includes:

• maintaining an accurate asset and identity inventory;
• defining logging requirements for important attack paths;
• synchronising time and standardising schemas;
• enriching events with ownership, criticality and identity context;
• using both deterministic rules and carefully governed behavioural analytics;
• testing detections with benign and adversarial simulations;
• measuring false positives and missed detections, not just alert counts;
• documenting playbooks and testing rollback procedures;
• protecting monitoring data as sensitive information;
• reviewing AI systems for drift, bias, explainability and adversarial risk;
• conducting regular hunts and converting validated findings into durable detections;
• preserving analyst judgement and escalation authority.

The most mature SOCs treat detection as an engineering lifecycle: define a hypothesis, identify data, implement a rule, test it, deploy it, measure outcomes, tune it and retire it when its value declines.

Chapter Summary

Security operations provide continuous visibility and response through people, processes and technology. SIEM platforms centralise and correlate logs; EDR supplies detailed endpoint telemetry and response; SOAR coordinates enrichment and workflow automation; and threat hunting proactively searches for evidence that routine alerts may miss. Reliable operations depend on complete, timely, accurate, contextual and protected telemetry.

Detection rules should express clear hypotheses, use appropriate thresholds and sequences, undergo testing and remain under lifecycle management. Baselines can identify unusual activity, but statistical scores are signals rather than proof and may fail when behaviour is seasonal, skewed or contaminated. Precision, recall and F1 help evaluate labelled detection performance, while operational metrics must be interpreted with scope and data limitations.

False positives create workload, whereas false negatives create exposure. Risk-based prioritisation, contextual enrichment and governed exceptions help balance them. AI can improve analysis and prioritisation, but concept drift, bias, privacy, opacity, prompt injection, model poisoning and evasion require strong governance. Effective security operations combine automation with accountable human judgement, ethical monitoring and continual learning.

Key Terms

SIEM: A platform that collects, normalises, correlates and analyses security events.

EDR: Endpoint detection and response technology that monitors and responds to endpoint activity.

SOAR: Security orchestration, automation and response technology for integrating tools and workflows.

Telemetry: Measurements and observations collected from systems and networks.

Log: A record of a system or application event.

Alert: A notification that activity may be suspicious.

Incident: A suspected or confirmed security event requiring investigation or response.

Threat hunting: Proactive, hypothesis-driven searching for signs of compromise.

Baseline: A description of expected behaviour for an entity or period.

Detection rule: Logic that identifies specified suspicious conditions.

Correlation: Combining related events to produce meaningful evidence.

IOC: An indicator associated with malicious activity.

False positive: Benign activity incorrectly classified as suspicious.

False negative: Malicious activity not detected by a control.

Precision: The proportion of generated positive alerts that are correct.

Recall: The proportion of relevant malicious cases that are detected.

Playbook: A documented sequence of investigation or response actions.

Concept drift: Change in data or behaviour that reduces model performance over time.

Detection-as-code: Managing detection logic through version control, testing and controlled deployment.

Alert fatigue: Reduced analyst attention caused by excessive or repetitive alerts.

Review Questions

Short Answer Questions

1. What are the principal functions of a SIEM platform?
2. How does EDR complement SIEM?
3. Define a false positive and a false negative.
4. Why is time synchronisation important in incident investigation?
5. What is the purpose of a threat-hunting hypothesis?

Long Answer Questions

1. Explain the security operations lifecycle from collection through lessons learned.
2. Compare signature-based, threshold-based, sequence-based and behavioural detection.
3. Discuss the benefits and risks of SOAR automation, including the role of human approval.
4. Explain how baselines can support anomaly detection and identify their limitations.
5. Evaluate the governance, privacy and security risks of AI-assisted detection.

Analytical / Application Questions

1. A detector produces 30 true positives, 15 false positives and 10 false negatives. Calculate precision, recall and F1, and interpret the result.
2. Design a detection use case for suspicious privileged cloud-account activity. Identify data sources, conditions, enrichment, likely false positives and response actions.
3. An organisation has many alerts but few confirmed incidents. Propose a measurement and improvement plan that addresses alert quality, data coverage, analyst workload and missed attacks.

Multiple Choice Questions with Answers

Question 1

Which capability is most closely associated with SIEM?

A. Centralising and correlating events from multiple sources

B. Replacing all endpoint operating systems

C. Physically repairing damaged servers

D. Encrypting every user document automatically

Correct Answer: A. Centralising and correlating events from multiple sources

Question 2

What is the main purpose of EDR telemetry?

A. To provide detailed visibility into endpoint activity and support response

B. To calculate an organisation’s annual budget

C. To manage employee payroll

D. To replace network routing protocols

Correct Answer: A. To provide detailed visibility into endpoint activity and support response

Question 3

Which action is most appropriate before automatically disabling a production administrator account?

A. Obtain suitable approval and verify the evidence

B. Delete all related logs

C. Ignore the alert until the next audit

D. Publish the account name publicly

Correct Answer: A. Obtain suitable approval and verify the evidence

Question 4

In the chapter’s metric definitions, precision is calculated as:

A. TP ÷ (TP + FP)

B. TP ÷ (TP + FN)

C. FP ÷ (TP + FP)

D. (TP + TN) ÷ all observations

Correct Answer: A. TP ÷ (TP + FP)

Question 5

A threat hunt normally begins with:

A. A hypothesis about potentially suspicious activity

B. Automatic deletion of all old logs

C. A request to disable monitoring

D. A random change to firewall rules

Correct Answer: A. A hypothesis about potentially suspicious activity

Question 6

What is a major weakness of a simple z-score baseline?

A. It may perform poorly with seasonal or heavily skewed data

B. It cannot use numerical observations

C. It always proves that an attack occurred

D. It eliminates the need for analyst review

Correct Answer: A. It may perform poorly with seasonal or heavily skewed data

Question 7

If TP = 40 and FP = 10, what is precision?

A. 20%

B. 40%

C. 80%

D. 90%

Correct Answer: C. 80%

Question 8

Which example is a false negative?

A. A benign login is flagged as malicious

B. A malicious action is not detected

C. A malicious action is correctly detected

D. A benign action is correctly ignored

Correct Answer: B. A malicious action is not detected

Question 9

Which risk is particularly associated with AI models used in security operations?

A. Concept drift and adversarial manipulation

B. Guaranteed elimination of privacy concerns

C. Permanent immunity to evasion

D. Automatic correctness of every explanation

Correct Answer: A. Concept drift and adversarial manipulation

Question 10

What is detection-as-code?

A. Managing detection logic with version control, testing and controlled deployment

B. Writing malware entirely in machine code

C. Replacing all analysts with software

D. Storing passwords in source repositories

Correct Answer: A. Managing detection logic with version control, testing and controlled deployment