[FEATURE] Ability to record the status of mitigations

[nguforw]

Describe the feature

I would like to be able to capture the status of any mitigations that are documented within threat composer

Use Case

Mitigations are the "What are we going to do about it?" part of threat modelling. Whilst threat composer allows you to define mitigations, it does leave you with a fair amount of ambiguity regarding the actual status of the mitigations. If a mitigation is captured against a threat, the tool will indicate that the threat has been mitigated. But it fails to capture the fact that the mitigation may not actually have been implemented. This leads to a false sense of security.

Proposed Solution

Add a new "Status" field against each mitigation with the following values:

• Backlog
• In Progress
• Implemented

Other Information

No response

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

[jessieweiyi]

Hi @nguforw, Thanks for raising the feature request. We have added it into our backlog.

[dboyd13]

The following is a combined proposal for both the ask for Mitigation status (#61) and Threat status (#126) given the interplay between them.

---

Ask: @nguforw for your feedback (and anyone else reading this) on if the below proposal would address your use case.

---

Broad design philosophy and decisions

We propose the tool will:

1. Focus on capturing outcome states for threats (risks) and mitigations (actions). In our experience, the combination of interim states, their associated business logic and risk management making process is highly customer specific.
2. Have static system defined statuses to ensure portability of exports (.tc.json) between deployments, and to maximise the usefulness of any associated 'Insight dashboard' widgets that would be created.
3. Allow for a degree of organisational customisation of the status, support change of the status "title" and "description" shown in the UI. Note this is applicable only for self-hosted and deployed environments.
4. Have human readable (english only) values for the static system defined statuses that are human readable (english only) - example: threatIdentified, such that it useful for diffs/PRs for those that use version control methods (which we encourage)
5. Not track (or of keep an audit log of) status changes. Given the client-side nature of the tool, we do not see this tool as a viable alternative for a workflow tracking or ITSM tool. Additionally, we need to be frugal with our data storage requirements within browser storage, and ensure .tc.json diffs do not become "noisy".

Threat status

Mental model

• These are risks (not tasks)
• We capture outcomes (not the process of getting to the outcome, which would require us to have knowledge of the consuming customers processes for risk acceptance, tolerance, escalations etc).
• There is always an amount of residual risk acceptance (unless one avoids the risk) - hence we will not include a seperate status for "Risk Accept" it will form part of "Resolved"
• We consider "Resolved" and "NotUseful" as both being outcome state - so both will include the term "Resolved" in their system defined code threatResolved and threatResolvedNotUseful respectively.

Proposed statuses

Status in .tc.json export (constant)	UI Label (can be changed in build)	UI Description (can be changed in build)	Comments
threatIdentified	"Indentified" (default) - Other possible values you may want in your build could include: "Open", "Active" etc	"Potential threat has been identified"	All newly added threats get this status
threatResolved	"Resolved" (default) - Other possible values you may want in your build include: "Mitigated", "Complete" etc	"All agreed risk response actions (mitigation, transfer, avoidance, risk acceptance) have been completed aligned to our risk tolerance"	As noted above there is always amount of residual risk acceptance (unless one avoids the risk) - hence we will not include a seperate status for "Risk Accept" it will form part of "Resolved"
threatResolvedNotUseful	"Not Useful" (default) - Other possible values you may want in your build could include: "False positive" etc	"This threat is invalid / not applicable to our use system"	We consider "Resolved" and "NotUseful" as both being outcome state - so both will include the term "Resolved" in their system defined code threatResolved and threatResolvedNotUseful respectively.

UI placement

• Select within "Threat List" under "Metadata"
• Select within "Threat Editor" under "Metadata"
• Add "Threat status" column to Threat table (possible values to be the same as the labelsvalues - with the defaults being : Identified, Resolved, NotUseful)

Business logic

• All new threats get the threatIdentified status
• All imports of pre-feature .tc.json files do not have the status automatically set, and will have a runtime-only status of NotSet (see dashboard section for visibility)

Dashboard

• Pie Chart - Threat status distribution (threatIndentified, threatResolved, threatNotUseful, NotSet)
• Note: we did consider a dashboard widget that would aim to warn of threats marked threatResolved where at least one linked mitigation was not marked mitigationResolved - but given our proposed approach to not differentiate full risk acceptance of a threat versus a partial, this is not possible.

Mitigation status

Mental model

• These are tasks (work to do)
• We capture outcomes. It is assumed that the ITSM (IT Service Management) process is outside of this tool. However we do propose a broad "In-progress" status for those that choose to track course grained interim state within the tool.
• We do not have the notion of "Partially Resolved" as we see that as" Resolved" where the mitigation has been completed to an agreed scope. Meaning if partial... that was agreed. We capture the outcome only.

• We consider "Resolved" and "Abandoned" as both being outcome states - so both will include the term "Resolved" in their system defined code mitigationResolved and mitigationResolvedAbandoned respectively.

Proposed statuses

Status in .tc.json export (constant)	UI Label (can be changed in build)	UI Description (can be changed in build)	Comments
mitigationIdentified	"Indentified" (default) - Other possible values you may want in your build could include: "Idea", "Planned", "Backlog"	"Mitigation has been identified"	All newly added mitigations get this status
mitigationInProgress	“In-Progress" (default) - Other possible values you may want in your build include: "Doing"	"Mitigation is in-progress"
mitigationResolved	“Resolved" (default) - Other possible values you may want in your build could include: "Implemented", "Complete","Accepted" etc	“Mitigation has been completed to an agreed scoped”	We do not have the notion of "Partially Resolved" as we see that as" Resolved" where the mitigation has been completed to an agreed scope. Meaning if partial... that was agreed. We capture the outcome only.
mitigationResolvedAbandoned	"Abandoned" (default) - Other possible values you may want in your build could include: "Won't do" etc	"Will not be implementing this mitigation"

UI placement

• Select within "Mitigation list" under "Metadata"
• Add "Mitigation status" column to Mitigation table (possible values to be the same as the labelsvalues - with the defaults being : Identified, In-Progress, Resolved, Abandoned)

Business logic

• All new mitigations get the mitigationIdentified status
• All imports of pre-feature .tc.json files do not have the status automatically set, and will have a runtime-only status of NotSet (see dashboard section for visibility)

Dashboard

• Digit - Mitigation Progress (e.g. 5/10 complete) - ((mitigationResolved + mitigationResolvedAbandoned) / total (inc NoSet))
• Pie Chart - Mitigation status distribution (mitigationIdentified, mitigationInProgress,mitigationResolved, mitigationResolvedAbandoned, including NotSet)

[github-actions[bot]]

:tada: This issue has been resolved in version 1.0.57 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: