1
00:00:12,950 --> 00:00:17,630
Good morning, good afternoon, and good morning to our fellow viewers across the globe.

2
00:00:17,890 --> 00:00:23,230
My name is Joe Christian and I'd like to personally welcome you to day three of AppSec Village at DEF CON 28.

3
00:00:23,610 --> 00:00:28,370
First, I'd like to thank our sponsors for check marks, Google, and Offensive Security.

4
00:00:28,510 --> 00:00:32,210
Without them, we could not have provided you all this amazing village this year.

5
00:00:32,290 --> 00:00:39,170
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.

6
00:00:39,570 --> 00:00:43,690
Lastly, I'd like to thank the community for supporting us another wonderful year.

7
00:00:43,710 --> 00:00:45,110
This village is for you.

8
00:00:45,210 --> 00:00:48,970
With that being said, I'd like to introduce our first speaker today, Christian Snyder.

9
00:00:49,390 --> 00:00:55,490
Christian's talk is titled ThreadGile, Agile Threat Modeling with Open Source Tools from Within Your IDE.

10
00:00:55,870 --> 00:01:03,950
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.

11
00:01:03,950 --> 00:01:09,170
His major areas of work are penetration testing, security architecture consulting, and threat modeling.

12
00:01:09,510 --> 00:01:20,170
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.

13
00:01:20,730 --> 00:01:25,490
Christian regularly enjoys speaking and giving trainings on major national and international conferences.

14
00:01:25,490 --> 00:01:27,330
Please give a warm welcome to Christian.

15
00:01:28,210 --> 00:01:30,410
Hello, welcome to my talk.

16
00:01:30,410 --> 00:01:37,290
My name is Christian Snyder and I'd like to introduce you to ThreadGile, the new open source toolkit for Agile Threat Modeling.

17
00:01:37,670 --> 00:01:48,990
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.

18
00:01:48,990 --> 00:02:15,290
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.

19
00:02:15,750 --> 00:02:32,850
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,

20
00:02:32,850 --> 00:02:37,030
your architecture, in a very simple-to-read, human-readable YAML file.

21
00:02:37,090 --> 00:02:51,910
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.

22
00:02:52,670 --> 00:02:56,810
That YAML file can be checked in in the source tree as any other artifact.

23
00:02:56,890 --> 00:03:05,990
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.

24
00:03:07,050 --> 00:03:24,550
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.

25
00:03:24,550 --> 00:03:41,510
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,

26
00:03:41,510 --> 00:03:44,150
and different output formats from that.

27
00:03:44,670 --> 00:03:51,230
And even custom risks can be added, because as any tool, you cannot identify every risk with a tool.

28
00:03:51,350 --> 00:04:05,290
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.

29
00:04:05,290 --> 00:04:08,190
And this can be added into the YAML file as well.

30
00:04:08,630 --> 00:04:13,270
ThreadGeneral is a technology-aware way of modeling your architecture.

31
00:04:13,270 --> 00:04:20,970
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.

32
00:04:20,970 --> 00:04:24,430
It has around 40 risk rules, so it's growing.

33
00:04:24,650 --> 00:04:27,150
And you can even create custom risk rules.

34
00:04:27,150 --> 00:04:32,990
It calculates some attacker attractiveness and data loss probabilities more on that later on.

35
00:04:32,990 --> 00:04:38,390
And you can even automate things using model macros in a very wizard-style approach.

36
00:04:38,390 --> 00:04:49,410
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.

37
00:04:49,670 --> 00:04:52,250
And of course, it's released as an open-source software.

38
00:04:53,610 --> 00:04:57,650
So in ThreadGeneral, basically you run it as a command -line interface.

39
00:04:57,650 --> 00:05:03,970
It's shipped as a docker container, or you can execute it as a web server with a REST interface.

40
00:05:04,310 --> 00:05:11,290
Here you just see the command-line interface with just a few of the many switches and options that you can use.

41
00:05:12,130 --> 00:05:23,850
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.

42
00:05:24,130 --> 00:05:34,990
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.

43
00:05:35,450 --> 00:05:50,110
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.

44
00:05:50,110 --> 00:05:55,310
So you can rate the data assets, how confidential for example they are.

45
00:05:55,310 --> 00:05:59,110
And you can model technical assets as well in that YAML file.

46
00:05:59,250 --> 00:06:09,250
So for example here, an Apache web server where you can define again the confidentiality, integrity, and availability ratings.

47
00:06:09,250 --> 00:06:13,610
But you can also define a technology out of a bunch of possible technologies.

48
00:06:14,030 --> 00:06:21,050
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.

49
00:06:21,050 --> 00:06:25,750
What type it is, like a process , external entity, or data store.

50
00:06:25,750 --> 00:06:29,070
And you can tag it if you like, and whether it's encrypted or not.

51
00:06:29,070 --> 00:06:32,710
So a few questions you can answer there as well.

52
00:06:34,010 --> 00:06:41,970
Then you can reference data assets that are processed or stored on that kind of technical asset just by their ID.

53
00:06:42,050 --> 00:06:51,610
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.

54
00:06:52,690 --> 00:06:55,230
And then you just model the communication links.

55
00:06:55,230 --> 00:07:02,090
So basically pointing from one system, from one technical asset to another component, another technical asset.

56
00:07:02,090 --> 00:07:09,510
So it's an outgoing communication link and you can even attribute that with the kind of protocol that's being used.

57
00:07:09,510 --> 00:07:15,050
Whether it's let's say here HTTPS or it could be FTP or whatever whatever you'd like, LLAP.

58
00:07:15,170 --> 00:07:19,710
That's a big list of protocol values that you can choose from.

59
00:07:20,010 --> 00:07:24,190
And Threja even knows whether it's an encrypted or not encrypted protocol.

60
00:07:24,390 --> 00:07:33,510
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.

61
00:07:33,790 --> 00:07:37,750
And if it's authenticated you can define with what kind of authorization.

62
00:07:37,750 --> 00:07:42,750
Either the technical user or an end user identity or something like that.

63
00:07:42,750 --> 00:07:52,630
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.

64
00:07:54,070 --> 00:07:56,810
Finally, you model the trust boundaries.

65
00:07:57,010 --> 00:08:10,170
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.

66
00:08:10,170 --> 00:08:11,290
You can model that.

67
00:08:11,290 --> 00:08:14,130
So different types of trust boundaries are existing.

68
00:08:14,270 --> 00:08:18,230
And then you just reference the technical assets that are used inside.

69
00:08:18,310 --> 00:08:24,510
And if you do nest trust boundaries, definitely something that's possible, you can reference them as well.

70
00:08:25,210 --> 00:08:33,670
Then when you execute fragile on the command line, it processes the YAML input and applies the RISC rules.

71
00:08:33,670 --> 00:08:39,310
So there are lots of built-in RISC rules and you can even add your custom ones and it creates some nice output.

72
00:08:39,310 --> 00:08:41,150
First of all, here an example.

73
00:08:41,150 --> 00:08:43,190
It gives a model graph.

74
00:08:43,190 --> 00:08:51,370
It generates a model graph that you can see whether you have modeled something wrong or something is missing from your architecture.

75
00:08:51,690 --> 00:09:04,490
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.

76
00:09:04,490 --> 00:09:13,690
So a red border means that there are very sensitive data stored or a red line means there's very sensitive data being transferred.

77
00:09:13,990 --> 00:09:25,670
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.

78
00:09:25,670 --> 00:09:31,310
So there's a set of semantics behind these kinds of colors.

79
00:09:32,010 --> 00:09:34,610
And it generates a PDF and Excel report.

80
00:09:34,610 --> 00:09:40,790
So very long in terms of being also some kind of documentation artifact.

81
00:09:40,790 --> 00:09:46,990
And this kind of report has some redundancy in it because it has two different views.

82
00:09:46,990 --> 00:09:53,310
It has a view of risks by vulnerability category and a view of risks by technical asset.

83
00:09:53,910 --> 00:09:57,410
So let's dive a little bit into the reports that have been generated.

84
00:09:57,410 --> 00:10:04,990
You see some management summary with some pie charts depending on the risk severity and also on the risk tracking state.

85
00:10:04,990 --> 00:10:07,750
You can add your custom management summary text as well.

86
00:10:08,150 --> 00:10:09,410
And you have got the impact.

87
00:10:09,410 --> 00:10:15,290
That's basically the impact from the identified risks, including some individual added one here, the critical one.

88
00:10:15,290 --> 00:10:16,530
More on that later.

89
00:10:16,850 --> 00:10:20,970
And also you can define and see the risk mitigation here.

90
00:10:20,970 --> 00:10:24,770
So in the risk mitigation chart, you see bar charts going up.

91
00:10:24,770 --> 00:10:34,610
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.

92
00:10:34,610 --> 00:10:45,910
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.

93
00:10:45,910 --> 00:10:48,750
And you've got the impact analysis of the remaining ones.

94
00:10:49,370 --> 00:11:01,870
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.

95
00:11:01,870 --> 00:11:03,950
And you've got an assignment by function.

