start	end	text
980	3960	I'm Nimrod. I'm a solution architect at BridgeCrew.
3960	7880	And over the next 35 minutes or so, I'd love to walk you through
7880	11100	how you can utilize open source to do least privilege
11100	14260	using infrastructure as code. Sorry.
15480	19300	So, a bit about me. I'm a solution architect at BridgeCrew.
19300	22000	BridgeCrew is a cloud security company that helps identify
22000	24940	misconfigurations in both real cloud environments
24940	29060	and infrastructure as code frameworks, such as Terraform, CloudFormation, etc.
29060	32200	And we're doing all of this using grid automation.
32380	35180	As part of my role in BridgeCrew, I'm involved with a few
35180	38720	open source projects around AWS and Terraform,
38720	41440	and security, which I either co-maintain
41440	43940	or contribute to continuously.
44180	48080	And my newest open source tool is called AirIAM,
48080	51300	which I hope at the end of this talk you'll also be a fan of.
52220	53700	Let's dive in.
54820	57320	So, just a quick overview.
57320	60820	AWS AirIAM is a service by AWS that manages
60820	64200	all the privileges in your AWS account,
64200	67180	in every AWS account. That means it includes
67180	70340	all the privileges both for things that you need,
70340	73280	your employees, your servers,
73280	75760	but also for things that run in the background,
75760	79540	like AWS services and access across services.
80700	84400	So, it starts out really cool, and it allows that for everything.
84400	86740	But the problem is that it is hard because
86740	90720	it includes a lot of specifics and details.
90900	93880	You create a user for every employee, and maybe
93880	97320	for integrations, and for your CICD pipeline,
97320	100800	and your servers, and it just becomes way too hectic.
101240	103980	So, let's try to break it down and see
103980	105940	why it is that way.
106660	109760	When I look at AIAM, I think of it
109760	112740	more like a road system. So, we have our users
112740	115920	and our servers, and we have the resources,
115920	119020	our data, our buckets, our databases,
119020	120820	and all of those are destinations.
121500	125220	And IAM, or privileges that are described in IAM,
125220	127780	are like the roads between those entities.
128600	131800	So, usually when you start out, you don't need a road planner.
131800	134460	You have maybe two or three employees,
134460	137300	and you set up maybe a server. That server
137840	140480	serves your app. It can be behind a load balancer.
140820	143520	It's pretty simple stuff. You won't need more than maybe
143520	147200	two or three roles and top four or five users.
147200	149820	But we don't use the cloud for this
149820	152740	simple infrastructure. We use the cloud because it allows us
152740	155680	to grow and scale and use more
155680	158520	and more services. And sooner rather than later,
158520	161780	you'll find yourself stuck in this kind of situation.
161780	164760	You'll be adding more services, RDS,
164760	168020	ECS, CloudFormation, CloudFront,
168020	170240	more and more services, and all of those
170240	173480	require different roles and different users.
173580	176940	Some of them are maybe even third-party tools.
176940	179740	And you also have different access patterns.
179740	182680	You can start out by everybody using their own
182680	185400	IAM users and then switch out
185400	188600	to maybe using SSO and identity providers,
188600	192280	which mean you have roles and not set of credentials.
192280	194360	And all of that leaves layer
194360	197920	over layer of unused and unnecessary privileges,
197920	201700	which can be used by bad actors.
202280	204060	Now, as a security person,
204060	206900	which is kind of what I do, when I
206900	209980	see IAM, I have only one question I really want
209980	213560	to answer. And that is, who has access to what?
214400	216100	It should be pretty simple,
216100	218660	but I will now show you why it isn't that simple,
218660	221880	specifically in AWS IAM, but that happens also in
221880	225320	GCP, Azure, and other cloud providers.
225900	229040	So let's start out with a simple question.
229080	231560	Who has admin access, which is full
231560	233720	access, to my AWS account?
234280	237520	When I asked this question in the beginning, naturally
237520	240380	I went to the administrator access, which is a managed AWS
240380	243620	policy, and I tried to understand who has access
243620	246580	to that policy. Who has that policy attached?
246720	249520	So you can see here, this is an example account.
249520	252480	We have two roles, which have admin
252480	255620	access to the account, and also a group. Now,
255620	258300	the group in itself is not any user
258300	261400	or role, but we would like to know who is part of that group.
261400	264160	So I clicked on the group, and now I see the group
264160	267460	has 11 users, all of them have admin access to the
267460	270360	account. The problem with IAM
270360	273620	in AWS is that this isn't a complete list
273620	275520	of all the admins in the account.
276260	279380	And the reason is simple. IAM allows you to create
279380	282580	your own policy documents, which are simple JSONs,
282580	285300	in which you describe what you allow and deny for each
286060	288300	entity. It could be a role, it could be a user,
288300	291300	it could be a group. So this is an example of an
291300	294040	inline policy, which means it's a policy for one specific
294040	297140	role, which allows all actions
297140	300440	on all resources. Well, that's what I would call an
300440	303200	admin. And this isn't listed anywhere. It won't
303200	306200	show up anywhere. You'll have to go entity by
306200	309100	entity, policy document by policy document
309100	311300	to find these entities.
312420	315200	So this example shows us two problems
315200	318760	we have with IAM. One is that it is easily bypassed.
318760	321320	You can just create your own policy, it won't be
321320	324080	listed anywhere, no one will know, and you can give any
324080	327120	permission you'd like. The second one is that
327120	330620	IAM supports complex relationships. Let's say you have a user.
330620	333240	You can attach a managed policy to it, or you can
333240	336260	put an inline policy. But as we've just seen, you can also
336260	339280	do that using a group, right? You can have the
339280	342420	user be a part of a group, and that group will have the policies
342420	345200	attached or put on. But that's not
345200	348380	all that IAM supports. IAM supports assuming
348380	351380	role as well. So that means a user can assume
351540	354340	a role and get the policies that are set on that
354340	357560	role, or assume through that role another role.
357560	359940	And that's a long chain of privilege excavation
359940	362760	that you won't be able to see using
362760	366260	simple console and going through the entities
366260	369640	in IAM. But that's not all.
369640	372080	Let's take a look at another example and see two
372080	375080	other things we can find in IAM. So
375080	378120	this is a list of the 11 admins from the admin group
378120	381040	we've seen before. If we look at them, we'll see
381040	384180	that 10 of them have access keys which are older than 90
384180	387340	days. So best practice is to rotate
387340	390420	your keys every 90 days since these are static credentials
390420	393580	that if discovered, they can be used to abuse the account.
394620	395800	We can also see that
396320	399420	four of these users have passwords and no
399420	402500	MFA set. Now you might notice that most
402500	405200	of them do not have password access. That's because we've
405200	408400	moved over to using SSO. And these
408400	411320	four users unfortunately did not do what was
411320	414040	required of them, or they've been handled since then.
414040	417100	But they do pose
417100	419900	brute force risk to the account just by having passwords
419900	423100	with no MFA. And if that's not enough, we also
423100	425880	see that two users have not been used for
425880	429000	more than half a year, more than 200 days. There's
429000	431500	really no reason to keep live access keys
431960	434900	that have such a high level of access to the
434900	438220	account without them being used at all.
438400	441120	So this example shows us two things.
441120	444280	One is that it's difficult to enforce patterns over time.
444280	446660	You have to manually go through the user list
446660	449720	and find the, I would say, the
449720	452200	people who are out of line
452980	456080	or the resources that are misconfigured.
456080	458960	But it's also hard to trace and verify usage. It could be that
459080	462100	a person was using this account a lot for a year
462880	464880	and has since stopped, but
464880	467900	we won't know it unless we check. And we have to check it
467900	471540	per user, per role, per entity in IAM.
473160	473740	So
473740	476180	we have all of these problems which cause
476790	479660	layer and layer of garbage and stuff that's left behind
479660	483460	and waiting to be now used.
483480	486160	And we were wondering how we can do it.
486160	488620	So what I developed
488620	491540	is called Air IAM. It's completely open source. You can
491540	494780	check out the link. I'll share it later too.
494780	497400	And what it does is distribute IAM through
497400	500340	Terraform. It creates Terraform code from your
500340	503440	existing IAM. Let's walk through and see
503440	504960	what it does.
505560	509240	So before we created the open source, obviously, we had to do
509420	511880	a few manual iterations to see
511880	515240	what works and what doesn't. And we came
515240	518280	to this flow of conclusions
518280	521560	and actions. So at first
521560	524720	we would like to collect all the IAM entities from the
524720	527920	account and their usage using AWS
527920	530720	APIs, maybe CloudTrail data and so
530720	533260	forth. And then for each entity
533260	536760	cross-reference it with its usage and decide
536760	539800	whether the entity is in use or not. Whether the entity is
539800	542780	in use or not is a question that depends on
542780	545640	the threshold for usage. I would
545640	548580	say the default best practice is 90 days.
548580	551600	I've seen it go down to 30 or up to 365
551600	554380	days. So it really depends on your preference.
554660	557480	Once we've decided what's not used, it's easy. We can mark
557480	560360	it for division. And we will need to go through the
560360	562340	permissions that are in use.
562780	566220	So we will have to go through the entities
566220	569300	and look at their permissions, look at what
569300	572300	they've actually used using Access Analyzer or
572300	575300	CloudTrail and create, I would say,
575580	578520	a minimized version of the policies that they have
578520	581320	based only on stuff that they use, meaning we won't
581320	584920	be able to impair any workloads,
584920	587660	not dev, not production, not anything. If it is
587660	590680	in use, we're leaving it as is. The third
590680	593640	one is to create a recommendation. That
594500	596520	usually included a very
597380	599580	large workbook with a few sheets in it
599580	602640	that describes what we want to do for each entity with
602740	605660	a few different, I would say, categories.
605920	608720	And after we've done that, we'll take that to the relevant
608720	611260	account stakeholder or
611260	614340	the person who actually uses the account and knows
614340	617500	the types of usage in the account.
617500	620700	For approval, that might
620700	623340	seem like a pretty long process. You actually
623340	626500	won't understand how long it is. I've added
626500	629680	some time estimations to the different steps. I would
629680	632580	say the most difficult part is to create
632700	635420	a recommendation and then get the approval from the relevant
635420	638300	stakeholders. I've seen it take weeks
638300	641660	and it's just a lot of misunderstanding
641660	643760	and meetings and getting
644500	647560	formal approval. And then I found out that
647560	650360	even implementing the changes after I have the action items
650360	653360	and I have the approval, it takes me a while. An
653360	656480	hour is for a medium-sized account.
656480	658780	It could take a lot longer for bigger accounts.
660260	662500	So after iterating through this a few
662500	665840	times and making sure that we understand what we need,
665840	668440	we decided, like we do in many other
668440	671960	fields here at Bridgecrew, that we want to automate it.
672380	674000	When we wanted to build
674000	677400	the automation, we decided that we have
677400	680400	four main, I would say, goals we
680400	683100	wanted to reach through the automation tool.
683100	686120	So the first one is that we want to identify unused
686120	689200	entities and easily remove them. When I say
689200	692380	unused entities, I also mean unused policy attachments.
692380	695180	So that means policies that are not in use at all by the
695180	698260	role or user or group that has that
698260	701060	policy attached. I want to also remove that.
701500	704620	We want to be able to detect drifts and enable rollback.
704620	707180	Let's say I made some modification and it caused
707180	710260	downtime. For some reason, something went wrong.
710260	714380	I can always roll back and make sure everything works.
714960	716660	I want to be able to handle scales
716660	719760	of thousands of entities. Again, when I say entities,
719760	722760	also the relationships between the users and the policies
722760	725680	and the roles and the groups. So it very easily
725680	729220	reaches the 1,000, 2,000 threshold on big accounts.
729640	731420	And then the fourth one,
731420	734440	which is very important, is to be able to take
734440	738080	the plan to get approval from the relevant stakeholders.
738080	740720	But I want something that I can share and people will
740720	744260	easily understand and either say that's fine or not.
745640	747500	So the tool itself,
747500	750020	ARIAM, is pretty easy. All it does is
750020	752740	collect data from AWS APIs, both
752740	756320	IAM and Access Advisor, cross-references it
756320	758840	and either outputs it as CLI
758840	762060	output for your convenience or
762060	765040	Terraform code, which we'll see in a bit how
765040	767580	that, I would say, leverages
767580	769560	the power to the maximum.
770840	773600	So let's start talking about the tool.
774560	776700	ARIAM contains three commands
776700	780060	built in. The first one is called Find Unused.
780060	782580	What it does is collect all of the data from
782580	785740	the APIs and decides whether the entity is
785740	788640	used or not. The default setting is
788640	792520	90 days. Let's do a short demo and see how it works.
793620	796940	Great. So I've already installed
796940	799140	ARIAM on this computer, although it is
799140	801740	very easy to install. And I can just run
802280	804780	ARIAM Find Unused.
806080	808080	So it now gets all the IAM
808080	811160	configurations for the account. It will then collect the usage
811160	813940	for all the users and the roles in the account. And
813940	817080	right after that, it will output all
817080	819980	the findings. Awesome. So you can see
819980	823420	it's generating the reports, editing it,
823420	826080	and now it will start outputting the unused
826080	828980	entities that it found in the account. So as you can see, we
828980	832120	have here four users who have not been used.
832120	834920	It says last used 365 days ago.
834920	837840	That's the maximum that AWS promises that
837840	840920	there was no usage in. We can
840920	844420	also see there's one active access key that isn't being used.
844580	846900	You'll notice that it's for a user that's not
846900	849580	listed under the unused users. So
850340	852740	ARIAM does not give you duplicate results. If
852740	856200	the user is unused, it won't say that its access keys are unused,
856200	859280	although he might have access keys that are unused.
860180	861180	Sorry.
861400	864640	We also have one user, that's my user, which
864640	867840	has password access to the console with MFA,
867840	870420	but hasn't used it for over 100 days.
871100	873720	If it doesn't have MFA, it will say it here.
873720	876400	So you'll be able to understand who is, I would say,
876400	879600	the bigger problem. We also have
879600	882600	four roles which are unused. Those are roles
882600	885600	that haven't been used for, I'd say, over
885600	888640	100 days. Yes. We have two groups which
888640	891800	are redundant. One of them has no members, which means
891800	894460	it's just laying there and it's a security hazard
894460	897480	because, let's say, it does have any policies attached.
897480	900720	If you attach a user to it, it will automatically gain
900720	903140	all those permissions. So even
903560	906760	it's just leaving behind privileges that maybe an attacker can
906760	910540	utilize. And then group without policies.
910540	912540	Groups can have members but have no policies
912540	915760	attached. And since a group is not an entity
915760	918700	that can be used in AWS, just
918700	921720	groups' privileges, there's no point in having those
921720	924780	groups. And since we want to make
924780	927940	AWS IAM as manageable as possible,
927940	930600	it also recommends deleting those kinds of groups.
931000	933940	We have a redundant policy that's a policy that's not
933940	937000	attached to any user, group, or role. It's just
937000	940340	clutter that's being left behind in the account.
940340	942640	And we also have two policy attachments.
942640	945140	For policies that are unused by the relevant
945780	949220	principle. So this user, S3User1,
949220	951840	is not using any privileges given to him by Amazon
951840	954940	API Gateway Administrator. But he does have that privilege
954940	958140	given to him, which can cause him to make
958140	961060	actions which he shouldn't, such as creating or even deleting
961060	963500	existing API gateways.
964680	965880	Great.
967020	970720	So I hope we've got all of that clear.
970720	973200	And this helps us actually create some
973200	976180	of the permissions baseline, since it allows us to remove
976180	979400	attachments of policies that are unused but given.
979400	982080	And create more of a list privilege model for
982080	985080	our IAM. The second command is called
985080	988060	recommend groups. What it does is try to look
988060	991060	through the users that you have in the
991060	993740	account, group them according to their
993740	996880	relevant privileges, and actually
998020	1000180	create recommendations for three
1000180	1003140	types of groups currently. One is the admins group, which are
1003140	1006440	active admins. The second one is power users,
1006440	1009100	which are for users who have write access to the account
1009100	1012020	but not admin access. And the third one
1012020	1014420	is the read-only group. That's relevant for
1014940	1017980	all the users who have read access to the account but don't have any
1017980	1020960	write access. This command
1020960	1023700	helps us finalize the permissions baseline or
1023700	1026800	the changes we want to... the things that are in use
1026800	1030100	and create the recommendation, what we want the account to look
1030100	1033280	like in the end. So let's
1033280	1034440	see that as well.
1035800	1038380	I'll hit ARIM, recommend
1040840	1041710	groups.
1043420	1044540	Awesome.
1044540	1047940	So in this account, we have two active users.
1047940	1050780	One is my user, which is an admin and requires admin
1050780	1053640	access. And also this S3 user one,
1053640	1056400	which has write access to S3.
1056400	1059720	We don't have any read users in this account, so it doesn't
1059720	1062760	offer me the read-only. There's no point in creating empty groups
1062760	1065800	as we've talked before, but if there were any, it would show them
1065800	1066480	here.
1068800	1072140	So we have the recommendation, it's just not actionable yet.
1072140	1074780	We have everything we want to do, but we can't show it
1074780	1078320	to anyone and we can't just hit play and make that work.
1078580	1080840	That's where the third command comes in.
1080840	1083440	It's called ARIM Terraform. And what it does is create
1083440	1086640	Terraform code and state file. I'll show you
1086640	1089260	how it works and we'll talk a bit about Terraform
1089260	1093140	so you understand all the power that this command brings with this.
1094160	1095280	So,
1095280	1097480	I'll type in ARIM Terraform
1098360	1101500	and what it does is it will initialize Terraform,
1101500	1104360	it will create Terraform files for me, and then it will import
1104360	1107380	the existing Terraform entities into the local
1107380	1109800	state file. Let's see how that looks.
1110120	1113100	So I'll change to the results there
1113100	1116840	and you'll see that it created just now.
1116840	1119640	This is in my time zone. It created
1119640	1122940	the .terraform directory, which includes all the
1122940	1125820	files that are necessary by Terraform to run.
1125820	1128560	This is a temporary file, so you can ignore it.
1128560	1131860	It creates .tf files that define all the
1131860	1134580	different entities and their relationships using Terraform
1134580	1137900	HCL code. It also creates a state file
1137900	1140900	and the backup, which again, you don't need to
1140900	1143620	care about because it is only temporary
1143620	1146400	and for system usage. Let's take a look
1146400	1149620	at groups.tf. So,
1149620	1152300	what this shows you is the
1152300	1155720	four groups that we have in the account and the
1155720	1158780	policies that they have attached, if any. So, for example,
1158780	1161460	we have the admins group and the admins group has
1161460	1164400	administrator access attached to it. We have a group
1164400	1167560	without members and that group has two policies attached,
1167560	1170560	the RDS full access and the user change password.
1170560	1173420	We also have a group without policies, which
1173420	1176580	has no policies attached, and the S3 group,
1176580	1179140	which has the Amazon S3 full access.
1179700	1182700	Just so we can see it for real,
1182700	1183920	I've opened the
1185680	1188340	console for it and this is the groups in the account.
1188340	1191500	You'll see these are exactly the four groups we have and
1191500	1194220	you can see that the group without policies actually
1194220	1197240	does not have policies and the group without members has
1197240	1199420	these two permissions.
1201460	1203320	So, the same goes for
1203320	1207260	roles. Let's see the roles file, for example.
1207420	1209400	So, for every role, we'll have
1209400	1212260	the role itself. We'll also have the assume role
1212260	1215280	policy document and if it has any
1215280	1218520	policy attachments, such as this one, it will be listed
1218520	1221080	as well. You'll notice that the syntax is
1221080	1224820	not using any hard-coded strings.
1224820	1228060	Basically, ARN creates the entities and connects
1228060	1231040	them so you can actually see who has access to
1231040	1233960	what. Awesome.
1234120	1237420	So, that's all the code. Let's take a look at the state file.
1237960	1239840	So, the way Terraform works
1239840	1242680	is it creates both the code and the state file
1242680	1245980	and the state file describes what connects
1245980	1248980	the entities that were defined in code with the actual
1248980	1252160	ARNs in the cloud environment. So, for example,
1252160	1255160	we have here the AWS IAM group admins
1255160	1257980	as we've seen it in the code and that's connected
1257980	1260900	to this instance with this ARN.
1261160	1263640	So, if I copy it and I go to admins,
1264060	1266840	that's exactly the ARN of the group. So, that means
1266840	1269760	this code describes
1269760	1273000	this group and when I
1273000	1276180	will run Terraform apply or Terraform destroy or Terraform
1276180	1279100	plan, it will go and check what's configured in the
1279100	1282040	code and what's configured in the state file and
1282040	1284960	fix the differences. So, if it needs to delete
1284960	1287480	or create or modify anything that's been
1288080	1290960	described in the code and is not as is in the
1290960	1294780	console, in the actual account, it will be fixed.
1296640	1297680	Awesome.
1298080	1298900	So,
1300000	1302960	once I've created this, I can actually create the
1302960	1305660	Terraform code, if you'd like, without the import stage
1305660	1308120	which takes a while.
1309840	1311920	So, this is what it does
1311920	1314840	and if I type ls-la,
1314840	1317360	you'll see that everything has updated
1317360	1320340	except, well, it just finished now.
1320380	1323340	So, if I run it again, you'll see that everything will change
1323340	1326640	except the state file. See that? Awesome.
1326640	1329300	So, the state file did not change, but all the tf files
1329300	1330540	got updated.
1331580	1333640	So, if I go into the results
1333640	1336880	and type Terraform plan,
1336880	1339600	you'll see that all the differences that it wants
1339600	1342580	to do is unrelated to actual
1342580	1345400	entity modifications. This Terraform code
1345400	1348480	describes the actual entities almost
1348480	1351600	one-to-one. You see it has a force destroy flag
1351600	1354400	added to the users. That's so when you select
1354400	1357500	to destroy a user, it will actually go and
1357500	1360860	destroy, including the access keys,
1360860	1363540	the password access, everything. So,
1363540	1366560	I'll run Terraform apply just to make sure we don't have
1367180	1369320	any differences. You'll see it takes
1369660	1372440	a few seconds. And then
1372440	1375100	we have the Terraform output form
1375100	1378360	and the actual account exactly in line.
1378360	1381700	Hold on. I don't want to break it. Yes.
1382460	1384500	Awesome. So, now
1384500	1387400	let's say I want to delete all the unused entities that I've just
1387400	1390320	found. Instead of going through and deleting
1390320	1393560	one-by-one the policies and the groups and the users and the
1393560	1395500	roles, I can just type here
1396300	1397920	minus minus without
1399220	1404710	unused. Great. So,
1404710	1407610	now it created the Terraform files. But if we'll take a look, for
1407610	1410530	example, at groups.tf, you'll see
1410530	1413650	that we only have two groups now, which are the two groups that
1413650	1417010	both have users and have policies attached.
1417770	1419450	Pretty simple.
1419650	1422370	Now, when I run Terraform plan again,
1423950	1425650	you'll see that it offers to
1425650	1428630	delete everything for me. And it will
1428630	1431510	be much higher than five or ten
1431510	1434530	entities. It actually plans to destroy 40
1434530	1437730	through users, roles,
1437730	1440670	policies, and all the relationships between
1440670	1443510	them. And it will take just a few seconds and
1443510	1446510	the Terraform will apply. That's all you need.
1447050	1448150	Pretty slick.
1450150	1451350	Awesome.
1452910	1455590	So, we've created a recommendation that's
1455590	1458770	very actionable. I can take it and
1458770	1461770	apply it. But I don't have any way to show it
1461770	1464670	and get approval for it. But another very
1464670	1467530	powerful plus side of using Terraform is that it's
1467530	1469790	code. And for code, we have
1469790	1473410	version control systems. I like GitHub, so these are
1473410	1476470	print screens from GitHub. But basically, what you
1476470	1478430	can do is commit the
1479150	1482330	Terraform code that is outputted by default with
1482330	1485310	everything to a master branch, check out a new
1485310	1488250	branch, run it without unused, for example,
1488250	1491270	and open a PR. And that PR talks
1491270	1494530	in a very simple language that developers can understand,
1496310	1499070	even less technical guys can understand that
1499070	1501170	if there's a group here that's called group without
1501170	1503690	members and has a minus in front of it, it will
1503690	1506570	probably get deleted. So you can use that
1506570	1509870	to actually have all the conversation around
1509870	1512810	getting approval and making
1512810	1516410	everything, I would say,
1516410	1519670	approved or agreed upon. And then,
1519670	1522190	again, just a simple Terraform apply will make all
1522190	1523730	those changes for you.
1525190	1528390	So that completes our entire flow. Although
1528390	1530710	we have three commands to help
1530710	1534470	crunch through all the data and understand the phases,
1534470	1536870	in general, you can just run directly RIM
1536870	1539990	Terraform, it will do all the work for you. It will find all the
1539990	1542990	unused entities, it will import them into Terraform,
1542990	1545010	and you'll be able to actually
1546470	1549250	run it again without unused or with unused,
1549250	1552830	run Terraform apply, everything will be in your hands.
1554210	1557170	Now, you've run it once, that's great. You have your
1557170	1560790	IAM set up clean and sparkling and beautiful.
1560970	1562930	But the problem with the cloud is that
1562930	1566270	well, it's both a plus and a minus, I would say,
1566270	1567510	is that people can
1569430	1572010	manually change and make modifications.
1572730	1575510	Now, using RIM on a
1575510	1578610	weekly basis, monthly basis, on a regular basis,
1578610	1581110	you'll be able to scan your IAM and identify
1581110	1584030	drifts in existing configurations. That means if there were any
1584380	1587330	modifications or deletions, you'll be able to find
1587330	1590490	those things in code and
1590490	1593410	actually automatically update your
1593410	1596370	Terraform state and your Terraform code.
1596370	1599770	You'll also be able to identify changes in usage status.
1599770	1602430	So we've seen the problem where we had admins who have been unused
1602430	1605470	for a long time. If you scan on a regular basis,
1605470	1608390	it will by itself find entities that have been unused
1608390	1611350	for 90 days or if you modify your threshold
1611350	1614370	by your threshold and mark them for deletion
1614370	1617750	and recommend you delete them. It will also help you identify
1617750	1620730	new configurations. So let's say you have a
1620730	1623950	new team or you have a new service or you even started a new Lambda
1623950	1626750	and you created a role for it, that role will
1626750	1629370	automatically be integrated into your Terraform.
1629370	1632450	It will be imported into your state file and you can add it
1632450	1635510	to your repository where you will still have it
1635510	1639290	managed and you'll be able to see it.
1639330	1641430	And nothing will go without
1641430	1644690	knowledge. And then the last
1644690	1647370	thing that ARAM and Terraform enable
1647370	1650570	to you is to use static analysis tools to identify
1650570	1653570	bad practices. So I would like
1653570	1656570	to take this to the next slide actually
1656570	1659490	which shows, I would say, two
1659490	1662030	really great tools that will help you
1662030	1665650	use infrastructure as code
1665650	1668570	and static analysis for your permissions
1668570	1671210	in your IAM. So the first one is called
1671210	1674650	Chekhov. It's also pretty easy to install and I already
1674650	1676390	have it set up here.
1676890	1680190	So Chekhov, what it does is identify bad practices
1680190	1683690	in Terraform. So if I run... let's see...
1684530	1686610	the last thing I did was without the unused
1686610	1689510	right? So I want to do it one second with
1689510	1692650	everything. So right now I created Terraform for
1692650	1695590	the existing IAM setup. And if I go to
1695590	1698070	the results tab, I can just run Chekhov
1698390	1701350	minus the results. This will make
1701350	1704530	Chekhov scan all the Terraform files that are in the results
1704530	1707810	directory. And we'll see in a few seconds
1707810	1710530	that it has quite a lot of findings.
1710730	1714310	So if I scroll up, yes, quite a lot indeed.
1714310	1717170	So it found, it ran 56
1717170	1720130	checks and 23 of them failed. This
1720130	1723150	includes misconfigured admins and
1723150	1725710	bad assumer role policies and
1726270	1728990	policies that are attached directly to users as this
1728990	1732170	would require justification. Otherwise, it is really
1732170	1735270	recommended to use groups. Let's say
1735270	1737490	I ran it without the unused, just for
1738250	1741110	checking what that would mean. By deleting all the unused
1741110	1743930	entities and running Chekhov again, I will see
1743930	1747010	how much cleaner the account is. And the
1747010	1750150	account is a lot cleaner. So we only have two failed checks
1750150	1752730	and both of them can be either justified or
1752730	1756130	fixed. And all in all, we only
1756130	1759130	have 11 checks that were scanned.
1759130	1761930	That means a lot of the overhead was cleaned simply
1761930	1764690	by deleting unused stuff.
1766130	1767330	Awesome.
1768290	1771410	Another really cool tool is PolicySentry.
1771410	1774210	PolicySentry allows you to build IAM policies
1774210	1776690	from scratch using YAML syntax
1777330	1780770	and easy, simple CRUD syntax.
1780770	1783410	So you have create, read and
1783410	1786530	update and delete syntax for different resources and
1786530	1789230	different services. And that creates an IAM
1789230	1792250	policy that's probably better than what
1792250	1795250	your average developer would create.
1796190	1799190	If you're talking about scanning your existing
1799190	1802350	configurations, I also have a few tools up my
1802350	1805590	sleeve. So the first one, I would say the category
1805590	1808410	is finer and more granular
1808410	1811550	disk privilege for IAM.
1811550	1814250	We have CloudTracker by Geolabs and Ardvark
1814250	1817470	plus RepoKid by Netflix. They both
1817470	1820030	use CloudTrail data, so you need to have CloudTrail read
1820030	1823430	access to analyze the policies and
1823430	1826510	mark specific privileges and break
1826510	1829390	down all the stars and the jokers in your
1829390	1832310	policy to understand what you're giving that isn't really
1832310	1835430	in use. I would say that CloudTrail
1835430	1838230	visibility or coverage is not 100%.
1838230	1841570	Not all actions are by default recorded
1841570	1843930	in CloudTrail. And so using
1843930	1847310	CloudTrail comes with a...
1847310	1848770	maybe you should take it
1850270	1852770	suspiciously. Another really
1852770	1855750	cool tool that I'd like to show is called CloudSplaining.
1855750	1858530	CloudSplaining is another tool by Salesforce that identifies
1858530	1861530	possible risks in your IAM configurations.
1861530	1865230	So it has four different classes, privilege escalation,
1865230	1867650	data exfiltration, other stuff.
1867650	1869950	Let me show you real quick.
1870270	1873550	So I run CloudSplaining. It's a very simple
1873550	1876890	setup again. So what it does
1876890	1879930	is it scans all of the policies that are in the
1879930	1882850	account and it outputs a very detailed and rich
1882850	1885930	report about all of the stuff that you can find
1885930	1888950	in your account. You can actually go by the policies
1888950	1892090	or by the principles, which is what I prefer, and just
1892090	1893870	take a look, for example,
1894670	1897530	who has access to infrastructure
1897530	1900730	modification. So say the misconfigured admin
1900730	1903890	user has... well, since he's a misconfigured
1903890	1907290	admin user, he has all the bad stuff that he can.
1907290	1911090	If we'll take a look at the misconfigured IAM user,
1911970	1912950	you'll see that
1912950	1916410	he has this very bad policy,
1916410	1919530	which we've talked about. It allows everything on everything.
1920430	1921830	So it shows that he can
1921830	1925030	do a lot of infrastructure modifications,
1925030	1927970	do privilege escalation, do resource exposure,
1927970	1930930	and data exfiltration. You can actually go
1930930	1933730	through this by risk and start
1933730	1936290	diving deeper into that.
1938410	1940170	And then the final
1940170	1943030	tool I'd like to show you is called PrincipleMapper
1943030	1945950	or PMapper. It's by NCC Group. It helps
1945950	1949570	identify possible privilege escalations in the account.
1949570	1952190	So if you remember, we had the graph where a user
1952190	1954750	can assume a role and that role can assume another role
1954750	1957870	and each role has its own privilege, I would say
1957870	1960130	policy context of policies.
1960690	1964370	So this tool creates a graph. You see it here.
1964470	1966710	An example, it's a very partial
1966710	1969530	graph. It has these two roles
1969530	1972650	and this user, for example, can assume this role.
1972810	1975430	And so the user, which is called
1975430	1978830	EC2 Manager, can assume the role and gain all the privileges
1978830	1982050	that are attached to EC2 role for SSM.
1982170	1984830	And this allows you to map all the different roles
1984830	1988710	and maybe if you identify a role that is super powerful,
1988710	1991070	check who can assume it and make sure
1991070	1993430	that that's in check.
1995830	1999390	Yep, that's it for the slideshow.
2000650	2001970	All right.
2002790	2004630	I guess to start off with
2004630	2007670	one question for me, I'm assuming that
2007670	2010430	if you wanted to make a change, a specific change
2010430	2013490	instead of the whole IAM recommendation made by
2013490	2016650	AIR IAM, you would just go ahead and edit the
2016650	2019330	Terraform file, right? And so are there any
2019330	2022470	specific config files within AIR IAM
2022470	2025510	that you can use to specify what to detect
2025510	2028150	and what to ignore or anything like that?
2028150	2030930	So Terraform itself allows you to
2030930	2034310	maybe, I would say, create or modify or destroy
2034310	2038050	anything you'd like within the code and the state file.
2038050	2040490	So AIR IAM gives you all of the changes you'd like.
2040490	2043410	You can run Terraform apply as I did in the slideshow,
2043410	2045970	but you can also specify a specific target,
2045970	2049210	be it a user, a group, or a policy, and Terraform will
2049210	2052530	modify only that part of the findings.
2052970	2056070	Got it. And then another one,
2056070	2057910	do you plan on bringing any of these
2058490	2061170	features to GCP or
2061170	2063490	Azure, something along those lines?
2063670	2067810	Definitely. So that's something that we've heard before.
2067810	2070850	We are planning to do this. It requires
2071190	2074290	a complete different set of, I would say,
2074290	2076990	you need to use the other
2076990	2079990	SDKs and it will require more knowledge because
2079990	2083770	GCP IAM is not exactly like AWS IAM.
2083770	2085930	It has a lot more of privileges
2085930	2089150	given by the resources and not the principles,
2089150	2092270	but we are definitely planning to go in that direction.
2092270	2095090	Got it. Another question
2095090	2097990	from Artemis in chat. How well do these tools
2097990	2100750	work in a multi-account environment?
2101050	2103210	That's a great question. So
2104090	2107050	I would start out by saying that IAM permissions are
2107050	2110110	limited to the account. You can give cross-account
2110110	2112950	permissions, but that would be from
2112950	2116110	one account you give the other account permissions.
2116170	2118990	So the context of every, I would
2118990	2122190	say, analysis is a specific AWS account.
2122190	2125430	So you can use ARAM using all the default
2125430	2128530	AWS credentials tools. You can use the profile and specify
2128530	2131410	the minus minus profile flag. You can use
2131410	2134370	AWS environment variables to scan different accounts,
2134370	2137350	but every ARAM scan is limited to the context of
2137350	2139830	one account since that is the context of IAM.