How to become a CTI analyst

Most guides to this career describe a tool list. That is not what gets people hired, and it is not what the job is. Cyber threat intelligence is an analysis and communication discipline with a technical floor. You need enough security engineering to read the evidence, and enough tradecraft to say what it means without overreaching.

This page is the map. Each section links to the deeper material, and every framework named here shows up in the interview simulator, so you can test whether you actually know it rather than whether you have read about it.

What the job actually is

A CTI analyst answers questions that someone else has to make a decision about. That framing matters, because it separates intelligence from the two things it gets confused with:

• It is not a feed. A list of indicators with no assessment attached is data. Intelligence is data that has been collected against a requirement, evaluated, and interpreted for a specific audience.
• It is not incident response. IR answers "what is happening in our network right now." Intelligence answers "who would do this to us, how do they operate, and what should we change." The two feed each other constantly, but the products are different.

A realistic week looks like: triage what came in overnight from your collection sources; enrich two or three clusters of activity that matter to your organisation; map behaviour to ATT&CK and hand the gaps to detection engineering; write one finished product; brief someone who does not work in security; and spend an uncomfortable amount of time deciding whether you actually believe your own assessment.

The three altitudes

Intelligence is produced at three levels, and job descriptions blur them constantly. Knowing which one a role is really asking for is the single most useful thing you can work out before an interview.

Most entry roles are tactical with some operational work. Most disappointing intelligence functions are ones producing tactical output for a strategic audience, or vice versa.

The skills that actually get tested

Technical floor

You do not need to be a reverse engineer. You do need to not be lost when the evidence is technical:

• Networking: DNS thoroughly, TLS and what a certificate actually proves, HTTP, proxies, and how beaconing looks in flow data.
• Operating systems: the Windows process tree, services, scheduled tasks, the registry autostart locations, and the Linux equivalents. You should be able to look at a parent-child process chain and say why it is odd.
• Logging and telemetry: what EDR, Sysmon, proxy and identity logs each can and cannot tell you. Knowing the blind spots is worth more than knowing the query syntax.
• Malware behaviour: enough to triage. Persistence, injection, C2 patterns, packing, and how to get a configuration out of a sample or a sandbox report. See malware triage for CTI.
• One query language: KQL, SPL, or plain SQL. Which one matters far less than being able to think in terms of what data would falsify your hypothesis.

Intelligence tradecraft

This is the part self-taught candidates most often skip, and it is the part that separates a good analyst from someone who reads threat reports.

• Requirements and the intelligence cycle — being able to turn "are we at risk from ransomware" into something collectable.
• Source evaluation — reliability and credibility as separate judgements, and spotting circular reporting where four sources are one source.
• Structured analytic techniques — Analysis of Competing Hypotheses and key assumptions checks, used properly rather than named.
• Estimative and confidence language — the difference between how likely something is and how confident you are in that estimate. Conflating these is the single most common tradecraft error in interviews.

Writing

You will be judged on your writing more than anything else, and it is the least practised skill in the candidate pool. The bar is: BLUF, no hedging that hides a judgement, no jargon the reader has not been given, and an explicit "so what" for a named audience. See writing intelligence reports.

A staged roadmap

Assumes you are starting with general IT or security familiarity and can put in steady part-time hours. Compress or stretch it to fit, but keep the order — the later stages depend on the earlier ones.

Stage 1 — months 0 to 3: build the floor

1. Networking and OS internals to the depth listed above. Build a small lab: a Windows VM with Sysmon and a Linux box, and generate your own telemetry.
2. Learn ATT&CK properly — the tactic set, the technique/sub-technique structure, and the Groups and Software pages. Do not memorise IDs; learn to navigate.
3. Read the three foundational models: the Diamond Model, the kill chain, and the Pyramid of Pain.
4. Start reading finished intelligence daily. Vendor reports, CISA advisories, national CERT publications. Note the structure, not just the content.

Stage 2 — months 3 to 9: produce something

1. Pick a single intrusion set and track it for the whole period. Build your own profile: TTPs mapped to ATT&CK, infrastructure patterns, targeting, and the open questions you cannot resolve.
2. Learn collection: passive DNS, certificate transparency, scan data, malware repositories. See OSINT for CTI, including the operational security of collecting at all.
3. Stand up MISP or OpenCTI and actually use it. Learn STIX and TAXII by pushing real data through them rather than reading the specification.
4. Write one finished product a month and get it critiqued. This is the portfolio.
5. Practise the tradecraft under pressure — mock interviews are the cheapest way to find out that you cannot explain the Diamond Model out loud.

Stage 3 — months 9 to 18: convert to a role

1. Move sideways if you can. A SOC seat is the highest-percentage route into CTI, because it gives you telemetry fluency and internal credibility. See the SOC-to-CTI interview track.
2. Turn your tracking project into public writing. A well-reasoned blog post with explicit confidence language is worth more to a hiring manager than a certificate.
3. Add detection work: turn your TTP research into hunt hypotheses and Sigma rules. See from intelligence to detection.
4. Now consider a certification, if the money is not yours or the job market you are in gates on them.

Certifications: what is worth it

Certifications open HR filters. They do not make you an analyst, and interviewers in this field are unusually good at spotting a certificate without the underlying skill. Prices change constantly, so check current figures directly with the provider.

• GIAC GCTI (paired with SANS FOR578) is the closest thing to a standard for the discipline itself. Expensive; excellent if an employer pays.
• CREST CPTIA / CRTIA carry real weight in the UK and parts of Europe, less elsewhere.
• Vendor and free options — MITRE ATT&CK Defender, arcX's free CTI foundation course, and Blue Team Level 1 for the technical floor — give you most of the learning at a fraction of the cost.
• Generalist certs (Security+, CySA+) help with HR filters for the first role and are close to irrelevant after it.

A fuller breakdown is in CTI certifications compared.

What the interview looks like

A typical loop for an analyst role has four parts. Each is practised separately in the simulator:

• Screening — motivation, what you read, whether you understand what intelligence is for.
• Technical — networking, host artefacts, malware behaviour, and the frameworks. Expect to be asked to apply one, not define it.
• Scenario or case — the differentiator. You are given a partial picture and asked what you do next, what you would collect, and what you would tell the business. Interviewers score your process: triage order, pivots, hypothesis discipline, and whether you reach past your evidence.
• Behavioural — how you handle being wrong, disagreement with a stakeholder, and pressure to name an actor before the evidence supports it.

The mistakes that cost people offers

• Naming an actor too fast. Jumping to "this is APT29" from an indicator overlap is the fastest way to fail a scenario round. Cluster first, name later, hedge always. See attribution and its limits.
• Confusing probability with confidence. "High confidence it is likely" means nothing unless you can explain that these are two different axes.
• Reciting a framework instead of using it. Nobody wants the four vertices of the Diamond Model recited. They want you to pivot across them on the evidence in front of you.
• Indicator thinking. Treating a hash or an IP as the deliverable rather than the starting point.
• No audience. Answering "how would you report this" without ever saying who is reading it.

Where to go next

If you are starting cold, read MITRE ATT&CK for CTI and then analytic confidence language — those two cover the largest share of what interviews actually probe. If you already have the theory, go straight to a mock interview and find out where it breaks under questioning.