Team 55 | Threat Modeling Hackathon 2025 Submission
Award: 3rd Place out of 55 teams
Theme: Smart Transportation Solutions
Our team approached the hackathon by aligning on a shared goal: deliver a threat model that could immediately resonate with executive leadership while preserving technical depth. We chose to model TMC-Drive, a fictional fully autonomous electric vehicle system, with scope limited to onboard software and real-time operations during a trip—excluding mobile apps, backend services, and hardware internals.
This model is built for CISOs, engineering leaders, and board-level stakeholders. The first page provides an executive-ready summary. Detailed assets, threats, assumptions, and mitigation recommendations follow in structured appendices.
Key Features
- Executive-first framing with CISO-focused messaging
- STRIDE and LINDDUN for combined security and privacy coverage
- Transparent threat prioritization using a cumulative voting method (each team member assigned 10 points across 20 threats)
- Clear scope boundaries with documented assumptions
- Innovative five-category assumptions framework (model, organizational, attack, data-driven, and architecture assumptions) to enhance clarity, scope control, and risk traceability
- Risk statements linked directly to business concerns
Judge Feedback
“Team 55’s threat model stood out in several important ways.”
“They really nailed that messaging for a CISO audience on the first page—clearly defining what was important and what should be done about it.”
“They made great use of assumptions to reduce scope, clearly defined what was in and out of scope, and associated each risk with a specific business concern.”
“Their approach to risk was simple and transparent… and earned a lot of respect from the judges.”
Closing Thoughts
We hope this model inspires future approaches to communicating security and privacy risk in a high-stakes, high-autonomy environment. Feedback and discussion are welcome—especially on risk prioritization, scoping strategies, or executive communication.
“If it’s not fun, you’re (probably) doing it wrong.”
— Steve Gibbons, Team 55 Lead
6 Likes
Hi @steve_gibbons,
Really awesome threat model!
Thank you for sharing and inspiring us!
Congratulations on winning place 3 of 55!
Also:
Great closing quote. I’d cut on the “probably” 
Keep up the good work!
1 Like
Thanks, @hewerlin !
I try to avoid absolutes, and to allow for things that may have been missed (such as not having fun for some other reason.) Dealing in uncertainty is certainly part of the job… 
Congrats to the Team 55, this is indeed a great work !!
1 Like
@steve_gibbons Great presentation and Threat Model, I really liked the idea of presenting icons for Artifacts, TM Elements, etc., with a graphical representation so how did that idea come up? I am really interested in knowing about the process of creating those icons, it will be helpful if you can share some details knowledge about it.
1 Like
Thank you. The iconographic representation was the work of one of my teammates, Wendy Segura, and she is best positioned to respond to your question about the inspiration. They certainly add a splash of color and fun 
1 Like
Yes, you are right. I missed the other causes of not having fun. 
Your threat model is super strong with respect to assumptions.
Some of your assumption read like “mitigation already in place”.
Can you share some of your thoughts about the interplay between assumptions and scope / threats / mitigations? How did your team derive those?
1 Like
Great questions! Constructive use of assumptions is a technique I picked up during my years of security architecture governance - it allows for quick baseline understanding with an assertion + confirmation interaction or alternately a structured dialog about a specific point or area of concern.
As a survival technique for the hackathon, we had an unwritten assumption that TMC-Drive was a world class organization and that they had already implemented many best practices that we would have expected to see in a new product with a lot of scrutiny on it. That one unspoken assumption helped shape many of the specific assumptions that were captured (as you noted many sound like “mitigation in place”) which let us not get bogged down in gory details and focus more on bigger picture (descoping entire categories of threats and swaths of analysis in the process.)
In a a RL engagement, some percentage of assumptions turn out to be false and some percentage of those turn into rabbit holes that reveal risks that very few in the organization knew about.
As far as the driving, the assumptions were largely my own individual contribution and based on years in the trenches evaluating and assessing processes, systems, products, projects, and 3rd parties.
Assumptions as early mitigations?
We have been following a “start from 
” philosophy, where everything that guarantees the security of our systems needs documentation. With that, we were hoping for really explicit 
↔ 
mappings.
So instead of “Post-quantum cryptographic readiness is assumed, with agile key rotation support.” there would have been a ↔ with status 
. Same for “Logs and configuration data are assumed to be tamper-resistant, privacy-sensitive, and require protection against unauthorized access or modification.” and friends.
But also, it is really boring sometimes. And the examples illustrate nicely why you don’t want to talk about all that stuff. That suggests we should import best practices and take them for granted. Seems like a quick assumption is a good shortcut idea to reduce scope and avoid talking about basics. (Surprise surprise, let’s TLS all the things. 
)
Process mitigations
I really love that move:
5.2. Organizational Assumptions
● Safety is a core value embedded across the development lifecycle, with a designated safety champion holding approval authority for release.
I would have bothered a LOT about safety in the Hackathon assignment. You simply say there’s other folks, too. Let’s just take a look at Security → Safety. Seems pretty clever. 
Will think about that. If you want to dive deeper, feel free. Again, thanks for the inspiration.
1 Like
There’s an old joke about assumptions that I try to keep in mind: https://www.esltoybox.com/5198/ throughout the exercise. This technique really only works when assumptions are verified and not blindly accepted as fact. I’ve had some GREAT conversations during the vetting phase, though. Starting from a positive assumption and filling in the reality is generally more effective than putting people on the defensive by assuming a negative. It’s also a good way of planting the seed on approaches to mitigation since an example expectation has been set by the stated assumption.
1 Like
Great job team .. Congratulations !!
1 Like
Wish that worked for 
AnnAhMe. 