Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 Choosing the need"]
N2["35.2 Aims"]
N3["35.3 Requirements"]
N4["35.4 Test scenarios"]
N5["35.5 Ethics and data"]
N6["35.6 Risks"]
N7["35.7 Approval"]
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 the need"]
N2["35.2 Aims"]
N3["35.3 Requirements"]
N4["35.4 Test scenarios"]
N5["35.5 Ethics and data"]
N6["35.6 Risks"]
N7["35.7 Approval"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 Choosing the need]
|
v
[35.2 Aims]
|
v
[35.3 Requirements]
|
v
[35.4 Test scenarios]
|
v
[35.5 Ethics and data]
|
v
[35.6 Risks]
|
v
[35.7 Approval]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) propose a capstone project addressing a real SOC need; (2) define aims, requirements and evaluation; (3) plan ethics, data and risks; (4) obtain approval.
35.1 Choosing the need
From the campaign review and coverage work, Lucas chooses: "Improve detection of compromised student mail accounts, measured against authorised test scenarios."
The choice follows the evidence: the review showed s3310 went undetected for nearly nine hours, and coverage work found gaps in mail-related detection. Measuring against authorised scenarios means the project can show improvement without waiting for a real attack, and without touching real students' accounts. The need was confirmed with Dr. Kim, who agreed it was the SOC's top detection priority for the coming year. A capstone that matches a real priority is more likely to be used once the student has graduated.
35.2 Aims
Aim 1: combine the correlation and keyword-deletion rules into a tested detection package. Aim 2: add detection of mass internal mailing by newly risky accounts. Aim 3: measure detection rate before and after on a set of 20 authorised test scenarios.
Aim 2 addresses the behaviour that made s2047 dangerous: sending phishing to contacts from a trusted address. Aim 3 provides the evidence for the other two. Each aim can be judged separately, so a partial success, such as a good package with a weak new rule, would still be clear in the evaluation.
35.3 Requirements
Detect at least 80% of test scenarios; no more than three false alerts per week in production; alerts within 30 minutes of the triggering activity.
Each requirement has a reason. Eighty percent reflects that no rule set catches everything; three false alerts a week is what six student analysts can absorb without ignoring alerts; thirty minutes would have saved s2047 hours of sending. Stating reasons lets the evaluation discuss a near miss intelligently. Each requirement can be checked with a number at the end of the project, which is what makes it a requirement rather than a hope.
35.4 Test scenarios
Twenty scenarios are designed with Dr. Kim: each uses university test accounts and benign actions, such as a test sign-in from a test address and creation of a forwarding rule to a test mailbox. No real accounts are touched.
The scenarios vary in timing, rule type and sending volume. Dr. Kim's involvement ensures they are realistic and authorised; test accounts are clearly labelled so analysts and the service desk do not respond to them as real incidents. Each scenario is written down in advance with its expected detection.
35.5 Ethics and data
The project uses SOC data under existing policy; personal data is not taken off university systems; the report uses aggregates only.
Because Lucas is both an analyst and a researcher, the proposal states that capstone analysis uses only data the SOC already holds for security, under the same access rules. The university's ethics office confirmed that no further approval was needed since no new data about people is collected. Lucas's dual role is stated in the proposal so that the supervisor can watch for conflicts, for instance if Lucas were tempted to look at accounts beyond the scenarios to improve his results.
35.6 Risks
Test scenarios may not resemble real attacks; mitigated by basing them on the campaign's actual behaviours. False alerts may disturb analysts; mitigated by monitor-only mode first.
Other risks include delays in change approval and Lucas's exam period. The timeline below leaves weeks for analysis and report writing, so a delay in deployment would shorten the margin rather than the evaluation. Each risk names who watches for it. A risk register at the end of the proposal lists each risk, its likelihood, its effect on the project and the mitigation. Lucas reviews it at each fortnightly supervision meeting and records any changes.
35.7 Approval
Dr. Kim and Lucas's academic supervisor sign the proposal.
The two signatures cover different concerns. Dr. Kim approves the operational work, including tests in production and rule changes. The academic supervisor approves the project as assessed work, including the evaluation plan. Both receive later changes through the shared log described under supervision. Signing both before work begins also protects Lucas: if anyone later questions why test accounts were signing in from unusual addresses or creating forwarding rules, the signed proposal shows the activity was planned and authorised. Copies are stored with the capstone log and in the SOC's change records.
Timeline
Weeks 1–3: package rules and write tests. Weeks 4–5: design mass-mailing detection. Week 6: run before-scenarios. Weeks 7–8: monitor-only deployment. Week 9: run after-scenarios. Weeks 10–12: analysis and report.
Supervision
Lucas meets his academic supervisor fortnightly and Dr. Kim weekly. Each meeting ends with agreed next steps recorded in a shared log, so slippage is visible early.
Worked example
Lucas's evaluation plan: run the 20 scenarios against the existing rules (before) and against the new package (after), report detection proportions with confidence intervals, and record false alerts in production for four weeks.
Synthetic case. The proposal is invented.
Errors and limits
Proposals change; record changes with reasons.
Exercises
- EX103 — Three aims. State the three capstone aims. Rubric: 3 = package rules, add mass-mailing detection, measure before/after on 20 scenarios; 2 = two; 1 = one; 0 = none.
- EX104 — Test safety. How are test scenarios kept safe? Rubric: 3 = university test accounts, benign actions, no real accounts; 2 = partial; 1 = vague; 0 = none.
- EX105 — Requirements. List the three requirements. Rubric: 3 = ≥80% detection, ≤3 false/week, within 30 min; 2 = two; 1 = one; 0 = none.
Synthesis
A capstone proposal links a real need to measurable aims, safe tests and approved plans.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →