1
00:00:00,000 --> 00:00:01,220
Welcome back.

2
00:00:01,320 --> 00:00:02,200
And thank you, Tim.

3
00:00:02,200 --> 00:00:03,740
Thank you for supporting DEF CON.

4
00:00:03,740 --> 00:00:05,700
Thank you for supporting the Red Team Village.

5
00:00:05,860 --> 00:00:06,780
The floor is yours.

6
00:00:06,780 --> 00:00:07,740
Take it away.

7
00:00:08,380 --> 00:00:09,360
Hi, folks.

8
00:00:09,360 --> 00:00:12,760
Good morning, good afternoon, good evening, wherever you are in the world.

9
00:00:12,800 --> 00:00:19,320
Welcome to my session, All of the Threats, Intelligence, Modeling, Simulation, and Hunting through an Attacker's Lens.

10
00:00:20,860 --> 00:00:26,460
So just to put a little bit of background behind this at a very high level, ATT&CK rocks.

11
00:00:26,640 --> 00:00:29,980
But what happens when ATT&CK doesn't give you the information you need?

12
00:00:32,140 --> 00:00:33,820
So introduction.

13
00:00:35,100 --> 00:00:39,760
TLDR, who I am, what the plan for this presentation actually looks like.

14
00:00:40,240 --> 00:00:42,800
So I'm not a data scientist.

15
00:00:42,980 --> 00:00:45,420
I'm not aligned to either blue or red.

16
00:00:45,420 --> 00:00:49,640
I do various activities on both sides of the fence.

17
00:00:49,820 --> 00:00:53,260
And I fully acknowledge that this isn't a solved problem.

18
00:00:53,260 --> 00:00:57,120
This is my stab in the dark trying to get somewhere with it.

19
00:00:57,700 --> 00:00:58,780
So who I am.

20
00:00:58,780 --> 00:01:00,140
So I work at Cisco.

21
00:01:00,180 --> 00:01:01,780
I've done various roles.

22
00:01:01,780 --> 00:01:03,680
I've done assessment work.

23
00:01:03,720 --> 00:01:05,600
I've done threat intelligence.

24
00:01:05,900 --> 00:01:10,220
I occasionally help out with incident response when we get weird situations.

25
00:01:10,580 --> 00:01:16,340
And indeed, I've also done my fair share of spreadsheet filling as an auditor.

26
00:01:16,540 --> 00:01:18,420
I am a technical person.

27
00:01:18,940 --> 00:01:20,420
I like bugs.

28
00:01:20,420 --> 00:01:22,020
I like Unix in particular.

29
00:01:22,140 --> 00:01:23,680
And I like exploiting stuff.

30
00:01:23,740 --> 00:01:28,880
Probably the most recent stuff you can go and find is Mimikatz and Unix.

31
00:01:28,880 --> 00:01:32,020
What happens in an active directory on a Unix estate.

32
00:01:32,320 --> 00:01:35,280
So the plan for this presentation, I'm going to give you a little bit of background.

33
00:01:35,280 --> 00:01:40,920
I'm not presuming that everybody knows the difference between threat intelligence, threat hunting, threat simulation, etc.

34
00:01:41,380 --> 00:01:45,020
I'm going to talk a little bit about building bespoke threat models.

35
00:01:46,120 --> 00:01:49,700
I'm going to talk about how we can use data we already have.

36
00:01:50,560 --> 00:01:53,900
I'm going to talk about how that translates into the real world.

37
00:01:53,900 --> 00:01:59,360
I'm going to look at some of the stuff that we do from an offensive standpoint and how that maps into things like attack.

38
00:02:00,160 --> 00:02:04,340
I'm going to talk about how we can be using this kind of information to improve our threat models.

39
00:02:04,340 --> 00:02:10,400
And hopefully I'm going to finish up some recommendations and conclusions and it'll all make sense and you'll go in and everything will be great.

40
00:02:10,820 --> 00:02:11,980
So background.

41
00:02:13,200 --> 00:02:16,960
The concept was we need to bring all of these different disciplines together.

42
00:02:16,960 --> 00:02:22,020
We have people that do threat intelligence, we have people that do threat modeling, we have people that do simulation, we have people that do hunting.

43
00:02:22,840 --> 00:02:25,700
And attack gives us a common language for all of those things.

44
00:02:25,780 --> 00:02:30,720
But does it go far enough and does it help us with, I guess, the business system?

45
00:02:30,720 --> 00:02:32,940
So that's kind of where we are.

46
00:02:33,240 --> 00:02:35,900
So as I said, bring the five disciplines together.

47
00:02:36,680 --> 00:02:42,440
Most of the people guessing on this will be involved in at least one of these.

48
00:02:42,580 --> 00:02:46,220
Maybe you're doing recovery work when breaches happen.

49
00:02:46,220 --> 00:02:48,760
Maybe you're doing detective work, you're sitting in a sock.

50
00:02:48,960 --> 00:02:52,820
Maybe you're the person that's meant to be responsible for keeping everything safe.

51
00:02:53,420 --> 00:02:55,900
You know, we're all in this together, right?

52
00:02:56,640 --> 00:02:58,640
So an ideal approach.

53
00:02:58,860 --> 00:03:04,400
Ideally, we'd all have a good understanding of targeting hypotheses and how we validate.

54
00:03:04,680 --> 00:03:07,620
You know, we'd understand actors, TTPs, assets.

55
00:03:07,620 --> 00:03:20,380
We'd be able to draw out hypotheses about how actors get into networks, what they do once they're in networks, and what they're looking for in terms of actions on targets, what they're looking to get away with.

56
00:03:20,520 --> 00:03:32,580
And hopefully, we'd have a common way to talk about that from a validation standpoint, either in terms of posture or telemetry, or indeed any of the other mechanisms that may or may not exist.

57
00:03:33,320 --> 00:03:35,140
So threat intelligence.

58
00:03:35,140 --> 00:03:51,680
That's all about identification, understanding emerging TTPs, understanding what malicious behavior looks like, collecting and enriching that, and providing situational awareness to your organization, to those people that you work with.

59
00:03:52,160 --> 00:03:53,440
Threat modeling.

60
00:03:53,560 --> 00:03:56,940
The mission there, I guess, is to describe the assets.

61
00:03:56,940 --> 00:04:16,380
So take that information that threat intelligence gives you, augment it, build kill chains, map attack surfaces, talk about vulnerabilities and weaknesses and how they inform that threat model, understand the motivation, understand the impacts of attacks.

62
00:04:17,180 --> 00:04:18,620
Simulators.

63
00:04:18,800 --> 00:04:21,000
Yeah, there's various different classes within that.

64
00:04:21,000 --> 00:04:24,700
You've got simulation, you've got emulation, you've got traditional penetration testing.

65
00:04:24,700 --> 00:04:42,080
But essentially, that's looking to take that information about what the threat model looks like, that information about what threat actors are out there, and recreate it so that your blue team, your defenders can understand, can test their telemetry, can test that they can pick it up,

66
00:04:42,080 --> 00:04:50,540
and hopefully so they can improve either the identification or the automation, the response to those threats.

67
00:04:51,540 --> 00:04:52,580
Hunting.

68
00:04:52,640 --> 00:04:55,640
That's, I guess, the final part of the jigsaw from my perspective.

69
00:04:55,660 --> 00:05:04,860
That's about understanding how threat intelligence, how threat models, what they look like on the ground.

70
00:05:04,880 --> 00:05:08,220
When an attacker has got in, what are they doing?

71
00:05:08,220 --> 00:05:09,420
What does it look like?

72
00:05:09,420 --> 00:05:12,400
And how can you go and find them and hopefully kick them out?

73
00:05:12,400 --> 00:05:24,380
So it's about understanding posture, it's about understanding telemetry, it's about reading that information, identifying where attackers are actually active, taking steps to remediate that problem.

74
00:05:25,260 --> 00:05:29,820
So that's kind of a high-level view of the people I'm talking to.

75
00:05:29,820 --> 00:05:30,920
What of it?

76
00:05:30,920 --> 00:05:32,600
What should we be doing?

77
00:05:33,180 --> 00:05:36,020
I talked about the fact attack is great.

78
00:05:36,300 --> 00:05:48,580
It's really good if you're talking about heterogeneous Windows networks, active directory, phishing through to crypto mining, phishing through to crypto lock-in.

79
00:05:48,680 --> 00:05:52,580
The traditional stuff that everybody worries about on their Windows desktops.

80
00:05:52,580 --> 00:05:57,040
But where it doesn't, in my opinion, particularly help is when you step beyond that.

81
00:05:57,340 --> 00:06:03,000
Most businesses, well, they actually have data, they have applications that essentially drive their business.

82
00:06:03,220 --> 00:06:10,240
And that's the purpose of this talk, is to look at how we take attack and leverage in those kinds of situations.

83
00:06:11,520 --> 00:06:13,960
So building bespoke threat models.

84
00:06:14,900 --> 00:06:20,240
I'm going to go through what I think requirements look like, what I think the workflow looks like.

85
00:06:20,240 --> 00:06:23,460
Some ideas about how to use a workflow effectively.

86
00:06:24,760 --> 00:06:27,380
How you can apply hypotheses.

87
00:06:28,100 --> 00:06:33,440
Some of the use cases that maybe we don't really tackle today, but perhaps we ought to.

88
00:06:33,740 --> 00:06:37,280
Some of the capability gaps that certainly exist.

89
00:06:37,600 --> 00:06:45,420
And why in my head, and this is just my head, I think threat intelligence collection is really just a backstop.

90
00:06:45,420 --> 00:06:58,140
There are far more useful sets of information about our platforms, about our assets, about our data, about our users, that should give us a far better understanding of where threats are likely to raise their heads.

91
00:06:58,960 --> 00:07:04,480
So in terms of requirements, broadly speaking, we need to define a mission.

92
00:07:04,760 --> 00:07:09,120
And I will say the value of any system, well, that's the data.

93
00:07:09,840 --> 00:07:16,080
Secondly, we need to have an understanding of what threat looks like from one perspective or another.

94
00:07:16,920 --> 00:07:22,360
In terms of building hypotheses, well, we need to understand what the organization actually cares about.

95
00:07:22,640 --> 00:07:25,220
And we probably need access to the design.

96
00:07:25,220 --> 00:07:34,800
It's very difficult to build threat models purely based on attack once you step into business systems, because you're really not matching like for like.

97
00:07:35,000 --> 00:07:46,060
A Windows desktop, the users, the use cases, are significantly different from, you know, an enterprise resource planning system, a data warehouse.

98
00:07:46,660 --> 00:07:54,440
So we need to understand what the designs look like, you know, three-tier architectures, are they using containers, are they using microservices, that kind of thing.

99
00:07:54,580 --> 00:08:00,420
And then from a validation standpoint, one way or another, we need some visibility of those targets.

100
00:08:00,560 --> 00:08:05,540
From an intelligence standpoint, I guess, third-party sourced evidence is kind of useful.

101
00:08:05,580 --> 00:08:11,380
If you're talking about simulation, well, you need to be in a position to go and actually test the systems that you're talking about.

102
00:08:11,540 --> 00:08:16,040
From a hunting standpoint, you need configuration, you need access to the logs.

103
00:08:16,560 --> 00:08:23,700
Ideally, you'd need dynamic telemetry, that is to say, telemetry that's feeding back in real time.

104
00:08:23,700 --> 00:08:35,340
But at the very least, the ability to see the events, the log events that are occurring in SAP, in a database environment, is pretty key to getting this right.

105
00:08:36,080 --> 00:08:43,780
So in terms of workflow, from my perspective, I've sat in all those different nodes at one stage or another.

106
00:08:43,780 --> 00:08:46,260
I sat there and looked at TTPs.

107
00:08:46,320 --> 00:08:53,120
I've gone and tried to simulate vulnerabilities and weaknesses to exercise attack surfaces.

108
00:08:53,980 --> 00:08:57,860
I've considered the impact from a governance standpoint.

109
00:08:58,180 --> 00:09:02,520
And in all and amongst that, you've got to understand the motivation.

110
00:09:02,520 --> 00:09:10,580
But hopefully, no matter what part of the security lifecycle you live in, you'll map into one of those areas fairly cleanly.

111
00:09:11,680 --> 00:09:16,180
And then, of course, the challenge is to hand off to the next node.

112
00:09:16,280 --> 00:09:21,700
And indeed, in practice, there's nothing to stop you handing across in other ways.

113
00:09:22,480 --> 00:09:26,020
Understanding impact, well, that feeds vulnerabilities and weaknesses.

114
00:09:26,560 --> 00:09:30,460
Understanding motivation, well, that might actually tell you something about TTPs.

115
00:09:32,080 --> 00:09:35,000
So iterating effectively through it.

116
00:09:36,440 --> 00:09:37,960
Understanding a platform.

117
00:09:37,960 --> 00:09:39,900
I talked about the fact attack is great.

118
00:09:39,900 --> 00:09:47,840
But if you understand the platform, maybe you can take attack on its own and filter out those TTPs that you're most interested in.

119
00:09:48,320 --> 00:10:04,460
Some of the work I've been doing recently has been around, for example, taking attack and extracting verticals, extracting regional differences, extracting particular vulnerability classes.

120
00:10:05,100 --> 00:10:13,580
In terms of threat modeling in a practical sense, you've got to be able to go and speak to the people, you've got to understand the roles, you've got to understand the processes.

121
00:10:13,960 --> 00:10:19,060
Tooling wise, there is nothing better than pen and paper or a whiteboard.

122
00:10:19,520 --> 00:10:27,280
But if you want to record your information, Microsoft Threat Modeling Tool, others of its, ILK, Visio and Excel, well, they can all help.

123
00:10:27,600 --> 00:10:31,740
And then fundamentally, producing a worksheet.

124
00:10:31,820 --> 00:10:45,240
And it doesn't really matter if that worksheet is built from the perspective of an adversary, a red team, whether it's built from the perspective of a threat intelligence person, whether it's built from the perspective of a threat hunter.

125
00:10:45,240 --> 00:10:52,900
Once you have that worksheet, actually, you can pivot those questions to answer whichever question you're actually asked.

126
00:10:55,470 --> 00:10:59,850
So applying hypothesis to real world platforms and applications.

127
00:11:01,030 --> 00:11:06,030
First of all, at a very high level, familiarizing yourself with ATT&CK.

128
00:11:06,130 --> 00:11:10,650
It is still useful, and you'll see this a little bit later in some of the data I draw out.

129
00:11:11,650 --> 00:11:17,050
Mapping out those ATT&CK surfaces, you might recognize the four I've iterated through.

130
00:11:17,050 --> 00:11:19,210
They're actually straight out of CVSS.

131
00:11:20,090 --> 00:11:21,750
It's a starting point.

132
00:11:22,050 --> 00:11:23,870
Vulnerabilities and weaknesses.

133
00:11:24,730 --> 00:11:33,970
ATT&CK TTPs are great, but actually CAPH, CWE, perhaps give you value that you're not necessarily recognizing today.

134
00:11:34,390 --> 00:11:40,830
If you're fortunate enough to have good threat intelligence, understanding motivation, understanding threat groups.

135
00:11:40,830 --> 00:11:45,550
If you're fortunate enough to have access to business data, understanding system value.

136
00:11:45,850 --> 00:11:47,790
And then, of course, impact.

137
00:11:47,790 --> 00:11:52,270
It's a pretty lazy way to do it, but stride still helps in that regard.

138
00:11:52,310 --> 00:11:59,110
Fundamentally, attackers are still spoofing, tampering, causing information to be disclosed, etc.

139
00:12:01,460 --> 00:12:03,180
So use cases.

140
00:12:04,500 --> 00:12:11,120
In an enterprise, fundamentally, ATT&CK gets used for manual design verification.

141
00:12:11,500 --> 00:12:13,980
It gets used for sourcing IOCs.

142
00:12:13,980 --> 00:12:16,780
It gets used for telemetry configuration.

143
00:12:17,660 --> 00:12:20,440
And it gets used for response prioritization.

144
00:12:20,560 --> 00:12:25,260
There will be other use cases and there will be sub-use cases to each of these.

145
00:12:25,260 --> 00:12:31,600
But fundamentally, the threat model concept is about understanding a design.

146
00:12:31,680 --> 00:12:34,260
It's about understanding what's likely to be attacking it.

147
00:12:34,260 --> 00:12:38,020
It's about making sure you've got the right security controls.

148
00:12:38,240 --> 00:12:42,880
And these days with consider breach, telemetry is a key aspect.

149
00:12:43,340 --> 00:12:49,900
And it's about being able to respond when breaches occur, because again, consider breach.

150
00:12:52,750 --> 00:12:55,990
So capability gaps.

151
00:12:56,390 --> 00:13:03,230
I've been into a fair few SOCs, either working in them or talking to them, evaluating their current capabilities.

152
00:13:03,790 --> 00:13:06,890
And that's what one's a pretty key one in my mind.

153
00:13:07,730 --> 00:13:10,210
SOCs are great at dealing with enterprise.

154
00:13:10,550 --> 00:13:13,770
Most people these days are familiar with ATT&CK.

155
00:13:13,770 --> 00:13:16,630
They do understand enterprise risks.

156
00:13:16,990 --> 00:13:31,970
But actually, once you start to grow them beyond that, and start to ask them about their SAP infrastructure, their banking enterprise applications, their data warehouses, we're kind of blind to a degree.

157
00:13:31,970 --> 00:13:35,450
And I think that's probably one of those things that we need to tackle.

158
00:13:35,450 --> 00:13:42,190
And I hope that some of what I'm talking today about is about informing how we can tackle some of this.

159
00:13:42,190 --> 00:13:48,030
We're clearly not going to teach every SOC analyst every application that a business cares about.

160
00:13:48,230 --> 00:14:00,190
So making better use of the knowledge they have, giving them the tools to translate generic enterprise risks into key business risks, that's pretty critical.

161
00:14:00,950 --> 00:14:06,730
Collection and routing, logs, audit events, telemetry.

162
00:14:06,990 --> 00:14:12,510
I guess depending on where you work, who you work for, you might say, we're pretty good at this.

163
00:14:12,510 --> 00:14:15,190
You might say, I'm not quite so sure.

164
00:14:15,190 --> 00:14:18,110
You might even just put your hand up and say, no, we're terrible.

165
00:14:18,770 --> 00:14:30,390
I think every incident response engagement I've turned up to over the last five years hasn't had as much information as we would require to evaluate the system.

166
00:14:30,710 --> 00:14:34,170
And if you talk about enterprise, that's a really good example.

167
00:14:34,530 --> 00:14:40,970
We did a response engagement recently, where it turned out that actually it was a message queue that was being tampered with.

168
00:14:41,070 --> 00:14:41,950
And guess what?

169
00:14:41,950 --> 00:14:44,830
Their message queue had no useful logs at all.

170
00:14:44,850 --> 00:14:50,990
Nothing that told you that much about who was accessing the message queue, where they were accessing it from.

171
00:14:51,270 --> 00:15:03,690
And indeed, when we eventually managed to find the application logs, the development data essentially about how the message queue was functioning, and we found that it was logging the messages, we were so excited.

172
00:15:03,730 --> 00:15:10,550
But even with that information, trying to take that back to a SOC and say, actually, which of these are the legitimate events?

173
00:15:10,550 --> 00:15:11,610
Which of these are?

174
00:15:11,610 --> 00:15:15,870
It was a challenge, because the security organization just didn't understand that.

175
00:15:17,710 --> 00:15:19,830
Orchestration and enrichment.

176
00:15:21,810 --> 00:15:29,810
Key to those two previous points is getting SOCs to a point where they know what data is useful, and they know how to use it.

177
00:15:31,230 --> 00:15:36,190
It's easier to do with Windows, it's easier to do with endpoint devices.

178
00:15:36,410 --> 00:15:43,390
But actually, if you want to kick someone out of to go back to that point, a message bus, where do you start?

179
00:15:43,390 --> 00:15:44,750
What data is useful?

180
00:15:44,750 --> 00:15:49,810
We had to tell them every step of the way, because they simply didn't know.

181
00:15:50,590 --> 00:15:55,250
And then, of course, you look at things like the... what is bad?

182
00:15:56,250 --> 00:16:02,890
What does bad look like in an enterprise resource planning application in a Unix estate for microservices?

183
00:16:03,230 --> 00:16:06,650
So those capability gaps, we need to start to fill them.

184
00:16:09,010 --> 00:16:15,730
But all of that data exists, which is kind of why I argue that threat intelligence really should be a backstop.

185
00:16:16,110 --> 00:16:30,670
If we're not consuming the data that the organization is already generating in one form or another and using it effectively, we're going to be forced to use threat intelligence as our only means to identify threat actors, identify attacks.

186
00:16:31,730 --> 00:16:37,710
But in terms of threat intelligence, even there, we could be using it more effectively, right?

187
00:16:37,890 --> 00:16:46,390
We know the vulnerabilities exist, for example, yet we don't necessarily use that in an effective way from a threat intelligence standpoint.

188
00:16:47,190 --> 00:16:51,930
We don't use it in a predictive fashion as much as we might like.

189
00:16:52,650 --> 00:17:04,790
We certainly don't construct the same degree of hypotheses around application vulnerabilities as we do around password cracking, phishing, etc.

190
00:17:05,530 --> 00:17:12,770
We need to get better at putting together hypotheses, straw men, that we can start to buy off in pieces.

191
00:17:13,050 --> 00:17:25,310
And ultimately, from a threat intelligence standpoint, we need to get better at tracking that kind of threat intelligence in just the same way that we track TTPs for enterprise threats.

