AWS re:Inforce 2023 - Continuous innovation in AWS detection and response services (TDR204)

Aug 16, 2023

AWS re:Inforce 2023 - Continuous innovation in AWS detection and response services (TDR204)

Join this session to learn about the latest advancements and most recent AWS launches in detection and response. This session focuses on use cases such as automated threat detection, continual vulnerability management, continuous cloud security posture management, and unified security data management. Through these examples, gain a deeper understanding of how you can seamlessly integrate AWS services into your existing security framework to gain greater control and insight, quickly address security risks, and maintain the security of your AWS environment.

Learn more about AWS re:Inforce at https://go.aws/42zqk7C.

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.

#reInforce2023 #AWSEvents

Content

0.15 -> - All right, welcome everyone.

1.71 -> Hopefully re:Inforce day two is going well.

4.92 -> This is TDR 204.

7.35 -> We will cover the session that highlights

9.72 -> the continuous innovation

11.37 -> in AWS detection and response services.

14.46 -> My name is Himanshu Verma.

15.93 -> I lead the team of our world worldwide security specialists

18.33 -> at Amazon that helps customers orchestrate

21.51 -> AWS native security services as well as partner tools

25.32 -> and helping them with their security journey in the cloud.

28.44 -> And I'm joined here with Ryan Holland,

31.68 -> who's the Senior Manager for Amazon GuardDuty.

35.85 -> So the topics we'll cover today are an overview

38.19 -> of AWS threat detection and monitoring services portfolio.

41.85 -> What are some of the key enhancements

43.29 -> that have been announced in the last recent months,

47.25 -> as well as late as yesterday?

49.74 -> We'll also provide a quick technical overview and demo

52.53 -> as we go through these features.

54.15 -> And then there'll be, you know,

55.71 -> time for Q&A on the side.

57.3 -> You guys can come and ask us some questions.

60.99 -> So diving into this,

62.1 -> all of our security services

64.17 -> that are native to AWS are focusing on providing

67.02 -> better visibility to our customers.

69.48 -> As you move towards continuous development

72.3 -> and/or modernizing your workloads,

74.52 -> we want to make sure that you have

76.41 -> the security services in place

78.45 -> that can provide you better visibility,

80.76 -> whether it's regards to providing detections

82.928 -> and/or providing monitoring capabilities,

86.16 -> without the operational lift of going through

89.31 -> orchestration and/or generating logs and telemetry.

94.65 -> Additionally, what we've seen

95.85 -> and heard from customers is that

98.19 -> there's an increasing trend in providing

100.92 -> that visibility to not only the security persona,

103.86 -> but also to the developer personas.

105.87 -> So you'll see that some of the enhancements

107.61 -> we've been making in our services are moving towards

110.1 -> that direction to bring the Dev SecOps experience together.

117.09 -> Before we dive into

118.8 -> the threat detection and monitoring services,

120.72 -> just wanted to provide you a holistic view

123.18 -> of the breadth and depth that AWS services provide.

127.2 -> So our goal is to provide

128.88 -> proven security to accelerate innovation.

131.4 -> And this is accomplished by orchestrating our services

135.57 -> in a cybersecurity framework use case.

138.78 -> So for instance, customers as they increase

141.45 -> their AWS workloads or are adding more workloads

144.63 -> in their AWS accounts continuously,

146.91 -> whether it's one team or multiple teams,

149.34 -> they need the ability to identify

151.158 -> what all controls or what all workloads are there,

154.11 -> and have a good inventory of

156.21 -> what all security posture is being implemented,

160.05 -> so that you have good view of evaluating

162 -> that security posture as well.

163.56 -> This is where some of our management and governance tools

166.08 -> come in that provide customers the ability to evaluate

169.14 -> those controls and then also have visibility

172.38 -> or continuous monitoring into whether

174.06 -> they're following security best practices or not.

177.75 -> Once customers have identified

179.16 -> these workloads and inventory

181.17 -> then comes in the protection.

183 -> So this is where some of our protection services

185.73 -> come into play, which is protecting data

187.47 -> at rest, in motion, in use,

189.48 -> or protecting the infrastructure to and from AWS.

193.68 -> So our services provide customers the layered defense

197.224 -> that can be applied to protect these workloads.

202.77 -> Next, is the ability to detect proactively

205.89 -> any misconfiguration, vulnerabilities,

207.96 -> threats in your environment.

209.79 -> So this is where most of our threat detection

212.16 -> and incident response suite of services come in

214.74 -> that help customers detect

216.322 -> these threats in their environment.

219.57 -> Most of these services will generate findings,

222.12 -> which is what customers can leverage to orchestrate response

225.81 -> or respond to these events.

227.809 -> Being cloud native,

229.65 -> these services all integrate

231.18 -> with EventBus or EventBridge,

234.18 -> and then can be used to drive event driven orchestration

237.6 -> by integrating with Lambda and step functions, et cetera.

241.77 -> And then finally is recover.

244.38 -> So finding an incident and then recovering

247.26 -> from that incident and making it easier

249.66 -> and automated by leveraging disaster recovery tools

252.42 -> or you know, cloud formation templates

255.36 -> and AWS backup tools is another area

258.24 -> where our services can help

260.25 -> by integrating with those tools.

262.29 -> So this is a holistic view of our breadth

264.87 -> and depth of all the AWS security services

267.81 -> that customers can leverage to orchestrate that

270.302 -> in a cybersecurity framework.

273.36 -> Now diving into the detection and response services,

276.84 -> this is what the portfolio looks like.

278.58 -> We're continuing to evolve this portfolio as well.

281.25 -> You can see there are six security services

285.21 -> highlighted here.

286.41 -> So first and foremost,

288.51 -> these services are natively integrated with AWS workloads.

292.23 -> There are three detection services,

294.109 -> Amazon GuardDuty, which is our primary service

296.85 -> focused on identifying known threats

299.634 -> and malicious threats or activity

302.64 -> and suspicious activity as well.

305.19 -> GuardDuty brings these findings

307.376 -> and those findings are available in the console,

309.84 -> as well as in the EventBridge, to take actions on.

313.56 -> The second service highlighted here is Amazon Macie

316.62 -> that helps customers identify the risk posture

319.89 -> associated with sensitive data

321.93 -> in their S3 workloads or S3 buckets.

325.342 -> Natively integrated with S3,

327.3 -> it allows customers to either run on demand scans

331.44 -> or automatically using intelligent sampling,

334.41 -> can actually identify sensitive data

337.17 -> that is matched to either

338.73 -> built-in managed identifiers in the service

341.28 -> or customer identifiers that customers can define as well.

344.64 -> But we've enhanced the service

346.32 -> to bring in context and risk associated

348.9 -> with the control plane activity

351.06 -> on the S3 buckets and objects as well.

354.45 -> The third service is Amazon Inspector,

356.28 -> which is our primary service

357.51 -> focus on vulnerability management.

360.12 -> Inspector natively integrates with EC2 instances,

364.057 -> container registries like Elastic Container Registry,

367.35 -> and lately with Lambda functions and Lambda code functions

371.43 -> to detect vulnerabilities and report those as well.

375.81 -> All these findings are then can be aggregated

378.981 -> in AWS Security Hub,

381.6 -> which is our centralized security monitoring,

383.76 -> as well as Security Cloud Posture Assessment Service.

388.122 -> One of the core functions that Security Hub provides is

390.63 -> evaluating the controls that are in your environment,

394.23 -> which are organized in a very easy

396.06 -> to infer security standards.

398.25 -> So these standards are built in aggregation of controls

401.4 -> such as AWS foundational security best practices,

404.4 -> and/or the NIST standards or CIS benchmarks,

408.99 -> so that customers have a high level view

411 -> of what the risk posture is.

413.19 -> And additionally they can dive deeper into the details

415.65 -> of where do they need to take actions to orchestrate

419.46 -> or configure those controls appropriately

421.62 -> and close that gap.

425.28 -> The fourth service,

426.36 -> the fifth service that's highlighted here

427.77 -> is Amazon Detective.

429.87 -> Detective is a service that's mainly focused towards

432.57 -> the security operations persona

434.76 -> as well as the threat analyst persona.

437.13 -> Detective helps customers investigate and identify

440.85 -> the root cause analysis of security events.

444.27 -> Detective is collecting a lot of telemetry

447.15 -> in the backend automatically,

448.98 -> not only from findings

450.42 -> but also the raw information

452.25 -> and is creating a behavioral graph

454.8 -> that correlates all the entities

456.99 -> as well as is able to provide a journey map to the customer

461.34 -> in the form of either visual interface

463.56 -> and/or going and identifying

465.48 -> what API actions were actually taken

467.88 -> or how did the threat manifest itself over a period of time.

472.89 -> So Detective is collecting all that information

474.81 -> and retaining it for at least 12 months,

477.48 -> which provides customers

478.74 -> and security investigators to go in

480.84 -> and investigate those events back in time as well.

485.16 -> And then the final service that's highlighted is

487.08 -> to help customers organize

488.85 -> and manage all the security data,

491.16 -> not only related to findings,

493.08 -> but also related to security logs.

495.54 -> We heard from customers

496.65 -> that this is a key challenge for them.

498.75 -> So at re:Invent last year

500.73 -> we announced a service Amazon Security Lake,

503.37 -> which is now available as of last week

505.86 -> and has been launched.

507.3 -> Security Lake helps customers easily centralize,

510.51 -> organize log data related to security use cases,

514.47 -> not only from AWS workloads

516.51 -> but also non AWS workloads as well,

519.3 -> which means you can bring in log information

521.19 -> from either hybrid environments

524.04 -> or other SaaS applications or even other cloud providers.

527.778 -> Once that information is aggregated

530.132 -> in a customer owned S3 lake formation bucket,

533.46 -> it also automatically transforms all that information

536.31 -> into a standard schema format,

538.32 -> making it much easier for the security teams

541.32 -> to now use the choice of their flexible analytic tools

545.46 -> and then reduce the time that it takes

548.46 -> to either run queries and/or infer

550.928 -> what actions need to be taken

553.603 -> or reduce the time for incident response.

557.19 -> So these six services are key

559.53 -> to our threat detection and incident response.

562.5 -> We will actually go into details of some of the new features

565.62 -> that have been launched in these services,

567.69 -> as well as showcase what these look like in the AWS console.

574.41 -> Let's first focus on the deploying these services

577.41 -> and how we are addressing the scale of their coverage.

581.34 -> First and foremost, as I mentioned,

583.05 -> all these services are natively integrated

585.84 -> with AWS workloads.

587.49 -> What that means is that there is no additional logging

590.221 -> and/or operationalization required.

593.22 -> Within a few clicks,

594.39 -> these services can be enabled both at the account level

597.9 -> as well as all these services are integrated

600.6 -> with multi account management

602.34 -> with the AWS organizations construct.

604.74 -> That means security teams can actually delegate

607.23 -> a centralized management account

608.97 -> and can easily aggregate either findings

611.97 -> and/or logs in these services

614.82 -> and can also manage onboarding

616.95 -> other member accounts very easily as well,

619.47 -> which allows customers and the security teams

621.33 -> the ability to make sure

622.8 -> that as new accounts are getting onboarded,

624.978 -> these services are either automatically enabled

628.08 -> or they have the choice

629.22 -> to turn on, off certain features within the services.

633.382 -> So again, from an operationalization standpoint,

636.42 -> it's very easy to enable these services

638.7 -> and none of these services actually require

640.693 -> raw logging to be enabled.

643.5 -> So just to show you a quick overview

646.11 -> of how this looks like in the console,

648.36 -> this is an interface for Amazon GuardDuty

650.94 -> where you can see I'm in the accounts tab.

653.82 -> And most of our services have the same

655.53 -> similar user experience where you can set up

657.45 -> a delegated management account,

659.16 -> a centralized delegated management account.

661.29 -> And from there, you can see a rich option

663.96 -> of enabling this service.

665.631 -> Not only can you take individual actions

668.73 -> by selecting one or many accounts

671.175 -> and just enabling services on those,

674.67 -> but you can also take multiple actions

676.92 -> of auto enabling these services either for all accounts,

681.615 -> which means anytime you're adding new accounts,

684.51 -> the service will be automatically enabled

686.52 -> and will start monitoring and providing the value.

689.31 -> Or you can also do that on, for example,

692.1 -> new accounts that are added to the organization.

695.76 -> And in the case of GuardDuty,

697.89 -> as we, you know, we'll talk more in detail,

700.32 -> you can see the rich options that are available

702.443 -> either at the feature level

704.61 -> or in some cases also at the sub feature level

708.42 -> that you can enable and toggle these options

711.66 -> based upon the accounts where these workloads reside

714.63 -> or based on how your accounts are orchestrated

717.51 -> between dev, test, prod, et cetera.

720.96 -> So this makes it very simple and easy

723.3 -> to manage these services and enable these services

726.06 -> across multiple member accounts

728.19 -> and then also aggregate their findings

730.47 -> in one single centralized account.

734.22 -> With that,

735.419 -> I'm going to hand it over to Ryan

736.252 -> to cover the first detection service.

739.71 -> - Thank you very much, Himanshu.

741.57 -> So the first service we're gonna talk about

743.46 -> and go a little more in depth is Amazon GuardDuty.

746.61 -> So Amazon GuardDuty has been around now

748.83 -> for a little over five years.

750.57 -> When we first launched GuardDuty,

752.28 -> we had three data sources.

753.66 -> So we had flow logs, DNS query logs,

758.16 -> and CloudTrail events from the management side.

760.98 -> We had later extended that to include data events

763.23 -> for things like S3.

765.09 -> And then most recently,

766.29 -> we've started adding additional log sources for our EKS.

769.71 -> So last year we launched EKS audit log protection.

773.25 -> And then the Aurora login events

777.63 -> from RDS Aurora instances.

779.85 -> And then recently we launched Lambda Protection,

782.22 -> which looks at flow logs from Lambda

784.17 -> as well as a runtime agent now for EKS clusters.

788.01 -> And as Himanshu mentioned,

789.06 -> one of the most important things is

790.08 -> you don't have to turn on these log sources

791.88 -> in individual accounts.

793.11 -> So you don't have to go turn on your flow logs

795.21 -> or turn on your EKS audit logs.

797.19 -> When you turn on these functions

798.39 -> within the GuardDuty service,

800.19 -> we're automatically gonna start

801.3 -> grabbing those from the backend.

802.68 -> So that helps save both cost

804.84 -> in turning those logs on at scale,

806.37 -> but also in management and making sure that they're enabled.

809.447 -> It also has some security benefits

811.53 -> because you can't interrupt our access to that data.

815.16 -> So once we have this log data,

817.08 -> the first thing we're gonna do is run it through

818.49 -> a set of different security analytics.

820.56 -> So we look at this in different ways.

822.12 -> We have threat intelligence based detections.

825.12 -> We partner with both CrowdStrike and Proofpoint.

828.36 -> And we also get a lot of very rich threat intelligence

830.85 -> from internal sources as well.

832.23 -> So we partner with our internal threat intelligence group

835.77 -> that tracks a lot of nation state actors

837.81 -> and a lot of other very sophisticated actors

839.82 -> to get some good threat intel

841.62 -> that we can apply to those data sources.

843.87 -> And we also have a very large investment in machine learning

846.78 -> where it allows us to baseline and do profiling

849.42 -> of different workloads,

850.92 -> be it a user in CloudTrail, or a bucket in S3,

854.19 -> or an EKS cluster from EKS audit logs.

856.8 -> And learn what is normal activity for that resource

860.94 -> and then raise anomalous findings

862.68 -> when we see things that are deviating

864.33 -> from what we consider to be normal.

867.63 -> And then we produce findings.

868.98 -> And the idea that for these findings

870.36 -> we want them to be actionable.

872.04 -> And one of the ways that we help customers

873.63 -> make these findings more actionable is by enriching them

876.018 -> with a lot of context.

877.83 -> So for an instance that could be information

880.17 -> about its tags or its network interfaces.

883.35 -> From an RDS perspective,

885.6 -> it could be what do we normally see?

887.55 -> Like we're telling you

888.383 -> that this particular login was unusual

890.621 -> and we now will also tell you

892.23 -> why we found it was unusual.

893.61 -> Like what is the normal activity we see?

895.572 -> Same with CloudTrail and S3,

897.99 -> if we're gonna say a user is accessing a bucket abnormally,

901.78 -> we'll also tell you what buckets they normally access

904.572 -> or what volume we normally see them access.

907.14 -> And that really helps the responder to take that alert

910.29 -> and understand, you know,

911.49 -> why we decided to send that to them.

915.19 -> And then all of these alerts go out

917.49 -> to multiple different sources.

918.99 -> So as I mentioned,

919.89 -> you can pivot directly to Detective.

922.2 -> If you wanted to go dive deeper

923.94 -> into an individual finding and learn more

925.65 -> about what other activity that resource was doing,

928.41 -> you can investigate it directly in Detective

930.51 -> from the GuardDuty console.

932.52 -> We also sent it to Security Hub for aggregation.

935.19 -> And then we also sent 'em out EventBridge

936.63 -> where a lot of customers are collecting these findings

938.85 -> and sending them to third party partner tools

941.46 -> or other internally developed tools

943.08 -> in order to do further investigation.

946.35 -> One other good piece of enrichment we have is

950.28 -> with our new malware protection.

952.35 -> So for EC2 based detections,

955.89 -> we can trigger an automated,

957.48 -> behind the scenes malware scan of the volume.

960.36 -> So for example,

961.29 -> if I tell you that an instance started doing crypto mining

963.6 -> or contacting a C2,

965.67 -> instead of having to go onto the incidents and figure out,

967.89 -> okay, where is the mining tool,

969.87 -> or where is the malware,

971.73 -> we'll automatically snapshot that volume

974.19 -> and run a malware scan against it.

976.53 -> We partner with Bitdefender

977.76 -> and we also have one of our own engines

979.26 -> that we run against this data as well.

980.903 -> And this will allow us to send you a detection that says,

983.97 -> we found this network activity that was suspicious

986.94 -> and we also scanned the volume

988.47 -> and now here's the actual list of files

990.45 -> that were detected as malware.

992.16 -> That really helps speed up the response time

994.41 -> and help the responder know exactly

996.78 -> what they need to go look at.

999.9 -> So I wanna just go a little deeper

1001.04 -> on some of the newer features that we recently added.

1003.08 -> So I mentioned the EKS protection.

1005.15 -> This is available in two different options.

1007.91 -> So there's the audit logs

1009.71 -> where if you turn this on, again,

1011.24 -> you don't have to change your EKS configuration,

1014.3 -> you can turn this on in accounts

1015.71 -> that don't have EKS running today.

1017.84 -> And if somebody were to decide tomorrow

1019.94 -> to start an EKS cluster,

1021.59 -> automatically we'll start getting those logs.

1023.9 -> And those go across all of the different accounts

1026.81 -> within your organization when you use that delegated admin.

1030.2 -> We're looking for things where we'll match the source IP

1033.41 -> of request to the Kubernetes controller

1035.63 -> through threat intelligence.

1037.01 -> So coming from a malicious or suspicious source

1040.16 -> or like a Tor exit node for example.

1042.77 -> And we also track configuration changes.

1044.78 -> So exposing your Kubernetes dashboard

1047.57 -> or making a role binding that allows anonymous access,

1051.65 -> those can trigger policy findings.

1053.21 -> And then if somebody were to use a Kubernetes request

1056.96 -> from an unauthenticated source,

1058.73 -> we'll also raise alerts for that too,

1060.17 -> so it can help identify some configuration problems

1063.2 -> that could ultimately lead to

1065.3 -> someone compromising your EKS cluster.

1068.72 -> We also do some machine learning on these logs too

1071.36 -> to understand what is normal for a particular cluster.

1075.32 -> Some of the things we look at are privileged pods

1078.38 -> or pods that mount host level directories.

1081.65 -> There's very good reasons to do this.

1083.87 -> A lot of security tools do need access

1086.09 -> to some of those things.

1087.44 -> However, we'll learn what is normal for a pod

1089.3 -> and if a pod comes along that we haven't previously seen

1092.66 -> request some of those elevated privileges

1094.4 -> we can raise an alert on that to let you know

1096.5 -> that there's this new privilege pod

1098.21 -> and if it's a malicious

1099.08 -> or if somebody were to compromise that,

1101 -> it would have a lot more access than you might want.

1105.5 -> The second part of EKS is the runtime protection.

1109.1 -> So we announced this at re:Invent last year

1111.167 -> and we went generally available at the end of March.

1114.26 -> And this was a collaboration between GuardDuty and EKS.

1117.47 -> So we really wanted to give customers

1120.38 -> more context to detections,

1122.54 -> but also be able to get richer and deeper detections

1125.33 -> that really can only come

1127.1 -> from the runtime environment themselves.

1129.44 -> And so we developed a EBPF based agent.

1132.53 -> So it's a very lightweight agent

1134.27 -> that we deploy using the EKS managed add-ons.

1137.48 -> So this really helps solve

1138.86 -> one of the biggest challenges people face

1141.08 -> with agents is getting 'em deployed is hard.

1143.51 -> Understanding where you even need to deploy them

1145.31 -> can be difficult.

1146.66 -> And so by working with EKS and their managed add-on,

1149.66 -> when you turn on the automatic management,

1151.79 -> if an EKS cluster comes into your environment

1154.07 -> in any account that's has this enabled,

1156.95 -> we will automatically go and deploy the add-on

1158.84 -> to all of the cluster worker nodes

1161 -> and start collecting the telemetry.

1163.37 -> We stream the telemetry directly to a VPC endpoint

1166.7 -> that will deploy for you as well.

1168.5 -> And it allows us to move all of that detection capabilities

1171.5 -> into the backend.

1172.67 -> So that helps keep the agent itself

1174.59 -> and the resources that it needs very lightweight

1176.724 -> and it also allows us to do more advanced detections

1179.69 -> that are looking at CIS calls over time as well.

1182.806 -> So we launched over two dozen new detections

1186.26 -> that are very specific to the runtime environment.

1188.441 -> Some of them are specific to container type of texts

1191.39 -> like container escapes, things like reverse shells.

1194.84 -> And then also for our threat intelligence detections

1197.46 -> in this case, you'll also get very rich contacts

1201.44 -> that I'll show you in the demo

1202.534 -> about not just that the instance

1204.77 -> or the pod performed this activity,

1206.6 -> but also which process was involved

1209.06 -> and what are the process lineage.

1210.65 -> And this really helps with responding

1212.84 -> to these types of attacks.

1215.69 -> So when you take this all together,

1216.89 -> you really get end-to-end detection

1219.8 -> and coverage from a threat perspective

1221.99 -> for running Kubernetes on EKS.

1224.42 -> So at the control plane from CloudTrail,

1226.43 -> the interactions directly with the EKS service itself,

1229.94 -> we're monitoring all of those.

1231.8 -> The Kubernetes control plane.

1233.3 -> So those are the audit logs where we're watching

1235.16 -> how people are interfacing with the Kubernetes controller.

1239.142 -> The underlying EC2 nodes themselves,

1241.49 -> we're still monitoring the flow logs

1243.02 -> and the DNS query requests from those as well.

1245.6 -> And then the system level events

1247.062 -> that we're capturing from the runtime agents as well.

1250.55 -> So it gives you a defense in depth

1252.29 -> and across all the different entry points

1254.39 -> for Kubernetes environment.

1259.01 -> And then the last new extension that we made for GuardDuty,

1262.85 -> which was about in April, was Lambda Protection.

1266.684 -> And so what we're doing here is

1268.97 -> we're looking at flow logs from Lambda functions

1271.94 -> and applying our threat intelligence to those flow logs.

1275.42 -> And it's important to note, again,

1276.98 -> you don't have to turn on any flow logs for these,

1279.35 -> and this works in both networking modes.

1281.54 -> So if you're using the Lambda standard network egress

1285.71 -> and you're going out our IGW,

1287.51 -> we still get access to those flow logs.

1289.67 -> And if you're going out of VPC,

1291.29 -> so you've connected VPC networking for your Lambdas

1293.69 -> and you're routing the traffic out your own IGW,

1296.36 -> we see them as well.

1297.89 -> And these flow logs are enriched

1300.29 -> with all of the function details.

1301.82 -> So you have an understanding of

1303.62 -> what was the function that was impacted

1305.87 -> and when was it last updated.

1311.6 -> So I wanna show you one other thing too

1313.04 -> that we just launched yesterday in fact

1315.08 -> is another enhancement to the GuardDuty console itself.

1318.41 -> So one of the things that we'd heard from customers is

1320.42 -> they wanted an easier way to consume some of the findings,

1323.03 -> especially larger customers

1324.328 -> who might get a large number

1326.54 -> of findings across their accounts.

1328.37 -> So we just released a new summary page

1330.05 -> and this again went live yesterday.

1332.48 -> It allows you to look at data over 30 days,

1334.34 -> seven days, or two days, and see some trends.

1337.19 -> So how am I trending from the number of total findings

1339.683 -> or high severity findings?

1341.84 -> You can then see these findings by date

1343.97 -> and the different severities.

1345.253 -> There's a little chart that'll break down

1347.27 -> like what are the most common types of findings

1349.31 -> that you're seeing.

1350.93 -> You can also look at it by your account.

1352.7 -> So out of all the accounts that I might have,

1355.16 -> what are the ones that are generating the most findings?

1357.71 -> So this will help you kind of drill down

1359.33 -> and prioritize where you maybe want to go look initially.

1363.02 -> And then I like this one at the bottom here too,

1365 -> because a lot of times you might have findings

1367.19 -> that you see quite a bit,

1368.3 -> it might have something that's activity happens a lot,

1370.389 -> sometimes it's that thing that doesn't happen very often

1373.25 -> that is most important to you

1374.9 -> because I should never have seen Tor access

1378.02 -> within my environment, for example.

1380 -> So we're highlighting and bubbling up, hey,

1381.68 -> these are the least occurring findings

1384.29 -> and how often they happened.

1385.88 -> And in this case, you can see I have a set of somewhat,

1388.94 -> you know, concerning looking findings

1390.977 -> and they've only all happened to once.

1392.15 -> And so you can then drill down on those as well.

1395.54 -> And then the same also we'll look at

1396.98 -> all of the findings you have across all of your accounts

1399.17 -> and identify what are the different resources

1401.96 -> that are generating the most findings.

1403.49 -> Again, as a responder,

1405.192 -> the things that are generating these most findings

1407.21 -> is probably something I want to go look at first

1409.16 -> when you start to prioritize how you're gonna go

1411.38 -> and address these.

1416.66 -> So we mentioned, you know, the protection plans

1420.11 -> and turning on and off the EKS protection.

1422.33 -> So I just wanted to highlight here

1423.71 -> on the cluster runtime protection.

1427.49 -> So you have the ability again

1428.81 -> for all of your member accounts to enable it

1431.24 -> for all new accounts.

1432.53 -> And then you can turn on just the log monitoring

1435.17 -> if you don't want runtime.

1436.49 -> And if you want runtime monitoring,

1437.93 -> you have the option of either an enabling it

1440.27 -> with automatic management and in this case,

1442.73 -> we do everything for you.

1444.11 -> So we'll create the VPC endpoints,

1446.15 -> we'll deploy the managed add-ons.

1448.16 -> Again, as new clusters come online,

1450.08 -> they'll automatically get covered.

1451.34 -> You don't have to do anything.

1453.32 -> Optionally, if you wanna do it yourself,

1454.97 -> I know we have a lot of customers that like tools

1456.98 -> like CloudFormation or Terraform

1458.39 -> you can do on manage it yourself.

1459.71 -> If you uncheck that, we'll still enable that functionality,

1463.04 -> but we won't go and create the resources for you.

1468.95 -> So I just wanted to give you a little snapshot

1471.44 -> into some of that additional context

1472.97 -> that I was mentioning from the runtime.

1474.92 -> So in this case I have a runtime finding

1476.99 -> and one of my clusters.

1477.83 -> I executed a crypto miner

1481.28 -> and as you can see we get context

1483.02 -> about the cluster itself,

1484.46 -> so the cluster its name

1485.93 -> and then what was the work load information.

1488.24 -> So the pod level details

1490.19 -> so you can see exactly which pod this actually ran in.

1493.58 -> And then really importantly,

1495.14 -> we also show you information

1496.91 -> about the process that did it itself.

1499.7 -> So you can see the process, it's executable path,

1502.7 -> it's Sha-256.

1504.53 -> So if you wanted to look at that through

1506.57 -> your own threat intelligence or look it up elsewhere.

1509.42 -> The PID, it's working directory

1511.49 -> and then also the lineage of that finding.

1514.04 -> So this can be very helpful in understanding

1516.08 -> how that process came to be, right?

1518.9 -> So you can see that the previous lineage,

1521.03 -> it was executed from a bash console.

1522.89 -> But you can imagine for example,

1524.72 -> if I had a remote shell detection.

1528.043 -> So your process that you would see would probably be

1530.45 -> like something like NC,

1532.07 -> but if the parent process is tomcat for example,

1535.04 -> that would be a good signal that I probably,

1536.87 -> that was probably a web-based vulnerability

1538.91 -> that allowed them to execute that.

1540.59 -> And that's helps you go trace back where you want to go

1544.01 -> for detection.

1544.843 -> So again, we'll look at the process tree

1546.83 -> all the way back to PID 1

1548.69 -> and show you exactly how the binary or the process

1552.92 -> that created the finding came to be.

1559.22 -> The next one I wanted to show you was the Lambda detection.

1561.5 -> So as I mentioned with Lambda now,

1563.51 -> we're looking at flow logs

1564.65 -> and a lot of times this could be something like

1566.87 -> a supply chain attack

1568.37 -> where you've got a compromised include.

1570.38 -> We've seen that before with crypto mining

1572.45 -> being embedded into Lambda functions.

1574.378 -> So looking at these flow logs,

1576.02 -> we can detect access to crypto, to C2, to Tor.

1579.8 -> And again, you're gonna get all of the context

1581.69 -> that you need about the function itself.

1584.12 -> So what was the function, ARN.

1585.89 -> When was that function last modified?

1587.99 -> And you can link directly to it.

1589.37 -> What role the function had attached to it,

1591.89 -> which could be very useful if you're trying to investigate

1594.211 -> kind of blast radius or what that function

1596.42 -> could have access to.

1597.65 -> And then again, all the information

1599.09 -> that we have about the connection.

1603.62 -> The last one I wanted

1604.453 -> to show you was the malware protection.

1606.38 -> So as I mentioned,

1607.82 -> we can automatically trigger a malware scan

1610.94 -> for an EC2 volume.

1612.47 -> And this is both for EC2 instances

1614.93 -> and it's also container aware.

1616.22 -> So if you're running Docker or Kubernetes

1619.117 -> or ECS on EC2 and that underlying instance

1622.58 -> generates one of the findings

1624.86 -> that is on our list to trigger an automatic scan,

1628.07 -> we will have a GuardDuty initiated scan.

1630.53 -> And we'll snapshot that volume,

1632.15 -> run a malware scan against that,

1633.68 -> and then generate a separate finding for you

1635.81 -> that details the paths,

1637.64 -> the locations of all of the malware

1639.35 -> that we found in that volume.

1641.15 -> And if you're using ECS or EKS,

1643.1 -> we'll also give you the EKS and ECS details as well.

1646.76 -> So the pod data from Kubernetes

1648.781 -> or the ECS task information if you're running ECS.

1655.04 -> All right, so after that

1656.15 -> the next thing is to investigate findings.

1657.83 -> So that'll hand it back over to Himanshu.

1660.32 -> - Thanks Ryan.

