Review Conexxus Security and Privacy Threat Model and Implementation Recommendations

[mmccool]

Will attach Conexxus document to this issue once I receive it.
Tasks:

1. WoT to read Conexxus document and see if we should make any updates to WoT S&P Guidelines and Best Practices doc.
2. Conexxus document to likewise ready WoT S&P Guidelines and Best Practices doc. and provide input.
3. Capture high-level main points in retail.md use case (ASAP). See Update Retail Use Case with Security and Privacy Considerations wot-architecture#494

[mmccool]

We should also review the WoT best practices document and see if there are any specific comments we should add that are mentioned in the Conexxus docs but not the WoT doc.

[mmccool]

Link to Conexxus documents: https://www.conexxus.org/documentation-guidelines-templates, in particular

• Designer Threat Model template
• Implementer Threat Model template

[mmccool]

Note that point 3 in the description, "capture main points in retail use case", has been done already.

[ereshetova]

Thank you for attaching the docs Michael! I will check them and can make a report next week on the security call

[ereshetova]

I have read through the template now and here are some points:

• the main structure of the template is similar to what we have followed in our WoT threat model (use cases, assets, trust boundaries, threats), but there are some notable differences. Since this is a template, it tries to be more concrete on helping/organizing/enumerating the threats similar to MS STRIDE and other threat modelling approaches.
• The template separates "assets" and "data" (first one as smth that explicitly needs protection, second is just smth that is processed by system). I am not sure this separation is needed, one can just view both of them as higher and lower value assets. At the end it describes the protection for each asset or data, thus supporting the idea that it might just make sense to join them.
• In the data section, there is a check list for providing more detailed info on the type of information that it being processed/stored. For example, for PII it has a list of different items, such as Birthdate, Certificate or License number (including driver’s license number), Email address, Fax number, etc.
• Section 6 API Consumers corresponds to WoT Stakeholders in our threat model. The template suggests to specify "Trust Level" for each consumer, i.e. whenever it has administrative rights, authenticated user rights, etc.
• Section 7 Data protection contains checklist of potential mitigations in order to guarantee various generic data security properties, i.e. data confidentiality, data integrity, etc. While it might be a good partial checklist of protections, IMO in practice it is going to be duplicating the mitigations done against the concrete threats, for example transferring data A between endpoint X and Y. Some parts of section 7 (like the list of cryptography) can be handy for export compliance report.
• Section 8 contains a checklist of measures used for audit and logging. We don't discuss this part in our S&P guidelines, which might be worth fixing.
• Section 9 - Compliance list, again smth we don't ask in our template, only briefly mention that there can be legislation and regulation requirements.
• Section 10 - common threats list, or more like common pitfall list, might be useful as a checklist to verify the implementation against.

Let's discuss these and other points in our next week security call.

[mmccool]

So, we should discuss what are action items are. Possibilities:

1. Updates to our existing documents, eg to our Threat model, eg adding logging/auditing, legal compliance.
2. Creation of new documents, eg our own template (ML has asked for a security question list for use cases, for instance...)

Each of these possible actions should be turned into issues for further discussion. For example, I have created an issue for "making our own template": #182, and have added an issue for adding "logging and auditing": #183

Creating these issues are just for discussing possible actions and even whether we should take them.

[mmccool]

Making an issue to further consider explicitly discussing setting different "trust levels" for different consumers, then we can close this issue: #190