1
00:00:00,980 --> 00:00:02,160
I'm Nimrod.

2
00:00:02,160 --> 00:00:03,960
I'm a solution architect at BridgeCrew.

3
00:00:03,960 --> 00:00:13,960
And over the next 35 minutes or so, I'd love to walk you through how you can utilize open source to do least privilege using infrastructure as code.

4
00:00:13,960 --> 00:00:14,260
Sorry.

5
00:00:15,480 --> 00:00:17,460
So, a bit about me.

6
00:00:17,460 --> 00:00:19,300
I'm a solution architect at BridgeCrew.

7
00:00:19,300 --> 00:00:29,060
BridgeCrew is a cloud security company that helps identify misconfigurations in both real cloud environments and infrastructure as code frameworks, such as Terraform, CloudFormation, etc.

8
00:00:29,060 --> 00:00:32,200
And we're doing all of this using grid automation.

9
00:00:32,380 --> 00:00:43,940
As part of my role in BridgeCrew, I'm involved with a few open source projects around AWS and Terraform, and security, which I either co-maintain or contribute to continuously.

10
00:00:44,180 --> 00:00:51,300
And my newest open source tool is called AirIAM, which I hope at the end of this talk you'll also be a fan of.

11
00:00:52,220 --> 00:00:53,700
Let's dive in.

12
00:00:54,820 --> 00:00:57,320
So, just a quick overview.

13
00:00:57,320 --> 00:01:05,760
AWS AirIAM is a service by AWS that manages all the privileges in your AWS account, in every AWS account.

14
00:01:05,760 --> 00:01:19,540
That means it includes all the privileges both for things that you need, your employees, your servers, but also for things that run in the background, like AWS services and access across services.

15
00:01:20,700 --> 00:01:24,400
So, it starts out really cool, and it allows that for everything.

16
00:01:24,400 --> 00:01:30,720
But the problem is that it is hard because it includes a lot of specifics and details.

17
00:01:30,900 --> 00:01:40,800
You create a user for every employee, and maybe for integrations, and for your CICD pipeline, and your servers, and it just becomes way too hectic.

18
00:01:41,240 --> 00:01:45,940
So, let's try to break it down and see why it is that way.

19
00:01:46,660 --> 00:01:51,320
When I look at AIAM, I think of it more like a road system.

20
00:01:51,320 --> 00:02:00,820
So, we have our users and our servers, and we have the resources, our data, our buckets, our databases, and all of those are destinations.

21
00:02:01,500 --> 00:02:07,780
And IAM, or privileges that are described in IAM, are like the roads between those entities.

22
00:02:08,600 --> 00:02:11,800
So, usually when you start out, you don't need a road planner.

23
00:02:11,800 --> 00:02:16,920
You have maybe two or three employees, and you set up maybe a server.

24
00:02:16,920 --> 00:02:18,620
That server serves your app.

25
00:02:18,620 --> 00:02:20,480
It can be behind a load balancer.

26
00:02:20,820 --> 00:02:22,020
It's pretty simple stuff.

27
00:02:22,020 --> 00:02:27,200
You won't need more than maybe two or three roles and top four or five users.

28
00:02:27,200 --> 00:02:31,260
But we don't use the cloud for this simple infrastructure.

29
00:02:31,260 --> 00:02:36,920
We use the cloud because it allows us to grow and scale and use more and more services.

30
00:02:37,180 --> 00:02:41,780
And sooner rather than later, you'll find yourself stuck in this kind of situation.

31
00:02:41,780 --> 00:02:53,480
You'll be adding more services, RDS, ECS, CloudFormation, CloudFront, more and more services, and all of those require different roles and different users.

32
00:02:53,580 --> 00:02:56,940
Some of them are maybe even third-party tools.

33
00:02:56,940 --> 00:02:59,740
And you also have different access patterns.

34
00:02:59,740 --> 00:03:12,280
You can start out by everybody using their own IAM users and then switch out to maybe using SSO and identity providers, which mean you have roles and not set of credentials.

35
00:03:12,280 --> 00:03:21,700
And all of that leaves layer over layer of unused and unnecessary privileges, which can be used by bad actors.

36
00:03:22,280 --> 00:03:30,900
Now, as a security person, which is kind of what I do, when I see IAM, I have only one question I really want to answer.

37
00:03:30,900 --> 00:03:33,560
And that is, who has access to what?

38
00:03:34,400 --> 00:03:45,320
It should be pretty simple, but I will now show you why it isn't that simple, specifically in AWS IAM, but that happens also in GCP, Azure, and other cloud providers.

39
00:03:45,900 --> 00:03:49,040
So let's start out with a simple question.

40
00:03:49,080 --> 00:03:53,720
Who has admin access, which is full access, to my AWS account?

41
00:03:54,280 --> 00:04:04,540
When I asked this question in the beginning, naturally I went to the administrator access, which is a managed AWS policy, and I tried to understand who has access to that policy.

42
00:04:04,540 --> 00:04:06,580
Who has that policy attached?

43
00:04:06,720 --> 00:04:09,520
So you can see here, this is an example account.

44
00:04:09,520 --> 00:04:14,820
We have two roles, which have admin access to the account, and also a group.

45
00:04:15,000 --> 00:04:21,400
Now, the group in itself is not any user or role, but we would like to know who is part of that group.

