start	end	text
12950	17630	Good morning, good afternoon, and good morning to our fellow viewers across the globe.
17890	21510	My name is Joe Christian and I'd like to personally welcome you to day three of AppSec
21510	27030	Village at DEF CON 28. First, I'd like to thank our sponsors for check marks, Google,
27030	31390	and Offensive Security. Without them, we could not have provided you all this amazing village
31390	36430	this year. I'd like to issue another thank you to DEF CON and all of our volunteers for their blood,
36430	41490	sweat, and tears poured into this incredible effort. Lastly, I'd like to thank the community
41490	46110	for supporting us another wonderful year. This village is for you. With that being said,
46110	50610	I'd like to introduce our first speaker today, Christian Snyder. Christian's talk is titled
50610	56270	ThreadGile, Agile Threat Modeling with Open Source Tools from Within Your IDE. Christian has
56270	60890	pursued a successful career as a freelance Java software developer since 1997 and expanded in
60890	66290	2005 to include the focus on IT security. His major areas of work are penetration testing,
66290	70670	security architecture consulting, and threat modeling. As a trainer, Christian regularly
70670	75550	conducts in-house training courses on topics like web application security and coaches Agile
75550	80170	projects to include security as part of their processes by applying DevSecOps concepts.
80730	83430	Christian regularly enjoys speaking and giving trainings on major national
83430	87330	and international conferences. Please give a warm welcome to Christian.
88210	94310	Hello, welcome to my talk. My name is Christian Snyder and I'd like to introduce you to ThreadGile,
94310	99830	the new open source toolkit for Agile Threat Modeling. I'm working as a freelance security
99830	105310	architect, penetration tester, and trainer, mainly focusing on areas like DevSecOps,
105310	111490	security architecture consulting, and Agile Threat Modeling. With ThreadGile, the idea is
111490	116090	to bridge the gap between classic, more workshop-like threat modeling approaches
116710	124850	and Agile development with a fast pace of rollouts and a fast set of commits and eventually using
124850	131850	DevSecOps approaches, a very Agile and very quick way of rolling out into production and not
131850	139270	neglecting threat modeling in these kinds of setups. And the idea is to let developers create
139270	145410	some declarative threat model inside their IDE that is basically not required to go to a different
145410	151470	tool or switch the work mode of operation, just maintain in a declarative fashion, everything
151470	157030	about your application, your architecture, in a very simple-to-read, human-readable YAML file.
157090	162530	That includes like classic threat modeling approaches, the data assets, the components,
162530	167710	technical components, and the communication links between them, where the data flows,
167710	173650	and trust boundaries that might be crossed by communication links. That YAML file can be
173650	179050	checked in in the source tree as any other artifact. So the benefits of that, it's diffable,
179050	185990	it's collaboration capable, it's testable, verifiable, you can easily just start along with the project.
187050	193530	And the modeled elements, especially the technical elements in that YAML file, contain very detailed
193530	200850	levels of the technology and the protocols that are chosen in order to be able to have a very good
200850	206790	risk generation from some kind of risk rules. So ThreadGeneral has a set of built-in risk rules
206790	213030	that analyzes these kinds of sets and treats this as a connected graph of components,
213030	219510	and deriving risks, potential risks, threats, hardening recommendations, documentations,
219510	224150	model graphs, data flow diagrams, and different output formats from that.
224670	230190	And even custom risks can be added, because as any tool, you cannot identify every risk
230190	237430	with a tool. So you need to have some manually identified risks that can be added to that model
237430	242630	as well, because sometimes in these kinds of workshops, you come up with new risks that have
242630	248190	not been identified by any kind of tool. And this can be added into the YAML file as well.
248630	253970	ThreadGeneral is a technology-aware way of modeling your architecture. So you define
253970	258890	what type of technology is used, what protocols are used, so it understands from that whether
258890	265690	it's encrypted or not, for example. It has around 40 risk rules, so it's growing. And you can even
265690	271270	create custom risk rules. It calculates some attacker attractiveness and data loss probabilities
271270	277410	more on that later on. And you can even automate things using model macros in a very wizard-style
277410	282730	approach. And even the risk mitigation can be maintained in that YAML file, so that even the
282730	290130	tracking and the remaining risks that you want to accept are documented that way. And of course,
290130	296730	it's released as an open-source software. So in ThreadGeneral, basically you run it as a
296730	302450	command-line interface. It's shipped as a docker container, or you can execute it as a web server
302590	308750	with a REST interface. Here you just see the command-line interface with just a few of the
308750	314870	many switches and options that you can use. So the first steps within ThreadGeneral are that you
314870	320430	create either a minimal stub model that can be created from ThreadGeneral as well, or a filled
320430	325950	example model if you want to play with it and see how it works. And it's basically containing that
325950	330710	YAML file that's the input into ThreadGeneral, the data assets, the technical assets, the
330710	336550	communication links, and the trust boundaries, and a little bit more if you like. So here you see
336550	345090	the YAML example of data assets, customer contracts, has some kind of owner, some kind of origin,
345090	350490	especially the confidentiality, integrity, and availability ratings are interesting. So you can
350490	357410	rate the data assets, how confidential for example they are. And you can model technical assets as
357410	365350	well in that YAML file. So for example here, an Apache web server where you can define again the
366450	370930	confidentiality, integrity, and availability ratings. But you can also define a technology
370930	376330	out of a bunch of possible technologies. And you could define a little bit more whether it's used
376330	382790	by a human, that would be more like being a client or browser for example. What type it is, like a
383090	388430	process, external entity, or data store. And you can tag it if you like, and whether it's encrypted
388430	396690	or not. So a few questions you can answer there as well. Then you can reference data assets that
396690	403750	are processed or stored on that kind of technical asset just by their ID. So from the ID referencing
403750	409750	Threja learns the distribution of data and the distribution of data that's processed on those
409750	415850	kinds of technical assets. And then you just model the communication links. So basically
416550	421490	pointing from one system, from one technical asset to another component, another technical
421490	427950	asset. So it's an outgoing communication link and you can even attribute that with the kind of
427950	433050	protocol that's being used. Whether it's let's say here HTTPS or it could be FTP or whatever
433050	439710	whatever you'd like, LLAP. That's a big list of protocol values that you can choose from.
440010	445390	And Threja even knows whether it's an encrypted or not encrypted protocol. You can define what
445390	450250	kind of authentication is happening, whether it's not authenticated, that communication link or
450250	456130	just uses credentials or a token-based approach. And if it's authenticated you can define with
456130	462550	what kind of authorization. Either the technical user or an end user identity or something like
462550	466990	that. And you can answer a little bit more questions and you can reference the data assets
466990	472630	that are sent and eventually received from that kind of communication link.
474070	481750	Finally, you model the trust boundaries. These are basically the let's say virtual network areas
482390	487670	where you want to have some kind of network trust boundary between them or in a containerized world
487670	492210	eventually namespace isolation, something like that. You can model that. So different types of
492210	497170	trust boundaries are existing. And then you just reference the technical assets that are used
497170	502490	inside. And if you do nest trust boundaries, definitely something that's possible, you can
502490	509590	reference them as well. Then when you execute fragile on the command line, it processes the
509590	515850	YAML input and applies the RISC rules. So there are lots of built-in RISC rules and you can even
515850	521730	add your custom ones and it creates some nice output. First of all, here an example. It gives
522170	528010	a model graph. It generates a model graph that you can see whether you have modeled something
528010	535010	wrong or something is missing from your architecture. The colors in the lines as well
535010	541730	as in the shapes are referring, depending on the data ratings that are being stored there, to the
541730	549490	sensitivity of that kind of asset. So a red border means that there are very sensitive data stored
549490	556410	or a red line means there's very sensitive data being transferred. And the color like the yellow
556410	561030	ones means there's custom developed code and the shape is a little bit depending whether it's a
561030	569830	data store, process, external entity or a client used by a human. So there's a set of semantics
569830	577130	behind these kinds of colors. And it generates a PDF and Excel report. So very long in terms of
577130	584650	being also some kind of documentation artifact. And this kind of report has some redundancy in
584650	590930	it because it has two different views. It has a view of risks by vulnerability category and a view
590930	597410	of risks by technical asset. So let's dive a little bit into the reports that have been generated.
597410	603430	You see some management summary with some pie charts depending on the risk severity and also
603430	608370	on the risk tracking state. You can add your custom management summary text as well. And you
608370	613270	have got the impact. That's basically the impact from the identified risks, including some individual
613270	619570	added one here, the critical one. More on that later. And also you can define and see the risk
619570	625630	mitigation here. So in the risk mitigation chart, you see bar charts going up. So where basically
625630	632410	the distribution of the risks that have been identified are grouped by the tracking state,
632410	637270	which you maintain as well in the YAML file. So you can have something that's in progress here in
637270	643970	blue or mitigated in green or something that has been accepted as a risk in pink or the red ones
643970	650830	are just unchecked. And you've got the impact analysis of the remaining ones. Also for classic
650830	657890	threat modeling, you do have the stride classification of the identified risks, spoofing, tempering,
657890	663050	repudiation, information disclosure, and other kinds of categories. And you've got an assignment
663050	669070	by function. So who, what kind of party in your corporation or team shall basically handle that
669070	674270	kind of risk? So who should address that? So is it business side, architecture side, development,
674270	682670	operations, something like that. Also ThreadGile calculates the RAA, the relative attacker
682670	688090	attractiveness value, which is just a percentage value ranging from zero to 100%. The higher,
688090	693830	more attractive for attackers, the technical asset is. So these values are assigned to technical
693830	700250	assets. And there's an algorithm which is pluggable. You can plug in your own custom algorithm if you
700250	705950	like. And that algorithm basically treats the amount and the sensitivity of data on the assets
705950	711550	and as well as the communication links and the paths that attackers can take to go to these.
711550	718490	If a sibling of another system is having less sensitive data, but connects to that
718490	723850	very high sensitive data carrying system, that kind of neighboring system is also rated a little
723850	731990	bit higher. And DLP, data loss probabilities, are also calculated. So here you see inside the report
732570	739770	a graph, which here on the left side contains lots of red data assets. And the right side of
739770	746970	the shapes are basically the components and the errors, depending whether it's a dashed or a
746970	753310	solid error is whether it's processed on that asset or stored on that asset. And depending
753310	758770	on the sensitivity of the data, you can see here if you eventually have some risks where you might
758770	766610	want to handle that. And the colors here reflect the risk of the data loss probability, which is
766610	773710	basically depending on how many data assets, how many technical assets the data assets are stored
773710	780170	or processed, and how many risks are there on these assets that might have a blast impact of losing
780170	785650	that data. So in the detailed report, you even have the individual risks listed that you should
785650	791510	mitigate, especially the red ones, which would yield the biggest benefit of going from red to
791510	797530	amber or even a better color that you're not risking the data loss there. So that way you can
797530	803670	basically prioritize, depending on the data risks that you might lose them, your efforts of
803670	810830	mitigation of those identified risks. And the risk mitigation recommendations are also created here.
810830	817710	So you see some server-side request forgery or XML external entity attack in these examples here,
817710	825190	where you have risk mitigation texts, including links to the OWASP ASVS chapters and to the OWASP cheat
825190	830470	sheet. That's basically if it's available for that kind of risk, giving the developer and team
830470	837070	some kind of hints on how to mitigate that. The risk instances are also obviously inside the
837070	841530	report. Everything's linked and clickable, so you can click and easily navigate around
841530	848110	in that report. And you have it either grouped by the vulnerability type on the left side,
848110	852730	or on the right side, you've got the risks by a technical asset, so that you can get from that
852730	857670	kind of view also to the risks and the descriptions of how you can mitigate them.
858170	863970	Of course, you get an Excel report as well for easier filtering, sorting, and stuff like that.
863970	870410	Same data, different format. And being DevSecOps ready, that means the results are also available
870410	877090	as a JSON output. So you can process them inside Jenkins or any kind of other GitLab CI, or
877090	883290	whatever you like, some kind of DevSecOps pipelines. So CICD pipelines can then execute
883290	888710	fragile as a command line or via the REST server, if you like, depends on what you want to do.
888730	893850	And the result is a JSON file listing the remaining risks and their distribution across
893850	898950	the different severity levels. And then you can, for example, automatically break a build
898950	905070	if a system includes or a build includes some yet unchecked high risks.
906470	911570	And the risk rules, that's a set of constantly growing risk rules. So there are around 40-ish
911570	917330	something in it, and you can extend that with more risk rules if you like. So that's growing
917330	924530	on a day-by-day basis. And risk rules are written in Go inside Fragile. Fragile is itself written
924530	930770	completely in Go. And here you see an example for a risk rule. This is an LDAP injection. So
930770	936050	you have some category definition where you have the texts and the cheat sheet links and basically
936050	941470	the metadata that the report is generated properly for that kind of risk. And on the right side,
941470	946910	you see the very simple code to identify those risks. So it's basically some kind of graph
948530	953450	identification from the assets that you modeled and the communication links that you modeled.
954650	961190	You can even, if you like, add manually identified risks to Fragile in the same YAML file. So the
961190	968050	same input file can include manually identified risks. These that are not usually identifiable
968050	973490	by tool. So for example, in a classic threat modeling workshop, you identify those additional
973490	978550	risks and you do not want to track them in a separate way. You want to keep them in the same
978550	985170	way that you track the tool-based identified risks inside Fragile. And that can be done
985170	990810	by simply enhancing the YAML input file with individual risks. So here you provide the
990810	996310	metadata of the text, what happened in that kind of risk that you identified, how it should be
996310	1002070	mitigated and stuff like that. Here you provide that basically as values inside the YAML file.
1002070	1006970	And on the right side, you see that this risk has two instances. So it has, for example,
1006970	1012470	been identified at some database and on some file system server here. And you can even link
1012470	1017910	to the technical assets that are the most relevant, have the most relevance of losing
1017910	1024150	that kind of data when that risk manifests itself. So that way, the blast impact of the
1024150	1030610	data loss probability is also reflected with that kind of manually added risk.
1031510	1036750	You do have very good editing support in IDEs for YAML files. That's definitely something
1036750	1041390	that's been around for some time, even in VI, if you like. So there are many YAML editors
1041390	1047130	available. It's easily readable by humans. For example, in my IDE, I do have here on the right
1047130	1053250	side a tree that I can click to navigate inside the YAML file. So that's automatically populated
1053250	1058610	from the structure of the YAML file. So that's definitely something that's having a very good
1058610	1067870	support of IDEs. It doesn't stop there. It goes even into schema validation and auto-completion.
1067870	1075000	So Thragil supports IDEs by having a YAML schema available for the Thragil model.
1075790	1081550	That basically means you can import that YAML file into the IDE. And then you have some kind
1081550	1086890	of automated checking of the syntax. And you get some error flags. For example, here on the left
1086890	1092550	side, I've got a typo web server with many Rs. So that's definitely flagged as an invalid technology
1092550	1098730	type. And that's something that has been validated by the IDE due to the schema. And that schema
1098730	1103310	gives me also some kind of auto-completion. So when I type on the technology web and hit
1103870	1108670	a control space, the pop-up basically includes everything that begins with web, like web
1108670	1113730	application, web server, or what else. So that's some kind of auto-completion that you just get
1113730	1121910	for free by simply importing the Thragil YAML file schema into your whatever IDE or YAML editor
1121910	1129890	you use. You can also have some kind of live templates for quicker editing of and creation
1129890	1136010	of those elements, like technical assets, communication links, or data assets, or something
1136010	1142850	like that. So importing these templates in major IDEs allows you just to hit a tech asset, enter,
1142850	1147730	bam, you've got a pre-populated template where you just give it a name and then you tap through
1147730	1153330	those elements and hit control space to open the auto-completion pop-ups. And that's a little bit
1153330	1160470	like a Zen coding style. Definitely something nice. And we do have model macros inside Thragil.
1160470	1165350	That's basically some kind of interactive wizard. So that's a little bit like a state machine that
1165350	1171290	you can create. And each model macro has a set of questions that are being asked in a sequential,
1171290	1178950	interactive way. And it reads, each model macro reads the YAML file of an existing model and it
1178950	1184010	asks you questions of what you would like to do. And so we do have different model macros like
1184010	1188430	adding a build pipeline or adding a vault or adding identity provider, including an identity
1188430	1196210	storage to the model. And that way you can codify and reuse and make this a little bit individual
1196210	1202590	due to the questions that you ask the user. The kinds of repeating model elements that you have
1202590	1208730	in your corporation or in your teams and make them, adding these, modifying the model files
1208730	1213850	that way in a very easy way. So a pluggable interface also allows you to create your own
1213850	1220610	model macros. So how does this look like? It's on the command line. So you do have, for example,
1220610	1224970	here a add build pipeline model macro where you have just a few questions that you answer
1224970	1229670	and then you can select on which kind of components this build pipeline should deploy,
1229670	1234630	for example. So it reads the model and it modifies it accordingly and you can create
1234630	1240070	new trust boundaries for that. Is it either push-based or pull-based deployments? More on
1240070	1247650	the GitOps style. And then you've got a summary, like a dry run, of what would be added to the
1247650	1253570	model and adding new data assets, adding new technical assets, including the communication
1253570	1258730	links, adding new trust boundaries. So all these modifications are done automatically then. And
1258730	1264850	the result is you get something more out of that. So you get the communication paths added as well.
1265970	1271990	Okay, so what about risk tracking? So inside the YAML file, you also have a way to
1273250	1280190	track the identified risks by a unique risk ID. And you can even group them with bytecards to
1280190	1286850	have some kind of sets of risks of the same type for the same component or something like that,
1286850	1293090	to be tracked in the same style. And you can assign a status, like whether it's unchecked,
1293090	1298330	that's the default state if it's not being tracked yet, or the risk is in discussion,
1298770	1303190	or whether the risk has been accepted and it just remains as a remaining risk,
1303190	1308990	or whether it's in progress, so you're working on mitigating it, or it has been mitigated,
1308990	1313770	or whether it's a false positive. Sometimes tools also have false positives, definitely.
1314830	1319950	And you can add a justification. Optionally, you can add a ticket ID, a date, and a check by
1319950	1325770	name tag, so you can track that in a very good way. And even a model macro is existing that
1325770	1332750	reads an existing YAML file, applies the risk tracking, and then it generates the yet-untracked
1332750	1340250	risk instance IDs, and they're tracking with the unchecked still, obviously, state that you can
1340250	1347530	then individually shift to some kind of other state. And out of the risk tracking definitions
1347530	1354490	in the same YAML file, you get the risk mitigation state you just saw recently here in the talk,
1354490	1360950	in the PDF file, you see it on the right side. What about bigger models? Of course,
1360950	1365370	bigger models work well, and even way bigger models work well. Something we did
1365910	1370730	in beta testing of Thragil, definitely, even way bigger models work quite good.
1371730	1377250	Also, a REST server is existing inside Thragil, so you do have some, in the Docker container,
1377250	1382650	some way to start it and expose a port, and that port is basically giving you a way to
1383190	1390250	use Thragil like a REST API. That means you can send in the YAML file and get a zip file
1390250	1397490	where all those artifacts are in that Thragil generates. And you can also, in the next version,
1397490	1402590	then basically create a model on the server side that start that way in an encrypted fashion.
1402610	1406630	And then you can add data assets to it, you can add technical assets to it, you can add
1406630	1410750	communication links to it, apply the risk tracking, import or export the model file,
1410750	1414450	if you like, something like that. And if you want to play a little bit with that,
1414450	1418610	there's even a playground online. It's just on run.thragil.io.
1420250	1426570	So what are the possible effects of modeling risks or modeling threats or applying threat
1426570	1431290	modeling actually in some kind of YAML file and letting the risks and the threats being
1431290	1437590	generated by an open source tool that way? So not leaving the IDE, making it pluggable,
1437590	1443850	the risk rating scheme or the risk rules means that corporations can even have their individual
1443850	1451150	policies coded in some kind of easy to code and go long risk rules. And these custom code
1451150	1456650	risk rules can analyze the model graph according to the corporate individual policies.
1457770	1463490	Also, if many more projects are using it inside a corporation, you can then, for example, have
1463490	1469710	some kind of uniform documentation of the system landscape built bottom up, project by project,
1469710	1474170	system by system. You can even try to link them in a very good way if you like.
1474770	1480190	And it's built by the dev teams in their IDEs. They're not leaving their tools of choice and
1480190	1485490	they do it in their favorite IDE. And it's just running along within the code base, checked in
1485490	1490990	in some kind of YAML file. That's it. So it's easy to keep that up to date compared to classic
1490990	1497530	threat model approaches. So it's a way to have continuous threat modeling. It's easy to instantly
1497530	1504530	regenerate from some kind of project, the risk landscape. So if something changes, for example,
1504530	1511150	so for example, a data classification changes, being more confidential, or some component is
1511150	1516330	moved into the cloud. So something like that. Then you can just regenerate it and see if some
1516330	1522790	new risks might emerge from that kind of change. And you can do that instant risk regeneration
1522790	1529530	even on corporate level. So for example, when a policy changes or a new policy is introduced,
1529530	1534510	some new regulatory policies, for example, then you can adjust your custom risk rules
1534510	1539870	accordingly or create a new one and then just execute Threadger on all of your projects.
1539870	1544710	And then you might see which of these projects eventually have some kind of to-do to mitigate
1544710	1551790	some newly emerging risks, not matching something like a new policy that has been put into place.
1552510	1559590	Also, CICD pipelines can check the generated JSON to automatically fail the build or at least flag
1559590	1567390	it as unstable, something like that, if some unmitigated high risks are still there. So having
1567390	1572990	the risk tracking state inside Threadger and having the remaining risks, that way you can also
1572990	1579770	just evaluate that data in the JSON file. And then you can just fail the build if you want to avoid
1579770	1587150	an automatic rollout into production where new high risks have not yet been checked, at least.
1587150	1592770	So that's something that is definitely ready for DevSecOps approaches. That means Thread modeling,
1592770	1597930	continuous Thread modeling, becomes part of a DevSecOps approach.
1598150	1602090	And that's basically what Threadger is about, about agile Thread modeling.
1603210	1608570	Hopefully, security is then less bottleneck for Thread model sign-offs. That basically means
1608570	1613970	the security team can more focus on the individual risks and not the standard that have been
1614630	1621210	easy to identify in some kind of coded risk rules. So that's easy and it's shifting things
1621210	1626850	more on the left side, so that by development teams beginning from early on to maintain and
1626850	1632230	create the YAML file, then you have a very early integration of Thread modeling that doesn't do
1632230	1635950	any kind of bottleneck effects on your security.
1636790	1642890	So it's released as an open source tool. The website is Threadger.io. There's a Playground
1642890	1647790	available, run Threadger.io. The source is available on GitHub and Docker images are
1647790	1652290	available as well. If you have any questions, feel free to ask. You've got my contact data
1652290	1660250	there as well. Special thanks definitely to those valuable feedbacks from all the beta users,
1660250	1667470	especially to those here, like in alphabetical order, very early adapters of Threadger.io and
1667470	1674250	very valuable feedback. Thanks. And I'd like to thank you as well. So a little bit of Q&A
1674250	1678470	if you like, and look forward to seeing you later in the chat.