AWS re:Inforce 2022 - How Guardian Life validates IAM policies at scale with AWS (IAM305)

Aug 16, 2023

AWS re:Inforce 2022 - How Guardian Life validates IAM policies at scale with AWS (IAM305)

Attend this session to learn how Guardian Life shifts IAM security controls left to empower builders to experiment and innovate quickly, while minimizing the security risk exposed by granting over-permissive permissions. Explore how Guardian validates IAM policies in Terraform templates against AWS best practices and Guardian’s security policies using AWS IAM Access Analyzer and custom policy checks. Discover how Guardian integrates this control into CI/CD pipelines and codifies their exception approval process.

Learn more about AWS re:Inforce at https://bit.ly/3baitIT.

Subscribe:
More AWS videos http://bit.ly/2O3zS75
More AWS events videos http://bit.ly/316g9t4

ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.

AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster.

#reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

0.42 -> - Hello, everyone.

1.83 -> Welcome to session IAM 305.

5.1 -> My name is Bohan Li.

7.29 -> I'm a senior security consultant with AWS.

10.77 -> I've been with AWS for a little bit over two years,

13.77 -> and my specialty is identity and access management.

18.3 -> Today, I'm super excited to be joined

20.97 -> by Michael and Hetul from Guardian.

23.01 -> Michael, could you please introduce yourself?

25.98 -> - Sure. Hi, everyone.

27.27 -> I'm Mike Novack.

28.5 -> I'm with Guardian Life,

29.49 -> and I'm on the security architecture team.

31.26 -> Our role is to bring technology

32.94 -> and the security org together,

34.53 -> and I specialize in application security.

36.9 -> Go ahead, Hetul.

37.777 -> - Yeah, I'm Hetul Patel,

39.72 -> in the industry for about little more than 20 years

43.2 -> and been working at awesome Guardian for more than six,

46.95 -> As a team lead for DevOps, it gives me opportunity

50.19 -> to work on latest and greatest tools,

52.02 -> like one of the tools we're demoing today.

55.17 -> and just to make sure that we have the footprint

57.66 -> and secure footprint in our cloud environment

59.88 -> using the toolsets.

62.25 -> - Thank you, Michael.

63.083 -> Thank you Hetul.

69.03 -> So before I get into the agenda,

71.79 -> let me ask you a few questions.

74.88 -> For the folks in the room,

77.07 -> raise your hand if you're developer.

82.92 -> One person?

85.35 -> Raise your hand if you're a security professional.

90.06 -> Awesome.

90.893 -> And finally, raise your hand if you have

94.47 -> shift your IAM controls to the left.

99.93 -> Oh great.

103.56 -> So either you are a builder or security professional

107.52 -> if you ever struggle with finding the balance between

112.02 -> agility DevOps or security,

114.99 -> you are at the right session.

117.27 -> Here is the agenda for today.

119.387 -> We are going to start with providing you

122.67 -> an overview of AWS IAM Access Advisor.

127.11 -> Then I'm going to walk you through

129.09 -> a few different approaches

130.86 -> for managing IAM policies we've seen used commonly.

136.17 -> Then Michael is going to talk about the IAM objectives

140.91 -> and the opportunities to improve IAM controls at Guardian.

146.935 -> Then Hetul is going to show you

149.31 -> how Guardian reaches to an ideal solution

153.48 -> to meet their IAM requirements

155.73 -> and how they manage and implement a skill with automation.

162.06 -> Hetul will also talk about how exception process

166.23 -> is managed at Guardian with automation.

171.09 -> And finally, make sure you stay to the end.

175.08 -> I will give you a live demo

176.31 -> to show how this solution works in action.

181.89 -> As a reminder, this is a 300-level session.

186.27 -> We're going to dive deep into technical details

189.96 -> about permissions management and automation in AWS.

194.79 -> So you wouldn't be comfortable if you are not familiar with

197.88 -> IAM policies, IAM roles, CI/CD pipelines and the like.

207.27 -> So what are the key takeaways from this session?

212.55 -> Today, we're going to show you how Guardian

215.79 -> enable its developers to move fast

219.69 -> without compromising IAM policies best the practices

223.8 -> and the principle of least privilege.

227.22 -> Today, we aim to show you how you cannot only

230.7 -> achieve your security objectives,

233.37 -> but also improve your security posture

237.24 -> and accelerate your business

239.58 -> by doing the following few things,

249.69 -> Getting to the right permission in AWS

253.26 -> is a continuous cycle.

256.303 -> AWS IAM Access Analyzer helps you

259.65 -> streamline permissions management

262.23 -> throughout each step in the cycle.

265.35 -> IAM Access Analyzer has the few features.

270.69 -> The first one is policy validation.

274.53 -> With policy validation,

277.277 -> it helps you to also secure unfunctional IAM policies.

283.95 -> It's able to tell you if your IAM policy

286.53 -> is overly permissive.

288.81 -> It's also able to tell you

290.52 -> if your IAM policy contains an error.

293.64 -> It can be things such as invalid action

297 -> and a missing comma.

299.7 -> It also gives you general warning that tells you

303.66 -> your IAM policy doesn't conform to best practices,

308.64 -> but not a security risk.

311.46 -> And finally,

313.41 -> it gives you suggestions

315.54 -> on how your IAM policy can be improved

318.87 -> without changing the permissions of your IAM policy.

327.9 -> The next feature is policy generation.

331.89 -> Now, if you just start with AWS,

337.23 -> you are exploring AWS.

340.23 -> You generally start with broader permissions.

344.79 -> Over time, you start figuring out

347.73 -> what does your workloads needs,

349.59 -> what are your specific use cases.

352.2 -> You want to start rightsizing your permissions.

355.83 -> Policy validation helps you with resizing permissions

360.36 -> by generating IAM policies

363.36 -> based on your activities in CloudTrail.

367.65 -> You can further customize the IAM policies if you need to.

376.35 -> For the next feature,

378.78 -> IAM Access Analyzer uses automated reasoning

383.01 -> to identify public or cross-account findings

385.86 -> to our resources.

388.53 -> So I mentioned the term automated reasoning.

391.02 -> Let me quickly explain it.

394.86 -> Automated reasoning is based on formal reasoning logic

399.42 -> and the techniques.

401.46 -> It allows IAM Access Analyzer

404.52 -> to run a comprehensive analysis

407.94 -> across all access path to your resources

411.9 -> and identify external access.

415.59 -> IAM Access Analyzer uses this analysis

420 -> and turn it into public or cross-account findings.

425.58 -> When you turn on IAM Access Analyzer,

428.88 -> it continuously reviews and monitors

433.26 -> for supported resources,

435.39 -> including new resources and updated resource permissions.

445.41 -> And finally, we have preview access.

449.1 -> Preview access uses the same analysis I just explained.

454.83 -> Instead of detecting and monitoring external access,

459 -> it's able to verify

461.4 -> any public or cross-account access to a resource

464.82 -> before your resource is deployed in your environment.

472.35 -> Today, our focus is policy validation.

481.26 -> Now I'd like to walk you through a few different approaches

485.58 -> for managing IAM policies

487.92 -> we've seen used commonly over time.

492.12 -> The first one is the centralized approach.

495.15 -> In this approach, builders tell security team

499.17 -> what they need, what they want,

501.18 -> and the security team go implement it.

505.2 -> There's some benefits of this approach.

508.89 -> One of them is that you have IAM experts

513.54 -> who are building your IAM policies.

517.41 -> However, this process can take a really long time.

523.47 -> As a result, you have a very slow feedback loop

528.3 -> and you end up with a very common scenario

533.31 -> where the builders also request

536.28 -> more permissions than they need,

538.53 -> because they know how long you will take to iterate

541.71 -> and take to get what they need,

545.37 -> or sometimes they simply don't know

547.17 -> what they need upfront.

550.8 -> Therefore, this approach doesn't scale

554.34 -> as you move more and more workloads to AWS.

566.34 -> In the second approach,

568.77 -> we shift the responsibility

570.96 -> of codifying IAM policies and roles

574.35 -> from this central security team to builders.

579.78 -> So there are some benefits here

581.73 -> especially as it relates to accountability,

586.38 -> because now the decisions about access is being made

592.41 -> by the people who are closest to the application

595.68 -> who are most familiar with the application.

600.96 -> However, this process is still slow

604.53 -> because you still get ton of applications

607.32 -> relying on essential security team.

611.52 -> On top of that, more policy defects may get through

617.79 -> because the expertise you have in the previous approach,

621.96 -> where you have IAM experts

624.63 -> who are writing your IAM policies may get lost.

632.67 -> In the next approach,

634.65 -> we introduce the tool to review IAM policies

639.36 -> that was done manually in the previous approach.

645.06 -> So now the benefit of this approach

648.57 -> comparing to the previous approach

651.78 -> is that the feedback loop get faster

654.69 -> because now you have a tool to review IAM policies.

660.39 -> and the IAM policies should get past

663.87 -> the checks with the tool

665.91 -> before they get to your security team.

670.62 -> However, the security team still needs to review and approve

675.48 -> the IAM policies,

677.25 -> so the feedback loop is not as fast as it could be.

687.3 -> In this final approach,

690.42 -> the entire development life cycle is automated.

695.67 -> The security team no longer needs to review and approve

699.12 -> every single IAM policy.

703.59 -> The goal here is to codify the security knowledge

709.08 -> so that things can be automated.

715.11 -> So in this case,

717.3 -> we use policy validation with IAM Access Analyzer.

721.59 -> Today, policy validation has over a hundred checks,

725.1 -> and we continue adding new checks over time.

729.57 -> If you have a use case that is now covered

732.54 -> by policy validation today,

735.12 -> come talk to us after the presentation.

740.34 -> We encourage you to think about,

744.09 -> automate, and codify checks

747 -> to codify the security knowledge,

749.73 -> so that you can integrate it

751.44 -> into your development life cycle in an automated way.

757.02 -> So in summary, this approach has fast feedback loop

763.14 -> because everything is automated.

766.59 -> Therefore, it enables your builders

770.28 -> for faster code delivery

773.37 -> as well as free up security team's time

777.69 -> so that they can focus on other things,

780.78 -> such as building guardrails,

783.9 -> monitor and improve the automations,

788.34 -> as well as building other type of security controls.

796.62 -> With that, I'd like to hand it over to Michael

799.89 -> to give us a little bit information about guarding.

803.37 -> - Thanks, Bohan, for that clear introduction

805.53 -> of the problem statement for the industry,

807.81 -> but I wanna give you a little more

810.45 -> detail about Guardian itself

812.4 -> before we go into our use case.

814.29 -> Guardian is a Fortune 250 life insurance company.

818.49 -> We have many products like dental, vision, accident,

821.91 -> and other types of insurance.

824.13 -> We've been at this for a really long time.

825.87 -> We've been around since 1860,

830.581 -> and we have a primary purpose of improving the wellbeing

834.06 -> of our employees, our customers,

836.67 -> and just the general community,

838.2 -> and we do that with three core pillars.

840.57 -> We do that with wowing the customer.

842.7 -> We wanna exceed their expectations,

845.28 -> reimagining mutuality.

848.28 -> We are a mutual company.

849.48 -> That means we're owned by our policy owners.

851.85 -> We're not owned by stockholders.

854.43 -> So we want you to feel like a policy with Guardian

857.46 -> is more than a transaction.

859.08 -> You're part of the club.

860.49 -> And finally, we wanna release what's possible.

863.97 -> Not only it's a cultural mission

866.31 -> to go ahead within our company

867.63 -> to empower our internal employees

870.81 -> to do what's best for themselves,

873 -> which then they can do what's best for the company.

877.71 -> So this project was a joint partnership

880.89 -> with AWS, as we all know,

884.22 -> Guardian, which I just introduced,

886.5 -> and Rearc, which is a software consultancy company,

890.49 -> Dan is in the audience, the main person from Rearc

893.64 -> that went ahead and did the work.

895.77 -> Can you give a little wave for the audience?

898.68 -> Sorry. Mindblind up here.

900.36 -> Sorry about that.

901.41 -> Dan is over there.

904.14 -> Sorry about that.

907.41 -> So some of the core objectives that we had.

910.41 -> We wanted to go ahead and reduce

912.36 -> the access of our application teams,

915.84 -> follow the principle of least privilege

918.9 -> by reducing risk and making sure that we are going ahead

921.81 -> and enforcing compliance at the same time.

925.26 -> But we're also trying to balance that with not

929.97 -> inhibiting our developers from going ahead

932.43 -> and building what they need to, being able to experiment.

935.61 -> We don't wanna stifle them.

939.45 -> So basically we...

940.47 -> And we also need to go ahead and make sure

941.97 -> that this can all be enforced.

945.42 -> So the security team can go ahead and focus

947.01 -> on the most important, high-impact items.

954.12 -> So we wanna go ahead and provide a tool

956.31 -> that will go ahead and...

958.05 -> Sorry.

958.92 -> That is scalable and extensible as we grow as a company.

963.21 -> and our pipeline, the tool will grow with us.

966.09 -> And none of these kind of tools are perfect.

970.68 -> None of these scanning tools are perfect.

971.97 -> We're always gonna have exceptions.

974.4 -> How are we going to handle those exceptions

976.38 -> when they come up?

977.213 -> Because they will.

978.24 -> And how to report on them

979.41 -> so that way we know compliance and other folks,

981.93 -> we can track it and it's not a Wild West.

986.43 -> So these are some of the opportunities we had.

988.62 -> We wanna go ahead and make sure that we

990.24 -> securely deploy the policies,

993.18 -> ensure that we're going ahead and meeting compliance.

997.02 -> We have resource constraints.

998.61 -> We have technical security experts

1001.61 -> and technical folks that are building,

1003.26 -> but they don't have the infinite time.

1004.46 -> We wanna reduce the manual effort they're having to do

1007.61 -> 'cause their time is valuable.

1009.53 -> By reducing the manual time that we're doing things

1012.35 -> that makes it scalable.

1014.51 -> But we're also balancing that

1016.16 -> with having some sort of centralized authority approval,

1020.51 -> some sort of automation.

1022.19 -> And most importantly,

1024.02 -> IAM is gonna keep growing and changing.

1026.48 -> So the solution can't only work

1028.13 -> for the current IAM policies,

1030.05 -> but as new services come along, how will it be handled?

1034.19 -> So that's a high level of what we're gonna be talking about.

1036.26 -> I'm gonna go ahead and handle over to Hetul

1038.33 -> to go ahead and talk more about the technicals.

1042.56 -> - All right. Thanks, Michael.

1043.82 -> - Here's the talking stick for it.

1044.84 -> - Yeah, the talking stick.

1047.75 -> I'm pretty sure you heard a lot about how to automate

1051.35 -> the access checks and access analyzer.

1053.99 -> Just by looking at audience,

1055.13 -> can I get a hand sign of how many of guys

1057.47 -> use CI/CD pipelines to deploy infrastructure?

1062.24 -> Awesome, we got a whole bunch of them.

1064.04 -> And how many of you guys use tools like Terraform

1066.86 -> to deploy those infrastructure?

1068.75 -> Oh, awesome.

1069.583 -> Almost everybody.

1070.49 -> So the reason why I asked you this question

1072.89 -> is because the tool can natively be integrated

1075.44 -> into your CI/CD pipelines

1077.6 -> as well as it also honors using Terraform.

1080.78 -> So if you're using Terraform and using CI/CD pipeline,

1083.03 -> you could still go and use the tool.

1085.7 -> So looking at the board, we have a couple of diagrams here.

1090.53 -> We have tooling team and a developers team.

1093.5 -> A tooling team is something that we call it

1095.96 -> as Guardian Rearc

1098.9 -> and AWS combined together to create the tool.

1101.33 -> So the tool that we're talking about

1103.16 -> is created by the tooling team.

1105.65 -> After developing the tool,

1107.42 -> we check it into an IAM compliance policy check code,

1111.26 -> and that is where the tool resides.

1112.64 -> That's where the bits of tools are.

1114.86 -> On the other hand, we talk about developers

1117.38 -> and giving them access to create infrastructure

1119.54 -> or infrastructure as code.

1121.49 -> So the developers are developing applications, right?

1125.09 -> So at Guardian, we have this unique combination

1127.64 -> of using a code for each application,

1129.98 -> which I suggest best practice.

1131.39 -> Most of the companies assign

1133.28 -> a unique code to an application.

1136.04 -> The reason why we give a unique code to an application

1138.59 -> is because we use that in creation of resources

1141.74 -> and it makes sure that the resource we create on AWS

1144.47 -> is always unique to that application, right?

1147.32 -> So in our case, for the rest of the session,

1149.27 -> we are considering,

1150.29 -> we are going to build an app called App100,

1153.47 -> as you can see on the screen.

1154.55 -> So a developer is trying to build an app called App100,

1158.15 -> and he has a bunch of Terraform templates

1160.07 -> because we are building resource or infrastructure as code.

1164.78 -> So that's where they're checking in

1166.43 -> their Terraform templates to build their codes.

1169.73 -> The biggest question is,

1173.3 -> how do we handle the tool?

1175.37 -> Where does it sit? Where does it reside?

1177.95 -> So the way we implement the tool

1179.9 -> is in the CI/CD infrastructure pipeline.

1183.2 -> We introduce a new stage called validation stage.

1186.53 -> This stage is the mandatory stage.

1189.08 -> So if you're building an application

1191.06 -> and infrastructure as code,

1192.89 -> you cannot overstep the validation stage.

1195.71 -> The validation stage has to be passed

1197.72 -> for your infrastructure to be built.

1200.75 -> So looking at the diagrams again now,

1202.37 -> a developer who's developing App100

1206.3 -> has written a code to deploy a resource in AWS.

1210.53 -> That in turn triggers the pipeline,

1212.81 -> which is the build stages,

1214.85 -> and a validation stage gets triggered.

1217.34 -> The logic and validation stage intercepts

1220.61 -> every single resource that you build on AWS,

1223.7 -> if you're building an IAM resource

1225.17 -> or a security group, et cetera, et cetera.

1227.33 -> So in this case, we're gonna stick

1228.53 -> to the IAM roles and policies.

1230.66 -> So here in validation stage,

1232.73 -> it is going to intercept the build

1234.44 -> of either a role or a policy.

1237.47 -> Once it intercepts the building of the resource,

1241.13 -> it concludes based upon the finding

1243.26 -> whether that policy or role or resource

1245.84 -> that it's trying to create,

1247.1 -> is it a compliant resource or a non-compliant resource?

1251.72 -> If it's a compliant resource,

1253.55 -> it is allowed to move forward

1255.11 -> and go ahead and do the build process.

1257.24 -> However, if it's not compliant, we break the build.

1261.23 -> That means nothing gets created

1263.3 -> and the build stops right there.

1265.43 -> So the next logical question is,

1267.11 -> what is happening in the validation stage?

1270.35 -> So the secret sauce here is,

1272.33 -> where we're living it is

1273.71 -> the developers now have App100,

1276.14 -> which calls the validation stage as we know.

1279.56 -> The validation stage in turn intercepts the resource

1284.75 -> and it sends...

1285.583 -> In this case, we're concentrating on the IAM policy, right?

1288.86 -> So it sends the IAM policy to AWS Access Analyzer

1292.73 -> for policy validation.

1295.37 -> The AWS Access Analyzer, as you all know,

1298.34 -> has hundreds of checks in-built into it,

1302 -> and they're frequently being updated.

1304.61 -> So AWS Access Analyzer reviews the policies

1308.09 -> that you're trying to create

1309.68 -> and sends the result back to the validation stage.

1313.43 -> The validation stage then takes this result.

1316.82 -> It combines it with the Guardian's

1318.98 -> minimum baseline security standard,

1321.62 -> and it concludes on the compliancy

1325.25 -> of the policy that is being created.

1326.96 -> So combination of the access analyzer

1329.54 -> plus the internal Guardian

1330.74 -> minimum baseline security standard

1333.17 -> would result into whether the policy

1335.03 -> is compliant or non-compliant.

1338.63 -> So a non-compliant policy, again, the build breaks

1342.5 -> and it's not allowed to move forward.

1352.13 -> So when we talk about empowering,

1354.71 -> automating developers to build code,

1357.74 -> it is very crucial and essential to have a good feedback.

1361.76 -> So here we are gonna talk into an example

1363.8 -> where developers who are trying to build App100

1367.28 -> is going through validation stage.

1369.71 -> The validation stage looks at the policy,

1371.87 -> combines it with the local Guardian's MBS controls,

1375.92 -> and it figures that the policy is non-compliant.

1379.04 -> That means it is either an overly permissive policy

1381.38 -> or it is a policy that is not allowed to be built.

1384.83 -> What happens in that case?

1386.33 -> The build obviously breaks.

1387.8 -> So it's not going to allow the developers

1390.53 -> to develop the infrastructure.

1392.75 -> The build breaks.

1394.49 -> But after the build breaks,

1396.71 -> it sends an email out to the developer

1399.59 -> with a lot of detailed information.

1402.83 -> And this is the feedback loop.

1405.05 -> So if the policy is compliant, it gets built.

1409.46 -> If the policy is non-compliant,

1411.2 -> you break the build and you send an email

1413.93 -> back to the user on the non-compliancy.

1420.23 -> So what is the use of non-compliancy?

1422.45 -> So for example, let's assume our developer

1425.63 -> is building his application

1427.91 -> and he's also building a role that needs a policy.

1431.21 -> And one of the policy that he's trying to write

1433.22 -> is he looked at his buddy and he said,

1434.517 -> "Hey, look, I need to pass a role.

1436.52 -> What policy should I use?"

1437.69 -> He Googled it.

1438.523 -> He found this piece of code.

1439.64 -> He pasted it in and said,

1440.937 -> "All right, I'm gonna go build it."

1442.7 -> So this is the policy that he's trying to build.

1445.64 -> Now I'm gonna take a few seconds here

1447.8 -> to explain the policy for people

1449.69 -> who are not versatile roles and policies.

1453.83 -> So this policy is called IAM 3 5 demo policy.

1458.51 -> And if you look at the statement, what it does,

1461.45 -> its action is IAM PassRole.

1465.47 -> The effect is allow,

1467.3 -> and the resource is star.

1469.58 -> What it basically means in a nutshell is

1472.49 -> whoever has this policy is allowed to pass a role

1477.02 -> to a resource or an entity.

1479.81 -> This policy is a very permissive policy.

1482.84 -> Why?

1484.1 -> Let's take a simple scenario where

1485.93 -> you have developers and DevOps engineers

1488.57 -> in your environment trying to create

1490.7 -> infrastructure for example, right?

1493.55 -> And they write this code

1494.96 -> and have the policy assigned to them.

1496.7 -> Now remember, the developer and the DevOps engineer

1499.07 -> can build EC2 instances, right?

1501.14 -> Because that's what they're supposed to do,

1502.4 -> is build it, build servers.

1504.65 -> If they have this policy,

1506.81 -> they can build a server

1508.52 -> and then assign server an administrative role, right?

1512.39 -> Because there's nothing stopping them.

1513.77 -> So if there is no underlying other policy

1515.75 -> that stops them assigning this role,

1518.39 -> the developer or the DevOps engineer

1520.07 -> can assign the server an administrative role,

1523.64 -> All he has to do is log into the server

1526.58 -> and use server's credentials to make API calls.

1529.76 -> So suddenly you have a developer with limited role.

1532.55 -> He spins up an EC2 instance and he becomes an administrator.

1536.03 -> So that's how this role is really very permissive.

1539.54 -> So going back to our App100, this developer

1543.98 -> who's new to Terraform and AWS tries to build this policy.

1548.63 -> It gets intercepted by the validation stage,

1551.57 -> the validation stage reviews this policy

1554.27 -> that it's trying to build.

1556.13 -> And it says, "Uh-oh, no go."

1558.77 -> So if there is no feedback loop

1561.08 -> and if we just break the build,

1562.31 -> the developer will never know what went wrong.

1565.07 -> He'll be clueless.

1566.6 -> So what we do is in the email feedback

1570.26 -> that we send back to the developers,

1572.33 -> what we do is we have a detail instruction

1575.39 -> on why the build failed,

1577.55 -> which includes anything that was non-compliant

1580.31 -> from a validation stage.

1581.69 -> So let's take a look at a snippet, not the entire email,

1584.12 -> but we have a little snippet

1585.14 -> of what the developers get back, right?

1590.99 -> Oops.

1592.07 -> I keep switching back and forth.

1594.95 -> So this is a points of code that they will get in an email.

1600.83 -> Now looking you'll see a lot of different lines and context.

1605.27 -> I'm gonna highlight a few of them

1606.77 -> that are essential to you reading it.

1608.96 -> The first one is finding severity,

1611.9 -> which is highlighted in green.

1613.91 -> Finding severity is a logical conclusion

1617.24 -> that validation stage reaches

1619.37 -> after evaluating your policy

1621.11 -> and the Guardian's security baseline.

1624.74 -> It finds that this policy is high in severity.

1628.31 -> The reason why this is important

1630.26 -> is because as you write your own CI/CD pipelines,

1633.32 -> you can interpret this

1635.78 -> and let the build pass in lower environments.

1638.63 -> So for example, if the developer is building this policy

1641.6 -> in your dev environment,

1642.98 -> you might not wanna break the build.

1644.75 -> You might just wanna warn him.

1647.06 -> So that logic can be built in with the severity finding.

1650.09 -> Whereas if it's production,

1651.35 -> you obviously don't want him to build this.

1656.87 -> The next is the policy details itself.

1661.55 -> So remember our App100,

1663.29 -> the developer is trying to build a role.

1665.69 -> Now that role can have a lot of different policies in it,

1669.59 -> and all these policies are getting evaluated, right?

1672.68 -> So if you get a failure,

1675.11 -> which policy is it complaining about?

1677.36 -> So basically, this gives you an ARN number

1680 -> and the name of the policy that it has found issues on.

1687.08 -> The next is defining type, which is a security warning.

1691.76 -> And the most important one

1692.99 -> that I find it really useful for developers

1695.48 -> is learn more links.

1698.21 -> Now, usually, the learn more links

1700.13 -> is an AWS documentation website

1703.49 -> that will tell you why this policy

1706.13 -> that you're trying to build is dangerous

1708.02 -> and also would recommend you

1711.794 -> to tighten down the permissive policy.

1715.28 -> So I'll give you an example where our App100

1717.2 -> if he's trying to build this app, he will get an email.

1719.81 -> And when he clicks on the link,

1721.49 -> which is at the bottom of your screen here,

1723.68 -> it will open up a well-documented AWS page,

1726.11 -> and AWS has tons of documentation on policy best practices.

1731.03 -> So going back to IAM role or IAM PassRole,

1736.19 -> It will tell you why IAM PassRole with wildcards

1740.33 -> is a very permissive policy.

1742.94 -> And then it'll also tell you

1745.19 -> different ways you can remediate these policy

1748.22 -> or different guardrails that you can keep

1750.11 -> to tighten this policy down.

1752.18 -> now With experts, with security experts,

1755.78 -> this is a no-brainer, right?

1757.07 -> You can see IAM PassRole.

1758.027 -> You can see...

1759.29 -> But as a developer,

1761.66 -> I have no knowledge about what IAM PassRole is.

1764.39 -> This plays very critical role in the feedback process

1767.57 -> because now I can read through why what I did was wrong,

1771.17 -> and what can I do to fix it

1773.03 -> just by looking at the documentation,

1774.56 -> instead of reaching out to security team, asking them,

1776.877 -> "Hey, something's broken. Take a look at it."

1779.42 -> So he can then go back to code and fix the code.

1786.14 -> So there will be times when developers will come to you

1788.84 -> and they will say, "No matter what, I need this built."

1794.3 -> Whatever security filings we need to file, we can file,

1797 -> but the application needs to access this resource

1799.91 -> in this particular fashion.

1802.19 -> The tool is designed to take exceptions

1804.56 -> because we all know there's gonna be rules

1806.27 -> and there's gonna be exceptions, always.

1809.72 -> So here, the exception process is a centralized process,

1814.19 -> which is monitored by the security team

1817.37 -> and it's approved by the security team.

1819.26 -> Since it's a centralized process,

1820.7 -> it goes through peer review process,

1822.38 -> and then it goes through the security review,

1825.17 -> and then there's the risk filing,

1826.43 -> and then there's the exception

1827.6 -> that are written down into a file.

1831.5 -> So let's take a look going back to our Application 100,

1834.86 -> and our developer who somehow found

1836.66 -> a snippet of code on Google

1838.04 -> is trying to build a policy for IAM PassRole.

1841.64 -> He gets an email, he understands,

1844.16 -> but then he's still adamant because the application

1846.29 -> needs the IAM PassRole For whatever reason.

1848.48 -> I can't think of any,

1849.32 -> but if you guys can think, just let me know.

1852.86 -> So here is a developer who said,

1854.367 -> "Well, I'm gonna file an exception."

1856.34 -> Because it's a documented process,

1857.78 -> the email has the link to the documentation.

1860.24 -> So he files an exception which goes through peer review.

1863.75 -> And then it goes to the security team for reviewer process

1867.05 -> before they get in merge.

1870.08 -> Important thing here to notify

1871.58 -> is there's two kinds of exception process

1874.01 -> that the tool can handle right now.

1876.26 -> There's a global exception,

1878.39 -> which basically covers the entire umbrella.

1880.76 -> So you can say no matter what application

1883.67 -> this account is allowed to build

1885.527 -> IAM PassRole with the start in it.

1888.11 -> And then it will not make,

