DFFML Rolling Alice: Progress Reports, 17 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Living Threat Models Are Better Than Dead Threat Models By John L. Whiteman and John S. Andersen

Description

Welcome to Second Annual
OWASP AppSec Pacific Northwest
OWASP Chapters of Victoria, Vancouver, and Portland have combined to deliver an amazing event for application security practitioners on June 11th, 2022.

----------------------- John L. Whiteman ------------------

Security Researcher at Intel Corporation

John L. Whiteman is a security researcher for Intel and a part-time adjunct cybersecurity instructor for the University of Portland. He also teaches the UC Berkeley Extension’s Cybersecurity Boot Camp. John holds a Master of Science in Computer Science from Georgia Institute of Technology. He possesses multiple security certifications including CISSP and CCSP. John has over 20 years of experience in high tech with over half focused on security. He can also hear John host the OWASP PDX Security Podcast online. John grows wasabi during his “off” hours.

https://twitter.com/johnlwhiteman1
https://www.linkedin.com/in/johnlwhiteman/

Presentation Abstract
Living Threat Models Are Better Than Dead Threat Models
The cornerstone of security for every application starts with a threat model. Without it, how does one know what to protect and from whom? Remarkably, most applications do not have threat models, take a look at the open-source community. And, even if a threat model is created, it tends to be neglected as the project matures since any new code checked in by the development team can potentially change the threat landscape. One could say that the existing threat model is as good as dead if such a gap exists.

Our talk is about creating a Living Threat Model (LTM) where the same best practices used in the continuous integration of source code can aptly apply to the model itself. LTMs are machine readable text files that coexist in the Git repository and, like, source code, can be updated, scanned, peer reviewed and approved by the community in a transparent way. Wouldn’t it be nice to see a threat model included in every open-source project?

We need to consider automation too to make this work in the CI/CD pipeline. We use the open-source Data Flow Facilitator for Machine Learning (DFFML) framework to establish a bidirectional data bridge between the LTM and source code. When a new pull request is created, an audit-like scan is initiated to check to see if the LTM needs to be updated. For example, if a scan detects that new cryptography has been added to the code, but the existing LTM doesn’t know about it, then a warning is triggered. Project teams can triage the issue to determine whether it is a false positive or not, just like source code scans.

We have been working on this effort for a few years and feel we are on the right track to make open-source applications more secure in a way that developers can understand.

A

So yeah I'd like to once again thank my sponsors, github synack, vlsd security, security, innovation forward security, websec, plurilock, netspy and scicode for making this possible, and uh our next speakers are john whiteman and john anderson. uh They're, going to talk about living threat models are better than dead thread models. I totally agree.

A

John whiteman is a security researcher for intel and a part-time adjunct instructor for the university of portland. I'm also an intel alumni there, john myself, and it's good to see you again. He also teaches the uc berkeley's extension cyber security boot camp and that's actually quite awesome. John holds a masters of science in computer science from georgia institute of technology. He possesses multiple security certifications, including cissp and ccsp.

A

He has over 20 years of experience and high tech with over half of it focused on security, that's kind of like mine as well half on security, half not on building things. You can also hear john host the obas pdx security podcast online and uh john grows wasabi during his off hours. I'd like to get some of that john.

A

When we meet in portland, eventually he's driven by passion for exploration and understanding, he's currently analyzing software development methodologies and technologies to identify and proliferate best practices across organizations so as to optimize asset allocation and alignment with desperate organizational strategic principles, he's excited to explore the application of these techniques on human and ai agents. His mission is to help foster an environment which maintains agent freedom, privacy and security.

A

We also have a another fantastic john joining us john anderson. uh He is driven by passion for exploration and understanding his currently well. I think that part that I read was for john anderson, so I'm going to stop here and I'm going to pass it over to you, gentlemen, and uh looking forward to your presentation awesome and I'm going to stop sharing.

A

Can you see my screen.

B

Absolutely perfect, yeah and by the way, because there are two john's just like the john squared thing. The intelligent questions like the hard to answer, one that goes to john anderson, so we'll know the context of it, but anything.

C

B

uh You know trivia for tick tock or something that's on my side. So anything like that john gets. The hard questions sounds.

A

B

All right well, thank you so much. This is my favorite day actually of the year, the favorite time, because in portland here it's we finally got back and we're with the rose festivals has is back in progress again and it is a little rainy but cool it's just a perfect day and- and both of us are really, we really appreciate you coming and and taking some time and and listening to us. We, we really are excited about this, but yeah as our as the title goes. Living threat models are better than dead throughout models.

B

um The opinions expressed here are our own and not necessarily our employer, which we have to say and about this presentation, we're going to assume that you already know something about threat models uh and it's not about any particular threat model methodology. We have the old school stride, pasta, vast trike and our favorite dread by the way.

B

If anybody wants to collaborate and create a cartoon for this, we're totally into this would be funny and we're agnostic to threat modeling tools, although we will be presenting a couple of tools in it in a couple of different contexts, particularly about some of the nice things that they have, but the limitations as well. What we're really trying to do here? Our primary focus is the collection and definition of data for threat, modeling use. So john, can you talk just a little bit more if you want beyond what was said.

C

Hey yeah sorry mute button uh yeah, so I'm john I'm at intel. Also with john and right now I'm focuses on intersource, and so you know, analyzing software development methodologies proliferating best practices uh playing around with those concepts. uh You know uh hopefully feeding best practices to developers, internal and external and then also exploring that on on ai agents. um Thinking about you know, how can we get ai to follow our best practices and living threat models? Are you know a part of that.

B