192
00:17:26,290 --> 00:17:30,370
A SAP system will still have that kind of information.

193
00:17:31,090 --> 00:17:35,310
We should still be able to work out the validity of the information.

194
00:17:35,690 --> 00:17:39,730
We should still be able to understand where it might affect us as an organization.

195
00:17:39,730 --> 00:17:42,870
We should still be able to understand why an attacker might wish to do it.

196
00:17:43,030 --> 00:17:49,630
And we need to start to ask threat intelligence teams to give us that information so that we can make the right decisions.

197
00:17:51,390 --> 00:17:53,230
So that's some of the problems.

198
00:17:53,350 --> 00:17:56,030
Let's have perhaps a little bit of a solutions.

199
00:17:56,710 --> 00:18:11,670
And here, what I was really looking to do was to map some of the more traditional concepts of threat modeling, Stride, Microsoft's tooling, and equivalent into attack language, into kill chains, into the attack matrix.

200
00:18:13,270 --> 00:18:20,950
So working in Cisco, I have a pretty good source of information about all of the assessment work that we do.

201
00:18:21,510 --> 00:18:23,410
The vulnerabilities, the weaknesses.

202
00:18:24,010 --> 00:18:26,450
I have the ability to extend that tooling.

203
00:18:26,570 --> 00:18:35,770
So I kind of wanted to say, well, actually, if we've got vulnerability data from an assessment, how do we translate that into a threat model that a SOC can use?

204
00:18:35,770 --> 00:18:37,710
So I want to label our findings.

205
00:18:37,710 --> 00:18:40,470
I want to start to analyze our data a bit more depth.

206
00:18:41,690 --> 00:18:44,350
So that's our vulnerability model, fundamentally.

207
00:18:44,830 --> 00:19:00,570
We take all of the things you would find in a pen test, the idea of scoring criticality, defining the weakness in generic terms, describing the vulnerability, describing the impact, talking about recommendations, industry references, etc.

208
00:19:00,690 --> 00:19:06,070
But on top of that, we have our not inconsequential VDB.

209
00:19:06,310 --> 00:19:10,210
It's internal, but it imports from Nessus, from MITRE, and from other sources.

210
00:19:10,250 --> 00:19:12,830
And our reporting engine is really driven off that.

211
00:19:12,830 --> 00:19:18,610
So when we report a finding, if it's a finding we've seen before, it will come from our VDB.

212
00:19:18,750 --> 00:19:21,790
If it's a new finding, it will end up in our VDB.

213
00:19:21,890 --> 00:19:24,450
So we have quite a rich historical view.

214
00:19:25,530 --> 00:19:27,810
I won't say it goes back 20 years.

215
00:19:27,810 --> 00:19:31,190
We have to clear down a lot of customer data , as you can imagine.

216
00:19:31,350 --> 00:19:39,410
But certainly in terms of the VDB portion, we have an understanding about how vulnerability trends have changed over time.

217
00:19:39,510 --> 00:19:43,830
And we should be able to leverage that to build more interesting analysis.

218
00:19:44,810 --> 00:19:46,950
So what have we been doing?

219
00:19:47,210 --> 00:19:50,930
So we've been automating some of our scenario generation.

220
00:19:50,930 --> 00:20:01,570
We've been taking ATT&CK using PyTAC, which is a Python framework, to start to filter the STIX output from the ATT&CK matrix.

221
00:20:02,050 --> 00:20:17,810
We've been starting to look at how we label vulnerabilities in our VDB, vulnerabilities in our customer reports, with ATT&CK TTP, so that we can say, we found this vulnerability on a traditional pen test, but actually it maps here into your kill chain.

222
00:20:18,090 --> 00:20:21,050
And these are the kinds of controls you're likely to need.

223
00:20:21,050 --> 00:20:29,210
Not just the tactical fixes of yet you should go and patch, or yet you should go and harden this particular service.

224
00:20:29,210 --> 00:20:32,370
But actually, have you got monitoring here?

225
00:20:32,490 --> 00:20:38,450
Is this system being protected by behavioral analysis engines, etc?

226
00:20:38,770 --> 00:20:45,350
And then of course, we can take that information, we can export it out, and we're using STIX for that.

227
00:20:45,450 --> 00:20:47,810
And then we can do cross data sharing.

228
00:20:48,270 --> 00:20:58,650
So for example, I can take out vulnerability data from our reporting engine, and I can share it with TALOS, or with PISA, or with any of the other security teams that would sit within Cisco.

229
00:20:58,650 --> 00:21:11,230
The idea being that we can get a better understanding of what our customers' environments look like, and we can drive some of the features that we think are critical into, obviously, Cisco's products.

230
00:21:11,550 --> 00:21:18,990
And ultimately, we're taking some of that knowledge and using it to make more effective business risk analysis.

231
00:21:19,090 --> 00:21:28,090
And we're starting to go to customers and actually use these techniques on their data, not in our VDB, but on their risk management systems.

232
00:21:30,010 --> 00:21:33,430
So I talked about labeling findings.

233
00:21:33,470 --> 00:21:38,810
This is probably a pretty trivial example, certainly with the data that we have.

234
00:21:38,810 --> 00:21:49,110
But broadly speaking, we're scoring our findings, we're comparing those scores against ATT&CK TTP definitions, and we're labeling findings.

235
00:21:49,410 --> 00:21:56,290
And then we're identifying similar findings elsewhere, so that we can validate that the scorings we're applying are appropriate.

236
00:21:56,310 --> 00:22:17,210
And then applying labels where relevant, so that we start to build up a contextual map of how individual vulnerabilities, individual weaknesses found in an incident response engagement, incident instances of technical vulnerabilities in a red team, how they all map together.

237
00:22:19,570 --> 00:22:24,990
To do this, it's not necessarily trivial, certainly if you don't have the data to begin with.

238
00:22:24,990 --> 00:22:32,930
But in our instance, we've been developing plugins that give us customer views, platform views, ATT&CK surface views of our data.

239
00:22:33,630 --> 00:22:37,670
Like I said, we've been extending our findings to capture this information.

240
00:22:37,930 --> 00:22:45,950
But then we've been able to develop plugins that do that automation for us using the mechanism shown on the previous page.

241
00:22:46,490 --> 00:22:49,850
And then we can start to render that information in kind of useful fashion.

242
00:22:49,850 --> 00:23:01,990
So I think a couple of slides time, I'll show you an example where I've taken a bunch of vulnerabilities from our VDB and using a tool called Gephi, I've actually mapped them into a full keychain.

243
00:23:01,990 --> 00:23:05,610
And you can start to see where the critical nodes are.

244
00:23:05,610 --> 00:23:12,350
And this is generic vulnerability data, not red team ATT&CK TTPs we're talking about here.

245
00:23:14,910 --> 00:23:17,270
Let's stop and pause for a second.

246
00:23:17,750 --> 00:23:20,570
CVSS is not a shoe size contest.

247
00:23:21,270 --> 00:23:25,570
How many organizations out there look at CVSS as a number?

248
00:23:26,190 --> 00:23:29,390
They look at a 10 and they go, we need to patch that immediately.

249
00:23:29,490 --> 00:23:33,690
They look at it as a six and they go, we can patch that in a little bit of time.

250
00:23:33,730 --> 00:23:36,910
They look at it as a three and they go, actually, we don't need to patch it at all.