1889.22 -> it will not interfere with you building any applications

1892.79 -> with that particular policy.

1895.34 -> And there is an application-based exception.

1898.73 -> Remember we talked about each individual application

1901.31 -> having a code,

1902.69 -> so we basically tie down the application

1905.27 -> and the exception process using the code.

1910.04 -> So zooming IAM PassRole,

1911.63 -> the developer have now raised a PR with the security team,

1915.65 -> and the security team has, for some reason, approved it.

1919.16 -> It gets merged into the policy exceptions files repo.

1922.97 -> So now we have an exception filed.

1927.26 -> So holistically, let's take a look at the diagram again,

1930.11 -> and this is the logical view of how the tool works.

1932.99 -> So at the bottom, you have the tooling team,

1935.3 -> Their tool gets called during the validation stage.

1938.18 -> In the midsection, you have developers

1939.83 -> trying to build the infrastructure.

1941.9 -> And at the top, there's a security team

1944.57 -> that is managing the exception process.

1947.06 -> So going back, the developer now has the exception in place.

1951.11 -> Now he triggers the pipeline again.

1953.45 -> It goes to the build stage.

1954.62 -> It goes to the validation stage.

1956.66 -> Validation stage says some resources found.

1959.9 -> Which resource? IAM policy.

1961.85 -> Call IAM Access Analyzer.

1963.89 -> IAM Access Analyzer says, "This is my findings."

1967.37 -> The validation stage says,

1968.637 -> "Oh, this is a very permissive policy.

1971 -> I'm gonna mark it as non-compliant."

1972.53 -> However, because the tool

1974.72 -> is now equipped to handle exceptions,

1978.14 -> instead of breaking the build,

1979.76 -> what it's going to do is it's going to see

1981.95 -> if there's an exception filed at a global level.

1986.06 -> Right?

1986.893 -> Is an exception available at global?

1988.97 -> If it is, don't care, you can pass.

1992.87 -> If it doesn't find any global exceptions,

1995.84 -> it then looks for the application-based exception.

1999.83 -> So if this particular app, which is App100,

2002.98 -> has an exception file.

2004.33 -> So in our case, it does find the exception.

2008.53 -> Because it finds the exception,

2010.9 -> now instead of marking the policy as non-compliant,

2013.87 -> it is going to mark the policy

2015.09 -> as compliant policy with exception,

2018.46 -> and then it'll be allowed to move on to later stages

2021.79 -> where the actual infrastructure is being built.

2025.6 -> Right?

2026.433 -> So what do we get out

2027.266 -> of all of these things we talked about?

2029.68 -> There's a couple of high bullet points that we cover

2033.46 -> from a developer experience perspective, right?

2036.01 -> So this pipeline not only helps you be accountable.

2039.52 -> So every developer is accountable

2041.35 -> for the resource that they try to create.

2044.23 -> It has a faster loop back cycle

2045.79 -> because you get an email instantly once you have ran.

2048.61 -> You have a link. You click on it.

2049.9 -> You read through it. You make your change.

2051.31 -> You start again.

2052.81 -> So it's a great feedback loop.

2054.85 -> Plus, it empowers the developers

2056.86 -> because now the developers can write their code

2059.17 -> and change them very quickly based upon the response.

2063.82 -> And because they're able to do so, ultimately,

2066.67 -> you have a very happy developer experience, right?

2070.36 -> So we talked a lot about the tool in the logical sense.

2073.39 -> We looked at the diagram and the workflow

2075.79 -> and how it's engineered.

2077.53 -> I bet you guys will be really thrilled

2079.57 -> to see this in action, so I'll give it to Bohan

2082 -> who's going to give us a live demo of the tool.

2090.52 -> - Thank you.

2097.42 -> Thank you, Hetul, for walking us through the solution.

2102.91 -> Now let's take a look how it works in action.

2110.08 -> Let's first take a look the environment

2113.53 -> that was set up for this demo.

2117.76 -> We're using AWS CodeCommit as our source code repository,

2122.71 -> where the Terraform template is stored.

2126.55 -> We've created a CI/CD pipeline using AWS CodePipeline

2130.78 -> and the AWS CodePipeline built

2132.4 -> that I will explain shortly.

2135.88 -> So the pipeline starts when I commit to AWS CodeCommit.

2141.877 -> AWS CodePipeline will detect

2144.85 -> a change in my source repository,

2148.75 -> and it will cause a AWS CodeBuild project,

2152.65 -> which invokes IAM policy compliance check tool.

2159.34 -> So if the IAM policy compliance check tool

2162.76 -> completes successfully,

2165.876 -> it will cause a separate project AWS CodeBuild project

2169.96 -> to deploy Terraform template.

2176.44 -> Now, let's come back to this diagram

2180.22 -> and take a look what we're doing here in this demo.

2185.26 -> For step one, I already completed,

2189.19 -> as part of my environment setup,

2192.37 -> where I committed the source code of

2195.13 -> IAM policy compliance check tool code

2199.69 -> to my AWS CodeCommit source code repository.

2204.52 -> Now in the demo, I am a developer.

2208.33 -> I'm going to commit a Terraform template to AWS CodeCommit.

2215.62 -> The pipeline detects a change,

2218.98 -> and then begins step three,

2221.56 -> the validation stage.

2224.29 -> Now in the validation stage,

2226.27 -> again, it invokes IAM policy compliance check tool.

2232.81 -> Basically, what he does,

2234.37 -> it extracts IAM policies from my Terraform template

2238.57 -> and runs through policy validation with IAM Access Analyzer

2243.43 -> showing as a step 3.1 at the top of the screen there.

2250.66 -> Now in this demo, I'm going to skip the steps

2253.27 -> before tracking exceptions.

2256.18 -> And then I will show you step four,

2258.46 -> where I get a failed pipeline

2260.56 -> because my Terraform template

2262.51 -> contains a problematic IAM policy.

2267.76 -> Now, as a developer, I'm going to look into

2270.55 -> the pipeline execution details

2274.3 -> and use the information provided to me

2277.57 -> and attempt to fix my IAM policy.