96
00:11:03,950 --> 00:11:10,030
So who, what kind of party in your corporation or team shall basically handle that kind of risk?

97
00:11:10,030 --> 00:11:11,330
So who should address that?

98
00:11:11,330 --> 00:11:16,690
So is it business side, architecture side, development, operations, something like that.

99
00:11:17,670 --> 00:11:27,230
Also ThreadGile calculates the RAA, the relative attacker attractiveness value, which is just a percentage value ranging from zero to 100%.

100
00:11:27,230 --> 00:11:31,430
The higher, more attractive for attackers, the technical asset is.

101
00:11:31,430 --> 00:11:34,870
So these values are assigned to technical assets.

102
00:11:35,390 --> 00:11:37,650
And there's an algorithm which is pluggable.

103
00:11:37,650 --> 00:11:40,930
You can plug in your own custom algorithm if you like.

104
00:11:40,930 --> 00:11:51,550
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.

105
00:11:51,550 --> 00:12:05,010
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.

106
00:12:06,110 --> 00:12:09,570
And DLP, data loss probabilities, are also calculated.

107
00:12:09,690 --> 00:12:18,750
So here you see inside the report a graph, which here on the left side contains lots of red data assets.

108
00:12:18,850 --> 00:12:32,650
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.

109
00:12:32,810 --> 00:12:40,870
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.

110
00:12:41,110 --> 00:13:01,250
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.

111
00:13:01,250 --> 00:13:16,610
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.

112
00:13:16,610 --> 00:13:27,370
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.

113
00:13:27,910 --> 00:13:30,830
And the risk mitigation recommendations are also created here.

114
00:13:30,830 --> 00:13:45,910
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.

115
00:13:45,910 --> 00:13:53,190
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.

116
00:13:54,030 --> 00:13:57,590
The risk instances are also obviously inside the report.

117
00:13:57,590 --> 00:14:03,270
Everything's linked and clickable, so you can click and easily navigate around in that report.

118
00:14:03,270 --> 00:14:17,670
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.

119
00:14:18,170 --> 00:14:23,970
Of course, you get an Excel report as well for easier filtering, sorting, and stuff like that.

120
00:14:23,970 --> 00:14:26,270
Same data, different format.

121
00:14:26,390 --> 00:14:31,970
And being DevSecOps ready, that means the results are also available as a JSON output.

122
00:14:32,190 --> 00:14:40,870
So you can process them inside Jenkins or any kind of other GitLab CI, or whatever you like, some kind of DevSecOps pipelines.

123
00:14:40,870 --> 00:14:48,710
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.

124
00:14:48,730 --> 00:14:56,010
And the result is a JSON file listing the remaining risks and their distribution across the different severity levels.

125
00:14:56,010 --> 00:15:05,070
And then you can, for example, automatically break a build if a system includes or a build includes some yet unchecked high risks.

126
00:15:06,470 --> 00:15:09,890
And the risk rules, that's a set of constantly growing risk rules.

127
00:15:09,890 --> 00:15:16,430
So there are around 40-ish something in it, and you can extend that with more risk rules if you like.

128
00:15:16,430 --> 00:15:19,090
So that's growing on a day-by-day basis.

129
00:15:19,610 --> 00:15:23,250
And risk rules are written in Go inside Fragile.

130
00:15:23,250 --> 00:15:25,890
Fragile is itself written completely in Go.

131
00:15:26,230 --> 00:15:29,390
And here you see an example for a risk rule.

132
00:15:29,390 --> 00:15:30,730
This is an LDAP injection.

133
00:15:30,730 --> 00:15:40,510
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.

134
00:15:40,510 --> 00:15:45,270
And on the right side, you see the very simple code to identify those risks.

135
00:15:45,270 --> 00:15:53,450
So it's basically some kind of graph identification from the assets that you modeled and the communication links that you modeled.

136
00:15:54,650 --> 00:16:00,970
You can even, if you like, add manually identified risks to Fragile in the same YAML file.

137
00:16:00,970 --> 00:16:04,970
So the same input file can include manually identified risks.

138
00:16:04,970 --> 00:16:09,270
These that are not usually identifiable by tool.

139
00:16:09,270 --> 00:16:16,950
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.

140
00:16:16,950 --> 00:16:24,330
You want to keep them in the same way that you track the tool-based identified risks inside Fragile.

141
00:16:24,330 --> 00:16:29,650
And that can be done by simply enhancing the YAML input file with individual risks.

142
00:16:29,650 --> 00:16:38,130
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.

143
00:16:38,130 --> 00:16:42,070
Here you provide that basically as values inside the YAML file.

