1
00:00:00,870 --> 00:00:06,070
Hi everyone, today we're going to talk about purple teaming and adversary emulation in the cloud.

2
00:00:06,070 --> 00:00:10,450
We're also going to present an open source tool that I'm the maintainer of called Stratus Red Team.

3
00:00:11,030 --> 00:00:13,070
My name is Christophe Tafani de Roper.

4
00:00:13,130 --> 00:00:16,430
I work at Datadog and this is my handle on Twitter.

5
00:00:16,430 --> 00:00:19,250
If you want to send me a message, feel free to do so.

6
00:00:19,250 --> 00:00:22,810
We have a lot of positions open, so if you want to apply, have a look.

7
00:00:22,810 --> 00:00:29,450
I think we have over 35 right now across security, operations, supply chain security, product security, etc.

8
00:00:30,530 --> 00:00:36,830
Today we're going to start by talking a bit about detection engineering, purple teaming, and how they relate together.

9
00:00:36,890 --> 00:00:41,110
We're going to see some pain points of doing purple teaming in the cloud.

10
00:00:41,250 --> 00:00:50,570
We're going to introduce Stratus Red Team, an open source project that I've been working on, as well as ways to use it more in an advanced way.

11
00:00:50,570 --> 00:00:56,490
And finally, I have two exciting announcements to make just for today for the Cloud Village attendees.

12
00:00:57,690 --> 00:01:00,510
Let's talk about detection engineering.

13
00:01:00,510 --> 00:01:08,090
Detection engineering is basically a fancy word to say how do we detect bad things and how do we maintain these detections as we go.

14
00:01:08,170 --> 00:01:20,890
As an industry, we've been moving from detecting indicators of compromise, like IP addresses, hashes, domain names, to detecting things that look more like behaviors and tools.

15
00:01:20,910 --> 00:01:23,670
You maybe have seen this this schema before.

16
00:01:23,670 --> 00:01:25,410
It's called the pyramid of pain.

17
00:01:25,590 --> 00:01:31,830
And basically, the idea is that as you move up to the pyramid, things are harder to change for an attacker.

18
00:01:32,370 --> 00:01:35,110
But they are also harder to detect for a defender.

19
00:01:35,190 --> 00:01:41,650
Typically, if you look at a file hash, it's very easy for an attacker to change, very easy for a defender to detect.

20
00:01:41,770 --> 00:01:50,290
If you move up and you look at the behavior, it's very hard for an attacker to change that, and it's harder for a defender to detect behavior because it's not well defined.

21
00:01:51,510 --> 00:01:56,790
If we start to detect behaviors, we need to have a way to model how attackers behave.

22
00:01:56,870 --> 00:02:00,450
And that's what, for instance, Mitre ATT&CK is doing.

23
00:02:00,450 --> 00:02:06,890
So they try to understand how attackers behave across the different stages of the attack.

24
00:02:07,270 --> 00:02:10,090
Now, they also have a version for cloud.

25
00:02:10,090 --> 00:02:15,850
I would argue that it's not great for cloud because they try to not be too specific about a single cloud provider.

26
00:02:15,850 --> 00:02:21,290
So you really have the common denominator between all the providers.

27
00:02:21,550 --> 00:02:24,810
There is one that is more specific, introduced by Microsoft.

28
00:02:24,810 --> 00:02:26,970
It's called the Threat Matrix for Kubernetes.

29
00:02:26,970 --> 00:02:34,490
And they use the same ATT&CK stages as Mitre ATT&CK, but they go into very much detail on how this works for Kubernetes.

30
00:02:35,310 --> 00:02:40,870
Very recently, there's also the Azure Threat Research Matrix that was released.

31
00:02:40,930 --> 00:02:48,670
Similarly, you have different ATT&CK stages and some ATT&CK techniques that are very specific to Azure and how they work.

32
00:02:49,830 --> 00:02:53,070
Now, a few words about purple teaming, which is a buzzword.

33
00:02:53,830 --> 00:03:04,050
So it's really about having, like, starting from having a blue team and a red team, but don't really work together and communicate, to having something like that, because blue and red makes purple.

