AWS re:Invent 2022 - Detect vulnerabilities in AWS Lambda functions using Amazon Inspector (SEC217)

Aug 16, 2023

AWS re:Invent 2022 - Detect vulnerabilities in AWS Lambda functions using Amazon Inspector (SEC217)

Developers are moving toward serverless compute, like AWS Lambda, for reduced infrastructure management, more efficient scaling, and reduced costs, but serverless workloads must be monitored for vulnerabilities in application code. In this session, learn how you can now use Amazon Inspector to detect vulnerabilities in your AWS Lambda functions in addition to software vulnerabilities and unintended network exposure in Amazon EC2 and container-based workloads. Learn now Amazon Inspector automatically discovers and inventories all existing and newly created Lambda functions for scanning and continually monitors to automatically detect issues. Inspector gives you a single view of your workload vulnerabilities and helps you prioritize remediation through its highly contextualized severity scoring.

Learn more about AWS re:Invent at https://go.aws/3ikK4dD.

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.

#reInvent2022 #AWSreInvent2022 #AWSEvents

Content

0.96 -> - Hello everyone and welcome.

2.88 -> I'm Rick Anthony and I'm joined here with Kashish Wadhwa

7.68 -> and we're both from the Amazon Inspector team

10.74 -> and we're very excited to talk to you about Inspector

15.537 -> and a new capability we launched to detect vulnerabilities

20.01 -> in Lambda functions.

23.76 -> So today we're going to go give you a little bit

27.362 -> of background about Amazon Inspector.

28.59 -> Kashish and I were here last year at re:Invent almost a year

33.63 -> to the day to introduce the brand new Amazon Inspector.

38.032 -> So we'll go in that, what do we mean by that?

41.97 -> We'll talk about what problems was Amazon Inspector designed

46.02 -> to solve, how it works, how it achieves those goals.

49.29 -> And then I'll hand it over to Kashish and he'll give a demo

52.77 -> and talk about how we've extended it

54.78 -> to support serverless functions through Lambda.

61.44 -> So starting with, what is Amazon Inspector?

65.28 -> So Amazon Inspector

67.14 -> is a automated vulnerability management service

70.8 -> that continually scans workloads

72.9 -> for software vulnerabilities

74.19 -> and unintended network exposures.

77.295 -> One of the things I really wanted to kind of make clear

79.83 -> before we get too far into Inspector

82.68 -> is that there's two Inspectors that are on AWS.

88.032 -> There is the original Inspector that we launched in 2016

92.86 -> and then there's the one that we launched last year.

96.6 -> So the original one in 2016

98.28 -> is called Amazon Inspector Classic.

102.42 -> And then the new one's just Amazon Inspector.

105.06 -> And we launched that new version because of a couple

108.33 -> of challenges that we saw with how customers

111.24 -> were doing vulnerability and management

114.134 -> either through traditional methods or through classic.

118.14 -> And one of the big changes that we made

122.433 -> was to really build it for the cloud

125.1 -> and make it a continual scanning system.

128.16 -> And what do we mean by that?

129.93 -> So we wanted to make Amazon Inspector easy to use

134.448 -> and low administration,

136.504 -> easy enablement and continual and monitoring

140.4 -> where Amazon Inspector decides what to scan,

143.991 -> when to scan, so that instead of having a system

147.271 -> where you schedule things and have to worry about

150.668 -> am I seeing everything in my environment?

153.39 -> Inspector takes the burden for you.

157.395 -> Okay, so couple of the main challenges

160.71 -> that we were looking to solve.

162.93 -> Number one, we wanted to build Inspector for the cloud.

167.67 -> So the cloud is, it's elastic, it's flexible, it's fast.

174.15 -> One of the, when we talk to customers,

175.86 -> one of the challenges they talk about is

178.17 -> it's hard for me to know what are all the accounts

180.54 -> that just exist within my organization,

183.36 -> what are all of the resources,

185.174 -> how do I know that I'm scanning everything

189.03 -> when resources can come up and go down so quickly?

193.32 -> That's one of the things we wanted to solve

195.48 -> with the new Amazon Inspector.

197.708 -> Number two, we wanted to tell customers

201.283 -> how to manage vulnerabilities in near real time.

205.53 -> One of the challenges we saw is that customers,

207.634 -> because they were using vulnerability management

211.32 -> in a very traditional sense of scanning once a week

214.44 -> or once a month or once a quarter,

216.36 -> they had to be really hyper aware

218.19 -> of what vulnerabilities were out there

220.552 -> because they had to know, hey,

222.54 -> if there's a brand new critical vulnerability,

224.67 -> is this important enough for me to now scan outside

227.139 -> of my normal window?

229.8 -> We wanted to kind of take that responsibility away

232.658 -> and hand it to Inspector so Inspector could do the work.

235.901 -> Number three, we saw that customers

239.18 -> as they went on their journey from scanning,

242.205 -> using EC2 workloads to container workloads

246.492 -> to Lambda workloads or serverless,

248.94 -> they were using different tools

250.8 -> where they were buying different modules and we wanted

253.89 -> to give customers a way

255.364 -> where they could do everything with one tool.

258.42 -> So that's why we support both EC2,

262.175 -> we support containers,

264.06 -> we support Lambda functions through Inspector.

267.36 -> And finally we saw customers struggling with,

270.48 -> once they had all the data, what do I do with it?

273.81 -> How do I action this data?

276.45 -> So we built Amazon Inspector in order to make it easy

280.89 -> to number one, know what's the state of environment,

284.73 -> number two, know what my findings are and number three,

288.45 -> easy methods to take those findings,

291.03 -> send them into other tools and action them.

296.19 -> So how do we do this?

297.69 -> How does Amazon Inspector address those challenges?

