Chapter 35 — Capstone proposal | Bachelor's Threat intelligence and OSINT

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Choosing a topic"]
  N2["35.2 Structure"]
  N3["35.3 Scope"]
  N4["35.4 Success measures"]
  N5["35.5 Data and ethics"]
  N6["35.6 Risks"]
  N7["35.7 Supervision agreement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Choosing a topic"]
  N2["35.2 Structure"]
  N3["35.3 Scope"]
  N4["35.4 Success measures"]
  N5["35.5 Data and ethics"]
  N6["35.6 Risks"]
  N7["35.7 Supervision agreement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Choosing a topic]
    |
    v
[35.2 Structure]
    |
    v
[35.3 Scope]
    |
    v
[35.4 Success measures]
    |
    v
[35.5 Data and ethics]
    |
    v
[35.6 Risks]
    |
    v
[35.7 Supervision agreement]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) write a capstone proposal for a CTI project; (2) define scope, deliverables and success measures; (3) plan data handling and ethics; (4) identify risks to completion.

35.1 Choosing a topic

Good capstones solve a real, bounded problem with lawful data. Amara proposes "A lookalike-domain early-warning process for HCHT using certificate-transparency data", which is passive, useful and achievable in one semester.

Amara chooses the topic because her internship showed lookalike domains appearing in phishing aimed at HCHT, and because certificate logs are public and can be searched without touching any suspicious site. The topic also fits an existing gap in HCHT's controls, so the results could be used. Her supervisor agrees it is suitable.

35.2 Structure

Background (the problem and why it matters), aim and questions, method, data and ethics, deliverables, timeline, risks and evaluation plan. Two to three pages is enough.

Amara drafts each part in a page or less and keeps the risks and evaluation plan specific to her project. Her supervisor reads the first draft and asks her to narrow the aim from "detect lookalike domains" to "produce a weekly list of likely lookalikes for analyst review". The narrower aim can be achieved and evaluated within the semester.

35.3 Scope

State what is in and out. In: generating candidate lookalike names, matching them against public certificate logs, triage rules, a weekly report. Out: contacting domain registrars, takedowns, active scanning of found sites.

Takedowns are left out because they involve legal judgment and contact with third parties, which belong to HCHT's security lead. Active scanning is out because it would touch infrastructure that may belong to attackers or innocent parties. Writing these limits into the proposal protects Amara and helps reviewers see that the project is achievable and lawful.

35.4 Success measures

Measurable: number of HCHT-relevant lookalikes found in a pilot month; share confirmed malicious or suspicious by the supervisor; analyst time per week. Set targets modestly.

Amara chooses modest targets because the pilot month may contain few real lookalikes. If none are found, the analyst time measure still shows whether the process is practical, and the proposal says how such a result will be interpreted. Each measure has a definition and a data source, so the evaluation can be done without arguing about what counted.

35.5 Data and ethics

Certificate-transparency data is public, but results may include domains registered by individuals for innocent reasons. Store only domain names and certificate dates; do not research registrants personally. Obtain supervisor and university approval.

The proposal explains how found domains will be handled: they are passed to the supervisor for a decision, not investigated further by Amara. Results are stored on HCHT systems and deleted at the end of the project, except those the supervisor keeps for operational use. The university ethics committee confirms the project needs only light review because it uses public data about domains, not people.

35.6 Risks

Data volume may exceed laptop capacity; many false positives may overwhelm triage; the supervisor may be unavailable during incidents. Each risk gets a mitigation.

Amara plans to filter certificate data by name before downloading full records, which reduces volume. Triage rules will be tuned on the first week's results. If the supervisor is busy with an incident, the weekly report waits and the project timeline allows two missed weeks. Each mitigation has a trigger, so she knows when to act.

35.7 Supervision agreement

Agree meeting frequency, how feedback will be given and what happens if HCHT priorities change mid-project. A one-paragraph agreement signed by student, academic tutor and workplace supervisor prevents later misunderstanding about ownership of results and what may be published.

Amara's agreement says that HCHT owns the operational results, the university may publish the method and anonymised findings, and Amara may use the work in her thesis. It names monthly meetings with the workplace supervisor and fortnightly ones with the tutor. If HCHT's priorities change, the three agree a revised scope within two weeks and record it.

Timeline planning

Break the semester into milestones: literature and rules in weeks one to three, pilot generation in weeks four to six, weekly checks in weeks seven to ten, analysis and writing afterwards. Build two buffer weeks for illness or incidents.

Worked example

Amara's tutor challenges her success measure "find all lookalikes". It is unmeasurable. She replaces it with "list candidate names from 20 generation rules, check them weekly for one month, and report precision as confirmed suspicious divided by flagged".

Synthetic case. The proposal is invented.

Errors and limits

Proposals change; record changes and reasons in an appendix.

Exercises

EX103 — Out of scope. Name two activities Amara excluded and why.
Show marking criteria
Rubric: 3 = contacting registrars/takedown/active scanning, with reason (authority, legality); 2 = two without reasons; 1 = one; 0 = none.
EX104 — Measurable success. Why is "find all lookalikes" a poor success measure?
Show marking criteria
Rubric: 3 = unknowable total; unmeasurable; replace with precision/defined checks; 2 = partial; 1 = fine; 0 = none.
EX105 — Registrant privacy. What data rule protects people who register similar domains innocently?
Show marking criteria
Rubric: 3 = store only domain names/dates; no personal research on registrants; 2 = partial; 1 = vague; 0 = none.

Synthesis

Choose a bounded, lawful problem, scope it, measure success realistically and plan ethics and risks.

Continue studying — chapter 35 of 40

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →