1
00:00:13,280 --> 00:00:15,760
All right, everyone, welcome back.

2
00:00:16,080 --> 00:00:22,100
If you're just joining us here in the AppSec Village, I hope you are ready for a fantastic talk.

3
00:00:22,100 --> 00:00:25,740
If you're still hanging around from the last talk, glad to have you back.

4
00:00:25,740 --> 00:00:27,100
This is going to be awesome.

5
00:00:27,180 --> 00:00:35,380
I wanted to take a few minutes to thank everybody who helped to put on DEF CON this year.

6
00:00:35,440 --> 00:00:38,540
I know this has been very challenging for people.

7
00:00:38,540 --> 00:00:41,060
It's challenging for us at home.

8
00:00:41,060 --> 00:00:48,240
It's doubly challenging to bring a great conference experience to DEF CON.

9
00:00:48,240 --> 00:00:50,260
And we really hope that comes through.

10
00:00:50,260 --> 00:00:53,300
Also take a minute to thank the AppSec Village.

11
00:00:53,320 --> 00:00:58,860
Some people have put in amazingly long hours to make this stuff happen.

12
00:00:58,940 --> 00:01:02,020
And we want to thank them as part of that.

13
00:01:02,540 --> 00:01:07,440
Additionally, if you want to get a shirt, head over to the AppSec Village website.

14
00:01:07,440 --> 00:01:15,060
You can purchase your shirt there for the second incarnation of the AppSec Village.

15
00:01:16,280 --> 00:01:28,820
So for our next talk, we've got Paul Abar and Stanislas Malveaux talking to us about turning the offensive security mindset into a developer's toolbox.

16
00:01:29,960 --> 00:01:31,040
Hi.

17
00:01:31,040 --> 00:01:32,440
Hello, everyone.

18
00:01:32,440 --> 00:01:42,940
Thanks for joining our presentation, which is going to be today about our journey into turning offsec mindset to developer's toolset.

19
00:01:43,560 --> 00:01:47,360
This presentation, we're going to be two of them doing it.

20
00:01:47,680 --> 00:01:51,300
And it's going to be in what we can say three parts.

21
00:01:51,420 --> 00:01:58,580
First one is going to be about a tool that we created inside our company, which is called ChopChop.

22
00:01:58,580 --> 00:02:05,620
And we will come to what happened, what was the context, what was the need for it, and that we're going to explain what happened.

23
00:02:06,100 --> 00:02:15,920
The second one is how did we want to broaden our audience into having more and more and more people using it, and especially developers.

24
00:02:16,160 --> 00:02:23,200
And the last part is going to be the demo that we're going to do with Stanislas, who is here just next to me, and who's going to do it.

25
00:02:23,220 --> 00:02:33,000
So three parts in trying to explain our journey into how we tried at least to achieve it and some of the mistakes, drawbacks, and things that we learned on the way.

26
00:02:33,000 --> 00:02:37,560
So hopefully, we hope that you're going to learn something about it.

27
00:02:38,160 --> 00:02:40,020
All right, let's start.

28
00:02:40,520 --> 00:02:44,760
This graph, we actually took it from CVE details.

29
00:02:44,760 --> 00:02:54,840
And it just shows the number of vulnerabilities and numbers of CVEs that we got starting from a couple of years back to basically now.

30
00:02:54,840 --> 00:03:04,300
So we took this graph last year, and we can realize that between 2016 to 2017, the number of CVEs just doubled.

31
00:03:05,060 --> 00:03:07,220
And this is something that we can see.

32
00:03:07,220 --> 00:03:10,560
Every day and every week, we get new vulnerabilities coming in.

33
00:03:10,560 --> 00:03:16,140
We get Oracle built-in, which is just full, and hundreds of vulnerabilities are inside.

34
00:03:16,140 --> 00:03:24,440
We also get built-in of Microsoft, which are just showing up hundreds of vulnerabilities, or let's say dozens of vulnerabilities each month.

35
00:03:24,440 --> 00:03:29,020
And this is something that's growing, obviously, and we're hearing a lot about this.

36
00:03:29,060 --> 00:03:38,500
And in the last couple of days, last couple of weeks, we got a number of vulnerabilities during the lockdown, which was just massive, and especially critical vulnerabilities.

37
00:03:38,500 --> 00:03:44,020
So this is something that we can feel, and this is getting really, really big.

38
00:03:44,380 --> 00:03:58,480
And when we're taking those numbers, we realize that just by dividing it by 52, the number of weeks that we have per year, we realize we get something like 319 new vulnerabilities.

39
00:03:58,480 --> 00:04:02,660
And this is the number of new vulnerabilities that we get per week.

40
00:04:02,660 --> 00:04:09,560
And this is huge, huge for a team to just realize that we do have to process all this information.

41
00:04:09,560 --> 00:04:22,420
So bear in mind that we are not affected by all those vulnerabilities at the time, but it really depends on your context, on our context, on your customer's context, and so on.

42
00:04:22,420 --> 00:04:32,680
But this is something, some information that needs to be digested by your teams to just realize if you're affected or not, and if you're vulnerable to it or not.

43
00:04:32,680 --> 00:04:41,380
And this is a huge thing to actually realize and to process, especially depending on the size of your team.

44
00:04:42,000 --> 00:04:58,980
And usually when we get a new vulnerability, like the MS17010, or let's say the new vulnerability for the DNS remote card execution on Microsoft, which happened a couple of weeks ago, we usually get the management, because they hear a lot about this on Twitter,

45
00:04:58,980 --> 00:05:07,100
on specific magazines, on specific websites, and they actually hear about like this, and there's like a really big buzz around those vulnerabilities.

46
00:05:07,100 --> 00:05:15,620
And usually they're coming to the security team and just asking, all right, are we affected by this vulnerability or this other one that we heard about?

47
00:05:16,280 --> 00:05:20,160
And this is something that, well, we can understand it, obviously.

48
00:05:20,160 --> 00:05:29,740
And the problem with this is we get to the point where the security team is overwhelmed by the number of new findings that happen each day.

49
00:05:29,740 --> 00:05:42,660
And you get like a backlog, which is full of things that you need to process, and it turns out that the management is coming and coming and coming again to just like ask if we are vulnerable to this, to just answer to the management, to the executive,

50
00:05:42,660 --> 00:05:43,680
and so on.

51
00:05:43,680 --> 00:05:53,160
So something to bear in mind, and this is part of the context that we are in and why we actually had like this old tool ID, and we started like getting this.

52
00:05:53,160 --> 00:05:56,200
So the context was based on this.

53
00:05:56,820 --> 00:06:04,240
So the problematics we had was something circa 2016, when we started having like this kind of philosophy and mindset.

54
00:06:04,240 --> 00:06:10,560
And the idea was we had thousands of servers and domains that had to be scanned daily.

55
00:06:10,620 --> 00:06:28,620
We wanted to scan them to basically for statistics reason, KPI, and having some like fresh data, because obviously as soon as you do a penetration test or any kind of testing, we can consider the test outdated a couple of hours or let's say a couple of days afterwards.

56
00:06:28,620 --> 00:06:34,220
So we wanted to have like fresh data all the time, and daily fresh data.

57
00:06:34,440 --> 00:06:41,460
Second of all is we did not have direct access to the servers in some specific situations.

58
00:06:41,460 --> 00:06:50,120
And this was based because the servers were materialized, because it was managed by other entities, and a couple of other reasons that we had.

59
00:06:50,120 --> 00:06:54,480
So we didn't have like SSH access on all the machines all the time.

60
00:06:54,480 --> 00:07:08,420
So this is why we needed to have like another way into assessing the security of the applications that were exposed on the internet, inside as well in the network, and really we had like a really big context with this.

61
00:07:08,420 --> 00:07:26,900
And we can see that the situation is quite pretty similar to what we can call black box penetration testing, which means that we don't have like administration access to the server, and that we need to like find other ways to qualify and to have an ID if we are vulnerable to this specific value.

62
00:07:27,200 --> 00:07:30,500
The tech landscape that we had was also unclear.

63
00:07:30,720 --> 00:07:37,740
In 2016, 2017, there were a lot of vulnerabilities, especially with WebDAV, if you can remember.

64
00:07:37,740 --> 00:07:46,540
It was like quite a hot topic at the time, but also with struts, because there were a couple of critical vulnerabilities which happened in a couple of days.

65
00:07:47,220 --> 00:07:52,420
So these were the things where, okay, there's a huge vulnerability with struts.

66
00:07:52,440 --> 00:07:54,200
Are we vulnerable to it?

67
00:07:54,200 --> 00:07:55,100
Yes, no.

68
00:07:55,100 --> 00:08:01,200
And can we quantify the number of servers which might be potentially vulnerable to this?

69
00:08:01,200 --> 00:08:04,600
And the last point, but not least, is interesting.

70
00:08:04,600 --> 00:08:08,440
And speaking of which, it's like this lean security, all right?

71
00:08:08,440 --> 00:08:15,340
And it's the idea of ability to perform checks every time, so again and again.

72
00:08:15,340 --> 00:08:23,020
So basically, this kind of like loop, this lean loop that we can have, where we would be able to like spot security regression.

73
00:08:23,680 --> 00:08:28,620
And this remembers like a cool anecdote, if we can say it this way.

74
00:08:28,620 --> 00:08:34,520
There's one company, quite big company, having a bug bounty program.

75
00:08:34,940 --> 00:08:48,280
And after speaking with them, they actually told us that they paid some really good bounty for a specific researcher who found remote code execution on some of the production servers.

76
00:08:48,280 --> 00:08:49,620
They fixed it.

77
00:08:49,780 --> 00:08:55,980
But unfortunately, a couple of weeks later, they redeployed the same vulnerable component.

78
00:08:55,980 --> 00:08:58,920
And another bounty researcher found it.

79
00:08:58,940 --> 00:09:07,180
And they had to pay twice for the same vulnerability that they had, that they had already patched, and that they already paid one researcher for it.

80
00:09:07,180 --> 00:09:10,360
And this is what I'm going to call security regression.

81
00:09:11,340 --> 00:09:21,520
When we're taking the tech and like the developer landscape, unit testing is actually one of the foundations of any kind of like new development.

82
00:09:21,520 --> 00:09:37,620
And I think that like this specific mindset and security regression should definitely be something that we could put on our top priority, just to make sure that we get all those regressions as soon as possible.

83
00:09:37,920 --> 00:09:40,240
We have everything automated right now.

84
00:09:40,240 --> 00:09:43,020
We do have like a lot of pipelines for our developers.

85
00:09:43,020 --> 00:09:45,880
Everything is going faster and faster and faster.

86
00:09:45,880 --> 00:09:49,780
And I think that we can improve our way into this.

87
00:09:49,780 --> 00:09:55,060
And this is some of the reasons why we created our tools, and we wanted to tackle this issue.

88
00:09:55,060 --> 00:09:58,640
Security regression was one of the big parts.

89
00:09:59,000 --> 00:10:00,780
So this was our context.

90
00:10:01,560 --> 00:10:14,140
The needs that we have, so needs from the field, and this was again from like 2016, we had to assess new vulnerabilities, new risks coming in, and we had to do this quickly.

91
00:10:14,140 --> 00:10:21,180
So yeah, 2017, we had Struts, we had RCE, so Remote Code Execution on Drupal.

92
00:10:21,260 --> 00:10:25,960
We had WebDAV, we had like lots, a lot of things happening, obviously.

93
00:10:25,960 --> 00:10:30,200
And we had to process this as fast as we could.

94
00:10:30,360 --> 00:10:31,580
So this was one thing.

95
00:10:31,580 --> 00:10:36,280
The other one was, we had like a small team working on this.

96
00:10:36,400 --> 00:10:40,100
When I'm speaking of small teams, it was three to four people.

97
00:10:40,100 --> 00:11:00,980
All of them were all security-oriented, which is really important for the rest of the journey, because this started introducing some bias, which means that we were security people working with security tools that we wrote, and we were more or less like in our circle and in our comfort zone,

98
00:11:00,980 --> 00:11:19,200
which means that when we started and wanted to deploy to other population and other kind of people, developers, devops, it turns out that we had some interesting gap, I would say, and those bias that we introduced, we're going to try to give you the mistakes and how we tackle these issues.

99
00:11:19,200 --> 00:11:21,860
But never mind, we will come back to this later on.

100
00:11:22,420 --> 00:11:33,520
So we needed a tool which would be fast, so something where we could just say, okay, here is the new vulnerability, run it across all our parameters and see if we get a hit.

101
00:11:33,520 --> 00:11:36,840
The second one was having something reliable.

102
00:11:36,840 --> 00:11:49,800
And when we say reliable, it's mostly interesting for the deterministic return, which means that if we would run the tool twice, we would make sure that if it hits, it would hit again.

103
00:11:50,080 --> 00:11:55,600
So there would be nothing random in the processing.

104
00:11:55,600 --> 00:11:59,440
So we would know exactly how the rules would be triggered.

105
00:11:59,520 --> 00:12:04,000
And if we would run it twice, we should have the same output, obviously.

106
00:12:04,260 --> 00:12:08,280
And the last point, but not least, would be no false positives.

107
00:12:08,480 --> 00:12:12,600
So it's interesting because we need to find like a threshold, right?

108
00:12:12,600 --> 00:12:15,040
We need to have like a tool super fast.

109
00:12:15,040 --> 00:12:20,560
But on the other hand, we don't want any false positives, which is really hard to combine all together.

110
00:12:21,580 --> 00:12:27,540
So it's two criteria, which unfortunately don't really work together.

111
00:12:27,740 --> 00:12:32,520
But we think that we did quite a great job, and this is something that we managed to do.

112
00:12:32,620 --> 00:12:48,640
And considering that a hit, chop chop hit, would be a real hit, which means that if we get something in the output, in the console output, we would have to open an incident, call someone, or start doing like an immediate action, right?

113
00:12:48,640 --> 00:12:52,280
And not having like a lot and lot and lot information to process.

114
00:12:52,360 --> 00:13:00,120
So really trying to like do some kind of like sniper thing, and just making sure that we get to what's really valuable.

115
00:13:00,260 --> 00:13:04,640
So those were our needs, and yeah, trust me, we had a lot of them.

116
00:13:05,660 --> 00:13:12,760
So if we can take an image, an analogy, it would be like more or less like going to the jungle, right?

117
00:13:12,760 --> 00:13:25,000
And it would be like something where we would just have like a machete, and like start just like chopping trees to try to like create a path in like the jungle, so that we could reach our destination point.

118
00:13:25,020 --> 00:13:27,340
But this was like more or less the case.

119
00:13:27,360 --> 00:13:36,040
As you saw beforehand, it was more or less like an approach of like black box testing, where the tech landscape was a bit unclear.

120
00:13:36,140 --> 00:13:47,220
We didn't exactly know what we were doing, and what we wanted to do is like creating hypotheses, and trying to see if it would be valuable for our context.

121
00:13:47,220 --> 00:13:57,300
And making sure that the tool that we released, and that we get, would be something also valuable for other organizations, so that they could customize it for their own environments.

122
00:13:57,300 --> 00:14:02,140
This was like mostly like the whole soul of the application.

123
00:14:02,140 --> 00:14:13,380
So yeah, this analogy, really the analogy of jungle, and having something where we would have to like start chopping trees, and making sure that we're not in danger.

124
00:14:14,760 --> 00:14:17,860
So we were saying chop-chop, chop-chop, and what does it mean?

125
00:14:18,460 --> 00:14:26,920
It's actually a funny name, and it's something coming from Cantonese, which means hurry, and suggest to do something like without delay and right now.

126
00:14:26,920 --> 00:14:32,940
So we thought the name was interesting, and exactly what was like the spirit of the tool.

127
00:14:32,940 --> 00:14:34,840
So this is why we called it chop-chop.

128
00:14:34,840 --> 00:14:44,870
We wanted to have like a tool where if an emergency alert was coming in, we would be able to like respond right now, and having results in no time.

129
00:14:45,160 --> 00:14:51,420
So it was the whole soul, and this is why we kept the name chop-chop, and released the tool with this name.

130
00:14:51,960 --> 00:14:56,820
The tool initially back in 2017 was written with Python.

131
00:14:56,820 --> 00:15:00,720
We started with Python 2.7, then migrated to Python 3.

132
00:15:00,720 --> 00:15:08,720
We got everything working, and following the upcoming month, we started getting plugins that the security team mostly wrote.

133
00:15:08,720 --> 00:15:12,060
And in the end, we came up with 80 plugins.

134
00:15:12,060 --> 00:15:15,220
So 80 things processing, which were done.

135
00:15:15,440 --> 00:15:30,660
Going from trying to find if there was like a .git folder exposed on the internet, or let's say in the web root, accessible in the web root, to also like checking if the RDP port was also open, checking if the port was here, and was just responding.

136
00:15:30,720 --> 00:15:36,580
A couple of things like this, and we started like creating plugins, which were specific to our environment.

137
00:15:36,580 --> 00:15:41,420
Those ones were not released, but this gives you the idea of the flexibility of the tool.

138
00:15:41,420 --> 00:15:45,580
So taking a domain name or an IP, and afterwards doing some processing.

139
00:15:45,580 --> 00:15:48,020
And any kind of processing, basically.

140
00:15:48,440 --> 00:16:04,200
As I said, it was mostly doing things with HTTP, and this was like the whole soul of the application at first, but then afterwards, people started integrating new protocols and new modules to start interacting with other services.

141
00:16:05,500 --> 00:16:16,380
So we had everything running, the ability to run scans daily, with what we called deterministic wizards, which was one of the things we were really eager to have.

142
00:16:16,380 --> 00:16:21,940
So daily scans, basically every day, and allowed us to answer two questions.

143
00:16:21,940 --> 00:16:25,640
The first one would be to answer to the management, are we affected?

144
00:16:25,640 --> 00:16:26,700
Yes, no.

145
00:16:26,700 --> 00:16:35,820
And then afterwards, being able to quantify the number of servers, or number of IPs, which were actually affected with this specific vulnerability.

146
00:16:36,260 --> 00:16:37,540
Is it going to be one?

147
00:16:37,540 --> 00:16:38,880
Is it going to be 100?

148
00:16:38,880 --> 00:16:42,540
Is it going to be dozens, hundreds, thousands?

149
00:16:42,540 --> 00:16:45,480
Is it going to be all the servers at once?

150
00:16:45,500 --> 00:16:49,600
So it's actually quantifying the results, and we were able to do this.

151
00:16:49,600 --> 00:16:58,160
So we would count every console output, every line we would get, and we would have an idea of how many servers would be affected.

152
00:16:58,160 --> 00:17:03,480
And this allowed us, and this saved us a lot of time.

153
00:17:05,040 --> 00:17:21,320
As I said, ChopChop initially was written in Python, and this is an example of a plugin that we wrote, and this one is to try and check, ensure that the git.git repository, .git folder, is not exposed in the web route.

154
00:17:21,340 --> 00:17:38,580
So what it's going to do, it's quite simple, it's going to test on port 80 and on port 443, in HTTP and HTTPS, and it's going to check one specific path, which is going to be .git slash config, and it's going to check for one specific word to appear in the HTTP response.

155
00:17:38,720 --> 00:17:43,620
Based on this, we're going to have a severity, which ranks from 0 to 10.

156
00:17:43,620 --> 00:17:51,320
10 is going to be critical, 0 is going to be informational, quite similar to what we can find with the CVSS code, something similar.

157
00:17:51,320 --> 00:18:12,240
Again, this thing, we will talk about this later on, but we changed it in the new version of ChopChop for particular reasons, and because we thought that having this specific range would be way too far and way too lot of information to process, and based on the audience we wanted to reach,

158
00:18:12,240 --> 00:18:14,700
this is something that was a bit useless.