Cool, thank you, john, and it was already said to not only microsoft and by the way, the word micro. All that means is that I started out with like five wasabi plants, and I have one left. That's living, so micro sounds good, but it's actually a result of a failure as a wasabi grower and also make kombucha. But that's an old person thing I'm not going to get into why we do that now something about john squared and what kind of led up to this presentation back in 2016.

B

We both worked as security researchers for intel's open source technology center. Unfortunately, that's not around anymore, but at that time our work. We didn't really work together, we're on the same team, but we're doing different activities.

B

Now I left intel 2016 for a few years and I went to oregon health and science university and there I worked on a project called sas and the bad human project, and this is where I was using machine learning to predict risk across hundreds of web apps at a time where they didn't really have any expensive sas tools, and this was risk prediction from say, source code for web applications, and I presented that information to b-sides in 2018 john a year later did something called down the dependency rabbit hole.

B

John, you want to describe a little bit about that work that you did.

C

Yeah in with that project, uh what we did was we looked at open source dependencies. So, if you're familiar with like the open ssf, identifying security threats or metrics working groups, a similar sort of concept, you know analyzing open source projects trying to understand uh whether you know there's something, secure and robust enough from uh from a general health and and their uh predictive life cycle. Health uh standpoint, rather than just you know, do they have cves or something like that.

B

And one of the things we discovered so I went back to intel and we started meeting because we felt like the work wasn't really done. We felt like we had some answers, but then all and sooner than later we found. Fundamentally, we were trying to solve the same set of problems. Number one was to find ways to dynamically: assess risks associated with these projects to collect a bunch of data from various git repos and other sources.

B

Three, we we need- and this is a big bulk of what we're going to be talking about today and that is define an open source threat, modeling language, four, integrate these systems into ci cd frameworks, fi, promote and socialize our efforts for adoption. That's why we're here today, hopefully get people on board and then, finally, if we solve all these things, we made the world a much more secure place. We would go in and retire and when I first created the slide, I showed it to john and john just kind of said.

B

You know there's a lot of words on this slide. What we can do, let's just go straight to six and retire. So we're done with our presentation. Thank you. All have a good day anyway enough of that. So when apps evolve so does the risk, and so should the threat model. At least that's what you would think typical threat model workflows are like this. The team, the project team, will create an architecture, design they'll, go then and do some threat. Modeling and usually it's a manual process and manual is good.

B

We think manual processes are good and this would be the bulk of the threat model early on in the project. Then they'll go off and save that threat model to store it somewhere and usually, at the same time, they're committing code, they're, doing manual code reviews if they're doing good, secure quality assurance, also static code scanning sas tools, dynamic testing like gas fuzzing.

B

If you're not buzzing, you should be ashamed of yourself, everybody should be fuzzing and then, through this whole process, they're finding and fixing vulnerabilities, it's evolutionary things get checked in there's a release every now and then and yeah, maybe an escape too. You might get a cve back, but if your project is right, that's transparency, you're, finding and fixing and giving patches back to your customers the end users as soon as possible.

B

Now one of the problems with this flow is we have we call this hadrian's wall, but we couldn't find a good image for hadrian to go this high up. But what what's happening is on the left hand. Side of this is your threat. Model is not really evolving, as it is on the right hand, side, and so what we call. This is the tombstone threat model process or ttmp.

B

Now it's a bit of a hyperbole to say that a threat model is dead. If you don't use it or update it after a while, or your threat model expires. In fact, your threat model is probably going to be pretty much intact, as as long as it doesn't. Funnily change the environment and all that, so we like to use best use before or best before, and a great analogy would be something like this. It's late at night, it's saturday, your refrigerator is, is empty.

B

Your cupboards are bare, but then you're under the sick sink, and you see behind the drano this package of top ramen and you're. Looking at it- and it's saying hey you know best before was like two years ago, and you got to make that critical decision and that decision is. Are you going to eat it or not? And with top ramen, it's probably not a it's going to live longer than the universe. We know that, but with milk I don't even think they used best before I think they use expiration.

B

So if anything, when you walk away from this presentation today- and somebody asked you that john squared meeting uh or presentation, what did you learn from there? What we've learned is that threat models are ramen and not milk, and I think we should be john. I think we should create swag for this. I just thought of that.

B

Okay, all threat models should be machine. Readable. Absolutely, that's! That's things that we found right off the bat. So what we normally see for typical threat model storage is you got your threat? Model teams might be doing it in something like powerpoint or word. They may be doing their their diagramming and visio, or something like that and they save it off to something. Now these can be pretty big files.

B

Sometimes teams would then do you know, converted or exported to pdf, and those are much smaller in most cases, but they're read only and they're not really parsable I've seen teams go and do threat modeling and take a picture say of a whiteboard, and they use that diagramming they had on the whiteboard as their threat model. Nothing wrong with that uh or they've actually used a tool like paint, microsoft, paint or dim. You know, hopefully they didn't save it as a bmp, but that's also part of what they're using for a diagramming piece.

B

Other teams now I see more often are doing something like draw io or some some related ones, and what happens is when all of these applications save like you save that application to data. We call this application specific languages or asl, we'll use the draw io as an example. Now most people, if you've used it before, are aware that there's an online version, but if you didn't know, there's also visual studio code version, it's a plug-in and what's really cool about.

B

This is, if you're, already in visual studio, you're, probably in the same place, where you're doing your coding and everything else you're under your repo directories, and so when you install this plugin, it comes. If you see, on the left hand side here, they call them stencils or templates whatever, but you got these pre-made objects and out of the box draw, I o comes with threat modeling- and you see here all these nice little things that you can easily drag over to your canvas and you can quickly start to diagram now.

B