1661.22 -> So as Ryan highlighted, you know,

1663.35 -> GuardDuty has this rich capability

1665.27 -> of providing detections and findings,

1668.66 -> which includes a lot of contextual information.

1671.39 -> But oftentimes customers have asked us

1674.03 -> and especially the security analysts have asked us that,

1676.67 -> you know, how can they correlate that information

1678.842 -> with other activities that might be occurring

1681.92 -> in the account.

1682.91 -> So for instance, you know, who launched that instance

1686.023 -> or what role was assumed or what session was assumed

1690.77 -> to actually take the action.

1692.3 -> And then what other API calls were made

1694.61 -> or what actions were performed.

1696.53 -> This is something that Amazon Detective

1698.9 -> is natively collecting all the information and telemetry.

1703.28 -> So all the network activity from flow logs,

1706.07 -> all the API activity from CloudTrail,

1708.8 -> and now findings from our own security services

1712.22 -> like GuardDuty, Inspector lately.

1714.89 -> And then just last few weeks ago,

1717.47 -> we announced the ability to integrate

1719.84 -> all of Security Hub's finding into Detective as well,

1723.38 -> so that it can then bring all of that information

1726.445 -> and build that correlational behavioral graph database

1730.07 -> that customers can actually visualize

1731.922 -> within the AWS console itself as well,

1735.02 -> or leverage APIs to integrate that information.

1739.46 -> So Amazon Detective is focused on helping customers

1743.39 -> save time and effort,

1745.49 -> which is required to investigate the root cause analysis

1748.586 -> of a certain event or look at the trends

1751.85 -> as to what were the actions that a threat actor

1754.85 -> might have taken to actually launch that threat.

1758.12 -> Using machine learning model,

1759.566 -> Amazon Detective not only creates

1761.99 -> the behavioral graph database,

1763.28 -> but also creates a baseline activity

1765.68 -> of what's happening in the account.

1768.23 -> This is both related to either network activity

1771.11 -> as well as API activity.

1773.18 -> As I mentioned earlier,

1774.41 -> Detective is also collecting and retaining this information

1777.59 -> for as long as 12 months.

1779.72 -> So most of the time security teams

1781.28 -> might want to go back in time

1783.02 -> and also view the trends for the last, you know,

1786.47 -> 45 days or three months, et cetera.

1789.53 -> So easily changing the scope time in Detective,

1792.5 -> you can actually view all that information

1795.02 -> and then the graph updates automatically within the console.

1799.43 -> Lately we've announced a new feature in Detective

1802.61 -> that can help aggregate these findings collectively

1806.06 -> and then highlight them either at the techniques tactics

1810.38 -> as well as procedures level

1812 -> or at the resource level as well.

1814.28 -> As you can imagine, you know,

1815.45 -> GuardDuty findings are automatically

1817.4 -> being ingested by Detective,

1819.23 -> so it can also highlight at the resource level,

1822.35 -> not only the one finding that you might see

1825.02 -> in your incident response queue,

1826.7 -> but also all the other findings or other vulnerabilities

1830.6 -> that are potentially on that resource.

1833.957 -> So as of yesterday,

1835.85 -> there was a new announcement that was made,

1838.22 -> which is that Detective now is able to bring in information

1841.67 -> from new sources such as Security Hub findings,

1845.622 -> as well as now supports all

1848.84 -> of our Amazon Security finding format related findings,

1853.79 -> which increases the number of entities

1856.16 -> in that behavioral graph

1857.6 -> and now provides much richer context

1859.85 -> and correlation to customers.

1862.19 -> Also over the time we've added detections

1864.92 -> and the ability to investigate events for RDS, Lambda,

1869.6 -> and EKS runtime monitoring findings

1871.94 -> from GuardDuty in Detective as well.

1875.3 -> One of the other features that was recently announced

1877.97 -> in Detective is the finding groups and visualizations.

1882.227 -> Although customers could actually go in

1884.72 -> and traverse that behavioral graph

1887.27 -> with regards to API activity.

1889.52 -> But we've also now created a visual graph interface

1892.7 -> that provides that correlation element

1895.28 -> in a visual element so that you can reduce the time

1898.46 -> further on the correlation elements,

1900.74 -> either starting from a finding or an incident

1903.89 -> or starting from a resource or an entity,

1907.25 -> for example, an IP address, et cetera.

1910.82 -> So let's switch over and see how this looks like

1912.92 -> in the console.

1914.96 -> So this is the Detective console

1916.82 -> and on the summary page itself now

1918.71 -> we have this findings group.

1920.63 -> The findings group is actually our way

1923 -> of aggregating these findings automatically

1925.578 -> on the techniques, tactics, and procedures level.

1929.45 -> This is all mapped to the Mitre attack framework.

1933.05 -> So it tells you actually what were the tactics

1935.51 -> that were taken, what is the path of,

1937.563 -> all the way from initial access to exfiltration

1941.81 -> for that particular resource

1944.18 -> that is this finding group here.

1945.89 -> And then down below here is the visualization

1949.43 -> of that finding group as well.

1952.07 -> So here you can actually select one of these,

1955.19 -> the legend shows you what all this stands for.

1958.43 -> So these are GuardDuty findings,

1960.08 -> which you can start and initiate your journey from

1963.05 -> for incident response

1964.059 -> or you can go to impacted resources

1966.65 -> like the instance to view the instance ID.

1970.1 -> But more importantly,

1971.51 -> when you go to viewing the details here,

1975.35 -> it'll show you what are the involved entities.

1978.17 -> So these involved entities could be IP address,

1980.69 -> could be instance IDs, or could be resource IDs.

1984.26 -> And we are showing you here from this IP address,

1987.26 -> we observed all these threat tactics

1989.491 -> that have been reported.

1991.52 -> So all that information is easily aggregated.

1993.792 -> Also, you can further dive and drill down

1997.13 -> into the details related to involved findings,

2000.4 -> which mean what are the known findings

2002.41 -> that have already been reported for this resource.

2004.63 -> And here you can see like I have multiple known findings

2008.71 -> already reported for this instance.

2010.715 -> And from those multiple IP addresses.

2014.26 -> From here, you can actually continue

2015.82 -> to traverse your journey if you click

2017.38 -> on one of these entities

2018.64 -> like this instance ID for instance,

2020.71 -> you can see when was this instance created

2023.32 -> by who was it created,

2024.97 -> what role was assumed to create this instance?

2029.29 -> And then here again,

2030.22 -> we are showing you all the findings that are reported now

2032.95 -> by, not only by GuardDuty,

2034.45 -> but also by other security tools

2036.328 -> that Detective integrates with.

2039.13 -> And then what are all the different findings

2040.99 -> that are related to that?

2042.76 -> And you can continue to further drill down into this

2046.66 -> by looking at things like

2048.1 -> what new behavior was observed for this instance

2051.395 -> from either geolocation or API activity.

2055.176 -> And in this case, what all Kubernetes activity,

2057.91 -> since we are bringing in the EKS information as well now

2061.12 -> with the container pods.

2062.74 -> The other thing you can do is you can easily change

2064.81 -> the scope time.

2066.607 -> As I mentioned, you can go back

2067.44 -> as long as 12 months because once Detective is enabled,

2071.05 -> it's collecting all that information and correlating that.

2074.98 -> Detective is actually one of our very few services

2078.07 -> which is natively all available

2080.68 -> from a user experience standpoint within the console.

2083.65 -> That means you can actually traverse this graph

2085.9 -> and you can look at the behavioral graph

2087.58 -> and dive down into the findings detail

2089.98 -> using the console without going,

2091.9 -> without having to go out of the console at all.

2097.12 -> So with that I'll hand it over to Ryan

2099.01 -> for the next detection service.

2100.39 -> - Thank you.

2102.397 -> So the next service that we're talking about is

2104.11 -> for managing vulnerabilities.

2106 -> So generally speaking,

2106.84 -> we think about vulnerabilities in the context of,

2108.317 -> you know, software vulnerabilities.

2110.8 -> And our service that addresses this is Amazon Inspector.