159
00:18:14,740 --> 00:18:16,600
But we will come back to this.

160
00:18:16,600 --> 00:18:28,020
We had a description, ensuring that the git repository is not accessible from the web root, and one fix, what we can call remediation.

161
00:18:28,400 --> 00:18:38,100
And it was really important for us because afterwards, after using it and using it, we started getting people and non-security people using the results of ChopChop.

162
00:18:38,100 --> 00:18:47,880
And it turns out that some of them were lost by just having an Excel file or anything like this, just an output, ChopChop output, just didn't know exactly what to do with this.

163
00:18:47,880 --> 00:19:01,220
So we started implementing remediations to give some insights and some inputs, so that people could work on their own by just giving them a bunch of pieces so that they could start working on the remediation and mitigation.

164
00:19:01,640 --> 00:19:12,480
So this is the kind of plugins that we had, written in Python, giving you some information, so you just had to inherit from the plugin class that we had.

165
00:19:12,480 --> 00:19:19,400
And afterwards, you would just have to override a couple of things and you would be start to go.

166
00:19:20,740 --> 00:19:25,720
Here are some things that we managed to find on production systems.

167
00:19:26,000 --> 00:19:40,080
So for example here, we managed to get repository access for SVN with some files, wc.db, which allowed us afterwards to basically fetch anything from the SVN repository, and afterwards getting the source code and so on.

168
00:19:40,080 --> 00:19:41,620
So this was quite problematic.

169
00:19:41,620 --> 00:19:52,080
We also had things like htpassword, which was not interpreted by the application server, for some reasons, misconfiguration, things like this.

170
00:19:52,080 --> 00:19:54,300
But this is something that we managed to show.

171
00:19:54,520 --> 00:20:02,980
And the idea was having hypothesis and trying them across a larger scope, depending on the scope that you have.

172
00:20:02,980 --> 00:20:16,720
But this was the idea, having a hypothesis, taking things maybe from the bug bounty, we were speaking about bug bounty beforehand, so just checking things that bug hunters are trying on large scopes.

173
00:20:16,720 --> 00:20:25,940
And you will see in the reference that there is a nice talk from James Kettle, Cracking the Lens, which is some research that he did in 2017.

174
00:20:25,940 --> 00:20:30,560
It's something quite similar to what we tried as well, and we got inspired.

175
00:20:30,560 --> 00:20:32,720
So this is why it's going to be in the references.

176
00:20:32,820 --> 00:20:37,580
And if you haven't seen the article, feel free to reach out and just check it out.

177
00:20:37,580 --> 00:20:39,060
It's absolutely awesome research.

178
00:20:39,060 --> 00:20:42,540
Even if it's 2017, absolutely awesome and just gold.

179
00:20:42,540 --> 00:20:46,400
So feel free to get it afterwards, and you will get it in the slides.

180
00:20:46,460 --> 00:20:48,280
So these were some things that we were trying.

181
00:20:48,280 --> 00:20:50,440
All right, maybe it's not going to be interpreted.

182
00:20:50,520 --> 00:20:51,720
Well, what do we lose?

183
00:20:51,720 --> 00:20:57,820
Just maybe writing a couple of lines of code and seeing if it's going to match and if it's going to trick somewhere.

184
00:20:58,420 --> 00:21:02,760
Fortunately for us, it tricked, and we managed to remediate it in a couple of hours.

185
00:21:03,280 --> 00:21:06,340
But also, internal information disclosure.

186
00:21:06,340 --> 00:21:10,540
So here we had the server status page, which gave us some information.

187
00:21:10,540 --> 00:21:12,640
Nothing super critical, but still.

188
00:21:12,640 --> 00:21:20,140
It could give URI, so basically endpoints, and maybe some kind of internal endpoints.

189
00:21:20,140 --> 00:21:25,380
But it was also giving some ideas about the IP address range that we were using internally.

190
00:21:25,380 --> 00:21:30,500
So those kind of things that we didn't want attackers to have on their hands.

191
00:21:30,500 --> 00:21:36,220
We wanted to try this across all our servers again, and finding them.

192
00:21:36,220 --> 00:21:39,300
So this is the kind of things that we managed to find.

193
00:21:40,820 --> 00:21:46,220
Last but not least, here is, for example, with the wildcard.

194
00:21:46,460 --> 00:21:51,760
So basically some cross-domain.xml files, which are way too permissive.

195
00:21:51,760 --> 00:22:00,400
Way too permissive, allowing anyone to just craft some payloads and being able to start discussing with our website.

196
00:22:00,400 --> 00:22:04,520
Might be afterwards stealing some cookies, stealing some information.

197
00:22:04,520 --> 00:22:08,060
And we wanted to just trigger it on all our parameters.

198
00:22:08,060 --> 00:22:10,740
This is something that we managed to find.

199
00:22:11,000 --> 00:22:13,280
One rule, doing it all.

200
00:22:14,340 --> 00:22:18,480
It worked pretty well, and we were really happy with this.

201
00:22:20,320 --> 00:22:23,760
So now, what we had was a hypothesis.

202
00:22:23,760 --> 00:22:31,240
We had a tool written by a security team, used by security people, and it was working.

203
00:22:31,240 --> 00:22:33,780
We were happy, everything was good.

204
00:22:33,900 --> 00:22:37,140
But then afterwards, we wanted to try the extra mile.

205
00:22:37,140 --> 00:22:40,380
And the extra mile was actually a couple of extra miles.

206
00:22:41,360 --> 00:22:47,700
And by saying this is, okay, we had our internal tool, and we wanted to make it available to everyone.

207
00:22:47,700 --> 00:22:50,900
And what we mean by everyone is mostly developers.

208
00:22:50,900 --> 00:22:58,160
As soon as having a tool, that they could integrate into the pipeline, and in the CI-CD pipeline.

209
00:22:58,160 --> 00:23:04,260
So this was our goal, and basically the polar star that we were trying to target.

210
00:23:04,960 --> 00:23:09,980
And it turns out that the first issue that we found was actually based on communication.

211
00:23:10,200 --> 00:23:13,240
Developers don't necessarily get security things.

212
00:23:13,240 --> 00:23:14,840
It's one of the golden rules.

213
00:23:14,840 --> 00:23:16,840
But same as the other way around.

214
00:23:16,840 --> 00:23:22,780
Which means that we're coming with our needs, we're coming with our ideas, with our beliefs.

215
00:23:23,120 --> 00:23:24,780
Developers come with theirs.

216
00:23:24,860 --> 00:23:29,020
And it turns out that we need to find a way on how to get a line.

217
00:23:29,440 --> 00:23:35,840
We found this interesting thread on Twitter, so we're not shaming anyone or doing any kind of finger pointing.

218
00:23:35,840 --> 00:23:38,560
But we think that it's an interesting thing.

219
00:23:39,300 --> 00:23:47,240
So we got someone on Twitter basically showing and giving some idea about past experience, and started using acronyms.

220
00:23:47,240 --> 00:23:53,080
IR, especially if you're working in security, this is something which stands for incident response.

221
00:23:53,080 --> 00:23:55,780
And this is perfectly understandable.

222
00:23:55,980 --> 00:24:02,280
But it turns out that in the comments, we got some people where IR didn't mean anything.

223
00:24:02,280 --> 00:24:08,760
So people started looking up and found that it was an acronym maybe for infrared cameras.

224
00:24:08,760 --> 00:24:16,900
And it's something that if this person doesn't know the acronym, there's some issue with the communication.

225
00:24:16,900 --> 00:24:21,180
And we need to find a way into achieving and finding a bridge between them.

226
00:24:21,180 --> 00:24:27,020
And the last picture is just showing on the right that everyone is right.

227
00:24:27,520 --> 00:24:31,160
Everyone is right based on what they're looking up.

228
00:24:31,160 --> 00:24:40,320
But it's just that we need to get those two people aligned to make sure that they can move forward and they can move together in the same direction.

229
00:24:40,540 --> 00:24:42,260
Security is not against developers.

230
00:24:42,260 --> 00:24:44,080
Developers are not against security.

231
00:24:44,080 --> 00:24:46,760
I think both of them can work together.

232
00:24:47,080 --> 00:24:53,380
But just trying to get the same beliefs, at least on some very specific topics.

233
00:24:55,040 --> 00:25:01,560
So yeah, interesting things about the communication channel and speaking the same language.

234
00:25:02,200 --> 00:25:06,340
And when it comes to security, it comes with a lot of details.

235
00:25:06,340 --> 00:25:10,040
SSTI, XSS, XSE, SQLI.

236
00:25:10,040 --> 00:25:12,680
But also when we're speaking about CVEs.

237
00:25:12,680 --> 00:25:16,860
So we get thousands of CVEs as we saw earlier.

238
00:25:16,860 --> 00:25:22,160
But also MS-Beltane, MS-08, MS-067.

239
00:25:22,160 --> 00:25:25,580
But we also have a name of vulnerabilities.

240
00:25:25,580 --> 00:25:28,440
Heartbleed, Eternalblue, Bluebone.

241
00:25:28,440 --> 00:25:33,080
And this is a huge referential that we do have in security.

242
00:25:33,080 --> 00:25:34,660
Absolutely crazy.

243
00:25:34,660 --> 00:25:40,640
And the thing is, security people are actually losing track of all this.

244
00:25:40,640 --> 00:25:42,500
It's so much information.

245
00:25:42,500 --> 00:25:44,800
We have so much information to process.

246
00:25:44,800 --> 00:25:48,280
So yeah, we have those named vulnerabilities.

247
00:25:48,280 --> 00:25:49,400
They have websites.

248
00:25:49,400 --> 00:25:50,180
They have videos.

249
00:25:50,180 --> 00:25:52,660
They have almost like choreography and things.

250
00:25:52,900 --> 00:25:57,880
But also like all the names of vulnerabilities and classes, vulnerability classes that we have.

251
00:25:57,880 --> 00:26:00,080
So much information to digest.

252
00:26:00,080 --> 00:26:05,280
It's already hard for security people and people working in this for day long, right?

253
00:26:05,280 --> 00:26:07,680
And who have been doing their careers in this.

254
00:26:07,680 --> 00:26:08,980
But what about developers?

255
00:26:08,980 --> 00:26:11,620
How can developers keep up with this information?

256
00:26:12,080 --> 00:26:17,420
When we just like giving them a report, some of them might just be, I'm just completely lost.

257
00:26:17,420 --> 00:26:18,380
I'm just completely lost.

258
00:26:18,380 --> 00:26:19,620
I have no idea what this means.

259
00:26:19,620 --> 00:26:26,820
I can see this presentation, but I might look like a fool if I just ask the question, what is this acronym for?

260
00:26:27,120 --> 00:26:34,600
So it's some information that we need to take care of and just making sure that we get the interesting bits to developers.

261
00:26:35,600 --> 00:26:40,620
And there's actually another question, and we're not getting to the debate, maybe afterwards in the Discord.

262
00:26:40,660 --> 00:26:44,120
But should developers keep up with all this information?

263
00:26:44,680 --> 00:26:45,540
Should they?

264
00:26:45,660 --> 00:26:46,700
And I don't know.

265
00:26:46,700 --> 00:26:49,320
But I don't have the information so far.

266
00:26:49,320 --> 00:26:50,140
I don't know.

267
00:26:50,140 --> 00:26:56,200
I have my opinion, but I'm happy to discuss and to chat about this afterwards in the Discord with you all.

268
00:26:56,760 --> 00:27:02,940
So a lot of information of process, a lot of vocabulary that we need to take care of.

269
00:27:04,760 --> 00:27:16,700
The second part was, all right, if we get a chop-chop hit and the application is flagged because of some reasons, maybe some plugins got in and so on.

270
00:27:16,700 --> 00:27:17,720
Now what?

271
00:27:17,720 --> 00:27:20,420
Now what is going to do the developer?

272
00:27:20,960 --> 00:27:22,200
I don't know.

273
00:27:22,400 --> 00:27:24,360
It just is that there's a URL.

274
00:27:24,360 --> 00:27:26,140
It's giving some information.

275
00:27:26,140 --> 00:27:27,680
But what is he going to do about this?

276
00:27:27,680 --> 00:27:28,860
What is the risk?

277
00:27:28,880 --> 00:27:32,740
And what is the kind of remediation he can put in place to mitigate this?

278
00:27:32,740 --> 00:27:35,720
But he needs to understand the risk and what can happen.

279
00:27:36,140 --> 00:27:39,880
What are the bad things that can happen with this specific thing?

280
00:27:39,880 --> 00:27:44,280
And in his environment and in his context, right?

281
00:27:44,500 --> 00:27:47,060
So security vocabulary is one thing.

282
00:27:47,060 --> 00:27:48,800
But remediation is another one.

283
00:27:48,800 --> 00:27:56,040
And bringing remediation in the tool and giving this capability is actually like bringing assistance to the developers.

284
00:27:56,040 --> 00:28:00,260
Which means that we're going one step forward to them, towards them.

285
00:28:00,260 --> 00:28:04,300
And what's going to happen is developers are going to come to us as well afterwards.

286
00:28:04,300 --> 00:28:06,840
And it's going to be a win-win discussion.

287
00:28:06,860 --> 00:28:12,020
And everyone's going to be aligned against just having secure application, running production.

