AWS re:Inforce 2022 - Using graphs for security operations insights (sponsored by Wiz) (DEM224-S)

Aug 16, 2023

AWS re:Inforce 2022 - Using graphs for security operations insights (sponsored by Wiz) (DEM224-S)

It’s easy to find risks in IT infrastructure, but it can be challenging to find the ones that are most critical because of an overload of information without much context. Access patterns across connected resources like VMs, containers, and applications can be used to correlate related issues that create attack vectors. Security graphs—using a graph data structure to improve security—are one of the largest and fastest growing use cases for Amazon Neptune. In this talk, explore how graphs can improve security operations insights. Hear from a Neptune customer, Wiz, about how they use graphs to provide a contextual risk assessment of clients’ clouds and cloud protection at scale. This presentation is brought to you by Wiz, an AWS Partner.

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

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

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

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

#reInforce2022 #CloudSecurity #AWS #AmazonWebServices #CloudComputing

Content

0.87 -> - Good morning.

2.16 -> Hey, everybody, we're so glad to have you here.

4.02 -> It's been a while since we've been in Boston.

6.09 -> So I went to college here.

7.32 -> I'm really excited to be back myself, too.

10.26 -> So we wanted to welcome you.

11.37 -> We're gonna have some wonderful speakers

12.45 -> throughout the day today,

13.35 -> and we're gonna get started this morning

14.67 -> with a joint presentation from Wiz and AWS.

18 -> So if you would please welcome

19.2 -> to the stage here in the Galaxy Theater,

20.58 -> they're gonna kick things off for us.

22.2 -> He came all the way from Tel Aviv.

24.15 -> This is Yinon Costica and Brad Bebee.

31.2 -> - Good morning.

32.033 -> Welcome, everybody.

33.15 -> I'm Brad Bebee.

34.38 -> I'm the general manager for Amazon Neptune,

36.93 -> and this session is "Using Graphs

39.6 -> for Security Operations Insights."

41.76 -> And I'm very pleased to present it with Yinon Costica

45 -> of an AWS partner and Amazon Neptune customer, Wiz.

49.41 -> Before we get started,

50.61 -> I just wanted to take a quick check of the room.

53.67 -> How many people are using graphs today

56.19 -> as part of their operations?

59.36 -> A few, okay.

60.57 -> How many people are using a graph database?

64.68 -> All right, how many people are using Amazon Neptune?

68.82 -> Okay.

71.19 -> Customers are really excited about graphs.

75.3 -> Thousands of customers are using Neptune every day.

79.68 -> The reason that they're excited about it

82.08 -> is because graphs allow you

84.6 -> to use the relationships in your data

89.01 -> to solve problems in different ways

91.02 -> or to solve them, problems, that you can't solve

93.99 -> with other techniques.

96.09 -> The range of graph applications is very broad,

99 -> everything from things that you might expect like fraud,

102.57 -> identity-resolution use cases,

104.82 -> to organizing information,

107.01 -> to life sciences kinds of applications

111.6 -> and, of course, security as a graph.

115.29 -> When you think about many of the challenges in security,

119.79 -> you often start with a graph first,

122.25 -> and you can see this kind of basic example here.

128.28 -> A quick primer on a graph basics.

130.98 -> Graphs are a data structure,

133.89 -> and they consist of nodes and edges.

137.49 -> And what's really important about graphs is that in a graph,

142.32 -> the relationships are first-class objects

145.86 -> in the data structure,

147.27 -> and this means that you can ask questions

149.31 -> about them directly.

150.6 -> You can express patterns, and you can express queries.

154.17 -> And when you're able to do this,

156 -> you're able to address these aspects of your data.

161.04 -> Now, if you think about security as a graph,

163.77 -> starting from your left,

164.73 -> you can see a very notional security model

167.28 -> about the kinds of things that you might be interested in

169.86 -> from a security case.

172.62 -> And on the other side,

173.453 -> you can see how that might be translated into a graph.

176.34 -> And so your key entities, your devices, your hosts,

179.85 -> your users will be represented as nodes.

182.91 -> Those nodes have properties,

184.68 -> so information that's important to you

186.87 -> in terms of addresses, various different kinds of metadata.

190.65 -> And then you can represent the relationships

193.2 -> about how they're connected.

198.36 -> Just like graphs in general,

200.64 -> the range of different security business challenges

203.1 -> is broad, everything from cloud security posture management,

206.91 -> which we'll hear from Wiz in just a second,

209.79 -> to different types of exfiltration,

212.67 -> to just understanding digital forensics,

215.67 -> so potentially a very broad set of applications

219.63 -> for graphs in the security space.

224.43 -> Using graphs can have its own challenges.

227.76 -> Often as you bring different sets of data together,

231.51 -> the relationships become complex and hard to understand.

235.89 -> And so you need to analyze

238.56 -> and take a look at your data model

240.42 -> and understand which pieces are really meaningful

243.27 -> for the kinds of detections that you wanna do.

246.33 -> Often graphs get very large very quickly.

250.86 -> And so you can quickly scale to billions of nodes and edges,

254.28 -> and you need to be able to manage that kind of size.

258.63 -> And then finally,

260.52 -> graphs and security are about protecting things.

262.68 -> And this kind of information is very important.

265.38 -> So you need to make sure that the ways

267.21 -> that you process the information

269.22 -> meet the various different security

270.81 -> and compliance regimes that you have.

275.94 -> This is a very basic example

277.53 -> of the kind of logical flow that you might take

280.47 -> for a security graph.

281.88 -> You start on the left-hand side with your data sources.

285.24 -> You might store them in a data lake, something in Amazon S3,

289.05 -> do different kinds of processing

290.7 -> with things like Amazon EMR to be able to use the data.

295.05 -> And then you might have different kinds

296.22 -> of analytic processing, things like identity resolution,

300.48 -> entity disambiguation.

302.07 -> In this case, we're showing both symbolic

304.41 -> and non-symbolic entity resolution.

306.87 -> And those things create relationships across the data

309.81 -> that you can then use for other parts of your application.

313.83 -> In this case, we're storing in a graph database.

316.17 -> You're driving APIs

