OpenCyber Academy
Postgraduate · Chapter 11 · English
Course code: OCA-152Chapter 11: OCA-152-C011

Chapter 11 — Applied project

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 11 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 The project"]
  N2["11.2 Baseline"]
  N3["11.3 Actions"]
  N4["11.4 Results"]
  N5["11.5 Stakeholders"]
  N6["11.7 Reporting"]
  N7["Project governance"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 The project"]
  N2["11.2 Baseline"]
  N3["11.3 Actions"]
  N4["11.4 Results"]
  N5["11.5 Stakeholders"]
  N6["11.7 Reporting"]
  N7["Project governance"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]
[Learning outcomes]
    |
    v
[11.1 The project]
    |
    v
[11.2 Baseline]
    |
    v
[11.3 Actions]
    |
    v
[11.4 Results]
    |
    v
[11.5 Stakeholders]
    |
    v
[11.7 Reporting]
    |
    v
[Project governance]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) plan and carry out an applied project in the workplace; (2) measure outcomes against a baseline; (3) manage stakeholders; (4) report results and limits.

11.1 The project

Hannah's applied project: reduce the number of third-party SDKs in the mobile app and cut the time from SDK data-collection change to detection to under three days, across all Northbridge apps.

The two aims are linked: fewer SDKs means fewer updates to review, and faster detection reduces the harm from the changes that do get through. The three-day target came from the February detection time of nineteen days and the median of two days seen in the pilot. Dr Menon approves the plan, and the CISO agrees to sponsor the work across all apps. The project runs for nine months, matching the period reported in the results.

11.2 Baseline

At the start: 22 SDKs across apps; February detection time 19 days; no SDK register.

These figures come from the February incident record and from a manual count Hannah's team made across the apps' build files. Without a register, the count of twenty-two had to be checked by hand, and two SDKs were found that nobody could name an owner for. Hannah records the baseline in the project plan before any action starts, so the results can be compared fairly. Dr Menon reviews the baseline method before the project begins.

11.3 Actions

Diff harness rollout (chapter 7), isolation of two sensitive SDKs, contract clauses, and an SDK reduction review asking each team to justify each SDK.

The reduction review asks each team three questions about every SDK: what it is used for, whether another SDK already provides it, and what data it processes. Isolation work is done by the platform team, while contract changes follow procurement's renewal calendar. Hannah tracks each action on the project board with an owner and a date. Progress against each action is reviewed monthly with the CISO, who sponsors the project.

11.4 Results

After nine months: 15 SDKs (seven removed or replaced with in-house code); median detection of planted changes 2 days across all teams; register complete; two real vendor data-collection changes detected and reviewed before release.

The detection figure comes from planted changes, so it measures the same thing as the pilot, now across every team. The two real detections, including the crash-reporting change described in the worked example, show the diff catching changes outside the study. Hannah compares each figure with the baseline recorded before any action started.

11.5 Stakeholders

Product owners worried about losing analytics features; Hannah worked with them to replace duplicated SDKs first, keeping features.

Replacing duplicates first meant no team lost a feature it relied on, which built goodwill for the harder cases later. Where a team wanted to keep an SDK that duplicated another, it had to state why in the register, and the CISO decided on the few disputed cases. Product owners were invited to the monthly review, so they saw the project's progress and its costs together.

11.6 Limits

Planted changes test detection, not every real-world variation; nine months is short; the cost of in-house replacements will continue.

Hannah states these limits in both the academic report and the board summary, so neither audience reads the results as proof of lasting change. She also notes that the in-house replacements now need maintaining, with their own security updates and owners. A follow-up measurement after a further year is proposed, using the same planted-change method. She lists which conclusions would change if that measurement showed detection had slowed again.

11.7 Reporting

A project report for Calder College and a summary for Northbridge's board.

The college report sets out the method, data, evaluation and limits in academic form, with references and the lab scripts as appendices. The board summary is two pages: the problem, what was done, what changed, what remains uncertain, and what it costs to keep going. Dr Menon reads both before submission, checking that the summary makes no claim the report does not support. The board receives its version at the next quarterly meeting.

Project governance

A steering group of the CISO, the head of mobile and the privacy lead meets monthly to review progress against milestones and resolve blockers. Hannah reports risks honestly, including a two-month delay in isolating one SDK because the vendor changed its interface. The steering group agrees to accept the delay rather than rush the work.

Closure

The project closes with a handover to the SDK register owner.

Worked example

One of the real changes detected was a crash-reporting SDK that began uploading device names, which can contain customers' real names. The update was held, the vendor was asked to change it, and a configuration setting turned the feature off.

Synthetic case. Project data are synthetic.

Errors and limits

Reductions may reverse as new features arrive; keep the justification step for new SDKs.

Exercises

Synthesis

Applied projects deliver measurable change with honest limits and stakeholder care.

Continue studying — chapter 11 of 12

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →

Worked answers

EX051. Reduce SDKs and cut detection time for data-collection changes to under three days.

EX052. 22 SDKs, 19-day detection and no register.

EX053. 15 SDKs, 2-day median detection, a complete register and two real changes caught.

EX054. By replacing duplicated SDKs first while keeping features.

EX055. Device names can contain customers' real names.