Week 8: audit process v. threat model

In my current course for learning how to analyze an environment and apply a security posture for the current vulnerabilities, threats, exposures, etc we have been working on how to create and apply threat models.

During the first few weeks we learned about threat models in general and how to create our own. Per usual, there were a couple industry standards out there; however, there was a point be driven... Threat models are constantly being updated and tweaked either for a specific project, a target audience, or because there a new vector to account for.

Initially, I thought the threat model was synonymous with the normal IT audit life cycle. The audit life cycle goes through and identifies assets/systems/processes to create a baseline. Then it will go through and analyze the state of each of those items to annotate the everything wrong. Then they will go through and generate a report about each of those with recommendations and submit that to the customers. Some of these reports will then show recommendations -- showing the same value vs likelihood vs risk exposure, etc.Then they will demonstrate how these items can be monitored over the length of time before the next audit.

So what I'm curious about is, which came first? The audit process or the de facto threat model? Will the audit process change if the de facto threat model changes? I assume so and it'll be a sweeping change with wide adoption.


 I have learned that there are additional steps and tools that can be used to assist in providing this report. The culmination of these tools has altered the presentation at the end of this and perhaps there is the answer. Perhaps the audit is more geared towards the department level and operations while the threat model is more geared towards senior leadership and executives at the company. 

The tools that we have used more for this course is like flow diagrams to show a very simplistic overview of how a system is or should operate. Working through STRIDE, to make it stick and be visually appealing is a great example.

https://www.researchgate.net/publication/283205029/figure/fig6/AS:325314161987590@1454572348624/Relation-between-STRIDE-security-attributes-and-security-service-for-HTN.png

Another huge tool, which I did not have as much experience with, was a network diagram which shows how enterprise objects are logically connected within an environment. This has shown me, a senior engineer, that I need to work on adding more skillsets like diagrams and flows into presentation and probably even our documentation (SOPs, Build Guides, Administrator guides, etc) to help convey more technical items better to a wider audience.