318.06 -> that you might be serving other clients with,

320.49 -> and so a very basic example of a security use case.

326.49 -> Why would you think about a graph database service?

329.76 -> Well, graphs as an information model

332.55 -> tend to have a lot of random access.

334.74 -> And so if you think about going from one node,

336.99 -> following a link traversing to another,

339.3 -> you're not able as a database

341.19 -> to lay out the data to get good locality,

344.34 -> for example, as you can in a relational database

346.92 -> with rows and columns.

348.93 -> So graph databases are optimized

350.82 -> for these kinds of graph-access patterns.

354.93 -> A graph service makes managing database itself something

358.47 -> that you don't have to worry about.

360.21 -> You don't have to have the expertise to do that.

363.21 -> And finally, the service itself,

365.13 -> you don't wanna have to think about adding storage

367.29 -> or compute or memory as you grow.

369.3 -> You want the service to do it for you.

373.83 -> Amazon Neptune is a fully managed graph database service

378.57 -> that's optimized for graph processing,

382.05 -> can store graphs of billions of nodes and edges,

385.26 -> and is designed to provide interactive graph queries

390.66 -> and retrievals with millisecond latency.

393.69 -> We provide the most choice

395.55 -> of different kinds of graph languages

397.41 -> supporting the open-source Apache TinkerPop,

399.6 -> openCypher, and RDF and Sparkle.

404.58 -> Thousands of customers use Neptune every day

406.95 -> to manage their graph processing.

408.87 -> And I'm very excited today

410.88 -> to introduce one of them to you, Wiz,

413.7 -> and you'll hear how they're using graph processing

415.98 -> as part of their application.

419.43 -> - Thank you.

422.97 -> Okay, thank you, Brad, and hi also.

425.007 -> I'm in Yinon Costica.

426.51 -> I'm running product management for a company named Wiz.

429.6 -> Wiz is about revolutionizing the way we do cloud security.

435.36 -> Across our environments,

436.86 -> we're leveraging a completely agentless technology,

439.74 -> but then again, this session will be focused

442.23 -> on the use we are doing internally within Wiz

446.19 -> for analyzing all of the security signals.

449.55 -> So we are an agentless and a graph-based approach.

452.82 -> And a little bit about the company,

455.73 -> we really founded Wiz two years ago

459.21 -> in order to do cloud security differently.

462.27 -> We realized that cloud security became way too complex.

466.2 -> It requires understanding of very complex systems,

469.17 -> and this is when we founded Wiz.

471.69 -> In the two years of our existence,

473.73 -> we raised more than $600 million

476.1 -> from the best VCs out there.

477.27 -> But the more important thing is that we already gained trust

479.94 -> for more than 20, actually 25%, of the Fortune 500 companies

484.14 -> alongside hundreds of other companies.

486.39 -> And you can see the leaders

489.84 -> of different industries using Wiz today

492.24 -> to protect their cloud environments.

494.34 -> And the question is what did they see

496.68 -> in Wiz that they didn't have

497.91 -> in all of the other tooling that they have in,

500.58 -> like employed, deployed in the past

502.71 -> and how did Wiz help them?

504.51 -> And Wiz is not only adopted

508.17 -> by such a large number of customers.

510.45 -> It's also basically the fastest growing SaaS company

514.26 -> and also the fastest growing AWS security partner

518.16 -> in the marketplace.

520.02 -> So with that, I want to focus a bit

521.85 -> on how our approach to cloud security,

524.01 -> and then we're gonna deep-dive into the use of the graphs.

526.77 -> First, Wiz is all about agentless.

528.72 -> Wiz can be deployed in a few minutes

530.88 -> on any size of an AWS environment.

533.4 -> It can be deployed at the account level,

535.44 -> at the organizational level.

537.06 -> And basically within just a few minutes,

539.04 -> you can get up and running with Wiz by setting up a role.

542.82 -> This role is actually being used

545.1 -> to analyze, first, all of the cloud APIs, right?

548.19 -> So to interrogate the APIs, interrogate the configuration,

551.25 -> so the control plane of the cloud.

553.65 -> And then we are actually taking a different approach

557.07 -> to analyzing the workloads,

558.93 -> so the VMs, the containers, the serverless functions,

561.9 -> by analyzing the actual running workloads,

565.08 -> by analyzing the snapshots, container,

568.05 -> running container images,

569.46 -> analyzing containers from the registry,

571.92 -> analyzing the serverless function code.

574.26 -> And by doing this, you can actually connect Wiz

576.51 -> using a single role but get a full analysis

579.24 -> of everything that you have running in your cloud.

581.76 -> Now, using this deployment, what we're actually doing,

584.91 -> we are running a very broad set of assessments.

587.43 -> The assessments start with the traditional scanners

589.86 -> that we all know about,

590.79 -> so a vulnerability scanner, a malware scanner,

593.25 -> a configuration analysis to identify misconfigurations

597.06 -> and non-compliant configurations.

598.98 -> But these are the traditional ones.

600.75 -> In order to make it really good for cloud,

603.45 -> we also need to be able to identify cloud risks.

606.87 -> And understanding cloud risks

608.4 -> is actually about understanding external exposure,

611.22 -> excessive permissions,

612.6 -> lateral movement path, insecure use of secrets.

615.72 -> So we have created an additional set of scanners

618.27 -> in order to really understand also these type of risks.

621.57 -> And this is the first application

623.07 -> of the graph that we will go into.

625.38 -> Then the killer app is actually by taking all of this signal

631.35 -> across all of the different scanners

633.3 -> and combining it on a single graph database, Neptune.

637.47 -> And this is what actually allows us

639.6 -> to take thousands, thousands of findings

642.78 -> of vulnerabilities, of misconfigurations,

645.06 -> and actually sieve out what is the most critical risks

648.36 -> that your organization can actually fix

651.42 -> with the largest impact on your security posture,

654.15 -> what are the actual attack path,

655.92 -> the effective risks that you have in the environment.

658.44 -> And this is all achieved based on the graph.

660.15 -> Think about it this way.

661.38 -> Let's say you have a vulnerable container image

663.39 -> for Log4Shell.

665.31 -> You probably have quite a few of those in the environment,

667.65 -> but you have only one week before the holidays

669.78 -> to fix the ones that really do matter.

671.61 -> How do you know which ones?

672.99 -> So probably you wanna know which ones are internet-facing,

676.08 -> which ones have admin permissions

678.03 -> or access to sensitive data.

679.83 -> And you need to take all of these data points

681.84 -> and correlate them into a single view

683.91 -> that tells you this container image

686.25 -> is your best next action to fix Log4Shell.

689.31 -> We do it using a graph, and we will go deeper into it.

692.88 -> But the really important thing,

695.1 -> all of this happens automatically behind the scenes.

698.07 -> What the customers get in the end is just a list

700.68 -> of prioritized risks that they can basically consume

703.98 -> and start fixing, improving their security posture

706.8 -> by hardening, automating the response,

710.1 -> integrating into their CI/CD pipelines

712.41 -> to prevent this from ever being deployed in the first place.

715.83 -> So this is how organizations can really go up

718.32 -> and scale up with their cloud security posture.

720.93 -> And I wanna focus on why did we choose

723.18 -> to model everything as a graph.

725.01 -> And the reason is that cloud, like real life,

728.16 -> is ultra complex,

729.57 -> and I'm thinking even about myself presenting here.

732.87 -> So I'm a co-founder of a company named Wiz.

736.11 -> We have investors like Sequoia, Index.

738.63 -> I'm currently in re:Inforce that happens

741.18 -> in Boston, Massachusetts, USA.

744.45 -> It's a conference by AWS.

747.18 -> And what I've listed now is a very complex set of entities

751.71 -> with relationships between them.

753.78 -> And let's say now I'm an investor in Sequoia,

756.45 -> and I wanna visit all of the co-founders

759.36 -> that Sequoia invested in that are currently presenting

762.24 -> in a conference in Boston.

763.98 -> Think about doing it without a graph.

766.17 -> Think about correlating all of these data,

768.21 -> joining all of these tables

769.74 -> just to find out an answer to this.

771.78 -> A graph can actually answer

773.19 -> that complex question in a second.

775.68 -> It's all about modeling,

776.88 -> and when we think about modeling,

778.47 -> we have, of course, entities,

780.72 -> but entities have types like humans, companies, VCs.

785.07 -> And when we correlate all of this,

786.51 -> it allows us the power of asking complex question not only

790.08 -> on the entities but also the relationships between them.

793.26 -> And this is where we actually modeled cloud security

796.41 -> on a graph.

797.25 -> What do we need to model on a graph

798.81 -> when it comes to cloud security?

800.58 -> We need to identify attack path.

802.38 -> What is an attack path?

803.49 -> What is a critical attack path?

805.38 -> Actually, it's an exposure

806.97 -> that allows an external threat actor

809.58 -> to compromise a resource and get into a high-value asset,

814.23 -> such as an admin account or a sensitive bucket

816.87 -> or a sensitive database.

819.03 -> This is an entire attack path,

820.74 -> and if I'm able to identify these attack paths

824.13 -> in your cloud environment within minutes,

826.44 -> you can also fix those in minutes

829.53 -> because you know these are the attack paths you should find.

832.44 -> So in order to address this question,

834.3 -> we modeled the entire cloud as a graph,

836.88 -> but we split the answer into three sections.

839.88 -> The first one is, what is actually exposed

842.82 -> across my cloud environment at any given time?

845.91 -> That's a very hard question to address,

847.98 -> many, many configurations.

849.57 -> We use a graph.

851.22 -> What is the priority of the vulnerabilities?

853.2 -> Like we use Log4Shell.

855.54 -> What are the lateral movement paths to high-value assets,

858.87 -> to sensitive resources?

860.91 -> These are three different use cases,

862.56 -> and I'm gonna deep-dive into each one of them.

865.2 -> Let's start with network exposure.

867.87 -> Today, traditional tools, legacy tools,

870.93 -> we're actually looking at the configuration

873.6 -> of every single network element.

876.36 -> This is a very, very noisy approach

879.6 -> because let's say I want to identify a machine

882.54 -> that is internet-exposed.

884.28 -> I can check for the public IP.

886.35 -> Does it mean it is exposed?

887.94 -> No, if a machine has a public IP,

890.16 -> it may not have a gateway at all,

892.86 -> not have a routing rule, so it's not exposed.

895.29 -> So it's noise.

896.4 -> On the flip side, let's say I have a machine

898.08 -> without a public IP.

899.61 -> Does it mean it's not exposed?

901.23 -> No, it can be behind a load balancer.

903.84 -> So actually inspecting one single configuration

906.9 -> to determine exposure is a really bad approach

909.75 -> when it comes to security.

910.95 -> It's great for compliance, really bad to identify risk.

914.49 -> Same thing about inspecting security groups, very noisy.

917.55 -> Maybe I have a security group that is open,

919.59 -> but there is nothing behind it.

921.09 -> Do I need to fix it?

922.17 -> Is there a real risk?

923.25 -> No.

924.3 -> So in order to solve it, what we actually did,

926.73 -> we modeled the entire network configuration topology,

931.05 -> the rules, on a single graph.

934.65 -> This actually allows us to take load balancers,

937.02 -> peering relationships, routing groups, security groups,

940.968 -> Kubernetes configurations,

942.63 -> and layer everything on a single graph

944.88 -> and then ask a very simple question.

947.25 -> Run a flow analysis from the internet

949.89 -> to every single resource in the graph.

952.68 -> And if you manage getting there,

954.75 -> then this resource is exposed, but this exposure is true.

958.32 -> It has taken into account every single configuration

961.29 -> along the path and determined that this is exposed.

964.86 -> So Wiz has actually introduced, using the graph,

967.59 -> the notion of effective network exposure.

970.8 -> So we can look at an environment and give you immediately

973.44 -> what are all the exposed endpoints that you have.

975.81 -> That's the first step.

977.67 -> From here, we are actually moving

980.07 -> to asking questions about prioritizing vulnerabilities

982.89 -> because now I have more context.

984.81 -> To prioritize vulnerabilities,

987.03 -> most, like the traditional approach,