2282.16 -> Then I go back to step two.

2284.59 -> I commit changes,

2286.78 -> repeat step three.

2288.88 -> And finally, I will reach to step five

2292.06 -> where the validation stage completes successfully,

2295.75 -> and then my Terraform template is deployed.

2301.48 -> One final thing before we get to the demo,

2304.78 -> let's take a look at the IAM policy

2307.51 -> we're using in this demo.

2312.46 -> So the IAM policy on the screen here

2316.09 -> allows me to perform some lambda operations.

2321.82 -> Let's take a look at the statement at the bottom

2325.15 -> with IAM PassRole pastor

2326.92 -> to see how I scope down permissions here.

2331.284 -> As Hetul explained, I want to scope down,

2335.14 -> I want to restrict my PassRole's permission.

2338.71 -> Using a namespace really helps here.

2342.31 -> In this case, I'm only allowed to PassRole's

2347.622 -> in the namespace of a topping,

2350.53 -> and I'm only allowed to PassRole's to lambda functions.

2355.72 -> It's restricted by the condition block.

2358.6 -> So I have a condition here saying,

2361.24 -> PassRole service equals to lambda.

2365.14 -> Now, in the demo, I'm going to start

2368.2 -> with a different version of this IAM policy

2371.83 -> with pretty broad permissions,

2374.29 -> and then I will show you how I use

2376.78 -> the CI/CD pipeline solution we described this presentation

2381.28 -> to help me scope down permissions.

2392.23 -> Now we're at AWS console.

2394.93 -> Let's first go to AWS AWS CodeCommit.

2407.68 -> So we can see two source code repository here.

2411.91 -> The first one is to store my Terraform templates,

2415.03 -> and the second one is to store the source code

2417.61 -> of IAM policy compliance track tool.

2420.64 -> Let's go take a look at my Terraform template.

2428.44 -> So for folks who

2430.75 -> are not familiar with Terraform in the room,

2434.44 -> this is a very common structure

2436.75 -> of a testing or small Terraform project.

2440.35 -> And the main code is the stored in main.tf file.

2445.27 -> Let's go take a look what's in there.

2456.55 -> On line three, I am trying to create IAM policy document.

2462.79 -> You may notice that, in the first statement,

2467.95 -> the pass execution role statement,

2471.19 -> I have really brought PassRole permissions

2474.4 -> that allow me to pass any role.

2478.78 -> So moving on.

2481.12 -> The second statement is allowing me

2483.16 -> to browse Lambda functions.

2489.76 -> And the third statement here is allowing me

2492.49 -> to view and create some lambda functions.

2499.12 -> On the line here,

2502.3 -> the lambda function I'm allowed to view and create

2505.45 -> is restricted to the current account,

2510.55 -> also in the name space of a pizza.

2518.68 -> Finally, on line 41,

2520.9 -> I'm trying to create an IAM policy resource

2524.26 -> using the policy document I just created.

2529.27 -> Now question time.

2532.18 -> When I commit this Terraform template to AWS CodeCommit,

2537.16 -> my source code repository,

2539.71 -> raise your hand if you think my pipeline is going to fail.

2547.9 -> And raise your hand if you think my pipeline is gonna pass.

2555.91 -> All right, so there's no right or wrong answer

2559.48 -> to my question.

2563.23 -> The decisions of

2567.19 -> flagging a pipeline as fail or pass

2570.67 -> is a piece of a code of the tool.

2574.24 -> You have the flexibility to define

2578.41 -> what factors can impact the decision

2582.61 -> and how your decision can be made.

2585.4 -> So the factors can be the finding severity,

2589.12 -> the finding type, the environment you're running in,

2593.29 -> or your AWS account ID.

2596.92 -> So now the current configuration of my tool

2600.94 -> that I'm using in this demo

2603.43 -> is based on finding type

2607.06 -> returned by IAM Access Analyzer.

2611.5 -> Furthermore, I define that any security warning type finding

2617.65 -> is going to make the tool execution unsuccessful.

2623.62 -> Now with that in mind, let's go take a look

2626.98 -> my pipeline execution.

2639.04 -> Now we're at AWS CodePipeline console.

2642.79 -> I've created this CI/CD pipeline for this demo.

2651.28 -> We can see that the pipeline failed at the second stage,

2655.807 -> the validation stage.

2657.97 -> Now let's take a look what's going on there.

2666.67 -> So the pipeline execution logs

2670.48 -> contain a lot of information.

2673.33 -> It contains the information such as

2677.98 -> installing dependencies,

2681.19 -> downloading the source code.

2684.67 -> And we are going to jump into the output

2688.9 -> of IAM policy compliance check tool.

2694.06 -> To make it easier to walk you through the logs,

2696.82 -> I'm going to look for keyword.

2711.46 -> Before I get into the output of the tool,

2716.14 -> let me quickly walk you through

2720.25 -> how the tool is involved.

2724.33 -> So on line

2726.64 -> 457

2729.31 -> is where we invoke the tool.

2732.07 -> So we are seeing here is I am invoking a Python project,

2738.07 -> and then there are some parameters

2740.32 -> are required to pass into the tool.

2744.55 -> So I wanna take a closer look of one of the parameter,

2749.53 -> the template pass.

2755.47 -> So template pass is a parameter that is looking for

2759.91 -> the pass to a file

2762.64 -> that is a human readable file generated

2765.73 -> from Terraform plan file.

2769.69 -> So before we invoke this tool,

2774.07 -> a list of commands will run,

2777.73 -> starting from...

2779.68 -> First, we run Terraform plan.

2782.59 -> We save the output file to a file,

2785.8 -> and then we generate a human readable file

2789.85 -> from this plan file.

2791.95 -> Specifically, we run a command Terraform show.

2798.31 -> And then we are gonna save that human readable file.

2803.2 -> We are gonna save the pass to that file into a variable.

2807.07 -> In this case, the plan pass is that variable,

2811.48 -> and we're gonna use that to invoke the tool.

2818.26 -> The output of the tool

2821.47 -> falls into two categories,

2824.17 -> blocking findings

