 Good afternoon and good morning to our fellow viewers across the globe. My name is Joe Christian and I'd like to personally welcome you to day three of Apsec Village at DEFCON 28. First, I'd like to thank our sponsors for checkmarks, Google, and offensive security. Without them, we could not have provided you all this amazing village this year. I'd like to issue another thank you to DEFCON and all of our volunteers for their blood, sweat, and tears poured into this incredible effort. Lastly, I'd like to thank the community for supporting us another wonderful year. This village is for you. With that being said, I'd like to introduce our first speaker today, Christian Snyder. Christian's talk is titled ThreadGyl, AdGyl Threat Modeling with Open Source Tools from within your IDE. Christian has pursued a successful career as a freelance Java software developer since 1997 and expanded in 2005 to include the focus on IT security. His major areas of work are penetration testing, security architecture consulting, and threat modeling. As a trainer, Christian regularly conducts in-house training courses on topics like web application security and coaches AdGyl projects to include security as part of their processes by applying DEFCON concepts. Christian regularly enjoys speaking and giving trainings on major national and international conferences. Please give a warm welcome to Christian. Hello, welcome to my talk. My name is Christian Snyder and I'd like to introduce you to ThreadGyl, the new open source toolkit for AdGyl Threat Modeling. I'm working as a freelance security architect, penetration tester and trainer, mainly focusing on areas like DEFCOPS, security architecture consulting, and AdGyl Threat Modeling. With ThreadGyl, the idea is to bridge the gap between classic, more workshop-like threat modeling approaches and AdGyl development with a fast pace of rollouts and a fast set of commits, and eventually, using DEFCOPS approaches a very agile and very quick way of rolling out into production and not neglecting threat modeling in these kinds of setups. And the idea is to let developers create some declarative threat model inside their IDE that is basically not required to go to a different tool or switch the work mode of operation, just maintain in a declarative fashion everything about your application, your architecture in a very simple to read human readable YAML file. That includes like classic threat modeling approaches, the data assets, the components, technical components, and the communication links between them, where the data flows, and trust boundaries that might be crossed by communication links. That YAML file can be checked in in the source tree as any other artifact, so the benefits of that, it's diffable, it's collaboration capable, it's testable, verifiable, you can easily just start along with the project. And the modeled elements, especially the technical elements in that YAML file contain very detailed levels of the technology and the protocols that are chosen in order to be able to have a very good risk generation from some kind of risk rules. So Threadgel has a set of built-in risk rules that analyzes these kinds of sets and treats this as a connected graph of components and deriving risks, potential risks, threats, hardening recommendations, documentations, model graphs, data flow diagrams, and different output formats from that. And even custom risks can be added, because as any tool, you cannot identify every risk with a tool, so you need to have some manually identified risks that can be added to that model as well, because sometimes in these kinds of workshops, you come up with new risks that have not been identified by any kind of tool. And this can be added into the YAML file as well. Threadgel is a technology aware way of modeling your architecture, so you define what type of technology is used, what protocols are used, so it understands from that whether it's encrypted or not, for example. It has around 40 risk rules, so it's growing. And you can even create custom risk rules. It calculates some attack attractiveness, some data loss probabilities, more on that later on. And you can even automate things using model mark pros in a very wizard style approach, and even the risk mitigation can be maintained in that YAML file, so that even the risk tracking and the remaining risks that you want to accept are documented that way. And of course it's released as an open source software. So in Threadgel, basically you run it as a command line interface, it's shipped as a docker container, or you can execute it as a web server with a REST interface. You just see the command line interface with just a few of the many switches and options that you can use. So the first steps within Threadgel are that you create either a minimal stop model that can be created from Threadgel as well, or a filled example model if you want to play with it and see how it works. And it's basically containing that YAML file that's the input into Threadgel, the data assets, the technical assets, the communication links, and the trust boundaries, and a little bit more if you like. So here you see the YAML example of data assets, customer contracts, has some kind of owner, some kind of origin, especially the confidentiality, integrity, and availability ratings are interesting, so you can rate the data assets, how confidential for example they are. And you can model technical assets as well in that YAML file. So for example here a Apache web server where you can define again the confidentiality, integrity, and availability ratings, but you can also define a technology out of a bunch of possible technologies. And you can define a little bit more whether it's used by human, that would be more like being a client or browser for example, what type it is, like a process external entity or data store, and you can tag it if you like and whether it's encrypted or not. So a few questions you can answer there as well. Then you can reference data assets that are processed or stored on that kind of technical asset just by their ID. So from the ID referencing Threadgel learns the distribution of data and the distribution of data that's processed on those kinds of technical assets. And then you just model the communication links. So basically pointing from one system from one technical asset to another component, another technical asset. So it's an outgoing communication link and you can even attribute that with the kind of protocol that's being used, whether it's let's say here HTTPS or it could be FTP or whatever, whatever you'd like, a lab. That's a big list of protocol values that you can choose from. And Threadgel even knows whether it's an encrypted or not encrypted protocol. You can define what kind of authentication is happening, whether it's not authenticated, that communication link just uses credentials or a token based approach. And if it's authenticated, you can define with what kind of authorization, either the technical user or an end user identity or something like that. And you can answer a little bit more questions and you can reference the data assets that are sent and eventually received from that kind of communication link. Finally you model the trust boundaries. These are basically the let's say virtual network areas where you want to have some kind of network trust boundary between them or in a containerized world eventually namespace isolation or something like that. You can model that. So different types of trust boundaries are existing. And then you just reference the technical assets that are used inside. And if you do nest trust boundaries, definitely something that's possible, you can reference them as well. Then when you execute Threadgel on the command line, it processes the ML input and applies the risk rules. So there are lots of built-in risk rules that you can even add your custom ones and it creates some nice output. First of all, here an example, it gives a model graph. It generates a model graph that you can see whether you have modeled something wrong or something is missing from your architecture. The colors in the lines as well as in the shapes are referring depending on the data ratings that are being stored there to the sensitivity of that kind of asset. So red border means that there are very sensitive data stored or red line means there's very sensitive data being transferred. And the color like the yellow ones means there's custom developed code and the shape is a little bit depending whether it's a data store process external entity or a client used by a human. So there's a set of semantics behind these kinds of colors and it generates a PDF and Excel report. So very long in terms of being also some kind of documentation artifact and it has this kind of report has some redundancy in it because it has two different views. It has a view of risks by vulnerability category and a view of risks by technical asset. So let's dive a little bit into the reports that have been generated. You see some management summary with some pie charts depending on the risk severity and also on the risk tracking state. You can add your custom management summary text as well. And you have got the impact. That's basically the impact from the identified risks including some individual added one here the critical one more on that later. And also you can define and see the risk mitigation here. So the risk mitigation chart you see bar charts going up. So we're basically the distribution of the risks that have been identified a group by the tracking state which you maintain as well in the ML file. So you can have something that's in progress here in blue or mitigated in green or something that has been accepted as a risk in pink or the red ones are just unchecked. And you've got the impact analysis of the remaining ones. Also for classic threat modeling you do have the stride classification of the identified risks spoofing, tampering, repudiation, information disclosure and other kinds of categories. And you've got an assignment by function. So who what kind of party in a corporation or a team shall basically handle that kind of risk. So who should address that. So it's business side, architecture side, development operations, something like that. Also Threadjar calculates the RAA the relative attacker attractiveness value which is just a percentage value ranging from 0 to 100 percent. The higher the more attractive for attackers the technical asset is. So these values are assigned to technical assets. And there's an algorithm which is pluggable you can plug in your own custom algorithm if you like. And that algorithm basically treats the amount and the sensitivity of data on the assets and as well as the communication links and the paths that attackers can take to go to these. So if a sibling of another system is having less sensitive data but connects to that very high sensitive data carrying system, that kind of neighboring system is also rated a little bit higher. And DLP data loss probabilities are also calculated. So here you see inside the report a graph which here on the left side contains lots of red data assets. And the right side of the shapes are the basically the components and the errors depending whether it's a dashed or a solid error is whether it's processed on that asset or stored on that asset. And depending on the sensitivity of the data you can see here if you eventually have some risks where you might want to handle that. And the colors here reflect the risk of the data loss probability which is basically depending on how many data assets how many technical assets the data assets are stored or processed and how many risks are there on these assets that might have a blessed impact of losing that data. So in the detailed report you even have the individual risks listed that you should mitigate especially the red ones which would yield the biggest benefit of going from red to amber or even a better color that you're not risking the data loss there. So that way you can basically prioritize depending on the data risks that you might lose them your efforts of mitigation of those identified risks. And the risk mitigation recommendations are also created here. So you see some server side request forgery or XML external entity attack in these examples here where you have risk mitigation texts including links to the OWASP ASVS chapters and to the OWASP cheat sheet. That's basically if it's available for that kind of risk giving the developer teams some kind of hints on how to mitigate that. The risk instances are also obviously inside the report everything is linked and clickable so you can click and easily navigate around in that report and you have it either by a group by the vulnerability type on the left side or on the right side you've got the risks by a technical asset so that you can get from that kind of view also to the risks and the descriptions of how you can mitigate that. Of course you get an extra report as well for easier filtering sorting and stuff like that same data different format and being DevSecOps ready that means the results are also available as a JSON output so you can process them inside Jenkins or any kind of other GitLab CR whatever you like some kind of DevSecOps pipelines so CLCD pipelines can then execute ThreadGal as a command line or via the REST server if you like depends on what you want to do and the result is a JSON file listing the remaining risks and their distribution across the different severity levels and then you can for example automatically break a build if a system includes or a build includes some yet unchecked high risks. The risk rules that's a set of constantly growing risk rules so there are around 40-ish something in it and you can extend that with more risk rules if you like so that's growing on a day-by-day basis and risk rules are written in Go inside ThreadGal. ThreadGal is itself written completely in Go and you see an example for risk rule if this is an LDAP injection so you have some category definition where you have the texts and the cheat sheet links and basically the metadata that the report is generated properly for that kind of risk and on the right side you see the very simple code to identify those risks so it's basically some kind of graph identification from the assets that you modeled and the communication links that you modeled. You can even if you like add manually identified risks to ThreadGal in the same YAML file so the same input file can include manually identified risks these that are not usually identifiable by tool so for example in a classic threat modeling workshop you identify those additional risks and you do not want to track them in a separate way you want to keep them in the same way that you track the tool based identified risks inside ThreadGal and that can be done by simply enhancing the YAML input file with individual risks so here you provide the metadata of the texts what happened and that kind of risk that you identified how it should be mitigated and stuff like that here you provide that basically as values inside the YAML file and on the right side you see that this risk has two instances so it has for example been identified it's some database and some file system server here and you can even link to the technical assets that are the most relevance have the most relevance of losing that kind of data when that risks manifest itself so that way the blast impact of the data loss probability is also reflected with that kind of manually added risk. You do have very good editing support in IDEs for YAML files that's definitely something that's been around for some time even VRI if you like so there are many YAML editors available it's easily readable by humans for example in my IDE I do have here on the right side a tree that I can click to navigate inside the YAML file so that's automatically populated from the structure of the YAML file so that's definitely something that's having a very good support of IDEs doesn't stop there it goes even into schema validation and auto completion so Threadgel supports IDEs by having a YAML schema available for the Threadgel model that basically means you can import that YAML file into the IDE and then you have some kind of automated checking of the syntax and you get some error flags for example here on the left side I've got a typo web server with many errors so that's definitely flagged as an invalid technology type and that's something that has been validated by the IDE due to the schema and that schema gives me also some kind of auto completion so when I type on the technology web and hit a control space the pop-up basically includes everything that begins with web like web application web server or what else so that's some kind of auto completion that you just get for free by simply importing the Threadgel YAML file schema into your whatever IDE or YAML editor you use you can also have some kind of live templates for quicker editing of on creation of those elements like technical assets communication links or data assets or something like that so importing these templates in major IDEs allows you just to hit our tech asset enter and bam you've got a pre-populated template where you just give it a name and then you tap through those elements and hit control space to open the auto completion pop-ups and that's a little bit like the encoding style definitely something nice and we do have model macros inside Threadgel that's basically some kind of interactive wizards so that's a little bit like a state machine that you can create and each model macro has a set of questions that are being asked in a sequential interactive way and it reads each model macro reads the YAML file of an existing model and it asks you questions of what you would like to do and so we do have different model macros like adding a build pipeline or adding a vault or adding identity provider including identity storage to the model and that way you can codify and reuse and make this a little bit individual due to the questions that you ask the user the kinds of repeating model elements that you have in your corporation or in your teams and make them these adding these modifying the model files that way in a very easy way so a plug-up interface also allows you to create your own model macros so how does this look like it's on the command line so you do have for example here an add build pipeline model macro with just a few questions that you answer and then you can select on which kind of components this build pipeline should deploy for example so it reads the model and it modifies it accordingly and you can create new trust boundaries for that is it either push-based or pull-based deployments more on the GitOps style and then you've got a summary like a dry run of what would be added to the model and adding new data assets adding new technical assets including the communication links adding new trust boundaries so all these modifications are done automatically then and the result is you get something more out of that so you get the communication paths added as well okay so what about risk tracking so inside the yaml file you also have a way to track the identified risks by a unique risk ID and you can even group them with byte cards to have some kind of sets of risks of the same type for the same component or something like that to be tracked in the same style and you can assign a status like whether it's unchecked that's the default state if it's not being tracked yet or the risk is in discussion or whether the risk has been accepted and it just remains as a remaining risk or whether it's in progress so you're working on mitigating it or it has been mitigated or whether it's a false positive sometimes tools also a false positives definitely and you can add a justification optionally you can add a ticket ID a date and then check by name tag so you can track that in a very good way and even a model macro is existing that reads an existing yaml file applies the risk tracking and then it generates the yet untracked risk instance IDs and they're tracking with the unchecked still obviously state that you can then individually shift to some kind of other state and out of the risk tracking definitions in the same yaml file you get the risk mitigation state you just saw recently here in the talk in the pdf file you see it on the right side what about bigger models of course even bigger models work well then even way bigger models work well something we did in beta testing of Threadal definitely even way bigger models work quite good also a rest server is existing inside Threadal so you do have some in the doc container some way to start it and expose a port and that port is basically giving you a way to use Threadal like a REST API that means you can send in the yaml file and get a zip file where all those artifacts are in that Threadal generates and you can also in the next version then basically create a model on the server side that start that way in an encrypted fashion and then you can add data assets to it you can add technical assets to it you can add communication links to it apply the risk tracking import or export the model file if you like something like that and if you want to play a little bit with that there's even a playground online it's just on runthreadal.io so what are the possible effects of modeling risks or modeling threats in or applying threat modeling actually in some kind of yaml file and letting the risks and the threats being generated by an open source tool that way so not leaving the IDE making it pluggable the risk rating scheme or the risk rules means that corporations can even have their individual policies coded in some some kind of easy to code and go long risk rules and these custom coded risk rules can analyze the model graph according to the corporate individual policies also if many more projects are using it inside a corporation you can then for example have some kind of uniform documentation of the system landscape build bottom up project by project system by system can even try to link them in a very good way if you like and it's built by the dev teams and their IDEs they're not leaving they are tools of choice and they do it in their favorite IDE and it's just running along within the code base checked in and some kind of yaml file that's it so it's easy to keep that up to date compared to classic threat model approaches so it's a way to have continuous threat modeling it's easy to instantly regenerate from some kind of project the risk landscape so if something changes for example so for example a data classification changes being more confidential or some component is moved into the cloud so something like that then you can just regenerate it and see if some new risks might emerge from that kind of change and you can do that instant risk regeneration even on corporate level so for example when a policy changes or new policies introduced some new regulatory policies for example then you can adjust your custom risk rules accordingly or create a new one and then just execute the fragile on all of your projects and then you might see which of these projects eventually have some kind of to do to mitigate some newly emerging risks not matching something like a new policy that has been put into place also CICD pipelines can check the generated JSON to automatically fail the build or at least flag it as unstable something like that if some unmitigated high risks are still there so having the risk tracking state inside fragile and having the remaining risks that way you can also just evaluate that data in the jason file and then you can just fail the build if you want to avoid an automatic rollout into production where high new high risks have not yet been checked at least so that's something that is definitely ready for DEFSEC ops approaches that means threat modeling continuous threat modeling becomes part of a DEFSEC ops approach and that's basically what fragile is about about agile threat modeling hopefully security is then less bottleneck for threat model sign-offs that basically means the security team can more focus on the individual risks and not the standard that have been easy to identify in some kind of coded risk rules also that's easy and it's shifting things more on the left side so that by development teams beginning from early on to maintain and create the YAML file then you have a very early integration of threat modeling that doesn't do any kind of bottleneck effects on your security so it's released as an open source tool the website is fragile.io there's a playground available run fragile.io the source is available on github and docker images are available as well if you have any questions feel free to ask you've got my contact data there as well special thanks definitely to those valuable feedbacks from all the beta users and especially to those here like in alphabetical order very early adapters of fragile and very valuable feedback thanks and I'd like to thank you as well so a little bit of Q&A if you like and look forward to seeing you later in the chat