34
00:03:04,230 --> 00:03:09,450
And the idea is really that your blue team and your red team should work together towards a common goal.

35
00:03:09,850 --> 00:03:18,650
For this talk, I'd like to define purple teaming as empowering defenders to understand, to reproduce, and to detect common attacker tactics.

36
00:03:18,730 --> 00:03:25,090
So we see here that you have the concept of how do I understand things, how do I reproduce them, and how do I detect them.

37
00:03:25,510 --> 00:03:32,550
And this is very much aligned to what an American psychologist named Kolb explained in the 1970s.

38
00:03:32,550 --> 00:03:36,350
And the idea is that he tried to describe how people learn.

39
00:03:36,630 --> 00:03:39,150
And it starts with an active experimentation.

40
00:03:39,310 --> 00:03:41,790
Maybe you are going to touch something very hot.

41
00:03:41,950 --> 00:03:44,390
Out of that, you get an experience.

42
00:03:44,710 --> 00:03:47,410
So your experience is I touched something very hot.

43
00:03:47,430 --> 00:03:52,130
Now you have something that is not only theoretical, but you experienced it in the real world.

44
00:03:52,190 --> 00:03:54,590
Then based on that, you're going to make an observation.

45
00:03:54,870 --> 00:03:57,830
Oh, I touched it, it was very hot, and now I got burned.

46
00:03:58,270 --> 00:04:04,010
And based on that, you are going to update your view, your understanding of the world by conceptualizing that.

47
00:04:04,450 --> 00:04:10,750
So you're going to say if I touch something very hot, it's likely I'm going to get burned, hence I'm not going to do it again.

48
00:04:11,050 --> 00:04:17,370
And it's really the same for detection engineering in the sense that first you want to reproduce a specific attack.

49
00:04:18,090 --> 00:04:20,630
You want to get your concrete experience of doing it.

50
00:04:20,630 --> 00:04:22,830
You're going to observe what data you have.

51
00:04:22,830 --> 00:04:23,930
What kind of logs do you get?

52
00:04:23,930 --> 00:04:25,110
What kind of artifacts?

53
00:04:25,110 --> 00:04:26,310
What kind of analytics?

54
00:04:26,510 --> 00:04:31,370
And then you're going to try to conceptualize a detection based on that.

55
00:04:32,330 --> 00:04:36,470
And today we're going to focus on this part of reproducing an attack.

56
00:04:36,570 --> 00:04:39,690
And we're going to see that it's not that easy in the cloud.

57
00:04:40,130 --> 00:04:45,910
So let's say that we want to detect when VPC flow logs in AWS are removed.

58
00:04:46,130 --> 00:04:52,630
This is a popular thing for attackers because if you remove some logs, then a defender cannot know what you were up to.

59
00:04:52,630 --> 00:04:55,790
So let's try to reproduce this attack.

60
00:04:55,790 --> 00:05:05,190
So first we need to create a VPC and to enable the VPC flow logs to have the prerequisite infrastructure we need to be able to reproduce that.

61
00:05:05,190 --> 00:05:06,670
And then we reproduce the attack.

62
00:05:06,670 --> 00:05:08,850
We're going to delete the VPC flow logs.

63
00:05:09,130 --> 00:05:11,050
So let's go to the AWS console.

64
00:05:11,750 --> 00:05:16,070
We are going to create a VPC, give it a name, an IP range.

65
00:05:16,070 --> 00:05:19,150
We are going to create a flow log configuration.

66
00:05:19,610 --> 00:05:23,210
So AWS asks us where we want to send the logs.

67
00:05:23,210 --> 00:05:24,110
Let's say CloudWatch.

68
00:05:24,110 --> 00:05:25,030
It's the default.

69
00:05:25,350 --> 00:05:29,090
So we are asked for a destination log group, but we don't have any.

70
00:05:29,130 --> 00:05:32,610
Then for an IAM role, we don't have an IAM role either.

71
00:05:32,610 --> 00:05:33,970
So we are not sure what to do.

72
00:05:34,350 --> 00:05:35,390
So we go to the docs.

73
00:05:35,390 --> 00:05:39,450
We see, okay, you need to create a role with this specific IAM policy.

74
00:05:39,750 --> 00:05:40,470
Fair enough.

75
00:05:40,670 --> 00:05:50,450
Then it says, also you need to add a trust policy to your role so that it allows the VPC flow logs delivery service to assume the role to deliver the logs for you.

76
00:05:50,630 --> 00:05:54,190
And at this point, you are already even more confused.

77
00:05:54,190 --> 00:06:05,610
And basically what happens is that you spend a lot of time trying to set up the right infrastructure you need to reproduce your attacks, sometimes to complain about the documentation, and very little time testing your threat detection.

78
00:06:06,430 --> 00:06:11,330
And that's something that we see when we test threat detection for the cloud and that we wanted to make better.

79
00:06:11,670 --> 00:06:18,370
So to sum up, the challenges that we found are really the testing prerequisites in the cloud can be very complex.

80
00:06:18,370 --> 00:06:23,950
If you want to test a specific attack and you need some prerequisites, it's not straightforward to set them up.

81
00:06:24,330 --> 00:06:28,230
The fact also that cloud security is still a pretty new field.

82
00:06:28,310 --> 00:06:32,590
And I think we have to acknowledge as an industry that it's an emerging threat landscape.

83
00:06:32,670 --> 00:06:38,130
So it's not very clear what are the threats and how they behave and how they evolve.

84
00:06:38,270 --> 00:06:45,290
And finally, and it's related, is that we don't have a lot of data available on what cloud incidents happen in the real world.

85
00:06:45,530 --> 00:06:47,930
And that's why we built Stratus Red Team.

86
00:06:48,150 --> 00:06:51,970
So Stratus Red Team is an open source project that you can find on GitHub.

87
00:06:52,250 --> 00:06:56,310
I like to pitch it as Atomic Red Team for the cloud, and we'll see why in a bit.

88
00:06:56,470 --> 00:07:04,210
It's written in Go, so it comes as a single prepackaged binary, which comes with a bunch of attack techniques.

89
00:07:04,670 --> 00:07:07,750
It currently supports AWS, Azure, and Kubernetes.

90
00:07:08,590 --> 00:07:15,810
So the attack techniques in Stratus Red Team, we try to have high quality attack techniques that follow this philosophy.

91
00:07:15,810 --> 00:07:17,430
First, that are threat informed.

92
00:07:17,430 --> 00:07:22,250
So we want things that we think defenders should care about, and we tell you why.

93
00:07:22,610 --> 00:07:24,670
It should be actionable for defenders.

94
00:07:25,390 --> 00:07:31,910
So it's not really useful if we tell you this is a threat, but we don't explain how to defend or how to detect it.

95
00:07:32,150 --> 00:07:33,350
It should be granular.

96
00:07:33,350 --> 00:07:36,070
So typically, we don't try to have a full attack chain.

97
00:07:36,070 --> 00:07:39,930
We only have specific attack techniques, like Atomic Red Team.

98
00:07:39,930 --> 00:07:41,570
And finally, safe sufficient.

99
00:07:41,570 --> 00:07:44,890
So when you run Stratus Red Team, it should work in any AWS account.

100
00:07:44,890 --> 00:07:49,250
You shouldn't have any prerequisites, and Stratus Red Team is going to handle all the prerequisites for you.

101
00:07:49,250 --> 00:07:50,890
And we'll see that in a bit as well.

102
00:07:52,190 --> 00:07:54,910
So to sum up, Stratus Red Team is going to bring two things.

103
00:07:55,130 --> 00:07:57,990
First is a catalog of cloud attack techniques.

104
00:07:58,330 --> 00:08:04,230
A bit like MyAzure Attack, but much more specific to AWS, to Kubernetes, to Azure.

105
00:08:04,530 --> 00:08:10,030
And secondly, a way to easily reproduce these attack techniques against a live environment.

106
00:08:10,170 --> 00:08:23,310
So typically, you're going to take Stratus Red Team, you're going to point it at an existing AWS account, or Kubernetes cluster, or Azure subscription, and you're going to detonate the attack techniques against one of these live environments.

107
00:08:24,930 --> 00:08:34,450
Currently, we have 27 AWS attack techniques, 7 for Kubernetes, and 3 for Azure, which is a quite recent platform.