301.597 -> We're really gonna talk about three areas or three pillars

306.09 -> of Amazon Inspector functionality.

308.67 -> Number one

309.63 -> is what we call frictionless activation management.

313.053 -> Number two,

314.79 -> we're gonna talk about continual vulnerability monitoring.

318.36 -> And number three we're gonna talk about

320.55 -> how to prioritize and contextualize the results.

327.15 -> Okay, frictionless activation.

330.63 -> So the new Amazon Inspector

333.03 -> is integrated with organizations.

335.7 -> So one of the problems we talked about is how do I know

337.945 -> what all of my accounts are?

340.35 -> If you're using AWS organizations,

342.218 -> you can very simply plug that into Amazon Inspector

345.9 -> and now Inspector knows all of your accounts

349.55 -> and with a single click,

351.63 -> you can now activate Inspector everywhere.

355.59 -> And so, one of the things things that this allows you to do

358.674 -> is to ensure I've got coverage on everything

361.59 -> and Inspector has a capability where you can say,

365.797 -> "Okay Inspector,

366.93 -> as you see new accounts automatically enable yourself."

370.003 -> So now you're eliminating gaps in your coverage

373.426 -> and now you have security by default because everything

377.58 -> is now configured through organizations.

382.05 -> The second benefit of this

383.94 -> is that if you're using organizations,

386.138 -> you have a single pane of glass where you can see everything

390.75 -> for your organization.

391.8 -> So the way Inspector works is you assign

394.77 -> a delegated administrator,

396.57 -> use that administrator to enable Inspector,

398.942 -> configure your organization-wide settings

402.48 -> and all of the findings and all the data

404.802 -> that Inspector collects now shows up in a single pane

408.27 -> of glass as you view it as a delegated administrator.

412.23 -> And if you want even more flexibility,

414.06 -> we allow you to send that data out to Security Hub

417.42 -> because Security Hub has very nice features

419.49 -> for bringing all your data into a single region.

424.23 -> So as an example, the power of this,

426.81 -> we recently had a customer onboard and enable Inspector

430.86 -> for 7,000 accounts and they did this

434.34 -> with just a handful of steps.

436.325 -> Number one, they had their organization set up already,

439.174 -> they came to the Inspector console,

441.821 -> they assigned a delegated admin enabled Inspector

447.03 -> and through that delegated admin account

449.22 -> they just said okay, number one,

451.62 -> I want all new accounts enabled and number two,

454.44 -> I want to enable all existing accounts.

457.29 -> And that was it, they were done.

459.3 -> As Inspector turned on it looked at all their resources,

463.25 -> it started doing assessments and from that single view now

466.478 -> they can see all of their results,

468.96 -> all their findings for 7,000 accounts.

474.87 -> Number two, continual vulnerability monitoring.

478.44 -> So one of the challenges customers tell us about

482.37 -> is how do I know what I have?

484.23 -> All of my teams are constantly creating new resources,

487.464 -> how do I know that I'm seeing everything?

491.37 -> The cloud is fast, resources come up, resources go down.

495.69 -> Amazon Inspector keeps track of all these resources for you.

500.094 -> When you activate Inspector,

501.877 -> it inventories everything in your account.

505.185 -> So it inventories all your EC2 instances,

508.29 -> or it inventories all your container images.

512.16 -> And as you will see later with our demo,

514.32 -> it will also inventory all of your Lambda functions

517.559 -> and it will hook into AWS to monitor all your activity.

524.1 -> So if you launch a new EC2 instance, Inspector is aware,

528.03 -> if you push a new container image, Inspector is aware.

531.07 -> In the demo you'll see us

532.93 -> create a brand new lambda function.

535.997 -> Inspector will become aware of that

538.153 -> and it will scan it automatically.

541.05 -> So as an administrator, I have no work that I have to do,

544.62 -> Inspector just finds it and Inspector will then also monitor

550.08 -> what's installed in those resources

552.692 -> and reassess them as needed.

555.414 -> So vulnerabilities are being published every day

559.707 -> and like we talked about,

561.852 -> you don't want to have to be an expert

564.06 -> of how critical is this brand new vulnerability?

566.94 -> Do I need to go outside of my patching cycle?

568.968 -> Amazon Inspector monitors all the vulnerabilities

573.6 -> and as new ones are published,

575.119 -> it will look at your resources,

577.23 -> it will pick the ones that are impacted

578.874 -> and automatically reassess those

581.907 -> and generate findings for you.

585.45 -> Also, if you patch your resources,

588.13 -> Amazon Inspector is aware, it will go in, it will reassess,

593.1 -> it will see that you've remediated your issue

595.98 -> and it will close the findings for you.

597.78 -> So constantly when you go and look at Inspector,

600.379 -> you're seeing the state of your resources

603.69 -> as they are at that moment.

608.294 -> So one of the examples of this,

611.701 -> a few weeks ago there was a open SSL vulnerability

616.83 -> that was rated, I think some vendors rated as critical,

620.97 -> some rated it as a high vulnerability and for customers

626.94 -> that were using Amazon Inspector,

628.73 -> they didn't have to worry about it.

631.44 -> So as vendors like Red Hat, Ubuntu and others

635.246 -> did their analysis and published

637.68 -> their findings for that vulnerability,

640.74 -> Inspector automatically pulled that information,

643.68 -> found the resources impacted and just reassessed them.

647.73 -> So customers who were worried about that really had nothing

651.12 -> they had to do, they just came into work that morning,

653.256 -> they logged in and they saw, oh look,

655.868 -> Inspector's aware of this vulnerability,

658.14 -> it's already done the work for me,

660 -> here's my status and this is where I'm at.

666.57 -> And then the third pillar of Amazon Inspector,

669.54 -> prioritizing and contextualizing results.

672.445 -> So we know that vulnerability systems can generate

677.73 -> a lot of findings 'cause customers have a lot of resources

681.462 -> and sometimes it can get very overwhelming

684.6 -> to know what should I work on first?

687.33 -> What's really important for me in my environment?

691.648 -> Inspector tries to help you with that decision making

696.565 -> by providing something we call the Amazon Inspector score.

701.4 -> So the Amazon Inspector score takes into account

704.864 -> the severity of the vulnerability,

709.74 -> takes into account the network accessibility

714.27 -> of your resource.

715.77 -> It takes into account exploitability and other factors

719.073 -> and then will tell you how important

722.217 -> that vulnerability is to you and your environment

726.148 -> so that you can prioritize better and pick the things

729.21 -> that are really important to addressed first.

733.23 -> In addition to this,

734.211 -> Amazon Inspector keeps track

736.984 -> of all of your findings holistically.

738.845 -> So if you do patch or you do delete a resource,

743.441 -> Amazon Inspector is automatically closing those

746.85 -> so that you have a current state of the art

749.216 -> and if you want to take that data

751.991 -> and send it into another system,

754.797 -> those findings automatically flow into Security hub

759.06 -> for easy viewing.

760.35 -> We also send them out to EventBridge

763.92 -> so customers can take action on them,

766.452 -> either feed them into ticketing systems

768.81 -> or write their own remediation scripts

771.3 -> through things like SSM Patch Manager.

776.7 -> Okay, so little bit of background on Inspector.

780.75 -> So how does those things work for serverless?

785.1 -> I'm gonna turn it over to Kashish to continue.

788.85 -> - Thanks Rick.

790.08 -> Before we move on to security for serverless functions,

793.347 -> one key point that Rick brought up was around

796.98 -> using EventBridge to automate remediation.

799.98 -> So we did recently publish a blog

801.888 -> with cloud formation templates where we showed

805.77 -> how you could take or enable Inspector, activate it

810.227 -> and if you have that solution in place,

813 -> that would automatically remediate all your findings

815.76 -> in real time using SSM Patch Manager.

818.52 -> So that was pretty impactful

820.2 -> because customers not only could identify

822.66 -> these vulnerabilities in real time,

824.61 -> they were automatically getting patched or EC2 instances

827.52 -> were getting patched in real time also.

829.95 -> Another blog that we recently published

832.2 -> was around container images where while it is important

837.12 -> to scan for vulnerabilities,

838.47 -> more important thing is to prevent the deployment

841.83 -> of those images or those vulnerable images in production

844.8 -> so that it's not exploited.

848.16 -> If you look at some of the studies done by prominent vendors

852.12 -> in the space between 2020 and 2021,

855.66 -> the time took to exploit a vulnerability

858.12 -> has gone down by 70%.

860.37 -> So there are bots

861.39 -> that as soon as your EC2 instance comes up,

864.12 -> they will try to poke it, they will try to see

866.76 -> how we can exploit it.

868.11 -> And if there is a critical vulnerability like open SSL

872.52 -> or any critical vulnerabilities

874.59 -> that have been published in the last year,

876.63 -> it's really easy to for them to exploit it

879.24 -> even before you know it.

882.865 -> So moving on security for serverless

885.54 -> and as we were talking about it is really important

888.44 -> for customers to kind of get a whole picture

892.47 -> of their overall landscape in compute world.

894.749 -> We saw 10 years ago we started with EC2 instances,

899.4 -> which is virtual machines.

900.6 -> Then we moved on to containers

901.98 -> in the last five to six years.

904.2 -> Now the industry trend is to move towards serverless.

907.26 -> I have spoken to a lot of customers

908.94 -> that only use serverless now

910.29 -> they don't even use containers

911.52 -> just because it's easy to use.

913.65 -> They don't need to have administration teams just

916.29 -> to manage the infrastructure.

918.33 -> So with that move we thought since customers

922.099 -> are using this vulnerability management

924.36 -> Inspector vulnerability management

925.8 -> for EC2 instances and container images,

927.99 -> it is equally important for serverless functions

930.812 -> and soon compliance requirements will also cover those

934.089 -> in addition to containers and traditional vulnerability,

938.19 -> traditional virtual machines.

941.73 -> So talking about the shared responsibility model

944.43 -> for serverless functions,

945.859 -> even though it is completely managed,

947.986 -> AWS manages the infrastructure, the hardware,

951.637 -> even the compute,

953.002 -> but the applications that you deploy

955.65 -> on that serverless infrastructure

959.054 -> is still responsibility of the customer.

962.31 -> So think about the code that you write is still susceptible

968.52 -> to exploitation or the dependencies

971.7 -> that you use are still like valid for exploitation.

974.776 -> One of the major things that we have seen

977.7 -> with lambda functions

978.63 -> is that there's a exploit called well poisoning.

983.7 -> Where if you have a certain,

986.257 -> if you have a certain package which is vulnerable

989.85 -> and you maintain some sort of repository

991.92 -> and regardless if your function

995.07 -> is accessible through API gateway,

996.99 -> external network or not,

998.7 -> if you're using that specific package,

1001.4 -> it could still be exploited.

1003.53 -> Then there are resource configuration and IM issues

1005.93 -> with functions which can still be exploited.

1009.44 -> So there are a lot of things that makes it really critical

1012.68 -> for us to tackle the problem around serverless functions

1018.2 -> or lambda functions also.

1019.85 -> And we wanted to give a single pane of glass

1022.16 -> because if you think about it the same,

1023.7 -> let's say hypothetically there is a vulnerable package,

1026.733 -> Python 2.7.

1029.21 -> Now you could use the same package in your EC2 instance