This threat model that I have here is going to be the one that we're going to be using throughout the the rest of this presentation. But there's it's very simple. We have three major components. We have a client application, could be a browser, it's out of scope and it's communicating to web server. That's in scope for us, it's talking across the network. It's doing the right thing: it's using https tls for encryption and authenticity and then on the other side, we have a customer database and again we're talking to it across the network.

B

This could be behind the dmc. It could be off in the cloud somewhere, but we're trying to do our best and these lines in blue these dashed lines in blue. This is going to be our truss boundaries, so we can easily diagram with these ready-made pieces. We have other areas if we wanted to add style and all that, but again we're really trying to threat model but use you know not spend our time to make it look pretty. Now. If we go and save this um there's various ways, you can export it as an image.

B

You can do all that, but they also have what they call a dot draw io file, and all that is, is this machine, readable, xml and xml is what we call a general purpose language. We love, we love gpls.

B

Other examples are json yaml and if you take a look here, there's a lot of data here, but you can, if you just take a little time, you can tell that there are some areas that are. You know, first of all, there's a very small print footprint, but there are areas where you start seeing things like mixed data and the the content, and so we don't necessarily care about page width.

B

That's not going to be a vulnerability of page width is greater than 850 pixels, but we do care about these other areas like the database and some other components from there threat. Modeling tools are dangerously shiny objects. This is the biggest mistake I think people make and we did it too, and this was about, I say the second year where we started talking about this.

B

We said: hey, you know, that's great, withdraw io and powerpoint, and all of that, why don't we just build a tool that does everything not just complementary, so we could have diagramming could have your apis reports templates stencils. We even talked about gamification and even something like putting on like a virtual reality. Headset grabbing pieces in the air and putting things together right, but when we realized quickly is that this whole thing, starting with the tool, that's so 1990s and it's always a big mistake.

B

What we found is that most model specific tools today they're not ci cd friendly and it's not because they don't have the features to automate, but it's because of a lack of a common, open foot model language and what we mean by that is, when you save that asl data app one app two. This could be something like jira. This could be some other tool out there.

B

The teams would have to build some custom tools to talk to these other components, to integrate into their ci cd environment and that's a tough call, especially if this is just a single purpose. Language and other people don't use it, and I think that's one reason why we're seeing these challenges, and also it's hard enough to get teams to do security in the first place.

B

One thing we notice out there too: there's not a lot of threat, modeling tools- if you look there might be maybe a dozen or so there's a bunch of others that have false starts, but there there aren't that many- and I grabbed five for this table here to illustrate a few things. um We all maybe know kairis, which is cool, because it also includes things like social engineering as threats where a lot of tools kind of miss that but microsoft threat, modeling tool, that's gone through a few iteration, our favorite omos fret dragon fragile.

B

If you haven't heard that look that up now and threat modeler and they can come in all types in terms of licensing, many are open source which we like for what we're trying to do. Microsoft is free, but it's proprietary and threat. Modeler is proprietary, I'm not sure if they have a community version, but you're going to pay money for the good stuff. When we talk about data, we're coming back to the data, there's really two major formats that we care about. There's the asl stuff that we talked about again.

B

That's the application specific one, and most of these application has have these export formats too, and if the export formats are not really parsable like pyrus again odf rtf doc files are pretty tough to to manage when you're parsing, even the microsoft tool does have html, which is a domain specific language, but maybe not the best and olaf says pdf, but the sl formats json. The thing I want to talk about fragile, though, is for both the asl format and the export form formats.

B

At least it supports a gpl, a general purpose, language yaml on the asl format and json in one of the export formats, and we'll illustrate why this is so crucial for what we want to do. Here's an example of the microsoft, the latest tool they again went through a few versions. The latest version has support around azure and it's it's a great tool and it's gui base. You start it up. You have a nice canvas here.

B

uh You can put you put your objects in here, similar to what we saw for draw io, but the nice thing about this. It includes all of these attributes for the given type of object, and in this case this is process. So when you're thinking about threads um a process might be, is it running elevated? It doesn't have input, service surfaces and things like that. So this is what is really great about this tool.

B

Now, when we go off and save it again, it's gui driven, so you have to start it up and do all your things, but when you save it, the asl part comes with this dot. Tmz file commit this to memory right it. This is what I call ponderously parsable. It is xml, but it's got a mix of of html, I see hieroglyphics in there.

B

I don't know sanskrit and everything is in there if you want to parse and figure that out go for it, but the actual export file is html and I don't have anything really bad against html, but it can. These things are a bit dynamic right based on the structures that come with it. So we'll have about the threats, maybe a summary and down here. It will have that diagram that we created in the canvas. But this is embedded as a as you know, the binary inside of it.

B

So what happens is because this is not really ci cd friendly. What you need to do is open the app you have to export that report to html. Then you got to go and extract this diagram. You know use something like beautiful soup, but there you go now. I was going through the msdn format thinking well, I must have the old version because I'm sure they got they did something better here. This is back all the way from 2017, where somebody was saying that hey wouldn't be really cool.

B

If we could take this diagram and map it to the actual things back here like we're. Talking about today come on microsoft, get with the program and we feel that they kind of dropped the ball here, because it's not really again ci cd friendly by the way we have our own favorite threat, modeling tool.

B

This tool is not in the list or the table that I showed before, but this is john and I's favorite tool, it's the etch-a-sketch and we were talking about um if somebody comes in for a job interview and they're, a security person, and you give them a scenario where they have to do some diagramming here for the threat model.

B

We give them that scenario and we tell them okay, you got 10 minutes to do it and we give them an etch, a sketch, and if they run away, we would hire that person if they stayed- and you know finish it then we'd be very scared of that person. Anyway. Sorry about that um application, specific data, we just talked about a machine readable, very specialized mixed content, not portable heavy weight right general purpose, languages, machine, readable, generalized, json, xml yaml. We love it because they're widely known they're accepted um they're, easily recognized you.

B

You don't have to know how to create the parser or use parsers for them. In fact, that's the nice thing about them is the parsers are already created. You never want to write your own parser right, michael libous of the old days. Never parsers are hard great presentation.

B

What we want to talk about next, though, is domain specific languages, dsls again machine, readable notice. This is the common thread: they're specialized and they're idiomatic to the domain very compact and lightweight. So some that you already know html sql uh html, you think of web pages. Sql. Do you think about relational databases right and that idiomatic piece that I'm talking about? That's what gives us sql injection errors right, there's specific things about it. I want to talk about two other languages.

B

These are diagramming languages, modeling language, mermaid and plant uml, and you may have seen these already in action and may not have been aware what they were.

B

So now, if we talk about mermaid, just with a few lines of code, the mermaid syntax here, if you've, never seen this before- if I click on this, it's wonderful. You get this wonderful diagram. All of this information contained with just a few lines of code, we're not talking about an image. We can parse this, but the challenge here is this language. You would have to figure out how to parse it. It's it's very specialized.

B

Let's take a look at another. The competitor plant, uml uml by the way, is a modeling language. It's domain specific, but it's it's it's based on uml and the same thing with just a few lines of code. We can come in here and define an equivalent equivalent threat model with this, at least with the diagrams. Now, obviously, we'd have to put more information in here, but we like the fact that, oh now we have some syntax.

B

Now we have some structure, but it's not quite what we want yet, but at least we have something here that we don't necessarily need a full-blown tool to do things with. So what is our goal? What why am I talking about languages up to this point anyway? Well, as I mentioned in the beginning, we want to define a threat model language, a threat, modeling language, an open language and open means. We want to do it as an open architecture with heavy community involvement.

B

Now, when I first just yet another slide, I was working with john I'm like old school. I mean my threat models, go back, you know uh pre-civil war days, you know, and my and I'm thinking like we got to get the standards team in we got to get the iso people in we got to get the ieee people in and john was really quiet. He didn't really see anything, and then he came john. Tell me why this is a better way of an open architecture versus the way I was describing.

C

Yeah so yeah and john- and I we played around with this this standard architecture um and uh came to standards are hard. You know standards require that everybody agree on on the whole standard right. So instead, what we're suggesting is. Okay, let's agree on a few things and then we can all have you know sort of interoperable uh architectures as within this realm of the open architecture, and eventually you know- maybe we ideally we converge on on some standard right, but but we we can't, let's not start there.

C

You know, let's not start climbing up the standard mountain without flushing this out as a community first right, so the goal is to say: hey here's a couple pieces of metadata right, which we think you're, which we think the the open architecture should include. If you decide that you want to do something slightly differently, that's fine, we're all still going to be unable to interoperate. As long as we include these several pieces of metadata.

B

Yeah perfect and we didn't want to pay, you know. If you want to download the standards you have to pay for it. The people that are really doing the work is what we want. The people here again we're thinking of a ci cdi, cd supported system. That's where we're looking at with the troops on the ground. So what this diagram represents here is this gray area. Is that standard?

B

Consider that the paper that has the grammars all of the dependencies, the academic paper, if you will and then what we want to do- is create this domain. Specific threat, modeling language from that, and we want to use it and represent it as a gpl, do it in gpl. So again it would be something like json, xml or yaml. We want to avoid that specialized syntax like we like. We saw for mermaid and plant uml, because that's just going to be a big turn off.

B

If we can represent this as a gpl language and we're going to show you example in a second, how important that is, as as a first impression of anything for adoption from there. We believe that, once this is defined, they will build it. So do you remember when we talked about going building those tools first and doing all these wonderful things again, that's so 1990s!

B

If we have this language already defined, then people will say: oh I'm going to invest my time, I'm going to go ahead and build a threat, modeling tool, but my tool is going to be cooler than the other people, but it's going to be based on that same language that everyone else is using. It's going to be ide, plugins, uh github, rendering, as you know, github does mermaid and platinuml and code syntax, and all of that or even editors for it. So fragile is one of our examples.

B

I just learned about this about a month ago, a co-worker, my rich hogan was talking about this and also these domain-specific languages and why I got really interested in so some credit to him. The idea is that if you take a look here, this is a threat model. It's represented as a yama file that fragile understands.

B

Now, if you don't understand anything about the, maybe the structures, but you know something about threat modeling, you can look in here and you can say: oh well, I know threat models have security requirements. I know a threat model should have something about assets. uh Maybe some metadata on here. This is the oldest threat model, the battle of hastings in 1066, and there was some overlaps or overlooked by errol and anyway you know what happened after that.

B

So, in addition, if you look at a full file, there's assets, there's flows, there's trust boundaries and there's customizable things. That's key too, and you have these tags where you can build things that might make sense to your business and and nobody else right stores nicely as we in the repos as a text file and it's ci cd friendly. It's a fragile, that's the command tools. Name, it's written in golang. It would ingest this yaml file generates these wonderful reports off the fly and you can do audits and we're going to talk about.

B

Why audits are important and why we need to be doing this. So fragile is a great one. Highly recommend you take a look at it uh for the open source. By the way we have a github repo, we'll send you all the link and all that for it, where all the slides, but all the stuff that we're working on some of these demos. That information is in there as well now scan threat models like you scan code.

B