108
00:08:34,450 --> 00:08:40,390
You have a full list on the website, and you will see that they are organized by Mitre Attack Tactics.

109
00:08:40,390 --> 00:08:45,870
So you have persistent, initial access, exfiltration, privileged escalation, etc.

110
00:08:46,170 --> 00:08:52,370
Now let's dive a bit into what specifically an attack technique looks like in Stratus Red Team.

111
00:08:52,730 --> 00:08:57,670
So if you use VCLI, you can do a Stratus show, and then the name of the attack technique.

112
00:08:57,670 --> 00:08:59,430
It will give you a bit of information.

113
00:08:59,750 --> 00:09:04,610
Here we are seeing an attack technique that consists in stopping a CloudTrail trail.

114
00:09:04,830 --> 00:09:06,330
And you see that we have two things.

115
00:09:06,330 --> 00:09:09,190
We have a warm-up phase and a detonation phase.

116
00:09:09,430 --> 00:09:12,710
The warm-up phase is when we are going to create the prerequisites.

117
00:09:12,870 --> 00:09:15,670
So here we are going to stop a CloudTrail trail from running.

118
00:09:15,690 --> 00:09:17,230
So what are the prerequisites?

119
00:09:17,230 --> 00:09:23,150
We need first a CloudTrail trail that logs into an S3 bucket with appropriate roles, etc.

120
00:09:23,590 --> 00:09:26,990
And then the detonation is really when we're going to reproduce the attack.

121
00:09:26,990 --> 00:09:30,370
Here it's going to be simple, just stop the trail from logging.

122
00:09:31,390 --> 00:09:42,130
We have the same thing on the website as well, in addition to the mapping to Mitre Attack, the description that we saw before, and a few ideas on how this can be detected.

123
00:09:42,310 --> 00:09:51,850
And the idea here is not to give a very precise rule, it's more to give you an idea of what logs you can use to detect the attack, if there are some guarantee findings for it, and things like that.

124
00:09:52,870 --> 00:09:58,090
Now the first piece of code that handles the prerequisite infrastructure is based on Terraform.

125
00:09:58,730 --> 00:10:07,030
It's going to be totally transparent for you, so you don't have to install Terraform, you don't have to manage it, but this is how it's done under the hood.

126
00:10:07,030 --> 00:10:12,430
So this is going to create the S3 bucket and the CloudTrail trail that we need to be able to reproduce the attack.

127
00:10:13,310 --> 00:10:23,190
Again, the Terraform instrumentation here is fully transparent, so typically it doesn't mess with your Terraform version, you don't need to install it, and it uses the official Terraform Go wrapper.

128
00:10:23,450 --> 00:10:27,430
Again, you don't need to know it, it's just to understand how it works under the hood.

129
00:10:27,890 --> 00:10:33,770
And then the second piece of code is going to be the actual attack written as imperative Go code.

130
00:10:33,930 --> 00:10:38,530
So here it's very simple, it's going to be my attack is stopping the CloudTrail from logging.

131
00:10:38,530 --> 00:10:42,950
I'm just going to use the AWS SDK to stop this trail from logging.

132
00:10:44,890 --> 00:10:49,550
In terms of lifecycle, so initially your attack technique is going to be called.

133
00:10:49,550 --> 00:10:51,310
It's going to be the initial state.

134
00:10:51,310 --> 00:10:55,690
Then once you create the prerequisite, it's going to be warm.

135
00:10:55,730 --> 00:10:59,710
And finally, when you detonate the attack, it's going to be detonated.

136
00:10:59,710 --> 00:11:09,190
So here again, warming up our attack means creating the S3 bucket, the CloudTrail trail, and at this point we are ready to reproduce the attack.

137
00:11:09,190 --> 00:11:15,510
We can do it right away, or we can maybe wait a few hours, a few days if we want, and it's going to be stopping the CloudTrail trail.

138
00:11:16,710 --> 00:11:18,790
Now let's have a very quick demo.

139
00:11:20,810 --> 00:11:22,530
So I have Stratus team installed there.

140
00:11:22,530 --> 00:11:25,930
I can do Stratus version, I see a version 2.2.2.

141
00:11:26,090 --> 00:11:32,530
If I do Stratus list dash dash platform AWS, I can see all the attack techniques for AWS.

142
00:11:32,570 --> 00:11:38,290
I can be a bit more specific and look at AWS attack techniques for exfiltration.

143
00:11:38,590 --> 00:11:55,030
Now if I copy-paste the name of an attack technique, I can go to the website and I will see the mapping to my attack, the description, you see we have the warm-up and the detonation phase, and the instructions on how to detonate the attack technique with Stratus Red Team.

144
00:11:55,070 --> 00:12:04,330
If I go back to the console, I do Stratus warm-up with the name, I see that the warm-up phase is going to create a snapshot and a volume for me.

145
00:12:04,370 --> 00:12:10,930
If I go to my console, I see that I now have a volume and a snapshot that was created for me.

146
00:12:11,050 --> 00:12:15,250
And this is really the prerequisite infrastructure that I need to reproduce my attack.

147
00:12:15,270 --> 00:12:20,590
And I can see that for now, the snapshot hasn't been shared with anything yet.

148
00:12:20,590 --> 00:12:29,450
Now if I do Stratus detonate of my attack technique, it's going to share the volume with an external AWS account to simulate this attack.

149
00:12:29,470 --> 00:12:37,150
And if I refresh, I will see that the permissions now show that the snapshot has been shared with a specific attacker account.

150
00:12:41,110 --> 00:12:45,690
Now one other point of doing that is being able to see what logs I get.

151
00:12:45,690 --> 00:13:03,010
So if I go to CloudTrail, I can have a query that says, show me the modify attribute events, and I will see that I have one event that was caused by Stratus Red Team for my specific snapshot, adding the create volume permission, essentially sharing it with an external account.

152
00:13:03,650 --> 00:13:05,910
Now we can do the same for Kubernetes.

153
00:13:05,910 --> 00:13:09,350
I'm here on a Kubernetes cluster with one node locally.

154
00:13:09,350 --> 00:13:13,870
If I do Stratus list for Kubernetes, I will get the list of attack techniques.

155
00:13:17,210 --> 00:13:28,310
And if I take this one, so stealing a service account token from a pod, I'm going to copy-paste that, go to the docs, it will show me what it means.

156
00:13:28,310 --> 00:13:32,590
So this is going to attempt to steal a service account token from a running pod.

157
00:13:32,590 --> 00:13:40,210
The warmup is going to create a namespace, service account, a pod, and the detonation is going to dump the service account token from the running pod.

158
00:13:40,410 --> 00:13:42,470
I can just do the detonate directly here.

159
00:13:42,470 --> 00:13:51,390
It's going to do the warmup, so spinning of the pod, and then do the detonation right away, showing me that it stole the service account token.

160
00:13:53,670 --> 00:14:02,290
Now, if I do Stratus detonate with another one, so privilege escalation, privilege pod, it's going to run a privilege pod.

161
00:14:02,290 --> 00:14:07,930
If I look at my pods running, I can now see that I have this malicious pod running.

162
00:14:08,150 --> 00:14:20,810
And if I do a Stratus status, I will see that some attack techniques have been detonated, some are still called, and I can do a Stratus cleanup with the name of my attack techniques to clean up everything.

163
00:14:22,170 --> 00:14:26,230
Let's have a look at the attack techniques we have in Stratus RATIM for AWS.

164
00:14:26,230 --> 00:14:27,390
Let's take this one.

165
00:14:27,390 --> 00:14:48,640
We're going to create a threat test scenario in GoCode, saying when we open a port 22 on a security group, and this is when we detonate this Stratus RATIM attack technique, then we expect a specific data log security signal that has this name, and we give it five minutes.

166
00:14:49,310 --> 00:14:57,910
Now, we're going to create another one, so we copy-paste this code for another attack technique, and let's take the one about sharing an EBS snapshot.

167
00:14:57,930 --> 00:15:00,510
We can just replace the attack technique name.

168
00:15:00,510 --> 00:15:09,010
We rename the scenario to exfiltrating an EBS snapshot, and then we expect a different alert.

169
00:15:09,010 --> 00:15:13,210
We give it five minutes, and then we're going to run threat test.

170
00:15:13,610 --> 00:15:33,690
We expect that it doesn't return any error, and then we go ahead, we go test our source code, and we see it's going to detonate the attack technique using Stratus RATIM, the first one, and the second one, and then it's going to show us that it has created the expected alerts that we thought we would get in data log.

171
00:15:34,210 --> 00:15:40,170
So, we see that this was closed also by the automation.

172
00:15:41,370 --> 00:15:42,810
This one as well.

173
00:15:43,190 --> 00:15:45,350
We are happy we get our alerts.

174
00:15:47,580 --> 00:15:54,680
Great, so now that we have seen how we can use Stratus RATIM in practice, let's see how we can use it in a more advanced fashion.

175
00:15:54,800 --> 00:15:58,820
And typically, you will see that Stratus RATIM works very well with automation.

176
00:15:59,380 --> 00:16:02,560
The first thing that we're going to see is programmatic usage.

177
00:16:02,560 --> 00:16:14,700
We're going to see also how we can automatically generate some logs data sets using the API from our CM, and we're going to see a few things about end-to-end testing our threat detection rules.

178
00:16:15,400 --> 00:16:23,800
So, the programmatic interface basically means that you can use Stratus RATIM as a Go library, just as you can use it from CLI.

179
00:16:24,400 --> 00:16:33,700
So, this is great if you want to automate some things, and you can just do a go get github.com data.stratus.ratim, and then use it from your code.

180
00:16:34,200 --> 00:16:43,180
It has an auto-generated documentation on the Go documentation, and basically the way to use it is very similar to how you would do it on the CLI.

181
00:16:43,300 --> 00:16:48,660
So, first you're going to instantiate a new Stratus RATIM runner for a specific attack technique.

182
00:16:48,660 --> 00:16:52,400
Then you say, at the end, I want to make sure it's cleaned up.

183
00:16:52,400 --> 00:16:54,420
Then you're going to warm it up.

184
00:16:54,700 --> 00:16:58,020
This is going to do under the hood, the terraform apply, etc.

185
00:16:58,520 --> 00:17:01,260
And when it's warm, you're going to detonate it.

186
00:17:01,260 --> 00:17:02,180
And that's it.

187
00:17:02,420 --> 00:17:04,700
It's great if you want to do some automations.

188
00:17:05,640 --> 00:17:16,800
Now, I worked in a SOG before, and one of the things that we like to do is to understand what a specific attack is going to generate in terms of logs.

189
00:17:17,760 --> 00:17:20,640
So, really, if I launch this attack, what logs do I get?

190
00:17:20,640 --> 00:17:33,320
And this is something that is hard to do manually because you need to go to detonate your attack, to go to see your logs, to understand what logs were created by your specific run, and what is just pollution coming from something else unrelated.

191
00:17:34,280 --> 00:17:39,500
So, the way that we can help with Stratus RATIM is, first, you can detonate the attack technique.

192
00:17:40,240 --> 00:17:55,820
Once you do the detonation, Stratus RATIM is going to automatically inject a specific unique ID in the user agent of the request that it makes to the AWS API, to the Azure API, or to the Kubernetes API.

193
00:17:55,940 --> 00:18:05,140
And based on that, it means that you can go to your SIEM, and you can ask it through the API, give me all the logs where you see this specific user agent.

194
00:18:05,560 --> 00:18:08,140
And what you get is, one, automation.

195
00:18:08,320 --> 00:18:15,840
And two, you are sure that the logs that you retrieve are caused by your actual detonation of the attack technique, which is a great property.

196
00:18:16,820 --> 00:18:20,120
So, we have some sample code for that on GitHub.

197
00:18:20,160 --> 00:18:28,560
It was written for Datalog as a SIEM, because that's what we know how to use, but it can be easily adapted to use anything like Splunk or any other SIEM.

198
00:18:28,880 --> 00:18:30,680
So, this is the way it works.

199
00:18:30,860 --> 00:18:39,520
You would go ahead and write dump logs, the name of your attack techniques, and then the output file in which to store the logs.

