Use cases, new ideas, inspiring discussions, networking, and more 🤩
- 57 Topics
- 234 Replies
hi folks! I wanted to share a blog post, C2PA Threat Modeling, and get thoughts on a question: Did they do a good job?Threat modeling for an industry standard is different than threat modeling for a thing you’re building for internal use, which is different than threat modeling for an API or a platform. One of my key goals in my Threat Modeling Thursday blogs is that no one should ever wince because I’m going all Gordon Ramsey on them. So while I intentionally accentuate the positive, I’m curious: what else can we learn by looking at their work?
Hi - first post here.I’ve been using STRIDE for some time. Heard for the first time about “STRIDE-LM” at ThreatModCon23 but was not able to pin down its definition. I’ve since heard two possible definitions: LM = Lateral Movementor LM = Leaking, Masquerading Is there any consensus and does anyone know the origins of this addition/extension to the classic STRIDE?Thanks,-Bill
Hi All;One of the issues that I run into constantly with threat modeling is the noise level. That is to say, many false positives.One way to look at this, I suppose, is that these false positives are an indication that you’ve cast a wide enough net.But this leads to hours tracking down the justification to write off these NA threats.(These false positives may also tend to overwhelm developers who are new to threat modeling - it is difficult to convince them that threat modeling works when they have to spend so much time weeding out the junk.) I tend to think that the answer to this is “better data”. However, given that threat modeling is *ideally* done as early in the SDLC as possible, when quality/rich/complete design data may not yet be available, how can one mitigate these false positives, and tune threat modeling to achieve higher quality, less noisy results? Looking for ideas here…thanks,-Bill
One question I am often asked by the many organizations I work with is where do I begin ? How do I get started Threat Modeling? What do I Threat Model, and what do I need to be concerned with? As with everything you do, you must be willing to take the first step. Taking on a new challenge is often very intimidating and the fear of failure is real. My advice is to start with the smallest, most simple application or workflow you have. Keep your model small and specific to a singular process. If you identify 1 new threat today, then you have accomplished something significant. I also encourage people to not take this task on by themselves. Threat Modeling is a collaborative process. No one know everything, so leverage the knowledge of your teams. And because you have kept your model compartmentalised, your collaborators will not feel overwhelmed. Finally, I highly encourage people to move the process of Threat Modeling left. By this I mean, start the process very early in the software de
They say a picture is worth a thousands words and so including some kind of diagram in your threat modelling process likely aids in understanding the system being threat modelled. But some diagrams can end up looking like “spaghetti and meatballs”, depending on the complexity of the system.I thought would be interesting to take the pulse of the community on this topic, so we can better understand what approaches are being used.Note, if your threat modelling approach uses lots of diagrams, perhaps just answer for the scenario where you were forced to choose just one.
I'd like to discuss about how organizations can introduce security in organizations and be adapted to the ever-changing cybersecurity landscape while maintaining seamless operations.What are some of the significant challenges that you faced to 'scale' security, and how did you address them? 🤔
Greetings ThreatModelingConnect Community, ThreatModCon 2023 is fast approaching (https://www.threatmodelingconnect.com/events/threatmodcon-2023-38)! As part of the conference, we're planning to host several Birds of a Feather (BoF) sessions during lunch. For those unfamiliar, BoF sessions are informal gatherings of like-minded individuals to discuss topics or common issues encountered without a pre-planned agenda. We wanted to reach out to the community for feedback on what topics/issues you would be interested in discussing at ThreatModCon 2023.
Hindsight is a wonderful thing and lessons learnt from Implementing a Threat Modeling program is no exception. I am curious to know how organisations from large to small have approached this.Would love to hear your experience or of others you have worked with on what has worked or working well, or what you may perhaps do differently that you feel would drive a better outcome to your Threat modelling program?
I would say this is the most enigmatic of the 4 questions in the 4 question threat modelling framework.After you’ve clearly defined what you are going to threat model, after you’ve analyzed the system for threats, after you’ve created a set of additional controls to mitigate those threats - did you do a good job? How do you know? What does “good” even mean? Would you really ever finish a threat model and then call it ugly?It’d be fascinating to hear how people tackle this thorny question?
So I know the usual suspects, of course: @Adam Shostack's books, various YouTube channels (including from IriusRisk), the Threat Modelling Manifesto, and this forum..But let's say I want to become an "expert" in Threat Modelling… what can you recommend? Something on LinkedIn Learning, perhaps? Or by O'Reilly? Or is it simply a matter of getting up-to-speed on the primary literature and hands-on learning?
ThreatModCon 2023 has chosen to foster greater threat modelling practitioner dialogue through a birds of a feather lunch at the conference.In 2011, at SANS What Works In Security Architecture Summit, it struck me that practitioners rarely get an opportunity to discuss recurring issues, to discuss the practice. We do an awful lot of “knowledgeable presenter” dispensing learnings. But we don’t make space for people who practice every day to discuss how they do things, to refine our discipline through unstructured interchange. As practitioners of an engineering discipline, what we do I believe will most certainly benefit from lively discussion, from strongly held opinions, hopefully held loosely enough that we listen to each other, searching for commonality and improvement. Networking events don’t lend themselves to focused discussion. These are more, “meet and greet”, which is fine so far as it goes, but does not advance the practice.After much reflection by ThreatModCon’s organizing com
In the threat modelling methodology I use, I ask teams to capture the authentication and authorization methods that the different parts of their system implement (for those bits in-scope). This ask, as it turns out, has been something that teams have really struggled with. It seems to be a combination of not always having the difference between authn and authz very clear in their mind, and the fact that sometimes the difference is indeed not very clear at all anyway! (IP allow-lists is a good example - authn or authz? or it depends?).In an effort to at least bring some consistency in how the teams I work with capture authn and authz, I created some Examples and some Guidance to help them, which I thought I would share, in case it helps others as well.If you know of any authn/z guidance, examples or docs that might help others, please do share.
I remember the first conference where I ever spoke about threat modeling like it was yesterday. The conference was the Microsoft Secure Development Lifecycle conference in Washington, DC, and the year was around 2010. I did a panel with a few other folks on threat modeling under the more significant SDL conference context. I always wished for a conference focused on threat modeling, and now that wish has come true! I am acting as the first conference chair for Threat Modeling Conference. A few of us in the world of threat modeling got together as founding members of Threat Modeling Connect. During an initial conversation, I mentioned that a big-ticket goal of Connect should be to host a threat modeling conference. And my reward for that suggestion was an invitation to chair the event. Always be careful when making suggestions. Of course, I'm kidding and honored to chair this event. I'm working with my various threat modeling besties, like Izar Tarandach @izar , Matt Coles, Brook Scho
What approach does everyone use to get developers engaged in the threat modeling process? Have you found that developers are generally open to getting involved and see the value in shifting left or do they look at it like its just going to add additional work for their teams?
It’s easy for everyone in security to agree on doing extra work to create secure systems. In my experience, it seems that once we begin to socialize or implement the process/idea/system/etc. there is pushback from others. Threat modeling is no exception.Implementing change, even if it is for the good, is difficult. Has anyone engaged with pushback to threat modeling? Either as a security practice or specific details in the methodology?If so, I’d love to hear your thoughts on how the pushback was approached. Or, like my kids would say, how did you clapback??
(as seen in The Security Table’s first LinkedIn live podcast episode!)As much as system builders at large have been more willing to accept Threat Modeling as a useful practice with clear positive results and advantages, it is still somewhat difficult to institute it as a part of the secure software development lifecycle in most organizations.The reasons are many, but chiefly among them is the clear fact that eliciting threats out of a design requires a certain amount of expertise, experience and savviness that is hard to quantify and harder to teach, in security practitioners. We can train people to be aware of security weaknesses that may be introduced at the design stage, but it is harder to train them to identify the multiple ways these weaknesses can sneak in when a system is being designed, or implemented in an agile way, when the design couples tightly with the implementation.This author (and many others!) has tried to make that path shorter, with Continuous Threat Modeling (http
We, the ThreatModCon 2023 Programme Committee were stunned by the response to our Call For Papers. It’s a new conference, the first conference dedicated to threat models and threat modelling. So the committee members would have been happy to receive a few more papers than available speaking slots.But that’s not what’s happened! Given an embarrassment of riches, we decided to add a second (2nd) presentation and workshop track. Then the hard task of choosing began.I wonder if those who’ve not been on a conference committee are familiar with the process:Understand every submission Adopt a process for identifying each evaluator’s favourites Urge (nag?) evaluators to make choices Categorize submissions by theme for an interesting mix Wrangle evaluators into 1, usually more meetings to work through disagreements and issues Draft acceptance and rejection letters. Obtain approval from committee Notify submitters Schedule the talks in some manner as to keep the energy flowing and themes coheren
We are excited to announce the inaugural Threat Modeling Conference (ThreatModCon), an event for application security professionals, researchers, developers, architects, testers, and practitioners to discuss and share their knowledge on threat modeling techniques, methodologies, tools, and best practices. We invite the submission of original and innovative research, case studies, and practical experiences. Conference Dates: Sunday, October 29th, 2023Location: Marriott Marquis, Washington DC The theme of the inaugural event is "Threat Modeling is for Everyone". The conference welcomes contributions from a wide range of topics related to threat modeling, including but not limited to: 1. Threat modeling methodologies and frameworks2. Threat modeling techniques and tools (OSS)3. Uses of machine learning and AI for threat modeling4. Security design patterns5. Privacy and data protection considerations in threat modeling6. Risk analysis, prioritization, and management9. Training and awarene
In order to model well, we have to understand how attacks get started and how they proceed. Otherwise, how do we figure out “What can go wrong?”For many new to the sport of threat models, compiling a reasonably comprehensive set of potential attacks can be daunting, at best, overwhelming for many.Personally, I spend a fair amount of time just keeping up, even though I’ve been modelling for more than two decades. Well, the following article I picked up out of my TL;DR cyber newsletter might help: Let’s Talk About SaaS Attack Techniques (11 minute read)An article from Push providing an overview of modern SaaS attacks. The attacks are broken down into a MITRE ATT&CK style matrix. The article concludes with a discussion on the observability of these attacks.
“Understand what a criminal is looking for, why they're going to attack you. Is it because of status, cash, ideology? Understand who the attackers are, why they're attacking you, what they're looking for, information access, data cache. And then you'll understand the persistence of the attack. You'll understand what you need to do to design security to deter that type of attack.” - Brett Johnson, Shadow Crew, the first organized cybercrime community. “Scale To Zero” Episode 2.Several members of TM Connect and I have had this long-running conversation (really, disagreement): Must we understand attackers or not? Mr. Johnson, former and foundational attacker clearly validates my position that attacker knowledge is essential to understanding the following:Attack surfaces Lateral movements (steps of the attack towards attacker’s objectives) What will be compromised and how (not every successful attack ends in a data breach. consider bot nets) Rating impacts properlyTake for example a divers
Hey all, I have not seen any posts nor much out there… but I am sure some people are thinking about this right? With the right DFD metadata and possibly a gherkin-like way to describe scenarios, it feels like something could be done.What are the collective thoughts around using AI to help lead threat modeling sessions to scale appsec teams efforts? Is there something out there that’s already midly useful?If I knew what I was doing, that’s probably something I’d start thinking on building :-)Cheers,
Singapore’s 2018 Cybersecurity Act indirectly makes it a criminal offence not to perform cybersecurity risk assessments which include threat modelling on computers and systems that have been designated by the Cybersecurity Agency (CSA) as Critical Information Infrastructure (CII).The Act (Act 9 of 2018), otherwise known as the Cybersecurity Bill, first came into force in August 2018 to establish a legal framework for Singapore’s national cybersecurity. The key objective is to strengthen the protection of CII and provide the CSA the powers needed to act effectively to prevent, manage and respond to cybersecurity threats and incidents.In accordance with the 2018 Cybersecurity Act, the CSA issued the Cybersecurity Code of Practice (CCoP) detailing the minimum regulatory requirements Critical Information Infrastructure Owners (CIIOs) must comply with; however, the expectation is that they implement measures beyond those stipulated. The current version (CCoP v2) came into effect on 4th July
@izar wrote something that I think is critically important for those who are wondering how to “sell” threat modelling to decision makers and developers. It bears repeating, underline, echo, big ditto from me: “[T]hreat models are a great hanger to hang most if not all other activities of the SSDLC on. If you have a threat model you can rely on it to provide a framework for security testing that you wouldn’t have beforehand, and you might end up either looking in the wrong places or putting too much energy and time into probing things that do not guarantee your security. Likewise, if you know you have a high level of exposure to injection issues, you can orient your pentesters in that direction and get a better return on the investment that is a pen test. You need to onboard new people? Point them in the direction of the threat model and not only they’ll get a detailed view of the system they will be working on, they will also learn of those areas that are more brittle or need more care
Salt Security API security report 2023 validates an aspect of #threatmodeling that I find myself needing to repeat: Authentication does not prevent attack!Of the 4842 API attacks analyzed for the report, only 22% were unauthenticated. A vast majority (78%) of attacks were authenticated!If what's behind an authentication is worth the expense/effort, attackers are happy to purchase/sign up. Consider:Freemium and advert-paid sites (Facebook, etc.) and sites that dole out email addresses (Live, Yahoo, Gmail) allow everyone (of course attackers) Large enterprises always have some compromised machines. Ergo, attacker rides along with authenticated user. Any enterprise user might also allow attack A billion cracked passwords readily available#threatmodeling must account for authenticated, likely authorized attackershttps://content.salt.security/state-api-report.html(In another post I’d be happy to explain what authentication does provide. It’s also in a couple of my books, if that helps?)
🔔 Stay connected
Start a conversation
Validate your ideas, share resources, get feedback from your peers and experts.Make a post
Create your account
Not a member yet? Become a member to join forum discussions, participate in community events and apply to write articles.Create an account
Log in with LinkedIn
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.