2115.09 -> So this is an automated vulnerability assessment.

2117.22 -> So it's a lot different

2118.6 -> than a traditional vulnerability assessment

2120.34 -> where you have to schedule scans and things like that.

2122.79 -> It is run automatically

2124.45 -> and it's run almost continuously.

2126.88 -> We leveraged the systems manager agent

2129.1 -> in order to collect information about the packages

2131.77 -> that are on the EC2 instance.

2133.99 -> Recently we extended that too to do deep scanning.

2136.6 -> So previously it would look at the EC2 instance

2139.6 -> and it would look at the package managers

2141.37 -> to understand what software was installed.

2143.26 -> Now we can actually go scan the volumes themselves

2145.51 -> and understand if there's other pieces of software

2147.7 -> that were installed outside of the package manager itself.

2151.12 -> It also has a direct integration

2153.04 -> with the Elastic Container Registry.

2154.93 -> So there's nothing, there's no agents

2156.43 -> or nothing involved to scan the ECR.

2158.17 -> If you turn on ECR scanning,

2159.656 -> we will automatically start scanning

2161.38 -> all of the ECR repos across your organization

2164.11 -> and identify vulnerabilities that are there.

2166.84 -> At re:Invent last year,

2168.1 -> we announced support for AWS Lambda as well.

2170.38 -> So Lambda, especially with Lambda layers

2172.24 -> that we could already scan some of the packages

2175.3 -> if they were in ECR Repos,

2178.96 -> but with the standard scanning now

2180.25 -> we can also scan the code that you push

2182.56 -> up into the function itself.

2184.36 -> So what we had launched last year

2186.04 -> at re:Invent was the standard scanning.

2187.63 -> So we're looking at the package dependencies

2189.79 -> that are within the functions code definition,

2193.03 -> looking for CVEs.

2194.62 -> What we announced yesterday

2196.57 -> at our keynote was the code scanning.

2198.52 -> So this is really cool, it's an integration

2200.65 -> we worked with CodeGuru on to actually scan

2204.73 -> the source code itself and look for vulnerabilities

2208.48 -> like injection flaws or data leaks, weak cryptography,

2212.14 -> other best practice misses that can be identified

2214.89 -> in the source code to raise findings about that,

2218.8 -> that aren't necessarily packaged vulnerabilities.

2220.51 -> It's more a software development vulnerability.

2224.29 -> And for both of these,

2225.25 -> it happens again automatically.

2226.6 -> So once this is turned on,

2228.19 -> we scan all of your functions.

2229.87 -> If somebody updates the function or creates a new function,

2232.36 -> they're automatically scanned at that time as well.

2236.35 -> So these have to be enabled.

2237.58 -> And again, like with GuardDuty as we were showing you,

2239.89 -> you have the ability to manage

2242.181 -> all of these features and functionality,

2244.441 -> not just for a single account,

2246.34 -> but across your organization.

2248.056 -> And for Lambda, you can choose whether or not

2250.24 -> you want just the package level scanning,

2252.31 -> the standard scanning,

2253.3 -> or if you want us to do the code level scanning as well.

2255.91 -> And again, you can do that at the organization level

2258.13 -> or on individual accounts as well.

2261.04 -> So I'll show you the findings in the console here

2262.75 -> in a minute with more detail.

2264.28 -> But as you can see,

2265.36 -> you get a lot of context about these findings.

2267.46 -> What is the package,

2268.6 -> what is the required update

2270.07 -> in order to fix that vulnerability?

2273.58 -> And then the other ones

2274.87 -> that are really important is exploit availability.

2277.09 -> So this really helps when it comes to

2279.088 -> looking at prioritizing which of vulnerabilities

2282.22 -> maybe you wanna start with.

2283.27 -> Right, there can often be more work to do

2286.45 -> than you have time to complete,

2287.83 -> especially when it comes to vulnerability management.

2289.78 -> So we try to help give you clues

2291.37 -> as to which ones you might want to prioritize.

2294.04 -> And then the code scanning

2295.42 -> as you can see over there as well,

2296.74 -> will show you the exact line of code

2298.801 -> that needs to be addressed

2300.4 -> and a recommended suggested fix

2302.83 -> for that line of code.

2304.12 -> So it really helps identify

2306.37 -> these vulnerabilities in your code.

2308.74 -> The other thing that we launched for Inspector yesterday

2312.07 -> is the Software Bill of Materials.

2313.57 -> So we're scanning all of your instances,

2315.79 -> we're scanning all of your Lambda functions

2317.47 -> and your ACR Repos.

2318.73 -> We're looking for vulnerabilities,

2320.23 -> but we can also then collect very rich information

2323.05 -> about what you have installed across

2325.09 -> to your entire compute landscape.

2327.19 -> This can be very useful if you know,

2329.02 -> you suddenly wanted to know, hey,

2330.43 -> do we have a particular version of a piece of software

2333.13 -> running anywhere in my environment?

2335.02 -> Well, software bill materials will help you do that.

2337.21 -> We support two of the most common

2339.97 -> industry supported formats.

2341.62 -> So CycloneDX and SPDX.

2343.709 -> This is a free service,

2345.61 -> so you export this directly to S3.

2348.7 -> It'll put the S3 bucket and then you can run Athena queries.

2351.16 -> You can use QuickSight to visualize it.

2352.96 -> You can run your own tools against the data

2354.58 -> if you wish as well.

2355.627 -> And this again will help you understand

2358.33 -> exactly what software you have

2359.71 -> and if there's any vulnerabilities

2361.21 -> identified for those packages,

2363.22 -> will include that as well in the Bill of Materials

2366.82 -> that gets written out.

2368.98 -> I'll just show you what some of the looks like here.

2371.35 -> So again, on the Inspector console,

2373.845 -> we have a summary page that gives you

2376.3 -> at first an understanding

2377.38 -> of how your environment is coverage looks.

2380.05 -> So how many of your accounts have it enabled,

2382.451 -> how many instances you don't have

2384.664 -> the Inspector reporting on.

2387.1 -> So like if you don't have the SSM agent active,

2389.8 -> then you'll have instances that aren't covered.

2391.78 -> Same for your ECR repositories and Lambda functions.

2395.11 -> We highlight what your most critical findings are up top.

2397.27 -> So again, give you a way to help prioritize

2399.383 -> and put focus where you need to start first.

2402.53 -> And we do some risk-based remediation.

2405.19 -> So these are vulnerabilities that are impacting

2407.95 -> lots of different resources within your environment

2410.59 -> and then are either high or critical

2412.3 -> from a vulnerability standpoint.

2413.98 -> Again, just to help focus people

2415.69 -> on where you might wanna start.

2418.24 -> And then again,

2419.073 -> will show you the top findings by ECR repo,

2423.19 -> by instances, by AMIs.

2425.71 -> So if you're using common images across your environment

2428.62 -> and you're using auto scaling for example,

2430.33 -> you might have a large number of instances

2431.95 -> that have the same vulnerability,

2433.36 -> but it's path to fixing that

2434.71 -> is probably in an image somewhere.

2436.18 -> So, knowing which AMIs you might want to go update

2439.21 -> and re-spin is a very useful way of tackling those.

2442.66 -> And then again, for your Lambda functions,

2444.73 -> so I'll take a look at a couple of these here.

2446.68 -> So I can look at these Lambda functions

2449.59 -> and you can see the vulnerability that's on there.

2451.9 -> And again, we will tell you whether or not

2453.67 -> there's a fix for it,

2454.57 -> and also if we've seen it being exploited in the wild.

2458.98 -> And also when the last time

2460.51 -> we saw it publicly being exploited.

2462.82 -> Again, all very useful for understanding what it is,

2465.34 -> which of the vulnerabilities

2466.72 -> you might want to go address in your environment first,

2469.24 -> and then the remediation step.

2470.95 -> So what version do you need to run

2472.69 -> versus what version are you running

2474.07 -> in order to be not vulnerable anymore?

2476.77 -> Links to external data sources for the CVE itself.

2479.963 -> And then all the information

2482.14 -> that you need about that function.

