Security Monitoring, Detection and Analytics

Introduction

Modern networks generate an enormous and heterogeneous record of activity: authentication events, DNS requests, endpoint telemetry, cloud control-plane actions, firewall decisions, application transactions, packet captures, and encrypted-flow metadata. Security monitoring is the disciplined process of collecting, interpreting, and acting on such evidence. Detection is the identification of activity that may represent a security violation, while analytics is the application of statistical, behavioural, and contextual techniques to discover relationships and anomalies that are difficult to identify through isolated alerts.

Monitoring is not equivalent to collecting the largest possible quantity of data. A mature capability must answer operational questions: What happened? Which assets and identities were involved? How reliable is the evidence? Is the activity malicious, authorised, or merely unusual? What should happen next, and how quickly? These questions place security monitoring at the intersection of network engineering, incident response, data management, risk governance, and human decision-making.

This chapter examines logs, flow records, packet analysis, IDS/IPS, endpoint and network detection, SIEM, UEBA, threat intelligence, and MITRE ATT&CK. It also develops principles for baselining, detection engineering, dashboards, metrics, and the responsible use of analytics and artificial intelligence.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish logs, flow records, packet data, endpoint telemetry, and security alerts.

2. Design a monitoring architecture that preserves context, integrity, privacy, and operational usefulness.

3. Explain the roles and limitations of IDS/IPS, EDR, NDR, SIEM, and UEBA.

4. Develop detection rules using hypotheses, behavioural baselines, and MITRE ATT&CK mappings.

5. Interpret alert-quality, coverage, timeliness, and response metrics.

6. Evaluate a monitoring capability using a realistic incident scenario.

7. Discuss governance, legal, ethical, and emerging-technology issues in security analytics.

1. The Evidence Model of Security Monitoring

A security monitoring system observes events rather than directly observing “attacks.” An event is a recorded occurrence, such as a successful login or a TCP connection. An alert is an interpretation of one or more events according to a detection rule or model. An incident is a confirmed or strongly suspected security event requiring coordinated response. Confusing these levels leads either to excessive escalation or to dangerous dismissal of significant signals.

A useful conceptual chain is:

Activity → Telemetry → Normalisation → Detection → Investigation → Response → Learning

Activity is what occurs in the environment. Telemetry is the evidence made available by sensors. Normalisation makes records comparable by representing fields such as timestamp, source address, user, device, action, and outcome consistently. Detection applies rules, correlation, or models. Investigation adds context and tests competing explanations. Response limits harm and restores trustworthy operation. Learning improves controls, data quality, and future detections.

1.1 Major telemetry types

Logs are structured or semi-structured records generated by systems and applications. Examples include authentication logs, firewall logs, operating-system audit records, database access logs, and cloud API logs. Logs commonly provide the richest semantic context, but their content and reliability vary by product and configuration.

Flow records summarise communications rather than recording every packet. A typical network flow contains source and destination addresses, source and destination ports, protocol, start and end times, packet or byte counts, and termination information. NetFlow, IPFIX, and similar technologies are useful for identifying scanning, unusual data transfer, and communication with suspicious infrastructure. They are less suitable for examining payload-level exploits.

Packet data includes complete packets or selected packet headers and payloads. Full packet capture can support forensic reconstruction and protocol analysis, but it requires substantial storage and raises privacy and encryption challenges. Selective capture, packet metadata, and strategically placed sensors are often more sustainable.

Endpoint telemetry records process creation, command-line arguments, file changes, registry or configuration modifications, memory activity, loaded modules, and user actions. Endpoint data can reveal execution and persistence that network-only monitoring misses.

Cloud and identity telemetry includes sign-ins, token use, privilege changes, key creation, resource deployment, policy modifications, and administrative API calls. In cloud environments, identity and control-plane events may be more informative than traditional perimeter traffic.

No single source is sufficient. For example, an unusual PowerShell process is more meaningful when correlated with a suspicious email attachment, a new outbound connection, and a subsequent credential-access event.

1.2 Data quality and trust

Monitoring data must be assessed for completeness, accuracy, timeliness, consistency, and provenance. Important controls include synchronised clocks, stable asset and identity identifiers, authenticated transport, access control, retention policies, and tamper-evident storage. Network Time Protocol should be securely configured because inaccurate timestamps can make event reconstruction unreliable.

A log that records “login failed” without an account, source, device, or time zone may be nearly useless for investigation. Conversely, collecting sensitive content without a defined purpose can create privacy and compliance risk. Data minimisation therefore means collecting sufficient evidence for defined security objectives rather than indiscriminately retaining everything.

2. Monitoring Architecture and Detection Operations

A monitoring architecture usually contains collection agents or sensors, transport and buffering, parsing and normalisation, storage, detection engines, investigation interfaces, and response integrations. Sensors may be deployed at internet gateways, data-centre boundaries, wireless controllers, cloud environments, endpoints, identity providers, and critical applications.

Centralisation improves correlation and search, but it also creates concentration risk. If an adversary can alter or disable the central platform, evidence may be lost. Important environments should use authenticated collection, restricted administrative access, independent time sources, resilient queues, and protected archival copies. Monitoring infrastructure itself must be monitored: sensor health, ingestion delay, dropped records, parsing failures, and unexpected reductions in event volume can be security indicators.

A practical operating model separates three related functions:

• Monitoring and triage: validates alerts, removes obvious benign explanations, and prioritises cases.
• Detection engineering: develops, tests, documents, deploys, and retires detections.
• Incident response and threat hunting: investigates suspected compromise and searches proactively for behaviours not yet represented by reliable alerts.

Detection engineering should use a lifecycle. First, state a threat hypothesis, such as “an attacker may use a newly created privileged account to access sensitive systems.” Next, identify required data sources and fields. Then specify logic, expected false positives, severity, response guidance, and ATT&CK mapping. Test the rule against representative benign and malicious data, deploy it in a controlled manner, measure its performance, and revise it as the environment changes.

3. Detection Technologies

3.1 Intrusion Detection and Prevention Systems

An IDS identifies suspicious network or host activity and generates alerts. An IPS places detection inline or otherwise enables automated blocking. Signature-based detection compares activity with known patterns, such as exploit sequences or malware indicators. It is efficient and explainable but weak against novel attacks and minor variations.

Anomaly-based detection identifies departures from an expected profile. It can reveal previously unknown activity but may generate many alerts when legitimate behaviour changes. Specification-based detection defines permitted protocol or application behaviour and identifies violations. Hybrid systems combine these methods with reputation, protocol analysis, and contextual correlation.

Inline prevention requires particular caution. A false positive can interrupt legitimate business activity, while a false negative can create unjustified confidence. High-confidence blocking is generally more appropriate for clearly malicious domains, exploit signatures with strong validation, or policy violations with low operational impact. Lower-confidence observations should often remain in detection mode.

3.2 Endpoint Detection and Response

EDR collects endpoint events and supports investigation, isolation, process termination, file quarantine, and other response actions. Its strength is visibility into execution, parent-child process relationships, scripts, persistence, and local privilege use. EDR can identify “living off the land” activity, in which legitimate administrative tools are abused.

EDR has limitations. Agents may be disabled, evaded, or absent from unmanaged devices. High-volume telemetry can overwhelm analysts. Kernel-level collection can create stability and privacy concerns. An EDR alert should therefore be interpreted with identity, asset criticality, network, and business context.

3.3 Network Detection and Response

NDR analyses network metadata, protocol behaviour, encrypted traffic characteristics, and sometimes payloads. It is valuable for discovering unmanaged assets, lateral movement, command-and-control patterns, and unusual data transfers. NDR cannot reliably attribute all activity to a process or user, particularly when traffic is encrypted, proxied, or generated by shared infrastructure.

3.4 SIEM

A Security Information and Event Management platform aggregates, searches, correlates, retains, and presents security data. Its analytical value depends more on data quality and use-case design than on product branding. SIEM functions commonly include parsing, field extraction, correlation, case management, dashboards, alert routing, and compliance reporting.

Correlation rules should express an investigative proposition rather than merely join unrelated events. For example, a sequence consisting of impossible-travel authentication, multifactor authentication failure, creation of an access token, and access to a sensitive repository has greater significance than any event alone. Correlation windows must reflect realistic attack timing and account for delayed ingestion.

3.5 UEBA

User and Entity Behaviour Analytics builds profiles for users, devices, service accounts, and other entities. Features may include login times, source locations, destination systems, administrative actions, data volume, and peer-group comparisons. UEBA is particularly useful when no known malicious indicator exists.

A behavioural deviation is not proof of compromise. A travelling administrator, a scheduled backup, or a new business project may explain a large change. UEBA should produce interpretable evidence and allow analysts to inspect the features contributing to a score. Opaque scores without context encourage automation bias and are difficult to govern.

4. Baselines, Rules, and Analytical Reasoning

A baseline describes expected activity over a defined period and under defined conditions. A single baseline for an entire organisation is usually inadequate. Useful baselines are segmented by asset role, user population, location, application, season, and time of day.

For a measured variable x, the arithmetic mean over n observations is:

x̄ = (1/n) Σxᵢ

The sample standard deviation is:

s = √[Σ(xᵢ − x̄)²/(n − 1)]

Here, xᵢ is an observation, x̄ is the sample mean, and s estimates variation in the population from which the sample was drawn. These statistics assume that the observations are reasonably comparable and that extreme values do not dominate interpretation. Network data are often skewed, seasonal, and autocorrelated; therefore, median, percentile, exponentially weighted, or robust methods may be preferable.

A simple threshold such as “alert when traffic exceeds x̄ + 3s” is not a universal law. It is a heuristic whose usefulness depends on distribution, sampling interval, baseline stability, and operational consequences. It can miss low-and-slow activity and generate false positives during legitimate peaks.

Detection rules should combine several dimensions where possible:

• Who: account, role, service identity, or certificate.
• What: process, command, protocol, resource, or action.
• Where: source, destination, segment, cloud region, or application.
• When: sequence, duration, frequency, and time of day.
• Context: asset value, vulnerability, threat intelligence, and approved change.
• Outcome: success, failure, privilege change, data access, or persistence.

A good detection is specific enough to support action, broad enough to capture meaningful variants, and documented sufficiently for another analyst to understand its rationale.

Worked example: evaluating alert quality

Suppose a team reviews 1,000 alerts. Investigation confirms that 120 represent genuine security incidents, while 880 are benign or irrelevant. The precision of the alert stream is the proportion of alerts that are true positives:

Precision = true positives / all positive alerts = 120 / 1,000 = 0.12, or 12%.

This means 88% of analyst-reviewed alerts did not represent confirmed incidents. Precision alone is insufficient: a system that produces very few alerts may have high precision while missing most attacks. If a test set contains 200 known relevant attack instances and the system detects 120, its recall is 120/200 = 60%. These measures depend on reliable labelling and a defined evaluation population; unknown or undiscovered incidents make recall difficult to establish in production.

5. Threat Intelligence and MITRE ATT&CK

Threat intelligence provides information about adversaries, campaigns, infrastructure, malware, vulnerabilities, and behaviours. It is most useful when connected to a decision. Strategic intelligence supports risk and investment decisions; operational intelligence informs campaign-level planning; tactical intelligence supports detection and blocking; technical indicators include domains, hashes, addresses, and artefacts.

Indicators have limited lifetime and context. A malicious IP address may be reassigned, a hash may change, and a domain may be shared through hosting infrastructure. Intelligence should therefore be evaluated for source reliability, confidence, age, relevance, and corroboration. Blindly importing feeds can increase noise and consume storage without improving detection.

MITRE ATT&CK is a knowledge base describing adversary tactics, techniques, and procedures across environments such as enterprise, cloud, and mobile. Tactics represent goals, including credential access, discovery, persistence, lateral movement, and exfiltration. Techniques describe ways of achieving those goals. ATT&CK is not a compliance checklist and does not prove that an organisation is secure. It is useful for vocabulary, threat-informed detection design, adversary emulation, coverage analysis, and communication between defenders.

A coverage map should identify, for each relevant technique, the data source, detection logic, confidence, response procedure, and known blind spots. “Mapped to ATT&CK” is not equivalent to “detected effectively.” Coverage must be validated through testing, such as controlled attack simulation, purple-team exercises, or replay of representative telemetry.

6. Dashboards and Actionable Metrics

Dashboards should support decisions rather than display attractive but irrelevant counts. An executive dashboard may show material incidents, risk trends, response performance, critical asset exposure, and control health. An operational dashboard may show alert queues, sensor availability, ingestion delay, detection failures, and cases approaching service-level targets. An analyst dashboard should enable pivoting from an alert to raw events, related entities, timelines, and response actions.