46
00:04:21,400 --> 00:04:28,160
So I clicked on the group, and now I see the group has 11 users, all of them have admin access to the account.

47
00:04:28,880 --> 00:04:35,520
The problem with IAM in AWS is that this isn't a complete list of all the admins in the account.

48
00:04:36,260 --> 00:04:37,800
And the reason is simple.

49
00:04:37,960 --> 00:04:46,760
IAM allows you to create your own policy documents, which are simple JSONs, in which you describe what you allow and deny for each entity.

50
00:04:46,760 --> 00:04:49,440
It could be a role, it could be a user, it could be a group.

51
00:04:49,900 --> 00:04:58,520
So this is an example of an inline policy, which means it's a policy for one specific role, which allows all actions on all resources.

52
00:04:58,560 --> 00:05:01,140
Well, that's what I would call an admin.

53
00:05:01,260 --> 00:05:02,900
And this isn't listed anywhere.

54
00:05:02,900 --> 00:05:04,200
It won't show up anywhere.

55
00:05:04,200 --> 00:05:11,300
You'll have to go entity by entity, policy document by policy document to find these entities.

56
00:05:12,420 --> 00:05:16,380
So this example shows us two problems we have with IAM.

57
00:05:16,400 --> 00:05:18,760
One is that it is easily bypassed.

58
00:05:18,760 --> 00:05:25,440
You can just create your own policy, it won't be listed anywhere, no one will know, and you can give any permission you'd like.

59
00:05:25,720 --> 00:05:29,360
The second one is that IAM supports complex relationships.

60
00:05:29,360 --> 00:05:30,620
Let's say you have a user.

61
00:05:30,620 --> 00:05:34,840
You can attach a managed policy to it, or you can put an inline policy.

62
00:05:34,880 --> 00:05:38,380
But as we've just seen, you can also do that using a group, right?

63
00:05:38,380 --> 00:05:44,140
You can have the user be a part of a group, and that group will have the policies attached or put on.

64
00:05:44,440 --> 00:05:46,840
But that's not all that IAM supports.

65
00:05:46,840 --> 00:05:49,680
IAM supports assuming role as well.

66
00:05:49,740 --> 00:05:57,560
So that means a user can assume a role and get the policies that are set on that role, or assume through that role another role.

67
00:05:57,560 --> 00:06:07,180
And that's a long chain of privilege excavation that you won't be able to see using simple console and going through the entities in IAM.

68
00:06:08,040 --> 00:06:09,640
But that's not all.

69
00:06:09,640 --> 00:06:14,660
Let's take a look at another example and see two other things we can find in IAM.

70
00:06:14,820 --> 00:06:19,320
So this is a list of the 11 admins from the admin group we've seen before.

71
00:06:19,600 --> 00:06:24,980
If we look at them, we'll see that 10 of them have access keys which are older than 90 days.

72
00:06:25,440 --> 00:06:33,580
So best practice is to rotate your keys every 90 days since these are static credentials that if discovered, they can be used to abuse the account.

73
00:06:34,620 --> 00:06:40,720
We can also see that four of these users have passwords and no MFA set.

74
00:06:40,720 --> 00:06:44,420
Now you might notice that most of them do not have password access.

75
00:06:44,420 --> 00:06:47,980
That's because we've moved over to using SSO.

76
00:06:48,060 --> 00:06:54,040
And these four users unfortunately did not do what was required of them, or they've been handled since then.

77
00:06:54,040 --> 00:07:01,260
But they do pose brute force risk to the account just by having passwords with no MFA.

78
00:07:01,600 --> 00:07:08,580
And if that's not enough, we also see that two users have not been used for more than half a year, more than 200 days.

79
00:07:08,580 --> 00:07:18,220
There's really no reason to keep live access keys that have such a high level of access to the account without them being used at all.

80
00:07:18,400 --> 00:07:21,120
So this example shows us two things.

81
00:07:21,120 --> 00:07:24,280
One is that it's difficult to enforce patterns over time.

82
00:07:24,280 --> 00:07:36,080
You have to manually go through the user list and find the, I would say, the people who are out of line or the resources that are misconfigured.

83
00:07:36,080 --> 00:07:38,480
But it's also hard to trace and verify usage.

84
00:07:38,480 --> 00:07:46,880
It could be that a person was using this account a lot for a year and has since stopped, but we won't know it unless we check.

85
00:07:46,880 --> 00:07:51,540
And we have to check it per user, per role, per entity in IAM.

86
00:07:53,160 --> 00:08:03,460
So we have all of these problems which cause layer and layer of garbage and stuff that's left behind and waiting to be now used.

87
00:08:03,480 --> 00:08:06,160
And we were wondering how we can do it.

88
00:08:06,160 --> 00:08:09,940
So what I developed is called Air IAM.

89
00:08:09,940 --> 00:08:11,300
It's completely open source.

90
00:08:11,300 --> 00:08:12,600
You can check out the link.

91
00:08:12,600 --> 00:08:14,780
I'll share it later too.

92
00:08:14,780 --> 00:08:18,140
And what it does is distribute IAM through Terraform.

93
00:08:18,140 --> 00:08:21,960
It creates Terraform code from your existing IAM.

94
00:08:21,960 --> 00:08:24,960
Let's walk through and see what it does.

95
00:08:25,560 --> 00:08:34,040
So before we created the open source, obviously, we had to do a few manual iterations to see what works and what doesn't.

96
00:08:34,040 --> 00:08:40,160
And we came to this flow of conclusions and actions.

97
00:08:40,260 --> 00:08:51,640
So at first we would like to collect all the IAM entities from the account and their usage using AWS APIs, maybe CloudTrail data and so forth.

98
00:08:51,700 --> 00:08:59,080
And then for each entity cross-reference it with its usage and decide whether the entity is in use or not.

99
00:08:59,080 --> 00:09:05,080
Whether the entity is in use or not is a question that depends on the threshold for usage.

100
00:09:05,080 --> 00:09:08,580
I would say the default best practice is 90 days.

101
00:09:08,580 --> 00:09:12,320
I've seen it go down to 30 or up to 365 days.

102
00:09:12,320 --> 00:09:14,380
So it really depends on your preference.

103
00:09:14,660 --> 00:09:17,120
Once we've decided what's not used, it's easy.

104
00:09:17,120 --> 00:09:18,500
We can mark it for division.

105
00:09:18,560 --> 00:09:22,340
And we will need to go through the permissions that are in use.

106
00:09:22,780 --> 00:09:40,540
So we will have to go through the entities and look at their permissions, look at what they've actually used using Access Analyzer or CloudTrail and create, I would say, a minimized version of the policies that they have based only on stuff that they use,

107
00:09:40,540 --> 00:09:46,940
meaning we won't be able to impair any workloads, not dev, not production, not anything.

108
00:09:46,940 --> 00:09:49,820
If it is in use, we're leaving it as is.

109
00:09:49,960 --> 00:09:53,120
The third one is to create a recommendation.

110
00:09:53,220 --> 00:10:05,660
That usually included a very large workbook with a few sheets in it that describes what we want to do for each entity with a few different, I would say, categories.

111
00:10:05,920 --> 00:10:17,500
And after we've done that, we'll take that to the relevant account stakeholder or the person who actually uses the account and knows the types of usage in the account.

112
00:10:17,500 --> 00:10:22,760
For approval, that might seem like a pretty long process.

113
00:10:22,760 --> 00:10:25,880
You actually won't understand how long it is.

114
00:10:25,880 --> 00:10:29,340
I've added some time estimations to the different steps.

115
00:10:29,340 --> 00:10:36,500
I would say the most difficult part is to create a recommendation and then get the approval from the relevant stakeholders.

116
00:10:36,640 --> 00:10:46,180
I've seen it take weeks and it's just a lot of misunderstanding and meetings and getting formal approval.

117
00:10:46,240 --> 00:10:53,240
And then I found out that even implementing the changes after I have the action items and I have the approval, it takes me a while.

118
00:10:53,240 --> 00:10:56,480
An hour is for a medium-sized account.

119
00:10:56,480 --> 00:10:58,780
It could take a lot longer for bigger accounts.

120
00:11:00,260 --> 00:11:11,960
So after iterating through this a few times and making sure that we understand what we need, we decided, like we do in many other fields here at Bridgecrew, that we want to automate it.

121
00:11:12,380 --> 00:11:23,100
When we wanted to build the automation, we decided that we have four main, I would say, goals we wanted to reach through the automation tool.

122
00:11:23,100 --> 00:11:28,440
So the first one is that we want to identify unused entities and easily remove them.

123
00:11:28,600 --> 00:11:32,380
When I say unused entities, I also mean unused policy attachments.

124
00:11:32,380 --> 00:11:39,100
So that means policies that are not in use at all by the role or user or group that has that policy attached.

125
00:11:39,100 --> 00:11:41,060
I want to also remove that.

126
00:11:41,500 --> 00:11:44,620
We want to be able to detect drifts and enable rollback.

127
00:11:44,620 --> 00:11:47,840
Let's say I made some modification and it caused downtime.

128
00:11:47,840 --> 00:11:50,260
For some reason, something went wrong.

129
00:11:50,260 --> 00:11:54,380
I can always roll back and make sure everything works.

130
00:11:54,960 --> 00:11:58,680
I want to be able to handle scales of thousands of entities.

131
00:11:58,680 --> 00:12:04,700
Again, when I say entities, also the relationships between the users and the policies and the roles and the groups.

132
00:12:04,700 --> 00:12:09,220
So it very easily reaches the 1,000, 2,000 threshold on big accounts.

133
00:12:09,640 --> 00:12:18,080
And then the fourth one, which is very important, is to be able to take the plan to get approval from the relevant stakeholders.

134
00:12:18,080 --> 00:12:24,260
But I want something that I can share and people will easily understand and either say that's fine or not.

135
00:12:25,640 --> 00:12:29,160
So the tool itself, ARIAM, is pretty easy.

136
00:12:29,160 --> 00:12:49,560
All it does is collect data from AWS APIs, both IAM and Access Advisor, cross-references it and either outputs it as CLI output for your convenience or Terraform code, which we'll see in a bit how that, I would say, leverages the power to the maximum.

137
00:12:50,840 --> 00:12:53,600
So let's start talking about the tool.

138
00:12:54,560 --> 00:12:57,600
ARIAM contains three commands built in.

139
00:12:57,600 --> 00:13:00,060
The first one is called Find Unused.

140
00:13:00,060 --> 00:13:07,000
What it does is collect all of the data from the APIs and decides whether the entity is used or not.

141
00:13:07,000 --> 00:13:09,960
The default setting is 90 days.

142
00:13:09,980 --> 00:13:12,520
Let's do a short demo and see how it works.

143
00:13:13,620 --> 00:13:14,660
Great.

144
00:13:14,980 --> 00:13:20,760
So I've already installed ARIAM on this computer, although it is very easy to install.

145
00:13:20,760 --> 00:13:24,780
And I can just run ARIAM Find Unused.

146
00:13:26,080 --> 00:13:29,660
So it now gets all the IAM configurations for the account.

147
00:13:29,660 --> 00:13:33,580
It will then collect the usage for all the users and the roles in the account.

148
00:13:33,580 --> 00:13:38,140
And right after that, it will output all the findings.

149
00:13:38,580 --> 00:13:39,400
Awesome.

150
00:13:39,400 --> 00:13:47,900
So you can see it's generating the reports, editing it, and now it will start outputting the unused entities that it found in the account.

151
00:13:48,000 --> 00:13:52,120
So as you can see, we have here four users who have not been used.

152
00:13:52,120 --> 00:13:54,920
It says last used 365 days ago.

153
00:13:54,920 --> 00:13:59,400
That's the maximum that AWS promises that there was no usage in.

154
00:14:00,280 --> 00:14:04,420
We can also see there's one active access key that isn't being used.

155
00:14:04,580 --> 00:14:09,260
You'll notice that it's for a user that's not listed under the unused users.

156
00:14:09,480 --> 00:14:12,620
So ARIAM does not give you duplicate results.

157
00:14:12,620 --> 00:14:19,280
If the user is unused, it won't say that its access keys are unused, although he might have access keys that are unused.

158
00:14:20,180 --> 00:14:21,180
Sorry.

159
00:14:21,400 --> 00:14:30,420
We also have one user, that's my user, which has password access to the console with MFA, but hasn't used it for over 100 days.

160
00:14:31,100 --> 00:14:33,720
If it doesn't have MFA, it will say it here.

161
00:14:33,720 --> 00:14:38,340
So you'll be able to understand who is, I would say, the bigger problem.

162
00:14:38,660 --> 00:14:42,000
We also have four roles which are unused.

163
00:14:42,000 --> 00:14:46,460
Those are roles that haven't been used for, I'd say, over 100 days.

164
00:14:46,460 --> 00:14:47,260
Yes.

165
00:14:47,360 --> 00:14:49,640
We have two groups which are redundant.

166
00:14:49,800 --> 00:14:57,480
One of them has no members, which means it's just laying there and it's a security hazard because, let's say, it does have any policies attached.

167
00:14:57,480 --> 00:15:02,400
If you attach a user to it, it will automatically gain all those permissions.

168
00:15:02,560 --> 00:15:08,320
So even it's just leaving behind privileges that maybe an attacker can utilize.

169
00:15:08,420 --> 00:15:10,540
And then group without policies.

170
00:15:10,540 --> 00:15:13,400
Groups can have members but have no policies attached.

171
00:15:13,400 --> 00:15:22,700
And since a group is not an entity that can be used in AWS, just groups' privileges, there's no point in having those groups.

172
00:15:23,200 --> 00:15:30,600
And since we want to make AWS IAM as manageable as possible, it also recommends deleting those kinds of groups.

173
00:15:31,000 --> 00:15:36,420
We have a redundant policy that's a policy that's not attached to any user, group, or role.

174
00:15:36,420 --> 00:15:40,340
It's just clutter that's being left behind in the account.

175
00:15:40,340 --> 00:15:42,640
And we also have two policy attachments.

176
00:15:42,640 --> 00:15:46,800
For policies that are unused by the relevant principle.

177
00:15:46,800 --> 00:15:53,540
So this user, S3User1, is not using any privileges given to him by Amazon API Gateway Administrator.

178
00:15:53,540 --> 00:16:03,500
But he does have that privilege given to him, which can cause him to make actions which he shouldn't, such as creating or even deleting existing API gateways.

179
00:16:04,680 --> 00:16:05,880
Great.

180
00:16:07,020 --> 00:16:10,720
So I hope we've got all of that clear.

181
00:16:10,720 --> 00:16:19,400
And this helps us actually create some of the permissions baseline, since it allows us to remove attachments of policies that are unused but given.

182
00:16:19,400 --> 00:16:23,520
And create more of a list privilege model for our IAM.

183
00:16:23,620 --> 00:16:26,360
The second command is called recommend groups.

184
00:16:26,360 --> 00:16:41,680
What it does is try to look through the users that you have in the account, group them according to their relevant privileges, and actually create recommendations for three types of groups currently.

185
00:16:41,680 --> 00:16:44,760
One is the admins group, which are active admins.

186
00:16:44,760 --> 00:16:51,000
The second one is power users, which are for users who have write access to the account but not admin access.

187
00:16:51,160 --> 00:16:53,460
And the third one is the read-only group.

188
00:16:53,460 --> 00:16:58,980
That's relevant for all the users who have read access to the account but don't have any write access.

189
00:17:00,200 --> 00:17:11,240
This command helps us finalize the permissions baseline or the changes we want to... the things that are in use and create the recommendation, what we want the account to look like in the end.

190
00:17:12,000 --> 00:17:14,440
So let's see that as well.

191
00:17:15,800 --> 00:17:21,710
I'll hit ARIM, recommend groups.

192
00:17:23,420 --> 00:17:24,540
Awesome.

193
00:17:24,540 --> 00:17:27,940
So in this account, we have two active users.

194
00:17:27,940 --> 00:17:31,700
One is my user, which is an admin and requires admin access.

195
00:17:31,700 --> 00:17:36,400
And also this S3 user one, which has write access to S3.

196
00:17:36,400 --> 00:17:40,920
We don't have any read users in this account, so it doesn't offer me the read-only.

197
00:17:40,920 --> 00:17:46,480
There's no point in creating empty groups as we've talked before, but if there were any, it would show them here.

198
00:17:48,800 --> 00:17:52,140
So we have the recommendation, it's just not actionable yet.

199
00:17:52,140 --> 00:17:58,320
We have everything we want to do, but we can't show it to anyone and we can't just hit play and make that work.

200
00:17:58,580 --> 00:18:00,840
That's where the third command comes in.

201
00:18:00,840 --> 00:18:02,440
It's called ARIM Terraform.

202
00:18:02,440 --> 00:18:05,540
And what it does is create Terraform code and state file.

203
00:18:05,760 --> 00:18:13,140
I'll show you how it works and we'll talk a bit about Terraform so you understand all the power that this command brings with this.

204
00:18:14,160 --> 00:18:28,280
So, I'll type in ARIM Terraform and what it does is it will initialize Terraform, it will create Terraform files for me, and then it will import the existing Terraform entities into the local state file.

205
00:18:28,280 --> 00:18:29,800
Let's see how that looks.

206
00:18:30,120 --> 00:18:36,840
So I'll change to the results there and you'll see that it created just now.

207
00:18:36,840 --> 00:18:38,720
This is in my time zone.

208
00:18:38,960 --> 00:18:45,820
It created the .terraform directory, which includes all the files that are necessary by Terraform to run.

209
00:18:45,820 --> 00:18:48,560
This is a temporary file, so you can ignore it.

210
00:18:48,560 --> 00:18:56,440
It creates .tf files that define all the different entities and their relationships using Terraform HCL code.

211
00:18:56,440 --> 00:19:05,600
It also creates a state file and the backup, which again, you don't need to care about because it is only temporary and for system usage.

212
00:19:05,600 --> 00:19:08,340
Let's take a look at groups.tf.

213
00:19:09,080 --> 00:19:18,140
So, what this shows you is the four groups that we have in the account and the policies that they have attached, if any.

214
00:19:18,140 --> 00:19:23,720
So, for example, we have the admins group and the admins group has administrator access attached to it.

215
00:19:23,720 --> 00:19:30,560
We have a group without members and that group has two policies attached, the RDS full access and the user change password.

216
00:19:30,560 --> 00:19:39,140
We also have a group without policies, which has no policies attached, and the S3 group, which has the Amazon S3 full access.

217
00:19:39,700 --> 00:19:48,340
Just so we can see it for real, I've opened the console for it and this is the groups in the account.

218
00:19:48,340 --> 00:19:59,420
You'll see these are exactly the four groups we have and you can see that the group without policies actually does not have policies and the group without members has these two permissions.

219
00:20:01,460 --> 00:20:04,460
So, the same goes for roles.

220
00:20:04,460 --> 00:20:07,260
Let's see the roles file, for example.

221
00:20:07,420 --> 00:20:10,840
So, for every role, we'll have the role itself.

222
00:20:10,840 --> 00:20:19,380
We'll also have the assume role policy document and if it has any policy attachments, such as this one, it will be listed as well.

223
00:20:19,380 --> 00:20:24,820
You'll notice that the syntax is not using any hard-coded strings.

224
00:20:24,820 --> 00:20:31,900
Basically, ARN creates the entities and connects them so you can actually see who has access to what.

225
00:20:32,840 --> 00:20:33,960
Awesome.

226
00:20:34,120 --> 00:20:35,580
So, that's all the code.

227
00:20:35,580 --> 00:20:37,420
Let's take a look at the state file.

228
00:20:37,960 --> 00:20:51,400
So, the way Terraform works is it creates both the code and the state file and the state file describes what connects the entities that were defined in code with the actual ARNs in the cloud environment.

229
00:20:51,420 --> 00:21:00,900
So, for example, we have here the AWS IAM group admins as we've seen it in the code and that's connected to this instance with this ARN.

230
00:21:01,160 --> 00:21:06,200
So, if I copy it and I go to admins, that's exactly the ARN of the group.

231
00:21:06,240 --> 00:21:24,060
So, that means this code describes this group and when I will run Terraform apply or Terraform destroy or Terraform plan, it will go and check what's configured in the code and what's configured in the state file and fix the differences.

232
00:21:24,060 --> 00:21:34,780
So, if it needs to delete or create or modify anything that's been described in the code and is not as is in the console, in the actual account, it will be fixed.

233
00:21:36,640 --> 00:21:37,680
Awesome.

234
00:21:38,080 --> 00:21:48,120
So, once I've created this, I can actually create the Terraform code, if you'd like, without the import stage which takes a while.

235
00:21:49,840 --> 00:22:00,340
So, this is what it does and if I type ls-la, you'll see that everything has updated except, well, it just finished now.

236
00:22:00,380 --> 00:22:04,900
So, if I run it again, you'll see that everything will change except the state file.

237
00:22:04,960 --> 00:22:05,980
See that?

238
00:22:06,020 --> 00:22:06,640
Awesome.

239
00:22:06,640 --> 00:22:10,540
So, the state file did not change, but all the tf files got updated.

240
00:22:11,580 --> 00:22:24,340
So, if I go into the results and type Terraform plan, you'll see that all the differences that it wants to do is unrelated to actual entity modifications.

241
00:22:24,400 --> 00:22:29,620
This Terraform code describes the actual entities almost one-to-one.

242
00:22:29,620 --> 00:22:33,220
You see it has a force destroy flag added to the users.

243
00:22:33,220 --> 00:22:42,800
That's so when you select to destroy a user, it will actually go and destroy, including the access keys, the password access, everything.

244
00:22:43,160 --> 00:22:48,600
So, I'll run Terraform apply just to make sure we don't have any differences.

245
00:22:48,600 --> 00:22:50,860
You'll see it takes a few seconds.

246
00:22:51,660 --> 00:22:58,360
And then we have the Terraform output form and the actual account exactly in line.

247
00:22:58,360 --> 00:22:59,340
Hold on.

248
00:22:59,340 --> 00:23:00,840
I don't want to break it.

249
00:23:00,840 --> 00:23:01,700
Yes.

250
00:23:02,460 --> 00:23:03,540
Awesome.

251
00:23:03,540 --> 00:23:08,200
So, now let's say I want to delete all the unused entities that I've just found.

252
00:23:08,400 --> 00:23:20,180
Instead of going through and deleting one-by-one the policies and the groups and the users and the roles, I can just type here minus minus without unused.

253
00:23:23,830 --> 00:23:24,470
Great.

254
00:23:24,470 --> 00:23:26,610
So, now it created the Terraform files.

255
00:23:26,610 --> 00:23:37,010
But if we'll take a look, for example, at groups.tf, you'll see that we only have two groups now, which are the two groups that both have users and have policies attached.

256
00:23:37,770 --> 00:23:39,450
Pretty simple.

257
00:23:39,650 --> 00:23:47,730
Now, when I run Terraform plan again, you'll see that it offers to delete everything for me.

258
00:23:47,730 --> 00:23:52,350
And it will be much higher than five or ten entities.

259
00:23:52,350 --> 00:24:01,190
It actually plans to destroy 40 through users, roles, policies, and all the relationships between them .

260
00:24:01,190 --> 00:24:04,830
And it will take just a few seconds and the Terraform will apply.

261
00:24:04,830 --> 00:24:06,510
That's all you need.

262
00:24:07,050 --> 00:24:08,150
Pretty slick.

263
00:24:10,150 --> 00:24:11,350
Awesome.

264
00:24:12,910 --> 00:24:17,430
So, we've created a recommendation that's very actionable.

265
00:24:17,430 --> 00:24:19,570
I can take it and apply it.

266
00:24:19,570 --> 00:24:23,650
But I don't have any way to show it and get approval for it.

267
00:24:23,710 --> 00:24:28,310
But another very powerful plus side of using Terraform is that it's code.

268
00:24:28,310 --> 00:24:31,910
And for code, we have version control systems.

269
00:24:31,910 --> 00:24:34,930
I like GitHub, so these are print screens from GitHub.

270
00:24:35,190 --> 00:24:49,730
But basically, what you can do is commit the Terraform code that is outputted by default with everything to a master branch, check out a new branch, run it without unused, for example, and open a PR.

271
00:24:49,730 --> 00:25:05,130
And that PR talks in a very simple language that developers can understand, even less technical guys can understand that if there's a group here that's called group without members and has a minus in front of it, it will probably get deleted.

272
00:25:05,310 --> 00:25:18,910
So you can use that to actually have all the conversation around getting approval and making everything, I would say, approved or agreed upon.

273
00:25:18,950 --> 00:25:23,730
And then, again, just a simple Terraform apply will make all those changes for you.

274
00:25:25,190 --> 00:25:27,250
So that completes our entire flow.

275
00:25:27,870 --> 00:25:39,330
Although we have three commands to help crunch through all the data and understand the phases, in general, you can just run directly RIM Terraform, it will do all the work for you.

276
00:25:39,330 --> 00:25:52,830
It will find all the unused entities, it will import them into Terraform, and you'll be able to actually run it again without unused or with unused, run Terraform apply, everything will be in your hands.

277
00:25:54,210 --> 00:25:56,550
Now, you've run it once, that's great.

278
00:25:56,550 --> 00:26:00,790
You have your IAM set up clean and sparkling and beautiful.

279
00:26:00,970 --> 00:26:12,010
But the problem with the cloud is that well, it's both a plus and a minus, I would say, is that people can manually change and make modifications.

280
00:26:12,730 --> 00:26:22,930
Now, using RIM on a weekly basis, monthly basis, on a regular basis, you'll be able to scan your IAM and identify drifts in existing configurations.

281
00:26:22,930 --> 00:26:36,370
That means if there were any modifications or deletions, you'll be able to find those things in code and actually automatically update your Terraform state and your Terraform code.

282
00:26:36,370 --> 00:26:39,770
You'll also be able to identify changes in usage status.

283
00:26:39,770 --> 00:26:43,650
So we've seen the problem where we had admins who have been unused for a long time.

284
00:26:43,650 --> 00:26:56,110
If you scan on a regular basis, it will by itself find entities that have been unused for 90 days or if you modify your threshold by your threshold and mark them for deletion and recommend you delete them.

285
00:26:56,570 --> 00:26:59,210
It will also help you identify new configurations.

286
00:26:59,210 --> 00:27:09,250
So let's say you have a new team or you have a new service or you even started a new Lambda and you created a role for it, that role will automatically be integrated into your Terraform.

287
00:27:09,250 --> 00:27:19,290
It will be imported into your state file and you can add it to your repository where you will still have it managed and you'll be able to see it.

288
00:27:19,330 --> 00:27:22,650
And nothing will go without knowledge.

289
00:27:23,430 --> 00:27:31,930
And then the last thing that ARAM and Terraform enable to you is to use static analysis tools to identify bad practices.

290
00:27:32,210 --> 00:27:50,030
So I would like to take this to the next slide actually which shows, I would say, two really great tools that will help you use infrastructure as code and static analysis for your permissions in your IAM.

291
00:27:50,150 --> 00:27:52,010
So the first one is called Chekhov.

292
00:27:52,010 --> 00:27:56,390
It's also pretty easy to install and I already have it set up here.

293
00:27:56,890 --> 00:28:01,490
So Chekhov, what it does is identify bad practices in Terraform.

294
00:28:01,710 --> 00:28:03,690
So if I run... let's see...

295
00:28:04,530 --> 00:28:07,130
the last thing I did was without the unused right?

296
00:28:07,130 --> 00:28:10,650
So I want to do it one second with everything.

297
00:28:10,950 --> 00:28:14,790
So right now I created Terraform for the existing IAM setup.

298
00:28:14,950 --> 00:28:20,230
And if I go to the results tab, I can just run Chekhov minus the results.

299
00:28:20,270 --> 00:28:25,590
This will make Chekhov scan all the Terraform files that are in the results directory.

300
00:28:25,850 --> 00:28:30,530
And we'll see in a few seconds that it has quite a lot of findings.

301
00:28:30,730 --> 00:28:34,310
So if I scroll up, yes, quite a lot indeed.

302
00:28:34,310 --> 00:28:39,690
So it found, it ran 56 checks and 23 of them failed.

303
00:28:39,690 --> 00:28:51,150
This includes misconfigured admins and bad assumer role policies and policies that are attached directly to users as this would require justification.

304
00:28:51,150 --> 00:28:53,950
Otherwise, it is really recommended to use groups.

305
00:28:54,450 --> 00:29:00,030
Let's say I ran it without the unused, just for checking what that would mean.

306
00:29:00,030 --> 00:29:06,810
By deleting all the unused entities and running Chekhov again, I will see how much cleaner the account is.

307
00:29:06,810 --> 00:29:08,130
And the account is a lot cleaner.

308
00:29:08,130 --> 00:29:14,190
So we only have two failed checks and both of them can be either justified or fixed.

309
00:29:14,450 --> 00:29:19,130
And all in all, we only have 11 checks that were scanned.

310
00:29:19,130 --> 00:29:24,690
That means a lot of the overhead was cleaned simply by deleting unused stuff.

311
00:29:26,130 --> 00:29:27,330
Awesome.

312
00:29:28,290 --> 00:29:31,410
Another really cool tool is PolicySentry.

313
00:29:31,410 --> 00:29:40,770
PolicySentry allows you to build IAM policies from scratch using YAML syntax and easy, simple CRUD syntax.

314
00:29:40,770 --> 00:29:48,070
So you have create, read and update and delete syntax for different resources and different services.

315
00:29:48,070 --> 00:29:55,250
And that creates an IAM policy that's probably better than what your average developer would create.

316
00:29:56,190 --> 00:30:03,330
If you're talking about scanning your existing configurations, I also have a few tools up my sleeve.

317
00:30:03,330 --> 00:30:11,550
So the first one, I would say the category is finer and more granular disk privilege for IAM.

318
00:30:11,550 --> 00:30:16,410
We have CloudTracker by Geolabs and Ardvark plus RepoKid by Netflix.

319
00:30:16,630 --> 00:30:33,510
They both use CloudTrail data, so you need to have CloudTrail read access to analyze the policies and mark specific privileges and break down all the stars and the jokers in your policy to understand what you're giving that isn't really in use.

320
00:30:33,510 --> 00:30:38,230
I would say that CloudTrail visibility or coverage is not 100%.

321
00:30:38,230 --> 00:30:43,130
Not all actions are by default recorded in CloudTrail.

322
00:30:43,130 --> 00:30:47,310
And so using CloudTrail comes with a...

323
00:30:47,310 --> 00:30:51,370
maybe you should take it suspiciously.

324
00:30:51,730 --> 00:30:55,750
Another really cool tool that I'd like to show is called CloudSplaining.

325
00:30:55,750 --> 00:31:01,530
CloudSplaining is another tool by Salesforce that identifies possible risks in your IAM configurations.

