Interview Q&A — Methodology & Engagement Lifecycle
Phases 00–01: Engagement authorization, ROE, OPSEC, deconfliction, adversary emulation methodology, the three adversary lenses, the emulation plan, and the engagement lifecycle.
Q1: What is the difference between adversary emulation, a penetration test, and a red team exercise?
Answer:
Penetration test: a scoped, time-boxed assessment that attempts to find and demonstrate all exploitable vulnerabilities within a defined boundary. The goal is comprehensive coverage — find everything. The output is a prioritized vulnerability list. The adversary is generalized: "a sophisticated external attacker."
Red team exercise: a goal-oriented, stealth-focused engagement that evaluates the organization's detection and response capability against a specific adversary. The goal is not to find all vulnerabilities but to answer: "Would a real adversary achieve objective X without being detected?" The output is an assessment of detection gaps, response effectiveness, and dwell time. The adversary is specific: an emulated threat actor with known TTPs.
Adversary emulation: a subset of red team exercises where the attacker is modeled on a specific real-world threat actor — their documented tooling, techniques, infrastructure, and objectives. The emulation plan is built from threat intelligence (ATT&CK matrices, CTI reports, public IOCs) rather than general offensive capability. The goal is to answer: "Could FIN-X achieve their documented mission objective against us?"
The hierarchy: adversary emulation ⊂ red team ⊂ penetration test (in scope specificity and adversary-specificity). Mandiant engagements are typically adversary emulations or full red team exercises, not penetration tests.
Q2: Walk me through how you build an adversary emulation plan from threat intelligence.
Answer:
The plan is built in five steps:
1. Actor selection. Based on the client's industry, geography, and critical assets, select the most relevant threat actor from the ATT&CK Groups catalog and supporting CTI (Mandiant threat reports, ISACs, public advisories). For Meridian Freight International, this would be a financially motivated actor targeting logistics — mapped to a fictional FIN actor.
2. Technique catalog. From the actor's ATT&CK page and associated CTI, extract the confirmed technique list. Each technique gets its ATT&CK ID (T1055.003, T1558.003, etc.).
3. Tactic ordering. Order the techniques by the ATT&CK tactic lifecycle: Reconnaissance → Resource Development → Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → Command and Control → Exfiltration → Impact. This gives the engagement timeline.
4. Procedure definition. For each technique, define a procedure — the specific implementation that matches the actor's documented tool or behavior. Not all procedures are run; the engagement team selects based on the authorized scope and OPSEC profile.
5. Detection mapping. For each procedure, document the expected telemetry (data source, Sysmon EID, network event), the detection that should fire, and the detection gap that would allow the procedure to proceed undetected. This shapes the assessment questions.
The output is the emulation plan document: actor profile + technique list + procedure descriptions
- detection expectations. The plan is approved by the client and the engagement lead before execution begins.
Q3: What must a Rules of Engagement document contain, and why does each element matter?
Answer:
A well-formed ROE document contains at minimum:
Authorization statement: explicit written authorization from a named client authority (CISO, CTO, or designated authority) with their contact information. This is the legal foundation — without it, the engagement is unauthorized access. The authorization must name the specific organization and the specific systems.
Scope definition: the in-scope systems (IP ranges, domains, cloud accounts, application names), the out-of-scope systems (explicitly named exclusions — typically production payment systems, HR data, life-safety systems), and the rule for discovered out-of-scope findings (report, do not exploit further).
Authorized methods: the specific technique categories permitted (network scanning, exploitation, credential testing, social engineering, physical) and those explicitly prohibited (DoS, destructive techniques, data exfiltration beyond proof-of-concept).
Time and rate constraints: permitted operating hours (to reduce collateral impact), rate limits on scanning or authentication attempts.
Deconfliction protocol: the SOC contact (phone, email), the deconfliction token format (how the team identifies their actions as authorized to the SOC if detected), and the escalation path if the engagement causes unintended impact.
Data handling rules: what data may be collected (screenshots, credential hashes), how it is stored (encrypted, short retention), and what is prohibited (exfiltrating real PII, storing plaintext credentials).
Emergency stop contacts: who can call stop, and how, at any time during the engagement.
The ROE is signed before any work begins and referenced throughout the engagement as the authority document.
Q4: You are mid-engagement and the client SOC calls you directly saying they have detected
unusual activity. What do you do?
Answer:
This is the deconfliction scenario. The procedure:
Stop all active operations immediately. No additional actions on any in-scope system until the situation is resolved. An uncoordinated engagement action during an active SOC investigation could contaminate evidence, escalate the response, or create legal risk.
Verify the caller. The SOC contact is named in the ROE. Confirm you are speaking with the named contact (not a social engineering caller trying to extract engagement details). Use the out-of-band contact method established in the ROE (pre-agreed phone number, not an email from the detected host).
Provide the deconfliction token. The ROE specifies a deconfliction token or code phrase that the engagement team uses to identify their actions as authorized. Provide it. This lets the SOC distinguish the engagement team's traffic from a real adversary.
Share the timeline. Provide the SOC with the timestamp range of actions taken in the area of concern. This narrows their investigation.
Document everything. Log the call, what was shared, what the SOC observed, and the time. This goes into the deconfliction log (Lab 02, Phase 00) and the engagement report.
Resume only with explicit permission. After the SOC clears the deconfliction, resume operations. If the SOC wants to stop the engagement temporarily, comply.
The report outcome: the detection by the SOC is a finding in the report — it documents whether the detection was from a deployed detection rule (good), a human analyst observation (good), or accidental (a gap). It is positive signal regardless.
Q5: Explain the three adversary-analysis lenses (ATT&CK, Kill Chain, Diamond Model) and when
you use each.
Answer:
Cyber Kill Chain (Lockheed Martin): a 7-phase linear model — Reconnaissance → Weaponization → Delivery → Exploitation → Installation → Command & Control → Actions on Objectives. Its value is as a communication tool: it gives non-technical stakeholders a linear narrative of the attack. "We entered at phase 3 (Delivery) and progressed to phase 6 (C2) before being stopped." Its weakness: it is too linear — real adversaries iterate, move laterally, and restart phases. Use it for executive reporting and timeline narrative.
MITRE ATT&CK: a matrix of Tactics (the adversary's goal) × Techniques (how they achieve it), grounded in threat-intelligence evidence. Its value is specificity: every technique has a technique ID (T1058.003), a detection section, a data sources section, and mapped real-world actors who use it. Use it for emulation planning (building the technique list), detection gap analysis (which techniques lack a detection rule), and reporting (ATT&CK IDs in finding reports are universal reference points).
Diamond Model (Caltagirone, Pendergast, Betz): four vertices — Adversary, Capability, Infrastructure, Victim — with Activity Threads linking events into a campaign. Its value is for attribution and campaign analysis: connecting multiple intrusion events through shared infrastructure or capability identifies the same actor across incidents. Use it for CTI and forensic attribution, not for engagement planning.
In practice: use Kill Chain for executive communication, ATT&CK for technical planning and detection engineering, Diamond Model for CTI correlation and threat actor profiling.
Q6: Walk me through your OPSEC decision process when choosing how to execute a technique on
a live engagement.
Answer:
OPSEC assessment for an action is a five-factor analysis:
1. Noise level. How many events does this action generate? A Nmap SYN scan of 65,535 ports is extremely noisy (thousands of SYN packets, likely triggering IDS). An LDAP query that uses the same pattern as a normal admin tool generates one event. Prefer the action that generates the minimum number of events that still achieves the technique objective.
2. Novelty. Does this action look anomalous given the baseline of the environment? A PowerShell
Invoke-WebRequest in an environment where PowerShell is common is less novel than the same
command in an environment where PowerShell is disabled by group policy. The anomaly score is
relative to the environment's baseline, not absolute.
3. Blast radius. How many systems does this action touch? A technique that hits one host is better than one that touches fifty. Minimize lateral exposure.
4. Reversibility. Can the action be undone? Writing a file to disk leaves an artifact. Creating a user account leaves an audit trail. Prefer reversible actions (read > write > modify > create > delete).
5. Detection window. Does this action require leaving a persistent artifact, or is it transient? An in-memory payload that cleans up on process exit has a shorter detection window than a service installed to disk.
Scoring these five factors gives a rough OPSEC risk rating. High-risk actions require explicit approval from the engagement lead and documentation in the deconfliction log. Low-risk actions proceed under the general ROE authorization.
Q7: What is the Pyramid of Pain and how does it apply to engagement planning?
Answer:
The Pyramid of Pain (David Bianco) ranks adversary indicators by the cost to the adversary of changing them:
From bottom (easy to change) to top (hard to change):
- Hash values — trivially changed by recompiling
- IP addresses — changed by spinning up new infrastructure (hours)
- Domain names — registered in minutes
- Network/host artifacts — named pipes, mutex names, URI patterns; require reconfiguration
- Tools — changing tools requires new development or procurement; weeks
- TTPs (Tactics, Techniques, Procedures) — changing the fundamental approach requires redesign
Application to engagement planning:
A detection built at layer 1 (hash) is bypassed by the engagement team with a recompile. A detection built at layer 6 (TTP) — e.g., "any process creates a remote thread in a system process from a user-writable directory" — survives any tool change, any recompile, any infrastructure rotation.
When planning an engagement, we use the pyramid to evaluate the client's detection maturity:
- If their detections are all at layers 1–2 (hash/IP blocking), the engagement will demonstrate that an adversary trivially rotates their way through those controls.
- If their detections reach layers 5–6 (behavioral TTP detection), the engagement has to demonstrate whether the adversary can redesign their approach.
The engagement's OPSEC plan mirrors this: we choose tooling, infrastructure, and technique procedures that operate at layers 5–6 so we test the durable detections, not just the easy ones.
Q8: How do you scope a finding that is out of scope for the engagement?
Answer:
Out-of-scope findings arise in two ways: you encounter something genuinely outside the authorized scope while pursuing an in-scope objective, or you discover a critical issue on a system the ROE excludes.
The procedure:
Stop and document. The moment you recognize the finding is outside scope, stop any further actions on that system. Document what you observed (timestamp, system identifier, the observation) in the engagement log.
Consult the ROE. Most well-written ROEs have an explicit clause for out-of-scope findings: "If the engagement team discovers a critical vulnerability on an out-of-scope system, they will notify the engagement sponsor within X hours with a description sufficient to allow remediation, without exploiting the finding further."
Notify per the ROE protocol. Contact the designated client authority (usually the CISO or technical lead listed in the ROE) with the minimum information needed: what system, what observed vulnerability class, when discovered. Do not include exploit details or evidence that required accessing the out-of-scope system further.
Report in the appendix. The engagement report includes an "Out-of-Scope Observations" section listing any such findings. Each entry notes: what was observed, the basis for its being out of scope, and the notification made.
Do not exploit. Even if the finding would significantly advance the engagement objective, do not exploit an out-of-scope system. The authorization document is the only legal protection the engagement team has. Operating outside it removes that protection.