482
B. Russell
Fig. 10.3 Threat modeling
flow
• Damage – what amount of damage (physical, monetary, reputation) would occur?
• Reproducibility – can the attack be reproduced easily?
• Exploitability – how difficult is it to execute the attack?
• Affected users – how many customers or stakeholders will be impacted?
• Discoverability – is the threat well known? Can anyone discover it?
Once risks are quantified and prioritized, leaders can choose to mitigate the risk,
defer the risk, or even to accept the risk.
10.3.1.2 Documenting Cyber Security Requirements
Identifying the specific security user stories to include in your backlog requires an
analysis of the specific threats faced by your system. Once understood, engineers
can begin to document the cyber security requirements that must be satisfied to
secure the system. Determining when to spend time on specific requirements can
be difficult though in an agile development process, since agile projects focus on
showcasing potentially shippable products at the end of each sprint. Some might
consider cyber security requirements as a “tax” on system development, with a
handful of these requirements being added to each sprint backlog. A better approach
is to review and categorize all cyber security requirements during the creation
and/or update of the product backlog and release roadmap. Microsoft’s Agile SDL
provides guidance on handling security requirements within the cadence of an agile
development. Three types of requirements are defined and aligned to the sprint
planning process.
Précédent

- 485/647

Suivant