Scott Piper: [00:00:00] Cause it was one of those problems where like looking at it, it's one of those things you see it and you're like this shouldn't exist. Like this is always bad. And so when there's cases where it's like always bad, that's where you oftentimes have a lot of leverage with different vendors like AWS to be able to see if there's something they can do to like basically make this not possible for people to do anymore.

The cloud security is no longer just focusing on an AWS environment or I always say AWS cause that's all that I care about. To me, no other cloud exists. That's all I care about.

AI especially lives and dies based on the access to data that it has. And so as a result of that, it oftentimes has access to a lot of critical data inside people's environments.

Ashish Rajan: Do know what a cloud research team is? In this episode with Scott Piper from Wiz, we spoke about what is a cloud security research team? Why are they different to a pentesting team? Why are they different to a bug bounty? Why is there a need for having a research team in the first place? And all the work that all the amazing people who find your security [00:01:00] vulnerabilities in cloud service providers in adjacent AI and everything else that goes around with it in this conversation with Scott we spoke about that we also spoke about how enterprise who are looking at moving into cloud today or trying to tackle the cloud security challenge how you are able to at least get to a point where you're comfortable with the security posture of your cloud environments.

By worthwhile calling out, we are recording this at fwd:cloudsec EU it's a great conference. It's a not for profit conference that you should check it out, which is run by practitioners for practitioners. I also want to say thank you to everyone who said hello to us and enjoyed the podcast.

Super grateful. Thank you so much for coming and saying hello and coming to my vlog as well. I look forward to seeing you at more conferences and I hope you enjoy this conversation. If you know someone who's interested in a cloud security research role or is looking into what kind of research is available, definitely check out this episode.

If you're here for a second or third time and you're listening to this on Apple or Spotify, definitely give us a review rating. It definitely helps more people find out more about us. But if you are watching this on YouTube or LinkedIn, definitely give us a subscribe, follow. And leave a comment for what else would you want us to cover.

I hope you enjoy this episode. I will talk to you [00:02:00] soon.

Welcome to another episode of Cloud Security Podcast. We are at fwd:cloudsec EU today. And I've got Scott with me. Welcome to the show, Scott. Could you give us a bit about yourself? What are you doing these days? And where was your cloud security journey started?

Scott Piper: Yeah so I'm working at Wiz. These days on the threat research team there and I have for past number of years been focused on AWS. Prior to this, some of the things that I've done is, was one of the original organizers for fwd:cloudsec. So we're now here at fwd:cloudsec EU. So first one, by the way, yes.

So the organization has expanded international now and had also at one point in my career written number of public open source tools and things. So tool called cloudmapper or flaws.cloud, a CTF back in the day. So now just continuing in that role, in terms of creating some public blog posts and other things as well.

Ashish Rajan: What are some of the things that you guys do at research teams? Cause I guess one question that a lot of people ask is like, And funny enough, I saw this as one of the topics at the fwd:cloudsec EU as well. What does the research team do? [00:03:00] And what is the cloud security research team? What do they do?

Scott Piper: Yeah. You sound like a CEO asking like why do we pay you?

Ashish Rajan: Why, what do they do again?

Scott Piper: I guess like our core responsibility is building detections into the tool. So this would be, identifying different misconfigurations and things like that. So people on research teams, one of the attributes of that type of human is probably that they have a social media addiction to Twitter and seeing, what are the new blog posts from other people in the cloud security community out there as well and making sure that our own product is taking like those types of things into consideration and then also trying to, generate those detections on our own as well.

Reading through the documentation, testing out various things in order to create that type of detection capability, running honey pots as well and seeing like what are attackers doing in that environment. For us, we now have capabilities not only in terms of like CSPM type capabilities in terms detecting misconfigurations in cloud environments, but then also moving more into monitoring, different cloud logs [00:04:00] and events in order to detect things there as well. So those types of activities writing blog posts on things, some conference talks. And as part of that, we're trying to share that information with people, but then also identifying what are our best practices that people should follow?

What are the things that, we are hearing and seeing from, some of the maybe more advanced companies out there, what are they doing and trying to share that with people as well in different ways, seeing things that may not be working as well for people and trying to, identify how to improve on those things.

Ashish Rajan: In terms of specifically going into the differentiation, because a lot of people look at research and go, Oh, so is it like bug bounty programs? Or so what would be the difference between a cloud security research and like that kind of traditional security research?

Scott Piper: So we have two research teams at Wiz.

So we have what's called our vulnerability research team and our threat research team. I'm on the threat research team, the vulnerability research team is the cooler team, maybe in terms of, is that where you are? Is that what, and so I'm not on that one, but those are the ones that are like hacking into the different cloud [00:05:00] providers.

Nowadays they're hacking into some of the different AI services. And so they're trying to break in. And the purpose behind that is, one, they want to ensure, that these are secure services. Everybody is building on these foundations. If those foundations have, security issues with them, then everybody that's building on top of that inherits that risk.

So they're trying to improve that. But then also as they're, I finding various flaws and oftentimes they have to chain together multiple problems inside these environments in order to ultimately get to, the ultimate goal is like cross tenant access, which means the ability to use a service, but then be able to see your data in the service.

So they're able to other people's data in that service. And so that's like the ultimate goal, to be able to access everybody's data. And they're terrifyingly good at that type of thing. But in doing that, they're chaining together these different issues. And so when they do that, they are giving further proof that all of these different Issues matter, so when you see this finding or, this [00:06:00] various problem that somebody is telling you that you should be fixing in some way and you're like that doesn't matter.

You can point to proof like it does matter, like here's an example of a case in which, this cloud provider was hacked because of, chaining together that issue along with other issues. And so it gives that proof of those types of things. And so to your point also in terms of what does the threat research team do or the research teams like that type of work was also tied into what we call the PEACH framework.

So this is something that we released to tell people, if you have a multi tenant product, here's how to segment things. Here's some of the things you should watch out for. So oftentimes, the types of research we're doing is feeding back into other things. So people in the research team are like siloed may not be the right word, but focused on different areas. Like I only focus on AWS. If you ask me a question about Azure or GCP. I have no idea, but focused only on that one thing. And so different people on the team are experts in different areas and are able to just dive [00:07:00] way more deeper than, is financially possible.

Like companies that don't have dedicated research teams and people that dedicated to having expertise in this different areas. So you have these people that ideally, hopefully have this expertise in different areas and then are feeding that back into the blog posts the product in different ways, writing these, community frameworks and other community projects as well.

Ashish Rajan: A lot of people also may confuse themselves with cloud pen testing and research. They might just say, but I do cloud pen testing. It's not the same thing.

Scott Piper: Yes. And so I think in one way, like our Vuln research team, because they're going directly after the cloud providers, they're like, playing on expert mode.

Cause a lot of times, people bring in like a pentest Oh, it's a new application. We acquired a company, and the company was a startup and they never focus on security. And so there's a billion things wrong with that, and it's it can be fairly easy for, pnetesters a lot of times to identify the various problems.

But when you're going after like big established companies, products that are, they're in use [00:08:00] by, like many customers. That is a product that has already been through all of the pen test. It's probably had multiple pen tests from different company internally, externally.

So that's like a more difficult thing for them.

Ashish Rajan: Would you say that? And the reason I asked is because I think a lot of people almost misunderstand cloud pentesting as well. A lot of people use a security assessment as a way to say, Hey yeah, I do cloud pentests, but it technically is just an assessment.

Sometimes an automated assessment as well. What are some of the interesting things you've found in your research that you've been working on for the past few months or however long you've been in the space that stood out for you that, Hey, by the way so these kinds of things is why we need to do research.

Was there anything that stood out for you?

Scott Piper: Yeah. So like recently I had a blog post on this concept called request collapsing, which is a. feature of many CDNs. So sometimes people will log into a website. This happens every few months you'll hear like a news story about people logged into a website and they saw somebody else's data.

So they logged in with their own username and password to a site, but they saw the content of [00:09:00] somebody else's account. And so the way in which this can happen is through different types of CDN misconfigurations. And sometimes those are like very obvious, but with this concept of request collapsing, it is not obvious to most people.

And so I guess to try and quickly summarize it is a CDN will cache a request. So you make a request, it caches it, somebody else makes the same request and it returns that response to them. But what happens if multiple people make the same request at the same time? Should all those requests go through to the origin or should it cache the very first one and then send the rest of them?

And what happens if that first request that is going to be cached in some way isn't ends up, with some type of caching directive saying don't cache this, so you've held up all of these requests. And then something says don't cache it. Do you then make all those requests to the origin, which could potentially be, if it's a very popular site, maybe like suddenly a million requests are flooding in.

Basically things can work in an [00:10:00] unexpected way. And so the blog post talks about what to watch out for there. And so that's like an example of something where identifying a problem that, exists out there, but it's not a problem where there's like a clear, you misconfigured something, you did something in a bad way, this is functionality that oftentimes people don't understand.

This is how it works, and so you should be mindful of this because it does lead to security incidents every once in a while.

Ashish Rajan: And I guess cause there's one of your research was around the whole GitHub pieces as well. Yeah. And the reason I bring that up is because I feel like the cloud market or the cloud security market in general, since the time people like you and I have started to where it is today, very different worlds.

Yeah, maybe just to set some context and we can bring this back to the research part as well, because I think that probably amplifies the need for research even more. Where were we in the beginning when all of us were trying to write a maturity framework blog? And then what was the thinking for a lot of us there?

And if you can put where were you in [00:11:00] that mindset? And today as you look at this, Where do you think the world is and why there's a need for research as well?

Scott Piper: Okay. So it's a couple of things to unpack there. So first I'm jumping into that GitHub issue that you were referencing.

So this is an issue that a number of research teams from a number of companies had put out blog posts related to GitHub actions and how that integration with an AWS IAM role works. And so it's through this feature called OIDC. This was resulting in some cases in the ability for, if you created one of these integrations and you misconfigured something in a certain way, it could allow an attacker to set up their own GitHub action to be able to assume the role into your account.

And so there were a number of blog posts where people identified this problem, identified a number of victims with it. And so I was luckily given the time to investigate this more thoroughly deep dive into it and try and drive it home in terms of eradicating the issue because it was one of those [00:12:00] problems where like looking at It's one of those things you see it and you're like this shouldn't exist this has always been bad.

And so when there's cases where it's like always bad, that's where you oftentimes have a lot of leverage with different vendors like AWS to be able to see if there's something they can do to like basically make this not possible for people to do anymore. And so this was luckily like, one of those types of problems.

And I took like a multi pronged approach to it. One of them was there was unfortunately a blog post tutorial telling people how to set up this integration that had this problem in it. And so that was like one of the reasons why this was happening was like if you were to Google, how do I set this up?

You maybe seeing this, unfortunate guidance on creating this misconfiguration. So I reached out to the author. They were changed it. So now it gave like the correct advice for people. Another problem is there was a issue I would say in a Terraform where it would do something somewhat unexpected there as [00:13:00] well. And so was able to get that changed. And then with AWS themselves a couple of things happened there. So one of them was in the web console. When you set up that integration it now says, Oh, you're setting up basically an integration with GitHub actions.

Here's an additional thing that you need to do. it would have an additional, component in the web UI there. They also sent out an email to all customers saying, that you need to fix this. And then they also, made a change to basically say, this is no longer going to be possible.

Everybody needs to, be mindful that like they were just going to break people if they tried to make it. Yeah. So they luckily did that. So that was like an example again, where the research team has luckily been able to work on a thing that like had, community benefit, for everyone there.

Ashish Rajan: Where were we back when we started cloud security?

Scott Piper: Yeah a number of years ago Cloud security was more like isolated into its own thing. If you're going to work on cloud security, you were only purely working [00:14:00] within a cloud environment and you were doing cloud security things where that was like, it was its own thing.

Whereas nowadays I feel like it's blended more into, other areas. So we started seeing that with the, Like performing terraform linting. So the concept of, instead of just checking for a misconfiguration inside the cloud environment, can we check for it before it gets to the cloud environment?

So start checking for it in code and performing those types of checks there and then the concept also, cloud security teams are more involved with helping developers create the concept of paved roads, so instead of giving people free reign to do whatever you create some modules or create some things that are implementing best practices, but then also are hopefully things that are just generally useful to your team.

You're start identifying like what are some concepts or things that people are doing regularly inside our environment? Can I create a Terraform module for that? Everybody can just use that one Terraform module and it's [00:15:00] already doing all the best things, but then it's also just something that is easier for the developers to use.

So they're encouraged to use it. So like the best case for any type of security like policy that you have is that people just do that as the default thing, as the easy thing to do. And so that's like the concept of paved roads.

And then on the other side of things, like when potentially an incident happens in some way, cloud security teams are interacting more with their SOC teams, more with, incident responders to, to, make sure that they have all the logs available and that all this tooling, works well with one another as well in order to investigate those issues.

Ashish Rajan: Sounds like cloud security is a lot more complex than just basically. And we haven't even touched Kubernetes yet. Yeah. There's a whole other layer to that as well.

Scott Piper: And I mean the other thing with like cloud security is it used to be everybody was in like a single monolithic account. Or you had some companies that were breaking things up into a couple of accounts and then there's various benefits and reasons for doing that but they still only had like a, a big company that was [00:16:00] doing like this type of thing, maybe had a dozen accounts.

Whereas like nowadays, like a dozen is the minimum. Like I personally have a dozen of these accounts, so there's companies now with tens of thousands of AWS accounts, like multiple AWS organizations. And so that creates like its own complexity and its own beast as well in order to deal with.

Ashish Rajan: Now that we are in this complex world of cloud security and now that you're focusing on research as well. For people who are in the enterprise space or people who are leaders who are listening to this conversation, what do you recommend are some of the, for lack of a better word, tactical things that people should consider if they haven't already in the cloud security program?

Because as much as there are a lot of people who are quite advanced in cloud security, there are also people who are getting into cloud in 2024, but with the research that you've done so far in terms of enterprise that are moving into cloud, they have hybrid networks potentially multi cloud as well and AWS being a specialty too What should they put in as hey, these are things that should be like the tactical things I should definitely [00:17:00] cover before I even go for the bigger long term pieces as well.

Scott Piper: I think one of the Big projects that larger companies should be doing and smaller companies as well. If they have the capability to do it is to have a good account vending strategy. And so the concept here is to make it easier for people to have their own AWS accounts or other types of cloud accounts and What is like the defining characteristic of an account vending strategy there is that it's a holistic thing.

So meaning that you're not just giving some of the ability to make an AWS account, but when they make that account that it's already integrated in with their SSO provider, it's already integrated in with a GitHub repo. So this encourages them to not just be doing click ops, but now here's a GitHub repo that has like a, Skeleton Terraform template in it, and it's already created like the GitHub action so that when you, I guess approve a pr, it's already going to deploy into your AWS environment.

So like all those things get integrated together. And so that goes back to, the [00:18:00] concept that like cloud security is no longer just focusing on an AWS environment or I always say AWS 'cause that's all that I care about . So no wait to me, no other cloud exists. That's all I care about.

So whenever I say AWS, you can oftentimes just like extend that to all cloud environments for their own terms, but that it's integrated in with all these other things. And so having that type of strategy where you are, thinking about how are the developers actually going to be using the cloud, and how can I make that easier for them and how can I build in into that GitHub action and in that pull request process, like automatic checking of, their Terraform. So performing linting there, or again, when I say Terraform, CloudFormation, or, the other options are also applicable there.

Ashish Rajan: Having automation and to your point about having a paved road.

Does that mean the kind of teams they require are different as well? Like I think to your point about someone who was just a comfortable person who just looked at AWS console from a Clickhouse perspective. And nothing wrong with that, by the way, I just want to call it out as well. I don't think people should feel bad about the fact that they use primary the console, nothing [00:19:00] wrong with it.

And would you say the team skillset these days as well are, you're expected to be knowledgeable in a lot more than just cloud these days. Because we've, it was a case before as security people as well, you had to know networking, routers, all of that as well. But with the complexity and I'm going to throw Kubernetes and AI in there as well.

What do you see of the impact of Kubernetes and AI in the cloud space? The reason I'm asking is because I guess there is some research required there as well, because the same way you spoke about the cloud research, I feel are these some of the other components that people should start consider as Hey, these are components that have tentacles into my cloud environment.

So they're equally important versus. No, I just need to focus on the cloud.

Scott Piper: It is important to know about those other things because AI especially lives and dies based on the access to data that it has. And so as a result of that, it oftentimes have access to a lot of critical data inside people's environments.

And so you have to be aware of how your company is using AI because you want to understand like what has access to all of your confidential proprietary [00:20:00] data. And so that's a, a key thing there. But then the other part about. Gen AI these days is, I think the most valuable part of that for cloud security practitioners is that one of the things that does very well is translation.

And so within security world, we end up having a lot of domain specific languages. And you have a one way in which you're querying this type of, logs, you have another way you're querying this other type of data source. And that's one thing that Gen AI can do very well is performing that translation So you're like I just want to be able to search for this thing And then it'd be it can generate those types of queries for you

Ashish Rajan: So that my final question is also around a lot of people want to become threat research people as well in cloud It's not the same as bug bounty research So for people who are probably considering going down that path of doing a cloud security research, is there a pathway?

Because this field didn't even exist until a few years ago.

Scott Piper: Yeah. It's always hard trying to give advice and guidance to people, especially because whatever got me to here is probably not what's going to [00:21:00] get anybody else to where they were, cause to your point cloud security was not a job role at the time that we joined it.

And so I think some people come at it from the perspective of, they were just building applications and started taking more and more of an interest into cloud security in different ways. And I think that is very relevant for the type of role that I'm in where I want to give people guidance on best practices.

Like I'm not ever. trying to find bug bounties, like trying to find problems in other people's environments. I'm trying to generate detections for misconfigurations in our own environment. And so a lot of times you have, people that are building things in the cloud that start slowly moving into more cloud security type roles just because as they're building things that, they're capable and understanding like what is happening inside their environment in terms of, where are places were, they start thinking, Oh, we already have a linter for, tabs versus spaces inside our code or something like that.

And they [00:22:00] can start saying Oh I'm already checking for those types of things. I might as well check if somebody is going to make a public S3 bucket, and so they start being able to add in those additional detections and checks in different places. And so those people come from a very strong background.

So people that are already building things, but then you also have people that come from like more incident response types roles, and they start saying, Oh, we hopefully have not had an incident in the cloud, but maybe they worry that they may one day. And so they start learning what are the type of log sources that exist there? What is normal in my environment? And they start, digging around and seeing, what do logs normally look like in their environment? You start having ideas of, Oh, I should check for this thing.

And then you realize that thing happens 10, 000 times a day in your environment and you start better understanding what your environment looks like. And so those people also, I think, end up moving into those cloud security roles too.

Ashish Rajan: With the research team that probably, obviously, It's definitely encouraged to try and do some more research in your current roles, expand into it.

Because you said a lot of your focus tends to be on best practices. What are some of the best practices for enterprise in an AWS cloud security [00:23:00] kind of context?

Scott Piper: I did want to say I focus on best practices. But then we have other people on the team, on the research team, doing a lot of other things.

So we have some people that have generated a number of CTFs. For people to be able to play and understand things. So we have a CTF that's dedicated to Kubernetes. Great. One to EKS, one on IAM. And then the latest one is on Gen AI. So you can actually like try and do some prompt engineering type stuff there.

So we have those and we have various other like projects that have been created. So there is research is pretty broad in terms of like the things that people can do, but to your question, as I mentioned, like the account vending strategy, I think is really powerful for that. thing for companies to focus on there.

And I think that shifting left, as they say, to, to getting more involved in developers and trying to help them generate those types of paved roads and things as well. And, but then also being able to add in more and more detections on that side of things before things actually get deployed into their environment.

And that can be really powerful as well, because if you purely focus on a cloud environment and you identify, One day you [00:24:00] decide to check for something, you identify, Hey, here's a common misconfiguration I have, here's a common vulnerability and things. If you're able to move further towards the left in order to identify what is the source of that problem, is there like a common module or, common library, like a single like source where that problem can be fixed and then it can be fixed in all these other places.

Because if you purely look in the cloud, a problem that a lot of times happens is, you identify this problem, you tell, Hey, you have 10, 000 findings, but there may only be like one place you actually need to fix that problem. And so if you can identify what the sources or the root cause, that is also, going to save a lot of people time as well.

So that, that's important. Nowadays, and I'm biased in this opinion, but getting more context on things and be able to identify where the correlations are between those different things. So being able to see what the cloud environment looks like, what do the cloud events that are related to that cloud environment look like can you get more context into that cloud environment from [00:25:00] not only like agentless scanning, but then also having some type of agent as well running inside that environment.

So getting all those different data sources. But then being able to tie them all together in some way and generate a stronger signal from that, because, when you're purely looking at these, single sources of data and you're trying to generate, findings or alerts based on single data points in there.

You, you end up with potentially a lot of noise or, very low signal types of events, but when you correlate those things together to be able to say, this is a little bit of a problem, this is a little bit of a problem, and this is a little bit of a problem, but tying all three of those together, this is a bigger problem, and that should be like where your focus is, that is also the type of thing, That benefits larger companies as well.

Ashish Rajan: Yeah, I think very well said because a lot of people tend to focus on, Hey, cloud vulnerability was became an assessment thing, so I have S3 buckets or whatever. But even though that S3 bucket may be private, but that being allowed access from an EC2 instance that seems to be, which is a public EC2 [00:26:00] instance on the internet, that is a high at that point in time.

It's not no longer a low anymore. And that I'm referring to the CapitalOne example, obviously, and that's where having that context to what you said. And also the fact where it's a lot more complex than just basically saying that i've got 10,000 alerts. As soon as I go through them, my life is like set. 100 percent cloud security right there for you.

With that said, You've had CTFs, flaws, one, two, is there three coming, or four, five? No, yeah.

Scott Piper: Mostly because I don't want to pay the 30 a year for the .Cloud domain. Oh fair. Oh, actually,

Ashish Rajan: is it 30? I

Scott Piper: think so, yeah.

Ashish Rajan: Holy shit, okay, wow. Now the cloud is a thing, so I guess now, at least it's not called .Ai, so that should save you some money.

So the other one is, now that you've been researching full time into this AWS space, are there any patterns that are emerging for you that you see, oh, this is where we are heading for cloud?

Scott Piper: I think to the point of doing more integrations between different things. So moving more into other areas to get more context and pulling [00:27:00] that all together in order to, extract out like a stronger signal by having more data sources is really the main focus there.

Ashish Rajan: Would you say we'll get to the one platform for everything? Is that one ring to rule them all or one platform? Would we get to that stage then?

I am biased in my views on that.

Of course. We will one day. Watch out for the space. No, but I guess because to what you said, because the more context we pull in, that's what we all security people want.

We just don't want to have an isolated problem just by itself. Where else has it gone?

Scott Piper: Yeah, and it's important also when you talk to the developers and you have more understanding of what's going on, because you tell the developer, Hey, this, EC2 instance has a problem or whatever happens to be and they're like, Yeah, that's in our sandbox.

We don't care. It doesn't have access to anything. Like, why should I waste my time? Improving the least privileges of an EC2 that has zero access to anything important, so when you're actually able to tell them like, no, but it actually has access to that S3 bucket and that S3 bucket, it has like our proprietary data in it. Then you're able [00:28:00] to build the case and not lose the trust of those developers.

Ashish Rajan: Yeah. And hopefully you're not sending, all the 10, 000 alerts straight away to the developers, hoping for the best so that's most of the technical questions I had.

Three fun questions for you, man. You've done this before, right? I'd be curious as to See if the answers change. So the first one is more around what do you spend most time on when you're not working on research for cloud security.

Scott Piper: Woodworking is probably the big thing. Making a table? I have not made a table.

I've made a door. Is it just multiple doors in your house standing up or like actually hinged? Currently one door that's actually installed. The goal is to create like a front door to my house, but creating an internal door versus an external door, you have to start worrying about what happens if there's like a moisture difference and the wood expands?

And so I made the internal door first. I kind of test for myself. Wait, there's no front door in your house? I do have a front door. But I want to replace it. So I want to replace it with one that [00:29:00] I make myself.

Ashish Rajan: Wait, you don't have a front door? Wow, how safe is Utah, man?

What is something that you're proud of that is not on your social media?

Scott Piper: I'm trying to think of what's not on my social media. Your door

is not on social media. Yeah, dog, your door, none of that is like me.

I believe I have given my dog it's best life in terms of he's still alive and doing well and everything. But so like this summer in July in Utah is not a fun time.

So it's very hot. It's fire season, so everything catches on fire. Oh wow. So you have smokes everywhere, all over the mountain west. And I went up to Vancouver, Canada with my dog. And drove that entire distance because I didn't want to have my dog in the cargo on an airplane. I drove up there and he was able to run and, go in lakes and jump off docks and everything like that.

Ashish Rajan: Why Vancouver? You could've just gone to the next state.

Scott Piper: Over. I've never been there before. Ah, explore it, see a new area. What kind of dog is it? It's a German Shorthair Pointer.

Ashish Rajan: Oh, wow, okay. It's a very high energy. Active, yeah. I'm like, super active. I can imagine just running around the [00:30:00] whole day.

No wonder you don't have a front door. Yeah. Just jet off. Whenever you feel like it, just run to the front door. Third and final question. What is your favorite cuisine or restaurant that you can share?

