[00:12.950 --> 00:17.630]  Good morning, good afternoon, and good morning to our fellow viewers across the globe.
[00:17.890 --> 00:21.510]  My name is Joe Christian and I'd like to personally welcome you to day three of AppSec
[00:21.510 --> 00:27.030]  Village at DEF CON 28. First, I'd like to thank our sponsors for check marks, Google,
[00:27.030 --> 00:31.390]  and Offensive Security. Without them, we could not have provided you all this amazing village
[00:31.390 --> 00:36.430]  this year. I'd like to issue another thank you to DEF CON and all of our volunteers for their blood,
[00:36.430 --> 00:41.490]  sweat, and tears poured into this incredible effort. Lastly, I'd like to thank the community
[00:41.490 --> 00:46.110]  for supporting us another wonderful year. This village is for you. With that being said,
[00:46.110 --> 00:50.610]  I'd like to introduce our first speaker today, Christian Snyder. Christian's talk is titled
[00:50.610 --> 00:56.270]  ThreadGile, Agile Threat Modeling with Open Source Tools from Within Your IDE. Christian has
[00:56.270 --> 01:00.890]  pursued a successful career as a freelance Java software developer since 1997 and expanded in
[01:00.890 --> 01:06.290]  2005 to include the focus on IT security. His major areas of work are penetration testing,
[01:06.290 --> 01:10.670]  security architecture consulting, and threat modeling. As a trainer, Christian regularly
[01:10.670 --> 01:15.550]  conducts in-house training courses on topics like web application security and coaches Agile
[01:15.550 --> 01:20.170]  projects to include security as part of their processes by applying DevSecOps concepts.
[01:20.730 --> 01:23.430]  Christian regularly enjoys speaking and giving trainings on major national
[01:23.430 --> 01:27.330]  and international conferences. Please give a warm welcome to Christian.
[01:28.210 --> 01:34.310]  Hello, welcome to my talk. My name is Christian Snyder and I'd like to introduce you to ThreadGile,
[01:34.310 --> 01:39.830]  the new open source toolkit for Agile Threat Modeling. I'm working as a freelance security
[01:39.830 --> 01:45.310]  architect, penetration tester, and trainer, mainly focusing on areas like DevSecOps,
[01:45.310 --> 01:51.490]  security architecture consulting, and Agile Threat Modeling. With ThreadGile, the idea is
[01:51.490 --> 01:56.090]  to bridge the gap between classic, more workshop-like threat modeling approaches
[01:56.710 --> 02:04.850]  and Agile development with a fast pace of rollouts and a fast set of commits and eventually using
[02:04.850 --> 02:11.850]  DevSecOps approaches, a very Agile and very quick way of rolling out into production and not
[02:11.850 --> 02:19.270]  neglecting threat modeling in these kinds of setups. And the idea is to let developers create
[02:19.270 --> 02:25.410]  some declarative threat model inside their IDE that is basically not required to go to a different
[02:25.410 --> 02:31.470]  tool or switch the work mode of operation, just maintain in a declarative fashion, everything
[02:31.470 --> 02:37.030]  about your application, your architecture, in a very simple-to-read, human-readable YAML file.
[02:37.090 --> 02:42.530]  That includes like classic threat modeling approaches, the data assets, the components,
[02:42.530 --> 02:47.710]  technical components, and the communication links between them, where the data flows,
[02:47.710 --> 02:53.650]  and trust boundaries that might be crossed by communication links. That YAML file can be
[02:53.650 --> 02:59.050]  checked in in the source tree as any other artifact. So the benefits of that, it's diffable,
[02:59.050 --> 03:05.990]  it's collaboration capable, it's testable, verifiable, you can easily just start along with the project.
[03:07.050 --> 03:13.530]  And the modeled elements, especially the technical elements in that YAML file, contain very detailed
[03:13.530 --> 03:20.850]  levels of the technology and the protocols that are chosen in order to be able to have a very good
[03:20.850 --> 03:26.790]  risk generation from some kind of risk rules. So ThreadGeneral has a set of built-in risk rules
[03:26.790 --> 03:33.030]  that analyzes these kinds of sets and treats this as a connected graph of components,
[03:33.030 --> 03:39.510]  and deriving risks, potential risks, threats, hardening recommendations, documentations,
[03:39.510 --> 03:44.150]  model graphs, data flow diagrams, and different output formats from that.
[03:44.670 --> 03:50.190]  And even custom risks can be added, because as any tool, you cannot identify every risk
[03:50.190 --> 03:57.430]  with a tool. So you need to have some manually identified risks that can be added to that model
[03:57.430 --> 04:02.630]  as well, because sometimes in these kinds of workshops, you come up with new risks that have
[04:02.630 --> 04:08.190]  not been identified by any kind of tool. And this can be added into the YAML file as well.
[04:08.630 --> 04:13.970]  ThreadGeneral is a technology-aware way of modeling your architecture. So you define
[04:13.970 --> 04:18.890]  what type of technology is used, what protocols are used, so it understands from that whether
[04:18.890 --> 04:25.690]  it's encrypted or not, for example. It has around 40 risk rules, so it's growing. And you can even
[04:25.690 --> 04:31.270]  create custom risk rules. It calculates some attacker attractiveness and data loss probabilities
[04:31.270 --> 04:37.410]  more on that later on. And you can even automate things using model macros in a very wizard-style
[04:37.410 --> 04:42.730]  approach. And even the risk mitigation can be maintained in that YAML file, so that even the
[04:42.730 --> 04:50.130]  tracking and the remaining risks that you want to accept are documented that way. And of course,
[04:50.130 --> 04:56.730]  it's released as an open-source software. So in ThreadGeneral, basically you run it as a
[04:56.730 --> 05:02.450]  command-line interface. It's shipped as a docker container, or you can execute it as a web server
[05:02.590 --> 05:08.750]  with a REST interface. Here you just see the command-line interface with just a few of the
[05:08.750 --> 05:14.870]  many switches and options that you can use. So the first steps within ThreadGeneral are that you
[05:14.870 --> 05:20.430]  create either a minimal stub model that can be created from ThreadGeneral as well, or a filled
[05:20.430 --> 05:25.950]  example model if you want to play with it and see how it works. And it's basically containing that
[05:25.950 --> 05:30.710]  YAML file that's the input into ThreadGeneral, the data assets, the technical assets, the
[05:30.710 --> 05:36.550]  communication links, and the trust boundaries, and a little bit more if you like. So here you see
[05:36.550 --> 05:45.090]  the YAML example of data assets, customer contracts, has some kind of owner, some kind of origin,
[05:45.090 --> 05:50.490]  especially the confidentiality, integrity, and availability ratings are interesting. So you can
[05:50.490 --> 05:57.410]  rate the data assets, how confidential for example they are. And you can model technical assets as
[05:57.410 --> 06:05.350]  well in that YAML file. So for example here, an Apache web server where you can define again the
[06:06.450 --> 06:10.930]  confidentiality, integrity, and availability ratings. But you can also define a technology
[06:10.930 --> 06:16.330]  out of a bunch of possible technologies. And you could define a little bit more whether it's used
[06:16.330 --> 06:22.790]  by a human, that would be more like being a client or browser for example. What type it is, like a
[06:23.090 --> 06:28.430]  process, external entity, or data store. And you can tag it if you like, and whether it's encrypted
[06:28.430 --> 06:36.690]  or not. So a few questions you can answer there as well. Then you can reference data assets that
[06:36.690 --> 06:43.750]  are processed or stored on that kind of technical asset just by their ID. So from the ID referencing
[06:43.750 --> 06:49.750]  Threja learns the distribution of data and the distribution of data that's processed on those
[06:49.750 --> 06:55.850]  kinds of technical assets. And then you just model the communication links. So basically
[06:56.550 --> 07:01.490]  pointing from one system, from one technical asset to another component, another technical
[07:01.490 --> 07:07.950]  asset. So it's an outgoing communication link and you can even attribute that with the kind of
[07:07.950 --> 07:13.050]  protocol that's being used. Whether it's let's say here HTTPS or it could be FTP or whatever
[07:13.050 --> 07:19.710]  whatever you'd like, LLAP. That's a big list of protocol values that you can choose from.
[07:20.010 --> 07:25.390]  And Threja even knows whether it's an encrypted or not encrypted protocol. You can define what
[07:25.390 --> 07:30.250]  kind of authentication is happening, whether it's not authenticated, that communication link or
[07:30.250 --> 07:36.130]  just uses credentials or a token-based approach. And if it's authenticated you can define with
[07:36.130 --> 07:42.550]  what kind of authorization. Either the technical user or an end user identity or something like
[07:42.550 --> 07:46.990]  that. And you can answer a little bit more questions and you can reference the data assets
[07:46.990 --> 07:52.630]  that are sent and eventually received from that kind of communication link.
[07:54.070 --> 08:01.750]  Finally, you model the trust boundaries. These are basically the let's say virtual network areas
[08:02.390 --> 08:07.670]  where you want to have some kind of network trust boundary between them or in a containerized world
[08:07.670 --> 08:12.210]  eventually namespace isolation, something like that. You can model that. So different types of
[08:12.210 --> 08:17.170]  trust boundaries are existing. And then you just reference the technical assets that are used
[08:17.170 --> 08:22.490]  inside. And if you do nest trust boundaries, definitely something that's possible, you can
[08:22.490 --> 08:29.590]  reference them as well. Then when you execute fragile on the command line, it processes the
[08:29.590 --> 08:35.850]  YAML input and applies the RISC rules. So there are lots of built-in RISC rules and you can even
[08:35.850 --> 08:41.730]  add your custom ones and it creates some nice output. First of all, here an example. It gives
[08:42.170 --> 08:48.010]  a model graph. It generates a model graph that you can see whether you have modeled something
[08:48.010 --> 08:55.010]  wrong or something is missing from your architecture. The colors in the lines as well
[08:55.010 --> 09:01.730]  as in the shapes are referring, depending on the data ratings that are being stored there, to the
[09:01.730 --> 09:09.490]  sensitivity of that kind of asset. So a red border means that there are very sensitive data stored
[09:09.490 --> 09:16.410]  or a red line means there's very sensitive data being transferred. And the color like the yellow
[09:16.410 --> 09:21.030]  ones means there's custom developed code and the shape is a little bit depending whether it's a
[09:21.030 --> 09:29.830]  data store, process, external entity or a client used by a human. So there's a set of semantics
[09:29.830 --> 09:37.130]  behind these kinds of colors. And it generates a PDF and Excel report. So very long in terms of
[09:37.130 --> 09:44.650]  being also some kind of documentation artifact. And this kind of report has some redundancy in
[09:44.650 --> 09:50.930]  it because it has two different views. It has a view of risks by vulnerability category and a view
[09:50.930 --> 09:57.410]  of risks by technical asset. So let's dive a little bit into the reports that have been generated.
[09:57.410 --> 10:03.430]  You see some management summary with some pie charts depending on the risk severity and also
[10:03.430 --> 10:08.370]  on the risk tracking state. You can add your custom management summary text as well. And you
[10:08.370 --> 10:13.270]  have got the impact. That's basically the impact from the identified risks, including some individual
[10:13.270 --> 10:19.570]  added one here, the critical one. More on that later. And also you can define and see the risk
[10:19.570 --> 10:25.630]  mitigation here. So in the risk mitigation chart, you see bar charts going up. So where basically
[10:25.630 --> 10:32.410]  the distribution of the risks that have been identified are grouped by the tracking state,
[10:32.410 --> 10:37.270]  which you maintain as well in the YAML file. So you can have something that's in progress here in
[10:37.270 --> 10:43.970]  blue or mitigated in green or something that has been accepted as a risk in pink or the red ones
[10:43.970 --> 10:50.830]  are just unchecked. And you've got the impact analysis of the remaining ones. Also for classic
[10:50.830 --> 10:57.890]  threat modeling, you do have the stride classification of the identified risks, spoofing, tempering,
[10:57.890 --> 11:03.050]  repudiation, information disclosure, and other kinds of categories. And you've got an assignment
[11:03.050 --> 11:09.070]  by function. So who, what kind of party in your corporation or team shall basically handle that
[11:09.070 --> 11:14.270]  kind of risk? So who should address that? So is it business side, architecture side, development,
[11:14.270 --> 11:22.670]  operations, something like that. Also ThreadGile calculates the RAA, the relative attacker
[11:22.670 --> 11:28.090]  attractiveness value, which is just a percentage value ranging from zero to 100%. The higher,
[11:28.090 --> 11:33.830]  more attractive for attackers, the technical asset is. So these values are assigned to technical
[11:33.830 --> 11:40.250]  assets. And there's an algorithm which is pluggable. You can plug in your own custom algorithm if you
[11:40.250 --> 11:45.950]  like. And that algorithm basically treats the amount and the sensitivity of data on the assets
[11:45.950 --> 11:51.550]  and as well as the communication links and the paths that attackers can take to go to these.
[11:51.550 --> 11:58.490]  If a sibling of another system is having less sensitive data, but connects to that
[11:58.490 --> 12:03.850]  very high sensitive data carrying system, that kind of neighboring system is also rated a little
[12:03.850 --> 12:11.990]  bit higher. And DLP, data loss probabilities, are also calculated. So here you see inside the report
[12:12.570 --> 12:19.770]  a graph, which here on the left side contains lots of red data assets. And the right side of
[12:19.770 --> 12:26.970]  the shapes are basically the components and the errors, depending whether it's a dashed or a
[12:26.970 --> 12:33.310]  solid error is whether it's processed on that asset or stored on that asset. And depending
[12:33.310 --> 12:38.770]  on the sensitivity of the data, you can see here if you eventually have some risks where you might
[12:38.770 --> 12:46.610]  want to handle that. And the colors here reflect the risk of the data loss probability, which is
[12:46.610 --> 12:53.710]  basically depending on how many data assets, how many technical assets the data assets are stored
[12:53.710 --> 13:00.170]  or processed, and how many risks are there on these assets that might have a blast impact of losing
[13:00.170 --> 13:05.650]  that data. So in the detailed report, you even have the individual risks listed that you should
[13:05.650 --> 13:11.510]  mitigate, especially the red ones, which would yield the biggest benefit of going from red to
[13:11.510 --> 13:17.530]  amber or even a better color that you're not risking the data loss there. So that way you can
[13:17.530 --> 13:23.670]  basically prioritize, depending on the data risks that you might lose them, your efforts of
[13:23.670 --> 13:30.830]  mitigation of those identified risks. And the risk mitigation recommendations are also created here.
[13:30.830 --> 13:37.710]  So you see some server-side request forgery or XML external entity attack in these examples here,
[13:37.710 --> 13:45.190]  where you have risk mitigation texts, including links to the OWASP ASVS chapters and to the OWASP cheat
[13:45.190 --> 13:50.470]  sheet. That's basically if it's available for that kind of risk, giving the developer and team
[13:50.470 --> 13:57.070]  some kind of hints on how to mitigate that. The risk instances are also obviously inside the
[13:57.070 --> 14:01.530]  report. Everything's linked and clickable, so you can click and easily navigate around
[14:01.530 --> 14:08.110]  in that report. And you have it either grouped by the vulnerability type on the left side,
[14:08.110 --> 14:12.730]  or on the right side, you've got the risks by a technical asset, so that you can get from that
[14:12.730 --> 14:17.670]  kind of view also to the risks and the descriptions of how you can mitigate them.
[14:18.170 --> 14:23.970]  Of course, you get an Excel report as well for easier filtering, sorting, and stuff like that.
[14:23.970 --> 14:30.410]  Same data, different format. And being DevSecOps ready, that means the results are also available
[14:30.410 --> 14:37.090]  as a JSON output. So you can process them inside Jenkins or any kind of other GitLab CI, or
[14:37.090 --> 14:43.290]  whatever you like, some kind of DevSecOps pipelines. So CICD pipelines can then execute
[14:43.290 --> 14:48.710]  fragile as a command line or via the REST server, if you like, depends on what you want to do.
[14:48.730 --> 14:53.850]  And the result is a JSON file listing the remaining risks and their distribution across
[14:53.850 --> 14:58.950]  the different severity levels. And then you can, for example, automatically break a build
[14:58.950 --> 15:05.070]  if a system includes or a build includes some yet unchecked high risks.
[15:06.470 --> 15:11.570]  And the risk rules, that's a set of constantly growing risk rules. So there are around 40-ish
[15:11.570 --> 15:17.330]  something in it, and you can extend that with more risk rules if you like. So that's growing
[15:17.330 --> 15:24.530]  on a day-by-day basis. And risk rules are written in Go inside Fragile. Fragile is itself written
[15:24.530 --> 15:30.770]  completely in Go. And here you see an example for a risk rule. This is an LDAP injection. So
[15:30.770 --> 15:36.050]  you have some category definition where you have the texts and the cheat sheet links and basically
[15:36.050 --> 15:41.470]  the metadata that the report is generated properly for that kind of risk. And on the right side,
[15:41.470 --> 15:46.910]  you see the very simple code to identify those risks. So it's basically some kind of graph
[15:48.530 --> 15:53.450]  identification from the assets that you modeled and the communication links that you modeled.
[15:54.650 --> 16:01.190]  You can even, if you like, add manually identified risks to Fragile in the same YAML file. So the
[16:01.190 --> 16:08.050]  same input file can include manually identified risks. These that are not usually identifiable
[16:08.050 --> 16:13.490]  by tool. So for example, in a classic threat modeling workshop, you identify those additional
[16:13.490 --> 16:18.550]  risks and you do not want to track them in a separate way. You want to keep them in the same
[16:18.550 --> 16:25.170]  way that you track the tool-based identified risks inside Fragile. And that can be done
[16:25.170 --> 16:30.810]  by simply enhancing the YAML input file with individual risks. So here you provide the
[16:30.810 --> 16:36.310]  metadata of the text, what happened in that kind of risk that you identified, how it should be
[16:36.310 --> 16:42.070]  mitigated and stuff like that. Here you provide that basically as values inside the YAML file.
[16:42.070 --> 16:46.970]  And on the right side, you see that this risk has two instances. So it has, for example,
[16:46.970 --> 16:52.470]  been identified at some database and on some file system server here. And you can even link
[16:52.470 --> 16:57.910]  to the technical assets that are the most relevant, have the most relevance of losing
[16:57.910 --> 17:04.150]  that kind of data when that risk manifests itself. So that way, the blast impact of the
[17:04.150 --> 17:10.610]  data loss probability is also reflected with that kind of manually added risk.
[17:11.510 --> 17:16.750]  You do have very good editing support in IDEs for YAML files. That's definitely something
[17:16.750 --> 17:21.390]  that's been around for some time, even in VI, if you like. So there are many YAML editors
[17:21.390 --> 17:27.130]  available. It's easily readable by humans. For example, in my IDE, I do have here on the right
[17:27.130 --> 17:33.250]  side a tree that I can click to navigate inside the YAML file. So that's automatically populated
[17:33.250 --> 17:38.610]  from the structure of the YAML file. So that's definitely something that's having a very good
[17:38.610 --> 17:47.870]  support of IDEs. It doesn't stop there. It goes even into schema validation and auto-completion.
[17:47.870 --> 17:55.000]  So Thragil supports IDEs by having a YAML schema available for the Thragil model.
[17:55.790 --> 18:01.550]  That basically means you can import that YAML file into the IDE. And then you have some kind
[18:01.550 --> 18:06.890]  of automated checking of the syntax. And you get some error flags. For example, here on the left
[18:06.890 --> 18:12.550]  side, I've got a typo web server with many Rs. So that's definitely flagged as an invalid technology
[18:12.550 --> 18:18.730]  type. And that's something that has been validated by the IDE due to the schema. And that schema
[18:18.730 --> 18:23.310]  gives me also some kind of auto-completion. So when I type on the technology web and hit
[18:23.870 --> 18:28.670]  a control space, the pop-up basically includes everything that begins with web, like web
[18:28.670 --> 18:33.730]  application, web server, or what else. So that's some kind of auto-completion that you just get
[18:33.730 --> 18:41.910]  for free by simply importing the Thragil YAML file schema into your whatever IDE or YAML editor
[18:41.910 --> 18:49.890]  you use. You can also have some kind of live templates for quicker editing of and creation
[18:49.890 --> 18:56.010]  of those elements, like technical assets, communication links, or data assets, or something
[18:56.010 --> 19:02.850]  like that. So importing these templates in major IDEs allows you just to hit a tech asset, enter,
[19:02.850 --> 19:07.730]  bam, you've got a pre-populated template where you just give it a name and then you tap through
[19:07.730 --> 19:13.330]  those elements and hit control space to open the auto-completion pop-ups. And that's a little bit
[19:13.330 --> 19:20.470]  like a Zen coding style. Definitely something nice. And we do have model macros inside Thragil.
[19:20.470 --> 19:25.350]  That's basically some kind of interactive wizard. So that's a little bit like a state machine that
[19:25.350 --> 19:31.290]  you can create. And each model macro has a set of questions that are being asked in a sequential,
[19:31.290 --> 19:38.950]  interactive way. And it reads, each model macro reads the YAML file of an existing model and it
[19:38.950 --> 19:44.010]  asks you questions of what you would like to do. And so we do have different model macros like
[19:44.010 --> 19:48.430]  adding a build pipeline or adding a vault or adding identity provider, including an identity
[19:48.430 --> 19:56.210]  storage to the model. And that way you can codify and reuse and make this a little bit individual
[19:56.210 --> 20:02.590]  due to the questions that you ask the user. The kinds of repeating model elements that you have
[20:02.590 --> 20:08.730]  in your corporation or in your teams and make them, adding these, modifying the model files
[20:08.730 --> 20:13.850]  that way in a very easy way. So a pluggable interface also allows you to create your own
[20:13.850 --> 20:20.610]  model macros. So how does this look like? It's on the command line. So you do have, for example,
[20:20.610 --> 20:24.970]  here a add build pipeline model macro where you have just a few questions that you answer
[20:24.970 --> 20:29.670]  and then you can select on which kind of components this build pipeline should deploy,
[20:29.670 --> 20:34.630]  for example. So it reads the model and it modifies it accordingly and you can create
[20:34.630 --> 20:40.070]  new trust boundaries for that. Is it either push-based or pull-based deployments? More on
[20:40.070 --> 20:47.650]  the GitOps style. And then you've got a summary, like a dry run, of what would be added to the
[20:47.650 --> 20:53.570]  model and adding new data assets, adding new technical assets, including the communication
[20:53.570 --> 20:58.730]  links, adding new trust boundaries. So all these modifications are done automatically then. And
[20:58.730 --> 21:04.850]  the result is you get something more out of that. So you get the communication paths added as well.
[21:05.970 --> 21:11.990]  Okay, so what about risk tracking? So inside the YAML file, you also have a way to
[21:13.250 --> 21:20.190]  track the identified risks by a unique risk ID. And you can even group them with bytecards to
[21:20.190 --> 21:26.850]  have some kind of sets of risks of the same type for the same component or something like that,
[21:26.850 --> 21:33.090]  to be tracked in the same style. And you can assign a status, like whether it's unchecked,
[21:33.090 --> 21:38.330]  that's the default state if it's not being tracked yet, or the risk is in discussion,
[21:38.770 --> 21:43.190]  or whether the risk has been accepted and it just remains as a remaining risk,
[21:43.190 --> 21:48.990]  or whether it's in progress, so you're working on mitigating it, or it has been mitigated,
[21:48.990 --> 21:53.770]  or whether it's a false positive. Sometimes tools also have false positives, definitely.
[21:54.830 --> 21:59.950]  And you can add a justification. Optionally, you can add a ticket ID, a date, and a check by
[21:59.950 --> 22:05.770]  name tag, so you can track that in a very good way. And even a model macro is existing that
[22:05.770 --> 22:12.750]  reads an existing YAML file, applies the risk tracking, and then it generates the yet-untracked
[22:12.750 --> 22:20.250]  risk instance IDs, and they're tracking with the unchecked still, obviously, state that you can
[22:20.250 --> 22:27.530]  then individually shift to some kind of other state. And out of the risk tracking definitions
[22:27.530 --> 22:34.490]  in the same YAML file, you get the risk mitigation state you just saw recently here in the talk,
[22:34.490 --> 22:40.950]  in the PDF file, you see it on the right side. What about bigger models? Of course,
[22:40.950 --> 22:45.370]  bigger models work well, and even way bigger models work well. Something we did
[22:45.910 --> 22:50.730]  in beta testing of Thragil, definitely, even way bigger models work quite good.
[22:51.730 --> 22:57.250]  Also, a REST server is existing inside Thragil, so you do have some, in the Docker container,
[22:57.250 --> 23:02.650]  some way to start it and expose a port, and that port is basically giving you a way to
[23:03.190 --> 23:10.250]  use Thragil like a REST API. That means you can send in the YAML file and get a zip file
[23:10.250 --> 23:17.490]  where all those artifacts are in that Thragil generates. And you can also, in the next version,
[23:17.490 --> 23:22.590]  then basically create a model on the server side that start that way in an encrypted fashion.
[23:22.610 --> 23:26.630]  And then you can add data assets to it, you can add technical assets to it, you can add
[23:26.630 --> 23:30.750]  communication links to it, apply the risk tracking, import or export the model file,
[23:30.750 --> 23:34.450]  if you like, something like that. And if you want to play a little bit with that,
[23:34.450 --> 23:38.610]  there's even a playground online. It's just on run.thragil.io.
[23:40.250 --> 23:46.570]  So what are the possible effects of modeling risks or modeling threats or applying threat
[23:46.570 --> 23:51.290]  modeling actually in some kind of YAML file and letting the risks and the threats being
[23:51.290 --> 23:57.590]  generated by an open source tool that way? So not leaving the IDE, making it pluggable,
[23:57.590 --> 24:03.850]  the risk rating scheme or the risk rules means that corporations can even have their individual
[24:03.850 --> 24:11.150]  policies coded in some kind of easy to code and go long risk rules. And these custom code
[24:11.150 --> 24:16.650]  risk rules can analyze the model graph according to the corporate individual policies.
[24:17.770 --> 24:23.490]  Also, if many more projects are using it inside a corporation, you can then, for example, have
[24:23.490 --> 24:29.710]  some kind of uniform documentation of the system landscape built bottom up, project by project,
[24:29.710 --> 24:34.170]  system by system. You can even try to link them in a very good way if you like.
[24:34.770 --> 24:40.190]  And it's built by the dev teams in their IDEs. They're not leaving their tools of choice and
[24:40.190 --> 24:45.490]  they do it in their favorite IDE. And it's just running along within the code base, checked in
[24:45.490 --> 24:50.990]  in some kind of YAML file. That's it. So it's easy to keep that up to date compared to classic
[24:50.990 --> 24:57.530]  threat model approaches. So it's a way to have continuous threat modeling. It's easy to instantly
[24:57.530 --> 25:04.530]  regenerate from some kind of project, the risk landscape. So if something changes, for example,
[25:04.530 --> 25:11.150]  so for example, a data classification changes, being more confidential, or some component is
[25:11.150 --> 25:16.330]  moved into the cloud. So something like that. Then you can just regenerate it and see if some
[25:16.330 --> 25:22.790]  new risks might emerge from that kind of change. And you can do that instant risk regeneration
[25:22.790 --> 25:29.530]  even on corporate level. So for example, when a policy changes or a new policy is introduced,
[25:29.530 --> 25:34.510]  some new regulatory policies, for example, then you can adjust your custom risk rules
[25:34.510 --> 25:39.870]  accordingly or create a new one and then just execute Threadger on all of your projects.
[25:39.870 --> 25:44.710]  And then you might see which of these projects eventually have some kind of to-do to mitigate
[25:44.710 --> 25:51.790]  some newly emerging risks, not matching something like a new policy that has been put into place.
[25:52.510 --> 25:59.590]  Also, CICD pipelines can check the generated JSON to automatically fail the build or at least flag
[25:59.590 --> 26:07.390]  it as unstable, something like that, if some unmitigated high risks are still there. So having
[26:07.390 --> 26:12.990]  the risk tracking state inside Threadger and having the remaining risks, that way you can also
[26:12.990 --> 26:19.770]  just evaluate that data in the JSON file. And then you can just fail the build if you want to avoid
[26:19.770 --> 26:27.150]  an automatic rollout into production where new high risks have not yet been checked, at least.
[26:27.150 --> 26:32.770]  So that's something that is definitely ready for DevSecOps approaches. That means Thread modeling,
[26:32.770 --> 26:37.930]  continuous Thread modeling, becomes part of a DevSecOps approach.
[26:38.150 --> 26:42.090]  And that's basically what Threadger is about, about agile Thread modeling.
[26:43.210 --> 26:48.570]  Hopefully, security is then less bottleneck for Thread model sign-offs. That basically means
[26:48.570 --> 26:53.970]  the security team can more focus on the individual risks and not the standard that have been
[26:54.630 --> 27:01.210]  easy to identify in some kind of coded risk rules. So that's easy and it's shifting things
[27:01.210 --> 27:06.850]  more on the left side, so that by development teams beginning from early on to maintain and
[27:06.850 --> 27:12.230]  create the YAML file, then you have a very early integration of Thread modeling that doesn't do
[27:12.230 --> 27:15.950]  any kind of bottleneck effects on your security.
[27:16.790 --> 27:22.890]  So it's released as an open source tool. The website is Threadger.io. There's a Playground
[27:22.890 --> 27:27.790]  available, run Threadger.io. The source is available on GitHub and Docker images are
[27:27.790 --> 27:32.290]  available as well. If you have any questions, feel free to ask. You've got my contact data
[27:32.290 --> 27:40.250]  there as well. Special thanks definitely to those valuable feedbacks from all the beta users,
[27:40.250 --> 27:47.470]  especially to those here, like in alphabetical order, very early adapters of Threadger.io and
[27:47.470 --> 27:54.250]  very valuable feedback. Thanks. And I'd like to thank you as well. So a little bit of Q&A
[27:54.250 --> 27:58.470]  if you like, and look forward to seeing you later in the chat.