What do you think?
Rate this book
Intelligence-Driven Incident Response: Outwitting the Adversary
Using a well-conceived incident response plan in the aftermath of an online security breach enables your team to identify attackers and learn how they operate. But only when you approach incident response with a cyber threat intelligence mindset will you truly understand the value of that information. In this updated second edition, you'll learn the fundamentals of intelligence analysis as well as the best ways to incorporate these techniques into your incident response process. Each method reinforces the threat intelligence supports and augments incident response, while incident response generates useful threat intelligence. This practical guide helps incident managers, malware analysts, reverse engineers, digital forensics specialists, and intelligence analysts understand, implement, and benefit from this relationship. In three parts, this in-depth book
575 pages, Kindle Edition
Published June 1, 2023
107 people are currently reading
302 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 11 of 11 reviews
July 6, 2023
Helpful, informative guide to the theory and practice of cyber threat intelligence (CTI), giving practical steps for running integrated, complementary CTI and incident response (IR) ops. Much of the book walks through the F3EAD model (a combination of the incident response and intel cycles).
Notes
Introduction
To aid decision-making, don't just give data; tell a story.
Basics of Intelligence
IoCs can be used to detect threats on network and aid post-incident analysis & strategic research.
Use OODA loop to make quick decisions. Use intel cycle to generate more formal intel products.
OODA loop
1. Observe: collect info (gather logs, monitor systems, collect outside info).
2. Orient: put info into context with known info about network, threat actors, IoCs, requirements, mission.
3. Decide: debate various courses of action (continue to observe attacker, start IR, or ignore activity), then choose 1.
4. Act: execute course of action.
Both defender and attacker use OODA loop. Try to slow down attacker loop and speed up defender loop.
Consider how 1 defender team's decisions affect others (e.g., org publicly sharing info about attack starts clock for defenders in other orgs to use that intel).
Intel Cycle
1. Direction: Establish question(s) that intel is to answer.
2. Collection: Gather data from external & internal sources. Redundant data is useful for corroboration. Include all threat actor aliases.
3. Processing: Make data usable (normalize, index, translate, enrich, filter, prioritize, visualize).
4. Analysis: Assess meaning & implication of data to answer question(s). Use analytic models to analyze, assess, predict.
5. Dissemination: Share intel with relevant stakeholders, in form they prefer.
6. Feedback: Ask stakeholders if intel successfully answered question(s).
Qualities of good intel
• Collection method (how info was collected)
• Date of collection
• Context (activities related to info, relationships between pieces of info, etc.)
• Addresses analytic biases
Intel levels
• Tactical: Low-level, highly perishable info. Includes IOCs, observables, granular TTPs. Customers: SOC analysts, CIRT investigators.
• Operational: More general than tactical, more specific than strategic. Includes info on campaigns; generalized TTPs (campaigns, actions on objective); anticipated adversary responses; actor attribution, capabilities, intent. Customers: senior DFIR analysts, other CTI teams.
• Strategic: Info for making serious decisions about risk assessments, resource allocation, organizational strategy. Includes threat trends, actor motivations, new tactics or targeting. Customers: C-level executives, boards of directors.
Basics of Incident Response
Understanding what's being targeted gives insight into adversary's goal, so you can better defend.
Data types
• Hard data: info about technical aspects of network, systems
• Soft data: info about org
Collection methods
• Active: collecting by interacting directly with target
• Passive: collecting info without interacting directly with target (e.g., DNS, WHOIS)
Weaponization: finding vulnerability, crafting exploit, developing payload, testing payload
Actions on Objective
• Destroy: destroy physical or virtual item
• Deny: deny usage of resource
• Degrade: degrade utility of resources or capabilities (usually C2)
• Disrupt: interrupt flow of info
• Deceive: deliver false info
D5 model can also be used for defense.
Each event in Diamond Model can be categorized according to its Kill Chain phase.
Use ATT&CK & D3FEND together to trace from actor to system-hardening steps & detections.
Reasons to not hack back
• Difficult to accurately identify/attribute attacker
• Difficult to respond proportionately
• Serves limited purpose beyond sense of revenge
• Could trigger retaliation
• Illegal in most countries
Active defense: disrupt attacker's tempo; impose cost; force attacker into making mistake, to expose them
F3EAD cycle
Intel & IR cycles feed into each other in OODA loop; each IR op leads to an intel op, & each intel op leads to an IR op
1. Find: determine threat(s) to address (Preparation phase of IR cycle)
2. Fix: identify attacker's presence in network (Identification phase of IR cycle)
3. Finish: take action against attacker (Containment, Mitigation, Eradication phase of IR cycle)
4. Exploit: gather info about attacker, from each stage of Kill Chain (Collection phase of intel cycle)
5. Analyze: develop complete picture of attacker and TTPs, & how to detect, mitigate, remediate (Analysis phase of intel cycle)
6. Disseminate: share intel with relevant stakeholders (Dissemination phase of intel cycle)
Find
Find info based on actor, victim, asset, capability, infrastructure, and/or media (news).
Goal: develop info that will be useful during Fix phase. Most useful info is hard-to-change info (high in Pyramid of Pain), especially attacker goals.
Fill in Kill Chain with info known about attacker.
Victim-centric questions
• Why were these victims targeted?
• What commonalities do they share?
• Can actors' goals or motivations be inferred from victims?
Victim-infrastructure questions
• What was connection between victim & adversary’s infrastructure?
• Did other devices interact with infrastructure in same way as victim?
• Is anything unique about relationship that could be pivoted on?
Victim-capability questions
• What about victim made this capability (un)successful?
• Are other victims susceptible to same capabilities?
Victim-adversary questions
• What would targeting victim help adversary achieve?
• Are there other victims with similar characteristics that may have been targeted?
By understanding who is capable of attacking types of systems you're protecting, you can focus on indicators & tools that are useful for attacking your systems.
To avoid rabbit holes, stop 2 pivots away from piece of info you know is relevant.
Attribute based on goals, motivations, behaviors, tactics. Don't attribute based on malware (shared by many groups).
Lead format
• Lead: core observation/idea
• Datetime: when lead was submitted
• Context: how lead was found (internal or external, research or incident)
• Analyst: who found lead
RFI content
• Request: summary of question
• Requestor
• Output: expected product (IoCs, briefing document, presentation)
• References: document(s) related to request
• Priority, due date
Fix
C2 communication
• Destination: known bad IP addresses, domains; unexpected locations
• Content: unexpected encrypted traffic, mismatches between content & protocol, suspicious metadata
• Frequency: patterns in communication frequency
• Duration: patterns in message length
Unusual traffic patterns that indicate data entering or leaving network, & unusual interactions between internal systems, can indicate attack.
Detecting exfiltration
• Monitor content (e.g., DLP)
• Monitor connection metadata
• Monitor ATT&CK techniques
Finish
Stages: mitigate, remediate, rearchitect
Finish phase can tip off adversary, so consider their potential responses, then act as quickly as possible to prevent persistence.
Monitoring lifecycle for signatures: creation, testing, deployment, refinement, retirement
Exploit
Gather data from investigation, analyze it for intel value, integrate it into detection and prevention methods & strategic initiatives (risk assessments, prioritization of efforts, future security investments).
Goal of 1st half of F3EAD is to give IR a tactically competitive advantage. Goal of 2nd half of F3EAD is to gain a strategically competitive advantage (understand adversary so well that their usual tactics and techniques won't work).
OASIS suite
• STIX: observables, context, relationships
• TAXII: STIX transportation & sharing framework
OpenIOC: Mandiant's standard for capturing IOCs; largely deprecated
ATT&CK: framework that describes relationships between Adversary Group, Technique, Tactic, Software
VERIS: framework that captures info about incident's Actor, Action, Asset, and Attribute, timeline, impact; used to understand risk
CAPEC: framework that captures attack pattern, including prerequisites, related weaknesses, related vulnerabilities, attacker steps
TIPs
• MISP: free; robust sharing
• YETI: free; designed to enable organization & analysis of various CTI components in 1 place; can do some indicator enrichment
Most commercial TIPs also manage system config, handle setup & hardware management, offer support for troubleshooting or feature requests. They're generally easier to set up and maintain.
Analyze
Choosing structured analytic technique (SAT)
1. Determine question to answer
2. Identify nature of question (e.g., diagnose, predict)
3. Determine if you have enough info to make hypothesis(es)
Key Assumptions Check
Method to identify assumptions being used, to fill info gaps & determine whether assumptions are valid
1. Gather people familiar with project & analysts who aren't familiar.
2. Identify topic. Ask each participant to write their assumptions.
3. As a group, review everyone's assumptions & brainstorm more.
4. For each assumption, ask key questions (e.g., "Why do we think this is true?" "How much evidence supports this assumption?"). Propose alternate assumptions that would significantly change perception.
5. For each assumption, evaluate whether it's sound, supported but with some caveats, or unsupported or questionable. Or, use 1-5 scale to rate confidence. For low-confidence assumptions, plan to gather additional info to help determine whether to keep them.
6. Assign each key assumption a place on a 2x2 matrix measuring high & low certainty, high & low potential impact. Low certainty/high potential impact assumptions are priority.
Analysis of Competing Hypotheses (ACH)
Method to determine most likely hypothesis among several
1. Identify hypotheses to consider.
2. Make list of evidence for & against each hypothesis.
3. Create matrix to evaluate whether each piece of evidence supports or refutes each hypothesis.
4. Conduct initial analysis to refine matrix.
5. Draw initial conclusions about likelihood of each hypothesis, focusing on disproving them.
6. Analyze how much of conclusion depends on single piece of evidence.
7. Report conclusions on likelihood of all hypotheses.
8. Identify situations in which analysis would need to be reevaluated.
Indicator Generation, Validation, & Evaluation
Method to generate, validate, evaluate list of indicators (IoCs or other observables) prior to analysis
1. Generate list of indicators that identify that particular activity is occurring or not.
2. Validate that each indicator can be observed (directly or indirectly), is reliable & specific. Rate according to likeliness to identify activity.
Use contrarian techniques (Devil’s Advocate, "What If" Analysis, Red Team Analysis) when wrong judgment would have serious consequences, or when you expect judgment to be contested. "What If" Analysis sees how other variables would change analysis. Red Team Analysis analyzes how adversary would think/act.
Futures Wheel: forecasting technique that predicts chain reaction
Target-centric analysis focuses on analyst-customer and analyst-collector relationships to build model of situation.
Target-centric analysis: Iterative process where info is gathered, analyzed to see if it helps answer questions. May generate new requirements. If more info is needed, collection & processing phases are repeated, info is disseminated. Analysts frequently ask customers if situation & needs have changed.
Analysis process
1. Determine what to analyze
2. Enrich data
3. Reference info from sharing relationships
4. Develop hypothesis
5. Evaluate key assumptions
Questions to determine what to analyze
• Why were we targeted? Analyze how they affected you, actions they took.
• Who attacked us? Analyze tactics, targets, operating hours, infrastructure used, etc.
• How could this have been prevented?
• How can this be detected? Analyze hashes, IP addresses, targets, tactics.
• Are there any patterns that can be identified? Analyze targets, infrastructure used, social engineering, etc.
Enrichment sources
• WHOIS (identify attacker infrastructure, compromised domains, researcher-run infrastructure & sinkholes)
• Passive DNS (understand nature of activity; pair with WHOIS)
• Certificates
• Malware (detection ratio, file details [fill knowledge gaps, indicate uniqueness], behavior [hash, installation destination, files it calls or relies on, automated actions])
• Biz ops: what's happening in network & org at time of incident
• User information: which users were targeted, attacker’s tactics
Share via ISACs, ISAOs, public/private partnerships, informal groups.
Evaluating key assumptions
1. Identify all key assumptions
2. Identify why assumption was made
3. Assess confidence in assumption
4. Identify how confidence rating was determined
5. Challenge each assumption, determine if it's true
6. Remove assumptions that aren't true or have low confidence
Biases
• Confirmation bias
• Anchoring bias
• Availability bias
• Bandwagon effect
• Mirroring (mirror-image bias)
Make judgment
1. Assess likelihood of hypothesis based on evidence. Focus on disproving rather than proving. Identify info that disproves.
2. Review info that led to judgment. Note if a single piece of evidence weighed most heavily, how confident you are in it.
3. Record conclusion on each hypothesis, citing evidence & confidence.
4. Articulate under what circumstances analysis would need to be reevaluated. State indicators.
Judgment formula: I/we assess with [low, moderate, high] confidence that [state judgment] based on [state evidence]. I/we will be monitoring [state indicators] to further support or refute this judgment.
Disseminate
Explicitly state customer’s goal/expectations for product.
Writing for leadership
• Focus on intel necessary to make biz decisions.
• Use intel to tell story of threat.
• Be brief, to the point. Start with executive summary.
Writing for technical customers
• Focus on improving detection, minimizing false positives
• Focus on data
• Be highly technical & descriptive, with references & research
• Back up products with machine-consumable products (e.g., STIX, YARA)
• Include method for accepting feedback, questions
Customer personas
• Name
• Title
• Key characteristics
• Department
• Reports to
• Background
• Technical acumen
• Preferred product
• Goals & challenges
• Values & fears
If you have many customers, use a few general personas. If you have few customers, use detailed personas for each. Or use detailed personas for key customers & general ones for others.
Actionability
• Provide info on adversary TTPs
• Ensure products that contain IoCs & signatures are easy for customers to use (e.g., Snort, YARA)
• Answer customer's questions
• Avoid broad descriptions of activity without meaningful details
• Don’t hinder copying info
• Avoid vendor-specific formats
• Don’t over-classify info
Customer characteristics
• Needs (problems, questions)
• Tech (tools)
• Maturity (skill level of team)
• Methodologies
Drafting
• Start with thesis statement; narrative format is natural for producers & customers
• Start with facts (times, indicators, concrete info)
Avoid
• Passive voice
• Uncommon terms & acronyms
• Leading or unobjective language
• Imprecision about known versus suspected
Consider visualizing data, adding graphics.
Writing structure
• What: issues, facts
• So what: why issues & facts are important to stakeholders
• Now what: actions customers can or should take
Intel product templates
Short-form products: 1-2 pages; address specific tactical or operational intel needs
Target package: actor description; useful for summarizing info from vendor reports; fact-based; don't get too far into estimative analysis, attribution
Campaign report: end-to-end breakdown of intrusion campaign; useful for identifying analysis gaps, which may lead to RFIs; useful for identifying missing response actions & bringing stakeholders up to speed
Intel estimate: provides context necessary for making strategic decisions (examples)
Use YYYYMMDD format to be easier to read & sort. Use 24-hour clock & consistent time zone (preferably UTC).
Use feedback to improve customer personas.
Weekly threat report: 1-page product focused on ongoing investigations & incidents, situational awareness (security news); good for variety of customers
5 questions to ask when writing products
• What is goal?
• Who is audience?
• What is proper length?
• Tactical, operational, or strategic?
• What language tone? Technical or nontechnical?
Strategic Intelligence
Strategic info: geopolitical, economic, historical, business
Analyze strategic intel with SWOT analysis, brainstorming, scrub down.
Scrub down (aka murder board): analyst presents findings to review board, which questions findings & analytic processes; helps identify biases, unvalidated key assumptions, analytic leaps not founded on evidence.
Anticipatory intel: studying situation & surrounding context, environment, & related situations to anticipate broad spectrum of possible future events & implications
Questions answered by strategic intel
• Which threats are most significant to org? Where should IR prioritize & focus?
• Which types of info are important to capture? What findings warrant brief to CISO or other execs?
• What situations may emerge as world changes?
• How do external situations (financial crises, global conflict, pandemics, etc.) impact security posture?
Building an Intelligence Program
Use 3rd-party intel & feeds for enrichment, not primary source.
Link new uses/tactics to existing indicators while weeding out indicators that are no longer valid.
Notes
Introduction
To aid decision-making, don't just give data; tell a story.
Basics of Intelligence
IoCs can be used to detect threats on network and aid post-incident analysis & strategic research.
Use OODA loop to make quick decisions. Use intel cycle to generate more formal intel products.
OODA loop
1. Observe: collect info (gather logs, monitor systems, collect outside info).
2. Orient: put info into context with known info about network, threat actors, IoCs, requirements, mission.
3. Decide: debate various courses of action (continue to observe attacker, start IR, or ignore activity), then choose 1.
4. Act: execute course of action.
Both defender and attacker use OODA loop. Try to slow down attacker loop and speed up defender loop.
Consider how 1 defender team's decisions affect others (e.g., org publicly sharing info about attack starts clock for defenders in other orgs to use that intel).
Intel Cycle
1. Direction: Establish question(s) that intel is to answer.
2. Collection: Gather data from external & internal sources. Redundant data is useful for corroboration. Include all threat actor aliases.
3. Processing: Make data usable (normalize, index, translate, enrich, filter, prioritize, visualize).
4. Analysis: Assess meaning & implication of data to answer question(s). Use analytic models to analyze, assess, predict.
5. Dissemination: Share intel with relevant stakeholders, in form they prefer.
6. Feedback: Ask stakeholders if intel successfully answered question(s).
Qualities of good intel
• Collection method (how info was collected)
• Date of collection
• Context (activities related to info, relationships between pieces of info, etc.)
• Addresses analytic biases
Intel levels
• Tactical: Low-level, highly perishable info. Includes IOCs, observables, granular TTPs. Customers: SOC analysts, CIRT investigators.
• Operational: More general than tactical, more specific than strategic. Includes info on campaigns; generalized TTPs (campaigns, actions on objective); anticipated adversary responses; actor attribution, capabilities, intent. Customers: senior DFIR analysts, other CTI teams.
• Strategic: Info for making serious decisions about risk assessments, resource allocation, organizational strategy. Includes threat trends, actor motivations, new tactics or targeting. Customers: C-level executives, boards of directors.
Basics of Incident Response
Understanding what's being targeted gives insight into adversary's goal, so you can better defend.
Data types
• Hard data: info about technical aspects of network, systems
• Soft data: info about org
Collection methods
• Active: collecting by interacting directly with target
• Passive: collecting info without interacting directly with target (e.g., DNS, WHOIS)
Weaponization: finding vulnerability, crafting exploit, developing payload, testing payload
Actions on Objective
• Destroy: destroy physical or virtual item
• Deny: deny usage of resource
• Degrade: degrade utility of resources or capabilities (usually C2)
• Disrupt: interrupt flow of info
• Deceive: deliver false info
D5 model can also be used for defense.
Each event in Diamond Model can be categorized according to its Kill Chain phase.
Use ATT&CK & D3FEND together to trace from actor to system-hardening steps & detections.
Reasons to not hack back
• Difficult to accurately identify/attribute attacker
• Difficult to respond proportionately
• Serves limited purpose beyond sense of revenge
• Could trigger retaliation
• Illegal in most countries
Active defense: disrupt attacker's tempo; impose cost; force attacker into making mistake, to expose them
F3EAD cycle
Intel & IR cycles feed into each other in OODA loop; each IR op leads to an intel op, & each intel op leads to an IR op
1. Find: determine threat(s) to address (Preparation phase of IR cycle)
2. Fix: identify attacker's presence in network (Identification phase of IR cycle)
3. Finish: take action against attacker (Containment, Mitigation, Eradication phase of IR cycle)
4. Exploit: gather info about attacker, from each stage of Kill Chain (Collection phase of intel cycle)
5. Analyze: develop complete picture of attacker and TTPs, & how to detect, mitigate, remediate (Analysis phase of intel cycle)
6. Disseminate: share intel with relevant stakeholders (Dissemination phase of intel cycle)
Find
Find info based on actor, victim, asset, capability, infrastructure, and/or media (news).
Goal: develop info that will be useful during Fix phase. Most useful info is hard-to-change info (high in Pyramid of Pain), especially attacker goals.
Fill in Kill Chain with info known about attacker.
Victim-centric questions
• Why were these victims targeted?
• What commonalities do they share?
• Can actors' goals or motivations be inferred from victims?
Victim-infrastructure questions
• What was connection between victim & adversary’s infrastructure?
• Did other devices interact with infrastructure in same way as victim?
• Is anything unique about relationship that could be pivoted on?
Victim-capability questions
• What about victim made this capability (un)successful?
• Are other victims susceptible to same capabilities?
Victim-adversary questions
• What would targeting victim help adversary achieve?
• Are there other victims with similar characteristics that may have been targeted?
By understanding who is capable of attacking types of systems you're protecting, you can focus on indicators & tools that are useful for attacking your systems.
To avoid rabbit holes, stop 2 pivots away from piece of info you know is relevant.
Attribute based on goals, motivations, behaviors, tactics. Don't attribute based on malware (shared by many groups).
Lead format
• Lead: core observation/idea
• Datetime: when lead was submitted
• Context: how lead was found (internal or external, research or incident)
• Analyst: who found lead
RFI content
• Request: summary of question
• Requestor
• Output: expected product (IoCs, briefing document, presentation)
• References: document(s) related to request
• Priority, due date
Fix
C2 communication
• Destination: known bad IP addresses, domains; unexpected locations
• Content: unexpected encrypted traffic, mismatches between content & protocol, suspicious metadata
• Frequency: patterns in communication frequency
• Duration: patterns in message length
Unusual traffic patterns that indicate data entering or leaving network, & unusual interactions between internal systems, can indicate attack.
Detecting exfiltration
• Monitor content (e.g., DLP)
• Monitor connection metadata
• Monitor ATT&CK techniques
Finish
Stages: mitigate, remediate, rearchitect
Finish phase can tip off adversary, so consider their potential responses, then act as quickly as possible to prevent persistence.
Monitoring lifecycle for signatures: creation, testing, deployment, refinement, retirement
Exploit
Gather data from investigation, analyze it for intel value, integrate it into detection and prevention methods & strategic initiatives (risk assessments, prioritization of efforts, future security investments).
Goal of 1st half of F3EAD is to give IR a tactically competitive advantage. Goal of 2nd half of F3EAD is to gain a strategically competitive advantage (understand adversary so well that their usual tactics and techniques won't work).
OASIS suite
• STIX: observables, context, relationships
• TAXII: STIX transportation & sharing framework
OpenIOC: Mandiant's standard for capturing IOCs; largely deprecated
ATT&CK: framework that describes relationships between Adversary Group, Technique, Tactic, Software
VERIS: framework that captures info about incident's Actor, Action, Asset, and Attribute, timeline, impact; used to understand risk
CAPEC: framework that captures attack pattern, including prerequisites, related weaknesses, related vulnerabilities, attacker steps
TIPs
• MISP: free; robust sharing
• YETI: free; designed to enable organization & analysis of various CTI components in 1 place; can do some indicator enrichment
Most commercial TIPs also manage system config, handle setup & hardware management, offer support for troubleshooting or feature requests. They're generally easier to set up and maintain.
Analyze
Choosing structured analytic technique (SAT)
1. Determine question to answer
2. Identify nature of question (e.g., diagnose, predict)
3. Determine if you have enough info to make hypothesis(es)
Key Assumptions Check
Method to identify assumptions being used, to fill info gaps & determine whether assumptions are valid
1. Gather people familiar with project & analysts who aren't familiar.
2. Identify topic. Ask each participant to write their assumptions.
3. As a group, review everyone's assumptions & brainstorm more.
4. For each assumption, ask key questions (e.g., "Why do we think this is true?" "How much evidence supports this assumption?"). Propose alternate assumptions that would significantly change perception.
5. For each assumption, evaluate whether it's sound, supported but with some caveats, or unsupported or questionable. Or, use 1-5 scale to rate confidence. For low-confidence assumptions, plan to gather additional info to help determine whether to keep them.
6. Assign each key assumption a place on a 2x2 matrix measuring high & low certainty, high & low potential impact. Low certainty/high potential impact assumptions are priority.
Analysis of Competing Hypotheses (ACH)
Method to determine most likely hypothesis among several
1. Identify hypotheses to consider.
2. Make list of evidence for & against each hypothesis.
3. Create matrix to evaluate whether each piece of evidence supports or refutes each hypothesis.
4. Conduct initial analysis to refine matrix.
5. Draw initial conclusions about likelihood of each hypothesis, focusing on disproving them.
6. Analyze how much of conclusion depends on single piece of evidence.
7. Report conclusions on likelihood of all hypotheses.
8. Identify situations in which analysis would need to be reevaluated.
Indicator Generation, Validation, & Evaluation
Method to generate, validate, evaluate list of indicators (IoCs or other observables) prior to analysis
1. Generate list of indicators that identify that particular activity is occurring or not.
2. Validate that each indicator can be observed (directly or indirectly), is reliable & specific. Rate according to likeliness to identify activity.
Use contrarian techniques (Devil’s Advocate, "What If" Analysis, Red Team Analysis) when wrong judgment would have serious consequences, or when you expect judgment to be contested. "What If" Analysis sees how other variables would change analysis. Red Team Analysis analyzes how adversary would think/act.
Futures Wheel: forecasting technique that predicts chain reaction
Target-centric analysis focuses on analyst-customer and analyst-collector relationships to build model of situation.
Target-centric analysis: Iterative process where info is gathered, analyzed to see if it helps answer questions. May generate new requirements. If more info is needed, collection & processing phases are repeated, info is disseminated. Analysts frequently ask customers if situation & needs have changed.
Analysis process
1. Determine what to analyze
2. Enrich data
3. Reference info from sharing relationships
4. Develop hypothesis
5. Evaluate key assumptions
Questions to determine what to analyze
• Why were we targeted? Analyze how they affected you, actions they took.
• Who attacked us? Analyze tactics, targets, operating hours, infrastructure used, etc.
• How could this have been prevented?
• How can this be detected? Analyze hashes, IP addresses, targets, tactics.
• Are there any patterns that can be identified? Analyze targets, infrastructure used, social engineering, etc.
Enrichment sources
• WHOIS (identify attacker infrastructure, compromised domains, researcher-run infrastructure & sinkholes)
• Passive DNS (understand nature of activity; pair with WHOIS)
• Certificates
• Malware (detection ratio, file details [fill knowledge gaps, indicate uniqueness], behavior [hash, installation destination, files it calls or relies on, automated actions])
• Biz ops: what's happening in network & org at time of incident
• User information: which users were targeted, attacker’s tactics
Share via ISACs, ISAOs, public/private partnerships, informal groups.
Evaluating key assumptions
1. Identify all key assumptions
2. Identify why assumption was made
3. Assess confidence in assumption
4. Identify how confidence rating was determined
5. Challenge each assumption, determine if it's true
6. Remove assumptions that aren't true or have low confidence
Biases
• Confirmation bias
• Anchoring bias
• Availability bias
• Bandwagon effect
• Mirroring (mirror-image bias)
Make judgment
1. Assess likelihood of hypothesis based on evidence. Focus on disproving rather than proving. Identify info that disproves.
2. Review info that led to judgment. Note if a single piece of evidence weighed most heavily, how confident you are in it.
3. Record conclusion on each hypothesis, citing evidence & confidence.
4. Articulate under what circumstances analysis would need to be reevaluated. State indicators.
Judgment formula: I/we assess with [low, moderate, high] confidence that [state judgment] based on [state evidence]. I/we will be monitoring [state indicators] to further support or refute this judgment.
Disseminate
Explicitly state customer’s goal/expectations for product.
Writing for leadership
• Focus on intel necessary to make biz decisions.
• Use intel to tell story of threat.
• Be brief, to the point. Start with executive summary.
Writing for technical customers
• Focus on improving detection, minimizing false positives
• Focus on data
• Be highly technical & descriptive, with references & research
• Back up products with machine-consumable products (e.g., STIX, YARA)
• Include method for accepting feedback, questions
Customer personas
• Name
• Title
• Key characteristics
• Department
• Reports to
• Background
• Technical acumen
• Preferred product
• Goals & challenges
• Values & fears
If you have many customers, use a few general personas. If you have few customers, use detailed personas for each. Or use detailed personas for key customers & general ones for others.
Actionability
• Provide info on adversary TTPs
• Ensure products that contain IoCs & signatures are easy for customers to use (e.g., Snort, YARA)
• Answer customer's questions
• Avoid broad descriptions of activity without meaningful details
• Don’t hinder copying info
• Avoid vendor-specific formats
• Don’t over-classify info
Customer characteristics
• Needs (problems, questions)
• Tech (tools)
• Maturity (skill level of team)
• Methodologies
Drafting
• Start with thesis statement; narrative format is natural for producers & customers
• Start with facts (times, indicators, concrete info)
Avoid
• Passive voice
• Uncommon terms & acronyms
• Leading or unobjective language
• Imprecision about known versus suspected
Consider visualizing data, adding graphics.
Writing structure
• What: issues, facts
• So what: why issues & facts are important to stakeholders
• Now what: actions customers can or should take
Intel product templates
Short-form products: 1-2 pages; address specific tactical or operational intel needs
Target package: actor description; useful for summarizing info from vendor reports; fact-based; don't get too far into estimative analysis, attribution
Campaign report: end-to-end breakdown of intrusion campaign; useful for identifying analysis gaps, which may lead to RFIs; useful for identifying missing response actions & bringing stakeholders up to speed
Intel estimate: provides context necessary for making strategic decisions (examples)
Use YYYYMMDD format to be easier to read & sort. Use 24-hour clock & consistent time zone (preferably UTC).
Use feedback to improve customer personas.
Weekly threat report: 1-page product focused on ongoing investigations & incidents, situational awareness (security news); good for variety of customers
5 questions to ask when writing products
• What is goal?
• Who is audience?
• What is proper length?
• Tactical, operational, or strategic?
• What language tone? Technical or nontechnical?
Strategic Intelligence
Strategic info: geopolitical, economic, historical, business
Analyze strategic intel with SWOT analysis, brainstorming, scrub down.
Scrub down (aka murder board): analyst presents findings to review board, which questions findings & analytic processes; helps identify biases, unvalidated key assumptions, analytic leaps not founded on evidence.
Anticipatory intel: studying situation & surrounding context, environment, & related situations to anticipate broad spectrum of possible future events & implications
Questions answered by strategic intel
• Which threats are most significant to org? Where should IR prioritize & focus?
• Which types of info are important to capture? What findings warrant brief to CISO or other execs?
• What situations may emerge as world changes?
• How do external situations (financial crises, global conflict, pandemics, etc.) impact security posture?
Building an Intelligence Program
Use 3rd-party intel & feeds for enrichment, not primary source.
Link new uses/tactics to existing indicators while weeding out indicators that are no longer valid.
July 10, 2022
I consider this a must read for Intelligence analysts or those new to the game.
March 11, 2018
A true pleasure to read. 9/10.
Read
September 2, 2021Skimmed through it mostly, for work. For insiders: this is from before ATT&CK became a (the) thing and thus it feels a bit dated. It also too often assumed a perfect situation within an organisation that seemed somewhat devoid from reality.
April 21, 2018
A most excellent book on the subject. The author does a good job at covering what you need to know if you want to use intel efficiently to address incident response. My team is currently developing its capability on the intelligence/IR front so I could definitely relate to what the author is presenting. I really enjoyed this book: a great read, and it felt very fresh: it talks intelligently about modern intel/IR.
The only two criticisms I have are that I would have liked the author to cover more tools/software related to the topic - and cover them with some depth. I am always interested in applying what I read, in particular with some open-source tools. Also: as another reader commented already, there were quite a few editing mistkaes err.. mistakes in the book. ;-) I think the editors rushed through this one.
Having said that, the quality of the book outweighs these two small criticisms.
The only two criticisms I have are that I would have liked the author to cover more tools/software related to the topic - and cover them with some depth. I am always interested in applying what I read, in particular with some open-source tools. Also: as another reader commented already, there were quite a few editing mistkaes err.. mistakes in the book. ;-) I think the editors rushed through this one.
Having said that, the quality of the book outweighs these two small criticisms.
March 4, 2022
This was a great overview of how the intelligence cycle and the incident response cycle come together. There was a lot of good information about starting an intelligence program, what kinds of products to implement, how to implement them, and WHY you should do threat intelligence to begin with. This book focused on big picture ideas and will likely remain relevant for a long time. I definitely would recommend it to a technical person shifting into CTI, or a SOC/IR person just wanting to know what the secret squirrels are doing.
Read
January 7, 2020Threat Intelligence and Incident Response are distinct realms, however there is a lot of interplay between the two and they are highly dependent on each other. When you're ready to expand your IR practice from whack-a-mole responses to looking at the big picture, this book is a great place to start on that journey.
December 13, 2020
Well-rounded introductory book on threat intelligence and incident response. I like good definitions and explanations of buzzwords, it's quite rare in infosec.
May 23, 2022
I found this to be a bit too obvious and high level to be truly helpful. It was a good coverage of incident response and attack models, but that could have been a long-form blog post.
May 8, 2023
Great book, easy to read & it has great examples
December 10, 2023
IDIR is a good intro to many of the processes and models that someone who comes from an incident response background could use to get into the intelligence cycle. I don’t think it goes particularly deep into any area and some of the concepts it touches on are a bit dated. Would recommend this as an intro to the field which gives folks plenty of next areas to focus on next for the intelligence reading.
Displaying 1 - 11 of 11 reviews