1031.7 -> in your container image and in your serverless functions,

1034.76 -> which is lambda functions.

1036.17 -> So you don't need three or four solutions

1038.78 -> or different modules or different solutions

1040.52 -> to kind of tell you the same thing with different details.

1043.957 -> Any solution should be able to give you that single source

1047.63 -> of truth and the goal is that you are able to go

1051.095 -> and remediate or update that package or issue

1054.53 -> that guidance to your organization

1056.612 -> that we don't need to use this package.

1060.218 -> So for example,

1062.24 -> internally we had a similar issue in the past

1065.39 -> where there was an organizational level decision

1068.54 -> that you can't use a specific package anymore

1071.48 -> just because it is vulnerable.

1072.98 -> So we had to identify even in our systems

1075.35 -> where all are we using that package.

1078.35 -> So it's really critical to have that inventory

1081.631 -> where all these packages are in in my entire environment

1087.26 -> and then it's about how do I go and rebuild it, patch it.

1090.17 -> So this is one of the reasons we try to bring

1093.466 -> this up forward before any other features.

1100.85 -> So what's new essentially how would the scanning

1106.7 -> for serverless functions work?

1108.32 -> I will show this in the demo, but how Rick explained,

1112.46 -> we have tried to make a very consistent operating model

1117.02 -> for serverless functions also.

1119.18 -> So for existing customers

1120.89 -> who are already using Amazon Inspector,

1122.75 -> they have to go to their account management page

1125.12 -> and just with one click and enable all their accounts

1127.917 -> for lambda standard scanning.

1130.88 -> With that, as soon as they click that,

1133.31 -> what will happen is we will go and discover lambda functions

1136.28 -> that exist in their accounts across or all the accounts

1140.632 -> within their organization

1142.078 -> and we'll automatically start discovering them.

1145.55 -> As soon as they're discovered,

1147.02 -> we will automatically scan them for software abilities.

1150.11 -> So what I mean by that is we will go

1153.14 -> and extract the lambda function,

1154.37 -> we will look at all the dependencies

1156.697 -> that are being included in that.

1159.26 -> We take an inventory of that and we will generate findings.

1162.738 -> And as let's say if you update a function,

1167.905 -> because I've talked to a few customers

1170.15 -> who have regular updates scheduled,

1174.303 -> if there's, let's say a dependency,

1177.079 -> they continuously update those functions every day

1178.85 -> or sometimes every 12 hours so that they make sure

1181.55 -> they're using the latest dependency version.

1183.439 -> So in traditional vulnerability management

1187.062 -> what you would have to do is either you scan every day,

1190.94 -> every week or every month, whatever that is it,

1193.622 -> it still leaves the room to possible exploitation

1199.94 -> because you still have that vulnerable package

1202.679 -> or overall software

1204.86 -> being used in your production environments.

1207.02 -> With Inspectors, since we auto discover not only

1209.783 -> when it is deployed, when you update a function

1212.84 -> and all this is in near real time,

1214.79 -> I would say 30 to 45 minutes or most of the times

1218.3 -> it'll be within seconds or minutes,

1220.04 -> but at max it could take 30 to 45 minutes.

1222.415 -> So as soon as you update a function,

1226.1 -> we will automatically discover and we will trigger a scan

1228.8 -> which will go and generate new findings

1231.14 -> if there is any delta in the packages

1234.44 -> that are used or the version of the packages that are used

1236.806 -> and on the other side.

1240.26 -> So this is what we kind of monitor your environment.

1243.385 -> Then we also monitor CVE landscape.

1247.13 -> As Rick alluded to earlier,

1248.48 -> we built a purposeful vulnerability intelligence database

1251.84 -> for the new Inspector and we consume over 50 sources

1255.284 -> in our database and that includes some

1260.42 -> of the prominent sources like sneak intelligence

1264.17 -> that we got procured licenses for.

1265.783 -> We also recently procured additional licenses

1268.518 -> from some other vendors for threat intelligence.

1272.101 -> And one of the things that we have added now,

1275 -> we not only give you, these are the findings,

1278.06 -> we also give you additional vulnerability intelligence.

1280.52 -> So think about when was this last CVE exploited?

1284.81 -> So CVEs, have a CVEs score as you, I'm sure you all know,

1291.05 -> let's say there is a CVE with CVE score of 10.0

1294.161 -> but it hasn't been exploited in the last five years, right?

1299.12 -> And there is a CVE with a CVEs score of let's say 9.1

1303.676 -> even though the score is lower,

1305.84 -> but we know that it has been exploited yesterday

1308.771 -> or this morning in the wild,

1310.58 -> not in your environment but in the wild,

1312.77 -> that automatically becomes more important

1315.47 -> and if there is a fix available,

1317.372 -> if you correlate both that data,

1319.64 -> it's slowly easy for you to identify these are the resources

1322.67 -> or these are the findings I need to address first

1325.19 -> and then I can tackle the later ones.

1327.2 -> Because one of the things we consistently heard

1329.42 -> from security teams including internal security team,

1332.96 -> that it's really hard to even go

1334.79 -> and remediate the criticals and the highs,

1337 -> let alone the mediums and the lows or the informationals.

1340.73 -> It's just the sheer volume of findings

1342.77 -> that are generated not in just in Inspector,

1346.91 -> just it's the nature of the space

1348.92 -> and it's just slowly hard to remade that.

1352.16 -> So like Rick was telling you about the prioritization,

1357.98 -> we do that for you.

1359.75 -> Our main goal with Inspector is that security teams

1363.29 -> should not be focused on managing a solution,

1366.47 -> deploying an agent are just the operational overhead

1370.728 -> that is associated with vulnerability management.

1373.85 -> They should be focused on remediation,

1375.71 -> implementing compensating controls

1377.96 -> or just focused on improving security.

1382.07 -> Maintaining a solution should be

1384.32 -> like solution should be good enough to do that.

1386.18 -> So that was our main tenant

1388.37 -> when we decide to rebuild Inspector.

1391.01 -> And going back to prioritization within Inspector,

1393.708 -> we do do that.

1395.57 -> So if you and I will show that in the demo also,

1399.02 -> we have a panel on the main dashboard called

1401.36 -> risk based remediations where we look at your holistically,

1404.57 -> your whole environment and we identify five packages,

1407.99 -> top five packages, what we call five packages on fire.

1411.23 -> And based on number of CVEs attached to it,

1414.62 -> the criticality of the CVEs and number of resources

1417.86 -> that are impacted by those packages

1420.172 -> that have those packages.

1422.81 -> We kind of identified those five things and our opinion

1426.08 -> is that if you go and try to patch or remediate those first,

1430.46 -> that will reduce your risk posture significantly.

1433.85 -> Obviously you have to implement others also

1436.64 -> or remediate others also, but this is a good starting point.

1443.54 -> Then the last thing about integration

1445.64 -> with EventBridge and also security hub.

1448.998 -> So some of the customers have already automated

1455.39 -> their ticketing system.

1457.071 -> So since inspected us everything in real time,

1459.764 -> every time there's a new finding generated,

1462.59 -> we would send an event to EventBridge.

1465.17 -> Every time a new resources discovered,

1467.6 -> all the state changes.

1468.68 -> So let's say if it is terminated or an instance is stopped

1471.8 -> or a Lambda function is deleted

1474.2 -> or a container image is deleted,

1475.82 -> we send all sorts of events and obviously in EventBridge,

1479.27 -> you can create different rules

1480.68 -> on how you want to kind of manage those events.

1483.92 -> You can be, you can get as granular as you want

1486.98 -> or it could be as broad as you want.

1489.007 -> So what customers have done at,

1490.91 -> they have used this mechanism

1492.98 -> to automate their ticketing systems.

1495.11 -> So for example,

1496.7 -> as soon as an easy to instance comes up, is launched,

1499.55 -> Inspector will detect it, scan it, generate findings,

1504.121 -> and as soon as we generate findings

1506.69 -> there will be an EventBridge notification or an event

1510.254 -> saying this is a new finding generated,

1512.6 -> these are the details and we also have the resource details.

1516.86 -> So things like tax attached to the resource instance ID

1522.8 -> or Lambda function ID and so forth and so on.

1525.05 -> So based on that, customers can automatically route

1527.99 -> or create tickets and route it to the appropriate team

1531.076 -> so that they don't have to worry

1532.61 -> about manually creating teams.

1535.071 -> In the past I've seen customers hiring people

1538.896 -> just to create tickets.

1540.68 -> Their whole job is to see what the scan results are

1543.311 -> and then go and create tickets.

1545.588 -> So we are trying to reduce all that operational overhead

1548.36 -> and the same mechanism could be used

1549.98 -> for automated patching also,

1551.81 -> which I was referring to the blog

1553.58 -> and there's a slide towards the end that has links to it.

1557.36 -> But if you go to Amazon Inspector's website under Resources,

1561.38 -> we have all those blogs also listed.

1565.653 -> So the whole goal is, so with this launch,

1570.92 -> as I've said before,

1572.04 -> you will get a single pane of glass across all compute types

1575.54 -> and it's just easier for you to identify

1578.012 -> where all your packages are

1579.74 -> and kind of have that supply chain traces

1583.46 -> in your environment.

1587.349 -> One thing I do want to note is that

1589.962 -> a lot of the customers typically have lambda functions

1595.553 -> kind of deployed

1596.87 -> but they are not getting involved in a while.

1599.12 -> So we also meet the solution intelligent enough

1602.3 -> to filter out those functions

1604.52 -> that haven't been invoked in a while.

1606.583 -> The reason behind that is to control costs

1610.01 -> or spend for the customers

1612.02 -> and if let's say you haven't invoked something

1615.23 -> for six months, we won't pick it up on enablement,

1617.41 -> but let's say tomorrow you do invoke it.

1619.938 -> So we have made that intelligent enough

1622.94 -> that as soon as it is invoked,

1624.737 -> it does come under Inspector coverage

1627.59 -> and we start scanning that

1628.82 -> and then it'll be monitored throughout

1630.53 -> until it is getting,

1632 -> there's a period when we will continue to monitor it.

1638.72 -> So I'm gonna transfer or switch to the demo now

1642.2 -> and then we can take questions after that in Q and A.

1658.28 -> So what I'm gonna do is I'm gonna log in

1660.89 -> through my org management account first

1665.27 -> just to show you how you can assign

1667.13 -> a delegated administrator account and how easy it is.

1724.58 -> So just to show you how the organization is set up,

1727.85 -> if you can see this is the org management account

1730.4 -> that we use to log in and this is an account

1733.52 -> I will assign as the delegated admin

1735.17 -> and this is another member account in the org.

1737.9 -> And when I go back here, all I have to do

1742.667 -> is when we get started here,

1747.71 -> you have to assign a delegated admin account

1750.11 -> and you just have to provide the account id.

1752.27 -> And what will happen is once you click on Delegate,

1756.5 -> it will not only delegate the admin account,

1759.56 -> which can act as a central Inspector admin account,

1762.17 -> which has visibility into all your other accounts,

1765.412 -> but also all the findings

1767.814 -> are consolidated into that one account.

1772.25 -> Now while it's getting delegated,

1774.47 -> I'm gonna log in through the delegated admin account

1777.44 -> to show you how it would look like.

1794.15 -> So when you log in,

1795.56 -> this is the delegated admin account

1797 -> and this is how you see Inspector would look like.

1800.3 -> So we give you the whole environmental coverage details.

1803.69 -> So, and I'll click on one of each one of these

1806.48 -> and show you how it would look like

1807.83 -> and what the benefit is and what the use cases are.

1810.8 -> But essentially when you log in,

1812.66 -> this is the first page you will see,

1814.07 -> you will see your real time environmental coverage,

1817.37 -> which means how many accounts are being used

1821.03 -> or activated with Inspector.

1822.47 -> So you can see three out of three accounts are enabled,

1825.17 -> instances we are giving you 85% instances

1828.347 -> are being covered by Inspector, that is 12 out of 14.

1832.16 -> And when I click on that,

1833.453 -> I'll show you in the coverage pages,

1835.927 -> we give you actionable guidance.

1837.41 -> The two instances that are not being scanned by Inspector

1840.35 -> or monitored by Inspector, why not?

1841.933 -> Similarly for container images

1844.16 -> or container repositories and lambda functions.

1846.44 -> We give you coverage details.

1848.42 -> And similarly for critical findings,

1851.135 -> we have this page like real time dashboard for you

1856.55 -> so that you can see our organizational vulnerability posture

1859.775 -> at any given time.

1861.86 -> So our whole goal is not to make it more

1864.89 -> like a traditional vulnerability management solution,

1867.23 -> it's more to build it more

1869.18 -> like a security operation center

1871.82 -> so that you don't have to worry

1873.825 -> about the operational overhead,

1874.88 -> you just have to monitor the real time data

1877.37 -> that you get from Inspector.

1880.19 -> So if you click on it or you can just go

1882.41 -> to account management page also,

1884.36 -> you can see there are EC2 scanning, ECR scanning

1888.92 -> or lambda scanning and all you have to do

1891.496 -> is click here and enable all.

1894.2 -> And if you don't want all types of scannings,

1896.21 -> we do give flexibility if you just want

1898.88 -> let's say EC2 scanning or lambda scanning,

1901.01 -> you can just turn on that.

1904.19 -> And we also provide additional feature

1906.62 -> for new member accounts.

1908.09 -> So let's say today you have only 10 accounts

1910.67 -> in your AWS organization but you plan to add one more

1914.72 -> so you don't have to come back

1916.73 -> and re-enable Inspector for that new account.

1919.647 -> If you have this setting turned on,

1921.969 -> the new accounts will automatically be onboarded

1925.85 -> to Inspector without any manual effort.

1930.74 -> So going back to instances and you can go back

1934.263 -> or go through account management also,

1936.68 -> you can see the coverage pages through there also.

1939.11 -> But essentially, we tell you how many EC2 instances

1942.74 -> are we scanning and the ones we are not, why not?

1945.26 -> So you can see this is being actively monitored,

1947.445 -> this one is unmanaged.

1949.55 -> So we do require SSM agent only for EC2 instances.

1954.29 -> So if you're already using SSM agents in your environment,

1957.71 -> you don't need to do anything else.

1959.612 -> But if you don't,

1960.74 -> you do need to have SSM agent for EC2 instances only.

1964.07 -> For container images, Lambda functions,

1966.41 -> you don't need any additional agent or a software.

1969.56 -> We automatically get that from the service.

1973.28 -> - And just to jump in,

1974.45 -> this is one of the differences between the new Inspector

1977.99 -> and Inspector classic.

1979.31 -> So for those who used the older Inspector,

1982.73 -> we had a dedicated agent that you had to deploy

1986.33 -> and kind of manually manage on your own

1990.17 -> and customers just constantly told us

1992.42 -> like we just don't want another agent,

1994.58 -> we're already using SSM,

1996.56 -> our security teams have blessed it

1998.18 -> like please, please make that work for us.

2001.27 -> And so that's why you see that change

2004.632 -> between classic and the new Inspector.

2008.32 -> - And similarly, you can see for container images

2010.144 -> and you will see unsupported OS

2012.49 -> or scan eligibility expired and we can go through

2014.863 -> that if you have questions around it in Q and A.

2017.92 -> But essentially we give multiple configurations

2020.8 -> for contained images on how long you want it

2023.47 -> to be monitored for.

2024.7 -> It could be 30 days, 180 days or lifetime.

2027.61 -> So depending on each customer

2029.23 -> you have that configuration available.

2032.596 -> - And those settings, those configuration settings,

2035.74 -> those are set by your delegated administrator

2038.11 -> so you don't have to go in

2039.4 -> and set them in every single account.

2041.77 -> The delegated administrator is that single point

2044.35 -> where you can decide,

2046.33 -> how do I want this configured for my organization?

2050.26 -> - And similarly for lambda functions

2051.58 -> you can see what are the resource tags,

2053.667 -> it is actively monitored and so forth and so on, run times.

2060.16 -> So before I deploy Lambda function,

2062.98 -> I do want to show you one of the unique things that we do

2065.498 -> with network reachability scans first.

2068.977 -> So vulnerability scans or CVE scans

2074.77 -> that we do for EC2 instances, we also do network scans.

2078.94 -> And the network scans that we do are kind of unique

2083.11 -> in the sense since we are an internal service

2085.33 -> we get data from security groups or other services.

2089.89 -> So what we can do is we can identify open paths

2092.245 -> to your ports from the internet or any VPC,

2097.389 -> I would say VPC edges.

2100.304 -> So think about internet gateways, load balancers

2103.57 -> or transit gateways.

2105.7 -> We identify paths from the internet to your instances.

2109.36 -> So if I

2114.37 -> just filter on network reachability scan

2117.19 -> or network reachability findings,

2120.07 -> you can see this port 2022 is reachable

2124.24 -> from the internet gateway and we do give you the exact path

2127.51 -> and if there are multiple paths,

2128.68 -> we will generate multiple findings.

2130.32 -> So you can say this internet gateway, this network ACL,

2134.17 -> this security group, this ENI and this instance,

2137.95 -> this is how the path is and if it is unintentional,

2141.73 -> you might want go and remediate that

2143.29 -> versus letting it be open.

2144.824 -> And what we do is for our contextualization

2151.034 -> as we alluded to earlier,

2152.806 -> we take that data and we correlated with the CVE data.

2158.71 -> Now if I show you an example of how Inspector's score

2162.43 -> is generated and how it is impactful,

2174.49 -> let's take an example of this one.

2175.81 -> So on this instance we identified this CVE 2017

2178.401 -> for CURL and libcurl.

2181.09 -> We do give you kind of a high level description

2183.91 -> of what the vulnerability is about.

2186.119 -> Then we give you the severity which is determined

2189.64 -> by the Inspector score, what kind of vulnerability it is,

2194.004 -> if there is an exploit available.

2197.079 -> So exploit available here is the feature

2202.03 -> we are launching as a part of this launch,

2205.12 -> which I called out earlier where we do give you

2207.52 -> the information that if there is an exploit available

2210.67 -> and we monitor Darknet for it,

2212.11 -> we have our internal thread intel groups

2214.3 -> that monitor known hacker groups for these.

2217.777 -> So we monitor the whole landscape to see

2219.04 -> which CVEs are actually being exploited in the wild.

2223.21 -> So for fixed available you can see these

2225.82 -> are the affected packages by the CVE.

2227.86 -> So curl and this version, this release,

2231.97 -> this architecture and we also give you fixed inversion.

2235.482 -> So not only which version is affected by this CVE,

2238.54 -> but how it is or where it is fixed in.

2240.94 -> If it is not fixed yet,

2242.356 -> which means like vendor hasn't really released

2244.99 -> a fixed version to address the CVE, then you will see,

2250.06 -> fixed available as nil or partial.

2252.4 -> So partial is when, let's say there are two packages,

2256.3 -> there is fixed available for one but not the other one.

2258.76 -> So it'll be partial

2259.63 -> and if none of the packages have fixed available

2261.79 -> it will be nil.

2264.16 -> And we give you scores, all type of scores.

2267.13 -> So you can see CVE's 2.0 score from NVD,

2270.089 -> CVE's 3.0 score from NVD.

2273.28 -> But if you look at it closely, CVE's score from NVD is 9.8,

2278.56 -> but here Inspector score is 8.4.

2281.43 -> We have reduced the score based on

2284.531 -> and we are being very completely transparent about it.

2287.92 -> If you look at it,

2288.97 -> what we did was we looked at the CVE metadata

2291.88 -> and if you look at attack vector,

2293.47 -> what it means is that this CVE

2295.66 -> can only be exploited remotely

2297.291 -> and we determine that your instance is local,

2300.79 -> which means it doesn't have any path from the internet

2303.78 -> and we adjust the parameters to generate an Inspector score

2307.89 -> that will eventually determine the severity of that finding.

2313.51 -> Now we didn't invent our own calculator,

2316.36 -> we are using industry standard calculator

2318.82 -> to calculate the Inspector score,

2320.74 -> but we adjust the parameters in that CVE vector.

2325.18 -> - And one thing that's important to point out

2328.491 -> that network reachability,

2329.324 -> we're not doing that through network probing.

2331.39 -> So we're not sending data into your environment.

2334.63 -> What we're doing is we're looking at your configuration

2337.07 -> and Amazon has provable security tools

2342.371 -> that basically guarantee us that yes,

2345.7 -> there is a path no matter from the edge of the VPCN.

2348.859 -> So just to be clear,

2350.65 -> this is without agent, without probing.

2353.05 -> This is where that's coming from.

2356.92 -> - Yeah, so now what I'm gonna do

2359.258 -> is I will deploy Lambda function.

2363.85 -> I did prepare some Lambda functions beforehand.

2370.57 -> So I'll just deploy this lambda function

2372.85 -> and I will show you what the function does in a minute

2375.7 -> once the deployment is done.

2388.12 -> And one thing we kind of didn't really talk about

2390.55 -> until now is layers also as you know you can use layers

2396.07 -> as a part of your lambda function.

2397.78 -> So we do scan layers also.

2399.223 -> So if any function that we are scanning

2401.68 -> and it has like five or 10 layers,

2403.9 -> not only will we show those layers

2408.16 -> or identify findings in those layers,

2409.9 -> we will also attribute that finding to that specific layer

2413.59 -> so that you know if you go and fix that layer,

2417.85 -> it could impact multiple functions at once.

2420.73 -> So we do have that capability also,

2426.58 -> it takes about a couple of minutes to deploy.

2432.04 -> While it is getting deployed,

2433.441 -> this is what's something I wanted to call out

2435.67 -> the risk-based remediations.

2437.32 -> So based on my demo environment,

2440.157 -> these are the packages which have the most critical like

2444.01 -> CVEs attached to it impacting most resources.

2447.85 -> So you can see these are the packages I need to go

2450.25 -> and update and that is how you can remediate those.

2455.74 -> And for EC2, I do want to call out another thing,

2458.978 -> we map it back to AMIs.

2462.34 -> So if you look here in this panel,

2464.68 -> this AMI is being used by four instances

2467.337 -> and since we are not scanning the AMIs directly,

2470.069 -> there is a baseline that you can see that for example,

2474.428 -> 130 high or 228 total vulnerabilities are like a baseline

2480.775 -> and there could be additional software

2482.8 -> in other instances or you might have patched in other,

