AWS re:Inforce 2023 - Stories from the cutting edge: Cloud security in 2023 (TDR207-S)

Aug 16, 2023

AWS re:Inforce 2023 - Stories from the cutting edge: Cloud security in 2023 (TDR207-S)

In this session, learn about cloud threats in 2023, including the reasons behind a 600% growth in supply chain attacks, why 55% of organizations report at least one database has been publicly exposed, and the emergence of API attacks. Gain insights from threat research from Wiz customers, Wiz and third-party joint threat research, and other sources so you can help improve your organization’s security. This presentation is brought to you by Wiz, an AWS Partner.

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.48 -> - Okay, good morning everyone.

3.33 -> My name is Alon Schindel.

4.53 -> I'm the Director of Data and Threat Research at Wiz.

7.35 -> And here with me is Jose.

9.03 -> - Hi, I'm Jose Veitia.

10.29 -> I am a Security Operations Manager for Red Ventures.

14.34 -> I lead a team of seven in multiple clouds,

17.46 -> and here to talk to you today about some stories

20.4 -> from the cutting edge.

22.11 -> - So today our plan for today is to cover

25.59 -> some of the top cloud threats,

26.97 -> but also some other interesting topics that are relevant

29.76 -> for threat and cloud security teams today,

34.62 -> like for modern security teams.

36.99 -> And the way that we're going to present,

39.777 -> we'll present a topic,

40.61 -> I'll start with a short overview

44.669 -> of the top risks over there

46.29 -> and what we see as we as a cloud security company,

48.9 -> what we see across the different customer environments.

51.63 -> And then I'll use the amazing insights that Jose has

54.63 -> as someone who like actually is

56.85 -> in the frontline and has to deal

58.74 -> with all these type of threats.

61.32 -> And we are going to do, I want to prepare,

63.12 -> so we are also going to talk about some other topics like

66.18 -> how to build a cloud security team.

69 -> I feel like it's connected.

70.29 -> We don't want to talk only about the threats and product.

73.83 -> We also want to cover what is the right way,

76.47 -> how to set the right processes and share some

79.17 -> of the great experience that Jose has.

82.98 -> Okay, so let's start.

86.37 -> So just to give you a kind of an intro about Wiz.

90.06 -> So what we are trying to do

92.76 -> is to help our customers detect risks

96.18 -> and threats in the environment.

98.01 -> Now the research that we are doing is part of Wiz

102.6 -> is kind of interdisciplinary research.

105.15 -> We do both vulnerability research and research of attackers

109.08 -> of what like the attackers are doing,

111.33 -> which vulnerabilities are they exploiting and so on.

114.27 -> And today, the result of this research

117.84 -> are turned into over thousands of like detections

123 -> and controls that we have inside our product.

126.475 -> And another very interesting aspect is

129.33 -> the emerging threats detection that we have

132.51 -> and we're trying to detect these threats

135.87 -> in less than 24 hours.

137.46 -> And for example, you know, Log4Shell,

140.771 -> it was something I'm sure that all of you heard about it

143.547 -> and most of you experienced it.

145.729 -> So for us, Log4Shell,

147.51 -> we had a detection for it within eight hours

151.02 -> from the time that the vulnerability was published.

153.78 -> And it means that we have to first

156.12 -> make sure that we actually detect the vulnerability,

159.06 -> we actually know how we can find it across customer

161.97 -> environments and also understand the impact

164.49 -> of this vulnerability and how we can help customers

167.97 -> know which resources they should patch first.

171.24 -> Another example was the OpenSSL vulnerability.

173.67 -> So it was actually published with,

175.2 -> I mean there was an announcement

176.88 -> that an OpenSSL vulnerability is coming.

179.13 -> Everyone was stressed because of Heartbleed.

183.66 -> Everyone thought, okay,

184.53 -> they're going to be the next Heartbleed.

186.96 -> We were prepared,

188.22 -> we added the detection within a few hours

190.44 -> even without the CVE because the CVE wasn't signed yet.

194.31 -> But eventually the vulnerability wasn't that bad.

196.83 -> We also, I mean as soon as the details were published,

198.69 -> we analyze it and realize that we can recommend our

201.27 -> customers and let them know that

204.96 -> this is not a very critical vulnerability.

207.51 -> And I think that this is part of what we're trying to do

209.88 -> to provide the context and context can be not,

213.96 -> it doesn't necessarily mean okay, patch it now,

216.06 -> everything is critical, sometimes even saying, okay,

218.07 -> this issue is not that severe,

220.89 -> you can go back to work, I mean you should patch it.

224.4 -> It's important,

225.233 -> but it's not the most prioritized thing to do right now.

231.9 -> And just to give you kind of a short overview

236.88 -> of the research process that we do

239.7 -> with these type of threats is tracking threat intelligence

242.52 -> can be through open sources,

244.5 -> sources through our own research

246.36 -> across all the amazing customers

248.79 -> that we have doing the analysis by the research team,

253.41 -> adding the coverage to the product.

255.09 -> And then I think the most important part

257.28 -> is the actionable part.

258.45 -> So it can be some advisory that we publish

262.89 -> inside our product, but also an external blog.

266.49 -> And we are trying to give the context such as like

268.65 -> in the OpenSSL case,

270.06 -> trying to help the general public understand

273.18 -> whether this issue is indeed critical

275.67 -> and how prevalent is this issue.

277.05 -> And we're really trying to leverage

278.46 -> the visibility that we have across

280.92 -> different customers and understand whether

283.98 -> a new vulnerability is something that is going

285.6 -> to be the next Log4Shell.

287.228 -> I mean, is it something that is now exploited

288.83 -> in the wild by attackers is going to be really impactful

293.67 -> and or maybe even like a new disaster

297.6 -> or if it's a vulnerability that you should patch,

303.3 -> but you should prioritize other issues as well before.

307.29 -> And with prioritization,

308.67 -> it's always important to remember that you have also

311.25 -> the internal prioritization within your organization.

315.78 -> So if you have a vulnerability on a resource

318.66 -> with high permissions that is exposed to the internet,

321.33 -> it's not the same situation like a vulnerability

323.4 -> on a resource in a test environment,

326.31 -> internal VM without any special keys,

330.03 -> secrets, or permissions.

331.95 -> So we are trying to help customers understand that.

335.07 -> And especially I think

336.33 -> it's most important when you have large environments

338.76 -> and you have a small team and you need to be really

343.05 -> effective and really understand how to prioritize

345.24 -> what should you do first.

346.32 -> Sometimes it can be the difference

347.85 -> between being breached or not.

354.96 -> So that was the kind of short intro

357.15 -> to some of the things that we are doing in the team.

361.92 -> And we want to start today with a new thread,

364.41 -> the API security.

366.36 -> And I think that we've seen in the past year across,

369.45 -> if you read in the news and some of the things that we've

374.16 -> seen across different environments is the threat of APIs,

379.89 -> attackers trying to leverage exposed APIs

383.79 -> and we'll explain why is it such a critical issue.

387.54 -> And I want to start with an example.

389.22 -> So this is something that happened a few months ago,

391.86 -> the Optus breach and in their case they had this API

396.66 -> endpoint that was exposed and

400.02 -> all the attack had to do is to kind of

403.47 -> manipulate this URL and then they could have access

407.1 -> to have unauthenticated access to customer data.

410.76 -> And the result was that over 11 million consumer records

414.6 -> were acquired by the attackers and was resulting

419.73 -> in a $1 million extortion threat to this company.

424.65 -> And what you see here,

425.73 -> it's really the attacker was as simple as that.

427.38 -> You see this URL, all you need to do is

430.864 -> to manipulate it and then you can get a customer data.

437.97 -> Okay, now why is it such a hard issue

440.97 -> and specifically harder in the cloud?

443.01 -> So first of all, you have API,

446.67 -> I mean using APIs is really, really common.

449.34 -> And also, I mean, I think the number one problem,

452.58 -> and we're going to talk about it further soon,

454.5 -> is the visibility.

455.73 -> Even understanding where do you have these API endpoints?

458.49 -> And I want to just,

459.87 -> I'm curious maybe to see here in the crowd,

461.46 -> so who knows how many API endpoints

464.007 -> they have in the organization?

468.57 -> Okay, good. I'm happy.

473.46 -> So first of all, really understanding all the APIs,

476.79 -> but also on top of that,

477.99 -> when you have an API endpoint trying to understand

480.57 -> what's behind it and there are so many different layers.

483.15 -> So you have the network layer, you have the identity layer,

485.55 -> and you have sometimes even the actual database

489.03 -> that is behind it or the storage bucket.

492.66 -> There could be many different, or maybe serverless,

496.17 -> there could be so many different services behind it

498.93 -> and you need visibility into all these different layers.

501.9 -> So that's the challenge, even understanding,

504.42 -> even if you know all your

505.74 -> API endpoints and you map them trying to understand

509.4 -> what's behind them and if there was a configuration change,

511.98 -> what data is it going to expose?

517.2 -> Yeah, great.

521.1 -> Okay, so we have kind of a checklist for

526.042 -> how to try and mitigate this API security risk.

528.3 -> But I think I want to start with a question to Jose.

531.26 -> So how do you start even handling the API security issue

535.477 -> in your organization?

537.33 -> - 100%, so like with APIs,

540.42 -> the first thing is getting an inventory,

542.28 -> understanding what you have out there,

544.44 -> especially if you have a small team, right,

546.09 -> like myself, one thing you want to prioritize is, okay,

549.66 -> those APIs are exposed, but then take it a step further,

552.45 -> how many of those APIs have authenticated access?

555.99 -> And start working on that with each team, build that trust,

559.41 -> understand what they're doing and then working

561.99 -> your way through the environment with a good inventory.

564.54 -> Once you have those APIs that are unauthenticated,

566.46 -> understanding what they're connected to,

568.47 -> if those databases have any kind of information

571.05 -> that you don't want to be publicly accessible.

574.26 -> And then also taking them down

576.36 -> if they're not needed to be exposed to the world.

579.39 -> So it's really understanding what you have,

582.54 -> validating what you have,

583.77 -> and then working with each team to understand

587.22 -> how you can make them better, right?

589.11 -> And creating that partnership.

590.76 -> I think that's really important.

593.34 -> - I mean maybe I think one of the recurring themes

595.722 -> that we're going to have today is

597.3 -> how do you build this partnership

598.68 -> between the security teams and the engineering teams?

601.11 -> And this is something that is as critical

603.9 -> in cloud environments because most of the teams

606.63 -> who actually fix the issues are the engineering teams,

608.861 -> not the security teams, so how do you do it?

610.77 -> How do you recommend organizations doing it?

612.86 -> - So in our case,

614.31 -> we took an approach of using a security champs program.

618.24 -> You've heard this before in different talks.

620.73 -> We took this on and basically distributed one key resource

625.29 -> on every business unit in our organization.

627.72 -> And that resource is dedicated to the security

630.36 -> of that business unit.

632.07 -> And they are our main contact point

634.41 -> whenever we have questions or whenever we want to empower

637.14 -> or release new tools,

638.31 -> we involve them in the process and get them early on

640.86 -> in anything that we're looking at from a detection

645.24 -> or response or even from an infrastructure perspective.

648.75 -> And I think that has helped us greatly in understanding

652.8 -> feedback from every business unit unit we have in our org

655.77 -> to get perspective from their end, right?

658.74 -> Like hey, these are some blockers we're running into,

661.08 -> or hey, these are some things we would like to see.

663.66 -> And really helped us foster that two-way communication

666.48 -> between our overall organization

668.7 -> and getting better every day.

671.73 -> - And how do you become such a champion?

673.83 -> So you took engineers and some of them,

675.87 -> they probably don't have any security background,

677.61 -> so how do you turn them into someone

678.99 -> who can be effective in in their job?

681.57 -> - That is a great question.

682.92 -> So it starts with just general interest.

685.35 -> There's always a couple of folks in any organization

687.84 -> that are curious or that ask some very interesting questions

690.51 -> regarding security.

691.71 -> We typically go for those folks and engage them first,

695.07 -> and then if we don't get that kind of engagement,

697.05 -> then we go to the different leadership teams

699.75 -> on each business unit and we ask them straight up, hey,

702.75 -> do you have anyone that would be interested in doing this?

704.7 -> And they're like actually yes, we have this one person.

707.22 -> He's always finding these issues

708.75 -> or they are always finding these issues

710.76 -> and I feel those are the best people to

712.44 -> champion and carry that message forward,

715.23 -> the folks that are actually interested, motivated,

717.87 -> and curious.

718.703 -> So it's been a good experience.

721.14 -> - And how long have you been doing this program?

723.72 -> - About a year now.

725.04 -> - And can you tell like the difference from the time before

727.5 -> you started using like this champions,

730.74 -> how things look and now.

732.36 -> - Really good.

733.41 -> It's really fostered this two-way communication path.

737.19 -> We meet with them monthly and we talk

739.8 -> through different issues and things that

741.6 -> need to be addressed or things that need to be escalated

745.11 -> or just general feedback about tooling that we have.

748.14 -> And it's been really great in fostering

750.66 -> this really good relationship between security

754.23 -> and the developers and also the business units

756.33 -> because then those champions go

758.525 -> to their team meetings and they talk about this stuff and

760.41 -> then we hear about it from their leadership team and going,

762.81 -> I heard you're doing this, and you're like, yeah,

764.37 -> how did you hear about that?

765.203 -> Oh, so and so told me.

766.35 -> I'm like, that's awesome.

767.22 -> So it's really fostering this culture of sharing,

771.81 -> getting excited about security, which most people aren't,

774.57 -> but we're getting there little by little

776.49 -> and it's really good.

779.79 -> - Right, now let's get back to your team,

781.89 -> to what you do at your team.

782.723 -> So you raised your hand when I asked

785.85 -> how many API endpoints you have an organization.

788.04 -> So how do you do it? How do you find all of them?

792.3 -> - Well, we have a great tool that we use

794.64 -> for our API endpoints to find them across all of our clouds.

798.69 -> And then we start prioritizing and understanding

801.33 -> what each one of does and making sure they

803.04 -> have the proper tags and classifications needed

805.56 -> to make sure that if we ever have

807.57 -> an issue or anything like that,

808.77 -> we know exactly what we're dealing with.

810.51 -> So it's been really beneficial to understand

812.46 -> what our inventory is and what we have as a whole perimeter.

816.81 -> It's been really, really good.

818.37 -> - And like beyond the perimeter,

819.78 -> how do you understand what's actually behind,

822.69 -> how do you validate

825.464 -> the data is not exposed or what's actually connected

828.81 -> to this API endpoint?

830.01 -> - So we leverage our champs along

832.17 -> with some of my staff and we, at scale,

835.17 -> have ways to look at

837.96 -> how they're responding, how the APIs are responding,

839.97 -> and then from a connectivity perspective,

841.471 -> we leverage a different tooling to let us know how things

845.13 -> are connected and then we roll it back

847.08 -> and it gives us that visibility.

848.94 -> And because we classify them as we go,

851.13 -> anything that's not classified,

852.63 -> we throw them into the bucket and we start all over again

855.439 -> and we ask really good questions.

858.42 -> - Amazing. Thank you.

859.26 -> That was really insightful.

860.1 -> Is there anything else you want

861.12 -> before we move on to the next topic?

863.22 -> No. Okay, thank you.

864.72 -> Yeah, so I think just to summarize,

866.4 -> so I think the most important steps are really

869.91 -> understanding the inventory,

870.99 -> understanding what API endpoints do we have,

874.5 -> and then understanding what's behind it,

876.42 -> really connecting the different dots

877.89 -> and understanding what's there.

880.29 -> But it's always important to remember that security

883.08 -> is also about the people and setting the right processes

886.47 -> and finding the way to collaborate

889.32 -> with the engineering teams because most of the time

892.05 -> they're the ones who actually know

893.76 -> why the system is built this way,

895.5 -> why things are configured this way.

897 -> So it's always about,

897.953 -> I think this is why we wanted to start with this topic.

901.02 -> I mean you need to understand that security

903.15 -> and especially in the cloud

904.92 -> is a collaboration between engineering teams

907.05 -> and the security team.

907.95 -> So finding the way to collaborate together

912.72 -> is the first step to secure your organization.

918.36 -> Now the next threat that we'll cover is data exposure.

922.44 -> So we had an interesting experiment a few weeks ago,

928.35 -> and we tried to see

930.69 -> how fast an exposed bucket will be accessed

934.68 -> by someone on the internet.

936.987 -> And we found when we had a S3 bucket with a common name,

941.37 -> it was accessed by attackers it within seven hours.

945.87 -> And that's, I mean,

947.76 -> it means that if you do very simple mistake,

950.34 -> you'll pay for that.

951.21 -> And when we tried to do something similar,

955.14 -> we put the bucket name on on GitHub,

958.98 -> it was accessed within 13 hours.

962.61 -> You see that if you do with buckets, with S3 buckets,

967.47 -> it's really easy to expose them.

970.38 -> Now I have to say that AWS added a lot of different

973.71 -> kind of warnings when you do it and

975.57 -> you have to work harder in order to do it,

978.69 -> but it's still, I mean,

980.37 -> it's still an issue and still something that

981.93 -> if you walk with, you know,

983.46 -> maybe set your environment with Terraform

987.69 -> or with other tools,

991.211 -> you can still do these mistakes and accidentally expose

993.84 -> your data and when your data is accidentally exposed,

996.923 -> it's very likely that it will be accessed by attackers.

1002.84 -> And overall we see,

1004.43 -> I think that not only if we speak not only on S3 buckets,

1007.76 -> but on data basis in general,

1011.18 -> we see across cloud environments

1014.945 -> that 55% of them have at least one publicly exposed database

1020.36 -> or data storage bucket exposed to the internet.

1025.97 -> And we keep seeing all these different

1029.3 -> exposures of companies, and in this, I mean,

1032.72 -> I think that maybe the problem is that it's not only about

1036.08 -> the security of your customers,

1037.25 -> there are some legal consequences to data exposure.

1043.04 -> And when we want to talk about

1049.4 -> why is it such an important problem,

1051.26 -> I think there are some similarities

1052.61 -> to what we discussed before

1054.537 -> with APIs because you have all of these different layers

1056.6 -> and you have the network layer, you have the identity layer,

1059.66 -> and you have the question of what data is actually there,

1063.62 -> what's stored in this database?

1066.41 -> And we have to remember,

1067.52 -> so in the cloud there are so many ways to store data.

1070.13 -> You have the past services and it can be services

1073.76 -> like RDS for example.

1076.04 -> You have storage, but you can also have hosted databases.