Well, if we have this wonderful threat, modeling language, this open architect, language- we can do some of the following, which we really can't do right now, number one. We could do things with the threat model file itself. We can write a linter for it. We can look in the file and we can do things like. Oh it's missing acids. Why does your throat model have no assets or some labels are missing? Maybe we see things like duplicate names, or we can even look for the age of the threat model in that best use before date.

B

We can do that as well, and these are quality checks that we call it, but we can also do scans against that same print model file for vulnerability checks like a sas scanner. In this case, we might be looking for a lack of or incorrect mitigations.

B

Maybe you have a network connection, it says http, but you're, not using tls. That is a vulnerability or you have nothing on there at all the other thing which we'll talk about later- and this is the core. What I believe is for this whole presentation is with this threat model. You can now start to model or monitor for these check-ins.

B

If you remember that evolutionary thing that was talking about between the existing threat model and the source code, so, for example, as people are checking things in uh all of a sudden, your source code starts containing network libraries or crypto or something of that nature. But your existing threat model says nothing about networks, says nothing about cryptos that can raise an alert and say hey. You might want to go back and take a look at your threat model.

B

It looks like we're getting some stuff in here that you haven't considered before could be a false positive could be real. Who knows.

B

Now, because we don't have that language, yet we can use something existing and we want to use our our our beloved owas rep dragon. To make a point and again, this is open source threat model 2, hopefully, here in oas, we know about it: goodwin, gatson, redding and all those folks gatson is one of our own from the pacific northwest, I believe, he's still up in vancouver washington state. So it's great to have that identity as well. There's two flavors of threat, dragon one is a standalone tool and the other one is a web app.

B

The web app is pretty cool, because what you can do is configure it to point to your repo and it'll automatically do the commits into it, and so all of this, this threat modeling, is integrated into your repo and, of course that's what we've been talking about really nice now, as I saw as we saw on that table before, there's really two flavors, the asl is exporting as json and then the actual exports themselves are are pdf in this case. We're going to reverse it.

B

Normally, we want to look at what the exports are, but the threat dragon's asl, the json representation- is actually pretty nice and easy to parse. So this is the same threat model that I was showing and if we saved it off in threat dragon. This is the actual asl data that we get and just at a glance, it's pretty easy to figure out where stuff is again.

B

We get this mix of presentation, data and some other trackers, but as you would go down- and we have this up there- you can see that, where you know the client app and all the data and some of the metadata that's associated with it, we would just want to go off and depart some of this stuff out to create some things and that's what we're going to do for this demo, I've created three. I created three threat models with threat, dragon and they're all based starting with the same thing here with our web server.

B

The first one is good and I saved it as good.json now, when you're in threat dragon. When you click on any of these components, you would get this little box that comes up and it'll. Ask you some questions, like you know, give it a label. Is it encrypted? Is it over a public network and so that's about what we get and maybe that's good enough. So we label it yeah it's over a public network, but we're doing the right thing. We're encrypting it accordingly and that's good.

B

We click on the backend network connection again same thing, but in this case it's not over a public network but we're doing the right thing again: we're labeling, that's a quality thing and encrypting. That's a mitigation against such a vulnerability and then finally, the customer database stores credentials. Okay is encrypted yeah. At least this is what we're trying to do, of course, there's many other things that we can do, but for the sake of this demo, these are the three things that we think have a you know: a complete threat model uh for this example.

B

So this is a good threat model. Now a bad threat model is where there are some problems. It could be a vulnerability problem. It could be a quality problem now, john. I got really excited about this because it's like about a year ago, year and a half ago. I think that was longer now I don't know and as everything's melting together. But um do you remember like the intentionally vulnerable web application or the intentionally vulnerable c program that used for afl fuzzing?

B

And all of that we got real excited for training, because we want people to learn how to threat model. We could create a project that has intentionally vulnerable threat models and we can teach students to say what's wrong with this threat model and we can do it in such a way that well we'll show you how you can recognize that and and grade it if you want. So in this case again, I'm looking at these three attributes, I'm calling this protocol now http, I'm taking the tls out.

B

It's not encrypted it's over a public network, very bad idea. In the back end side, we are encrypting in. We left that, but we're leaving we left out the the label, so the label is more of a quality issue, even though this is not a real vulnerability and then the back end yeah we're still storing credentials, but we're not encrypting. So we essentially have two vulnerabilities with the uh the encryption part, the tls and then the non-encrypted database, and then we have one quality issue for the protocol and we call this bad.json.

B

Now there has to be an ugly, I said: well, I'm kind of stuck. Where am I? What is an ugly threat model? What the heck is that- and I wish I wish we're all in person, because then I would ask you to raise your hands and stuff. What is an ugly threat model? In short, it's no threat model. Shame on you! Your grandkids will come to you they're, going to ask your grandma grandpa. Why you know? What are you proud of?

B

What are you you know ashamed of in case you tell them I'm proud of you the most and and what are you ashamed of the most? He said because I never threat model and they just never look at you the same way. So this is what we call it, and this ugly.json is an empty file all right now. What I did, because you saw how that syntax was very simple um application. Specific language, I wrote a little parser and if you take all of these things out, all I'm doing is just extracting the info.

B

I want ignoring the presentation data. You can write this in maybe a few dozen lines of code or not. In fact, I wrote this probably about 30 minutes. That's how easy it was and that's the beauty of having a json structure. You know you understand, json, you understand the structures, it doesn't take very long. I then created another one called auditor which uses parser consumes that that threat dragon file, and then it goes and looks for some specific issues again.

B

The three that we mentioned here would be a labeling issue or it's the http, not https and stuff. You would probably do this. These rules in some text face file and then you know consume it accordingly, but just for just for the sake of this presentation, you can see the power here with just a few lines of code on each side. Where now we can parse this threat model and we can start doing things like auditing uh the threat model. So let me show you the screen here.

B

And what's happening here is I'm going through three all three cases, the first one, the good is that empty or that good file. So here's good, we get nothing back, which means it's good, the extra status, bad, the bad one. We get there three issues and then the ugly it just crashes my program, it's like perfect for that anyway. So that's what we do and you see this thing is repeating now imagine this in your continuous build environment right you just you every time you get!

B

This commit you're, going to run these things and then you're going to set some rules there, and if you are getting something, that's a non-zero coming back, then you take whatever appropriate action or or maybe there are known issues and you look at the file, but you know the sky's the limit, because we're all on some standard define open language that we can use for this. So this is this example: the scripts are there. If you want to take a look at it now we say: put the threat model in the cicd workflow.

B

One way you can do it there's multiple ways of doing it. Now we can say instead of that threat model sitting over there as a powerpoint slide. We now have this. This defined language machine, readable lightweight. We can create an individual branch called threat model again. This is one approach, and this threat model is keeping track of the versions of the threat model. So, like this initial check-in, this is the stuff that we've done manually. That's all the hard work that goes in and we set it up as we move along now.

B

The branch one we might get some hotfix and this null operator means that there's really no code inside it. That has changed anything. So we don't need to update our threat model and we can go ahead and merge accordingly. But let's say we get some significant code changes that affect the threat model, maybe we're adding cloud components and all of that and with that we're going to have to update our threat model here now.

B

This is the point like what we're saying is something significant like that would probably require some manual intervention or if it's something small, we'll show you in a little bit, we can actually catch that and update accordingly.

B

Another thing that could happen is we could get something like a zero day vulnerability we find out about it, but there's no code or anything. We can almost treat the threat modeling branch as private, it's not being merged in. So we are aware of this and now we're waiting. Maybe it's going to be branch three or something that will come along and it's going to say: oh, we um we got to put an implement.

B

We have to implement this, but before we make it public we're aware of that and we're going to update the threat model accordingly, that's one way of doing it. Another way where I think john and I kind of agree that maybe this other way is again we're going to do that initial check-in, where the threat model is done manually, but then the threat model itself is really just part of the code. It's part of the regular check-ins at the same branch.

B

So just like the code you're going to do your sas scans, you might be scanning for third-party vulnerabilities, along with your custom code and you're, also going to be scanning your threat model, because now you have those scanners. For those and again, the caveat here is that you know you're going to want to check.

B

It might not be fully automated, but at least, if you have the tools in place to look for things like these deltas uh along with some human interactions, it could be a pull request, for example, that might be just to pull the threat model. Those are the things that are kind of natural anyway, when we're doing it uh like this. This is kind of a typical scenario.

B

Now threats.md is the new readme md, and what do I mean by that? Well, everybody know hopefully knows what a readmemd is. It's a simple markdown file, but it has a special purpose in github right, so it resides at the root of the repo directory. You can always find it there and we understand that's usually the place. You start when you want to find out something about the repository now inside it this readme file.

B

We, we were kind of alluding to this earlier, but you know the triple back tick stuff right um and then you put something in there. The markdown parser understands it doesn't understand, what's going on inside it, but it assumes you do, and maybe your parser will understand it.

B

So there's this foundation, readme parser and then the special purpose could be domain specific stuff, in fact, uh mermaid's a great example of it planning uml as well on github is when you look at the markdown file, you got your triple backtick here we got a mermaid label here. That indicates whatever the parser is. On top of that says, oh this is I got to pay attention to this because this is mermaid.

B

It goes in and renders, of course, something simple like that, and I think that's the coolest thing in the world and that's so easy to do with the readme file, because it gives us a bo the best of both worlds. Now I want to talk about something called overlays and john, and I kind of made this this name up, but um there's a super there's something super powerful about it and the best way I can explain it is start with something called citations.cfm now.

B

Citation cff is not called an overlay, but it's something that's supported by github. If you create this file- and this is a the format- it's a domain specific format. But if you want people- and I think you should, if you've got good, uh if you don't know about citations- and but you have a really good repo out there- and you want people to you know cite it the right way, create this file and citations again we're talking about academic papers or books that may go out and use your uh repo.

B

As for some something right, you want them to cite it uh correctly. This is the way to go and, as you would expect, who are the authors, the title uh version, maybe orchid names you have all of those the date released and, of course, the url. Now what happens is when you save this as citation.cff?

B

It's just like just like the readme file. You do this at the top you'll immediately notice over on the about on your github side. This thing appears cite this repository and when you click on this, all of a sudden, you start getting a couple of different flavors of citations, which is really cool, there's apa, which is great for scientific stuff.

B

You get bibtex as well I'd love to see something like ieee or chicago style, or something people can go and build this tool and add it accordingly, and when you pick this, you get the format that you're looking for. If it's apa you get, this bittex is great because it's kind of used for a lot of other things as well, and this is all it is now. You say: well, what's the big deal about that?

B

Well, if we do it for something like we create this file called threats.md readme file, and it's just doing some stuff here and then we have our back ticks here. We call it threat model threats, whatever we want to call it. We have some dummy. We have our language, we haven't defined it. Yet I'm just giving this an example: um it's going to understand now again the readme is not going to understand it, but somebody's going to go off and say I understand this.

B

Specific language is open and I'm going to go ahead and create some back-end thing that github is going to support and it's going to render it accordingly. So if we save it at threats.md, we then get this automatic thing that comes up again. All the machineries back in github called threat models or threats and mitigations, and when we click on that, we can go as far as remember those methodologies and those characters. At the beginning of our presentation, we can have it represented as stride.

B