Important metrics include:

• Mean time to detect (MTTD): average time from a defined start event to detection. The start point must be specified, because compromise time is often unknown.
• Mean time to respond (MTTR): average time from detection or triage to a defined response milestone. “Response” must be operationally defined.
• Precision: confirmed true positives divided by all alerts reviewed.
• Recall: detected relevant instances divided by all relevant instances in a defined evaluation set.
• Alert volume per analyst: useful for workload planning, but dangerous as a performance target by itself.
• Ingestion coverage: proportion of in-scope assets or services producing expected telemetry.
• Detection coverage: proportion of prioritised threat behaviours with tested detection and response capability.
• Data freshness: delay between event occurrence and analyst availability.

Metrics can be gamed. Reducing alert volume by disabling weak detections may improve workload statistics while reducing security. Similarly, rapid closure can conceal poor investigation. Metrics should be interpreted as a balanced set, accompanied by definitions, confidence limits where appropriate, and qualitative review of significant cases.

7. Applied Case: Illustrative Ransomware Detection Scenario

Background

The following is a fictional illustrative case. Meridian Components operates manufacturing sites, a corporate identity service, cloud email, and an enterprise resource planning system. It has deployed a SIEM, EDR on corporate endpoints, and flow monitoring at site gateways. Its initial detection programme focused heavily on malware signatures and perimeter firewall blocks.

Problem

One morning, several engineering workstations become unavailable. The organisation discovers that shared files have been encrypted. The SIEM contains many alerts, but analysts cannot quickly determine the initial access path or the scope of lateral movement. Some site logs are delayed by several hours, and service accounts are not clearly distinguished from human accounts.

Analysis

Investigation correlates the following evidence:

1. A user authenticated to cloud email from an unusual location and then received a message containing a compressed attachment.

2. EDR recorded a document application spawning a scripting interpreter, followed by a new scheduled task.

3. The endpoint made outbound connections to a newly registered domain.

4. The same user account authenticated to a file server and then to several engineering workstations.

5. A service account, which normally accessed only a database, authenticated interactively to a workstation.

6. Flow records showed a rapid increase in east-west SMB traffic before encryption activity began.

No single event proves ransomware. Together, the sequence supports a hypothesis involving phishing, script execution, persistence, credential misuse, lateral movement, and impact. ATT&CK mappings help organise the behaviour, but analysts must validate each event and exclude approved administrative activity.

Approach and solution

The response team disables affected accounts, isolates selected endpoints through EDR, blocks the confirmed malicious infrastructure, and preserves forensic evidence. It protects recovery systems from the compromised identity domain and verifies backup integrity before restoration.

After containment, detection engineers create and test several use cases: unusual scripting spawned by office applications; creation of scheduled tasks by non-administrative users; interactive use of service accounts; rapid SMB fan-out; and a sequence combining suspicious email, endpoint execution, and lateral authentication. Rules include asset and identity exceptions that are reviewed rather than permanently embedded. The team also improves clock synchronisation, requires service-account restrictions, and routes cloud identity logs into the SIEM.

Outcome

The organisation restores critical services from verified backups. A retrospective test finds that the original signature-only programme would have detected the payload only after execution, whereas the revised behavioural detections identify earlier stages. Analysts also discover that a site sensor had been silently dropping records; sensor-health monitoring is added as a control.

Learning points

The case demonstrates the value of sequence-based correlation, identity context, endpoint and network complementarity, protected telemetry, and tested response actions. It also illustrates that ATT&CK mapping, threat intelligence, and machine-generated scores are aids to reasoning—not substitutes for evidence, investigation, and accountable decisions.

8. Challenges, Governance, and Ethical Considerations

Monitoring can intrude on privacy, particularly when it captures employee communications, browsing behaviour, location, or content. Organisations should establish a legitimate purpose, proportionality, transparency, retention limits, access controls, and review procedures. Legal obligations vary by jurisdiction and may include data protection, employment, sectoral, breach-notification, and electronic communications requirements.

Security teams should separate security-relevant telemetry from unnecessary personal content, restrict investigative access, log analyst actions, and apply role-based permissions. Cross-border cloud storage requires particular attention to transfer rules and contractual obligations. Evidence retention should reflect investigative and legal requirements without retaining data indefinitely.