326
00:31:01,530 --> 00:31:07,650
So it has four different classes, privilege escalation, data exfiltration, other stuff.

327
00:31:07,650 --> 00:31:09,950
Let me show you real quick.

328
00:31:10,270 --> 00:31:12,410
So I run CloudSplaining.

329
00:31:12,410 --> 00:31:15,410
It's a very simple setup again.

330
00:31:15,750 --> 00:31:27,090
So what it does is it scans all of the policies that are in the account and it outputs a very detailed and rich report about all of the stuff that you can find in your account.

331
00:31:27,090 --> 00:31:38,850
You can actually go by the policies or by the principles, which is what I prefer, and just take a look, for example, who has access to infrastructure modification.

332
00:31:38,990 --> 00:31:47,290
So say the misconfigured admin user has... well, since he's a misconfigured admin user, he has all the bad stuff that he can.

333
00:31:47,290 --> 00:31:57,330
If we'll take a look at the misconfigured IAM user, you'll see that he has this very bad policy, which we've talked about.

334
00:31:57,330 --> 00:31:59,530
It allows everything on everything.

335
00:32:00,430 --> 00:32:09,410
So it shows that he can do a lot of infrastructure modifications, do privilege escalation, do resource exposure, and data exfiltration.

336
00:32:10,030 --> 00:32:16,290
You can actually go through this by risk and start diving deeper into that.

337
00:32:18,410 --> 00:32:23,930
And then the final tool I'd like to show you is called PrincipleMapper or PMapper.

338
00:32:23,930 --> 00:32:25,450
It's by NCC Group.

339
00:32:25,450 --> 00:32:29,570
It helps identify possible privilege escalations in the account.

340
00:32:29,570 --> 00:32:40,130
So if you remember, we had the graph where a user can assume a role and that role can assume another role and each role has its own privilege, I would say policy context of policies.

341
00:32:40,690 --> 00:32:42,750
So this tool creates a graph.

342
00:32:42,850 --> 00:32:44,370
You see it here.

343
00:32:44,470 --> 00:32:47,570
An example, it's a very partial graph.

344
00:32:47,570 --> 00:32:52,650
It has these two roles and this user, for example, can assume this role.

345
00:32:52,810 --> 00:33:02,050
And so the user, which is called EC2 Manager, can assume the role and gain all the privileges that are attached to EC2 role for SSM.

346
00:33:02,170 --> 00:33:13,430
And this allows you to map all the different roles and maybe if you identify a role that is super powerful, check who can assume it and make sure that that's in check.

347
00:33:15,830 --> 00:33:19,390
Yep, that's it for the slideshow.

348
00:33:20,650 --> 00:33:21,970
All right.

349
00:33:22,790 --> 00:33:37,890
I guess to start off with one question for me, I'm assuming that if you wanted to make a change, a specific change instead of the whole IAM recommendation made by AIR IAM, you would just go ahead and edit the Terraform file, right?

350
00:33:37,890 --> 00:33:48,150
And so are there any specific config files within AIR IAM that you can use to specify what to detect and what to ignore or anything like that?

351
00:33:48,150 --> 00:33:58,050
So Terraform itself allows you to maybe, I would say, create or modify or destroy anything you'd like within the code and the state file.

352
00:33:58,050 --> 00:34:00,490
So AIR IAM gives you all of the changes you'd like.

353
00:34:00,490 --> 00:34:12,530
You can run Terraform apply as I did in the slideshow, but you can also specify a specific target, be it a user, a group, or a policy, and Terraform will modify only that part of the findings.

354
00:34:12,970 --> 00:34:13,990
Got it.

355
00:34:14,070 --> 00:34:23,490
And then another one, do you plan on bringing any of these features to GCP or Azure, something along those lines?

356
00:34:23,670 --> 00:34:24,350
Definitely.

357
00:34:24,350 --> 00:34:27,810
So that's something that we've heard before.

358
00:34:27,810 --> 00:34:30,390
We are planning to do this.

359
00:34:30,390 --> 00:34:43,770
It requires a complete different set of, I would say, you need to use the other SDKs and it will require more knowledge because GCP IAM is not exactly like AWS IAM.

360
00:34:43,770 --> 00:34:52,270
It has a lot more of privileges given by the resources and not the principles, but we are definitely planning to go in that direction.

361
00:34:52,270 --> 00:34:53,230
Got it.

362
00:34:53,990 --> 00:34:56,830
Another question from Artemis in chat.

363
00:34:56,830 --> 00:35:00,750
How well do these tools work in a multi-account environment?

364
00:35:01,050 --> 00:35:02,850
That's a great question.

365
00:35:02,850 --> 00:35:08,810
So I would start out by saying that IAM permissions are limited to the account.

366
00:35:08,830 --> 00:35:16,110
You can give cross-account permissions, but that would be from one account you give the other account permissions.

367
00:35:16,170 --> 00:35:22,190
So the context of every, I would say, analysis is a specific AWS account.

368
00:35:22,190 --> 00:35:26,790
So you can use ARAM using all the default AWS credentials tools.

369
00:35:26,790 --> 00:35:30,470
You can use the profile and specify the minus minus profile flag.

370
00:35:30,470 --> 00:35:39,830
You can use AWS environment variables to scan different accounts, but every ARAM scan is limited to the context of one account since that is the context of IAM.