Part 23 — Threat Intelligence & IOC Analysis
# Part 23 — Threat Intelligence & IOC Analysis
*Fifteen medium-level interview questions on turning threat intelligence into defensive action — indicator quality, confidence, aging, pivoting, sharing standards, and avoiding false conclusions.*
*Figure: Part 23 — Not every connection is evidence; intelligence depends on context, confidence, and time.*
> **Series:** Cybersecurity Interview Questions — Parts 21–40 · **Part 23 of 40** · **Author:** Karanam Shrivasta
> **Previous:** Part 22 — Detection Rules & Detection Engineering
> **Next:** Part 24 — Security Logging & Log Analysis
> **Level:** Medium · **Format:** 15 questions (12 core + 3 scenario-based) with answers, practical explanations, defensive perspective, interview tips, and common mistakes
## Introduction
Threat intelligence is often introduced as a list of bad IP addresses and file hashes. In practice, the list is the least interesting part. The real work is deciding which information is relevant, how much to trust it, how long it stays useful, and what a defender should actually do with it.
Part 2 introduced the difference between indicators of compromise and indicators of attack. Part 23 builds on that with the analytical questions interviewers use to test judgment: how to rate a source, why a match on a cloud provider’s IP address might mean nothing, how to share information responsibly, and how to avoid turning a weak indicator into a confident but wrong conclusion.
The recurring theme is that intelligence exists to support decisions. If it does not change what someone detects, blocks, hunts, patches, or prioritizes, it is information, not intelligence.
## Learning Objectives
After working through this part, you should be able to:
- Distinguish strategic, operational, tactical, and technical intelligence and who uses each.
- Evaluate indicator quality using relevance, confidence, context, and age.
- Explain why shared infrastructure causes false positives and how to handle it.
- Describe STIX, TAXII, and the Traffic Light Protocol and why they exist.
- Use analytical models such as the Diamond Model and intelligence requirements to structure work.
- Handle scenario questions about indicator matches, report triage, and sharing.
## Interview Questions
### 1. How do strategic, operational, tactical, and technical threat intelligence differ, and who consumes each?
**Answer:** They differ by audience, time horizon, and level of detail. Strategic intelligence informs leadership about trends and risks affecting the organization. Operational intelligence describes specific campaigns or adversary intentions relevant to upcoming or ongoing activity. Tactical intelligence describes adversary TTPs used by defenders to design detections and controls. Technical intelligence includes specific indicators such as hashes, domains, and IP addresses consumed by tools.
**Practical explanation:** A board might receive a strategic brief on ransomware trends in its sector. An incident response lead might use operational intelligence about a campaign targeting a software product the company uses. Detection engineers use tactical intelligence to build behaviour-based rules. A firewall or SIEM consumes technical indicators automatically. Some frameworks group these differently — for example, merging tactical and technical — but the key point is that each audience needs a different product.
**Defensive perspective:** Mismatch is a common failure: sending indicator lists to executives or strategic essays to SOC analysts helps no one.
**Interview tip:** Tie each level to a decision. “Strategic intelligence informs budget and risk decisions; tactical intelligence informs detection design.”
**Common mistake:** Treating “threat intelligence” as synonymous with indicator feeds.
### 2. What makes an indicator of compromise high quality?
**Answer:** A high-quality indicator is relevant to your environment, accurate, recent, specific enough to avoid collisions with legitimate activity, and accompanied by context: what it represents, where it was observed, how confident the source is, and when it was last seen.
**Practical explanation:** A bare IP address with no date, no context, and no confidence rating is difficult to act on. The same IP address labelled “observed as command-and-control for a specific malware family, first seen and last seen dates, medium confidence, dedicated hosting” gives an analyst enough to decide whether to block, hunt, or monitor. Context also lets you distinguish indicators suitable for blocking from those only suitable for alert enrichment.
**Defensive perspective:** Low-quality indicators create noise and can cause operational harm if they block legitimate services.
**Interview tip:** Mention that you would track the indicator’s *outcome* — how often it produced true positives in your environment — to judge feed quality over time.
**Common mistake:** Measuring a feed by the number of indicators it provides rather than the number of useful detections it enables.
### 3. Why do indicators lose value over time, and how would you manage indicator aging?
**Answer:** Adversaries change infrastructure and tooling, domains expire or are re-registered, IP addresses are reassigned, and hashes change with every rebuild. An indicator that was accurate last month may now point to a legitimate service or to nothing at all.
**Practical explanation:** IP addresses in cloud and hosting environments are frequently reassigned, so an old malicious IP may now belong to an unrelated customer. Domains may be taken down, sinkholed by researchers, or re-registered. A practical approach assigns each indicator type a default lifetime (for example, shorter for IP addresses than for file hashes), extends it when the indicator is re-observed, and removes or downgrades it when it expires. Expired indicators can still be retained for retrospective investigation.
**Defensive perspective:** Aging reduces false positives and keeps blocklists manageable. It also avoids blocking legitimate traffic to reused infrastructure.
**Interview tip:** Say that different indicator types age differently, and explain why — hashes do not become “benign,” but IP addresses often do.
**Common mistake:** Keeping every indicator forever on the assumption that more data is always safer.
### 4. How would you assess the reliability of an intelligence source and the credibility of a specific report?
**Answer:** Assess them separately. Source reliability reflects the source’s track record and access; information credibility reflects whether the specific claim is corroborated and plausible. A reliable source can make a mistake, and an unknown source can occasionally be right.
**Practical explanation:** Some teams use the Admiralty (NATO) system, which rates source reliability with letters and information credibility with numbers. In practice, questions include: Has this source been accurate before? Does it have direct visibility of what it claims? Is the report corroborated by other independent sources or your own data? Does it describe observations or assumptions? Is the reasoning shown?
**Defensive perspective:** Record confidence explicitly in your own products. Consumers can then decide whether to block on a finding or merely monitor it.
**Interview tip:** Mention that corroboration from sources that copy each other is not independent corroboration.
**Common mistake:** Treating vendor reports or social media posts as authoritative without examining evidence and methodology.
### 5. Your SIEM reports a match between internal traffic and an IP address on a threat feed. The IP belongs to a large cloud provider. How do you interpret this?
**Answer:** Treat the match as a lead, not a conclusion. Large cloud and content delivery providers host many unrelated customers behind shared or frequently reassigned addresses, so a match may reflect legitimate traffic to a completely different service.
**Practical explanation:** Check the indicator’s context and age, then look at what your host actually communicated with: the requested domain name or TLS server name, the HTTP host header if visible, the process that initiated the connection, and the timing and volume pattern. If the host was reaching a well-known business application hosted on the same provider, the match is almost certainly benign. If the process is unusual and the connection pattern is regular and persistent, investigate further.
**Defensive perspective:** For shared infrastructure, domain names, certificate attributes, and behavioural patterns are more meaningful than IP addresses. Feed ingestion can also tag shared-infrastructure ranges to lower their priority.
**Interview tip:** Mention that blocking the IP could disrupt legitimate services, so blocking decisions should consider collateral impact.
**Common mistake:** Escalating as a confirmed compromise because the IP appeared on a list.
### 6. What is “pivoting” in threat intelligence analysis, and what are its risks?
**Answer:** Pivoting means using one known data point to find related ones — for example, from a malicious domain to its registration details, historic DNS resolutions, hosting IP, TLS certificates, and other domains sharing those attributes. It helps build a fuller picture of adversary infrastructure. Its risk is drawing false connections from attributes that many unrelated parties share.
**Practical explanation:** Passive DNS data might show that a malicious domain previously resolved to an IP that also hosted other suspicious domains. That is useful — unless the IP is a shared hosting server with thousands of sites. Certificate transparency logs, registration patterns, and hosting providers can link infrastructure, but each link should be weighed for how unique it is.
**Defensive perspective:** Pivot using passive data sources and authorized intelligence platforms. Directly probing suspected adversary infrastructure can alert the adversary, may breach legal or policy boundaries, and should only be done under approved procedures.
**Interview tip:** Mention “link strength”: a shared unusual certificate attribute is a strong link; a shared large hosting provider is a weak one.
**Common mistake:** Building a large infrastructure graph and presenting every connected node as malicious.
### 7. What are STIX and TAXII, and what problem do they solve?
**Answer:** STIX (Structured Threat Information Expression) is a standardized language and data model for describing cyber threat information — indicators, malware, threat actors, attack patterns, relationships, and more. TAXII (Trusted Automated Exchange of Intelligence Information) is a protocol for exchanging that information over HTTPS. Both are maintained by OASIS.
**Practical explanation:** Without a standard, every sharing partner uses a different format, and receiving systems need custom parsing. STIX allows a threat intelligence platform to express that “this indicator indicates this malware, which is used by this intrusion set, which uses this attack pattern,” with confidence and timestamps. TAXII lets organizations publish and subscribe to collections of that information automatically.
**Defensive perspective:** Standard formats help, but they do not guarantee quality. A well-formatted STIX bundle can still contain stale or poorly sourced indicators.
**Interview tip:** Mention relationships. The value of STIX is less in describing single indicators and more in expressing how objects relate.
**Common mistake:** Assuming that automated TAXII ingestion removes the need for human review and tuning.
### 8. What is the Traffic Light Protocol (TLP), and how should it affect your behaviour?
**Answer:** TLP is a set of labels that tells recipients how widely they may share information. FIRST maintains the current version, TLP 2.0, which uses TLP:RED, TLP:AMBER+STRICT, TLP:AMBER, TLP:GREEN, and TLP:CLEAR, ranging from the most restricted (named recipients only) to information that may be shared publicly subject to copyright rules.
**Practical explanation:** If you receive a TLP:AMBER+STRICT report, you may share it only within your own organization on a need-to-know basis. You should not paste it into a public forum, a public sandbox comment, or a partner email list. TLP is about sharing permission, not classification or urgency.
**Defensive perspective:** Respecting TLP maintains trust in sharing communities. Breaching it can cut an organization off from valuable intelligence.
**Interview tip:** Mention that when a label is unclear, you ask the originator before sharing further.
**Common mistake:** Treating TLP labels as optional or as indicators of severity.
### 9. How does the Diamond Model of Intrusion Analysis help an analyst?
**Answer:** The Diamond Model describes each intrusion event using four core features — adversary, capability, infrastructure, and victim — and the relationships between them. It helps analysts organize information, identify gaps, and pivot logically from one feature to another.
**Practical explanation:** If an investigation knows the capability (a malware family) and the victim (a finance workstation), the model prompts the analyst to ask what infrastructure the capability used and whether other victims connected to that infrastructure. Across many events, analysts can group activity into threads and activity groups. It complements rather than replaces MITRE ATT&CK, which focuses on techniques.
**Defensive perspective:** The model encourages analysts to document what is known versus assumed at each point, which reduces overconfident conclusions.
**Interview tip:** Explain one concrete pivot using the model rather than only listing the four corners.
**Common mistake:** Using the model only for diagrams and not for identifying investigative gaps.
### 10. What are intelligence requirements, and why should a threat intelligence program start with them?
**Answer:** Intelligence requirements are the questions stakeholders need answered to make decisions — for example, “Which threat groups are targeting organizations in our sector with ransomware, and what initial access methods are they using?” Starting with requirements ensures intelligence work supports real decisions rather than collecting information for its own sake.
**Practical explanation:** Requirements are often described as priority intelligence requirements (PIRs) and are gathered from stakeholders such as the SOC, vulnerability management, leadership, and fraud teams. They guide collection (which sources to use), analysis (what to focus on), and dissemination (who receives what, in which format). This is part of the intelligence lifecycle: direction, collection, processing, analysis, dissemination, and feedback.
**Defensive perspective:** Requirements also give a way to measure the program: did the intelligence answer the questions stakeholders asked?
**Interview tip:** Mention that requirements should be reviewed periodically as the business and threat landscape change.
**Common mistake:** Buying feeds first and deciding what questions they answer later.
Get Karanam Shrivasta’s stories in your inbox
Join Medium for free to get updates from this writer.
### 11. How would you safely analyze a suspicious file hash reported by a user or tool?
**Answer:** Start with the hash, not the file. Look it up in your own telemetry and in reputable intelligence sources, check where it appeared internally, and only handle the file itself in an isolated analysis environment following your organization’s procedures.
**Practical explanation:** A hash lookup can reveal whether the file is known-good, known-malicious, or unknown, and your EDR or SIEM can show which hosts have it and how it arrived. Be careful with public sandboxes and multi-scanner services: uploading a file may make it available to other users, which can expose confidential documents or alert an adversary that their tool has been found. Many organizations restrict uploads for this reason and prefer hash-only lookups or private sandboxes.
**Defensive perspective:** “Unknown” is not “benign.” A hash with no reputation is common for custom or recompiled malware and for internal software.
**Interview tip:** Mention checking prevalence: a file on one host is treated differently from a file on thousands of hosts.
**Common mistake:** Uploading internal documents to public analysis services to check whether they are malicious.
### 12. What are the risks of attribution, and how much should a defender care about it?
**Answer:** Attribution — identifying who is behind an intrusion — is difficult, often uncertain, and can be misled by shared tools, false flags, and overlapping infrastructure. For most defenders, understanding *what* the adversary does matters more than *who* they are, although attribution can help anticipate objectives and future behaviour.
**Practical explanation:** Multiple groups may use the same publicly available tools, and some criminal services are used by many customers. Naming a specific actor confidently based on one indicator or tool can mislead responders about the adversary’s goals. Many intelligence teams use “activity clusters” or intrusion sets and express attribution with explicit confidence levels.
**Defensive perspective:** Focus response on behaviour, scope, and impact. Leave formal attribution to teams with the necessary evidence, legal guidance, and mandate.
**Interview tip:** Say that you would communicate attribution with a confidence level and the evidence behind it.
**Common mistake:** Telling stakeholders “this was group X” based on a single tool overlap.
## Scenario-Based Interview Questions
### 13. A widely shared report lists 200 indicators for a new campaign. Your manager asks whether you are affected. How do you proceed?
**Answer:** Assess relevance, search efficiently, and report with confidence and scope rather than a simple yes or no.
**Practical explanation:**
1. Read the report for context — targeted sectors, technologies, initial access methods — and decide how relevant it is.
2. Check indicator quality: age, type, and whether any belong to shared infrastructure.
3. Run retrospective searches across the relevant time range in proxy, DNS, firewall, EDR, and email data.
4. Extract the described behaviours and check whether existing detections cover them.
5. Report findings: “No matches for 186 indicators in the last 90 days; 14 indicators matched shared CDN infrastructure and were reviewed as benign; two described behaviours are covered by tested detections, one is not.”
**Defensive perspective:** Behavioural coverage protects against the next variation; indicator searches only address this specific set.
**Interview tip:** Mention the searchable time range. “No matches” is only meaningful if you have data for the period in question.
**Common mistake:** Adding all 200 indicators to a blocklist without review.
### 14. An EDR alert fires on a domain that your threat intelligence platform scores as “high confidence malicious,” but the domain belongs to a small legitimate vendor your company uses. What do you do?
**Answer:** Investigate both possibilities: a false positive in the intelligence, or a genuine compromise of the vendor’s infrastructure. Neither should be assumed.
**Practical explanation:** Check the intelligence record’s source, date, and supporting evidence. Look at what your hosts actually did: which process connected, what was downloaded, whether the connection pattern changed recently. Legitimate vendor domains are sometimes compromised and used to host malicious content, which is why the alert should not simply be dismissed. If evidence suggests compromise, coordinate with vendor management and security contacts through established channels.
**Defensive perspective:** Supply-chain risk means “trusted vendor” and “malicious” are not mutually exclusive.
**Interview tip:** Mention feedback: if the intelligence is wrong, report it to the provider so the score can be corrected.
**Common mistake:** Allow-listing the vendor domain permanently without understanding why it was flagged.
### 15. You discover indicators from an incident at your organization that could help others. How would you share them responsibly?
**Answer:** Share through appropriate channels, with legal and management approval where required, after removing sensitive internal information, using a clear TLP label and enough context for recipients to act.
**Practical explanation:** Appropriate channels may include sector ISACs or ISAOs, national CERTs, trusted peer groups, or intelligence platforms your organization participates in. Before sharing, remove internal hostnames, usernames, personal data, and anything that reveals unrelated vulnerabilities. Provide context: what the indicator represents, first and last observed times, confidence, and suggested use (block, detect, or hunt). Structured formats such as STIX make automated consumption easier.
**Defensive perspective:** Sharing can shorten the time it takes other organizations to detect the same activity, but poor sharing can expose your organization or mislead recipients.
**Interview tip:** Mention that incident-related sharing may have legal or regulatory considerations, so you involve the appropriate internal stakeholders first.
**Common mistake:** Posting raw indicators publicly without context, approval, or sanitization.
## Key Takeaways
- Intelligence exists to support decisions; its value is measured by the actions it enables.
- Indicators need context, confidence, and age; bare lists create noise and risk.
- Shared infrastructure makes IP-based matches weak evidence on their own.
- Pivoting should use passive, authorized sources, and link strength matters.
- STIX, TAXII, and TLP standardize format, transport, and sharing permissions — not quality.
- Behaviour-based detection outlasts indicators; attribution should always carry stated confidence.
## Strong Cybersecurity Disclaimer
> **IMPORTANT CYBERSECURITY DISCLAIMER**
>
> This material is provided strictly for educational, defensive, research, and authorized security-testing purposes. Cybersecurity techniques described in this article must only be applied to systems, networks, applications, accounts, devices, cloud environments, or data that you own or are explicitly authorized to assess.
>
> Unauthorized scanning, exploitation, credential attacks, interception, access attempts, persistence, privilege escalation, data extraction, disruption, or other security activity may violate organizational policies and applicable laws.
>
> Examples in this article are intended to explain cybersecurity concepts, detection, prevention, investigation, secure configuration, risk assessment, and authorized testing. They must not be interpreted as permission to target third-party systems. Indicator analysis, enrichment, and pivoting described here must use your own data, authorized intelligence platforms, and passive sources; never interact with suspected adversary infrastructure outside approved procedures.
>
> The author does not authorize, encourage, endorse, or accept responsibility for unauthorized activity performed using information from this material.
>
> Readers are responsible for obtaining appropriate authorization, following applicable laws and regulations, respecting rules of engagement, protecting sensitive information, and maintaining safe isolated lab environments where required.
>
> Security information can become outdated as software, standards, configurations, and threats change. Readers should independently verify security-sensitive information against current authoritative documentation before applying it in production or testing environments.
>
> All names, hosts, domains, and addresses used in examples (such as `HOST-A`, `SERVER-01`, `TEST-USER`, `example.test`, and RFC 5737 documentation addresses) are fictional placeholders.
## References
- NIST SP 800–150, *Guide to Cyber Threat Information Sharing* — https://csrc.nist.gov/pubs/sp/800/150/final
- OASIS Cyber Threat Intelligence (STIX and TAXII) documentation — https://oasis-open.github.io/cti-documentation/
- FIRST — Traffic Light Protocol (TLP) 2.0 — https://www.first.org/tlp/
- Caltagirone, Pendergast, and Betz, *The Diamond Model of Intrusion Analysis* (2013) — https://apps.dtic.mil/sti/citations/ADA586960
- David J. Bianco, “The Pyramid of Pain” — https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
- MITRE ATT&CK — Groups — https://attack.mitre.org/groups/
- CISA — Information Sharing — https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing
## Author
**Karanam Shrivasta**
Karanam Shrivasta is an aspiring cybersecurity professional and technology learner focused on cybersecurity, ethical hacking, security engineering, AI, and related technologies. This series is written as public study notes for interview preparation and practical security education.
LinkedIn:
<https://www.linkedin.com/in/karanam-shrivasta/>
GitHub:
<https://github.com/mrshrivasta>
## SEO Package
**SEO Title:** Threat Intelligence Interview Questions: IOC Analysis Guide
**Meta Description:** Medium-level threat intelligence interview questions on IOC quality, confidence, indicator aging, pivoting, STIX/TAXII, TLP 2.0, and the Diamond Model.
**Primary Keyword:** threat intelligence interview questions
**Secondary Keywords:** IOC analysis, indicator of compromise quality, indicator aging, STIX and TAXII, Traffic Light Protocol, Diamond Model of Intrusion Analysis, intelligence requirements, threat intelligence sharing, CTI analyst interview
**Search Intent:** Readers preparing for CTI analyst, SOC, or incident response interviews who want to understand how intelligence is evaluated, operationalized, and shared responsibly rather than simply consumed as indicator feeds.
## AEO Package
**Direct Answer:** Threat intelligence analysis turns information about adversaries into decisions defenders can act on. Good IOC analysis checks relevance, context, confidence, and age; treats matches on shared infrastructure as leads rather than proof; pivots using passive sources; shares through STIX/TAXII and TLP-labelled channels; and prioritizes behaviour-based detection over short-lived indicators.
## GEO / Entity Coverage
Cyber threat intelligence (CTI); strategic, operational, tactical, and technical intelligence; indicators of compromise (IOCs); indicators of attack; indicator aging; Admiralty/NATO source grading; shared infrastructure and CDNs; passive DNS; certificate transparency; pivoting; STIX 2.1; TAXII 2.1; OASIS; Traffic Light Protocol 2.0; FIRST; Diamond Model; priority intelligence requirements (PIRs); intelligence lifecycle; attribution; ISACs; NIST SP 800–150; Pyramid of Pain.