251
00:23:37,810 --> 00:23:39,230
So frustrating.

252
00:23:41,390 --> 00:23:47,990
So what we've been doing there, we've been attempting to map CVSS into the cyber keychain.

253
00:23:48,750 --> 00:23:56,370
One of the reasons that CVSS is kind of quite interesting is because nobody feels fearful about sharing that data in isolation.

254
00:23:56,690 --> 00:24:00,570
If I go to a customer, I say, I don't want anything else about your estate.

255
00:24:00,570 --> 00:24:02,730
I'd like to know your CVSS scores.

256
00:24:03,610 --> 00:24:06,110
Most organizations feel comfortable with that.

257
00:24:06,390 --> 00:24:13,090
And what that means is that they can then give me some information, which actually, when you start to break it down, becomes slightly more useful.

258
00:24:15,770 --> 00:24:20,630
So this is a rough mapping of our model.

259
00:24:21,110 --> 00:24:25,430
And what I've essentially got on there on the left-hand side is all of the key kill chain phases.

260
00:24:26,010 --> 00:24:36,630
And then as you progress through, I've got the aspects of CVSS that are likely to impact or likely to be interesting in each of those stages.

261
00:24:37,090 --> 00:24:40,190
And then I've rated them in terms of how useful they are.

262
00:24:40,390 --> 00:24:54,090
So I'm able to say that, you know, from a confidentiality standpoint, if the confidentiality impact is high, that's probably going to be useful from a reconnaissance standpoint.

263
00:24:54,190 --> 00:24:57,930
It's also probably going to be useful from an actions and objective standpoint.

264
00:24:58,270 --> 00:25:02,310
And similarly, with some of those other nodes in that graph.

265
00:25:03,110 --> 00:25:05,290
And where you get to is this.

266
00:25:05,590 --> 00:25:22,710
If you take all of our BDB data, and indeed, if you take Cisco's publicly disclosed vulnerabilities, and you break down and you score in the way that I've described, you can see where individual vulnerabilities that we report to customers, individual vulnerabilities that get reported to us,

267
00:25:22,710 --> 00:25:30,970
well, how they potentially, and it's my model, so only potentially, how these potentially map into the kill chain phases.

268
00:25:31,290 --> 00:25:45,230
And given that the kill chain phase is inspired attack, we're then in a position where maybe we can start to look at actually which parts of the kill chain are we exercising effectively, which parts we're exercising badly.

269
00:25:45,330 --> 00:25:52,050
Yeah, we never report almost anything that helps us with weaponization.

270
00:25:52,070 --> 00:25:57,550
We rarely report anything that talks to installation.

271
00:26:00,190 --> 00:26:05,550
And command and control, well, actually, if you think about it from a pentest standpoint, that kind of makes sense.

272
00:26:05,550 --> 00:26:08,890
We're unlikely to really look at command and control.

273
00:26:08,890 --> 00:26:10,370
We're unlikely to look at installation.

274
00:26:10,370 --> 00:26:12,310
We're unlikely to look at weaponization.

275
00:26:12,690 --> 00:26:16,890
So it's almost reflective of what you expect to see.

276
00:26:16,890 --> 00:26:25,790
But what it means is actually, if we were doing a pentest tomorrow, if we were doing a threat hunt tomorrow, where perhaps should we focus our efforts?

277
00:26:26,170 --> 00:26:36,270
Installation and command and control might be kind of interesting if you're an organization that has regular pentests, simply for the fact that pentests are unlikely to produce useful findings in that space.

278
00:26:38,750 --> 00:26:47,670
And then I said we talked to some of our customers and started to use this kind of information on their risk databases, on their vulnerability databases.

279
00:26:48,330 --> 00:26:53,210
For that, we've been going into organizations, perhaps a couple of steps up the tree.

280
00:26:53,210 --> 00:26:56,190
We've been talking to CISOs, executives, etc.

281
00:26:56,370 --> 00:27:08,970
And we've been using this concept of FAIR, which is essentially a risk framework that allows you to talk about risk in quite an interesting way.

282
00:27:08,970 --> 00:27:17,430
It allows you to talk about things like resistive strength, threat capability, probability of action, primary loss, secondary loss, etc.

283
00:27:17,430 --> 00:27:21,010
And it allows you to put proper numeric scores.

284
00:27:21,010 --> 00:27:29,010
Indeed, FAIR encourages you to score in ultimately a dollar, a pound size value.

285
00:27:29,530 --> 00:27:35,330
But what it means is that we can go and talk to organizations at levels that the executive cares about.

286
00:27:35,330 --> 00:27:39,550
The executive doesn't necessarily care about CVSS version 10.

287
00:27:39,550 --> 00:27:52,230
What they care about is that they're able to trade, that their IP isn't being stolen, that if they're a bank, someone hasn't got access to the treasury and stolen all the money.

288
00:27:52,850 --> 00:28:01,970
So starting to take vulnerability data and turn it into business impact, business risk, etc.

289
00:28:01,970 --> 00:28:05,890
Yeah, that's kind of quite compelling to a lot of C-suite.

290
00:28:08,960 --> 00:28:10,980
So why do the labeling?

291
00:28:11,560 --> 00:28:16,500
This statement, it's a great statement and it's very true.

292
00:28:16,940 --> 00:28:20,340
Defenders thinking lists, attackers thinking graphs.

293
00:28:20,360 --> 00:28:23,620
If you think about it logically that makes perfect sense.

294
00:28:23,620 --> 00:28:26,480
An attacker doesn't care how they get into an organization.

295
00:28:27,200 --> 00:28:30,300
Yeah, if they can't get in one way, they'll get in another.

296
00:28:30,300 --> 00:28:31,680
That's a graph.

297
00:28:31,680 --> 00:28:38,120
If you think about how risk management businesses work, how risk management organizations work, guess what?

298
00:28:38,120 --> 00:28:42,100
For most part, they're operating on spreadsheets or the equivalent.

299
00:28:43,040 --> 00:28:51,440
So getting to a place where we can help those risk management functions think more effectively in graphs, that's kind of going to be useful.

300
00:28:52,020 --> 00:28:59,280
So when we do the labeling, it allows us to produce documents such as this.

301
00:28:59,560 --> 00:29:22,100
So this I think was from recollection was AWS, but essentially was taking all of the TTPs, all of the threat groups, all of the parts of the attack matrix and map them, filtered as I say through the view of AWS rather than the whole STIX object collection.

302
00:29:22,740 --> 00:29:27,920
But we're now starting to do the same thing with penetration tests.

303
00:29:28,000 --> 00:29:31,020
We're starting to do the same thing with red teaming.

304
00:29:31,020 --> 00:29:34,860
And hopefully we'll get to a point where we can deliver it right across the board.

305
00:29:35,340 --> 00:29:43,000
Every report in my view, this visualization is pretty key to helping people understand what matters to them.

306
00:29:45,540 --> 00:29:48,000
So that's all of the theory.

307
00:29:48,000 --> 00:29:51,700
That's all of the data science from a person that isn't a data scientist.

308
00:29:52,440 --> 00:29:56,940
What I really wanted to do is have a look at how our data maps to the real world.

309
00:29:57,140 --> 00:30:03,440
And I talked about the fact that my background is Unix and big systems and that attack doesn't really help.

310
00:30:03,780 --> 00:30:10,460
So I kind of constructed three hypotheses, which I thought were probably pretty short to evaluate.

311
00:30:11,340 --> 00:30:15,940
I was probably going to be challenged to find useful data to support me.

312
00:30:15,940 --> 00:30:17,840
But it was a starting point.

313
00:30:19,260 --> 00:30:22,120
So I chose my targets.

314
00:30:22,220 --> 00:30:23,400
As I said, Unix.

315
00:30:23,400 --> 00:30:24,600
I built hypotheses.

316
00:30:24,600 --> 00:30:26,500
I validated those hypotheses.

317
00:30:26,840 --> 00:30:32,120
And I'm hoping to start to feed some of that learning back into our reporting.

318
00:30:33,000 --> 00:30:37,660
And I'm certainly more comfortable to talk to some of the missed opportunities that I've seen along the way.

319
00:30:38,740 --> 00:30:45,480
So in terms of targeting, if you're familiar with Portcullis, obviously we're Cisco these days.

320
00:30:45,480 --> 00:30:50,040
But if you're familiar with Portcullis, you'll know we spent years doing lots of interesting stuff in Unix.

321
00:30:50,160 --> 00:30:51,840
It seemed a good place to start.

322
00:30:51,860 --> 00:30:58,080
We've written quite a lot of things that you could consider to be TTPs, if you were that way inclined.

323
00:30:58,480 --> 00:31:02,920
And as I said, we had quite a lot of access to our customer data.

324
00:31:03,360 --> 00:31:08,980
So we were able to do things like, actually, what have we reported over the last 10 years?

325
00:31:09,220 --> 00:31:19,000
And the way we have our data segmented means that our VDB keeps track of how many times a particular issue gets reported.

326
00:31:19,000 --> 00:31:30,280
Even if we clear down the customer data, we still have an understanding of trends going back not many decades, but certainly the last 5-10 years kind of thing.

327
00:31:31,420 --> 00:31:34,300
So the hypotheses I constructed.

328
00:31:35,260 --> 00:31:38,420
Attackers are using our tools to target environments.

329
00:31:39,060 --> 00:31:45,240
Attackers are using techniques from attack to target Unix environments.

330
00:31:45,660 --> 00:31:59,080
And attack is not representative of the TTPs that we, that is the traditional pen testing arm of Cisco, find success with when we go and do professional service engagements for our customers.

331
00:32:03,620 --> 00:32:07,060
So, hypothesis validation.

332
00:32:07,440 --> 00:32:11,460
I used a small selection of our TTPs, in particular, two tools.

333
00:32:12,200 --> 00:32:20,700
Pentest, Monkeys, Unix check, and my Linux implementation for attacking AD on Unix.

334
00:32:25,320 --> 00:32:30,220
And, as I said, there's a lack of information out there.

335
00:32:30,520 --> 00:32:35,120
So I was kind of hoping we'd go and have a look at a bunch of incident response reports.

336
00:32:35,800 --> 00:32:39,540
And we'd kind of say, okay, there's loads of useful information in there.

337
00:32:40,120 --> 00:32:41,060
Guess what?

338
00:32:41,060 --> 00:32:45,440
When you look at enterprise systems, that might be the case.

339
00:32:45,620 --> 00:32:50,680
When you go and look at big box servers, far less often does it occur.

340
00:32:51,240 --> 00:32:53,580
So we went back to the drawing board.

341
00:32:54,220 --> 00:33:06,300
Detonations, bits of attack that might be useful, a lot of Googling furiously, and to the point about VDBs, many of our other data sources.

342
00:33:09,650 --> 00:33:12,830
So, hypothesis one.

343
00:33:13,390 --> 00:33:16,310
Attackers are using our tools to target Unix environments.

344
00:33:16,310 --> 00:33:19,930
So, guess what?

345
00:33:20,010 --> 00:33:37,630
It's almost impossible to determine whether, if an attacker was to compromise a Unix box, and they would use off-the-shelf, publicly available tools, it's almost impossible to tell whether they'd actually be picked up.

346
00:33:37,770 --> 00:33:43,430
Unix privilege check was undetected in pretty much all of the cases.

347
00:33:43,450 --> 00:33:49,170
And even where it was detected, it wasn't classified as malicious.

348
00:33:50,570 --> 00:33:51,750
Kind of cool.

349
00:33:51,830 --> 00:33:57,070
I kind of like the fact that I could rock up, I could use this tool when I do an assessment.

350
00:33:57,330 --> 00:34:06,570
But actually, you probably want to know whether it's on your network, even if ultimately you go, it's the pen testers, and they're meant to be using it.

351
00:34:10,290 --> 00:34:12,110
Again, looking for detonations.

352
00:34:12,110 --> 00:34:15,870
I went out and had a look to see if anyone had spotted in the wild.

353
00:34:16,870 --> 00:34:17,410
And guess what?

354
00:34:17,410 --> 00:34:18,290
They haven't.

355
00:34:18,970 --> 00:34:21,630
Is that because it's not malicious?

356
00:34:22,010 --> 00:34:27,950
Is that because people have looked at it and kind of gone, we don't mind, it's only being used by pen testers.

357
00:34:29,170 --> 00:34:42,150
Actually, it's probably because if an attacker gets you onto a system, they're probably not going to pass it through a Windows box unless they absolutely have to, or at least not in a way that a Windows AV is like to pick it up.

358
00:34:42,810 --> 00:34:56,910
Which means that unless you have good telemetry on your Unix estate, both those tools, you're unlikely to see them up until the point that the breach occurs and you start going back through your historical data.

359
00:34:56,910 --> 00:35:14,730
And even then, you're probably not going to see it unless you've got an attacker that's left it in the history, or an attacker who has left it on the file system, or an attacker who is ultimately pretty incompetent.

360
00:35:14,930 --> 00:35:20,350
If I wanted to get those tools onto a Unix box right now, I could do so.

361
00:35:20,350 --> 00:35:31,090
The fact that we don't even have the telemetry to allow us to spot the sloppy amongst us is probably a challenge that we ought to address.

362
00:35:33,730 --> 00:35:35,870
So, science of life and attack.

363
00:35:35,870 --> 00:35:39,010
Well, neither of those tools are mentioned.

364
00:35:39,070 --> 00:35:44,570
Kind of understand why it's not generic enterprise attacks tools.

365
00:35:45,290 --> 00:35:46,570
But guess what?

366
00:35:46,570 --> 00:35:49,830
It's used by almost every penetration tester out there.

367
00:35:49,830 --> 00:35:52,170
It's in lots and lots of tutorials.

368
00:35:52,290 --> 00:35:57,630
And it's even being used by people that we would probably consider to be threat actors.

369
00:35:57,630 --> 00:36:06,810
Phineas Fisher literally mentions it in his paper around how to breach organizations.

370
00:36:06,810 --> 00:36:12,310
Now, you might argue that Phineas Fisher isn't an adversary you care about.

371
00:36:12,330 --> 00:36:13,810
It didn't really matter.

372
00:36:13,810 --> 00:36:21,670
The fact that we haven't even identified these tools exist when our own community knows they exist and is using them.

373
00:36:22,270 --> 00:36:25,070
You know, we talk about offensive security tools.

374
00:36:25,070 --> 00:36:30,410
These are offensive security tools that will be being used by people and we'll just never see it.

375
00:36:32,310 --> 00:36:34,590
So, the second hypothesis.

376
00:36:35,050 --> 00:36:38,610
Attackers are using techniques from attack to target Unix environments.

377
00:36:39,310 --> 00:36:42,390
Like I said, that's pretty hard in a practical sense.

378
00:36:42,770 --> 00:36:51,870
If you look at the stuff that comes up in attack from a Linux standpoint, it's mostly IOT or front end centric.

379
00:36:52,810 --> 00:36:55,070
It's a bit of a chicken and egg situation.

380
00:36:55,070 --> 00:36:59,990
If you can't monitor your estate effectively, you're probably not going to spot it.

381
00:37:00,210 --> 00:37:09,910
And from an incident response standpoint, well, organizations, perhaps they're not going to be particularly honest, certainly publicly, about just how deep breaches went.

382
00:37:10,370 --> 00:37:19,570
But anecdotally, and I'll call back to the Phineas Fisher point, they certainly are doing things that would fall into the attack categories.

383
00:37:20,270 --> 00:37:22,770
Unix backend breaches do occur.

384
00:37:23,770 --> 00:37:28,350
There is almost always some level of application level interaction.

385
00:37:28,490 --> 00:37:32,350
Remember I said the value of any asset is the data that it holds.

386
00:37:34,450 --> 00:37:38,130
Some access are truly incompetent if it's not a Linux host.

387
00:37:38,130 --> 00:37:43,310
We did an incident response engagement for a mainframe platform that had a Unix-like shell.

388
00:37:43,910 --> 00:37:56,010
And the attacker had gone to that Unix shell without really realizing what they'd done and poked around a bit, not had a huge amount of success, and then attempted to wipe their evidence.

389
00:37:58,590 --> 00:38:13,790
If I'm looking at this critically, the TTPs from attacker are actually probably still a reasonable place to start with Unix, with enterprise business systems, with servers, etc.

390
00:38:14,470 --> 00:38:18,310
But perhaps we don't have the telemetry to support it at this point in time.

391
00:38:21,420 --> 00:38:28,640
If anybody wants to know what a good breach report looks like, this is probably the best one I've found.

392
00:38:29,360 --> 00:38:32,280
It's looking at fast cache on AIX.

393
00:38:32,920 --> 00:38:39,580
And it's not perfect, but it does support the fact that a lot of this stuff is stuff that attack knows about.

394
00:38:40,380 --> 00:38:44,700
Okay, it's AIX, not Linux, but question marks against that.

395
00:38:44,700 --> 00:39:01,520
But it certainly calls out to the same techniques that the fast cache malware was using in terms of persistence, privilege escalation, evasion, persistence, impact, etc.

396
00:39:02,760 --> 00:39:08,300
There's a little bit of speculation on application and entry point, probably not enough.

397
00:39:08,620 --> 00:39:15,000
But this is the kind of thing, in my mind, should be going into the attack matrix.

398
00:39:15,300 --> 00:39:21,280
Or if it's not going to the attack matrix, should be going into the equivalent matrix for business systems.

399
00:39:21,280 --> 00:39:25,720
If we don't capture this kind of information, we're never going to get our socks to start looking for them.

400
00:39:28,740 --> 00:39:30,320
So hypothesis three.

401
00:39:30,360 --> 00:39:32,340
So this was taken from our VDB.

402
00:39:33,060 --> 00:39:40,280
I took the top 10 or so issues that we regularly report to customers when we go and look at Unix systems.

403
00:39:40,280 --> 00:39:47,140
I went and I had a look at whether they were captured inside ATT&CK as it stands today.

404
00:39:48,520 --> 00:39:52,320
Security patches, password reuse, etc.

405
00:39:52,460 --> 00:39:53,960
They're all covered.

406
00:39:55,440 --> 00:39:58,480
Role accounts for interactive logins.

407
00:39:58,540 --> 00:40:04,320
Semi covered, but perhaps not the way I would have viewed it from my standpoint.

408
00:40:04,880 --> 00:40:10,720
That third, fourth one down, that's not captured at all in any useful sense.

409
00:40:12,440 --> 00:40:19,220
It gets us into almost every enterprise Unix box we go and look at.

410
00:40:19,340 --> 00:40:23,380
You get your role account, you get your low privilege user.

411
00:40:23,620 --> 00:40:26,760
Almost every single one of them will get to read through that.

412
00:40:28,040 --> 00:40:41,340
So we ought to make sure that ATT&CK factors that in, describes it, and gives the information that allows a sock to start to detect, to start to respond when those kinds of attacks are used.

413
00:40:43,340 --> 00:40:54,880
So broadly speaking, I guess where we're at, I think we don't have the right level of platform and application awareness today, which inevitably means there's an intelligence gap.

414
00:40:55,220 --> 00:41:08,940
Which means that no matter whether you're doing intelligence, whether you're modeling, whether you're simulating, or whether you're hunting, you're going to be working, I think, from an incomplete set of hypotheses.

415
00:41:09,140 --> 00:41:16,100
Which means that the models that you're working to probably don't relate to the systems that you're actually caring about.

416
00:41:16,640 --> 00:41:22,860
And you're probably not going to be as accurate as you might want to be when you start to validate them.

417
00:41:25,060 --> 00:41:27,560
How do we improve all of this?

418
00:41:27,960 --> 00:41:30,120
It's the million dollar question.

419
00:41:33,260 --> 00:41:35,580
Threat modeling certainly plays a part.

420
00:41:35,580 --> 00:41:53,900
If you were simply to take the approach I did with the vulnerabilities, and use that to drive the threat models for systems you don't know about, you would certainly get to a place where your blue team would probably have a better understanding of what bad is likely to look like.

421
00:41:55,480 --> 00:42:01,520
Once your blue team have an understanding, then they can drive the visibility.

422
00:42:02,420 --> 00:42:08,640
And then you can start to refocus your offensive services to validate that visibility is appropriate.

423
00:42:11,020 --> 00:42:17,140
Ultimately, I would posit that at least some of the problem is there aren't enough bums on blue team seats.

424
00:42:18,520 --> 00:42:32,460
I guess what I mean by that, we need to find a way of making it attractive to have those people that understand those applications, the security models behind them, sitting directly in the blue teams, or certainly sitting adjacent to those blue teams,

425
00:42:32,460 --> 00:42:40,480
so that the blue teams can start to understand what some of the applications the businesses care about actually look like.

426
00:42:43,440 --> 00:42:48,040
Yeah, we can't fix architectural alignment or mission tomorrow.

427
00:42:48,840 --> 00:42:56,640
We probably can work on threat visibility and on target visibility, if we know what we're aiming for.

428
00:42:57,940 --> 00:43:04,140
If we understand the threats, we can better protect our customers and our data.

429
00:43:04,860 --> 00:43:25,720
More importantly, if you can start to talk about individual vulnerabilities, in terms of their impact or threat model on the kill chain, not only can you make sure that your SDLC is looking for the right things, but you can also make sure that the people that are doing the code,

430
00:43:25,720 --> 00:43:33,720
you know, the people that are sitting there writing the web applications, writing the code that interfaces with your message bus, your database, etc.

431
00:43:33,720 --> 00:43:38,420
So they understand why and how an attacker might attack them.

