Understand Security Operations

Three log lines from a hypothetical night: at 02:14 an account fails to sign in, at 02:15 the same account signs in successfully, and at 02:31 the server it reached sends an unusually large file to an address outside the organization. Each line on its own may be inconclusive. Together they may describe a stolen password being used to carry data out of the organization (exfiltration). Security operations is the work of recording events like these, noticing when they belong together, and deciding what to do about them.

This page follows objective 5.2 of the Certified in Cybersecurity (CC) exam outline^[1] through its five parts: logging and monitoring security events, security event triage, threat actors, cyber threat intelligence and threat frameworks. Objective 5.1 of the outline, data security, lists data handling (for example classification, labeling, masking and sanitization) and encryption (CC exam outline^[1]). Objective 5.3, incident response, lists the data handling policy implementing an Incident Response Plan (IRP) and incident response exercises (for example testing and tabletop) (CC exam outline^[1]).

One path from event to decision

NIST Special Publication 800-61 Revision 3 (SP 800-61r3) defines an event as "any observable occurrence that involves computing assets", such as a user login attempt, the installation of a software update or an application responding to a request (SP 800-61r3, section 1^[2]). An event is not necessarily harmful.

1. Logging: systems write a record, called a log entry, for selected events.
2. Monitoring and correlation: tools and people examine the records, link related ones and raise an alert when something needs attention.
3. Triage: an analyst decides whether the alert describes a real incident and, if it does, how urgently it needs a response.

Three kinds of knowledge supply context to stages 2 and 3: who attacks and why (threat actors), what is currently known about attacks (cyber threat intelligence) and a shared vocabulary for describing attacker behavior (threat frameworks). NIST recommends integrating cyber threat intelligence and other context, such as asset inventories, into the analysis of events (SP 800-61r3, DE.AE-07^[2]).

The takeaway: logging, monitoring and correlation, and triage turn events into evidence and a decision, and threat actors, cyber threat intelligence and threat frameworks help interpret that evidence.

This section separates the first two stages of the path, because treating them as one job is a mistake.

Logging creates records; monitoring examines them. NIST defines a log as "a record of the events occurring within an organization's systems and networks", made up of log entries that each describe one event (NIST SP 800-92, section 2.1^[3]). Security-relevant logs come from many sources, including security software such as antivirus software, firewalls and intrusion detection systems, the operating systems of servers, workstations and network equipment, and applications (NIST SP 800-92, section 2.1^[3]).

Monitoring is the review that turns those records into findings. The OWASP logging guidance says logged event data must be available for review, with processes in place for monitoring, alerting and reporting, and that the responsible teams should be alerted immediately about more serious events (OWASP Logging Cheat Sheet^[4]). NIST recommends tools that continuously monitor log events for known malicious and suspicious activity, plus regular manual review for technologies that automation cannot monitor well (SP 800-61r3, DE.AE-02^[2]).

Why an archive alone is not detection

A logging service that only stores events can answer questions after the fact, but it raises no alert while an attack is under way, because nothing evaluates the events as they arrive. Monitoring also covers the logging system itself: OWASP advises processes that detect whether logging has stopped (OWASP Logging Cheat Sheet^[4]), since an attacker who switches logging off leaves no new records to find.

The takeaway: a detection capability needs both halves, records that exist and a process that examines them in time to act.

This section covers what a single log entry should contain, because an analyst can only interpret what the record actually says.

The OWASP logging guidance puts the rule in four words: application logs must record "when, where, who and what" for each event (OWASP Logging Cheat Sheet^[4]). Typical fields for each question include:

Question	Example fields
When	Date and time of the event, in an international format
Where	Application name and version, host name or address, service
Who	Source address, user identity if known
What	Type of event, severity, description

OWASP also suggests recording the result status, such as success or failure, and the result matters as much as the action. A failed login and a successful login to the same account mean very different things: a run of failures may be someone guessing passwords, while a success after those failures may mean the guess worked.

Example: one login event recorded with its context (illustrative layout, not a standard format)

when=2026-03-02T02:15:07Z  where=hr-app on hr-web-01
who=j.smith from 203.0.113.25  what=login  result=success

