add categories to threats

[nineinchnick]

Add a categories field to threats so custom threat libraries can use any threat taxonomy.

Formatted the threats.json file using jq so it has consistent identation.

[ghost]

Congratulations 🎉. DeepCode analyzed your code in 2.696 seconds and we found no issues. Enjoy a moment of no bugs ☀️.

👉 View analysis in DeepCode’s Dashboard | Configure the bot

[adamshostack]

Categories implies exclusivity, and STRIDE is bad at that. Maybe "type of threat" or "tags"?

[nineinchnick]

TBH I choose categories because I was recently looking at https://github.com/microsoft/threat-modeling-templates/blob/master/default.tb7#L2520
I'm ok with types. Throwing in threats in there looks reduntant. Tags seem too generic and I'd remove STRIDE from threats.json. But I'm also ok with that as I'm using a custom threats db.

@izar has the final word so WDYT?

[izar]

I'd prefer we keep pytm methodology-agnostic, avoiding nomenclature that's closely related to one methodology or another.

[nineinchnick]

So how should I proceed? Remove changes to threats.json and somehow rename the new field?

[nineinchnick]

I removed all default categories but left the field named like that.

[izar]

what values would go there? I don't know if i like adding fields just because.

[nineinchnick]

Yeah, it only made sense when actually adding some categories in the threat db. I'm looking at CAPEC right now and since it's actually a hierarchical db, not a flat one, there's no existing field there that we could use to group the threats somehow. BTW does the prefixes in IDs mean anything? If yes, maybe we could use those as categories?

When going through all threats I did get a feeling some are very generic and some very specific. Looks like they've been picked from different levels of CAPEC.

BTW2 "Likelihood Of Attack" is also unused :-P

If we can't find anything to put into categories I'm fine with closing this for now and getting back to it later when I'll have other contributions to the threat db itself.

[izar]

I'm working on getting the likelihood removed :) I need to go over the SIDs again, but for example, "INP" stands for "input", so they are categorized already. Just need to remember what the categories where...

…

--izar https://keybase.io/izar/chat

On Tue, Mar 17, 2020 at 1:22 PM Jan Waś ***@***.***> wrote: Yeah, it only made sense when actually adding some categories in the threat db. I'm looking at CAPEC right now and since it's actually a hierarchical db, not a flat one, there's no existing field there that we could use to group the threats somehow. BTW does the prefixes in IDs mean anything? If yes, maybe we could use those as categories? When going through all threats I did get a feeling some are very generic and some very specific. Looks like they've been picked from different levels of CAPEC. BTW2 "Likelihood Of Attack" is also unused :-P If we can't find anything to put into categories I'm fine with closing this for now and getting back to it later when I'll have other contributions to the threat db itself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC2BAI2QJ4WAWABRXIK5OTRH6WUHANCNFSM4LLDECNA> .

[nineinchnick]

So if we can fill out the categories based on IDs, this would be more explicit and allow grouping threats by categories. Given the high number of threats and broad conditions this should help to manage findings.

Note, #86 is also to allow grouping but by element. This breaks up a potentially very long list of findings in the report.

[nineinchnick]

I'd like to use values from the Scope column in the table in Consequences section.

https://capec.mitre.org/data/definitions/98.html

[nineinchnick]

I checked and both CAPEC and CWE defines this scope field. CAPEC describes it as:

The Scope identifies the security property that is violated,

CWE schema has this description:

The ScopeEnumeration simple type defines the different areas of security that can be affected by exploiting a weakness.

Possible values:

• Confidentiality
• Integrity
• Availability
• Access Control
• Accountability
• Authentication
• Authorization
• Non-Repudiation

Those look similar to properties associated with STRIDE items:

Threat	Desired property
Spoofing	Authenticity
Tampering	Integrity
Repudiation	Non-repudiability
Information disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

So how about we name it properties? Now we can add a meaningful description to the field in the Threat class :-)

[izar]

Having all context, "properties" makes sense, BUT without it... too generic. From an educational perspective, I think "Security Fundament" would be appropriate as it describes the principle that is addressed, but then I question what the final use of it would be.

…

--izar https://keybase.io/izar/chat

On Fri, Apr 10, 2020 at 8:18 AM Jan Waś ***@***.***> wrote: I checked and both CAPEC and CWE defines this scope field. CAPEC describes it as: The Scope identifies the security property that is violated, CWE schema has this description: The ScopeEnumeration simple type defines the different areas of security that can be affected by exploiting a weakness. Possible values: - Confidentiality - Integrity - Availability - Access Control - Accountability - Authentication - Authorization - Non-Repudiation Those look similar to properties associated with STRIDE items: Threat Desired property Spoofing Authenticity Tampering Integrity Repudiation Non-repudiability Information disclosure Confidentiality Denial of Service Availability Elevation of Privilege Authorization So how about we name it properties? Now we can add a meaningful description to the field in the Threat class :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC2BAKQSLU2M2GCNNBVU3DRL4E7ZANCNFSM4LLDECNA> .

[nineinchnick]

Fundament is also pretty generic. How about affectedSecurityPropreties? The value in this is that some of those properties may be more important in a model, depending on the business domain, and it should help prioritize threats. Threats affecting certain properties might be always critical.

Making it a multi-valued field makes it easy to extend pytm to do some post processing and to either grouping threats or highlighting values in this field.

[izar]

impacted instead of affected just to keep the vernacular?

…

On Sun, Apr 26, 2020, 02:48 Jan Waś ***@***.***> wrote: Fundament is also pretty generic. How about affectedSecurityPropreties? The value in this is that some of those properties may be more important in a model, depending on the business domain, and it should help prioritize threats. Threats affecting certain properties might be always critical. Making it a multi-valued field makes it easy to extend pytm to do some post processing and to either grouping threats or highlighting values in this field. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC2BAJQEKZZHBMED2BBX3DROPKKRANCNFSM4LLDECNA> .

[izar]

So where are we with this one? Is it impactedSecurityProperties ?

[nineinchnick]

Renamed but I have not filled the values in threats.json