200
00:18:39,520 --> 00:18:43,640
It will use Stratus Red Team programmatically to detonate the attack technique.

201
00:18:43,760 --> 00:18:46,900
It's going to show you the unique ID for the detonation.

202
00:18:47,500 --> 00:18:50,260
It's going to search for the logs in your SIEM, here, Datalog.

203
00:18:50,740 --> 00:18:53,000
And then it says, okay, I found one log.

204
00:18:53,220 --> 00:18:54,180
I'm going to dump...

205
00:18:55,600 --> 00:18:57,300
Okay, I found one log.

206
00:18:57,340 --> 00:19:13,230
I'm going to dump this log to logs.json, which means that without leaving your terminal, you are able to detonate an attack and see what logs you get for that, which is a very nice property when you do detection engineering, as it makes the feedback loop quite easier and faster.

207
00:19:15,020 --> 00:19:20,560
The last use case I want to mention today is about end-to-end testing of threat detection.

208
00:19:21,240 --> 00:19:26,760
So, let's have a look at what a typical AWS detection pipeline looks like.

209
00:19:26,900 --> 00:19:34,940
First, we have a bunch of AWS accounts that are going to log to a single CloudTrail trail, probably running inside a management account.

210
00:19:35,400 --> 00:19:43,140
This is going to be logging to an S3 bucket, and probably you have some kind of forwarder that's going to take these logs and send them to your SIEM.

211
00:19:43,640 --> 00:19:49,920
Now, your SIEM is going to ingest these logs, to parse them, to aggregate them, maybe to do some kind of enrichment.

212
00:19:50,360 --> 00:19:53,440
And at the end, the detection rules that you have are going to run.

213
00:19:53,700 --> 00:19:55,880
And based on that, you get some alerts.

214
00:19:57,140 --> 00:20:10,540
Now, a lot of things can go wrong here, maybe your CloudTrail trail is not set up properly, maybe your forwarding is broken, you have a parsing issue, the rule that you expect to work is actually disabled, or you don't have enough license in your SIEM,

215
00:20:10,540 --> 00:20:12,060
so the rules are not running.

216
00:20:12,340 --> 00:20:13,700
A lot of things can go wrong.

217
00:20:14,100 --> 00:20:24,940
So, the idea is really to take this as a black box and to poke at it from one end using Stratus Red Team, and then to see what comes out in terms of alerts.

218
00:20:26,960 --> 00:20:32,480
And the workflow is really going to be, first, we detonate Stratus Red Team programmatically.

219
00:20:33,100 --> 00:20:38,460
Two, we pull our SIEM to check if we have an alert that we expect to have.

220
00:20:38,540 --> 00:20:40,340
If yes, we close the alert.

221
00:20:40,400 --> 00:20:50,020
If not, we basically raise an error to say, we detonated this attack, we were expecting this alert to trigger, it didn't trigger, so something is going wrong.

222
00:20:50,920 --> 00:21:03,060
And then it's easy to build some automation on top of that, to build some dashboards that say, you know, today we tested automatically these attacks, these are the results, everything looks fine, or you have some issues that you want to fix.

223
00:21:03,280 --> 00:21:06,960
So, today I'm very happy to announce that we are releasing Threatest.

224
00:21:07,060 --> 00:21:10,800
Threatest is a Go framework for end-to-end testing of threat detection rules.

225
00:21:11,040 --> 00:21:12,580
And let's see how it works.

226
00:21:13,060 --> 00:21:20,400
The idea is that you basically have detonators that you can use to detonate specific attack techniques, and matchers.

227
00:21:20,720 --> 00:21:23,900
Detonators are going to be about, how do I run an attack?

228
00:21:23,900 --> 00:21:29,800
And matchers are going to be, I expect a specific alert to have been triggered in a specific platform.

229
00:21:30,340 --> 00:21:33,300
For the detonators, we have the ones that are more for the cloud.

230
00:21:33,540 --> 00:21:37,620
So there is one using Stratus Red Team, one using the AWS SDK.

231
00:21:38,080 --> 00:21:43,540
You have some detonators that you can use to run OS-level commands over SSH or locally.

