simoneonofri
commented
1 month ago Hi @jyasskin, thank you for your comment.
So in general I feel the same way as you, that important topics like Threat Modeling is an important topic to be "chartered" and I have and we have made several thoughts with respect to CG or IG. I'll write them down for you here the reasoning we've done, I'd appreciate your opinion. Then if you prefer let's also talk about it in call or as it's more convenient for you (maybe we'll even meet at TPAC in f2f :))
- Premised that Threat Modeling is something that is already present within W3C as well as IETF and we find in fact references in the Security and Privacy Questionnaire and in RFC 3552 and RFC 6973.
- Also, in general, the various Groups already have Threat Models that they reason about when specifying, as it is an innate process as a human being.
- Talking with the various Groups (and it also shows in the Minutes and dicussions on GitHub), the issue is not so much having a Threat Model, but how to generate it in a structured way and how best to document it (things that then make it into Security and Privacy Considerations).
- To bridge this gap I proposed an Breakout introductory on this, be aligned on a process/method/techniques.
- As well as then maybe produce a guide on how to do Threat Modeling in the case of standards and specifically for the Web (much already exists but for software).
- In general we can say that Threat Modeling is the coming together on the one hand of expertise specific to the object/technology being developed (hence the working groups), and those who know the threats well (security experts, privacy experts, human rights experts for example). So it's a joint effort where though the responsibility for implementation and mitigation lies with the Group managing the Specification.
- In that sense, it's important to understand the life cycle. The Threat Model should be born together with the technology, right from the explainer and "grow" as it goes. Obviously Spec developers can work through the various tools we are gradually creating (including the list of threats/attacks in security, privacy, human rights shared via e-mail) together with those who know the threats well.
- Hence a "cross-competency" CG of Threat Modeling and not just Security (such as SING), which still remains in support and as a reference. It is true that historically Threat Modeling originated in Security in the 60s but it can also be used for Privacy and Human Rights. Also a CG simplifies collaboration (and since it is based on brainstorming it is useful to have more opinions) as for example with @msporny we will reason insme to Marianne from #whyid (they have their own Threat Model for Digital Identities) and it is definitely easier for her to participate.
- Of course SING, as a sister group to PING then has the formal task of "reviewing" the work with the Horizontal Reviews, which in fact is a time of review, not of creating the Threat Model (and the people who can help, like CG) also because in the review moments it would already be too late and the bulk of the being untarred earlier. Besides maybe it is the right place to formalizing the method better receiving inputs from the CG. And here we can also formalize the process and maybe a general Threat Model for the Web (I held also a presentation for the Web Kill Chain).
I hope I explained myself, let me know what you think about the reasoning :)
@simoneonofri noticed that we don't have a home at the W3C for general web threat modeling. He tried to address this by creating https://www.w3.org/community/tmcg/, but my personal sense is that this area is mature enough to fit into a chartered group. The horizontal review group for security will be enforcing a particular threat model, so it makes sense to give them the responsibility to write it down.