Q&A

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

  • 6 February 2023
  • 20 replies
  • 309 views
izar
Userlevel 4
  • izar
  • Participating Frequently
  • 15 replies

Hi everyone, I’m Izar Tarandach, a Sr Staff Engineer at Datadog these days helping develop security products. Previously, I helped Squarespace, Autodesk, DellEMC RSA, IBM, and Bridgewater Associates design and implement product- and enterprise-wide security solutions, offering guidance in the design and implementation of secure systems and products.

I’m also a co-author of "Threat Modeling: A Practical Guide for Development Teams", O'Reilly with Matthew Coles, and part of the "Threat Modeling Manifesto" band. I wrote the Continuous Threat Modeling Handbook and lead the OWASP pytm project, the first (I think!) threat-model-with-code framework out there.

Currently I am looking into the bridge between Observability and Security. I’m excited to talk about that, secure development and engineering, threat modeling, careers in cybersecurity, Threat Modeling Manifesto, my favorite movies, dogs, what is that funny fish and anything in between.

How it works:

  1. Add your questions below any time before or during February 20th, 11:00am-noon ET

  2. Tune in on Monday, February 20th, 11:00-noon ET, I’ll respond to all the questions in this thread.

"No, really - what could _possibly_ go wrong?"

20 replies

BorjaGC

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?

VíctorG

Hi @izar! First of all congratulations for your amazing career, very impressive! Thanks to Threat Modeling Connect we have the opportunity to get in touch and to know the point of view of such talented people, so I wanted to get the chance. 

 

My question is about the future of threat modeling. I like to be optimistic and I really would like to have a collaborative environment where all the companies could share their own models, and everybody could take advantage of it, making every system more secure and robust just following best practices and advice of each system experts. That’s probably too optimistic, but how do you see the future of threat model in about 5 years?

jmgarcia

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?

JamesR
Userlevel 3

As someone who was on the front lines for creating the threat modeling manifesto, what do you think the next phase of threat modeling will look like? What do you see as the biggest obstacle to get us to that more ideal future state? 

James Rabe
Brook Schoenfield
Userlevel 4

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?

dFont

Hello @izar, thanks for this AMA session!

I have been developing for a few years and just a few months ago I started reading about threat modeling. My first conclusion is, why weren't all development teams doing this before?

From a developer's point of view, in my opinion, the concept of security is an abstract layer that is taken care of by other teams and developers just with a few tests plus QA team testing already feel that they have accomplished their tasks in a secure way.

Now that I am starting to model, my question is, how can I quickly convince my fellow developers to start using threat risk modeling in their day-to-day work? Especially since development cycles are always short and spending hours on other processes is often difficult to justify.

Thank you very much!

R
Userlevel 1

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?

 

BashSergei

Should Threat Modelling be included in Governance within organisations to increase inclusion? Because I believe Threat Modelling to be an overall concept not just for developers for their applications.

joshdub
Userlevel 1

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.

Josh, out.
izar
Userlevel 4

Hi everyone, and first of all thanks for the great questions! I’ll address them to the best of my knowledge and experience.

With that said, caveat time! Anything I write here is my opinion, not my current or past employers, and definitely not of my co-authors and collaborators (who have stupendous opinions themselves and you should definitely check them out!). 

Anything I write here is not the answer or the way of anything - they are my answer and my way of things, and reflect my experiences and the time I spent thinking about this stuff. Not only will your mileage vary but it must vary! I invite you to take my failures and successes and used them as you see fit to build your own approach to this thing we call Threat Modeling (and to Security in general). 

With that said, onwards to the questions!

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

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?

 

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. 

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

My question is about the future of threat modeling. I like to be optimistic and I really would like to have a collaborative environment where all the companies could share their own models, and everybody could take advantage of it, making every system more secure and robust just following best practices and advice of each system experts. That’s probably too optimistic, but how do you see the future of threat model in about 5 years?

 

Hi @VíctorG ! Thanks for your kind words. 

3...2...1….AI! ChatGPT! 

There, now that we got that out of the way, let me go back to your actual question, which I think is an extremely important one, specially the way you put it. 

I like to be optimistic too. Doesn’t happen often, no, wait, I can’t remember when it last happened, no, wait, I never did it and I am talking based on what I hear other people say about being optimistic. I hear it is nice. I am a realist. Which means, basically, I am a pessimist. 

So yea, I will agree with you. Sharing and collaboration between companies will probably not happen, even though there’s big talk of collaboration. Consortiums, committees, all that good stuff. if it was going to happen, it would already have happened. 

But even the pessimist in me has hope! And here’s where I hope to see Threat Modeling going in the next 5 years, led in no small part by members of this community:

 

  1. Threat Modeling becomes part of corporate culture. We have made huge strides in making TM part of developer culture. As Security (or, as they call it nowadays Cybersecurity) makes its inroads in the boardroom, I expect “what could go wrong?” to become more and more a question asked at high levels, and expected to permeate to less lofty parts of organizations. 
  2. Automate the boring stuff. Threat modeling tools will serve as bridges and repositories of knowledge, and as helpers in avoiding past mistakes, and will direct efforts towards the more “chewy” parts of systems, freeing thinking time to things that are less prone to requirement-think, like privacy and business processes. 
  3. Security contracts (check @Brook Schoenfield writings for more details) and security design reference models will be identified and emerge more easily (another opportunity for threat modeling tools!) inside organizations, leading to opportunities where we can “threat model the shift out of it” (you heard it here first, more to follow!)  - we will be able to focus on on those things that go out of the standard way things are done in a particular environment
  4. Developers won’t think threat modeling is something that happens to other people, and instead will adopt it as part of good and sane systems engineering.
"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

 

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?

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!

 

 

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

As someone who was on the front lines for creating the threat modeling manifesto, what do you think the next phase of threat modeling will look like? What do you see as the biggest obstacle to get us to that more ideal future state? 

Hi @JamesR, thanks for taking the time to ask!

I answered most of it in @VíctorG question, but I like the thing you called out - the biggest obstacle.

My take on it? The biggest obstacle is time.

What we are asking people (not only developers!) to do takes time. Not only linear time, in the sense that it takes X hours of training from not-knowing to having-a-clue but in the sense that development happens in units of time, that we are asking people to allocate away from the activities they “really want to do” or that “are productive” or that “offer a bigger ROI”. 

Until we get to the point were we have convinced people that it is worth to re-allocate those units of time, we will have a hard...time….doing anything else. 

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

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?

 

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.

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

 

I have been developing for a few years and just a few months ago I started reading about threat modeling. My first conclusion is, why weren't all development teams doing this before?

From a developer's point of view, in my opinion, the concept of security is an abstract layer that is taken care of by other teams and developers just with a few tests plus QA team testing already feel that they have accomplished their tasks in a secure way.

Now that I am starting to model, my question is, how can I quickly convince my fellow developers to start using threat risk modeling in their day-to-day work? Especially since development cycles are always short and spending hours on other processes is often difficult to justify.

 

Hi ​​​@dFont - thanks for taking the time to participate in my AMA!

First of all let me congratulate you on being a developer on a security journey. As you pointed out, many developers see Security as somebody else’s problem, and that is in my opinion, the biggest problem! You wouldn’t catch a developer dead saying “performance is somebody else’s problem”, would you? 

Also notice, there’s a huge distinction between “accomplishing their tasks in a secure way” (which is a must) and developing securely. You can have the most secure CI/CD pipeline in the world and still produce insecure systems. 

I’ll refer you to @BorjaGC question above for an initial take, but I want to leave you with another one - secure code is quality code. Developers are, and should, be proud of delivering quality code. Nobody wants to be the main generator of wtf/minute in a code review session. So it is important to make sure that developers understand that the basics of security can in great part be taken care of by creating really high quality code - check your returns, check your boundaries, check your assumptions, don’t ignore edge cases, etc. 

IMHO developers should take as much pride on the security and safety of the code their produce as in their performance.

 

 

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4


* 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?

 

 

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!

 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

Should Threat Modelling be included in Governance within organisations to increase inclusion? Because I believe Threat Modelling to be an overall concept not just for developers for their applications.

 

Hey @BashSergei , thanks for popping by!

I am going to chose to understand “inclusion” in the sense of the practice being included in the set of other “security things” happening. Hopefully that is what you meant, otherwise, please let me know.

I think you are totally correct when you say Threat Modeling is an overall concept not just for appsec and developers. It can, and does, bring better outcomes at many different layers and for different stakeholders.

Governance is an example of these. There are many controls that Governance may require that will be reflected in a threat model, either as mitigations, requirements or, gasp!, findings. 

Governance can be a great ally in stressing out the benefits of threat modeling in an organization, BUT it cannot be the sole motivation. That, in my opinion, may lead directly to it not being adopted as a valuable everyday practice but rather a mandated, check in the box activity that will certainly fail to bring all the possible benefits it carries. 

"No, really - what could _possibly_ go wrong?"
izar
Userlevel 4

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.

 

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. 

 

"No, really - what could _possibly_ go wrong?"
Brook Schoenfield
Userlevel 4

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?

 

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”.

 

 

 @izar This! “reluctant to point out bad design”. Yup. 

With a proviso. You said it above, Izar: we’re all in it to make things work, to improve, for results. If the “bad design” is really in the way, I will speak up.

 

OTH, and this is I think perhaps stylistic? Or perhaps, really important? If dev insist on their bad design, then it’s my job to secure it if I can. 

That noted, I’ve won a couple of internal awards for reporting bad design/implementation (it was REALLY BAD) over dev’s heads. Didn’t make any friends. But then, I felt my responsibility to the company was greater than making friends.

 

Reply


Terms and Conditions and PrivacyCookie settings