Each field in this listing answers one of the four questions above: when carries the time, where the application and host, who the account and the address it came from, and what plus result the action and its outcome. The submitted password does not appear anywhere in it, for the reason explained next.

What stays out of the log

Some values should usually not be written to logs directly, but removed, masked, hashed or encrypted instead. OWASP's list includes authentication passwords, session identifiers, access tokens, database connection strings, encryption keys, payment card data and sensitive personal data, among others (OWASP Logging Cheat Sheet^[4]). Recording submitted passwords to make failed logins easier to investigate turns the logging system into a store of secrets: anyone who can read the logs could reuse them.

A count is not an individual event record

Systems can consolidate many similar entries into one entry that holds a count, a technique NIST calls event aggregation (NIST SP 800-92, section 3.2^[3]). A count shows volume, but if individual activity must later be investigated, a record that holds only a total has already discarded the actors, targets and outcomes needed to reconstruct what happened.

The takeaway: record when, where, who and what with the result, and keep secrets from being written to the log directly.

This section covers why logs need protection of their own and what that protection includes.

Logs are attractive to attackers in two ways. They can reveal information: personal data about users, details of systems and, if logging was careless, secrets (OWASP Logging Cheat Sheet^[4]). And they hold the evidence of an attack, so an intruder has every reason to change or delete them; NIST notes that many rootkits, malicious tools that hide an attacker's presence, are designed to alter logs to remove evidence of their installation or execution (NIST SP 800-92, section 2.3.2^[3]).

Protection therefore covers confidentiality, integrity and availability of the log data. Measures from the OWASP guidance include (OWASP Logging Cheat Sheet^[4]):

• Restrict who may read logs, review those privileges periodically, and record and monitor all access to the logs.
• Build in tamper detection so that modification or deletion of a record is noticed, and copy log data to read-only media as soon as possible.
• Use a secure transmission protocol when log data crosses untrusted networks.

NIST describes one integrity technique: calculating a message digest (a hash) of each log file and storing it securely, so that any later change to the file produces a mismatch (NIST SP 800-92, section 3.2^[3]).

The takeaway: logs are both sensitive data and evidence, so restrict who can read them and make changes to them detectable.

This section covers how long logs survive, because evidence that has been overwritten cannot be investigated.

Many logs have a maximum size, such as the 10,000 most recent events or 100 megabytes of data; when the limit is reached, the log might overwrite old data with new data or stop logging altogether (NIST SP 800-92, section 2.3.2^[3]). Log rotation closes a log file and opens a new one, on a schedule or when the file reaches a certain size, which keeps files manageable (NIST SP 800-92, section 3.2^[3]).

A rolling local log is not a retention period

How far back a device's local log reaches depends on how many events it records and how much storage it has, so a busy week can push important entries out within hours. Retention requirements often come from legal or regulatory obligations (NIST SP 800-92, section 3.2^[3]), and they are met by archiving logs elsewhere, typically on a central log server or dedicated archive. NIST distinguishes log retention (archiving logs regularly as part of normal operations) from log preservation (keeping logs that would normally be discarded because they record activity of particular interest, often for an investigation).

When a log source fills up, NIST lists the usual choices: stopping logging is generally unacceptable because operations continue without monitoring; overwriting the oldest entries is often acceptable for lower-priority sources whose significant entries have already been sent to a log server; and for critical logging a system can be configured to shut down rather than run unlogged (NIST SP 800-92, section 5.1.2^[3]). Retention cuts both ways: OWASP notes that log data must not be destroyed before the required retention period ends and must not be kept beyond it (OWASP Logging Cheat Sheet^[4]).

The takeaway: forward logs to protected storage and watch capacity, so that a log that fills and overwrites old entries never silently shortens the period the organization is required to keep.

This section covers the tool that brings logs from many systems together so they can be analyzed in one place.

A security information and event management (SIEM) product collects log data from many sources, stores it, and analyzes it centrally. NIST describes SIEM software as having one or more log servers that perform analysis and one or more database servers that store the logs (NIST SP 800-92, section 3.4^[3]). It can collect in two ways:

• Agentless: the SIEM server pulls logs from each host, or each host pushes its logs to the server, with no special software installed on the host.
• Agent-based: a small program (an agent) installed on the host filters, aggregates and normalizes its logs, then sends them to the SIEM server, usually in real time or near real time.

Log normalization converts each log data field to a particular data representation (NIST SP 800-92, section 3.2^[3]).

Whichever way the data arrives, the SIEM server "analyzes the data from all the different log sources, correlates events among the log entries, identifies and prioritizes significant events, and initiates responses to events if desired" (NIST SP 800-92, section 3.4^[3]). SIEM products typically support several dozen kinds of log source, such as operating systems, security software, application servers and even physical security devices like badge readers. NIST's detection guidance likewise recommends sending log data from its many sources to a relatively small number of log servers (SP 800-61r3, DE.AE-03^[2]).

Limits of central analysis

A SIEM can only analyze the events it receives. A system that does not send its logs is a blind spot for the SIEM, and badly formatted or incomplete records can weaken analysis of the affected events. Centralization also does not make a traffic-control device into a SIEM: a packet-filtering firewall decides which traffic may pass and is one of the log sources a SIEM collects from, not the tool that collects and centrally analyzes application and host events across the organization.

The takeaway: a SIEM centralizes collection and analysis, and its findings are only as complete as the sources feeding it.

This section covers two separate problems that appear as soon as records from different systems are compared, and the separate fix for each.

Clocks: putting events in their true order

A log-generating host typically stamps its log entries using its own internal clock. If that clock is wrong, so are its timestamps, and NIST gives an example of the result: timestamps might show event A happening 45 seconds before event B when A actually happened two minutes after B (NIST SP 800-92, section 2.3.1^[3]). NIST recommends time synchronization technologies such as Network Time Protocol (NTP) servers to keep log sources' clocks consistent, and notes that organizations spanning several time zones often convert all logged times to a single time zone (NIST SP 800-92, section 3.2^[3]).

The order in which records reach the SIEM server is not a reliable timeline either. The OWASP guidance points out that the time an event happened can differ from the time it was logged, for example when a device is only online now and then (OWASP Logging Cheat Sheet^[4]). Transmission and collection delays can therefore reorder records in transit; investigators order events by synchronized event timestamps, not by arrival.

Normalization: one representation for the same information

Log normalization converts each log data field "to a particular data representation" and categorizes it consistently (NIST SP 800-92, section 3.2^[3]). NIST's example: one product stores the event time in twelve-hour format (2:34:56 P.M. EDT) in a field called Timestamp, while another stores it in twenty-four-hour format (14:34) in a field called Event Time, with the time zone (-0400) in a separate field. Normalizing both into one representation lets analysis tools compare them without requiring every product to produce identical native logs.

Two problems, two fixes

Clock synchronization makes the times correct at the source; it does nothing about differing field names and formats. Normalization makes formats consistent; it does not repair a clock that recorded the wrong time, although a known offset from an out-of-sync source can be corrected afterwards by adding or subtracting time (NIST SP 800-92, section 3.2^[3]). Synchronizing clocks at the source remains the recommended fix for time.

The takeaway: synchronize clocks so events can be ordered, and normalize formats so records can be compared.

This section covers correlation, the step that turns separate records into one picture of an activity.

NIST defines event correlation as "finding relationships between two or more log entries" (NIST SP 800-92, section 3.2^[3]). The most common form is rule-based correlation, which matches entries from one or more sources on logged values such as timestamps, IP addresses and event types; statistical methods and visualization tools can also be used. When automated correlation succeeds, the usual result is a new entry that brings the pieces together, and the system may raise an alert that the combined event needs investigation.

Correlation provides context for log entries so they can be validated: in NIST's example, host-based intrusion detection software records an apparent file modification attack, the host's operating system log has an entry showing the file was modified successfully, and correlating the two entries gives stronger assurance of a successful attack than either log source alone (NIST SP 800-92, section 5.2.2^[3]). NIST's detection guidance recommends correlation technology such as a SIEM, or a security orchestration, automation and response (SOAR) platform, to gather related data captured by multiple sources, and using cyber threat intelligence to help correlate events among log sources (SP 800-61r3, DE.AE-03^[2]).

Collecting is not correlating

Storing every record in one repository makes correlation possible, but it does not perform it. Until something establishes that the records describe the same activity, a central store is a pile of unrelated entries.

The takeaway: correlation links records by shared context such as account, host and time; centralized storage only puts them in the same place.

This section covers how artificial intelligence (AI) features in a SIEM help with the volume of alerts, and where human judgment still applies.

The volume of potentially harmful events is generally high, so NIST recommends technical solutions that filter large event sets down to a subset suitable for human review (SP 800-61r3, DE.AE^[2]). When too many alerts reach analysts, real problems are easier to miss; OWASP warns that a blind checklist approach to logging can produce an "alarm fog" in which real problems go undetected (OWASP Logging Cheat Sheet^[4]). The usual name for its effect on people is alert fatigue: analysts facing a constant stream of alerts start to overlook or dismiss them. The CC exam outline includes a foundational understanding of how SIEM tools use AI for logging and monitoring, correlating data to reduce alert fatigue (CC exam outline^[1]).

AI-assisted analysis can find relationships across event sets and group related alerts, so an analyst may review a combined finding rather than separate alerts. The finding still has to be interpreted in the organization's context. A false positive is benign activity identified as malicious (NIST SP 800-94, section 2.2^[5]). NIST's step for declaring an incident is to apply the organization's defined incident criteria to the analyzed activity and consider known false positives (SP 800-61r3, DE.AE-08^[2]). An automated score does not perform that step on its own. Automatically closing every alert that an AI ranked low hands the incident decision to the score without anyone checking the evidence behind it.

The takeaway: AI-assisted correlation reduces repetitive work and alert fatigue, while the decision on each alert stays with the triage process.

This section covers the first triage decision, whether an alert describes a real incident, which starts the third stage of the path.

NIST separates three ideas (SP 800-61r3, section 1^[2]):

• An event is any observable occurrence, such as a login attempt.
• An adverse event is one associated with a negative consequence, whatever the cause.
• A cybersecurity incident is "an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."

NIST adds that additional analysis is often needed to decide whether adverse events indicate that an incident has occurred.

Triage starts with a preliminary review to verify that an incident has actually occurred, then estimates its severity and the urgency of the response (SP 800-61r3, RS.MA-02^[2]). Incidents are declared when adverse events meet the organization's defined incident criteria (SP 800-61r3, DE.AE-08^[2]).

An anomaly is not yet an incident

An anomaly is activity that departs from what is expected. NIST notes that anomalies "may have benign or malicious foundations" (SP 800-61r3, DE.AE^[2]). For example, detection tools that learn normal behavior can flag legitimate maintenance work as a significant deviation (NIST SP 800-94, section 2.3^[5]). An alert, including a high anomaly score, says that something deserves a look; it does not establish what caused the activity. Declaring a breach from an anomaly score alone skips both the cause and the criteria.

The takeaway: an alert raises a question, and triage answers it against the organization's incident criteria before anyone declares an incident.

This section covers the two ways detection can be wrong, which every triage decision has to allow for.

NIST defines both errors for intrusion detection, and the definitions apply to any detection rule (NIST SP 800-94, section 2.2^[5]):

	Activity is malicious	Activity is benign
Alert raised	Correct alert	False positive: benign activity identified as malicious
No alert	False negative: malicious activity not identified	Correctly no alert

No detection technology is completely accurate, and NIST notes that reducing one kind of error usually increases the other. Many organizations accept more false positives in exchange for fewer false negatives, which means more analyst time spent separating false alarms from real ones. Adjusting a detection configuration to improve its accuracy is called tuning (NIST SP 800-94, section 2.2^[5]).

Silencing a noisy rule

In some intrusion detection products, turning off an alert also disables related detection capabilities; in others, detection processing is still done but no alert message is generated (NIST SP 800-94, section 3.2.3^[5]). In products of the first kind, turning off a noisy rule's alert also disables the related detection capabilities, so the product then fails to identify the malicious activity the rule detects, which is a false negative (NIST SP 800-94, sections 2.2 and 3.2.3^[5]). Tuning aims to improve detection accuracy by balancing false positives and false negatives, rather than to eliminate alerts.

The takeaway: a false positive wastes attention, a false negative misses an attack, and tuning balances the two instead of silencing either.

This section covers what happens once an incident is declared: deciding what kind of incident it is and how urgently it needs attention.

NIST calls evaluating the overall risk from an incident and applying the appropriate prioritization "perhaps the most critical decision points in the incident response process", and states the rule plainly: "incidents should not be handled on a first-come, first-served basis" (SP 800-61r3, RS.MA^[2]). Triage, prioritization and escalation decisions should rest on a set of risk evaluation factors. NIST's examples include (SP 800-61r3, RS.MA^[2]):

• the criticality of the affected assets;
• the functional impact (what the incident stops the organization from doing);
• the data impact (what information is exposed, changed or lost);
• the stage of the observed activity;
• what is known about the threat actor;
• recoverability (how readily normal operation can be restored).

Elsewhere NIST frames priority around an incident's scope, likely impact, time-critical nature and the resources available (SP 800-61r3, RS.MA-03^[2]). An active compromise of a critical service can therefore justify attention before an older, low-impact report.

Category and priority are separate decisions

Categorizing an incident means identifying its type, with NIST's examples being data breach, ransomware, account takeover and denial of service (SP 800-61r3, RS.MA-03^[2]). The category can help responders select a procedure for that incident type. It does not set the priority: two ransomware incidents, one on a test laptop and one on a payment system, share a category but differ greatly in impact.

Revising the assessment

Early estimates of scope and impact are often incomplete, and NIST recommends reviewing and refining them (SP 800-61r3, DE.AE-04^[2]). When new evidence reveals more affected systems, sensitive data or continuing activity, the incident is re-prioritized and, where needed, escalated (given more resources or time) or elevated (brought to a higher level of management) (SP 800-61r3, RS.MA-04^[2]). A ticket that has already been assigned a low priority is an administrative record, not evidence, and does not outweigh newly discovered impact.

The figure below traces triage from the alert through the declaration decision to categorizing, prioritizing and reassessing.

The takeaway: rank incidents by risk, keep category and priority apart, and re-rank whenever the evidence changes.

A ransomware gang, a foreign intelligence service and a protest group could all knock the same website offline. What separates them is why they did it, and that motive shapes what they are likely to do next. This section covers the main types of threat actor, the people or groups behind cyber threat activity, and the motivation usually associated with each.

The Canadian Centre for Cyber Security groups threat actors by motivation and notes that each category has a primary motivation (Cyber Centre, An introduction to the cyber threat environment^[6]). Its model has six types:

Threat actor type	Usual motivation	What else to know
Nation-state (state-sponsored)	Geopolitical	Frequently the most sophisticated, with dedicated resources; activity includes espionage, disruption and influence operations
Cybercriminal	Financial	Sophistication varies widely; organized crime groups add planning and support functions
Hacktivist	Ideological	Generally lower sophistication; often relies on widely available tools
Terrorist group	Ideological violence	Often relies on widely available tools that need little skill
Thrill-seeker	Satisfaction	Often relies on widely available tools
Insider threat	Discontent	Has access from inside the organization; the next section widens this definition

Motive is typical, not exclusive

These motivations describe what is usual, not what is guaranteed. The Cyber Centre notes that state-sponsored actors may also pursue financially motivated activity (Cyber Centre^[6]), so an operation that raises money does not rule out state sponsorship. In the other direction, the technique used does not reveal the motive. A denial-of-service attack can be the work of a hacktivist, a criminal demanding payment, or a thrill-seeker; an extortion campaign demanding money that attracts wide publicity is still financially motivated; and an intruder who reaches valuable systems may have done it for the challenge. Classify an actor from evidence of their goals, such as a ransom demand or a published political statement, rather than from the technique, the publicity or the value of what was reached.

The takeaway: motives help characterize actor types, and a technique alone does not prove which motive is at work.

This section covers insider threats, defined by access to or knowledge of an organization’s resources rather than by motive alone.

The Cybersecurity and Infrastructure Security Agency (CISA) defines an insider as "any person who has or had authorized access to or knowledge of an organization's resources", and insider threat as the threat that an insider will use that access, "intentionally or unintentionally", to do harm (CISA, Defining Insider Threats^[7]). Its examples of insiders go well beyond employees: contractors, vendors, custodians and repair people with regular access, people given a computer or network access, and people who know the organization's products or strategy, among others.

CISA separates insider threats by intent (CISA^[7]):

• Unintentional threats come from negligence, such as ignoring security policies or letting someone follow through a secure door, or from accidents, such as emailing a sensitive document to the wrong address or clicking a phishing link.
• Intentional threats, often called malicious insiders, act to harm the organization for personal benefit or over a grievance.
• Collusive threats, a subset of malicious insiders, work with an external threat actor, for example when criminals recruit an insider to enable fraud.

The previous section's table lists discontent as the usual insider motivation. That describes malicious insiders, who are often disgruntled employees (Cyber Centre^[6]); CISA's definition also covers people with no hostility at all. An insider-risk review that looks only at unhappy employees misses accidental harm and every trusted person who is not an employee.

The takeaway: insider threat is the potential for someone with current or past authorized access or knowledge to harm the organization, on purpose or by accident.

This section covers how capable threat actors are and why naming the actor behind an attack is hard.

Threat actors differ widely in resources, training and support, and may act alone or as part of a larger organization such as a state intelligence program or an organized crime group (Cyber Centre^[6]). At the top of that range sits the advanced persistent threat (APT): threat actors "in the top tier of sophistication and skill" who are "capable of using advanced techniques to conduct complex and protracted campaigns in the pursuit of their goals". The Cyber Centre notes that the label is usually reserved for nation-states or very proficient organized crime groups (Cyber Centre^[6]).

Persistence here means pursuing an objective over a long period with deliberate effort. An automated scan that repeats every few minutes is repetitive, but repetition alone does not make it a sophisticated, sustained campaign.

Why one tool does not identify the attacker

Attribution is the act of accurately determining the threat actor responsible for a set of activities, and it is difficult because many actors deliberately hide who they are (Cyber Centre^[6]). Several facts work against attributing an attack from the tool it used:

• Different actors use the same public, commercial or stolen tools, and sophisticated actors sometimes choose readily available tools precisely because they work and make attribution harder.
• Some actors run false flag operations, imitating another actor's known activity, for example by using a tool associated with a different group, so that defenders blame someone else.

Analysts therefore build attribution from several reliable observations. Tactics, techniques and procedures are an adversary's tactical goals, the ways it achieves those goals and the specific implementations it uses (ATT&CK FAQ^[8]). RFC 9424 describes clustering similar combinations of tactics, techniques and procedures seen across multiple campaigns over time, together with deeper analysis, to infer attribution to a single actor (RFC 9424, section 4.1.7^[9]).

The takeaway: an APT is a highly capable actor on a long campaign, and attribution rests on many observations, never on one recognizable tool.

This section covers cyber threat intelligence, the context that helps analysts judge what an event or alert means.

NIST distinguishes two levels (NIST SP 800-150, Executive Summary and section 2.1^[10]):

• Cyber threat information is "any information that can help an organization identify, assess, monitor, and respond to cyber threats", such as indicators, descriptions of attacker behavior, security alerts (advisories) and threat intelligence reports.
• Threat intelligence is "threat information that has been aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for decision-making processes".

The second definition explains a mistake. A larger feed of raw alerts or indicators is more input, not better intelligence; it becomes intelligence only after someone has established what it means and whether it applies. Cyber threat intelligence (CTI) can then help detect malicious activity earlier, reduce its impact and shorten recovery (SP 800-61r3, DE.AE^[2]).

Current and relevant to local assets