989.01 -> was all around CV and CVSS scores.

991.89 -> So I'm getting Log4Shell with CVSS 10.

995.07 -> Do I need to fix everything?

996.63 -> Well, yes, but not right now, right?

998.67 -> There is more color to it.

999.75 -> There is more context to it.

1001.37 -> Maybe it's internet-exposed,

1002.84 -> and then I need to start from there.

1004.49 -> So we have the graph.

1005.72 -> Now we can say, okay, I know that I have thousands

1008.99 -> of instances with Log4Shell,

1010.94 -> but now I can correlate it

1012.2 -> to the other exposure that we've just seen how to correlate.

1015.53 -> This gives me another priority, but this goes on.

1019.64 -> I can actually correlate it

1020.93 -> with other elements on the same asset.

1023.69 -> Maybe I even exposed secrets on this machine.

1026.24 -> So if this machine gets popped, this is truly impactful.

1030.29 -> This is truly risky.

1031.97 -> And maybe this secret has a lateral movement path

1035.63 -> to a higher value asset.

1038 -> So in fact, what we're doing

1039.29 -> with the graph is not only analyzing flows

1041.87 -> but also analyzing toxic combinations

1044.75 -> like you can see here on the VM,

1046.46 -> correlating vulnerabilities, exposures,

1048.53 -> lateral movement path,

1050.12 -> and then determining the true risk of a vulnerability.

1053.42 -> And there are many discussions on what is a good approach

1056.78 -> to rank vulnerabilities more than just the CVSS,

1060.38 -> the contextual risk.

1062.12 -> And this is exactly how we achieve contextual risk

1065.33 -> on vulnerabilities

1066.32 -> and any type of findings in the environment.

1069.32 -> The third thing is about lateral movement path,

1072.71 -> and lateral movement paths are tricky.

1075.35 -> They are ultra complex.

1077.24 -> They use combinations of secrets,

1079.52 -> identities, permission sets,

1081.92 -> toxic combinations of permissions in order to escalate.

1084.8 -> And the question is,

1085.67 -> how can I identify all of these paths

1088.31 -> that actually lead me from one asset

1090.53 -> to a high-value asset in a very large environment?

1093.89 -> Guess what, this problem is very, very similar

1096.86 -> to the problem we had with the network exposure.

1099.38 -> We just need to model the graph correctly.

1102.11 -> So we modeled the graph,

1103.94 -> and basically we modeled the secrets,

1107.24 -> but we also run a full IM analysis

1110.63 -> that basically tells me for every single role,

1113.51 -> what are all the accessible resources from that role

1116.96 -> and which resources can assume this role.

1119.72 -> So if I have chains of assume role, I can detect them.

1124.01 -> If it's one single hub, two hubs, 10 hubs,

1127.73 -> I can still detect all of these escalation paths

1130.79 -> and more than this.

1132.35 -> We have solved the cross-account access

1134.45 -> because now what we can do, we can ask,

1136.55 -> can I actually move laterally from a development environment

1140.69 -> to a production environment using a secret

1143.24 -> that allows me to access the machine?

1145.79 -> So modeling the graph correctly

1148.49 -> and running the flow allows us

1150.02 -> to identify attack path that literally no one,

1154.79 -> no human can find with traditional tools in the environment.

1158.9 -> It's way too complex.

1161.15 -> And when we run these on customer environments,

1163.58 -> the type of findings it has are outstanding

1167.75 -> because these are actual facts.

1169.97 -> There are no heuristics.

1171.38 -> There is no ML.

1172.46 -> There is no AI.

1173.63 -> It's pure facts correlated together on a graph analysis

1177.53 -> that can tell the engineering team, the security team,

1181.85 -> you have here an exposed resource.

1183.8 -> You thought it's okay

1185.51 -> because it's in the development environment,

1187.58 -> but in fact here is the entire path

1190.43 -> to get to your most sensitive S3 bucket in production.

1193.79 -> And this is why you really need to pay attention,

1196.07 -> even if it looks insignificant.

1199.04 -> So this is the third thing,

1200.21 -> and just for this session for re:Inforce, actually,

1203.12 -> we launched an additional use of the graph.

1205.907 -> The additional use of the graph

1207.53 -> is when we take not only configurations and vulnerabilities,

1211.73 -> but also detections like GuardDuty detections.

1216.41 -> And what we have just launched is the ability

1218.96 -> to take these GuardDuty detections

1221.54 -> or any other threat detections you may have

1224.24 -> in the environment

1225.26 -> and then use the same context of the graph

1228.05 -> in order to quickly understand what is the actual risk

1232.52 -> and whether it is truly important

1234.2 -> to tackle this specific alert right now.

1237.17 -> And the answer is that we can reduce

1238.94 -> by a factor of 10 the time it takes

1241.31 -> to correlate a single threat using the context of the graph.

1246.05 -> So let's take a very simple example,

1248.12 -> SSH brute-force attacks.

1249.8 -> We're getting many of them.

1251.36 -> Any organization, as soon as you open an SSH port,

1254.3 -> it will get a brute-force alert, many of them.

1256.82 -> But then if we can say more things about the resource.

1260.36 -> For instance, not only it is brute force

1263.84 -> and it is internet exposed,

1265.31 -> of course, because it is brute force,

1267.29 -> but this machine from our analysis

1269.42 -> of the snapshot, the agentless analysis,

1271.91 -> we can tell you that this machine

1273.41 -> actually has a weak password.

1275.48 -> And if this password is really easy to get poked,

1279.56 -> an attacker can get access to this machine.

1282.14 -> But now hold on for a second.

1283.76 -> Not only it can get access to this machine,

1286.34 -> it can move laterally using the lateral movement path.

1289.07 -> So security team, if you see this alert

1292.64 -> and this correlation on the graph,

1294.35 -> you really need to take an action right now.

1296.54 -> And this is taking minutes to basically identify

1301.88 -> versus hours to investigate.

1304.1 -> So using it also for sec ops operations.

1307.31 -> Now here is the killer app.

1310.01 -> Everything,

1311.06 -> we could have basically placed this analysis

1313.97 -> in different sections of the graph, different graphs,