Automation creates further governance issues. Automated isolation or account suspension can prevent harm but can also disrupt safety-critical or business-critical operations. High-impact actions should have clear authorization, rollback capability, exception handling, and human oversight. Machine-learning systems may reproduce historical bias, misclassify unusual behaviour by minority user groups, or become unreliable after organisational change. Models require validation, drift monitoring, explainability appropriate to the decision, and a route for appeal or correction.

9. Contemporary Developments and Best Practices

Encrypted traffic reduces payload visibility, increasing reliance on endpoint telemetry, DNS, certificate information, flow characteristics, and identity events. Extended Detection and Response platforms increasingly combine endpoint, identity, email, cloud, and network signals, but integration does not eliminate the need for sound data governance.

Security data platforms and cloud-native SIEM services offer elastic storage and analytics, yet cost can grow with event volume. Sampling, tiered retention, selective parsing, and prioritised collection should be based on risk and investigative value. Open schemas and interoperable formats reduce dependence on a single vendor and support portability.

Generative AI can assist with query construction, alert summarisation, enrichment, and investigation timelines. It can also hallucinate explanations, omit crucial evidence, expose sensitive data, or encourage analysts to accept unsupported conclusions. AI output should be treated as an untrusted draft, linked to source events, tested against known cases, and subject to human review.

Best practices include:

1. Begin with assets, threats, business impact, and investigation questions rather than products.

2. Establish authoritative identity, asset, time, and data-classification standards.

3. Prioritise high-value telemetry and monitor collection health.

4. Write detections as documented hypotheses with owners, tests, exceptions, and response actions.

5. Use layered evidence: endpoint, network, identity, cloud, application, and intelligence sources.

6. Measure precision, recall where feasible, timeliness, coverage, data quality, and analyst workload together.

7. Validate detections through purple-team exercises, simulations, and post-incident review.

8. Protect monitoring systems and evidence against tampering.

9. Apply privacy-by-design, least privilege, retention controls, and transparent governance.

10. Retire detections that no longer support decisions, while preserving rationale and lessons learned.

Chapter Summary

Security monitoring transforms operational activity into evidence for detection, investigation, and response. Logs provide semantic detail, flow records provide communication summaries, packet data supports protocol and forensic analysis, and endpoint, identity, cloud, and application telemetry reveal activity that network-only approaches may miss. A reliable architecture requires normalisation, synchronised time, secure transport, resilient collection, protected storage, and continuous sensor-health monitoring.

IDS/IPS, EDR, NDR, SIEM, and UEBA provide complementary capabilities with different strengths and limitations. Detection engineering should begin with explicit threat hypotheses, identify data requirements, combine behavioural and contextual evidence, test false positives and missed detections, and document response guidance. Baselines and statistical measures can assist analysis, but their assumptions must be understood because security data are often seasonal, skewed, and dependent.

Threat intelligence is valuable when it informs a decision, and MITRE ATT&CK provides a common language for threat-informed detection and coverage analysis; neither guarantees effective protection. Dashboards should support decisions, while metrics such as precision, recall, detection and response time, coverage, and data freshness must be interpreted together. Finally, monitoring must respect privacy, legal obligations, proportionality, human oversight, and the risks of automated or AI-assisted decisions.

Key Terms

Telemetry: Recorded evidence about activity in systems, networks, applications, or identities.

Log: A record generated by a system or application describing an event.

Flow record: A summary of network communication between endpoints.

Packet capture: Recorded network packets used for analysis or investigation.

Alert: An interpretation indicating activity that may require attention.

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

IDS: Intrusion Detection System that identifies suspicious activity.

IPS: Intrusion Prevention System capable of blocking or disrupting activity.

EDR: Endpoint Detection and Response technology for endpoint visibility and action.

NDR: Network Detection and Response technology for network-based behavioural analysis.

SIEM: Security Information and Event Management platform for aggregation, correlation, search, and alerting.

UEBA: User and Entity Behaviour Analytics for detecting unusual behaviour.

Baseline: A representation of expected activity under defined conditions.

Detection engineering: The disciplined design, testing, deployment, and maintenance of detections.

Threat intelligence: Analysed information about threats, adversaries, infrastructure, or behaviours.

MITRE ATT&CK: A knowledge base of adversary tactics and techniques.