144
00:16:42,070 --> 00:16:45,890
And on the right side, you see that this risk has two instances.

145
00:16:45,890 --> 00:16:51,630
So it has, for example, been identified at some database and on some file system server here.

146
00:16:51,630 --> 00:17:02,010
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.

147
00:17:02,010 --> 00:17:10,610
So that way, the blast impact of the data loss probability is also reflected with that kind of manually added risk.

148
00:17:11,510 --> 00:17:15,830
You do have very good editing support in IDEs for YAML files.

149
00:17:15,830 --> 00:17:20,250
That's definitely something that's been around for some time, even in VI, if you like.

150
00:17:20,250 --> 00:17:22,450
So there are many YAML editors available.

151
00:17:22,550 --> 00:17:24,550
It's easily readable by humans.

152
00:17:24,590 --> 00:17:31,770
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.

153
00:17:31,770 --> 00:17:35,410
So that's automatically populated from the structure of the YAML file.

154
00:17:35,410 --> 00:17:40,910
So that's definitely something that's having a very good support of IDEs.

155
00:17:41,690 --> 00:17:43,170
It doesn't stop there.

156
00:17:43,170 --> 00:17:47,870
It goes even into schema validation and auto-completion.

157
00:17:47,870 --> 00:17:55,000
So Thragil supports IDEs by having a YAML schema available for the Thragil model.

158
00:17:55,790 --> 00:18:00,510
That basically means you can import that YAML file into the IDE.

159
00:18:00,510 --> 00:18:04,090
And then you have some kind of automated checking of the syntax.

160
00:18:04,090 --> 00:18:05,890
And you get some error flags.

161
00:18:05,890 --> 00:18:09,770
For example, here on the left side, I've got a typo web server with many Rs.

162
00:18:09,770 --> 00:18:13,410
So that's definitely flagged as an invalid technology type.

163
00:18:13,410 --> 00:18:17,870
And that's something that has been validated by the IDE due to the schema.

164
00:18:18,070 --> 00:18:20,910
And that schema gives me also some kind of auto-completion.

165
00:18:20,910 --> 00:18:30,690
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.

166
00:18:30,690 --> 00:18:43,150
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.

167
00:18:43,730 --> 00:18:57,170
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.

168
00:18:57,170 --> 00:19:12,730
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.

169
00:19:12,730 --> 00:19:15,190
And that's a little bit like a Zen coding style.

170
00:19:15,290 --> 00:19:16,770
Definitely something nice.

171
00:19:17,810 --> 00:19:20,470
And we do have model macros inside Thragil.

172
00:19:20,470 --> 00:19:23,330
That's basically some kind of interactive wizard.

173
00:19:23,330 --> 00:19:26,270
So that's a little bit like a state machine that you can create.

174
00:19:26,270 --> 00:19:32,670
And each model macro has a set of questions that are being asked in a sequential, interactive way.

175
00:19:33,150 --> 00:19:41,810
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.

176
00:19:41,830 --> 00:19:50,190
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.

177
00:19:50,190 --> 00:19:58,730
And that way you can codify and reuse and make this a little bit individual due to the questions that you ask the user.

178
00:19:59,130 --> 00:20:11,350
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.

179
00:20:11,350 --> 00:20:15,010
So a pluggable interface also allows you to create your own model macros.

180
00:20:15,570 --> 00:20:16,910
So how does this look like?

181
00:20:16,910 --> 00:20:19,030
It's on the command line.

182
00:20:19,090 --> 00:20:30,770
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.

183
00:20:30,930 --> 00:20:36,690
So it reads the model and it modifies it accordingly and you can create new trust boundaries for that.

184
00:20:37,010 --> 00:20:39,870
Is it either push-based or pull-based deployments?

185
00:20:39,870 --> 00:20:42,510
More on the GitOps style.

186
00:20:43,250 --> 00:20:55,750
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.

187
00:20:55,750 --> 00:20:58,550
So all these modifications are done automatically then.

188
00:20:58,550 --> 00:21:01,470
And the result is you get something more out of that.

189
00:21:01,470 --> 00:21:04,850
So you get the communication paths added as well.

190
00:21:05,970 --> 00:21:08,130
Okay, so what about risk tracking?

191
00:21:08,130 --> 00:21:17,510
So inside the YAML file, you also have a way to track the identified risks by a unique risk ID.

192
00:21:17,510 --> 00:21:28,810
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.

193
00:21:28,810 --> 00:21:45,110
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,

194
00:21:45,110 --> 00:21:51,010
so you're working on mitigating it, or it has been mitigated, or whether it's a false positive.