Scott Piper: I think people know that I eat a lot of pastries. So there's a, Queen Amman is a pastry that I've eaten a lot of in my life.

Ashish Rajan: And continue to eat for the rest of my life. Yeah.

Scott Piper: Yup. Yup. Yup. So maybe just that, yeah, fair. Okay.

Ashish Rajan: I don't know. Thank you for sharing that. And so you created fwd:cloudsec

Scott Piper: I was one of the original organizers.

Ashish Rajan: What is it?

Why? What are we doing in the EU at the moment?

Scott Piper: fwd:cloudsec was created as a community conference.

So not one that is as driven by the cloud providers or various vendors. We wanted something that you know, is actually practitioner focused for people and has, talks that are on research that we wanted to know and research that's on, what happens when you are using multiple cloud providers?

What are the best practices there? What are the actual threats that you should be worried about? Because we didn't see that from some of the other conferences and then more security general [00:31:00] conferences. You have talks that are all over the place on, like lock picking and things like that. Whereas we wanted something that was more dedicated.

So a bunch of people got together, created a fwd:cloudsec. And so our first year was in 2020 and it's continued on. It's continued. Becoming more successful and this year there were two major risks that were taken one of them being to separate from re:Inforce, so so moving away from AWS's re:Inforce

it had previously been in the same city right alongside it So this was the first year we're in a different city and then also having two fwd:cloudsec. So there is a completely separate team. So I only focus on like the US fwd:cloudsec and involved with that. Whereas I have not been involved at all with this one.

There has been some overlap between some of the individuals between both of the four cloud sex but I was not involved in this one. And this one has been amazing. Today I only was able to see Rami's talk so far. It was the first talk of the day before we started recording this and his talk was phenomenal.

The [00:32:00] rest of the lineup looks phenomenal as well. And so it has been a success, super packed room, with everybody actually attending because anytime you run a conference, it's always, it's like throwing a party and you're not sure who's going to actually show up. And so luckily like people, have showed up, people submitted talks.

So I think, it's been great. It was presented at the beginning that there were like 113 talks submitted and like 10 talks selected somewhere around that area.

Ashish Rajan: Yeah Less than 10%.

Scott Piper: So again, it's yeah, success and every, sense of the word. Yeah. Yeah.

Ashish Rajan: And it's a not for profit as well.

Scott Piper: Exactly. Yeah. So we have people, all the different organizers work at different companies, some are like vendors, some are practitioners. And so we really try to ensure that it's not going to get, biased in different ways by different people. And, try to ensure when we are selecting talks that you try and make sure are there talks represented all the different cloud providers, or try and have as much different interest areas as possible, all within cloud security as well. Yeah, the team [00:33:00] here again, like I have not been involved at all. Like I get to just sit here as an attendee, just enjoy it while they're like super stressed. And I get to laugh, I know what that feels like, but they're doing an amazing job.

Ashish Rajan: That's awesome, man. Thank you for sharing that as well. And I'll put a link for the fwd:cloudsec EU all the talks for live streaming as well. So I think that definitely worthwhile. By the time you get to see this episode, if you haven't checked out the talks, it's primarily on the YouTube channel so definitely check that out. And I'm sure the slides will be there as well. So with that said, now that we've spoken about research and why are you in Brussels in the first place, where can people connect with you to learn more about the research space? What are you guys working on? Where does your research go end up in, all the research you're working on?

Where can people connect with you and learn more about the space as well.

Scott Piper: Yeah, so there's wiz. io slash blog is where our research ends up. Our research gets tagged with a research tag. So if you want to just focus on the research, and not see all the other blog posts that show up there.

Not that they're not important. They're important as well. Yeah, but that's going to be where [00:34:00] things show up. I'm active on LinkedIn and Twitter as well. My handle, unfortunately, I chose it back when I did a lot of reverse engineering. So it's difficult to like even write out. So it's probably better to click on a link.

Ashish Rajan: Oh, fair. Okay. I'll put the links in the show too. But dude. Thanks so much for coming on the show and thank you for sharing about the research space as well that you guys are working on. Thanks so much for coming. Thank you. Thank you for listening or watching this episode of Cloud Security Podcast.

We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at cloudsecuritypodcast. tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister podcast called AI cybersecurity podcast, which I run with former CSO of Robin Hood, Caleb Sima, where we talk about everything AI and cybersecurity, how can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of [00:35:00] ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. TV. I'll drop that in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