CTI Analyst Portfolio: Build a Safe, Reproducible Lab

A CTI analyst portfolio should let another person inspect how you reached a judgment. A dashboard screenshot can show a tool was running. A documented question, source ledger, reproducible dataset, and revised assessment show the work behind the answer.

You can build that evidence in an offline laboratory. You do not need to collect information about real victims, download live malware, or interact with command-and-control infrastructure. Synthetic data can expose important analytical problems: copied sources, contradictory claims, missing timestamps, ambiguous network activity, and decisions that depend on unresolved information.

In a 26 August 2026 Reddit discussion about moving from application security into CTI, participants discussed engineering work and analytical writing. That conversation is a useful prompt for a portfolio project, not evidence of what every employer requires. The lab below is designed to make those skills reviewable without promising a hiring outcome.

Define a skill you can demonstrate through an artifact

“Learn threat intelligence” is too broad to evaluate. “Normalize three source files while preserving provenance and rejecting invalid dates” produces an observable result. “Explain whether the available evidence supports credential exposure” produces an assessment a reviewer can challenge.

The NICE Workforce Framework, NIST SP 800-181 Revision 1, provides a vocabulary for tasks, knowledge, and skills. Use that distinction to describe your work. A course topic is not the same thing as a task you completed, and knowing a tool name does not demonstrate that you handled an ambiguous case correctly.

Choose a fictional stakeholder with a concrete need. For this lab, the incident lead at Boreal Workshop wants to know whether a reported credential lure requires additional account investigation. The answer must distinguish message delivery, recorded web requests, and confirmed credential submission.

Write the scope in the README: the exercise demonstrates source handling, analytical reasoning, and communication. It does not measure real-world detection performance, incident response readiness, or access to commercial intelligence. Honest limits make the work easier to assess.

Build an offline dataset with deliberate imperfections

Create a small dataset containing two fictional workstations, a few mail records, proxy events, and three source statements. Twelve to twenty rows are enough if each row contributes to a question. More volume is useful only when the task requires scale or performance measurement.

Use domains such as documents-boreal.example and documentation addresses such as 192.0.2.44. RFC 2606 reserves example domain names, while RFC 5737 specifies IPv4 blocks for documentation. These are values in the exercise data, not destinations to contact or addresses to assign to an operational network.

Introduce four imperfections intentionally. One source copies another. One event has an invalid date. One request could have come from an automated preview service. One record concerns a different time period than the rest. Keep a private answer key during your first attempt, then publish it with the completed exercise so a reviewer can inspect the design.

Mark every file and output as synthetic. Do not replace real victim names while retaining unique URLs, tokens, or exact operational details. Creating original records from scratch avoids implying that you investigated an organization or handled an incident you did not actually work on.

Organize the repository so a reviewer can start quickly

Keep the entry point short. State the question, describe the input, provide the reproduction command or manual steps, and link the final assessment. The reviewer should not have to inspect several notebooks to discover the purpose of the project.

A simple directory layout works:

README.md
data/raw/
data/expected/
method/
analysis/
results/
review/

Raw data contains the fictional inputs. Expected data holds the intended outcomes for validation. Method documents transformations and assumptions. Analysis contains the working evidence ledger. Results holds the deliverables. Review records criticism, corrections, and remaining limitations.

Separate generated files from source files and make their relationship clear. If a result depends on a manual decision, record that decision in a versioned file rather than leaving it inside an untracked notebook session. A fresh checkout should lead to the same result without relying on your memory.

Do not add infrastructure solely to make the repository look sophisticated. A local script and several plain-text files can demonstrate this task. Introducing containers, databases, and a dashboard is reasonable only when they help test a specific skill or make the work easier to reproduce.

Project one: preserve provenance through normalization

Source Alpha says that documents-boreal.example hosted a credential-themed page. Source Beta repeats Alpha's statement and includes Alpha's report identifier. Source Gamma describes a later benign demonstration page. Each statement has a source identifier, relevant time period, publication date, and acquisition date.

Write a transformation that normalizes the domain while retaining those fields. Preserve the original assertion and record the rule version used. If a date is invalid, send the record to an explicit rejected-record output with a reason. Do not replace it with the current time and make it appear fresh.

The expected result contains three source statements, one documented copying relationship, and two distinct origins. It does not contain three independent confirmations of maliciousness. The later benign page also does not automatically disprove the earlier claim because the statements refer to different times.

Show the accounting: input rows equal accepted rows plus rejected rows, with duplicates handled according to the declared rule. Give the reviewer one command or a short manual procedure to check that relationship. Preserve a rejected example so the failure path is visible.

The guide to building IOC pipelines covers the wider ingestion workflow. This portfolio project should remain focused on a narrower question: can someone trace a normalized value back to what was actually received?

Project two: write an assessment that can remain uncertain

The dataset records a message delivered at 08:37 and a proxy request at 08:39. It does not include a form submission, a browser history entry, or authentication logs. The analyst's task is to decide what this evidence supports and what collection would help next.

Start with separate observations. The message reached a fictional mailbox. The proxy recorded a request associated with a fictional workstation. A supplied page image depicts a credential-themed form at an earlier time. Each statement links to a specific row or artifact.

