Reviewing and updating a threat model

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. A school app adds a new feature that lets students upload photos. What should the team do with their threat model?

A Review and update it to cover the new feature

B Leave it alone because it was finished last term

2. Which statement about a threat model is true?

A It is written once and never needs to change

B It is a living document that is updated when things change

3. Your team starts using a new third-party library in its code. What is the best next step?

A Add the dependency to the threat model and check for new risks

B Ignore it because the library was written by someone else

4. A team adds multi-factor authentication to protect logins. What should they do with the risk ratings in the threat model?

A Re-rate the risks to see how much the control lowered them

B Keep the old ratings because controls never change risk

5. Which of these is a good reason to review a threat model?

A The team changed the colour of the app's buttons

B A new type of attack is reported against similar systems

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1threat model review		AAfter adding a control, the risks it affects should be re-rated, because their likelihood or impact may have dropped.
2Re-rate: SQLi likelihood High -> Low		BReviewer: 'You missed a trust boundary at the API'
3Adding a new dependency changes the system, so the model must be reviewed for new threats		CUpdating a risk rating after a new control, such as input validation, has been added
4A peer review has someone else check the model for missed threats and wrong ratings		DChange: add payment library -> Review: add supply chain threat
5Model written in Term 1. Next review: never, it is finished.		EA threat model is never finished. It must be reviewed whenever the system, users or threats change.
6Added MFA to login. Risk ratings left the same.		FChecking and updating a threat model whenever the system, its users or the known threats change

Definitions

threat model review

Fill in the Blanks

Complete each line of code by filling in the missing parts.

IF newFeature THEN ______(threatModel)

__ controlAdded THEN rerate(risks) log("risks re-rated")

IF systemChanged __ threatsChanged THEN review(threatModel) END IF

FOR EACH risk __ threatModel peerCheck(risk) END FOR

model.version <- model.version _ 1

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A IF new_feature = true THEN

B delete_threat_model()

C update_risk_ratings()

D END IF

Question 2

A new_dependency ← true

B IF new_dependency THEN

C list_new_threats()

D update_user_manual()

E END IF

Question 3

A IF control_added = false THEN

B rerate_risks()

C save_model()

D END IF

Question 4

A model ← load_threat_model()

B reviewer ← get_peer()

C feedback ← author.review(model)

D apply(feedback)

Question 5

A old ← likelihood * impact

B likelihood ← likelihood + 1

C new ← likelihood * impact

D DISPLAY old, new

Answer Key

Reviewing and updating a threat model

Section A: Quick Questions

A — Review and update it to cover the new feature

B — It is a living document that is updated when things change

A — Add the dependency to the threat model and check for new risks

A — Re-rate the risks to see how much the control lowered them

B — A new type of attack is reported against similar systems

Section B: Match the Pairs

threat model review → Checking and updating a threat model whenever the system, its users or the known threats change

Re-rate: SQLi likelihood High -> Low → Updating a risk rating after a new control, such as input validation, has been added

Adding a new dependency changes the system, so the model must be reviewed for new threats → Change: add payment library -> Review: add supply chain threat

A peer review has someone else check the model for missed threats and wrong ratings → Reviewer: 'You missed a trust boundary at the API'

Model written in Term 1. Next review: never, it is finished. → A threat model is never finished. It must be reviewed whenever the system, users or threats change.

Added MFA to login. Risk ratings left the same. → After adding a control, the risks it affects should be re-rated, because their likelihood or impact may have dropped.

Section C: Definitions

threat model review — Checking and updating a threat model whenever the system, its users or the known threats change, for example after a new feature, a new dependency or a new control.

Section D: Fill in the Blanks

IF newFeature THEN review(threatModel)

IF controlAdded THEN rerate(risks)
    log("risks re-rated")

IF systemChanged OR threatsChanged THEN
    review(threatModel)
END IF

FOR EACH risk IN threatModel
    peerCheck(risk)
END FOR

model.version <- model.version + 1

Section E: Spot the Error

B — A new feature changes the system, so the threat model must be reviewed. It should call review_threat_model(), not delete the model.

D — After finding the threats a new dependency brings, we update the threat model. Updating the user manual does not record the new risks. It should be update_threat_model().

A — Risks should be re-rated when a control HAS been added. The condition should be control_added = true.

C — In a peer review, a different person checks the model. The reviewer should do the review, so it should be reviewer.review(model), not author.review(model).

B — A new control makes an attack less likely, so the likelihood should go down. It should be likelihood - 1, not + 1.