Add initial Threat Modelling document

[gyro2009]

What has changed

• Added a Threat Modelling document to try and standardise the UKHO approach
• Linked to the Threat Modelling document from the Secure Development policy

Why has this changed?

• Provide consistency in approach to Threat Modelling
• Add starting point for discussions on approach
• Enhance work began by existing teams
• Provide documentation for Audit purposes

[OTjornelund]

Good work so far. Most of my comments and suggestions are just minor improvements to spelling, grammar and structure.

[perrytom]

Are we saying that a threat modelling session at the start of a project needs to have Principals, leads, and ITSO in it? Usually how it works at the moment the team does the threat modelling session among themselves and then meets with ITSO to discuss the project and what had been identified and mitigations.

[gyro2009]

To bring our conversation here, the ideal would be what is laid out in this document as you can build up your documentation from the early stages. It also allows for intervention at the design stage when looking from the outside in on the project. Obviously an ideal and something we can work towards.

[bealesd]

Is STRIDE done at the start of project? The gov link suggested it would be run by a PM or the secuirty org, with the relevent expertise from devs, devOps, hardware admin, net admin.

[gyro2009]

I have just been conversing with Dave Tilsley on this and at the start of the project (before any code is written) the ideal would be to have a data flow diagram and relevant people present (customers, user researchers/designers, security, devs, operations) so that a fluent discussion can be had about the initial design. Then we can move onto a more technical TM session as described above before being a little more hands off. STRIDE is how we categorise the things we find so it will be done all the way through, its just who is involved at what point may change.