2825.82 -> and the non-blocking findings.

2828.31 -> So blocking findings are the findings

2829.827 -> that's gonna fail my pipeline,

2832.15 -> versus non-blocking findings.

2834.16 -> It still gives me details about the findings

2837.73 -> however it's gonna pass the pipeline.

2843.1 -> So if you remember, as I explained just now,

2848.56 -> I am defining any security warning type of funding

2853.15 -> is gonna fail my pipeline.

2856.9 -> So we are seeing here on line 461.

2860.83 -> I have a security warning type of finding.

2864.25 -> There are a lot more information here.

2866.59 -> For example, on line 463,

2870.612 -> it has a message basically telling me

2873.4 -> why this IAM policy gets this finding.

2877.99 -> And on line 464 here,

2882.1 -> it gives me

2884.53 -> the name of the IAM policy

2887.14 -> that generates the finding.

2888.91 -> In this case, it's called demo policy.

2892.51 -> So if I'm a developer,

2896.075 -> I'm writing Terraform template,

2898.15 -> contains multiple IAM policies,

2900.55 -> this will help me to quickly pinpoint

2903.22 -> which IAM policy is causing the problem.

2908.26 -> And finally, on line 470,

2913.72 -> this is the learn more link that Hetul just explained.

2917.44 -> So this is a link,

2919.03 -> point you to a AWS public documentation

2923.05 -> to tells you what is this finding about

2925.63 -> And then what are some action items you can do

2929.08 -> to remediate this finding?

2932.8 -> Now,

2935.02 -> I have all these information

2937.9 -> and I'm going to attempt to fix my IAM policy.

2956.23 -> I'm using Cloud9 as my development environment

2961.12 -> and my IDE.

2964.72 -> So I'm going to fix this pass role statement

2967.96 -> and then scope down the permissions.

2972.76 -> I've prepared a snippet.

2977.38 -> So I'm going to copy on the paste it.

2985.18 -> So how am I scoping down permissions here?

2988.9 -> Again, first, I'm restricting

2992.41 -> the roles that allow to pass to the current account

2997.09 -> in the namespace of a topping.

2999.76 -> And then I added a condition block

3003.72 -> that allows me to only pass those to lambda functions.

3010.47 -> So

3013.08 -> I'm going to

3015.93 -> save and commit the changes.

3023.46 -> As soon as I push the code to my repository,

3027.75 -> the pipeline is gonna detect the change

3030.45 -> and the trigger in execution.

3032.7 -> It's gonna take a couple minutes to execute.

3035.52 -> So what I'm gonna do is I'm gonna show you

3038.4 -> an execution history.

3042.21 -> Then I'm going to walk you through the details

3044.28 -> so that we can save a couple minutes there.

3051.99 -> So I am going back to my pipeline.

3061.47 -> I'm going to click on history.

3066.09 -> So I have a pipeline that

3072.33 -> was successful

3074.91 -> in the past.

3076.44 -> Let's go take a look.

3085.71 -> I'm going to click on virtualization,

3092.76 -> and then let's go to validate stage to take a look.

3096.9 -> Again, I'm going to search for keywords, blocking findings,

3101.25 -> 'cause remember those are the findings gonna block my,

3104.58 -> gonna fail my pipeline execution.

3115.83 -> So,

3117.859 -> we're seeing here I got zero blocking findings.

3123.45 -> That's why my pipeline was executed successfully.

3128.85 -> I still got a non-blocking funding.

3131.88 -> So what it's telling me is that this is suggestion

3135.45 -> that one of the statement in my IAM policy is missing a sid.

3141.99 -> So as a developer,

3143.61 -> I have a option using this information

3146.34 -> to further improve my IAM policy.

3149.25 -> However, I got a successfully executed pipeline.

3156.45 -> So to conclude,

3159.09 -> I started with a Terraform template

3162.36 -> containing a very permissive IAM policy.

3166.92 -> Then I used this CI/CD pipeline solution

3171.42 -> to provide me with feedback and information

3174.42 -> and help me to scope down the permissions in my IAM policy.

3193.35 -> So with that, I'd like to hand it back to Michael

3198.03 -> to talk about what we accomplished.

3199.86 -> - Yeah.

3201.24 -> Thank you, Bohan, for making that real for the audience.

3204.21 -> We've come a really long way.

3206.37 -> We came from a world where there's one of two

3208.89 -> not great possibilities.

3210.78 -> We have fully empowering developers,

3213.54 -> but most likely giving way more access

3216.15 -> than what we'd really like,

3217.56 -> or the other one, we injecting security

3220.41 -> deeply into the process,

3221.67 -> manually blocking developers and stifling innovation.

3225.66 -> Neither of scenarios are great.

3228.96 -> We have now shown you a solution

3230.31 -> where we go ahead and automate that interaction,

3233.43 -> blurring the lines between security and tech

3237.972 -> so we can innovate quickly

3239.34 -> while still having the proper security.

3244.05 -> So we've gone ahead and shown you

3245.97 -> a lot of technical aspects today,

3248.01 -> but this also has clear visibility, and knowledge,

3251.91 -> and respect from our senior leaders.

3254.43 -> This is a quote from our deputy CSO, Greg K.

3258.24 -> Sorry. I cannot say your last name, Greg.

3262.38 -> This is a quote from him that basically says,

3264.39 -> look, we can go ahead and fastly deploy code

3268.5 -> while also making sure that our controls

3271.23 -> aren't over-permissive.

3273.12 -> This goes ahead and supports the overarching

3278.13 -> trend in the industry

3279.9 -> to go ahead and shift left with security

3282.81 -> and blur the lines between the organizations.

3288.39 -> So before we end, just wanted to say

3290.91 -> please fill out your surveys.

3292.71 -> We are gonna take Q&A on the side.

3295.32 -> Thank you, Bohan.

3296.37 -> Thank you, Hetul for your time,

3297.84 -> and thank you all for your time.

3300.06 -> Have a lovely day.

3301.608 -> (audience applauding)

Source: https://www.youtube.com/watch?v=3o_H0G18_hY