1316.43 -> but we didn't.

1317.263 -> We actually took all of this,

1318.89 -> and we layered it on one single graph.

1322.07 -> The single graph is what allows us

1323.78 -> to identify exposures side by side

1326.48 -> with lateral movement path, with vulnerabilities,

1328.64 -> with secrets exposed, with alerts from threat alerts.

1333.77 -> And anything else that we add

1335.18 -> to the graph just builds on top of it

1337.61 -> and allows us to basically uncover

1339.59 -> what we call toxic combinations of risks.

1343.4 -> So now we can look at the entire spectrum

1346.49 -> of the signals that we collect from the different scanners

1349.22 -> and give you one view of the entire risk,

1351.86 -> so one queue for alerts, one queue for risks.

1355.13 -> And we know what is the most critical risk.

1357.44 -> So it's prioritized.

1359.57 -> And basically this is the end result for a customer.

1364.28 -> The customer, in the end,

1366.29 -> what the security team gets is a very clear view

1371.03 -> of the exact slice on the graph

1373.64 -> that creates this attack path, this toxic combination.

1377 -> So you can see the internet exposure,

1379.94 -> the access path to the resource via the network,

1383.3 -> the lateral movement path,

1384.71 -> the vulnerabilities that need a fix,

1386.81 -> and everything is explainable in seconds.

1391.19 -> And you don't even need to be a security expert

1393.29 -> to understand it because it's visual.

1395.63 -> The visualization makes it clear, makes it simple,

1398.75 -> and it reduces the time it takes security teams to explain

1402.59 -> and explain and explain why is this so important,

1406.97 -> why does this really need a fix?

1409.49 -> And this makes it clear because when an engineer gets it

1413.12 -> without any security background,

1415.16 -> they look at it, and they get it.

1416.78 -> They simply get it

1418.13 -> because they know that this is an attack path,

1420.29 -> and, of course, they don't want an attacker

1421.76 -> to get to this point, but it's possible, and it's factual.

1425.3 -> There is no percentages of probability.

1428.93 -> It's 100% correct.

1431.33 -> So this is what the alert looks like.

1433.46 -> It brings it in, all of the context together.

1436.43 -> It allows to take action from the portal.

1438.89 -> So basically we have shortened the time it takes

1441.83 -> to take an action, so an engineer can just go in

1445.34 -> and fix the stuff in their own environments.

1449.6 -> This is important because, in the end,

1451.94 -> our goal as security teams is not to fix all

1454.46 -> of the issues ourselves.

1455.84 -> We need to make it accessible

1457.49 -> to every single engineering team,

1459.83 -> every single business unit that builds to the cloud

1462.71 -> because this is what allows us to scale and be effective

1466.07 -> and democratize security back to the engineering teams

1468.77 -> that, in the end, they need to apply the fix.

1471.11 -> The graph and the visualization

1473.03 -> and the accuracy and the context,

1475.1 -> all of these are the things we used based on Neptune

1478.19 -> in order to enable organizations to move from a very,

1484.16 -> let's say, a labor-intensive security program

1487.67 -> to a democratized security program that can scale

1490.82 -> to any size of an organization.

1493.82 -> Now, all of this wouldn't have been possible

1496.46 -> without the amazing partnership with the Neptune team,

1500.18 -> and I want to talk a little bit about the technical aspects

1504.11 -> behind what it takes to build what is today probably one

1508.1 -> of the largest cloud graph-as-a-service implementation

1514.01 -> in the world, I think, which is the Wiz graph.

1517.1 -> Basically the partnership with Neptune allowed us

1520.52 -> to maintain the scale,

1522.86 -> even on the largest cloud environments that we protect.

1525.71 -> And we are connected today

1526.76 -> to some of the largest cloud deployments in the world,

1529.88 -> and the graph can scale up to it.

1531.89 -> How did we achieve it, right?

1533.69 -> So first, we need to basically use

1537.74 -> what we call the ingestion at scale.

1540.23 -> The graph itself is an accurate representation

1543.35 -> that is continuously updated.

1545.6 -> So when you make a change,

1547.04 -> the graph needs to be updated to represent that change

1549.59 -> in the environment back in the graph.

1552.83 -> This requires ingestion process at scale.

1556.55 -> This requires us to analyze billions of activities

1560.15 -> and fix, update, all of these properties,

1563.39 -> all of these nodes, all of these edges, in near real time

1566.72 -> in order to have an accurate representation

1569.03 -> of the environment.

1570.17 -> And in order to do this,

1571.25 -> we need to make sure we use optimized keywords.

1574.4 -> And when I mean optimized keywords,

1576.08 -> so graph is based on Gremlin.

1578.87 -> It's an open-source language that is used.

1582.26 -> And when we use optimized keywords

1584.78 -> that are implemented natively within Amazon Neptune,

1588.68 -> this is actually what allows us

1590.27 -> the performance use of the graph.

1592.16 -> So over time, making sure

1593.54 -> that the entire ingestion pipeline

1595.46 -> actually uses these optimized keywords was the key

1599.06 -> to create this up-to-date graph.

1602.27 -> The second thing is, how do you do a query on the graph?

1605.42 -> And when you think about it,

1607.28 -> every single graph query can be asked in multiple ways.

1610.67 -> If I have an internet exposure

1612.95 -> on a machine that has a vulnerability,

1615.89 -> I can start asking, show me all of the vulnerabilities

1618.89 -> that are attached to a VM that have an internet exposure.

1622.52 -> I can ask, show me all the VMs that have a vulnerability

1626 -> and also have internet exposure.

1628.16 -> And I can start from all the exposures

1630.23 -> that have a VM behind them that has a vulnerability.

1633.47 -> And you can see how it scales.

1635.36 -> So being able to query in an effective manner,

1638.96 -> in a performance manner,

1640.67 -> this is exactly what we've accomplished

1642.8 -> using the data-flow engine that basically inspects a query

1647 -> and optimizes it before it is actually being processed.

1652.91 -> The third thing is about the openCypher.

1655.25 -> So I mentioned the use of Gremlin,

1657.47 -> but the other query language on a graph is openCypher.