288
00:28:12,020 --> 00:28:14,480
And everyone's going to be happy with this.

289
00:28:14,480 --> 00:28:18,180
So bring anything valuable as soon as you have a hit.

290
00:28:18,180 --> 00:28:21,340
And that you have something that's actually triggering in your environment.

291
00:28:21,340 --> 00:28:24,760
So it could be a link to whatever, what kind of explanation.

292
00:28:24,760 --> 00:28:26,340
It could be like a research document.

293
00:28:26,340 --> 00:28:27,920
It could be anything on Twitter.

294
00:28:27,920 --> 00:28:30,180
It could be just a thread, whatever.

295
00:28:30,180 --> 00:28:32,940
Or it could be also a pointer to internal resources.

296
00:28:33,060 --> 00:28:36,900
Do you use the OWASP ASVS, for example?

297
00:28:36,900 --> 00:28:39,760
So maybe that could be a link to the specific section.

298
00:28:39,760 --> 00:28:43,900
And just referencing it so that developers could start getting information.

299
00:28:43,900 --> 00:28:47,180
Developers are super curious as security peeps.

300
00:28:47,180 --> 00:28:52,100
So I think it's a good opportunity to have this discussion and this conversation with them.

301
00:28:52,100 --> 00:29:01,960
So yeah, just bringing assistance and helping them into achieving better security within their application by giving them as much inputs as we can.

302
00:29:02,920 --> 00:29:06,170
Another part is contextualization.

303
00:29:06,560 --> 00:29:09,900
And contextualization is also key.

304
00:29:10,160 --> 00:29:13,090
Again, I'm not going to go into debate.

305
00:29:13,090 --> 00:29:18,030
And I think that this is something like a question that you might have to ask yourself.

306
00:29:18,450 --> 00:29:36,610
Should we consider the same criticity if we get a chop-chop hit for one machine which is exposed on the Internet and one machine which is completely air-gapped in a segregated environment where only two people are reaching the application and this specific server?

307
00:29:37,230 --> 00:29:40,010
It might be some kind of trade-off that you need to find.

308
00:29:40,010 --> 00:29:41,650
Maybe it's finding some balance.

309
00:29:42,310 --> 00:29:52,110
Because if you start answering yes, this is exactly the same criticity, the same exploitability, it might just start giving red flags to developers.

310
00:29:52,110 --> 00:29:54,250
Because everything is going to be critical.

311
00:29:54,750 --> 00:29:57,490
And based on this, developers have a lot to deal with.

312
00:29:57,630 --> 00:29:59,010
Production errors.

313
00:29:59,010 --> 00:30:00,410
They have a lot of development.

314
00:30:00,410 --> 00:30:01,370
They have deadlines.

315
00:30:01,370 --> 00:30:03,950
They have a lot of work that they have to do.

316
00:30:03,950 --> 00:30:09,670
And if we start getting security tasks on top of it, they're going to start getting overwhelmed.

317
00:30:09,670 --> 00:30:14,970
And having too much information afterwards, they're not going to be able to process any of it.

318
00:30:14,970 --> 00:30:24,850
So this is why I think it's a trade-off about what we try to achieve with them and what's the image that we want them to perceive from us.

319
00:30:24,850 --> 00:30:28,310
So balance and trade-off are now part of the game.

320
00:30:30,650 --> 00:30:34,670
Last but not least is about collaboration.

321
00:30:34,750 --> 00:30:39,050
And we truly believe that collaboration will empower your organization.

322
00:30:39,050 --> 00:30:43,990
And by saying this, it's like finding the best tools to do it.

323
00:30:44,230 --> 00:30:52,770
So for example, a lot of people, when we released ChopChop in June, we had a lot of people asking us, what's the difference with Nikto?

324
00:30:52,930 --> 00:30:59,110
And we are users of Nikto, we find it absolutely an amazing tool, and it works greatly.

325
00:30:59,110 --> 00:31:03,210
But it works greatly especially for security-oriented people.

326
00:31:03,630 --> 00:31:09,970
Because it's going to give you usually a lot of output, but afterwards you're going to start to have to dig in.

327
00:31:09,970 --> 00:31:16,650
You might have between one line and the other, something which is going to be informational and another one which is going to be critical.

328
00:31:16,650 --> 00:31:24,790
But this is going to depend on your experience, on what you think about it, and you're going to have to do those choices on your own.

329
00:31:25,250 --> 00:31:27,370
Are the developers going to be able to do it?

330
00:31:27,370 --> 00:31:31,950
It might not be possible because they might not know anything about security.

331
00:31:31,950 --> 00:31:40,750
So this is why we want to help them by doing some kind of triage in all those findings, and providing them good inputs.

332
00:31:40,750 --> 00:31:47,010
So finding the best tools to do this is extremely important, and some of them might be tailor-made.

333
00:31:47,370 --> 00:31:50,270
So something definitely to bear in mind.

334
00:31:50,630 --> 00:32:11,530
Second of all is making sure that the learning curve that you're going to have, if you're looking for people to collaborate, which means writing new rules, helping, maybe doing a pull request on your project, and doing this kind of collaboration, make sure that the learning curve that people are going to have to start digging in the codebase,

335
00:32:11,530 --> 00:32:14,030
that's not going to be something too crazy.

336
00:32:14,650 --> 00:32:21,570
Usually, when we speak to developers, they find the security quite mystic.

337
00:32:21,570 --> 00:32:25,290
It's like some kind of black magic happening behind the scenes.

338
00:32:25,290 --> 00:32:43,050
They're using some weird commands and so on, and this is why if we start putting on the shelf a new application that we want people to start playing with, that they start collaborating with us, we need to make sure that this is mostly friendly to new people coming in security,

339
00:32:43,050 --> 00:32:45,850
and writing tools, and writing rules, and so on.

340
00:32:45,850 --> 00:32:47,530
So something to bear in mind.

341
00:32:47,910 --> 00:32:56,010
And again, this depends on the context where you're in, which means if your developers are using YAML, in this case, go for it.

342
00:32:56,010 --> 00:33:03,790
If your users stick with XML for some reasons, because in your context, this is what they use, stick with it and go for it.

343
00:33:03,790 --> 00:33:13,650
It's really going to depend on your context, and I think that the last point, discernment and clear thinking for your choices within your organization are key.

344
00:33:13,850 --> 00:33:23,790
This is one of the most important things that we learn, is just checking the context, and make sure that the security adapts perfectly to this context within your organization.

345
00:33:23,790 --> 00:33:40,610
Because if you're trying to get a bigger audience, and broaden the usage of your tools, you need to actually get them in, and by doing this, you need to look like them, so that they can start getting it without any issue.

346
00:33:41,150 --> 00:33:46,530
And last point, but not least, change the posture from no, you can't, to yeah, let's see how to make it.

