I'm Izar Tarandach - and if you have questions, I may have answers!

Looking forward to attend the session. In the meantime.
If you have only one shot to encourage Agile Teams to embrace Threat Modeling, what would be your phrase to convince them?

Hi @izar !! Thanks for this opportunity to ask my newbie doubts

As a Treat modeling newbie with a background in Software Development. What would be your advice for someone new to start threat modeling as a developer?
What advice would you like to have had in your beginnings in threat modeling?

Slightly personal. I hope that’s ok? 

How, @izar do you deliver unpleasant realities, bad news? About challenges/stubbles in your programmes, about things not working, strategies that seem to be failing (I KNOW you’ve got a story or 2 about that!), about designs that aren’t actually going to work, etc?

What’s the trick(s) to telling the truth and NOT getting terminated? Or, is there one?

Hi @izar I’m new to TM as a whole and thankful for people like you willing to train and share your knowledge. That said,

* If you could go back and talk to you when you first started out, what would you tell yourself back then? What are 1-2 things you wish you knew when you were getting started?

Hi @izar. How do you handle teams that push back against threat models? When teams do not have the motivation to threat model, they produce little and, sometimes, unuseful information. This creates the opposite effect that we are trying to gain with a threat modeling program. Do you work with the information you have, or do you push back and try to refine the threat model better, which slows down the process?

I guess the question boils down to how valuable is a threat model with little information? This becomes helpful to know when figuring out when to push back or not.

A number of options runs through my mind, but if I had to choose a single phrase, it is important to bring up the concept of cost-benefit: “It will be cheaper this way”, where cheaper is actually a measure of many things - money, time, effort, emergency mode, communication, inter-team dynamics. It will simply be, in the long run, more cost effective to invest the time and reap the benefits of threat modeling than leave things to fester and grow, and have to deal with them in emergency mode as alarms blast and customers call later on. 

Hey @jmgarcia , thanks for taking the time to ask questions!!

My advice to you comes by way of a sports apparel company, which I wish was sponsoring me (can you imagine?) - “Just Do It”(TM)(C)

I know, huge cop-out, but seriously - there’s only one way you’ll develop your own experience, be able to decide by yourself which methodology to use when, what areas you need more polish, and how to communicate your thoughts and findings, as well as the non-trivial bit of actually modeling the system. 

We are all fortunate to have great resources available that we can use to draw guidance and inspiration from, but if you take a look at the Threat Modeling Manifesto you’ll see that one of the anti-patterns identified there is “Admiration For The Problem”. Like most patterns, it appears at many different levels in a process, and I believe that at the topmost level it shows itself by people being fascinated with the “problem” of Threat Modeling, which keeps them from actually threat modeling! 

So my advice to you is, do it. Grab a system and dive into it, hopefully not by yourself, and figure out what is being built, what can go wrong with it, what to do about it and then decide if you did a good job. The last part is where you’ll really grow. See what you could have done differently, add new knowledge and approaches, and go for it! We’re here if you have questions!

A long time ago in a galaxy far away, an Elder Statesman For Appsec synthesized one the biggest truths of our practice with the words “nobody likes to be told that their baby is ugly”, which then got distilled to “we are not here to criticize your design, we are here to make it more robust and secure”.

Needless to say, that person was you. 

I took that to heart and incorporated it in my practice. I was never a professional outside consultant (I did consult on projects that were not my responsibility, but it wasn’t a main gig) so I think I have been lucky here that whenever I am giving an opinion, I can always rely on “the success of this thing is as important to me as it is to you, so I am trying to help us both make it better”. 

Let me pontificate here for a second without a single shred of hard data to support my opinion: I think that what separates “the old guard” of threat modeling practitioners from the raising one is that we came mostly not from a security background, but from a system development one. As such, we may sometimes feel we are entitled to an opinion that goes beyond security and into systems design proper. But even then, I am very reluctant to point out “bad design”.

What I have found over time is that we can always try to dress that bad design as a valid threat modeling finding. After all, there’s many reasons for the D in STRIDE! Can we point at that design issue as a “this thing might break under stress, and you know, service will be denied” ?

On the bigger stuff, programmes, things not working, strategies failing - “failing” being the operative word I think - anyone in this field for more than a second will have had experiences where efforts started with 110% energy and commitment only to fall in the “will it scale?” question, or not be sufficiently supported, or, or...which is where that thing that is the most difficult to teach and mentor, but not to grow, the soft skills of communication and diplomacy, comes in.

I haven’t found a trick yet. But I have found something that gives me pause for thought before I open my mouth, and that’s the sketch by “That Mitchell and Webb Look” - “Are We The Baddies?” - is the person I am going to talk to going to see me as the baddie when I see myself as the hero? If I take their perspective on things - am I being the best collaborator I can be? It is not about being likable or not - Cthulhu knows I have had my issues with that! - it is about seeing things as they may be seeing them and delivering those bad news in the same framework as they are using, not mine. Or even reconsidering that in their framework, the issue may not be as bad as I see it in mine.

Hey @Roger_RPC thanks for popping by!

If I could go back, what would I tell myself? Easy! To listen to my mother and go into a profession that doesn’t have so much drama, doesn’t require constant study and doesn’t carry the same risk. Something like neurosurgery or maintaining the Springfield Nuclear Power Plant.

But seriously - what I would tell myself is, in the words of Brene Brown, to “dare greatly”. It took me a long time to gather enough courage to stop caring about what others may think and go out and share my thoughts with other people and see what they thought. I was a consumer for a long time before I imagined being able to produce anything worthy.

We, threat modeling practitioners, are fortunate in the communities we have been building. I am just back from OWASP Global AppSec at Dublin and I couldn’t stop marveling at the relationships built in this corner of the appsec community. Not only are people genuinely good, but as a rule, we are all interested in pushing each other up. We review each other’s output, we collaborate on joint projects,  we participate in each other’s talks and we cite each other constantly, not because we think we must, but because we can! We disagree respectfully (most of the time!) and we question everything, all the time, to make the whole better.

So my advice to young me, and that I want to extend to everyone in this community, is to dare greatly. Come out and share with us what you have - your answers but also your questions. It may not always be a great experience, but you (and we) will be better for it. Don’t wait, come in, the water is great!

Hey @joshdub - I have a speech prepared for those cases: “I don't know who you are. I don't know what you want. If you are looking for bugs I can tell you I don't have your source code, but what I do have are a very particular set of skills. Skills I have acquired over a very long career. Skills that make me a nightmare for people like you. If you let your developers ellicit threats now that'll be the end of it. I will not look for you, I will not pursue you, but if you don't, I will look for you, I will find you and I will point out all the vulnerabilities you could have avoided". I try to do it over the phone with a Liam Neeson accent, but if you ever heard me talk, there’s no way.

Threat models are a great example of GIGO, garbage in, garbage out. The threat model will only be as valuable as the detail in which the system is modeled (there is no perfect representation, as the Threat Modeling Manifesto points out, but you can model with a more useful level of detail than not) and the effort put into eliciting threats out of that model. 

You can refer to some of the previous answers for some of my usual spiel in these cases, but there’s something else I want to point out: threat 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 for one reason or another. Need to make sure you are interfacing right with another team or another system ? Compare threat models! See if you have the same attackers in mind, if you are executing security contracts and if the responsibility is being shared correctly. 

At the end of the day I think I have had the best results in convincing people to threat model when I manage to get them to see that the benefits carry beyond the time spent doing the actual threat model, and benefits compound as the result is shared and used correctly.