432
00:43:38,620 --> 00:43:46,520
And hopefully we'll get into a situation where less vulnerabilities of note will make it into business applications in G-course.

433
00:43:46,720 --> 00:43:51,300
Ultimately, organizations will have profit motivated.

434
00:43:52,260 --> 00:44:06,740
And if we can talk in language that makes it apparent to the C-suite why it matters, what the cost of not doing X is, I think perhaps we'll be slightly more successful in that regard.

435
00:44:09,240 --> 00:44:12,100
So, offensive services.

436
00:44:13,920 --> 00:44:17,260
I think there's life beyond Nessus and MITRE.

437
00:44:18,440 --> 00:44:22,980
But that data is still useful, even from a red team standpoint.

438
00:44:23,440 --> 00:44:29,480
I guess we need to figure out how to use it more effectively.

439
00:44:30,700 --> 00:44:41,260
You know, we need to be in a position where we can far more quickly, far more comfortably talk to the kinds of bespoke briefings that organizations want.

440
00:44:42,460 --> 00:44:49,180
Craft war games that are actually appropriate to the things that matter to a business.

441
00:44:49,740 --> 00:44:53,300
We need to be able to articulate all of that.

442
00:44:54,000 --> 00:45:00,560
And obviously, better metadata, visual representation certainly helps with that communication piece.

443
00:45:00,560 --> 00:45:04,420
And we need to refine our assessment methodologies.

444
00:45:04,420 --> 00:45:11,220
I think too much of pen testing today is focused on the break in.

445
00:45:11,360 --> 00:45:31,920
And I think the data I showed around CVSS shows that actually, given that pen tests are still the lowest bar most organizations will jump through, they're actually getting testers to a place where they feel comfortable to talk about the other side of the line.

446
00:45:31,980 --> 00:45:33,760
The system has been compromised.

447
00:45:33,760 --> 00:45:39,500
How do we get back out is something we probably ought to focus more time on.

448
00:45:40,980 --> 00:45:42,940
So some conclusions.

449
00:45:43,260 --> 00:45:44,720
What have we learned?

450
00:45:44,840 --> 00:45:46,360
How do we do this better?

451
00:45:46,360 --> 00:45:47,560
Next steps.

452
00:45:49,380 --> 00:45:52,780
We can automate extraction of hypotheses.

453
00:45:52,940 --> 00:45:57,240
We can build threat models in an automated fashion.

454
00:45:59,460 --> 00:46:10,280
Vulnerability data, no matter how poor you may think it is, could still be useful with the right labeling applied.

455
00:46:12,280 --> 00:46:24,480
Actually, from a tester standpoint, it'd be kind of great if we rocked up organizations and they had a threat model based on their existing understanding of their vulnerability state.

456
00:46:25,720 --> 00:46:34,180
Extract your quality information, build that threat model, give it to the tester at the start and say, this is kind of where we think the threats live.

457
00:46:34,540 --> 00:46:36,120
Help us validate that.

458
00:46:38,260 --> 00:46:49,280
Again, if you can get to a place where you can take your vulnerability data and start to think about it in attack terms, then you can start to think about the control sets that you need.

459
00:46:49,280 --> 00:46:55,120
And potentially, you can start to think about automatic generation and validation.

460
00:46:57,160 --> 00:47:00,740
Ultimately, it's a communication problem, right?

461
00:47:00,900 --> 00:47:11,160
Attack has given us a wonderful tool to help us bridge the gap between red and blue, between operational and management.

462
00:47:11,160 --> 00:47:15,040
We just need to make sure we take the best advantage of it.

463
00:47:16,060 --> 00:47:17,760
So doing this better.

464
00:47:19,160 --> 00:47:21,060
Better consideration.

465
00:47:21,380 --> 00:47:27,200
I know that from a red team standpoint, we would argue that perhaps we're there.

466
00:47:27,380 --> 00:47:41,420
But actually, I don't think a VA, a generic pen test necessarily needs to consider the scope they're given to be an impedance to giving better outcomes to customers.

467
00:47:43,140 --> 00:47:56,680
We do a really good job of collecting awesome information about threats and vulnerabilities, whether it's Reddit, whether it's peer list, unfortunately closed down, or anywhere else.

468
00:47:56,720 --> 00:48:01,140
But even that data, we don't particularly do a good job of enriching it.

469
00:48:01,340 --> 00:48:07,380
Having a platform that allows proper automated enrichment of that kind of information.

470
00:48:08,340 --> 00:48:12,020
Maybe you're lucky and you're sitting in an organization that has it.

471
00:48:12,020 --> 00:48:14,440
It's a bit of a forlorn dream for me.

472
00:48:16,040 --> 00:48:23,960
Personally, getting our database to a point it's fully labeled and being able to run queries against those labels will be pretty kick ass.

473
00:48:25,260 --> 00:48:29,260
Taking that the next step and making it actionable.

474
00:48:29,400 --> 00:48:31,720
I mentioned that we use sticks.

475
00:48:31,720 --> 00:48:36,200
Sticks is good at talking about the types of threats.

476
00:48:36,740 --> 00:48:42,840
It doesn't really capture the level of information that's required for machine action ability.

477
00:48:43,320 --> 00:48:47,380
There are some solutions to that, the Sigma and others.

478
00:48:47,840 --> 00:48:53,700
But we're really not at a point where we define vulnerabilities in a way that's particularly helpful for scale.

479
00:48:55,440 --> 00:49:03,780
And ultimately, if we don't generate for scale, improving EDR and workload protection products is going to be pretty forlorn.

480
00:49:03,780 --> 00:49:23,720
If every vulnerability report that every pen test or security researcher turned out had essentially a cool chain graph that an EDR solution or workload protection product could import and then look for, rather than being reliant upon hashes, IP addresses,

481
00:49:23,720 --> 00:49:28,440
host names, that would take us a huge way forwards.

482
00:49:30,400 --> 00:49:33,500
So next steps, call to action, I guess.

483
00:49:35,540 --> 00:49:41,200
Just because we don't have the capabilities to look for bad guys doesn't mean they're not there.

484
00:49:42,600 --> 00:49:46,400
Attackers, we use the easiest TTPs that get them to the root prompt.

485
00:49:46,500 --> 00:49:49,560
Those things I was talking about are pretty damn easy.

486
00:49:50,940 --> 00:49:58,580
Behavior, don't rely upon agents that are merely relying upon hashes and IP addresses.

487
00:49:59,980 --> 00:50:08,060
If you're doing Unix stuff, make sure you're exercising those things, because the bad guys certainly are.

488
00:50:09,280 --> 00:50:21,460
And Linux apps, Unix check, I kind of look forward to the day when they appear in a virus title, and they're being detonated and being marked as malicious.

489
00:50:21,640 --> 00:50:27,740
It'll make my job a little bit harder, but actually it'll make Blue Team's jobs a hell of a lot easier.

490
00:50:31,080 --> 00:50:40,520
Finally , a few thanks, my old colleagues, Cisco's wider team, MITRE, ATT &CK wouldn't exist without them.

491
00:50:41,120 --> 00:50:49,420
Swimlane, PyTAC is still the most comfortable interface I've found rather than writing in Perl.

492
00:50:49,920 --> 00:50:56,180
And Blue Team's everywhere, because you do a thankless job, and for the most part, you do it as well as you can do.

493
00:50:57,480 --> 00:50:59,600
And with that, questions?