347
00:33:46,530 --> 00:33:52,130
For example, if some people want to use the tool, because they also want to do some monitoring and things, yeah, why not?

348
00:33:52,130 --> 00:33:52,530
Why not?

349
00:33:52,530 --> 00:33:54,530
They should be able to do this, right?

350
00:33:54,530 --> 00:34:05,010
If they start asking questions about new technology, new frameworks that they want to put in, well, obviously there's going to be a balance into, is it something that's good for my company, for my organization?

351
00:34:05,010 --> 00:34:09,610
But you need to have this discussion, and not having just really close answers.

352
00:34:10,130 --> 00:34:23,170
So that's, we think, some of the keys that we got, and that we managed to see following this development, and trying to broaden the usage of our tools.

353
00:34:23,810 --> 00:34:36,690
So this is why we created GoChopChop, and what I'm going to do is give my seat to Stanislas, and he's going to present you the tool, and hopefully make an awesome testing session and demo video.

354
00:34:36,770 --> 00:34:37,530
Cheers!

355
00:34:40,630 --> 00:34:41,970
All right.

356
00:34:43,810 --> 00:34:47,050
Hello everyone, and thank you for watching this talk.

357
00:34:47,050 --> 00:34:53,910
I'm Stanislas Malveaux, I'm working currently as an intern, a security intern at Michelin.

358
00:34:54,670 --> 00:35:05,970
So I present to you how we created GoChopChop, which is the second version of ChopChop, which Paul presented to you.

359
00:35:06,670 --> 00:35:15,310
So, ChopChop, GoChopChop is a command line for dynamic application security testing, and it's written in Golang.

360
00:35:15,310 --> 00:35:25,350
Its purpose is to scan several endpoints, and expose services, files, folders, through the web root.

361
00:35:25,570 --> 00:35:36,050
And we created the tool so it can be fully configurable by developers, even by non-security people.

362
00:35:36,210 --> 00:35:43,670
And I present to you how it works, and how easy it is to modify and add a role, for example.

363
00:35:46,170 --> 00:35:47,430
Alright.

364
00:35:48,050 --> 00:35:56,490
So, here we are testing our own web application, which is exposed on port 80.

365
00:36:00,010 --> 00:36:01,690
Alright.

366
00:36:01,830 --> 00:36:10,090
So, for the purpose of the demo, we exposed a git config on the web application.

367
00:36:10,090 --> 00:36:23,350
So, we can see here, we did a curl on a web app, and it returns a status code of 200, and a core repository format version, and so on.

368
00:36:23,650 --> 00:36:29,930
So, now we're going to try the tool on our own web app.

369
00:36:32,970 --> 00:36:34,170
Here.

370
00:36:36,250 --> 00:36:37,130
Alright.

371
00:36:37,130 --> 00:37:01,330
So, we launched GoJarChat on our URL foobar.com, and it flagged the git config vulnerability, and it gives you a severity level, which is high in our case, a name for the plugin, and a remuneration we can use later to remunerate the vulnerability.

372
00:37:01,330 --> 00:37:10,590
So, now we're going to see how to configure ChopChop to make new rules, and how you can configure it.

373
00:37:11,070 --> 00:37:15,450
So... no.

374
00:37:15,610 --> 00:37:16,690
Alright.

375
00:37:18,210 --> 00:37:28,570
So, the rules are written in YAML, and it's very easy to create a new one or modify.

376
00:37:28,570 --> 00:37:37,170
So, here, for our example, we have the rule git config, so it will scan the endpoint slash git slash config.

377
00:37:37,430 --> 00:37:58,230
We give it a name, so git exposed, a status code of 200, which will scan the HTTP response to see if the HTTP response gives a 200 status code, a match, which is a list of strings the tool needs to find in the HTTP response.

378
00:37:58,230 --> 00:38:00,550
So, in our case, we saw it was core.

379
00:38:01,530 --> 00:38:06,130
There is other things like no match.

380
00:38:06,130 --> 00:38:13,670
No match is a list of strings which needs to not be in the HTTP response.

381
00:38:13,850 --> 00:38:19,490
And another one is headers, for example, content-type application-json.

382
00:38:19,830 --> 00:38:28,590
And you have to give it a remuneration, so here we say do not deploy .git folder on production servers.

383
00:38:28,590 --> 00:38:37,430
A quick description so the developers understand what is going on and why it has a severity level of high.

384
00:38:37,430 --> 00:38:45,830
So, here, it verifies that the git repository is accessible from the site and a severity level of high.

385
00:38:45,830 --> 00:38:52,190
So, you can easily modify it, for example, high to a low level.

386
00:38:52,190 --> 00:39:00,610
Or, for example, if the developers don't really know what to do, we can give FUBAR, for example.

387
00:39:05,070 --> 00:39:18,670
So, if we launch it now, it will say, OK, I don't understand FUBAR, you need to give a severity level of informational, low, medium, and high.

388
00:39:18,670 --> 00:39:23,150
So, we can modify it again to, for example, low.

389
00:39:23,710 --> 00:39:24,530
All right.

390
00:39:24,590 --> 00:39:32,650
And if you relaunch it, it will take into account the modification and the severity level goes to low.

391
00:39:32,870 --> 00:39:33,410
All right.

392
00:39:33,410 --> 00:39:37,370
So, now, we're going to do a new rule.

393
00:39:37,370 --> 00:39:48,370
For the sake of the demo, we created a quick HTML page.

394
00:39:51,530 --> 00:39:57,970
So, yeah, we see here we created an HTML which says DEFCON rocks.

395
00:39:57,970 --> 00:40:06,270
So, I want the tool to flag it and to give us an output on this.

396
00:40:07,070 --> 00:40:09,110
All right.

397
00:40:11,550 --> 00:40:12,910
OK.

398
00:40:13,410 --> 00:40:21,450
So, here, I'm going to scan the main endpoint of the web application.

399
00:40:21,790 --> 00:40:27,590
So, what we check is we give a name to the rule, so DEFCON rule here.

400
00:40:27,590 --> 00:40:32,890
We need a status code of 200 and we need to match the string DEFCON.

401
00:40:32,890 --> 00:40:37,290
So, if the DEFCON is found in the HTTP response, it will flag.

402
00:40:37,330 --> 00:40:40,470
And a remediation and description and the severity.

403
00:40:40,930 --> 00:40:42,670
So, we can test it.

404
00:40:45,530 --> 00:40:46,690
All right.

405
00:40:47,970 --> 00:40:54,650
And here, you see the tool flagged it on the main endpoint, the severity level and the remediation.

406
00:40:55,830 --> 00:40:56,530
All right.

407
00:40:56,730 --> 00:40:58,410
That's pretty much it.