195
00:21:51,010 --> 00:21:53,770
Sometimes tools also have false positives, definitely.

196
00:21:54,830 --> 00:21:56,730
And you can add a justification.

197
00:21:56,730 --> 00:22:03,770
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.

198
00:22:03,770 --> 00:22:25,090
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.

199
00:22:25,630 --> 00:22:37,850
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.

200
00:22:38,870 --> 00:22:40,470
What about bigger models?

201
00:22:40,470 --> 00:22:44,650
Of course, bigger models work well, and even way bigger models work well.

202
00:22:44,650 --> 00:22:50,730
Something we did in beta testing of Thragil, definitely, even way bigger models work quite good.

203
00:22:51,730 --> 00:23:06,670
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.

204
00:23:06,670 --> 00:23:14,730
That means you can send in the YAML file and get a zip file where all those artifacts are in that Thragil generates.

205
00:23:15,110 --> 00:23:22,590
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.

206
00:23:22,610 --> 00:23:32,150
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.

207
00:23:32,150 --> 00:23:36,170
And if you want to play a little bit with that, there's even a playground online.

208
00:23:36,170 --> 00:23:38,610
It's just on run.thragil.io.

209
00:23:40,250 --> 00:23:53,870
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?

210
00:23:53,890 --> 00:24:10,190
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.

211
00:24:10,310 --> 00:24:16,650
And these custom code risk rules can analyze the model graph according to the corporate individual policies.

212
00:24:17,770 --> 00:24:31,150
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.

213
00:24:31,150 --> 00:24:34,170
You can even try to link them in a very good way if you like.

214
00:24:34,770 --> 00:24:37,330
And it's built by the dev teams in their IDEs.

215
00:24:37,330 --> 00:24:42,010
They're not leaving their tools of choice and they do it in their favorite IDE.

216
00:24:42,010 --> 00:24:46,870
And it's just running along within the code base, checked in in some kind of YAML file.

217
00:24:46,870 --> 00:24:47,650
That's it.

218
00:24:47,650 --> 00:24:52,070
So it's easy to keep that up to date compared to classic threat model approaches.

219
00:24:52,070 --> 00:24:54,930
So it's a way to have continuous threat modeling.

220
00:24:55,990 --> 00:25:02,510
It's easy to instantly regenerate from some kind of project, the risk landscape.

221
00:25:02,510 --> 00:25:12,670
So if something changes, for example, so for example, a data classification changes, being more confidential, or some component is moved into the cloud.

222
00:25:12,670 --> 00:25:14,210
So something like that.

223
00:25:14,210 --> 00:25:19,410
Then you can just regenerate it and see if some new risks might emerge from that kind of change.

224
00:25:20,230 --> 00:25:24,530
And you can do that instant risk regeneration even on corporate level.

225
00:25:24,530 --> 00:25:39,870
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.

226
00:25:39,870 --> 00:25:51,790
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.

227
00:25:52,510 --> 00:26:07,070
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.

228
00:26:07,070 --> 00:26:15,890
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.

229
00:26:15,890 --> 00:26:27,150
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.

230
00:26:27,150 --> 00:26:31,190
So that's something that is definitely ready for DevSecOps approaches.

231
00:26:31,190 --> 00:26:37,930
That means Thread modeling, continuous Thread modeling, becomes part of a DevSecOps approach.

232
00:26:38,150 --> 00:26:42,090
And that's basically what Threadger is about, about agile Thread modeling.

233
00:26:43,210 --> 00:26:47,590
Hopefully, security is then less bottleneck for Thread model sign-offs.

234
00:26:47,590 --> 00:26:59,370
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.

235
00:26:59,370 --> 00:27:15,950
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.

236
00:27:16,790 --> 00:27:19,750
So it's released as an open source tool.

237
00:27:19,770 --> 00:27:22,070
The website is Threadger.io.

238
00:27:22,070 --> 00:27:25,250
There's a Playground available, run Threadger.io.

239
00:27:25,250 --> 00:27:29,110
The source is available on GitHub and Docker images are available as well.

240
00:27:29,110 --> 00:27:31,410
If you have any questions, feel free to ask.

241
00:27:31,410 --> 00:27:33,690
You've got my contact data there as well.

242
00:27:34,510 --> 00:27:48,930
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.

243
00:27:48,930 --> 00:27:49,810
Thanks.

244
00:27:50,770 --> 00:27:52,630
And I'd like to thank you as well.

245
00:27:52,630 --> 00:27:58,470
So a little bit of Q&A if you like, and look forward to seeing you later in the chat.