Then evaluate two explanations: a user browsed to the page, or an automated preview produced the request. Identify what would distinguish them. If that evidence is missing, the result can remain unresolved. A portfolio that honestly narrows a question demonstrates more judgment than one that forces a compromise verdict from incomplete records.

The Diamond Model investigation walkthrough provides a worked example of event records and rejected pivots. You can adapt its structure while keeping your own dataset and answer key explicit.

Explain the difference between the likelihood of an event and confidence in the assessment. The UK intelligence assessment guidance on uncertainty treats these as separate concepts. In your own assessment, identify the evidence gap that limits confidence and the observation that would change your judgment.

Use the source evaluation guide to structure the evidence review. Avoid treating a polished report, multiple copied feeds, or a numerical score as a replacement for independent support.

Project three: produce two outputs from the same evidence

Write a short SOC handoff and a short executive note. They should share the same underlying assessment while serving different decisions. If the uncertainty disappears when you shorten the document, the editing process has changed the meaning.

The SOC handoff identifies relevant accounts and devices, the search period, available artifacts, unresolved questions, and the next telemetry request. It should distinguish a hunt hypothesis from a confirmed incident. Include an owner and a stopping condition for the follow-up.

The executive note states the current business question, known exposure, what remains unconfirmed, and the decision requested. In this exercise, that may be approval to prioritize a short log review, with a scheduled update. Do not invent financial loss, attack frequency, or avoided incidents to make the note sound important.

The strategic, tactical, and operational threat intelligence guide explains audience differences. Your portfolio should make those differences observable in two finished artifacts, not merely repeat their definitions.

Ask a reviewer to compare the outputs sentence by sentence against the ledger. Every material claim should be supported, explicitly assessed, or identified as unknown. A concise executive note is successful when it preserves the decision and its constraints, not when it removes all technical caveats indiscriminately.

Make reproduction a documented property

Record the runtime and dependency versions required for the lab. Prefer a small dependency set and deterministic transformations. Avoid external lookups during reproduction: a live reputation result could change tomorrow and make the same input yield a different conclusion.

Store input hashes to detect accidental changes, but explain what they prove. A matching hash shows the reviewer used the same bytes; it does not establish that the data is accurate. The synthetic label and the source ledger remain necessary.

Include expected counts and a few meaningful assertions: the mirrored source is not independent, the malformed date is rejected, the ambiguous request remains unresolved, and both reports preserve the same uncertainty. These checks test the behavior the project promises to demonstrate.

If you use a language model for editing or summarization, disclose its role. Retain the reviewed output and the evidence mapping. Do not make a changing model response the only path to reproducing the assessment. A reviewer should be able to inspect the reasoning without an account on an external service.

Review the work with a rubric tied to consequences

Evaluate six aspects: the question's scope, provenance, reproducibility, analytical boundaries, audience usefulness, and correction handling. For each, describe a concrete pass condition and a material failure. Avoid combining them into a decorative percentage that hides an important weakness.

A provenance pass means the reviewer can trace every conclusion to its inputs. A failure is counting Beta as independent from Alpha. An analytical pass means the proxy request remains distinct from credential submission. A failure is claiming a compromised account without the required evidence.

For audience usefulness, ask whether the recipient can identify the next action, owner, and decision deadline. For correction handling, introduce a revised source statement and check whether the affected conclusions can be found and updated. The guide to reusing threat report evidence provides related workflow context.

Keep reviewer comments in the repository and respond with changes. A documented disagreement can be valuable when it explains a tradeoff or missing information. Do not manufacture a peer review or imply that a tool-generated review came from an independent human analyst.

Show one correction and its downstream effect

Suppose the first version accidentally counted Beta as a separate confirmation. Correct the source relationship, revise the confidence assessment, and update both audience outputs. Record precisely which conclusions changed and which remained supported.

Then add a fourth source that copies Beta. The regression check should still count one origin for that chain. This small addition demonstrates that you corrected the rule, rather than manually editing one visible result.

Keep the earlier version available with a clear correction note. Explain how the error was found and how the revised method prevents recurrence within the tested scope. Do not invent an anecdote about discovering the mistake under pressure; the repository already provides the evidence of learning.

The same approach applies to dates, unsupported mappings, and overconfident language. A portfolio becomes more credible when it shows the ability to change an assessment without hiding its history.

Publish a bounded, honest demonstration

Before publishing, inspect the repository for credentials, personal metadata, copied proprietary material, and unintended live URLs. Confirm that the dataset and answer key are synthetic and that any third-party material has appropriate attribution and reuse terms.

State what you authored, which tools helped, and what the exercise does not demonstrate. Keep screenshots secondary to inspectable artifacts. A reviewer should be able to understand the case even if an image fails to load or the original development environment no longer exists.

For an interview or portfolio walkthrough, begin with the decision question. Show one source relationship, one uncertain conclusion, and one correction. Explain why each changed the output. That gives the discussion a concrete basis without claiming experience beyond the lab.

The OSINT guide for SOC analysts can support later work with authorized public sources. This first laboratory should remain offline. When you eventually add real, permitted indicator enrichment, keep it as a separately scoped project with its own provenance, privacy review, and reproducibility limits.