I’d love to hear your thoughts and experiences around using the output of your threat modelling activities to build or even strengthen the much needed collaboration between design and operational security teams.
Comment below 
Have a great weekend legends
Our people tag mitigations depending on who is responsible. That way we can consider both worlds when we threat model and be clear about what is expected from operations and engineering to provide an overall secure system.
I’d love to hear more about this! Sounds interesting 
This article discusses our research in which we offer a bridge between operations (including dependencies, such as supply chains), designing and executing incident response (including a concrete metric):
What more info do you need? @PaulSpruce
Imagine you live in a world where vendors build a product, operators install / configure / operate the product, then users use the product.
For any given threat, you can come up with a lot of mitigations. Then think about who would do this and be responsible - vendor, operator, user; mixed?
Then choose mitigations. Favor engineering solutions over operation solutions over user solutions.
Have processes and communications installed that the people responsible know what’s their part and actually do it.
End up secure. 
See also: TRANSFER strategy in approaching a risk…
We have customers where the SOC team signs off on threat models (which are a part of release gates). In other places, using threat model and threat model updates can give a named time to talk between teams. Much like naming “backlog grooming” helps, naming threat modeling as the activity can help ensure the meetings happen.
This is what is needed and where I feel can be a stumbling block - getting the right people with the right buy in, inside the room. Thanks Adam much appreciated
You’re welcome. Getting that buy in involved finding SOC folks who cared (that wasn’t hard), who were willing to stretch in practical ways, and who could advocate for process change in the SOC.