1662.36 -> And it allows us, actually,

1663.62 -> and Neptune add the ability

1664.97 -> to use side by side also openCypher,

1668.123 -> in a way that allows us to load balance, right,

1671.03 -> and to optimize both worlds,

1673.28 -> so best-of-breed approach to the same set of data.

1676.13 -> So we have one set of data, different approaches.

1678.77 -> So if we need complex queries, we have the Gremlin approach.

1681.95 -> If we have simple queries, we have the openCypher approach.

1686.42 -> And compliance,

1687.56 -> Wiz is already deployed in GovCloud.

1689.87 -> We are working with federal customers.

1691.79 -> We're on the process to have FedRAMP.

1693.62 -> Without having all of the underlying services compliant

1696.83 -> to the same level, it wouldn't have been possible.

1699.59 -> So working with the Amazon Neptune team on that process,

1703.06 -> on that journey to make sure they're compliant

1705.68 -> so we can be compliant is, of course, huge.

1708.83 -> All of these weren't there two years ago, right?

1711.83 -> So from our perspective, when we started Wiz,

1714.98 -> we were very cautious about the way we use the graph

1719.63 -> and how we scaled that graph.

1721.43 -> But after two years

1722.72 -> in scaling to the largest cloud environments

1724.85 -> in the world using this graph,

1727.25 -> we feel like graph technologies are now ready

1729.26 -> for their prime time.

1730.22 -> They are ready for scale.

1731.24 -> They are ready for use in multiple,

1733.52 -> like Brad mentioned, multiple use cases

1735.86 -> and scenarios across security industry.

1738.2 -> And this is something that allows us to use context,

1740.72 -> which is one thing that's really missed

1742.49 -> for security, decades.

1746.36 -> And there are more things we can do using the graph.

1750.32 -> So I'll touch on a few,

1751.61 -> and then we can move to a Q&A session.

1755.09 -> We'd love to get your thoughts as well.

1757.19 -> But basically we have the flexibility.

1759.59 -> Because we are using one single graph,

1761.57 -> we have the flexibility to add more and more layers.

1764.69 -> So let's say Wiz releases tomorrow a data security layer

1768.32 -> that will basically tag all of the data that you have

1771.62 -> in the environment, right?

1773.6 -> It's a very small enhancement to the graph.

1776.6 -> And now let's add this very important label

1779.93 -> that says this bucket is sensitive,

1782.54 -> but now I can say a whole bunch of other things

1784.7 -> on this same bucket.

1785.9 -> It is exposed.

1787.13 -> It can be accessed from identities

1789.35 -> that you probably didn't want them to be able to access it.

1792.74 -> It is accessed via external resources.

1795.92 -> So now by adding one single layer,

1798.62 -> this is maybe 10% of the work.

1800.72 -> We just need to add extra layer,

1802.22 -> but we have 90% of the context already there.

1806.15 -> So we keep adding more and more layers to the graph.

1809.3 -> And the other thing is that we also implemented something

1812.96 -> that allows using the graph,

1814.73 -> allows us to democratize access to the graph.

1817.7 -> And this is an ABAC approach to the graph entities.

1821.6 -> So think about it this way.

1822.95 -> Every single graph entity is stamped with an attribute,

1830 -> which teams own this specific resource.

1833.39 -> If we are able to take all of the teams that own a resource

1836.18 -> and stamp it into the objects themselves,

1840.14 -> then we can actually extend access to the teams

1843.29 -> and tell them if you log in,

1844.91 -> you will see only the resources that you own on the graph.

1848.96 -> What this allows us to do is basically to take Wiz

1852.44 -> and the huge graph that we describe

1854.75 -> and segment it to every single team.

1858.29 -> Whether you have one team, 10 teams, thousand teams,

1862.64 -> each one will get their slice of the graph,

1864.83 -> and they can use Wiz to the full extent,

1867.14 -> but they will see only what they have access to.

1870.2 -> So that's a very important use on top of the graph for RBAC.

1875.09 -> And the last piece, and I think Brad also covered it,

1878.54 -> is how do we use multiple databases

1882.05 -> or datasets in order to optimize different tasks?

1885.47 -> So there is a very complex architecture

1889.34 -> behind the scene that basically balances

1892.34 -> between the benefits of a SQL database

1896.42 -> in order to inspect the entities and report at scale

1899.75 -> and a graph database in order to actually query

1902.78 -> on the relationships between these objects.

1905.12 -> So combining these different approaches actually allowed us

1908.69 -> to scale as well.

1912.41 -> In the end, and I'll quote Igor, Igor,

1916.46 -> CTO of Bridgewater, largest hedge fund in the world.

1920.15 -> Basically when they look at security as a whole,

1924.83 -> they see the benefit of the graph

1927.08 -> by understanding the environment.

1929.81 -> The graph allows us to really understand

1933.2 -> what is the bigger picture, what is the context,

1936.71 -> and really impact on how we do security in the industry.

1941.66 -> It's not only about cloud.

1943.01 -> It's about changing the way we do security,

1945.227 -> and the graph is an enabling component to it.

1948.23 -> So with that, I want to ask Brad back on the stage,

1952.55 -> and I want to open it up.

1954.02 -> We have about 10 minutes.

1955.13 -> I want to open it up for any questions you may have.

1958.97 -> Feel free.

1960.59 -> Kayla will step in in a moment and will have a microphone.

1967.37 -> Any questions?

1969.23 -> Ah, Kayla.

1973.07 -> - Hello.

1973.903 -> All right, we are gonna bring the microphone around

1975.56 -> if anyone does have questions

1977.57 -> after I ever so gracefully get down this thing

1979.88 -> that has no stairs.

1981.35 -> Okay, here we go.

1983.57 -> Thank you. Thank you very much.

1984.68 -> Thank you.

1985.513 -> All right, here we go, first question.

1988.01 -> - [Attendee] So the democratization of the data,

1990.53 -> is that done through tagging assets,

1993.8 -> and then the tags go into properties,

1995.45 -> or how does that work actually?

1997.34 -> - Great question.

1998.36 -> If there are tags, then we basically read the tags

2001.27 -> from the cloud environment.

2004.12 -> So that's great.

2005.5 -> Another way to do it is at the account level.

2007.81 -> So those who have already separated accounts

2010.69 -> for business teams, business units,

2014.38 -> that's a good approach as well.

2018.19 -> I would say the least optimized approach,

2020.14 -> but also possible, is actually connecting it to a CMDB.

2023.68 -> But that actually, it's like a third party,

2025.87 -> and then you need to read from the third party,

2027.55 -> embed it into the objects and then do the RBAC.

2029.83 -> But all are possible.

2031.36 -> Cloud tags are probably the best, more granular,

2033.97 -> and best way to do it or account level.

2038.17 -> - [Kayla] Anybody else? Questions?

2039.31 -> Just raise your hand. Here we go.

2040.51 -> We have one up here in the second row.

2045.16 -> - [Attendee] Thank you.

2046.15 -> The compliance detection, is it event-based or batch?

2049.21 -> - Okay, great question.

2050.38 -> So we basically combine both event,

2054.04 -> It's a great question,

2054.94 -> so let me dwell on that for a couple of minutes.

2058.3 -> In fact, there are benefits to both, right,

2060.37 -> because I would say in general,

2063.43 -> if we want to keep an up-to-date representation

2065.89 -> of the entire risk in the cloud,

2067.6 -> it's better to do like a batch approach.

2069.31 -> So we have a periodic scan

2071.35 -> that basically scans the entire cloud environment

2074.32 -> every single day, okay,

2075.76 -> so across the workloads for vulnerabilities,

2079.03 -> across the configuration.

2080.53 -> But then side by side with this,

2082.09 -> there are many configurations that we want to know about

2084.49 -> in near real time, right, as soon as they happen.

2087.16 -> And this is why we incorporated also

2089.32 -> an event-based approach.

2091.24 -> You can think about them as two streams of data,

2094.24 -> but they both update the same compliance alerts,

2097.54 -> graphs, and so on.

2098.8 -> So the graph actually is the most up-to-date based

2102.31 -> on the periodic scan and the event-based ones in parallel.

2105.97 -> And that's how we optimize both worlds, right?

2109 -> So you can take a near real-time action.

2110.83 -> Let's say someone created a publicly exposed API gateway,

2115.99 -> and you want to shut it down.

2117.19 -> So you can create that automation that would trigger

2119.23 -> within seconds, minutes,

2120.46 -> depending on how much time the event, when it was created.

2124.39 -> But on the flip side, when an API gateway is created,

2127.66 -> maybe you want to create another very complex query.

2130.42 -> For instance, show me all

2131.5 -> of the exposed resources behind it,

2133.36 -> and shut it down only if it has like a sensitive resource.

2136.93 -> Okay, so you can combine both worlds.

2140.95 -> - [Kayla] Great, any other questions?

2141.923 -> Just raise your hand. Anyone?

2143.92 -> Got one over here.

2149.02 -> - [Attendee] My question is about what's next.

2151.06 -> So you say it's mainstream,

2152.35 -> but both for Brad and yourself,

2156.52 -> how the future looks like using graphs for security.

2160.75 -> - Yeah.

2161.583 -> - Go ahead.

2162.43 -> - So I think when I'm seeing customers using the graph,

2167.11 -> it really inspires me

2168.46 -> in terms of what more can be done on the graph.

2171.82 -> Customers are using graphs in,

2173.8 -> Once we make it accessible to customers,

2177.67 -> it's unbelievable the creativity that it actually sparks

2181.12 -> in order to ask very complex questions

2183.22 -> about very complex environments

2184.93 -> in a way that creates very effective results.

2187.57 -> And I think that over time, what we will realize,

2190 -> that we need to add,

2191.05 -> same way we are doing with the identity

2194.77 -> and network and data,

2196.36 -> we will need to add more and more components

2198.34 -> to that graph, right?

2199.51 -> So we need to add more layers,

2201.28 -> and over time, this will be what I think

2204.25 -> the most accurate representation of an entire cloud estate

2208.96 -> in a way that allows you to interrogate

2211.03 -> and react, not only necessarily for security purposes,

2214.33 -> but there are many other purposes

2215.98 -> once you have a very accurate representation

2218.5 -> of your cloud environment.

2220.06 -> And you can, again,

2221.74 -> I'm saying customers are the ones that inspire me

2224.86 -> when I see the use of it, but it's really,

2228.1 -> I'm very excited about what's next

2230.32 -> in terms of adding more and more layers

2232.18 -> and using it for more purposes and business cases.

2237.22 -> - [Kayla] Okay, great.

2238.053 -> I think I have another question over here.

2243.73 -> - [Attendee] I'm just curious what level of access Wiz needs

2246.28 -> to the accounts that I wanna be have managed

2248.77 -> and whether it becomes a vector of attack.

2252.13 -> - Great question.

2252.963 -> So in terms of setting up Wiz,

2254.95 -> Wiz has read-only permissions

2257.14 -> and permissions to analyze workloads, a snapshot.

2260.56 -> It has no write execution,

2262.75 -> any form of elevated permissions, I would say.

2266.17 -> And the other thing that Wiz has,

2267.85 -> we have actually two deployment modes.

2270.76 -> One deployment mode is, we call it full SaaS,

2273.16 -> this set of permissions that we discussed.

2275.71 -> The other one that actually is used

2277.54 -> across the regulated industries, we call it the Outpost.

2281.83 -> It's not AWS Outpost.

2283.12 -> It's Wiz Outpost,

2284.05 -> but essentially deploys the entire assessment

2286.96 -> within the customer's cloud.

2288.55 -> And that guarantees a full separation

2290.95 -> of duties between the metadata scan

2293.2 -> and the actual data scan.

2295.03 -> So the permissions that are granted

2296.68 -> are like the lowest level.

2299.08 -> It's a read-only permission only to configuration.

2301.93 -> So actually, it's super easy to deploy,

2304.27 -> even on some of the most regulated environments

2307.21 -> in the world.

2309.04 -> - [Kayla] All right, anybody else?

2310.18 -> Raise your hand if you have any more questions.

2313.12 -> Going once, going twice.

2314.5 -> We have one up front here.

2318.85 -> - [Attendee] Just a quick question.

2320.08 -> Great presentation, by the way.

2321.79 -> We're currently using Wiz,

2323.23 -> and we're not integrating with the CI/CD pipeline.

2326.2 -> Can you kind of like walk through that

2327.64 -> as far as like the instillation process

2329.38 -> and that would work out.

2331.15 -> - For sure.

2331.983 -> So all of the scanners that we have implemented

2334.45 -> on the runtime environments,

2336.04 -> the vulnerability scanner, the configuration scanner,

2338.41 -> actually we have their digital twin in the pipeline itself.

2343.39 -> It's actually a very simple-to-use CLI.

2346.09 -> The CLI can be integrated into any pipeline

2349.63 -> to scan VM images, container images,

2352.57 -> and infrastructure as code, as it goes.

2355.45 -> Now, the benefits of using the CLI,

2358.51 -> and this is a very important, I think,

2363.37 -> journey into a secure CLI,

2366.64 -> the problem that I've seen customers struggling with

2369.19 -> is how do you roll out a CLI scan in a way that is effective

2373.12 -> and doesn't create friction with the engineering team?

2375.64 -> So when you use a single policy, like with Wiz,

2378.43 -> it actually gives you the predictability

2380.8 -> to every single policy you can run in the pipeline.

2383.8 -> So let's say you want to apply a blocking rule

2386.44 -> on a certain vulnerability.

2388.09 -> Guess what?

2388.96 -> The graph already has answers into what is the infestation

2392.47 -> of that specific vulnerability across the environment.

2395.08 -> So there are no surprises.

2396.46 -> If you're gonna block a deployment based on that CV,

2399.37 -> you know exactly who's gonna be impacted.

2401.29 -> You can give them a heads-up,

2402.61 -> and same thing goes to configuration.

2404.44 -> Let's say we block this internet-accessible API gateways,

2408.73 -> and you block it.

2409.78 -> You know before you roll out it through the CI/CD,

2412.18 -> you know exactly what is the impact

2414.16 -> of this in your cloud environment,

2415.87 -> who's gonna be impacted,

2416.79 -> so you can give enough time for your teams

2419.74 -> to actually fix it before they get blocked on deployment.

2422.98 -> And that's a very important way

2424.96 -> to use a single policy across runtime and pipeline.

2429.19 -> And the CLI is super easy to do,

2430.84 -> but we actually applied the notion,

2432.82 -> I like calling it learning from the right

2435.97 -> and pushing to the left, okay.

2437.68 -> So first let's see what's happening in the environment.

2440.38 -> Let's not go all in, start blocking stuff,

2443.08 -> because we will only lose points with the engineering team.

2446.14 -> So let's start from the right

2447.49 -> and then slowly push to the left

2449.14 -> when we know the teams are ready for it.

2451.15 -> And that creates a much higher maturity level

2453.1 -> from what I see with customers in rolling it out.

2455.41 -> And I think there was a misconception in the industry,

2457.72 -> on, like, CLI should be separated, then the runtime.

2462.34 -> You create a lot of friction if you approach it

2464.92 -> as two separate problems because it's not.

2466.99 -> It's the same rule, just running it in different places.

2470.77 -> Thank you.

2471.603 -> - [Kayla] I think we have time for one more question.

2473.246 -> Okay, here we go.

2476.29 -> - [Attendee] So just continuing on the CI/CD.

2479.89 -> So we use CDKs for deployment.

2481.66 -> Can it pre-scan the CDK and then say you will have an issue

2485.98 -> if you deploy this? - Yeah, yeah.

2487.24 -> You can actually run the CDK.

2488.67 -> It like compiles it, analyzes it,

2490.57 -> and gives you the results, yeah.

2492.31 -> Yeah, I think there was one last question.

2493.81 -> - [Attendee] One more, sure.

2494.643 -> We can do one more.

2499.69 -> - [Attendee] Thank you.

2500.86 -> You talked about CI/CD and the CLI

2502.807 -> and then also used an example of the ability

2505.48 -> to block like a publicly exposed API gateway.

2510.55 -> Can you elaborate on the other sort of remediations

2513.28 -> that Wiz can perform?

2515.86 -> - Yeah, so remediations in the cloud,

2519.19 -> I would say they are very diverse.

2521.92 -> It really depends on what's your approach.

2523.87 -> Some organizations feel like they can auto-remediate,

2527.47 -> and then we have a full integration

2530.088 -> into your cloud environment

2531.7 -> or through another SOR, a ticketing system.

2533.98 -> So you can create these automations

2535.96 -> that will basically orchestrate the response

2539.41 -> to a misconfiguration or a risk in the environment.

2542.05 -> But most organizations from what I see are hesitant,

2545.26 -> so they provide it as a canned action

2547.36 -> that like someone can apply from the portal,

2550.03 -> like run action, isolate the machine,

2552.01 -> shut down the gateway, and so on.

2553.81 -> And then what I'm seeing more

2555.64 -> and more is actually the approach

2557.56 -> that says let's not deal with it in production.

2560.5 -> Let's go back, redeploy.

2562.39 -> Let's fix this stuff.

2563.35 -> I think AWS is a huge proponent of that approach as well

2566.86 -> of not fixing in production

2568.39 -> and actually going to the pipeline, fixing,

2571.3 -> and then redeploying, also for vulnerabilities.

2573.91 -> So to be honest, I'm bigger fan of the latter, right,

2578.62 -> so learning what's going on

2580.51 -> and then pushing it to the pipeline and redeploying

2582.85 -> because making changes to production,

2585.1 -> in most cases, are, one, expensive, unpredictable,

2588.16 -> and hard to trace, trace, like.

2591.04 -> So it's possible, but I'm a big proponent actually

2594.01 -> of the AWS approach as well of go to the pipeline,

2597.55 -> redeploy, fix, redeploy, fix, and so on.

2601.75 -> - [Kayla] All right, I think we're gonna wrap it up.

2603.37 -> Yes, so gentlemen, thank you so much.

2605.47 -> - Thank you all.

2606.303 -> It was great.

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