Precision: The proportion of reviewed positive alerts that are confirmed true positives.

Recall: The proportion of relevant instances in a defined evaluation set that are detected.

Mean time to detect: Average time from a defined event start to detection.

Data freshness: The delay between event occurrence and availability for analysis.

Review Questions

Short Answer Questions

1. Distinguish an event, an alert, and an incident.

2. State two strengths and two limitations of flow records.

3. Why is time synchronisation important in security monitoring?

4. What is the purpose of mapping detections to MITRE ATT&CK?

5. Define precision and explain why it matters to a security operations team.

Long Answer Questions

1. Explain how logs, endpoint telemetry, flow records, packet captures, identity events, and cloud audit records complement one another.

2. Describe the lifecycle of detection engineering from threat hypothesis to post-deployment improvement.

3. Compare IDS/IPS, EDR, NDR, SIEM, and UEBA in terms of visibility, action, and limitations.

4. Discuss how dashboards and metrics can support management decisions without encouraging counterproductive behaviour.

5. Analyse the privacy, governance, and human-oversight requirements of enterprise security monitoring.

Analytical / Application Questions

1. An organisation has high alert volume but few confirmed incidents. Design a plan to improve precision without reducing recall unnecessarily. Specify data, testing, and governance steps.

2. Design a monitoring and detection strategy for a cloud-hosted application using identity, API, endpoint, network, and threat-intelligence data. Map at least three use cases to relevant ATT&CK behaviours.

3. Using the illustrative ransomware case, identify the earliest potentially actionable detection, explain why it might generate false positives, and propose a layered rule sequence that improves confidence.

Multiple Choice Questions with Answers

Question 1

Which telemetry type primarily summarises network conversations without recording complete packet payloads?

A. Flow records

B. Full packet capture

C. Process creation logs

D. Application source code

Correct Answer: A. Flow records

Question 2

What is the main purpose of normalising security data?

A. To delete all low-severity events

B. To make records comparable using consistent fields and representations

C. To encrypt every packet payload

D. To replace incident response personnel

Correct Answer: B. To make records comparable using consistent fields and representations

Question 3

Which technology is most directly focused on process execution and endpoint response actions?

A. NDR

B. EDR

C. DNS

D. IPFIX

Correct Answer: B. EDR

Question 4

An alert stream contains 120 confirmed true positives out of 1,000 reviewed alerts. What is its precision?

A. 12%

B. 20%

C. 60%

D. 88%

Correct Answer: A. 12%

Question 5

Which statement best describes MITRE ATT&CK?

A. A mandatory firewall configuration standard

B. A database of adversary tactics and techniques

C. A packet-encryption protocol

D. A replacement for security logs

Correct Answer: B. A database of adversary tactics and techniques

Question 6

Why can a simple threshold based on the mean plus three standard deviations be unreliable for network security data?

A. Security data are always normally distributed

B. Network activity may be seasonal, skewed, or autocorrelated

C. Standard deviation has no mathematical definition

D. Thresholds cannot be used in any security system

Correct Answer: B. Network activity may be seasonal, skewed, or autocorrelated

Question 7

Which metric measures the proportion of relevant instances detected in a defined evaluation set?

A. Precision

B. Recall

C. Data freshness

D. Mean time to respond

Correct Answer: B. Recall

Question 8

Which is the strongest example of useful detection correlation?

A. Alerting on every successful login independently

B. Joining suspicious scripting, persistence, unusual authentication, and lateral movement in a defined time window

C. Deleting all events after an alert is generated

D. Blocking every newly registered domain automatically

Correct Answer: B. Joining suspicious scripting, persistence, unusual authentication, and lateral movement in a defined time window

Question 9

What is a major limitation of threat-intelligence indicators such as IP addresses and hashes?

A. They never change after publication

B. They may become stale, be shared, or lack sufficient context

C. They cannot be stored in a SIEM

D. They always identify the responsible person

Correct Answer: B. They may become stale, be shared, or lack sufficient context

Question 10

Which practice best supports responsible use of AI-generated security summaries?

A. Accepting summaries without checking source evidence

B. Disabling analyst review for faster closure

C. Treating output as a draft linked to source events and subject to human validation

D. Sending all confidential telemetry to an unapproved public service

Correct Answer: C. Treating output as a draft linked to source events and subject to human validation