2483.58 -> So the context of where that lives,

2485.11 -> what account it lives in, what the function ARN is,

2488.11 -> the runtime that was used.

2490.78 -> So what type of code, that's Python for example.

2493.15 -> And then any of the tag data that's associated with it.

2497.38 -> And then similarly on the code scanning as I mentioned,

2501.07 -> this is where we're gonna look at the actual source code

2503.38 -> that's uploaded into the Lambda function.

2506.574 -> Show you what was found.

2508.75 -> So this was a CWE, and in this case,

2512.05 -> I'm binding a socket to any IP address, right?

2515.74 -> So that means basically anyone can come along

2517.93 -> and it will accept a connection from that.

2520.15 -> And then it gives you the recommendation

2521.62 -> on how you should go about fixing that,

2523.54 -> highlighting the exact line of code

2525.61 -> where that particular software vulnerability was identified.

2528.55 -> And then again, all the context about the function itself.

2533.77 -> - From these detection services,

2535.57 -> you can see that as the findings are generated

2537.736 -> once they're available in the console,

2540.52 -> they're also available through the EventBridge,

2542.718 -> EventBus queue to orchestrate them

2545.62 -> and aggregate them in downstream automation.

2548.86 -> More importantly, they all are aggregated in Security Hub.

2553.18 -> So Security Hub is our centralized monitoring service

2556.45 -> that is bringing in findings

2559.54 -> from native AWS Security Services

2562.39 -> as well as partner integrated tools.

2564.61 -> So you can actually have one place

2566.59 -> to aggregate all these findings.

2568.75 -> Additionally, Security Hub normalizes these findings

2571.15 -> into Amazon security finding format,

2573.94 -> which as I mentioned earlier,

2575.02 -> then Detective leverages to correlate

2577.33 -> that information easily as well.

2580.3 -> More importantly, what Security Hub is doing

2582.4 -> is helping customers stay secure

2585.01 -> by providing an overarching view of controls

2588.28 -> that are being evaluated.

2589.93 -> So Security Hub uses

2591.409 -> at the foundation AWS configure recorder

2594.49 -> to continuously monitor new workloads,

2597.52 -> new controls that are implemented automatically,

2600.97 -> and then help customers understand that risk

2604.99 -> or evaluate those controls on built-in standards.

2608.47 -> So some of the standards that are already available

2610.54 -> in the service are things

2612.22 -> like the AWS foundational security best practices,

2615.13 -> which is our collection of these controls

2618.25 -> telling customers where they can go

2620.11 -> and address some of the security gaps.

2623.08 -> Additionally, we will also launch a NIST standard now

2625.96 -> that's available based on customer feedback.

2628.54 -> And then the CIS benchmarks have been updated

2631.51 -> to the latest version based on

2633.55 -> the new controls and definitions.

2635.582 -> Additionally, Security Hub also integrates

2638.2 -> with Control Tower, which is our governance

2640.603 -> and baselining service that helps customers

2643.195 -> define now either preventative or detective controls.

2647.83 -> So those evaluations and those findings

2650.14 -> can also be integrated into Security Hub.

2653.74 -> Using all these findings,

2655.24 -> customers can then automatically orchestrate operations

2659.2 -> that could be either as simple as defining workflows

2662.62 -> for ticketing and/or using chat based operations,

2666.7 -> sending it to the incident response teams,

2668.846 -> and taking event-based actions

2672.97 -> by integrating them with either step functions

2675.25 -> or Lambdas or defining CloudWatch,

2678.01 -> custom CloudWatch actions that can then take

2680.59 -> collective response actions as well.

2684.01 -> Customers and we have published GitHub library of, you know,

2688.75 -> these runbooks and playbooks that actually customers

2691.36 -> can easily import and also add them to the workflow

2694.72 -> within Security Hub's interface to take those actions.

2699.91 -> Most recently we've added a new feature

2702.22 -> that was just announced yesterday,

2703.57 -> which is the Automation Rules in Security Hub as well.

2706.39 -> Oftentimes, you know, customers will receive findings

2709.127 -> which they would want to go

2711.46 -> and change the attributes on conditions on

2713.98 -> before they are routed downstream for taking actions.

2717.43 -> So that's where now Security Hub allows customers

2720.43 -> to create those automation rules as well.

2722.89 -> And then they can also see the history

2725.11 -> of what changed in those findings.

2728.23 -> So Security Hub is essentially focused on

2731.2 -> providing not only their risk view,

2733.54 -> but also helping customers to orchestrate a response

2736.9 -> and remediation across their full AWS workload.

2741.422 -> And then it allows customers to either

2743.89 -> leverage custom CloudWatch actions

2745.99 -> for that automated response

2747.58 -> or leverage built-in native partner integrations

2750.94 -> to either SIM and/or SOAR platforms

2754 -> or XDR platforms where you can send these findings.

2757.262 -> And this is again to help customers easily integrate

2760.9 -> with existing workflows

2762.52 -> so that you can enable the incident response teams.

2767.05 -> Going back to the console here for Security Hub.

2771.298 -> On the summary page of Security Hub,

2773.53 -> you can see all the standards that are enabled

2777.16 -> and then a high level aggregated view

2779.5 -> of the risk posture across those standards.

2782.8 -> Additionally, we'll give you more information

2784.87 -> around what regions these findings

2787.42 -> are getting aggregated from.

2788.8 -> Security Hub is actually one of our other services

2791.2 -> where not only are we bringing information

2793.42 -> from multiple accounts,

2795.19 -> but also multiple regions as well.

2797.05 -> So since AWS organizations is a regional construct,

2800.74 -> we've enabled a cross-regional aggregation

2803.41 -> of these findings so that there's one place

2805.87 -> to view that across all regions as well.

2808.6 -> Additionally, customers can create insights

2810.771 -> which could be useful for their security teams

2813.7 -> based on either a resource type

2815.32 -> or based on a workload type.

2818.32 -> From here, you can either dive into controls

2821.53 -> or go into a specific standard

2824.11 -> and you can view what are all the different findings

2828.37 -> and what exactly are the controls

2830.446 -> that are evaluated as passed or fail.

2834.19 -> These are all automatically ordered

2837.28 -> in the order of severity.

2838.75 -> So from here you can see like, you know,

2840.43 -> I have a user, a root user, who does not have MFA.

2844.12 -> Again, a critical finding.

2845.56 -> And then you can actually dive into these findings

2848.11 -> from here based on either filter them by resource.

2852.25 -> So if you just wanna look at your failed findings

2855.18 -> and from here dive deeper in,

2857.355 -> you can actually click in on this finding as well

2860.89 -> and look at, you know,

2862.09 -> what are the controls that were failing.

2864.67 -> And then from here you can dive

2866.11 -> into the finding itself as well.

2868.45 -> Also, all the findings are available

2870.603 -> in one single view here as well.

2874.18 -> So you can see here the finding detail.

2877.6 -> These are all organized

2879.07 -> in the Amazon security finding format

2881.35 -> and most recently we've actually included a feature

2884.41 -> where you can not only see the details of the finding,

2887.23 -> but you can also view the history of the finding as well,

2890.41 -> which is how has this finding, you know,

2893.77 -> manifested itself and then what are the changes

2895.84 -> that have been happening.

2897.22 -> So here you can actually see

2899.23 -> one of the new features that was announced yesterday,

2901.24 -> which is automation rules.

2903.677 -> This finding has been changed and edited

2906.4 -> or evaluated by that automation rule.

2908.86 -> So automation rules is a way of helping customers

2912.01 -> define their own custom actions

2914.657 -> that they want to take on these attributes

2918.958 -> before these findings are then either sent

2921.94 -> to the incident response team and/or downstream tools.

2925.39 -> So things like, you know,

2926.44 -> changing the severity of the finding

2928.428 -> based on certain either product that it came from

2933.34 -> or the resource that it came from,

2935.32 -> or elevating that finding.

2937.03 -> And also enriching that finding

2938.56 -> with security defined information.

2940.18 -> So here you can see what was the rule that was defined,

2943.419 -> giving it a name to enrich that finding,