408
00:40:59,390 --> 00:41:03,790
Paul will finish this presentation and thanks for listening.

409
00:41:06,690 --> 00:41:08,710
Welcome back.

410
00:41:09,430 --> 00:41:13,310
Thank you, Stanislas, for the demo.

411
00:41:14,110 --> 00:41:16,390
So, what we learned from this.

412
00:41:16,430 --> 00:41:23,570
So , from going from an offensive mindset to creating a tool used by developers.

413
00:41:23,570 --> 00:41:37,870
And what we learned was things that finding the same language, same vocabulary and speaking the same with the same concept is extremely important.

414
00:41:38,350 --> 00:41:44,830
Second of all is make sure that they get your points and that you get theirs as well.

415
00:41:44,830 --> 00:41:53,030
Which means that if you have some beliefs, if you have some things and reasons that you think that the application should be secured this way.

416
00:41:53,030 --> 00:41:58,830
Just make sure that you also understand what are their problematics in terms of development side.

417
00:41:58,830 --> 00:42:01,990
Maybe it can be something based on the organizations.

418
00:42:01,990 --> 00:42:05,050
But this is something that has to be done, definitely.

419
00:42:05,050 --> 00:42:13,390
It has to be done and having you to be conversational in two channels, basically.

420
00:42:13,890 --> 00:42:18,310
Third point is bringing assistance will lead to better collaboration.

421
00:42:18,310 --> 00:42:25,310
So, as Stanislas showed you before, by giving some remediations.

422
00:42:25,310 --> 00:42:39,610
This could be giving links, giving information to the ASVS OWASP, to a bunch of resources and trying to give more information to the people so that they could secure it in a timely manner.

423
00:42:39,610 --> 00:42:50,150
This is something that bringing this will actually help them and helping them will bring definitely more joy and they're going to be able to help you as well if you're looking for something.

424
00:42:51,310 --> 00:42:58,070
Again, don't underestimate collaboration to broaden your audience based on your context.

425
00:42:58,370 --> 00:43:06,370
If the developers that you have that you're trying to target are using XML and you're coming with something in YAML, this is not going to work.

426
00:43:06,370 --> 00:43:07,790
The opposite as well.

427
00:43:07,790 --> 00:43:15,850
Because everything which might be shiny or anything like this might not be the real solution and you're not going to bring anything to them.

428
00:43:15,850 --> 00:43:18,370
So, try to bring something super valuable.

429
00:43:18,970 --> 00:43:21,070
This is extremely important.

430
00:43:21,070 --> 00:43:27,910
And last point, but not least, that we have on our checklist is the contextualization in the trade-off.

431
00:43:28,010 --> 00:43:29,650
Having this balance.

432
00:43:29,650 --> 00:43:42,250
As I showed you before, Stanislas, during the presentation, you are able to change, for example, the severity of one specific finding if your organization has a specific context.

433
00:43:42,550 --> 00:43:50,970
For this specific trigger, this specific hit, especially with the GitExpo, I would not recommend putting it in low.

434
00:43:50,970 --> 00:43:56,130
But this is something that we can do and programmatically everyone can do this.

435
00:43:56,130 --> 00:43:58,830
Even non-developers people, non-tech people.

436
00:43:58,830 --> 00:44:06,710
You could definitely imagine a product owner or anyone just like, you have this file and you can actually start tweaking a couple of parameters.

437
00:44:06,730 --> 00:44:08,870
This is something that we can do.

438
00:44:08,870 --> 00:44:21,970
And even though you can tweak the parameters, if anyone is just going wrong, you can see that there are a couple of checks that Stanislas developed to make sure to give some insights about, okay, it failed, but why does it fail?

439
00:44:21,970 --> 00:44:29,150
And okay, so it's got an enumeration and you can only choose from those specific values.

440
00:44:29,250 --> 00:44:36,810
But anyway, so those are, I would say, the lesson learned from having an offensive tool and putting it into developers' hands.

441
00:44:37,790 --> 00:44:43,210
We do have a couple of references and obviously we're just on the shoulder of giants.

442
00:44:43,210 --> 00:44:51,070
And I think that those specific links are quite valuable, especially with what we try to build.

443
00:44:51,070 --> 00:44:57,830
And I think that those talks and those blog posts are actually similar to the mindset that we have.

444
00:44:57,830 --> 00:45:02,390
So first of all, and we talked about it with cracking the lens from James Cato.

445
00:45:02,390 --> 00:45:14,710
And I think it's interesting in terms of the scope he has, taking everything from the bug bounty platform and having hypotheses and running it and seeing if it triggers anything or not.

446
00:45:14,710 --> 00:45:17,370
The second one is the keynote from the STIC.

447
00:45:17,370 --> 00:45:19,630
STIC is a French conference in France.

448
00:45:19,630 --> 00:45:26,110
And we had the privilege to have Alex Ionescu in 2019 speaking about security with developers.

449
00:45:26,110 --> 00:45:43,570
He started dealing with Rust and a bunch of things like this where he was actually launching the debate about should developers keep up with the compilation flags to avoid having any kind of memory corruption errors, etc.

450
00:45:43,750 --> 00:45:45,810
And it's an interesting discussion.

451
00:45:45,810 --> 00:45:49,830
I think that might have some English subtitles because the talk is in French.

452
00:45:49,830 --> 00:45:54,990
But definitely something that I would consider to watch afterwards.

453
00:45:54,990 --> 00:45:58,310
The last two are actually from Harold Meir.

454
00:45:58,850 --> 00:46:01,050
And two great conferences talks.

455
00:46:01,050 --> 00:46:03,850
The first one, learning the wrong lessons from offense.

456
00:46:03,850 --> 00:46:08,490
And the second one from B-Sides Doha, which is make more stuff.

457
00:46:08,650 --> 00:46:11,610
And this was oriented to security people.

458
00:46:12,050 --> 00:46:16,650
So those four references are absolutely awesome.

459
00:46:16,650 --> 00:46:18,950
And we recommend you to watch them.

460
00:46:18,950 --> 00:46:21,770
It's worth the watch, definitely.

461
00:46:23,370 --> 00:46:24,830
So thanks a lot.

462
00:46:24,830 --> 00:46:26,150
Thanks a lot for your time.

463
00:46:26,150 --> 00:46:27,490
Thanks a lot for watching.

464
00:46:27,570 --> 00:46:33,390
Feel free to check our GitHub if you want to follow the project and start collaborating with us.

465
00:46:33,390 --> 00:46:41,510
And if we do have one advice, embrace hackiness, have fun and collaborate with your organization to make it more secure.

466
00:46:41,930 --> 00:46:42,710
Cheers.

467
00:46:42,970 --> 00:46:43,890
Bye.