Someone could write the stride version and it's writing on top of our specific dlc, mn or pasta, and they can click on it and get the language extremely powerful, and this is what we're saying for the potential behind all of this.

B

So finally, we have to we have to feed the threat model to keep it alive. So I've been talking about languages up to this point, but what I haven't been really talking about is: how do we keep it alive? Well, we needed we needed to find this language first, but now we need the tools to determine what's new, what are the things that are we're going to check, for example, the deltas?

B

What is the data that we're going to do to extract from all this information and john's going to take over here, he's going to do a dfml demo and describe exactly what this scenario is for us, john.

C

All right so uh so let me bring up this all right, so here's here's, what we're going to be doing I'll show you all. You know what we're going to be doing and then we'll do it and then we'll talk about it again.

C

um So john and I talked about the the threats md file and the you know, the threat model uh um that the thread dragon thread model right and this idea of this- this uh open architecture based off of a general purse with this link uh general purpose, description like uh json, right or or yaml or whatever right.

C

The point is we have this this structure and we're gonna have a schema involved right, so uh we're gonna be doing a little demo here where so so, when I said, I'm excited to try this on human and ai agents, we have a project which is spun out of the dfml project to build sort of this ai software developer.

C

Her name is alice and so alice is going to be helping us generate our threats md file today. So what we're going to do is first thing: we're going to do is generate just the threat model. It's just going to have you know the threat dragon threat model in it, the the diagram there and then, as well as the general just the this open architecture. Description of the uh you know of of the of the uh of of the threat model right, so we're doing a conversion.

C

So let's do here all right. So let me remove the file right, so oops, okay, so there it is okay, nevermind! Okay! So if we take a look at the file.

C

And let me go to my browser so.

C

This is the file that gets generated here, all right, so okay, so I don't have the mermaid for you today, but what we do have is and I'll paste this into the body of a github issue. So this is what it looks like right. So we're you know that I'm just previewing in a github issue right now in the body of an issue, um and you know so we have our threat model, uh our diagram from uh threat dragon, and then we have our our open architecture, spec right, and so uh this is actually.

C

uh This is actually the open architecture for the uh the tool itself right now so and you can see basically you've got uh effectively. We have this directed graph of data and it's a little verbose right now. You know where it's in progress, but the the main point is you have your sort of definitions of your data types and your assets which correspond to you know the elements that we'd see up here and then we have our connections between them right um and so that's uh getting into. You know what?

C

How do we link these things together? um Okay, so and then in the future. We'll have also the mermaid diagram, which will be synthesized from there right, but in general the concept is okay, you take your your source of truth material right. So in this case it's your your threat, dragon threat model, any maybe supplementary data.

C

You may have right that's written text and then we're going to combine it all together using alice and dump it into this threat, simply right and when we do that uh this helps ensure that our thread model or our threats, md file, is always up to date. Right because we generate that with our ci and we pull from you know whatever, whatever authoritative sources of truth, we have right. So uh then, let's see, oh, I had a checklist of things. I was supposed to talk about and I was not doing that so.

C

Where is my manifest? Oh, this is where's the manifest you can't get to that tab. Oh here, it is all right. So uh what you know? What? What is this open architecture well at a high level?

C

uh And so we also have I've also been referring to alice as the open architecture, so she's, an entity which is uh based off of this off of the architecture itself at a high level um and and and so we we use the same same terminology to refer to both so with the open architecture uh effectively. What we have is like uh you can think of it, almost like a reverse proxy for domain, specific formats of architecture or representations for of architecture and uh since domain-specific representation of architecture is such a mouthful.

C

uh We basically have been referring to that as as what is effectively a manifest, um and so when we talked about earlier, you know what are these properties of a manifest that allow us to uh interoperate right? Well, we looked at the world and we said okay. So what are some successful formats? What do they do uh and and how would we you know if we treat the the world of data as like streams of data, and we may not see file names? We may just see these blobs coming through.

C

What are the things that we need to see in these blobs of data to know what they are right to know? What an individual element within an architecture is so that we can appropriately apply uh threats and mitigations, as and and the auditing which john showed um in this cross-language way right. So you we, we uh figure out what is the domain specific representation of argument for of architecture aka, the manifest uh for our source of truth right and that source of truth?

C

You know that we could have multiple sources of truth for different parts of our application and we're forming them together and we're bringing it all together to do this open architecture, representation, and so the nodes in that graph are effectively a manifest and then the top level node of the graph. The graph itself is also effectively a manifest right because the same it's it's it's it's you know you can represent any domain specific format uh within within.

C

This is the goal right um so, and we need this to be a community effort to figure that out right. So so what are some of the things that are uh involved in a manifest right? Well, uh we looked around and we said: uh json schema did a lot of good. You know they learned. They learned some. They they have built a lot for the community right. We stand on the shoulders of giants, and so we know that documents should have schemas, uh because the schema will allow us to understand. Well.

C

What is this thing when I hit a new node in the graph it'll? Let us say: okay, well, what should I expect this node to contain and if I know what I can expect the node to contain right, I can do my input, validation and then, when my tool consumes from the graph, then it you know I can have a tool that understands the various different formats and the schemas that are applicable to each format and then basically, well, there's this concept of sort of the shim that says all right.

C

Well, given this format for this domain-specific representation of architecture, let's jump into this auditor right or this visualization right and then we output that all to the threats, md and that way it stays alive right. It's not stale, it's always coming from the source of truth. So uh so effectively the main thing that we there was three properties which we said.

C

These are good things, the manifest metadata right, which a manifest should have, which would allow us to uh effectively validate any blob of data right and and uh say we understand this thing as if it's it's part of the open architecture.

C

