Hear from our very own experts about security topics.
- 9 Topics
- 14 Replies
This article “What to Threat Model -- 3rd Party Software” is part of the What to Threat Model series. This article targets Software Acquirers and the Security Champions/Architects working within that group. Author: John Steven Soon after modeling some of an organization’s internal applications -- or even because of such modeling -- an inevitable question arises: “How should threat modeling contend with 3rd party components and services?” Increasingly, this question becomes more important to security posture, as engineering evolves from principally a development activity to one focused on integration.Yes, absolutely, 3rd party components and services are not only likely to require threat modeling, but they may also turn out to be a focal point of threat models. How do you determine what 3rd party material to model? How does modeling 3rd party material differ from what which your organization owns and delivers? Before we continue, a distinction: this article addresses incorporating 3rd
Did you miss the live fireside chat about why a threat modeler community can be a huge asset to you and your threat modeling practice? We discussed about what this community has to offer, how sharing and learning from others can help your threat models be more effective and be implemented faster, as well as other ways the community can help your cyber security program. Check it out!
With Executive Order 14028 and the compendium NIST Internal Report 8397, organizations are required to diagram their software and along with that conduct threat modeling exercises. In this context, order 14028 supplies the mandate and IR 8397 provides guidance for how to comply. Whereas practitioners can quickly interpret and implement given SAST guidance from IR 8397, threat modeling guidance demands interpretation. For instance, when discussing threat modeling technique, IR 8397 references an SEI paper that itself refers to twelve (12) methods of threat modeling. Shevchenko's "Features by Threat Modeling by Method" - See Original In her SEI paper, Shevchenko provides a table (see right) describing the different features of various threat modeling methodologies. Before proceeding, note that there are different classes of “method” within this list. Some, like CVSS or OCTAVE focus on scoring risk. Others, like STRIDE, or SECURITY CARDS focus on evaluating a checklist to discover risk.
“Proliferating threats and increasingly complex IT architectures are putting significant pressure on teams to keep their enterprise systems secure. These trends show no signs of slowing down, which raises the question: How are IT leaders planning to address these challenges as they make their way through 2023?”Read the rest of the article from @archie here:https://www.forbes.com/sites/forbestechcouncil/2023/03/22/how-devsecops-can-increase-confidence-in-security-architecture/
Welcome From the CEOfeatured_side
With the launch of the ThreatModeler Community, we are continuing to light the way for enterprises pursuing more resilient architectures,” said Archie Agarwal, Founder and CEO, ThreatModeler. “Years of experience and patented capabilities uniquely position ThreatModeler to provide a platform of thought leadership, technical best practices, and peer conversations that will have a real impact on enterprises' ability to incorporate threat modeling into their SDLC efficiently and effectively.
This article "What to Threat Model -- Continuous Threat Modeling" is part of the What to Threat Model series. This article targets Security Champions/Architects conducting threat modeling exercises.Author: John Steven As organizations threat model applications and infrastructure in earnest and become more confident with what to threat model, questions about "what to model" don't go away. Instead, those questions evolve into "What should threat modeling output?" or "What does ‘done’ look like?" In many ways these questions are just different ways to tackle "What's in and what's out of our threat model?" Continuous is KeyThroughout this and other content, one concept consistently re-emerges: threat modeling is not a one-off point-in-time activity but instead is a capability, continuously applied. This, more than any other factor or technique, helps security champions understand "what to output" and "what done looks like". The last article, What to Threat Model in Each Software Release C
This article "What to Threat Model -- Each Software Release Cycle" is part of the What to Threat Model series. This article targets Software Security Group (SSG) Owners and the Security Champions/Architects working within that group.Author: John Steven Even after an organization has decided what applications and infrastructure to threat model, questions remain for an SSG. "Does each delivery team wait for a particular phase of its lifecycle to conduct the threat model? -- Does threat modeling have to occur during design?" "Do we block on threat modeling before proceeding with the rest of delivery?" "What if the team doesn't have a diagram? -- what artifacts are necessary to begin threat modeling?" Having Enough to start Threat ModelingHaving decided a particular application or piece of infrastructure is worth threat modeling at the organizational level, the work on that threat model begins in earnest. The team assigned begins to collect inputs: system diagrams and answers to key design
This article “What to Threat Model -- For CISOs” is part of the What to Threat Model series. Author: John Steven When organizations consider adding threat modeling activity to their software security initiative, a common worry is, "Do I have to cover every application? All the infrastructure?" The number one concern heard over the years is, "I'm not sure I have the staff, let alone qualified staff, to take this on… " Organizations address this concern by prioritizing their portfolios and threat model that which is perceived most valuable. How should organizations think about what to threat model? Model the Full StackOrganizations should threat model those essential applications and infrastructure alike, it's not sufficient to do only one or the other. Each provides its respective piece of the total model: modeling the application is vital because that’s where business logic and assets are. And, increasingly, infrastructure views help define a model's surfaces, security properties, and
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.