232
00:21:43,780 --> 00:21:50,340
And for the matchers, currently, you can use it to check if a specific alert was created on Datadog.

233
00:21:50,340 --> 00:21:56,700
And we are hoping to get some contributions to add support for other platforms such as Greylog as well.

234
00:21:57,020 --> 00:21:58,600
So let's see how this works.

235
00:21:58,660 --> 00:22:01,200
First, you're going to create a scenario with Threatest.

236
00:22:01,200 --> 00:22:03,040
So this is going to be using GoCode.

237
00:22:03,180 --> 00:22:08,360
You say, I want a scenario where I do an AWS console login without MFA.

238
00:22:08,780 --> 00:22:13,440
The detonation is going to be Stratus Red Team with this specific attack technique.

239
00:22:13,840 --> 00:22:20,160
And as expectations, I expect to get a Datadog security alert with this name and this severity.

240
00:22:20,260 --> 00:22:23,080
And I give it 15 minutes to be there.

241
00:22:23,920 --> 00:22:27,920
So now let's have a demo on how Threatest works in practice.

242
00:22:29,040 --> 00:22:31,440
All right, so that's pretty much it for today.

243
00:22:31,440 --> 00:22:33,100
So now we're going to wrap up.

244
00:22:33,240 --> 00:22:35,200
What's next for Stratus Red Team?

245
00:22:35,200 --> 00:22:38,440
First, we want to increase the attack techniques coverage.

246
00:22:39,260 --> 00:22:45,400
Typically, we want to add more techniques for Kubernetes for Azure and to have more platforms as well.

247
00:22:45,640 --> 00:22:47,420
We are eager to hear from the community.

248
00:22:47,560 --> 00:23:00,380
So typically, if you are involved in AWS security, especially incident response, I'm really interested to hear about what you see in the wild and when we have some attack techniques that make sense to help having them inside of Stratus Red Team.

249
00:23:02,360 --> 00:23:09,840
So specifically focusing on attacks that we see in the wild or that are used by Red Teams, by pen testers, by tooling.

250
00:23:10,300 --> 00:23:14,200
Then I want to say a big thank you to the contributors of Stratus Red Team.

251
00:23:14,400 --> 00:23:21,380
So the four first public ones are Ryan Marcotte-Cobb, Marcus Rollwagen, Aydan Alvarez, and Dakota Reilly.

252
00:23:21,620 --> 00:23:23,700
So they are the first contributors to Stratus Red Team.

253
00:23:23,700 --> 00:23:25,080
I'm very proud of them.

254
00:23:25,260 --> 00:23:28,020
And thanks again for all your contributions.

255
00:23:29,280 --> 00:23:37,040
Then one more thing that I want to announce today is that just this morning, we have released GCP support for Stratus Red Team.

256
00:23:37,040 --> 00:23:43,020
And this is thanks to Dakota Reilly from Acquia, who did the initial contribution.

257
00:23:43,020 --> 00:23:44,820
And I'm very excited about this.

258
00:23:44,980 --> 00:23:47,620
So we are going to have first three attack techniques.

259
00:23:47,620 --> 00:23:56,360
First one is creating an admin GCP service account, creating a GCP service account key, and impersonating GCP service accounts.

260
00:23:56,360 --> 00:23:57,820
So this is just fresh out.

261
00:23:57,820 --> 00:24:00,180
It was released this morning over breakfast.

262
00:24:00,580 --> 00:24:01,920
So go and check it out.

263
00:24:01,920 --> 00:24:03,820
I'm very excited about it.

264
00:24:05,660 --> 00:24:08,460
Thanks a lot for looking at this presentation.

265
00:24:08,820 --> 00:24:10,840
The slides are available here.

266
00:24:10,940 --> 00:24:15,040
If you have some questions, you can send them on Twitter or by email.

267
00:24:15,040 --> 00:24:17,140
My contact information is on the first slide.

268
00:24:17,600 --> 00:24:20,200
I hope you will find Stratus Red Team useful.

269
00:24:20,340 --> 00:24:23,600
I'm looking forward to your comments, your ideas, and your contributions.

270
00:24:23,840 --> 00:24:24,780
Have a nice day.