Intro
This post is not about convincing you to threat model. I want Detection Engineering (DE) or Detection and Response (D&R) teams to consider integrating with existing internal threat modeling engagements to more effectively identify detection opportunities, threat hunt, or improve logging. To be clear, this may not be the right approach for all teams - each organization will have their own priorities, risks, exposure, etc. There is no one size fits all. I cannot understate the importance of this. Bring engineering teams along for the journey. Help them understand why this exercise is worthwhile and what the impact will be for improving Security. Give them the context around how this will be a net positive investment for the organization.
During my Bsides Berlin presentation in 2021, I spoke about why Detection and Response teams that are ready to adopt Detection Engineering and DaC principles need to consider integrating threat modeling into their processes. Historically, threat modeling has primarily been used by Application Security teams and the threat modeling conversations were oriented around data handling and insecure design. However, I think there may be a lot of opportunity in these engagements for Detection engineering teams.
Detection engineering teams looking to better understand the environment and where they may be lacking visibility or alerting should incorporate threat modeling to feed into threat hunting, detection creation, or log collection. It will enable teams to better understand risks and where log collection and exploration could be a high ROI. It will help you identify gaps in data visibility, logging, quality of logging, consistency. I was recently watching the SANS Insight into Detection Engineering 2025 webinar and noticed one of the slides mention how in the current landscape, detection engineering teams are underutilizing threat modeling. So it seems like it’s made it’s way into the conversation a bit more widely since back in 2021. Machine learning is one way to evolve detections beyond a human combining sequentially triggered atomic detections to build a “behavioral detection” or “batch detections”. Threat Modeling can also help DE teams identify services or logging sources that may be good candidates for applying machine learning analytics.
If you’re convinced that threat modeling can help you get closer to achieving a more comprehensive view of the services, here are some issues you may run into and suggestions around how to bring it to your teams.
Quick overview of threat modeling
There are several reasons why Security teams incorporate regular threat modeling into their operational workflows.
Understand cause and effect
Identify vulnerabilities
Evaluate and track risks in your environment
Implement or advocate for security improvements
Prevent threats
When you go into these conversations, you are trying to understand and track:
What are you assessing? This includes things like APIs, Cloud Infrastructure, Internal Services.
Where can something go wrong? You could be dealing with over-permissive users, mismanagement of keys, or even hardware related vulnerabilities.
How are we going to address it? This can vary depending on the risk and has historically been driven with an Application Security perspective.
Most steps in commonly known frameworks, like STRIDE, PASTA, etc can be categorized into these 4 buckets: Planning, Identifying, Prevention/Mitigation, Validation/Remediation. DE can partner with AppSec teams to integrate into these existing steps to find opportunities for logging, new detections, or threat hunt.
When it could be helpful to involve DE or D&R in Threat Modeling
I want to start by reiterating that this may not be the right decision for all teams. Different factors impact priorities and D&R goals. Teams may run very lean and prioritize fixing bugs as opposed to proactively detecting bad behavior, which is understandable, but it could be helpful to tracks risks or opportunities for detecting malicious behavior in the future.
Threat modeling engagements may have different scopes and these are the scopes I’ve found to be the most helpful for DE teams.
High level overview of the system
Modified access or user (internal, external, or NHI) permissions
Typically not considered in AppSec driven threat modeling:
Log delivery pipeline and infrastructure
Auditing capabilities
Other sensitive security feature modifications that impact detection capabilities
Framework for DE and D&R teams
Establish a methodology for prioritization
This will be very environment specific and should be tailored to your organization. You may want to consider (as a starting point), since there may be a wide range of applications in your environment, where sensitive data or customer data is stored, handled, or otherwise interacted with. At this point, there any be a lot of unknown risks, so this is just a starting point.
Let’s say you’ve picked one service to begin with. How do you proceed from here to inspire detections? These are some of the areas you will want to explore. This will not only help with detection creation, but if there is an incident, you can more effectively investigate (or help your SIRT team investigate).
Data centric risk evaluation
Where is the most sensitive data?
How can that data be exploited, abused, or stolen?
Exposure to attack vectors and traversal paths
Existing vulnerabilities that allow for this data to be exploited
Attacker trees
Authentication
How does authentication to this service work?
Who or what has access to the service?
Who or what controls access to the service and what is the process?
Who is able to make changes to this data?
Who has access to this data in the data stores?
Storage
Does it store customer information?
Which platforms store this data? Is there existing logging?
How long is the data stored in each source?
Logging
What logging and auditing is available to monitor for anomalous activity?
What logging should be implemented?
Is our logging pipeline set up in such a way that we can ingest the available logs for this service?
Service to Service Interaction
How do other services interact with this service?
What type of customer information does it interact with?
Does this service interact with customer data?
Linked here is a spreadsheet with the same areas in a more useable format.
Challenges and Mitigations
Resistance from Application Security teams to bring DE/D&R to the engineering engagements:
Propose to start small and then expand - experiment and see how it goes in one very scoped engagement.
Partner with AppSec, don’t go around or try to increase the burden on engineering teams
Be collaborative and Iterative
Remote Threat Modeling:
Create and send out diagrams and pre-meeting material
General understanding of who focuses on what
Define scope beforehand
Explain or share foundational knowledge
Cross Functional Engagements (these are your partners, give them context, build on their expertise and existing relationships):
System owners that know the ins and outs and historical context
Application Security
Engineering teams
Agree upon timelines for any auditing implementation or follow up items - this will help with future engagements and facilitate better relationships with Security
References:
https://www.youtube.com/watch?v=kPVFYAm7NzY
https://docs.google.com/spreadsheets/d/1B-Mgb1lMAes_UZGjiSdPpwZHZIuQQEQGKF2-ZinTH28/edit?gid=0#gid=0