Good morning, 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 AppSec
Village at DEF CON 28. First, I'd like to thank our sponsors for check marks, 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 DEF CON 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
ThreadGile, Agile 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 Agile
projects to include security as part of their processes by applying DevSecOps 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 ThreadGile,
the new open source toolkit for Agile Threat Modeling. I'm working as a freelance security
architect, penetration tester, and trainer, mainly focusing on areas like DevSecOps,
security architecture consulting, and Agile Threat Modeling. With ThreadGile, the idea is
to bridge the gap between classic, more workshop-like threat modeling approaches
and Agile development with a fast pace of rollouts and a fast set of commits and eventually using
DevSecOps 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 ThreadGeneral 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.
ThreadGeneral 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 attacker attractiveness and data loss probabilities
more on that later on. And you can even automate things using model macros in a very wizard-style
approach. And even the risk mitigation can be maintained in that YAML file, so that even the
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 ThreadGeneral, 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. Here 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 ThreadGeneral are that you
create either a minimal stub model that can be created from ThreadGeneral 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 ThreadGeneral, 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, an 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 could define a little bit more whether it's used
by a 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
Threja 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, LLAP. That's a big list of protocol values that you can choose from.
And Threja 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 or
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, 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 fragile on the command line, it processes the
YAML input and applies the RISC rules. So there are lots of built-in RISC rules and 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 a red border means that there are very sensitive data stored
or a 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 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 in the risk mitigation chart, you see bar charts going up. So where basically
the distribution of the risks that have been identified are grouped by the tracking state,
which you maintain as well in the YAML 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, tempering,
repudiation, information disclosure, and other kinds of categories. And you've got an assignment
by function. So who, what kind of party in your corporation or team shall basically handle that
kind of risk? So who should address that? So is it business side, architecture side, development,
operations, something like that. Also ThreadGile calculates the RAA, the relative attacker
attractiveness value, which is just a percentage value ranging from zero to 100%. The higher,
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.
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 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 blast 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 and team
some kind of hints on how to mitigate that. The risk instances are also obviously inside the
report. Everything's linked and clickable, so you can click and easily navigate around
in that report. And you have it either grouped 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 them.
Of course, you get an Excel 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 CI, or
whatever you like, some kind of DevSecOps pipelines. So CICD pipelines can then execute
fragile 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.
And 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 Fragile. Fragile is itself written
completely in Go. And here you see an example for a risk rule. 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 Fragile 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 Fragile. And that can be done
by simply enhancing the YAML input file with individual risks. So here you provide the
metadata of the text, what happened in 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 at some database and on some file system server here. And you can even link
to the technical assets that are the most relevant, have the most relevance of losing
that kind of data when that risk manifests 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 in VI, 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. It doesn't stop there. It goes even into schema validation and auto-completion.
So Thragil supports IDEs by having a YAML schema available for the Thragil 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 Rs. 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 Thragil 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 and 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 a tech asset, enter,
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 a Zen coding style. Definitely something nice. And we do have model macros inside Thragil.
That's basically some kind of interactive wizard. 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 an 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, adding these, modifying the model files
that way in a very easy way. So a pluggable 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 a add build pipeline model macro where you have 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 bytecards 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 have false positives, definitely.
And you can add a justification. Optionally, you can add a ticket ID, a date, and a 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,
bigger models work well, and even way bigger models work well. Something we did
in beta testing of Thragil, definitely, even way bigger models work quite good.
Also, a REST server is existing inside Thragil, so you do have some, in the Docker container,
some way to start it and expose a port, and that port is basically giving you a way to
use Thragil 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 Thragil 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 run.thragil.io.
So what are the possible effects of modeling risks or modeling threats 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 kind of easy to code and go long risk rules. And these custom code
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 built bottom up, project by project,
system by system. You can even try to link them in a very good way if you like.
And it's built by the dev teams in their IDEs. They're not leaving their tools of choice and
they do it in their favorite IDE. And it's just running along within the code base, checked in
in 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 a new policy is 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 Threadger 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 Threadger and having the remaining risks, that way you can also
just evaluate that data in the JSON file. And then you can just fail the build if you want to avoid
an automatic rollout into production where new high risks have not yet been checked, at least.
So that's something that is definitely ready for DevSecOps approaches. That means Thread modeling,
continuous Thread modeling, becomes part of a DevSecOps approach.
And that's basically what Threadger is about, about agile Thread modeling.
Hopefully, security is then less bottleneck for Thread 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. So 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 Thread 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 Threadger.io. There's a Playground
available, run Threadger.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,
especially to those here, like in alphabetical order, very early adapters of Threadger.io 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.