NIST recommends integrating up-to-date CTI and other context, such as asset inventories, into the analysis of events, and rapidly acquiring and analyzing vulnerability disclosures for the organization's own technologies (SP 800-61r3, DE.AE-07^[2]). Two checks follow when a threat report arrives. Is it current? And does it concern technology and behavior that actually exist in this environment? An advisory about a product the organization does not run deserves less attention than one about an internet-facing system it depends on. Treating every new external advisory as equally urgent spends analyst time without establishing local exposure.

The takeaway: intelligence is information that has been analyzed for a decision, and it pays off when it is current and matched to the organization's own assets.

This section covers indicators of compromise, observable artifacts relating to an attacker or their activities that an analyst compares against local logs.

NIST describes indicators as technical artifacts or observables that suggest an attack is imminent or under way, or that a compromise may already have happened. Its examples include the IP address of a suspected command and control server (the system an attacker uses to direct compromised machines), a suspicious domain name, a web address that points to malicious content, the hash (a fixed-length fingerprint) of a malicious file, and the subject line of a malicious email (NIST SP 800-150, section 2.1^[10]). Analysts search their own logs and systems for matches to decide where to investigate.

A match needs context

RFC 9424, an informational RFC on indicators of compromise (IoCs), states that "an IoC without context is not much use for network defence", while context such as the related threat actor, its role in an attack and when it was last seen lets a defender decide whether to simply log it, monitor it or block it (RFC 9424, section 3.2.2^[9]). Context matters because indicators vary in precision. An IP address is less precise when it belongs to a cloud hosting provider and is regularly reassigned, or when the attacker abused a legitimate server that others still use normally; cloud services, proxies, virtual private networks and address translation all put more systems behind any one address (RFC 9424, section 5.2^[9]). A connection to a reported address is a reason to investigate the circumstances of that connection, not proof of compromise.

Indicators also differ in how long they stay useful. RFC 9424 describes a Pyramid of Pain: file hashes are cheap for an attacker to change and so are fragile, while the attacker's tactics, techniques and procedures are far more costly to change and so make longer-lasting detections (RFC 9424, section 3.1^[9]). Indicators that have reached the end of their useful life should be removed from detection to reduce false positives (RFC 9424, section 3.2.7^[9]).

The takeaway: an indicator tells analysts where to look, and its meaning depends on context, precision and age.

This section covers the labels organizations use to say how far shared threat information may travel.

The Traffic Light Protocol (TLP), maintained by FIRST (the Forum of Incident Response and Security Teams), is "a set of four labels used to indicate the sharing boundaries to be applied by the recipients" (FIRST TLP version 2.0^[11]). The source of the information chooses the label; recipients apply it. Version 2.0 has been authoritative since August 2022, and its labels are TLP:RED, TLP:AMBER, TLP:GREEN and TLP:CLEAR, plus the stricter variant TLP:AMBER+STRICT.

The labels depend on three audience terms that FIRST defines:

• Organization: a group sharing a common affiliation by formal membership and bound by common policies.
• Clients: people or entities that receive cybersecurity services from an organization.
• Community: a group sharing common goals, practices and informal trust, which can be as broad as all cybersecurity practitioners in a country, sector or region.

Label	Who may receive the information
TLP:RED	The individual recipients only, with no further disclosure; in a meeting, only those present
TLP:AMBER+STRICT	The recipient's organization only, on a need-to-know basis
TLP:AMBER	The recipient's organization and its clients, on a need-to-know basis
TLP:GREEN	Peers and partner organizations within the community, but not through publicly accessible channels
TLP:CLEAR	Anyone, with no limit on disclosure, subject to standard copyright rules

Rules that apply to every label

The source may add further restrictions, which recipients must follow, and a recipient who needs to share more widely than the label allows must obtain explicit permission from the source (FIRST TLP^[11]). So a TLP:RED report received in a meeting may not be forwarded to colleagues who were absent, even inside the same team; a TLP:AMBER+STRICT report may not go to a client under ordinary TLP:AMBER rules; and a TLP:GREEN advisory may not be posted on a public website, even to reach other security professionals.

A sharing label, not a classification