2946.15 -> and then also the criteria that was used,

2948.67 -> in this case, the product name.

2950.95 -> And then what automated action is being used,

2953.753 -> in this case to be tagged

2956.303 -> so that once it's received by the incident response team,

2960.58 -> they have this additional enrichment that they can use.

2963.55 -> So these automation rules should help customers define

2967.038 -> or add more context to these findings

2969.73 -> before they're sent to this.

2972.76 -> Moving forward, we wanted to also help customers

2975.76 -> centralize the management of security data

2978.37 -> for all your workloads across your enterprise.

2981.16 -> So not only just AWS workloads,

2983.29 -> and not only just findings,

2984.58 -> but also the log information,

2986.5 -> which is often required by the security teams.

2989.59 -> So last year at re:Invent,

2992.08 -> we announced a service Amazon Security Lake,

2994.9 -> which is now generally available as of last week.

2997.599 -> Security Lake helps customers

3000.03 -> centralize all the log information,

3002.387 -> not only from AWS native logs and workloads,

3005.94 -> but also non AWS logs,

3008.758 -> either from on-premise applications

3011.31 -> or SaaS applications or other cloud providers as well.

3015.48 -> Easily aggregate that and centralize that

3017.94 -> and optimize all that information

3019.86 -> in a standard format called

3021.75 -> the Open Cybersecurity Schema Framework.

3024.45 -> That's an initiative that Amazon actually partnered

3026.7 -> with industrial leaders

3028.44 -> and then it's an open standard schema

3030.33 -> or our way of democratizing the finding format

3033.6 -> for all the tools that are generating findings.

3037.95 -> Once it's normalized,

3039.15 -> then it's available for analysis

3040.86 -> that customers can integrate

3042.6 -> with multiple different analytic tools.

3044.61 -> So whether it's a SIM tool that you might be using

3046.98 -> or a Soil tool.

3049.05 -> One of the common objections

3050.16 -> we heard from customers was that

3052.2 -> they often didn't have control over their security data

3055.83 -> to either enrich that or they were spending too much cost

3059.64 -> on either ingress or egress of that data to other tools.

3064.59 -> So the way this service works is that at the center of it,

3068.79 -> once it's enabled at the account level,

3071.94 -> it can automatically create

3074.31 -> a centralized S3 lake formation bucket.

3077.04 -> It can be integrated with AWS organizations

3081.69 -> for centralized management

3083.228 -> and aggregation across multiple accounts.

3086.49 -> And automatically the AWS log sources

3089.25 -> that are today integrated are all

3091.677 -> the API activity from CloudTrail,

3094.14 -> network activity from flow logs,

3096.21 -> and also data plane events from S3 and Lambda

3099.24 -> and the security findings from Security Hub.

3101.91 -> So all that information

3103.14 -> is actually automatically integrated,

3104.91 -> which means customers do not have to go

3106.95 -> and exclusively enable any of these log sources.

3110.73 -> In addition to that,

3111.671 -> our partners and other solution providers

3114.93 -> have built integrations that can bring in

3117.9 -> their log information as well.

3119.97 -> So whether it's from, you know,

3121.44 -> endpoint telemetry or whether it's from SaaS applications

3125.13 -> like firewall, gateway providers,

3127.44 -> and/or identity providers, et cetera,

3129.723 -> all that log information can also be integrated

3132.87 -> into that centralized S3 lake formation bucket.

3136.32 -> And then we also have options for customers

3138.6 -> to add their own custom sources.

3140.73 -> So either you might have existing data

3142.77 -> that your security team is using,

3144.54 -> or in the future you might wanna bring in

3146.67 -> not only your corporate workforce data,

3148.86 -> but consumer logs as well.

3150.51 -> So there are options to bring in that data as well.

3153.45 -> For the AWS log sources,

3155.7 -> we will automatically normalize that into OCSF,

3158.76 -> and then our partners are integrating and you know,

3162.21 -> providing integrations to bring in

3163.89 -> their logs in OCSF format as well.

3167.04 -> Also, in the center of the service,

3168.72 -> you can actually set up the lifecycle management,

3171.06 -> which means you can define

3172.59 -> what you want to do with that data

3174.51 -> and who should use that data and how they should use it.

3178.26 -> For example, security teams might need, you know,

3181.14 -> 30 days worth of data or three months worth of data

3184.38 -> for active analytics.

3186 -> So you can keep that in hot storage

3188.07 -> and the rest can be stored

3189.75 -> for longer term retention in cold storage.

3192.78 -> So those are configurations that you can define easily.

3196.339 -> All the data is then automatically standardized schema

3200.37 -> as well as directory structure,

3201.87 -> so you can actually go in and per region or per account

3205.41 -> traverse the data all the way down to the parque objects,

3208.71 -> which is automatically done.

3210.3 -> So as I mentioned,

3211.29 -> once you enable the service in your account,

3214.2 -> we do all the operationalization in the backend

3216.54 -> so that you don't have to create multiple S3 buckets

3219.21 -> and you don't have to run glue tables or Lambdas.

3222.18 -> That is all automatically done

3223.95 -> and the information from the AWS logs

3225.9 -> is brought automatically in.

3228.39 -> What you see on the right hand side is the flexibility

3230.46 -> of what you can do with that data.

3232.23 -> There are two ways that data can be accessed.

3234.48 -> The first one is direct S3 access,

3236.76 -> where you can stream S3 objects to an integrated tool.

3241.11 -> Or the second one is in place query access,

3243.6 -> which means you don't have to move the data anywhere

3246.06 -> because we are supporting virtual indexing

3248.19 -> and virtual querying in the service,

3250.59 -> you can actually query the data from where it is as well.

3253.95 -> So using native AWS analytic tools like Athena,

3257.28 -> you can actually run standard SQL queries

3259.29 -> because all the data is now transformed

3262.11 -> in a standard schema.

3263.79 -> So you're no longer writing complex queries

3266.34 -> to look for IP address, for example,

3268.44 -> which might be different in format for AWS logs

3271.53 -> versus a firewall log.

3273.42 -> All of that is automatically normalized and ETL into OCSF.

3278.82 -> That helps reduce quarry times,

3281.124 -> that helps reduce the time to respond,

3283.86 -> and create much more richer analytics downstream.

3287.13 -> Also, customers can leverage tools like OpenSearch,

3289.68 -> QuickSight, Kibana, et cetera,

3291.3 -> to build their own custom dashboards

3293.34 -> and use native integrations with tools like,

3296.513 -> you know, Splunk or QRadar, et cetera.

3300.12 -> So there's a list of variety of partners

3302.52 -> that are already available

3303.69 -> both as sources as well as subscribers in the service.

3307.86 -> So we hope customers will leverage

3309.12 -> this service to orchestrate

3311.19 -> and easily manage all the data

3313.86 -> that's needed for security analytics.

3315.9 -> And this will actually give them control of their data

3319.02 -> as well as easily allow to aggregate

3321.63 -> and centralize that data for their security teams.

3325.199 -> So to summarize,

3326.46 -> all of our security services are here to help customers

3329.28 -> protect their workloads.

3330.75 -> One of the key aspects of protection

3332.94 -> is to first be able to detect some of the elements.

3336.759 -> So security tools that are natively available

3339.57 -> in AWS are integrated with AWS workloads

3342.81 -> that eliminate the need of any operationalization.

3345.45 -> It also helps reduce the burden from the security team

3348.586 -> by allowing them to easily centrally manage

3351.69 -> all these security services,

3353.19 -> easily enable these services as well.

3355.47 -> And then finally, to allow for scale

3358.359 -> and then centralized management of security data,

3361.53 -> we now have a service that can allow customers

3363.63 -> to do that as well.

3365.52 -> Like I said, most of these services

3366.96 -> can be deployed at a single click,

3369.27 -> so there's no additional log enablement

3371.22 -> or operationalization required.

3373.911 -> So with that, thanks for your time

3375.66 -> and thanks for joining.

3377.04 -> Please take the session survey

3378.39 -> and appreciate you joining us today.

3380.25 -> Thank you.

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