2487.15 -> but it gives you a good idea of what you need to patch

2490.24 -> or regenerate your AMI to see results.

2496.9 -> Let's see, yeah, so this is deployed

2499.15 -> and within seconds you will see, it has been discovered

2503.95 -> and within a couple of seconds it it'll turn to,

2518.02 -> yeah, so this is the function I just deployed

2520.75 -> and you can see findings generated a minute ago

2523 -> or few seconds ago.

2524.71 -> So within like a minute or so, as soon as it is deployed,

2527.98 -> you can see all the findings for lambda function.

2531.04 -> You can see if there's a fix available,

2532.69 -> if there's an exploit available for this one.

2535.33 -> And similarly for others, for example,

2537.4 -> this specific CVE exploit is available, yes.

2542.07 -> And it was last exploited on October 24th in the wild.

2546.31 -> So it hasn't been too long,

2548.17 -> like according to our intelligence,

2550.3 -> it has been exploited in the last month or so.

2554.32 -> And we do give you kind of which package manager

2556.36 -> where exactly it is.

2557.31 -> So you can see if there are layers which layer this package

2562.99 -> was consumed through and you can see all the results there.

2569.47 -> - Kashish, are you gonna talk about

2572.091 -> what environments we support with this?

2573.28 -> - Yeah, so at launch or right now

2576.49 -> we support three run times, Python, Node and Java

2580.908 -> because that kind of represents 96% of the functions

2583.813 -> in Lambda service anyway.

2585.85 -> But we do plan on adding support for other run times

2589.21 -> also pretty soon.

2594.73 -> Yeah, so this was mainly the demo

2597.43 -> and before we jump onto the Q and A,

2602.98 -> I do want to talk about pricing a little bit

2604.9 -> and then we can.

2606.64 -> - While Kashish switches over,

2608.11 -> I think there's a couple things we really want you

2611.725 -> to take away from this.

2612.94 -> Number one, we've designed Inspector

2615.297 -> to be easy, low administration and single click,

2620.95 -> you turn it on for your organization,

2623.5 -> you set it to auto enable and you can just assure that,

2626.148 -> okay, I don't have any gaps in my coverage.

2628.87 -> Number two, Inspector does all the hard work

2631.6 -> of discovering your resources.

2633.91 -> So as your development teams are doing new things,

2638.416 -> you don't have to worry about it,

2640.3 -> you don't have to keep track.

2641.71 -> Inspector will do that for you.

2643.51 -> And number three, we manage the findings.

2646.21 -> So as you patch, as you destroy resources

2650.14 -> or as new CVEs are published,

2652.522 -> Inspector takes care of the details.

2655.69 -> We really wanna get you out of the business

2658.51 -> of administrating a solution

2660.28 -> and into the business of remediating findings.

2663.19 -> And at the end of the day,

2665.02 -> we want you to have one tool that does it regardless

2667.96 -> of the compute, whether it's EC2 containers or lambdas,

2671.761 -> that's the goal with Inspector

2673.93 -> and that was the goal of adding Lambda to this product.

2678.354 -> - So talking about the pricing,

2680.62 -> we have priced it pretty aggressively

2682.63 -> because we want customers adopt this feature

2687.31 -> and it's not about making money for us,

2690.22 -> it's about making sure

2691.33 -> all your compute environments are secure.

2696.592 -> So the way we price it is per Lambda function per month

2701.17 -> and it is determined by Inspector coverage

2703.958 -> and what that means is as soon as it is deployed,

2708.8 -> which means Inspector will discover it until it is deleted

2712.24 -> or you exclude that function from scanning,

2715.12 -> we will calculate the number of hours and we charge by that

2719.107 -> and we plot it by a number of hours also.

2721.339 -> So 30 cents per month per function is in US East one.

2727.57 -> And if let's say you have that function you deploy today

2730.93 -> and you delete it tomorrow we will only charge 1 cent.

2734.41 -> So we will only charge for one day.

2736.21 -> If it is for few hours, we only charge for a few hours.

2739.15 -> So it is prorated,

2740.292 -> it's not like we charge for the whole month.

2743.359 -> And there is a pricing example there.

2746.23 -> For example, if you have 10 lambda functions,

2749.14 -> continuously monitor for 30 days, it'll be $3.

2752.14 -> If let's say you delete us another set of 10 functions,

2756.4 -> but you delete them by after 15 days,

2759.49 -> we will only charge you for 15 days,

2761.26 -> which is a $1.50 and then will be $4.50.

2766.84 -> - One of the important parts to that

2768.55 -> is we want it to be predictable,

2770.71 -> as you saw in Kashish's example, I think there was,

2773.408 -> how many supported Lambdas did you have, like 14?

2776.567 -> - [Kashish] Seven, yeah.

2778.115 -> - Oh seven, okay, I can actually see the screen.

2779.53 -> So in his case, if with seven Lambdas,

2783.34 -> if they were being monitored all month,

2786.25 -> it's pretty easy math, it's just seven times 30 cents.

2789.25 -> So, that was the goal.

2792.13 -> It doesn't matter if Inspectors scanned them

2794.62 -> once in the month or a hundred times in the month,

2797.71 -> you're just getting charged for those seven lambdas.

2802.505 -> - Yeah, and these are the blogs I mentioned before

2804.61 -> during my kind of talk before.

2808.27 -> These are also listed on our website.

2810.34 -> So if you go to resources on Amazon Inspector,

2812.74 -> you can see all the blogs.

2814.24 -> These are some of the critical ones

2815.74 -> that I wanted to make sure you kind of know about those.

2819.79 -> But others, there are many more blogs

2822.58 -> that we kind of write and we publish on a regular basis.

2828.343 -> I think we can take questions now.

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