1081.158 -> You can just spin up your VM with a Postgres database on it

1086.12 -> or with any other database on it.

1088.67 -> And as a security team,

1090.71 -> you have to know that your engineers,

1092.21 -> they might use each one of these services

1095.3 -> and you might also have just SaaS services,

1097.52 -> external third parties that store your data.

1099.77 -> So even understanding like where do you have the data

1102.047 -> and what type of data is there is a very

1105.02 -> difficult question in a cloud,

1106.13 -> it can like change on daily basis.

1108.11 -> So that's a complex challenge.

1111.59 -> And then even if you know where your data is stored,

1114.77 -> you have to understand all the different layers,

1116.42 -> understand the configuration,

1117.253 -> if you have maybe a load balancer

1119.9 -> that might be misconfigured and eventually expose your data

1124.64 -> if you have APIs, API endpoints,

1126.83 -> that that can access this data,

1128.48 -> so many ways to access it.

1130.25 -> And so many different network and identity

1132.59 -> configurations that you have to analyze.

1136.908 -> So the visibility and visibility even to self host

1139.82 -> the database is important.

1142.31 -> And understanding the configuration of the past database

1146.39 -> is something that is also really important

1148.4 -> and also like a very difficult task.

1150.313 -> There are so many databases and I want to give you,

1152.15 -> so like another interesting example,

1154.91 -> today we are seeing the use of new AI services.

1159.74 -> Like, for example, AWS Bedrock,

1162.47 -> it's a new AI service that

1166.52 -> was introduced a few weeks ago.

1169.73 -> And you can think about these services also there,

1172.07 -> like as some like small databases,

1174.47 -> because when you train the models and you sometimes

1178.91 -> store customer data on them.

1181.19 -> And so the engineers and the AI engineers,

1183.62 -> they'll just go and want to

1185 -> start developing new services on top of that.

1187.157 -> And all these AI services are cloud based,

1189.26 -> so it'll be in the cloud environment,

1191.09 -> but security teams have to learn and understand

1192.95 -> all the different configurations and even know

1195.17 -> that someone has started to use it inside the organization.

1197.66 -> So data can be everywhere and you the data,

1201.19 -> it can change, it's always, always changing.

1207.08 -> Okay, so Jose, for you, let's get back to you.

1210.7 -> So how do you even start

1212.18 -> understanding where the data is inside the organization?

1215.03 -> - It starts with a good inventory, back to that again,

1217.64 -> however in this case, when it comes to data,

1221 -> it's what you were saying, right?

1222.14 -> It's not just about the services being leveraged,

1224.06 -> it's also about what we're self hosting,

1225.89 -> what's been forgotten about,

1227.27 -> what no longer has ownership

1228.92 -> and making sure you have a process to identify

1232.07 -> and get those things owned and managed

1234.77 -> and mitigated if it needs to be mitigated or just,

1240.17 -> handled from a security perspective.

1243.4 -> So first things first, gaining that visibility,

1246.14 -> classifying what you have,

1247.73 -> making sure you know where your crown jewels are

1249.586 -> in your environment.

1250.91 -> It ties back to the API conversation, right?

1253.49 -> It's having a good inventory

1255.2 -> and classifying this data is critical.

1257.87 -> And then just understanding and monitoring

1261.14 -> for when those changes arise because

1263.03 -> things are gonna change and you gotta change

1264.8 -> with the business and you gotta understand

1266.9 -> where you have an exposure

1268.1 -> or if you have a misconfiguration that can make something

1272.06 -> happen that you don't want to happen,

1273.38 -> you wanna understand what that is.

1274.85 -> So it goes back to making sure 100%

1277.79 -> you have that visibility and that inventory.

1281.3 -> - And how do you do the data classification?

1284.36 -> Because you might have, I mean you have large organization,

1286.88 -> different teams using the data.

1288.59 -> I mean how do you even understand like where the data,

1292.49 -> what's the data, is it sensitive,

1293.78 -> is it not sensitive, how can you tell?

1296 -> - That's a great question.

1296.833 -> And we get this a lot even in my org.

1298.91 -> We actually document and communicate what each data type is

1303.08 -> and how we want them to classify it.

1304.7 -> And we constantly reiterate,

1307.04 -> here are the data classifications that we use internally

1310.13 -> and this is how we want you to classify the data.

1311.927 -> And if we find something that's not classified correctly,

1314.69 -> we correct it and we train those folks on like, hey,

1318.5 -> you tagged it this way,

1319.55 -> but it's actually something supposed to be different.

1322.22 -> And we go about training and making sure we're empowering

1325.52 -> each team so that they can understand

1327.62 -> what our classification is for our organization.

1331.1 -> So it's just about communication.

1332.75 -> Going back to the initial thing,

1334.04 -> it's really about empowering the folks that are working

1337.25 -> in our org and then making sure they understand the rules,

1340.73 -> the rules to the game.

1341.6 -> We like to gamify everything.

1342.77 -> So we always say we're gonna give you the rules

1345.11 -> to the game and then we're all gonna play together,

1347.78 -> and it works out pretty well.

1350.54 -> - And we saw like in the first slide that

1353.42 -> exposed data can be accessed

1355.13 -> almost immediately by attackers.

1357.14 -> And what is the way for you to handle such data incidents?

1362.12 -> Because it's not like, I mean,

1364.49 -> like a classic sock incident when you might

1367.22 -> have a malware or like a bitcoin miner

1369.29 -> inside your environment,

1370.123 -> this is kind of a different type of incident.

1372.08 -> So what is the process?

1372.92 -> Okay, data is exposed, what happens next?

1376.25 -> - That's a great question.

1377.21 -> So every business unit is different

1379.25 -> and every org is different.

1380.75 -> It's understanding what their risk appetite is

1382.94 -> and what they're willing to accept.

1387.44 -> For us it's mostly about automation and making sure

1391.31 -> that if that were to happen,

1392.54 -> we have a quick way to shut that down.

1394.67 -> So building guardrails is a great way to do that.

1397.43 -> And then also making sure you're communicating those

1399.77 -> guardrails so people understand if there was to be something

1403.915 -> that was gonna expose data,

1405.5 -> they understand that we would have a mitigation in place

1409.49 -> that's gonna protect them,

1410.96 -> and if that causes an outage, so be it,

1413 -> they understand the risk.

1414.53 -> But it's all about communication upfront

1416.15 -> before that even happens.

1417.65 -> So making sure all your stakeholders are aware of whatever

1419.75 -> automations you're putting in place

1420.95 -> to do this type of mitigation.

1424.1 -> - Okay, so before we conclude, so if you have one question

1428.45 -> that you know that everyone in the crowd should

1430.73 -> ask themselves about the data in their organization,

1432.71 -> what would it be?

1434.57 -> - Do you know where your crown jewels are?

1437.54 -> Today, can you say with confidence,

1439.52 -> you know where all of your crown jewels are

1441.08 -> for the most important data in your organization?

1442.94 -> I think that's a great question.

1445.37 -> - I mean like many other cloud issues,

1448.04 -> it's always about trying to even avoid the incident.

1450.92 -> So we talked about how you mitigate the incident,

1452.69 -> but the best thing to do is even to avoid it and

1456.2 -> make sure that you know where your data is and you know

1458.9 -> whether it is protective or not.

1460.55 -> So thank you. Let's move to the next topic.

1464.36 -> So supply chain risks and think supply chain,

1467.51 -> so it became a very popular threat.

1471.29 -> And I think with the SolarWinds attack,

1474.02 -> I think this is the first time when everyone really saw

1477.68 -> the massive impact that such a issue can result.

1483.14 -> And when we talk about supply chain risks in the cloud,

1487.79 -> there is a very interesting angle,

1490.58 -> and you have, like in the cloud,

1493.25 -> there's the short responsibility model

1494.87 -> and I'll try to explain it really shortly.

1498.32 -> It's way more complex than that.

1499.67 -> But you have the infrastructure that is built

1501.89 -> by the cloud providers and they're the ones

1503.81 -> that are responsible for that.

1505.58 -> And there's the code that is running and that

1508.07 -> the cloud customers are using and deploying,

1511.34 -> but there's also a gray zone in the middle.

1514.64 -> And this is software that is actually deployed

1518.21 -> by the cloud provider, but it's running on the VMs

1522.375 -> and resources that are owned by the customers.

1526.34 -> And one example is the OMIGOD vulnerability.

1528.62 -> It's a vulnerability that was found

1530.9 -> with the research team,

1532.73 -> was actually sitting here in the crowd

1535.64 -> and it was in a library that is used by Azure

1540.71 -> and they installed it on

1543.32 -> as part of the use of their services,

1545.57 -> they installed it on the customer VMs.

1548.03 -> And we saw that this library was

1551.427 -> used by 60% of Azure customers and it had a vulnerability.

1556.49 -> And we found this vulnerability, we reported it of course,

1560.51 -> we responsibly disclosed it,

1562.58 -> the vulnerability was patched.

1563.72 -> But the problem was that no one really knew that

1567.92 -> if they use this library or not,

1569.87 -> it was kind of a very secret library.

1571.91 -> No one really knew

1573.17 -> if they use it and this is how this problem,

1576.23 -> I mean this is exactly the problem.

1577.79 -> So you have now a vulnerability,

1580.58 -> it's really easy to exploit it.

1582.47 -> Attackers started exploiting it in the wild

1586.91 -> after the patch because it was so easy to exploit it.

1590.33 -> But most of the cloud customers didn't know that it's there.

1592.82 -> And this is exactly the supply chain.

1594.23 -> So code that is written by someone else is vulnerable

1597.23 -> or is tempered and then

1600.44 -> attackers can leverage it and you don't even know

1602.18 -> that it's in your environment.

1603.41 -> So that's kind of one interesting angle

1609.77 -> about the supply chain risk.

1611.39 -> And we have another interesting angle

1613.13 -> that we'll present soon,

1615.525 -> but just kind of showing

1617.21 -> why is it not only about packages,

1620.9 -> so you have any third party code,

1623.45 -> any third party resource that you're using

1626.499 -> might be infected.

1629.66 -> And we saw recently some cases where attackers deliberately

1632.99 -> tried to hack specific companies and change the code

1635.84 -> of their services like in the SolarWinds case.

1638.24 -> And so they can then add their implants over there or

1644.48 -> change the code to create vulnerabilities.

1646.889 -> And after they do that,

1650.12 -> the code is deployed to the customers

1652.79 -> and to the customer environment

1654.14 -> and they start exploiting it or maybe use the malicious code

1657.68 -> to search for AWS secrets and then

1664.52 -> use the secrets for initial access or to access data

1667.91 -> in the customer environment.

1669.95 -> Now okay, so we don't want to scare,

1672.62 -> I mean of course this is something that is really, you know,

1675.136 -> it's a problem, but there are also some solutions.

1678.2 -> So it's not only a bad thing.

1683.84 -> And I want to cover,

1685.4 -> so we talked mostly about the software,

1687.5 -> what we call software based supply chain risk,

1689.81 -> but in the cloud there's another supply chain risk,

1692.66 -> and this is what we call identity supply chain risk.

1695.48 -> And I'll explain shortly

1698.09 -> and we'll have another slide for that in a minute.

1701.21 -> So in the cloud,

1702.86 -> you and everyone who uses the cloud also allows

1707.03 -> third party services to access their cloud environments.

1710.15 -> And you let them have permissions,

1713.9 -> sometimes even sensitive permission

1715.52 -> to access your data, maybe create VMs,

1718.67 -> maybe even hire admin permission

1722.27 -> to some resources and you give it to a third party.

1726.71 -> But what happens if this third party is hacked?

1729.56 -> So we will explain it shortly.

1733.13 -> So that's the OMI case that I covered it,

1736.01 -> but for the identity one,

1737.42 -> so you give this third party access

1741.38 -> and we see how common it is.

1742.79 -> So 82% of companies provide third party vendors

1746.33 -> highly privileged roles.

1747.8 -> And you have to understand that if you do it,

1751.85 -> I mean this is something that it's okay to do.

1753.59 -> I mean it's part of cloud environment,

1755.39 -> but you should ask yourself whether

1757.13 -> they really need all the permissions.

1759.2 -> That's the first question.

1760.43 -> And even after the first time when you added

1764.398 -> this role to your environment,

1765.231 -> you should ask yourself whether these permissions

1768.11 -> are really being used and maybe they have just

1771.5 -> excessive permissions that are not really being used,

1773.84 -> but no one monitors it, so I mean it's just there.

1776.45 -> And then in case this third party is breached,

1781.13 -> they will be able to access your environment

1783.65 -> and we see that attackers and we saw some use case of APT,

1788.241 -> like here, the Nobelium group,

1789.92 -> this is an APT group that is associated

1793.76 -> with Russian nation state actors.

1798.29 -> So they are trying to find these companies

1800.543 -> that have access to like MSSPs that have access

1805.73 -> to many environments in order

1808.58 -> to get access to their customers.

1813.41 -> So Jose,

1816.44 -> so let's start with the identity supply chain,

1818.24 -> how the process of adding a new role,

1819.98 -> a third party role to an environment looks like.

1822.02 -> - So first and foremost, before we even get there,

1824.75 -> we want to build a relationship with the vendor

1827.27 -> with whoever we're dealing with,

1828.38 -> we're obviously reaching out to these vendors

1830.39 -> because they have a service we want.

1831.89 -> So first thing first is understanding

1835.084 -> what the escalation path is for any vendor.

1837.26 -> What is their email, what are their SLAs?

1840.41 -> And then from there,

1841.31 -> when they ask for access to anything,

1842.84 -> we question and push back.

1844.28 -> How many of you folks actually push back

1846.05 -> when vendors ask you for excessive access?

1848.48 -> I think everyone should be doing this.

1849.92 -> I think it's a great way to help the security community

1852.83 -> as a whole because a lot of times,

1854.63 -> these vendors just need input.

1855.86 -> They think they need more access than what they do.

1857.87 -> And pushing back is a great first step,

1860.54 -> but also understanding the escalation path

1862.43 -> so that if there was an issue,

1864.26 -> especially from an identity perspective,

1865.97 -> you have a good escalation path to ask

1867.65 -> those good pointed questions, like hey, are we affected?

1871.31 -> Hey, do we have a problem?

1872.45 -> Do you have a problem?

1874.22 -> These are all things you wanna build.

1875.45 -> It's a two-way street with any vendor,

1877.31 -> so you wanna make sure you foster that relationship

1879.38 -> with them as well.

1880.4 -> And then you also wanna make sure that you are definitely

1883.82 -> asking do they need those permissions?

1886.25 -> And in some cases just take it away and see what happens.

1889.31 -> If nothing breaks,

1890.75 -> just go for it and then give them that feedback like,

1892.73 -> hey, I've been running this for three weeks

1894.26 -> and nothing's happened.

1896.18 -> I think that's a much better approach in giving

1897.95 -> some of these vendors so much access.

1900.74 -> - Yeah, no, I completely agree.

1903.966 -> And also for my own is the security research team,

1906.41 -> we sometimes help our product security team and

1910.04 -> there was a third party service that we wanted to use

1912.68 -> and we talked with this vendor,

1914.57 -> we reviewed the different permissions and we really saw

1917.03 -> there was some permissions that

1918.41 -> we didn't understand why they're there.

1920.66 -> I mean it didn't make any sense.

1922.67 -> We pushed back and we told them that we don't want to,

1926.21 -> like we're not going to approve this role

1929.18 -> and they actually remove them.

1930.68 -> So it's also a good thing to do for the community

1933.38 -> because this kind of a way to

1935.39 -> help everyone and make sure to reduce the risk for everyone.

1941.75 -> Now let's get back to the software supply chain.

1945.05 -> So I think another interesting impact,

1948.17 -> so other than just libraries is like using images.

1951.44 -> So we use like in many cases, container images,

1955.64 -> they're coming from external sources

1958.04 -> and how do you even check,

1959.54 -> how do you validate that they're okay?

1961.85 -> - Yeah, so with the container pipe,

1963.68 -> we obviously created a container pipeline where we validate

1966.86 -> every package and try to stay up to date

1968.87 -> on all the vulnerabilities in those different packages

1971.57 -> and just assess the same as with roles, really,

1975.02 -> do you need all of these packages that are in these

1977.18 -> containers and are they effective

1979.16 -> for what you're trying to do?

1980.57 -> And just constantly reevaluating that and making sure

1984.17 -> you're exhausting all your options

1986.51 -> when looking at how you're

1987.68 -> trying to achieve that goal with that container

1990.44 -> or with those images, right?

1992.15 -> But it starts with patching,

1993.77 -> making sure you're staying up to date on all of the

1995.9 -> vulnerability patching that's available for whatever

1997.97 -> you're trying to use.

1999.11 -> And also just continuously asking yourself, do I need this?

2003.46 -> I think that's a great, great step.

2005.65 -> - Now let's get back to the recurring theme for today.

2009.43 -> So who actually owns these processes?

2010.87 -> So is it you, is it the developers?

2013.15 -> An image is used by developers and

2015.07 -> there are different layers inside the image.

2018.22 -> So who is actually like the owner of the image?

2021.28 -> - That's a great question.

2023.2 -> We essentially have a team that owns the process

2026.62 -> of the pipeline and then our developers are able

2029.08 -> to basically engage via pull request

2032.5 -> and engage in fixing or augmenting.

2035.56 -> And then we roll that into those images.

2039.01 -> And then what we do from a security perspective

2040.9 -> is we make sure we're scanning and keeping track

2043.12 -> of those vulnerabilities and then just pushing, hey,

2045.49 -> are you staying up to date on the vulnerabilities?

2047.08 -> Hey, are you addressing these vulnerabilities?

2048.58 -> And trying to get to a place where we're constantly

2051.76 -> mitigating the biggest risk in our organization

2053.71 -> from a vulnerability and supply chain perspective.

2056.68 -> - And what is your biggest challenge with this process?

2059.47 -> What's the biggest challenge with the supply chain?

2064.225 -> - Some packages aren't fixable.

2066.19 -> So then it goes back to, okay, what do we do now?

2069.31 -> It doesn't have a patch.

2070.679 -> So then we start looking at compensating controls and making

2073.21 -> sure we're looking at, hey, does this need to be external?

2076.15 -> Hey, does this even need to be running?

2078.19 -> And going from there.

2079.3 -> But it definitely starts with having those conversations and

2082.18 -> making sure you have folks on your development teams

2084.58 -> that you can talk to about this stuff

2085.81 -> to understand the need because that's major.

2090.46 -> - Okay, thank you.

2091.39 -> So just want to go and show the quick checklist

2094.66 -> for the supply chain risk.

2095.863 -> So I think there's a interesting issue

2098.02 -> that we touched before with OMIGOD

2100.598 -> and like software that is being introduced

2103.69 -> by cloud providers and in many cases,

2105.82 -> these vulnerabilities.

2106.87 -> So with packages they have CVE and then you can know it,

2110.05 -> but with some of the cloud services

2112.33 -> and cloud vulnerabilities,

2113.92 -> these cases they don't have a CVE.

2115.93 -> So there's a community project that we started.

2119.11 -> It's the open cloud vulnerability

2120.64 -> and security issue database.

2122.62 -> It's an open project,

2124.72 -> like the UI cloud vuln db, you can see it on the screen.

2130.12 -> And this is a place where we kind of collect

2132.97 -> all these different issues.

2134.14 -> And the purpose is

2135.82 -> to help different teams and help you make sure that these

2139.18 -> issues are not in your environment

2140.92 -> and that you know how to fix them because there's no place,

2143.23 -> there's no database like the CVE,

2145.57 -> like the NVD database for vulnerabilities.

2148.66 -> And you have to make sure that your environment

2154.3 -> is clean from these issues.

2155.83 -> So I'd recommend going there.

2158.23 -> It's a project started as community project

2161.17 -> and we kind of helped setting it up

2164.59 -> and setting this website and we keep

2167.86 -> updating this website.

2170.17 -> We have here also (indistinct) is one of the collaborators

2173.68 -> who make sure that the vulnerabilities

2175.81 -> are being added to this project.

2179.35 -> And with that,

2180.52 -> is there anything else about supply chain risk

2182.62 -> that you'd like to add before we move on?

2184.6 -> - Just as a community,

2185.98 -> let's just make sure that whenever you have vendors that

2189.55 -> are asking for excessive access,

2191.11 -> just continue to push back.

2192.19 -> I think as a community that's something that we could do as

2194.17 -> a team together to make sure that

2196.3 -> as the broader security community,

2198.13 -> we have proper roles for the stuff needed.

2201.13 -> And that's gonna be huge.

2203.56 -> - Thank you. Okay, so next topic.

2206.47 -> Now we're moving to like the topics that are more about

2209.62 -> how to deal with these issues,

2210.52 -> not only covering the threats,

2211.99 -> but what do you do about them?

2213.61 -> So in cloud environments there are, you know,

2217.21 -> like doing the detection and response processes

2220.51 -> is a whole different story from doing it on endpoints,

2224.345 -> on on-prem environments because first you don't necessarily

2228.31 -> know who owns the resource or why is this issue there,

2233.792 -> what is it doing?

2235.54 -> The environment changes really, really fast.

2237.73 -> I mean you can have

2238.563 -> a day with 100 new VMs in your environment

2241.06 -> and maybe the day later they're all gone.

2243.75 -> You have to keep track on what's happening there.

2246.82 -> And also response processes like there were in the past,

2250.45 -> I mean just, I mean you see a malicious process,

2253.45 -> you can kill it, and if you kill a malicious,

2256.604 -> I mean a process in your production environment,

2258.19 -> you might result in some outage

2262.27 -> or other business consequences.

2264.936 -> So you don't want to do it.

2266.29 -> So doing it in the cloud is challenging.

2268.72 -> And also there is the kind of skill challenge

2272.5 -> that you have now to train a lot of people

2274.6 -> to monitor a new environment.

2276.46 -> So on-prem, it's there for years, cloud is new,

2279.79 -> so you have to make sure that everyone knows

2282.76 -> how this environment look like.

2284.36 -> So let's start with that.

2285.52 -> So with cloud detection response,

2286.93 -> so how the process looks like in your organization,

2290.83 -> how the SOC organization looks like,

2292.99 -> who owns detection response in the cloud?

2295.18 -> - So that's on my team.

2296.41 -> So we are the facilitators for the response capabilities

2300.31 -> and what we do is we empower, again,

2302.62 -> through our security champions program,

2303.88 -> we empower those folks to help us with any context, right?

2307.54 -> And then from there we also make sure we're providing

2311.29 -> documentation along with that and run books.

2314.26 -> And then not only are we providing that documentation,

2316.39 -> we're actually running through those processes,

2318.22 -> through tabletops and through different CTF type events

2322.12 -> to make sure people are familiar at getting

2323.95 -> that muscle memory with how to respond in the cloud

2326.86 -> to any event that happens in the cloud.

2329.11 -> And making sure they understand the totality

2331.54 -> of all the different actions we can take.

2333.19 -> So it's not just about containment

2336.242 -> of a workstation or of a workload,

2338.59 -> but it's also identity, right?

2340.78 -> How do we revoke the keys,

2341.98 -> how do we think about rotating creds,

2344.23 -> things of that nature in the cloud and making sure we're

2346.63 -> practicing those skills across all of our business units.

2349.9 -> I think the practice part is a huge,

2352.33 -> huge win because you also get feedback like,

2354.88 -> hey, this took me a long time to do,

2356.92 -> or hey, this is really impacting,

2358.84 -> this would be really impacting if we were to do it.

2361.18 -> So understanding those things and making sure we're

2363.19 -> communicating again through our security champions

2365.62 -> so that we know what the potential impact is

2367.78 -> across the whole work.

2368.767 -> And I think that's important.

2371.32 -> - Thank you.

2372.327 -> And I think the next topic and the last for today

2375.61 -> is actually about building the cloud security team.

2378.76 -> So it's not only about the processes for,

2381.88 -> what are the processes for detecting these threats,

2385.87 -> it's about how you build it,

2387.34 -> who are the relevant people to bring to such a team?

2391.93 -> Should they have security background,

2393.28 -> engineering background, what do you do?

2395.29 -> How do you find the right people for the team?

2397 -> - So first thing I do is I always ask myself

2398.98 -> what is the problem we're trying to solve, right?

2400.75 -> What are the problems that we're trying to solve on my team?

2403.45 -> And then I figure out, okay,

2405.31 -> from the problems we're trying to solve, is this individual,

2409.57 -> does this individual have the qualities

2413.247 -> needed to solve that problem?

2414.85 -> So if they're a developer

2416.14 -> and I'm looking for someone to automate something,

2418.69 -> I can have them partner with someone that's security-centric

2421.54 -> to give them that handholding on the security side.

2424.03 -> And then flip side of it's more of a security type person

2428.56 -> or task that I need fulfilled.

2430.57 -> Then I ask myself, okay,

2432.73 -> can they partner with a developer to understand

2435.13 -> how to automate or how to develop things

2437.08 -> and really creating these partnerships like that

2439.57 -> to force multiply and grow talent.

2442.42 -> I think that's been huge.

2443.83 -> The other thing is when I interview

2446.41 -> or when I try to bring someone on board,

2448.03 -> I always try to understand the why behind them,

2451.84 -> why are you doing this?

2453.28 -> What's your inspiration?

2454.54 -> Where do you want to go next?

2456.01 -> And really understanding what their passion is so that

2458.71 -> the work can align with their passion.

2460.6 -> Because there is nothing better than a team member

2463.99 -> that is passionate about what they do

2465.55 -> because they just love and they just live,

2468.91 -> sleep, and breathe this stuff.

2470.11 -> And it's awesome to see them grow

2472.09 -> doing something they're passionate about.

2473.41 -> So understanding that stuff has been really great

2475.3 -> for my team and growing them

2477.37 -> and learning through this journey of cloud

2479.89 -> that we're all going through.

2482.11 -> - Amazing.

2483.64 -> Yeah, I think I'd say for me,

2485.08 -> I really agree that you have to find the people who really

2487.09 -> love it and love to learn

2488.11 -> because I think cloud is always like,

2489.7 -> it's about learning and understanding

2492.04 -> there are always new services, always new threats.

2494.89 -> So finding people who really love learning it.

2497.47 -> So the background is, I mean,

2499.18 -> sometimes you need specific background, specific knowledge,

2501.46 -> but other than that,

2502.36 -> finding people who really love to learn,

2504.16 -> really want to, you know, never know the answers,

2509.44 -> they don't like not knowing what's happening.

2513.43 -> - They just go out and they get it, right?

2516.46 -> - And for you as a manager,

2518.56 -> what do you see that is like

2519.91 -> maybe the largest challenge

2521.98 -> with building a cloud security team?

2524.98 -> - First, there's a couple of things.

2526.63 -> So like, first and foremost, avoiding burnout.

2529.48 -> This job is stressful.

2531.31 -> It's a lot of work, lot of hours, right?

2533.56 -> So making sure you're giving your folks

2536.23 -> on your teams that autonomy to take vacation,

2539.38 -> remind them to take a vacation.

2540.7 -> Actually in some cases,

2541.81 -> force them to take vacation,

2543.49 -> especially if there's an opportunity

2545.71 -> and there's nothing actively happening, get them out there,

2549.07 -> get them to see the world, get a hobby, live life, right?

2553.12 -> And then when they're recharged like that

2555.28 -> and they're motivated and they're passionate,

2557.08 -> they come back to work and they want to do more cool things

2560.38 -> with security and overall.

2562.87 -> The other thing is just making sure you're engaged, right?

2567.649 -> Asking questions and pushing, right?

2570.25 -> Constantly asking like, what's next? Where can we go?

2572.86 -> And as a leader, sometimes I could be wrong.

2575.8 -> So hearing that input and then applying it

2578.59 -> so that we can get better as a team is huge

2581.2 -> because it's not just a one man show, it's everyone.

2585.91 -> - Yeah, couldn't agree more.

2589.75 -> Thank you for that.

2591.37 -> So now we're going to summarize it.

2593.47 -> I think, I mean, first really again,

2595.12 -> thank you for these amazing insights and

2597.143 -> I think you couldn't have someone better who will

2601.63 -> teach you all these kind of stories

2604.33 -> from the frontline, from actually doing the work.

2606.67 -> So sometimes when we do research,

2608.56 -> we're kind of in our lab and

2610.48 -> we are focused on what we do and investigating,

2614.29 -> but when you actually experience it

2616.15 -> as someone who actually has to deal

2619.36 -> with these day-to-day challenges,

2620.92 -> it's a whole different perspective.

2622.75 -> So I really appreciate the knowledge

2625.66 -> that you shared with us today.

2626.77 -> - Thank you.

2628.69 -> - So just to summarize, I mean we have some

2631.54 -> short lessons that you can take.

2637.36 -> And so with the API attacks,

2640.15 -> I think that what we show is that visibility,

2643.33 -> understanding visibility is the key.

2645.88 -> And understanding misconfigurations

2648.1 -> is another challenge and this is something that

2650.77 -> you need to have.

2654.24 -> So Lapsus, we didn't touch it, it's a topic that we skipped,

2657.58 -> so skipped it also now.

2659.53 -> For data exposure,

2660.7 -> so we really recommend monitoring,

2663.61 -> understanding all the instances of data storage

2667.36 -> that you have.

2668.193 -> So it can be, again, hosted databases,

2670.3 -> past databases, storage,

2671.77 -> you have to understand all of them and

2673.87 -> never forget that there might be

2677.069 -> another database somewhere.

2678.716 -> For a software supply chain,

2680.62 -> it's scan and prioritize all the infrastructure,

2683.71 -> the images, make sure you have the right processes for that.

2686.92 -> And for identity supply chain,

2688.39 -> make sure that you validate all the third party services

2691.9 -> that you allow in your environment,

2694.54 -> all the roles that you allow in the environment.

2696.37 -> Make sure that they really need all these permissions.

2700 -> Now for if you want to stay ahead

2701.44 -> of different cloud threats.

2702.4 -> So we have some resources that we use at Wiz,

2705.73 -> so there's the open cloud vulnerability database.

2708.37 -> We also wrote security,

2710.05 -> this is something more before your engineering teams

2713.44 -> we wrote based on the vulnerability research

2715.84 -> that we had.

2719.68 -> We wrote an isolation framework.

2721.36 -> It's how to build if you use

2724.21 -> multi-tenant services or build multi-tenant services,

2728.17 -> how to build it in a secure way,

2729.94 -> how to avoid cross tenant vulnerabilities.

2731.68 -> So we recommend you read these materials.

2736.99 -> It's another, like, it's an open website.

2740.14 -> There is a GitHub repository where you can

2743.47 -> add comments and the request for that.

2747.37 -> And so that's shortly about Wiz,

2750.1 -> and now we'll open the floor for questions.

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