It's part of this proxy format right, and that is the format name, the format version and the schema for that right, and so we can combine all those things with little little shorthand, we'll put them all in the url right and basically the file name gives us all three of those and then when we resolve the url, we get the schema right. And so, if we have this uh information, then we can write our our parsers off of it right or our auditors right and then so.

C

We talked a little bit about the concept of overlays, um so the default flow that we just ran right to generate the okay. I've got a lot of stuff on my screen here. Can you all see the top arc? You can't see the top part right all right, I'm gonna assume you can't. You know what I'll hit enter a few times in case you can so this command, which we just ran right to generate the threat model. uh This just just you know, stores the truth in and then good uh good threats out.

C

But uh what we would like to do is run that auditor, that john showed right so and here's the auditor again right, and so we want to run this as along with generation of the threat of the threats md.

C

Since we're thinking cicd, we want to make sure that this source that that threat model conforms to like the code that we're seeing right- or in this case you know, we just want to check check just a few basic checks on the threat model itself, to make sure it's complete right, and so we can start to combine this by adding overlays. So what we did here is we basically just uh we made a little overlay. All it is is uh all we with the underlying framework that we're using dfml.

C

Basically, all this is typed right, because if you think about these manifests in the schema, you got to have some types, so we're going to go ahead and and just throw a little type hinting on there and then create this overlay, which is basically saying all right. We have this audit operation right, and so what we're going to do is we're going to export the audit operation to this open architecture, format right so oops. Once again, I can't really see here, but I'm hoping that you can alright, so we exit we.

C

We export the open architecture to this format um and then what we're going to do is uh run the same generation with the overlay right. So now, what it's going to do is it's going to check for that? It's going to run that auditor internally right, along with make sure we're running the overlay right. So it's going to run the auditor there and we should see you know oops wait! Where are we it's the wrong command? The command is running over here. All right, we're going to run it over here all right.

C

So this is the same command, different, different terminal with the right context, and we end up. You know with once again the threat model. Oh wait wrong file, so.

C

Model good threads, all right, so here's the file again right and this time we've run through the auditor before we we uh we generated it right and that way. If this, if the auditor failed, it wouldn't split, it wouldn't spit out the um it wouldn't spit out. Good threats. Md and we'd fail to see eye job all right.

C

Let's see, um and then let's see so there's a few, a few things that we want to.

C

uh uh You know we'd like to ask the community to help us with right and we'd, like everybody to you, know, think about this concept of the open architecture and how you might uh build tools around this and then also collaborate with us and comment uh in into uh the thread which we'll we'll link here um and we're going to have this as a pull request soon right now, it's just a discussion thread on github, so we'd like people's feedback and to play with the tools that we showed uh you know with the auditor and with alice and try to figure out.

C

You know how: how is this stuff working for you, you know, does. Are you having success with it? Are you seeing places where we could extend? Do we need to modify the concept of what metadata is required right for us to be interoperable?

C

Is there some more pieces of information that that would be required beyond the schema, the format name and the version right and then we're also looking to you know create this as, along with commenting on thread, we're looking to make this into a whole, a working group right and so within that working group, we'll try to figure out. How does this? How does this uh all? uh You know that that can be our forum for discussion. uh There was some work adjacent work. I I think.

C

Maybe I saw the mailing list the other day, the spdx, abstract, syntax tree stuff sounds like the look from what I saw it might be vaguely related, but we need to pull in everybody who might be working on this type of thing uh and- and you know think together about how this works, uh and some some future stuff that we wanted to uh do is uh combine scan data right. So your static analysis data to understand are all these: the uh components that are really in your application right so using something like cve bend tool.

C

We could augment right. We output to the open architecture from cv event tool, and then we augment uh the the auditor to ensure that if you saw a database in your scan results that it better show up in your threat model right, so uh yeah I'll turn it back over to john. But just a call for engagement here.

B

Awesome, thank you, john. So wrapping up here there was a question we we did an interview with adam shostak like it was like one of the most exciting oas podcast. We did a while back and I think it was like 2018 that's how long ago it was, but there was a question in there about.

B

Can we fully automate threat modeling? Can we could we just take the humans out of it and he responded back with a question and he said: can you fully automate programming and then I said I don't think so not now, but here's something to think about. um I just did a look yeah. I did a google there's, 128 million repos on github right now and we know every one of them are quality repos with threat models.

B

No just joking, but if you took 10 of that or something less and let's just pretend people decide to threat model and let's pretend that people are making it publicly available right.

B

I think some teams are, but we just never see it, but let's say they're using this 20 years from now 10 years from now, it's optimistic, then you have this huge corpus of data that you can then start creating your your machine learning models from there, and I think then that's the big picture that maybe then not only that you have these commits where github is already looking for things, but you could also have a threat model check and it can come back and give you a pretty good.

B

You know risk or whatever you want to call it from that. So there's a lot more involved here again, if we're all speaking the same language and that language, of course, is this language and and the tools that and again the people are going to build the tools accordingly, so yeah, we do appreciate it. If there's any questions, uh please feel free. As john said, we're looking for input and we're going to keep moving forward with this. If something's got to happen, something has to happen to make these more secure. So we appreciate your time.

B

Thank you. Thank.

A

You thank you again, gentlemen. Thank you, john and john. We really appreciated that talk. I'm actually uh looking forward to potentially grabbing the slide deck from you. If that's possible um and uh I'm gonna put the sponsor. Are there any questions before we uh switch over? Let me take a look at the chat. Have we taken all the questions.

A

Yeah, it looks like if you have 30 final questions. We have a couple minutes, please let us know otherwise, I'd like to once again thank our sponsors, github synack, the lst security security, innovation forward security website, plurilock, netspy and scicode.