FIRST states that "TLP is not a formal classification scheme" and was not designed to handle licensing terms or information handling and encryption rules (FIRST TLP^[11]). A TLP color therefore says who may receive the information and nothing about how to encrypt or otherwise handle it; recipients still apply their own security and legal requirements. Older documents may show the earlier version 1.0, which used TLP:WHITE where version 2.0 uses TLP:CLEAR (NIST SP 800-150, section 3.4.2^[10]).

The takeaway: TLP labels set sharing boundaries chosen by the source, and going beyond a label needs the source's permission.

This section covers MITRE ATT&CK and the three levels of description it uses.

MITRE ATT&CK is "a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations" (MITRE ATT&CK^[12]). Publicly available threat intelligence and incident reporting are its main source of data (ATT&CK FAQ^[8]). It is a body of knowledge, not a tool that runs: ATT&CK does not scan systems or discover vulnerabilities. Defenders use it as a common language to describe observed activity and to check which behaviors their detections cover; finding weaknesses is the job of vulnerability scanning.

Three levels: why, how and exactly how

ATT&CK describes behavior at three levels (ATT&CK FAQ^[8]):

• A tactic is the "why": the adversary's tactical goal, the reason for an action. Example: credential access.
• A technique is the "how": the way the adversary achieves that goal. Example: dumping credentials. Sub-techniques describe the same behavior in more specific detail.
• A procedure is the specific implementation an adversary used, as observed in the wild. Example: an adversary using PowerShell, a Windows scripting tool, to read credentials out of the memory of the Windows process that handles sign-ins.

Keeping the levels apart keeps an attacker's objective separate from the observed method; calling a high-level goal such as credential access a "procedure" mixes up the reason for an action with one particular way of carrying it out. The figure below shows the three levels for the credential example.

Tactics are not a required sequence

The Enterprise matrix arranges tactics as columns, including Reconnaissance, Initial Access, Credential Access, Exfiltration and Impact, among others (ATT&CK Enterprise tactics^[13]). The column order is not a set of steps every attacker completes. MITRE states that ATT&CK tactics "are unordered and may not all occur in a single intrusion because adversary tactical goals change throughout an operation" (ATT&CK FAQ^[8]). An observed tactic therefore stays significant even if nothing was detected for the column before it.

The takeaway: ATT&CK is a knowledge base of real adversary behavior, organized as tactics (why), techniques (how) and procedures (exactly how), with no mandatory order.

This section compares ATT&CK with two other threat frameworks, the Cyber Kill Chain and the Diamond Model, so the right one can be matched to the task.

MITRE's position is that "most models and frameworks are complementary to ATT&CK, so you don't have to choose just one" (ATT&CK FAQ^[8]). The choice depends on the question being asked:

Question	MITRE ATT&CK	Cyber Kill Chain
What does it describe?	Detailed adversary behavior	The progression of an intrusion through high-level phases
Is there an order?	No: tactics are unordered	Yes: ordered phases
Level of detail	Specific techniques	Broad objectives
Typical use	Describing activity, checking detection coverage	Explaining how an attack progresses

The comparison rests on MITRE's descriptions of how the models relate. The Cyber Kill Chain, developed by Lockheed Martin, uses ordered phases to describe high-level adversary objectives, while ATT&CK sits at a lower level of definition (ATT&CK FAQ^[8]). The Diamond Model "is helpful if you're trying to cluster intrusions", and ATT&CK-mapped techniques can be one input into it for analyzing adversary capabilities (ATT&CK FAQ^[8]).

Threat frameworks also differ from threat modeling. These frameworks describe and analyze how adversaries behave, while threat modeling examines a system's design to find potential security problems throughout its lifecycle, ideally beginning during planning.

The ordering trap

Distinguish the models by whether they prescribe ordered phases. The Cyber Kill Chain is the ordered phase model; ATT&CK's matrix columns are not, even though they are laid out left to right. Reading the matrix as a kill chain leads to dismissing a real observation because an "earlier" column was never seen.

The takeaway: use the Cyber Kill Chain for the broad, ordered story of an attack, ATT&CK for the detailed behavior, and the Diamond Model to relate intrusions to each other.