Ashish Rajan: Welcome Scott. So grateful to you for coming in.

Scott Piper: Thank you. Appreciate it. Thanks for having me here.

Ashish Rajan: No problem. And I was also gonna ask so why that what’s so special about the song that you

Scott Piper: like that much? That’s from turnpike two doors , who are based out of Tahlequah , Oklahoma, which is where I went to college at.

So so listen to that.

Ashish Rajan: Also, there’s a bit of history there as well. You definitely need to get a bit more into the history as we kind of go through this

so I’m going to start with the obvious, I don’t think I have to give you an intro.

But you’re a bit of a celebrity. The, I was going to say the, the legend, but I don’t know. So I’m like but for, for people who may not know Scott Piper I think you have not, you’ve crossed 11 K followers mark on Twitter. You’ve been contributing into the AWS security space before I even got into the space of I’ve known of you for, for a long time.

But for people who may not still know you and maybe living under a rock. So what’s the short intro for who’s Scott Piper.

Scott Piper: Yeah. So about four years ago started in AWS security consulting business as just an independent solo, consultant. And from there, I focused started a lot [00:01:00] with some open source tools that are released through duo security and from their number of blog posts as well worked with a number of different clients doing assessment work for them, some custom software development in different ways, helping to set up their cloud security in different ways.

And then more recently focused a lot on providing training to companies on AWS security. And so that’s what I focus on a lot now took took a little tangent in my career to work directly for a company, but now I’m back to providing security consulting to companies.

Ashish Rajan: Awesome. And this is probably a good question to ask at this point in time as well.

What was your part into like cloud security, cyber security, I know you kind of did a few things, but why AWS security? What got you into cyber security. So,

Scott Piper: yeah, so actually I was the sole security person at a company prior to spinning up this consulting business. And while I was there, I.

You know, had to do everything in terms of our AppSec or cloud sec, or, you know, corporate security in addition to like physical security, like our badge [00:02:00] readers and surveillance cameras and everything like that. So I was, I was doing all of that and doing all of it poorly because I was spread way too thin as, you know, a single person trying to do it with no budget for any of it.

And so one, I wanted to focus on one thing. I wanted to focus on a narrower niche where you know, I could get some expertise in it and do it well. And additionally, I noticed that while I was trying to do all those things of that company, one of the things I was concerned about was our AWS environment.

You know, at the time, I didn’t know a ton about AWS security, but we were running in AWS. And I was just like, I, I would really like it if there was somebody that would, look at our environment or give us some advice on things, you know, something like that. And so, and I couldn’t find anybody there, there wasn’t anybody available at the time, or at least I wasn’t able to find anybody.

And so I knew that there was a demand because I wanted it and assumed that other companies probably wanted something there. And I knew that there was no supply. And so, because I couldn’t find anybody. And so given, that problem of there being [00:03:00] you know, demand, but no supply, I figured this is probably a good business opportunity.

And so that coupled with the fact that I wanted to focus and specialize in one area, it just became like that perfect storm for me.

Ashish Rajan: That’s pretty awesome. And I think it’s really interesting that you noticed the demand supply pieces, and well-placed bet as well, considering cloud security I feel is so, I mean, there’s so much there, even if it’s just one big, if you just pick one cloud.

So I’m curious from your side. What does cloud security mean for you then? Like when you are, when people say, Hey, cloud security, cloud security, but what does that mean

Scott Piper: for you? Cloud security is really become its own thing. And, and being able to focus on one cloud has become its own thing because the different clouds are so complex and large nowadays, I think.

Think AWS is about to break 10,000 different API calls. I don’t know if they have yet, but they’re super close if they haven’t already. They’re super complex there and it’s become like very fractal in the sense that, you know, like those images, those fractal images you look at, and as you zoom in more and more, [00:04:00] like you realize it becomes more and more complex and you keep zooming in and it keeps becoming more complex.

Like that is the same thing that happens with just computer security in general. And then, you know, you zoom in and now you’ve got cloud security, but then you realize if you zoom in further that this is niche of AWS security, and then you zoom in further and you realize, you know, There’sIAM there’s, you know, networking on there.

There’s all these different, you know, niches within the niche. And so, so for me though, like cloud security is a lot about trying to leverage the different cloud providers, what they offer you and try to make as best use of that as you can in your environment. And try to use those things that are available to help you improve your security, try to avoid the misconfigurations and foot guns that are possible in those environments.

And so keeping kind of both those things together there , I’m a big advocate of trying to leverage the cloud for as much as possible. Like you’re already paying for AWS and if you’ve already, or, you know, whatever your cloud provider is, and if you’ve already gone all in, on one [00:05:00] of these cloud providers, or leveraging them to some degree, like leverage them more and more and more, I think.

And yeah, there’s like the concept of the shared responsibility model, where it’s really like this split responsibility where AWS is securing some things you’re responsible for securing everything else. And from just like a cost and maintenance perspective, it is usually beneficial to try and throw as many things over the fence as possible to make them AWS has responsibility in some way.

And so that is, also a part of it is trying to recognize what does AWS offer? How can you leverage those things that you don’t have to do them yourself? You don’t want to have to run some of these different services is it’d be less is already offering them there.

Ashish Rajan: That’s awesome.

And a hundred percent with you on this one. And I can, we can definitely go into the honest reality of going into new AWS service when it’s first released as well. The pain that comes with it and the documentation,

Scott Piper: and that’s something to keep in mind as well is like, there are all these different AWS services and all these different capabilities, but depending on your specific needs, it may not be appropriate for you, or depending on honestly, [00:06:00] the maturity of the services that AWS is offering.

Sometimes they offer things before they have some of the capabilities, some of the features, some of the things you might expect, even when it’s like, a managed open source solution in some way, like elastic searches, like one of the examples of that when elastic search was first released, you didn’t have access to any of the air logs.

You didn’t have access to any of the authentication logs. So you just did not have visibility into any of the potential problems that could exist there. So if you, as you’re trying to ingest your log data or whatever it happens to be into AWS has managed elastic search. You had no visibility into knowing whether or not that data.

Into there because they didn’t provide you with those logs. And I’m a big advocate of trying to use AWS if it’s possible for you, but there’s a number of times where there are those limitations in gotchas where it’s just not going to work depending on your scale, depending on other issues there.

Ashish Rajan: Yeah. Awesome. I love the answer, man. So we spoke about cloud security.

We defined cloud security and we’ve spoken about what does that mean from an AWS perspective, but also how [00:07:00] cloud security has become its own being as well. So. If someone is looking at going AWS today and they’re just going, oh my God, this is so much here. Right? I’m going to zoom out into, from other security leadership perspective and looking at this from a, say a 10,000 feet and going, where are there some obvious things.

That you see people not consider our security leaders not considered when they’re trying to build roadmaps, because I you’ve released like the AWS security roadmap. Like I think it was a second version, 20, 21 version though. But are there any obvious gotchas because once we do this, we’ll get into like specifics of it, but I’m curious, what’s the obvious gotchas that you still see people do.

Scott Piper: So the roadmap that I released was just over two years ago, it’s on its third iteration now. And, and so in terms of roadmaps I tried to create this roadmap, which was going to hopefully be universally applicable to people like it’s opinionated.

There’s going to be different ways where maybe it doesn’t get to work in your environment, you know, or your special situation. But like, I did try to make it universally applicable [00:08:00] and tried to make it opinionated just because there has been. I would say, if you, so in terms of roadmaps roadmaps that exist out there, you know, something similar that, that have been offered by it from other places.

I think that being opinionated was important for it, you know? And so if it’s a vendor roadmap in some way, if AWS comes out with a roadmap or some, you know, other cloud security company comes out with a roadmap for something or another. Beyond cloud security. A lot of times they don’t make them opinionated that because they don’t want to be wrong, like different situations.

There are going to be different things that work and don’t work. And a lot of times people feel uncomfortable about making that like specific guidance to people. But there’s like also the benefit of like an 80, 20 rule, you know, where it’s like, this is going to be useful for most people. And so instead of, you know, giving somebody a a hundred page document where you list off all the different caveats and everything, like my roadmaps, 11 pages long to basically say like, this is what’s usually going to [00:09:00] work for most people.

So I I think that that is really important for other people that are trying to create those different types of roadmaps for companies themselves, when they create these roadmap. I think it’s relevant to acknowledge what your different strengths are. So in my roadmap, for example, I didn’t focus a lot on network security controls, and some companies that I’ve talked to, they have very strong network security controls throughout the rest of their company.

They come from a non-cloud background, they’re an older, more established company that has, you know, like the big firewall vendors and things like that, you know? And so they’re used to that. They already have the investment in those, you know, they’ve purchased these different products that use them.

They have the experience and skill set in them. And so for those companies, it’s more valuable for them to. Give some more priority to the network security controls versus what I advocated in my roadmap. So I think that that’s important is recognizing what are the skills and [00:10:00] capabilities of your employees?

What are the experiences that they have? What is the like, strategies that you’ve already tried to focus on and leveraging those as opposed to, like I made this as a PDF for the whole world to see, like, don’t view it as, this is the way, and you know, you shouldn’t try and do things any other way, you know, like take advantage of the advantages that you have.

Ashish Rajan: Oh, awesome. Great answer, man. I think it’s definitely worthwhile focusing on the strengths of the organization, . So maybe now it could be a good time for us to go start going a bit more deeper into this. The way I want you to take this interview was start from his startup today, which is looking at funding and we’ve signed up and what are some of the initial steps that we could be doing from a, I guess, building the strong foundation so we can build on later on when the startup becomes a Facebook level, at a startup level, what do you normally recommend would be some of the challenges that people would see, and which maybe should be, I guess they should consider from a roadmap perspective for that would set them up for.

Yep.

Scott Piper: Yeah, the challenges I think [00:11:00] that startups have is just time is of the essence, they’re trying to get things done as quickly as possible. They don’t have the bandwidth, they don’t have the you know, the, the human capacity to accomplish different things. And so as an example, they’re like, I am generally.

Not a fan of AWS control tower which is a service that basically provides what AWS refers to as a landing zone. So kind of like a, a default way of setting up your environments. And for the most part, I’m not a fan of it. It has a number of limitations. They haven’t really kept it as well up to date as I would like.

And so some of the limitations are, it doesn’t work in all regions. It doesn’t have an API for it. And, you know, again, that’s a, that’s a solution that tries to be generally applicable and useful for everybody. And given some special circumstances at different companies, it’s not always gonna work out ideally for them.

And so I’m generally not a fan of control tower, however, for startups, like it’s a relevant solution for them to consider because it’s going to be essentially, you know, like a few clicks, you just stand this thing up [00:12:00] and then you’re able to basically have a more secure baseline, then you wouldn’t be able to put together in the same amount of time.

And so, that’s something, you know, relevant there is even though like, I’m like disappointed, you know, when people use control tower, cause I know that they’re going to run into different problems with it and everybody’s going to complain about it in different ways. Like it makes sense, you know, for the bandwidth that a startup has, like they’re trying to move fast and trying to do things quickly.

I think that’s the primary trade off there. You know, the benefit of startups is they don’t have all of the like historical clutter that the larger companies have, they haven’t yet made all of the bad decisions or decisions that maybe worked at one time for their architecture, for the technologies.

And then things have moved on and maybe there’s some learning experiences where they would’ve made different decision today, but they have to continue to support and deal with some of those historical decisions that they have. And so that really becomes the the difficulty for larger companies and also just the scale and the size in that, you know, It’s even though a larger company has [00:13:00] potentially hopefully more bandwidth on their security team, you know, more people to do things.

They also have more problems throughout the rest of the company. So even though, like in theory, they’d have more people to do things. They also have more problems because they are a larger entity with more stuff going on, like as by definition of being a bigger company.

Ashish Rajan: Yep. Awesome. And I think to your point, then what would be considered like maturity, like a graph.

If I imagine there’d be a lot of startups who started with IAM users probably multiple accounts as well, because all accounts are free. So keep creating them, I guess. The so what would you consider as a good maturity benchmark for a startup then? AWS security.

Scott Piper: So, in the roadmap, I do try and lay out essentially like phases , for people to try and focus on different aspects of their security

I tried to make some, again, upended choices as to what things they should work on first as kind of a way of building up their maturity over time. , that’s something that you see sometimes with, it’s becoming actually less common now with startups. Some startups are focusing on basically SSO [00:14:00] first.

And so, , they’re already using something like G suite as their identity provider, essentially. And so they’re leveraging. As a way of using SSO in order to get access to their different AWS accounts. And so they’re avoiding the IAM users from the very beginning. So that is for companies that are perhaps a little bit more technically savvy you know, or more security focused.

You’ll still see though, a lot of companies that are using IAM users, you know, everybody’s working in the same account with admin privileges. And so, there’s always like room for improvement, for those companies to better leverage, again, some of the best practices on AWS that I tried to like you know, identify in, in that road.

Ashish Rajan: That’s pretty awesome. And maybe let let’s up the ante a bit more over here than the start has made a lot of money. They’ve become like a medium to large-scale business. I don’t know. Well FinTech or I’m just going to imagine some company which has got a lot of employees now, thousands employees, massive AWS footprint now.

So what are some of the challenges at this scale that you see people have? I mean, assuming they haven’t [00:15:00] done any of that from the boss, because they were too busy with speed . So, what are some of the challenges at

Scott Piper: that level? , I think with that level you know, again, it depends on the companies, but I think trying to limit people to least privileges and better isolating people and better leveraging technologies that.

Enable you to not have so many administrators. And so, as an example of this, using something like Terraform, CloudFormation, something like that. Usinginfrastructure as code, where you are checking that into GitHub or some type of repository, and you are having some type of approval process to get those changes deployed into your environment and have a solution set up that is deploying those changes for you so that you are not, you know, you don’t have everybody at your company running Terraform, like from their laptop, you know, Terraform you know, applies or something like that.

Requires everybody to have administrative access into your different AWS accounts. So getting yourself to a place where you have some type of CICD system that is deploying those changes for you, so that you don’t have individual [00:16:00] people with those administrative access to that account. And instead can leverage some type of like break glass functionality for when those situations, you know, inevitably occur where somebody actually does need to be hands on keyboard, accessing the different AWS accounts directly.

Ashish Rajan: That’s a great answer. And I think IAC or infrastructure as code has definitely going a long way and having the right skill set would be, I mean, I guess the person who knows one of these or knows multiple of these, it definitely will be an interesting challenge, but and maybe a, add a few more layers to this as well then.

So we’ve done IAC . We are deploying the code Threat detection and maybe even continuous compliance and like, what about those kinds of topics? Like how do you see people tackle that? And what’s your recommendation around that space?

Scott Piper: So first of all, do compliance because that’s the easier problem there.

And so you have some features on AWS that enable that to make it easier. Where you can, for example you know, have your EBS volumes encrypted by default, you know, some things like that. But then also with infrastructure as code, you do have some linters out there that will [00:17:00] check that infrastructure.

For some of those compliance issues such as, you know, making sure you’re encrypting resources are not making S3 buckets public and things like that. Before they actually get deployed into your environment once they get deployed into your environment, then you can use your CloudTrail logs or in more real time, look at cloud CloudWatch events in order to try to detect those issues in real time or near real time.

And then kind of as a, another layer of defense in depth, you then have a number of like CSPM tools out there which is cloud security, posture management tools which will scan your environment. And so they make a whole bunch of lists and scribe calls and, or to look at everything that’s in your environment and identify when things are out of compliance there.

So that’s your compliance and, and it’s never like super easy, but it’s easier than the threat detection. I think threat detection, I think is a harder problem there because it’s oftentimes very difficult looking at specifically CloudTraillog in isolation to identify whether or not something bad is happening here.

Because anytime. You [00:18:00] think of any possible AWS call that can be made and that an event is logged for, there is always going to be a, actual, reasonable, reason why somebody is making that call in some way, , like people think like, oh there’s STS get collar identity is basically the, who am I call?

And, and this is something I did. I was like, I was like, oh, you know, only attackers ever run, who am I? Cause everybody else actually knows who they are. You know? Like, why would anybody else ever run this call? Like, no, it’s super common. Like, I think Terraform runs it by default. Every time you run Terraform.

And , so it’s super, super common. I mean like listing your S3 buckets, you don’t think that’s going to happen, but yeah. Yes every person when they get access to an AWS account in order to make sure their credentials work, usually run you know like S3 LS in order to see whether or not like they can see any you know, S3 buckets.

And so like, again, that’s super common. But what you can start doing is start trying to understand more context behind these calls. And so a human user, a person making a call [00:19:00] to list the buckets in your account. That’s super common. Don’t try and alert on that. It’ll create a billion false positives.

Don’t do that in application, making a call to list buckets. Then that becomes a lot more interesting. If you can identify that this is a service, you know, some type of application running on one of your and it is making the cult a list of buckets in your account that is oftentimes much more rare. There could be some applications, again, that could be doing that.

Maybe you have some type of , backup utility that runs out of an ECE two and wants to try and look at your different , S3 buckets that you have, or again, it could be one of the CSPs tools that is listing all the S3 buckets in order to see whether or not they’re in compliance in different ways.

But you should be able to filter out those false positives and be able to say, okay, as long as it’s not my CSPs tool or some of these other, no one exception. If any other application in my environment ever tries to run S3 LS, like that is weird. That is something that, your security team should investigate more.

And so if you can get that context and additionally, and this is a lot more difficult to [00:20:00] do is try to get additional context from other events that are happening, not only did this EC2 make a call to list the buckets in the account, but it also did these other things.

It also made a call out to this DNS. It also, did these other things, if you can get that different context and start building that up, that becomes a lot more powerful and it helps you reduce that false positive problem. But that’s a difficult thing to try.

Ashish Rajan: Yeah. I can’t even know I was in the playbook red.

You would have to keep, I get, start building from day one because I don’t think there is like, I think a lot of people go down and do CIS benchmark as like, oh, this is my playbook, but that’s already an incident response playbook. That’s not really like a,

Scott Piper: and that’s like compliance issues that they’re finding there, trying to do incident response, trying to figure out what’s weird, I’ve created rules before where it’s, detecting if any, like large ECE twos are ever used because , those are used by Bitcoin miners, but then you find out that, oh, the company actually has a use case for that large EC2 , or. We, you assume a company only works at a certain regions and then all of a sudden you find out, [00:21:00] oh, you have, you know some third-party contractors or something, and they want to make use of resources that are closer to them.

And so they use a different AWS region, or you find out that your company is expanding into a different market and now, you’re using another region. So there’s all those like, you know, gotchas for over any of those types of rules where they’ll end up creating false positives.

Ashish Rajan: Oh my God. Yes.

And I, that remind me of, so I, I mean, in my day job I remember first day I came in like, certain regions I wanted to switch off. And I think this is on the same time that, AWS made it possible that you can, you have to enable each region that you go into your own by default, which used to be the case before I’m going on about like, oh, we should all be using the IRR.

This, this region is required. You’re only in these regions and like, We’re not using them. Like, what do you mean you’re not using them? It’s probably be on my and they’re like no, it’s not, I don’t know if it sounds like an embarrassing moment, but it was like a humbling moment as well for me, because I, how quickly things change in AWS is also an insane thing that I just cannot, like, it’s not that you get a memo from AWS or Azure or Google cloud, [00:22:00] Hey, by the way, Ashish, we have changed this.

So next time you feel embarrassing yourself or don’t say this. So, you know, I do find that’s also something that, is probably making the thing quite complex to the point that a lot of people have wondering that there is no way to standardize security in a cloud. I’m not even talking about multi cloud.

Right. I’m just talking about just AWS. How do I standardize my operation in a large AWS environment what’s your recommendation? Or are you more on the path hey, let each business unit deal with their problem. All I care about is the biggest skill. So curious to know about that man.

Scott Piper: So, there’s a couple of things to unpack there.

You know, initially you talked about like the issues with the regions that in and of itself is a super complex thing. You can disable STS endpoints in your different regions. And a lot of people don’t understand that disabling, those end points does actually disabled the region.

The only way to disable those regions, the existing regions is through a STP service control policies that can be applied there. And then in terms of like new regions coming online, I think it was the Osaka region [00:23:00] was like an old region that then got enabled by AWS. And so this was a case where it was like a region that you didn’t actually, nobody actually.

Unless you specifically asked AWS spore. And so this broke that rule that, you know, new regions are enabled by default because it was technically an old region that just became enabled for everybody. So it’s chaos. So the regions area mess but also just like understanding all of these like details and caveats.

Like nobody knows all of it. I’m learning constantly. I’ve worked with so many different clients, you know, where they asked me questions about things expecting, I know the answer and I’m like, again, like. All body of knowledge is, is fractal where you can get so down in the weeds, in different things.

if somebody has been focusing on one individual AWS service, for the past, number of years, and that’s all they’ve done, clearly they are more of an expert, you know, than, than anybody. Oh, I’ll ask me these questions. And I’m just like, I have no idea, I’ve never touched that service.

There there’s 200 plus services on AWS. Like I unfortunately have not used all of them, you know, and, and some of the services are crazy to try and use like [00:24:00] you know, ground control. We’ll talk with satellites and stuff, like have not used that one, you know, probably will never, you know, like probably really expensive for me to use that.

So, that’s all that problem there. Your, your question about standardizing though on compliance. I do think so. So there is some standardization you can try and do across all of your different, you know, environments there. But it is also important and valuable to not try to apply a single standard, across everything, because then you’ll end up with your lowest common denominator or you’re going to run into.

One of two problems here, either one, you try and use the most you know, you basically say, well, we need a sandbox account where people can do various things in. And , the same compliance that you use for your sandbox account is not what you want to use in your production account, your production account, you want more locked down.

And so if you try to apply the same you know, standards across both a production account and a sandbox account, either your production account is not going to be as secured as you want, or the sandbox account is going to be more restricted and you’re going to [00:25:00] end up with a shadow it problem where people say, you know, I want to try to, Test out some different things in AWS.

I can’t in my sandbox account because it’s too restricted because you applied all these different compliance standards to me, therefore, I’m going to use my own credit card and spin this up in my own AWS account. And that creates, you know, its own problem there. So neither of those is good. And so you do have to try to break things up, be able to say this, these accounts here, , or some way trying to segment that different standards that you have to be able to say, these things need to adhere to a higher standard.

That’s more restrictive. And then these other things can be less restrictive in order to allow the freedom of people to you know, test out different things, experiment and develop.

Ashish Rajan: That’s awesome. And I love the fact that you touched on the challenges sometimes standard compliance as well, because a lot of times I’ve found a lot of people kind of just go down the path of hardware, standardized security, because that’s the only thing.

For me to control this or control what’s happening. Otherwise it just feels like a wild west for, lack of a better word. . So I’m just gonna [00:26:00] quickly go through the ones that I haven’t acknowledged it. I got a question from Ms at a broader level. What is usually your strategy when you’re invited for building a cloud security roadmap for a company and how important it is to understand the shared responsibility model.

Scott Piper: So I don’t do that. That’s why I created that cloud security roadmap. Cause I didn’t want to do that for companies. So like kind of get it like once and then it was like, yeah, I don’t want to do that again. And so that’s why I’ve released a number of like the things that I have you know, when some of the blog posts and things like that is like , from a business perspective, it would be much smarter for me to, you know, keep some of these things private.

And you basically like, you know copy paste these over and over again for every different engagement, you know? And you basically sell that different advice or sell these different solutions to different companies. I don’t like doing that though. Cause it’s super boring. So that’s why like I will release these things and that’s forces me to continue doing newer.

Yeah. Interesting things. Because now I have like backed myself into a corner where the thing that. [00:27:00] Possible for me to sell. I can no longer sell. Cause I released it open source already, you know, released it to the world in some way. So, I don’t do this for companies but I do provide training to companies though.

And , so in terms of helping them understand the shared responsibility model, that is where I’ll go more into that for companies there. And, I do think it’s important that they understand it because , I do think the way the the name of it, I think is misleading to people, you know, the shared responsibility, like you’re not sharing the responsibility.

It is a split responsibility where some things AWS does and some things you do, like a sharing would mean that AWS would sometimes help you with your security in some ways like, Hey, we noticed, yourEC2 was compromised and they kind of do that, and then they’ll do that for some things sort of, but it’s not.

They’re not watching over you in the same way that you know, I’ve heard some of the other cloud providers will you know, have more visibility into your environment and we’ll look at those things. AWS is much more hands-off in that situation where they do not want to investigate specifically what is happening on host in [00:28:00] your

And so there’s that split responsibility there. likewise, AWS has never going to say like, Hey you know, one of our people couldn’t make the shift to you know, be a security guard at our data center. Would you like mind, like showing up, you know, and just like keeping an eye on things.

Like, again, it is not shared, like, it is a split responsibility where they do their thing and you have to do your thing.

Ashish Rajan: Awesome. Great answer, man. Hopefully the answer to your question, Ms. I’ve got a question from Magna. What advice would you give to someone that is starting to work in cloud security or.

Scott Piper: Yeah. So I provide in my roadmap a list of some of the different resources , that I find are valuable. Some of the different newsletters out there, some of the different some of the different conference videos and these are valuable. I list them as ways of keeping up to date.

But it’s also valuable in terms of helping people to learn what’s going on in these different environments or start learning about AWS security. AWS does have a security, specialization certificate that you can get. And in general, , I guess the view of like certificates, aren’t like super valuable, super important there, but at the same time, like [00:29:00] I recognize that.

It one you know, people are in different places in their career and you know, somebody that is just starting in their career, a certificate is much more valuable for being able to show a possible employer. What you know, , some capability in these different areas. And two, I think certificates are super valuable from the perspective of giving you some type of you know, end goal something to focus on something, to prove that you accomplished you know, whatever it is you did, and to force you to study for it, you know, like you, you have it on your calendar, I’m going to be taking this exam.

I need to study for it, you know, in the same way that people will sign up for marathons or five Ks or whatever else it is like that, you know because it forces you to to do that exercise, in order to run those different races. And similarly it forces you to learn some of the things that, maybe you’re not.

Super interested in, you know, different areas. Like, I mean, I got some of the different APS certificates and learned about services that I’d never would have bothered learning about because it was, I knew it was going to be on the exam. And so I had to [00:30:00] force myself to learn it. And otherwise it just like motivates you to, to focus on that.

So so I do think that some of the, you know, AWS is certificate is valuable from that perspective. And it also helps you identify and define what the learning materials should be, because AWS will tell you here’s, what’s going to be on the exam. And so, you know, here’s, you know, some of the different things you could try and read some of the different white papers or, you know, FAQ’s for the different services.

And so it’s useful from that perspective.

Ashish Rajan: Awesome. Thanks for I, hopefully that answers your question Magno. Thanks for your patience as well, man. I’ve got Hey, Hey Priya. Well, I guess the alarms work that’s her she’s awake. I’ve got a question from Nataraj what’s your view on CSP native security tools versus cloud native security products for consistent approach across multiple cloud platforms.

Scott Piper: So, I’m a big fan of trying to leverage what the different cloud providers provide you. If you try to use a solution that tries to duplicate some of those things, it is usually going to be more expensive for you to try and do that. As an example of that and in some cases you, you [00:31:00] have to leverage the different solutions that the cloud providers provide for you.

So like guard duty, for example, is meant to try to identify you know, incidents or of compromise in your AWS environment in it is given like special access to VPC flow logs to guard duty into your DNS. It has a number of limitations. There’s a number of ways that attackers can avoid being detected by it.

Like guard duty has its problems at the same time, it is the least expensive and most bang for your buck way of getting that type of detection in your AWS environments. And so I think that that is really important is, is recognizing those, those cost perspectives of things. Because if you turn on VPC flow logs, You know, that’s going to incur different costs.

If you try to collect your DNS , information from, your environment that is going to incur an, a cost there. Whereas guard duty is able to access those things in a much less expensive way than if you try to do them on your own. And so from that perspective, there are some cases where [00:32:00] it makes sense to leverage what the CS what the different cloud providers provide to you.

But at the same time , having that consistent view across your different clouds I definitely could see benefit in that. I’ve been lucky enough to not have to worry about any other clouds , that has been why I’ve like hyper specialized in only AWS. So I personally don’t have like, experience using those other tools and seeing how they interact in the different you know, other cloud providers.

So, so I can’t really speak to them too much there unforeseen.

Ashish Rajan: No, but I think I you’ve touched on a good point about the consistency part as well, because would you say if we do go down the use point of using say the cloud native tools, like ,guard duty or if it’s just a security hub as well, there’s the challenge of having a single pane of glass.

I hate using the word single pane of glass, but I can’t think of a better word, where you kind of are creating your own viewpoint into, Hey, this is what my security would look like. If I’m looking across my entire landscape, any comments.

Scott Piper: Yeah. I mean again, it has its limitations, but you know, at the same [00:33:00] time, again, like you, you probably are not lucky enough to have like, you know, experts that focus on each of the different cloud providers individually you know, or some of these different gotchas.

And , having some of those things standardized for you, having a single place that is identifying, you know, your different you know, problems, misconfigurations, things like that, especially across all of your different AWS accounts and aggregating that into a central location for you to look at tons of value there, you know I’m generally of the view that.

I would rather have things standardized in a non-ideal way or, you know potentially even in like a wrong way then have everything, you know, uniquely wrong in its own, you know, different. No, I would rather have it all wrong. Like, so this has come up, for example, in like Terraform modules or something like that, you know where we’re companies will try to create a.

Like a recipe book. I would say something like that, where it’s like, Hey, here’s some standard ways of doing things in our environment. And, from you on the security team, you may not have the ability, knowledge, [00:34:00] skillset , to be able to review all those things properly in the same way.

But it would be better to have those things used across your company. So that once you do have the time to review those different libraries of some sort that you can identify what the problems are in that one library, and hopefully fix them across your entire environment, as opposed to now having to evaluate these different modules or libraries and, across all the different environments that you have.

And then there’s the same problem that comes up in Lido, like application security, where it’s actual code and there’s actual code libraries, you know, or code modules in some way. Like it would be better for you to standardize again in the wrong way you know, or the non, the, maybe. Optimal best way. And have that standardized across everything, in my opinion, then to have just chaos of everybody using, you know, whatever libraries that they’d want to, , across everything, just because when one of those is wrong, like you’re probably never going to be able to find those problems because you just will not have the time to [00:35:00] identify those misconfigurations those coding problems that exist when everything is different and unique and you have a billion snowflakes everywhere.

Ashish Rajan: Yeah. I think that’s a good point because as you’ve mentioned it, I just realized because even the CSP as well, they’re looking at each one of them as a unique thing as well. And that’s too, it’s all a single viewpoint, but as you could, as an individual working in a company, you can choose. I’m just going to look at encryption across.

Okay. And go on just one on the, I just want to know encryption and rest happens in my organization, but as, I don’t think you can do that in a CSP in that easily, it’s just like, well, EC2 is this one super section. And then there is another section for RDS in the other section, like, oh, and oh, actually that’s a good point, man.

I’m going to make a note of that as well in my mind now, but hopefully that answers your question and thanks again for your patience, man. Got a question from Ms. It’s a big. So more, we talk about cloud agnostic, more IC security analysts or engineers relying on ton of vendors for managing security and cloud, which security vendors you recommend or any open source tools that you have personally used.

Also while relying on top of [00:36:00] security vendor, how do we ensure there is no breach happening? Why are these tools? Isn’t it a scary to be dependent on security vendors where enterprise actually fails to build something internally. It’s a mouthful.

Scott Piper: So a lot there. So, so one so I’m not associated with any vendors out there.

And so vendor agnostic, I don’t recommend , any of them specifically in any way in terms of some of the different open source tools that exist out there. They tend to have like specific use cases. So like for, for auditing your different environments, you have something like scout suite, for example, from NCC group Prowler as well.

Both of those tools are really meant though, for a point in time evaluation, they were built, you know, especially like NCC group is a pen testing company. Like they come in once a year, once a quarter, something like that in order to do a point in time investigation of your environment, it is not a tool that was used or built for continuous auditing in your environment.

And so you run into some complications in that way. So I think it’s important to recognize what is the tool built for and use it, you know, for [00:37:00] that specific use case or identify the tools that are meant for the use case that you have there. I’ve used a stream alert as an open-source tool that comes from Airbnb in order to To monitor the events in your environment from CloudTrail and other places stream alert though, it requires a lot of care and feeding a lot of maintenance.

, it is something that does require some investment from the company in order to make sure that it’s running properly. And, that’s honestly true of like every log monitoring solution. Like I do not know of a company out there that has ever run into the situation or has not run into a situation in which they recognize that they have not been monitoring their logs for a period of time.

Like they, some somewhere they’re logging pipeline or alerting pipeline, something broke and they didn’t realize it until, you know, like somehow some other incident happened and they were like, weird. We should’ve gotten an alert about that, it’s been kind of quiet for the past, like week or two, you know, like a , wonder if like, suddenly our developers just got really good and stopped, you know, introducing bugs [00:38:00] and stuff, or, you know, maybe it’s your, you know, monitoring pipeline broke and you’re not receiving those alerts anymore.

So that, that’s a common problem. And so stream alert does require some of that care and feeding there. But, , the concept though I think is valuable to look at. And so what it does is it works in like a serverless way in such that it will spin up Lambdas in order to deal with incoming logging spikes.

And so, as you know, for example, most people, their logs are cyclical where. During the morning when, you know, everybody comes into work, suddenly you get a lot of, you know, login events and things like that. Or if you have some type of you know, a website out there in the world, like there are going to be different times of the day when, you know, a lot of people are accessing it.

And then they’re going to be times in the day when it’s not producing a lot of logs, because it’s just not that busy anymore. And, and so that’s where a server list a logging platform becomes valuable because it can spin up and spin down as more logs come in or there’s quieter periods.

And that’s also valuable when perhaps you’re experiencing [00:39:00] some type of. No denial of service attack or in some other way, there’s some type of logging spike. And if you don’t have something that can spin up a, you know, in order to deal with that spike of traffic or that spike of logs you will oftentimes end up missing that data you know, or you’ll end up having this backlog of data as such that, you get this spike of traffic from you know, we’ll just say denial of service or something like that.

And you know, you have that spike. You’re trying to deal with that. Spike, not aware of any incidents that are happening because your logging monitoring solution is trying to like, you know, basically dig through all that data. And then eventually, you know, maybe a few days later it catches up to things that were actually happening a few days ago, but your, your solution just had this big backlog of events.

And so you end up being, you know, days behind in identifying incidents.

Ashish Rajan: Oh, yeah, that’s the whole real-time detection, also in itself was a big thing as well. So I hope that answered your question, but just want to call out Tony, De La Fuente . We had him [00:40:00] on the show some time ago. I love the fact he named it prowler because prowler was the first song, the first album for iron maiden.

I just thought, tell random fact I’d throw it at you guys, but definitely check out the talk. I’ll try and link it over here as well. Ive got a comment from Priya. I agree. The security road map is a great resource. I have used the roadmap as a conversation starter for AWS security planning with engineers and top level management as well.

So thanks for sharing that, Magno thanks for your patience again, man. So question, what do you think of organization going multicloud instead of staying with one vendor? Doesn’t that bring more complexity and more.

Scott Piper: The concept of multi-cloud like you shouldn’t do it is basically everybody says, but at the same time you’re going to do it because everybody, whether they want to, whether they know I would or not ends up being on multiple cloud providers in some way and this can happen, you know, because maybe GCP or Azure is just better at certain things in different ways.

And so people want to make use of some of the services that are available there or it can happen. Maybe you acquire a company and that company happens to be all in, [00:41:00] on one of the other cloud providers. And it just doesn’t make sense to try to lift and shift everything to AWS or, try and move things in a more intelligent way.

Like just leave it as it is. And so now you’re multi-cloud and , so that, happens so you should try to avoid it, but it’s going to happen ultimately.

Ashish Rajan: Yeah. . Well, the goal was to try it though. We can all try it, like become more security. People are supposed to be the gatekeepers and just go now we’re coming in.

Awesome. I hope that answers your question back note. I’ve got another statement from Ms. I’ll definitely look into security roadmap for AWS. I’ve leveraged the same in. Deployment in past. She that’d be interesting because I imagine the framework you’ve defined in your AWS security roadmap, it’s actually generic enough that you can apply to any of the cloud as well.

I mean, apart from certainly logging specifically. Yeah.

Scott Piper: I mean, there, there are definitely like some very AWS specific things, but like the general concepts like do apply. Like I mentioned, you know, it was one of the first things like you should try to get an inventory of what different, you know, AWS accounts that you have in the same way that you would get an inventory of like what exists in your.

Cloud providers you know, one of the other steps early on is, is getting backups [00:42:00] of things, you know, like for your critical data. And that’s like, especially important nowadays with how common a ransomware is. And also, like there’s been a lot of talk somewhat privately about there having been a number of like scorched earth instance where an attacker gets access to somebody’s AWS account and just deletes everything.

Like doesn’t even, you know, try to ransomware and anything like that, just delete everything. And so yeah, for problems like that, like you want to have backups. And so even though I mentioned in the roadmap, like AWS specific technologies that are useful for your backups the concept of having backups as, you know, universally good thing that you want across any clusters.

Ashish Rajan: Yup. Yup. I think especially anyone who’s been coming from a day of hardware because actually I want to show my age here, but I forgot how important backups were back in the day of non-cloud devices. There was no Dropbox. It was not the thing nowadays. I haven’t, I don’t even see a CD drive in most of the computers coming out and you’ll go.

Cause that’s what it used to be like. Oh, in my backup drives and my backup CDs or backup [00:43:00] floppy, then you go nowadays, I’ll just back up to the cloud. Yeah, I guess there is no that kind of backup, but I guess, that’s that’s thanks for that statement, Ms. I’ve worked Priya has a question curious, what’s your take on AWS audit manager for compliance check?



Scott Piper: I’ve not used it. So see, I know no comment on that, I guess.

Ashish Rajan: All right. So we’ll come back to that one. Priya has a statement as well. I found situations is where least privileged users are using instances used for CICD to do manual changes to the AWS environment, even in production. This makes it harder to build a false positive context of alerts, I guess, or this is a red thread story that we were going with the false positive to come out.

Scott Piper: I mean, that is like a true positive, , you’re identifying like. Something a non approved way of doing CIC CD in your environment and accessing your production environment. Like that is a true positive that you want to try. , it’s unfortunate that like, probably someone’s going to say, well, I have to do this.

And you know, you’re going to run into like those types of you know, just kind of people issues there, you know, where, or you’re going to have a more difficult time trying to stop it and they’ll continue [00:44:00] generating alerts for them. But it is a situation where that will hopefully help you start the conversation with like the engineering team or something like that to say, Hey, you should really prioritize making your CICD environment better so that you don’t have people running them from, you know, random, easy two instances or something like that.

Ashish Rajan: Awesome. Thanks for sharing that Priya , Zinat is our, she likes to split responsibility to the shared responsibility comment. The three thing, Ms. ADA business spectrum database Guard Duty is very good, indeed, and least expensive checks for putting some initial good security checks. Would you agree?

Yeah,

Scott Piper: yeah, definitely. So this is what I was saying before, like guard duty is the least expensive way of getting this, you know, some of that incidents detection set up in your environment. But it it’s going to be lacking and can be bypassed in certain ways. So, you know, ideally you would try to build upon it or, you know, maybe one day try to replace it.

But, but yeah, it’s definitely the easiest first way of trying to get that done.

Ashish Rajan: Awesome. Yeah. Thanks for the comment as Ms . Kris , thanks for much for your patience as well. A question on CSPM plus remediation tools. How [00:45:00] mature do you think the current industry is in terms of finding misconfiguration and resolving them?

Scott Piper: So yeah, it’s a super scary thing, especially if it’s like auto remediation, you know, or if somebody is doing the remediation and doesn’t have the context of the environment or of potentially the knowledge of how it, you know, could potentially break things in that environment. And some of these things are going to be context specific as well.

You know, where you know, somebody may have an S3 bucket, that’s public and somebody decides, oh, I shouldn’t, you know, have that public anymore. But yet that is like, you know, all of these things. Content for your primary website and now your website’s broken, you know? So , like having that context of why things are potentially misconfigured you know, because your, your CSPs never has that context, it tells you, you have a public S3 bucket, public S3 buckets are bad, and you don’t have the context though, that, like, there are architectural decisions that would require you to have that public S3 bucket and historical needs for having that public.

And so there’s always that danger for remediation or especially auto remediation of breaking, you know production environments in some ways. Yeah.

Ashish Rajan: Yeah, [00:46:00] actually, that’s a good point. A lack of context is definitely has come out quite a bit in the past few months about, Auto Remediation was great when it was, oh my God, I can solve it because that’s what cloud is supposed to be.

But the more you start doing it, more people started hitting security for all these false positives as well. So yeah. Cool. Thanks for that. Thanks for the question, Chris. Hopefully we answered, I’ve got a comment from Roxanne Unified Visibility instead of single pane of glass. Oh my God. Thanks Roxanne. Cause I don’t want to use single pane of glass. So unified visibility. It is. I’ve got a question for Priya in your experience doing assessment. What are three top gaps that companies usually.

Scott Piper: Even the basics, , you always find IAM users that like have existed for years and never been removed and they haven’t been used for years. You know, like a number of times I will find an IAM user named after whoever the current CTO of the company is, and he doesn’t touch AWS anymore.

He’s doing like CTO, executive things and not like actually, you know, hands-on coding anymore. And yet there’s this IAM user and access key that hasn’t been used, you know, in three years and still exists [00:47:00] there. You’ll find any type of problems. Exists all over the place for different companies.

In terms of gaps, sometimes I’m like, how did you guys not realize this is a problem? Like, and sometimes they need the external consultant to like, tell the, the CTO, Hey, you have to let go. You know, like you’re no longer, you know, hands-on, you know, actually using these AWS environments anymore, you’re not logging in.

We can prove that you have not logged in in years. Like you need to let go and, you know, get rid of that. Like, it is a security risk. But yeah, can’t really speak to like any specific gaps there. Right.

Ashish Rajan: Awesome. Ive got Roxanne thinking about roles and responsibilities within an organization, how we can share or split roles of security team and the cloud users in tool selection, or managing security incidents.

Neat. Any thoughts on that question?

Scott Piper: This can be become problematic if you do try to split things up too much here, because if you have one team for example, like creating detection rules or, you know, different compliance check rules or setting up those different tools and then another team that’s actually responding to the alerts that get [00:48:00] generated there, then the.

Team has no idea, potentially how much toil and pain they are imposing on the second team. You know? Cause cause oftentimes like when people first run any type of security tool, if it’s a large environment, you suddenly like generate, you know, perhaps like a hundred thousand alerts. And , if you are deploying that tool and you are not the person responding to those alerts, like you have now caused so much pain on somebody else and you don’t even realize it.

And like that’s a bad situation. even trying to read a hundred thousand things is going to take you, you know, like multiple weeks of time. And so you, you can’t do that to somebody. So be cautious if you do try to split up things too much in an organization like that, like be aware of, how those situations can.

Ashish Rajan: Awesome. Ive got acouple more questions from her as well. What is the best way to manage monitoring and logging in cloud ?

Scott Piper: So-so stream alert?

The tool that I mentioned before You know, maybe not specifically that tool, but conceptually how it’s doing some things there is valuable to [00:49:00] look at. And you know, AWS also has a service, they call the , which allows you to query logs that are in S3 bucket. There are some benefits of doing that.

And so you may want to look at that as well as a way of, you know, doing some of those investigations and things. Just because it’ll allow you to sometimes have a, , cost avoidance, if you can leverage that you know, for your situation.

Ashish Rajan: Awesome. I think another one that’s so final one from her security hub versus any scene, what do you think she’ll be getting benefit from using security hub is something like Splunk is also heavily used.

Scott Piper: So I’ve, I’m generally not been a fan of security hub. Again, this is one of, this is one of those like solutions out there, , but again, like it has its place, you know, like it very much so for, for, you know, companies it’s, it’s more point and click setup. It is giving you like a guidance from AWS on what is good and bad there. , it’s one of those things where if you have the bandwidth and ability to start leveraging other things, then you should investigate perhaps looking at other things [00:50:00] beyond security hub, but for companies that don’t have that bandwidth, then it’s a reasonable option.

Ashish Rajan: Awesome. And I think just a spoiler alert for Roxanne. I’ve got someone who does, I think he’s a product manager for AWS security hub coming later this week as well. So great question for him as well to us. So

Scott Piper: one of the situations where , you again, are trying to provide a general solution to everybody and depending on your specific needs, there may be special cases where different solutions just don’t work for everybody.

Ashish Rajan: Awesome. All right. Hopefully that answered your question. Roxanne. Thanks so much for asking them as well. And I’ve got us to the final question for tonight. Priya asking . How do you keep up with AWS announcement and other AWS security related things at the moment? Your Twitter is my go-to for resources for free and love it.

There you go. So how do you do

Scott Piper: this man? So Twitter is my main way. There there’s some accounts on there that I follow that helped me keep up to date with it. Like I personally, I review every SDK commit from AWS. So every for their AWS SDK, I review those commits, then make it into like their, every [00:51:00] single day.

It happens that for me, it’s like 1:00 PM my time. And I just go ahead and look at that and see like what changes were made in order to see what API changes were made and, or to identify sometimes like interesting things that happen there. Otherwise, I would say for other people that aren’t, you know, like as heavily focused on AWS you know, as I am, or, you know, don’t want to invest that time.

Cause it does take a lot of time to, to look at that. There’s a number of good newsletters out there that I think are valuable. And so I mentioned some of those you know, in my roadmap, but those include like Corey Quinn screaming in the cloud, Clint gamblers TLDR and Marco’s cloud sec news.

Ashish Rajan: Yes. I think it’s called Cloud Sec Newsletter definitely great resource from all of them as well. I was going to ask maybe it was like calling out. So for people starting today, How do you, like, I know this is the last question as well, but where did it start? If define, go, oh Scott’s inspired me today.

I’m going to learn AWS security. I’m sure they don’t need to start with CIS benchmark, but where do they start? Or the curiosity, please do drop in about FwdCloudSec

[00:52:00] Scott Piper: yeah. I think , my roadmap hopefully you know, gives them an understanding of a lot of different technologies that they can start digging deeper into.

You know? So , as that roadmap mentions different things, they can start digging into some of those things there. We talked about like getting certificates and helping to focus your education by you know, perhaps getting one of the or security certificates there. But then to your point so forward cloud sec is a conference that that I’m helping to run that is taking place here in salt lake city in September 13th and 14th.

But it is going to be run as hybrid. So we are both streaming it live so anybody can see the talks as they’re happening for free. You don’t have to register anything like that. They’re going to be free. And also we are going to be streaming in some of the speakers as well. Because we recognize there are some world issues right now that make travel difficult for a number of people.

But there are people doing awesome things with AWS security or cloud, sorry, cloud security all over the place. And so there are talks at this conference that are not only about AWS security, but also GCP Azure and some various [00:53:00] other things and things that are adjacent to some of those.

And super excited about that. And I think that we had, we ran it last year. It was all virtual. Those, all those talks are online on YouTube. If you go to fwdcloudsec.org . So that’s spelled FWD cloud sec.org. If you go there, you can it’ll link to last year’s talks and you can check those out.

But yeah, , we’ll be having the talks. Again, we’ll put them up on YouTube a few weeks after the actual conference, but you can watch it live as well. I also in part of the cloud security forum, slack which is a pretty useful slack, I think for, for a lot of people as well. There’s a lot of conversations that happen in there that don’t end up happening on Twitter or elsewhere.

So I think that’s another valuable resource for people to get access to. So you can reach out to me or a number of other people that are involved in cloud security can invite you to that as well.

Ashish Rajan: Awesome. And thanks for sharing that as well. I’ll definitely put links for, FwdCloudSec and the slack channel as well.

I think for me personally, I’ve found the slack channel to be quite helpful as well. So it’s definitely a great resource. I mean, definitely check out the newsletter from [00:54:00] Cloud Sec from Clint Gibbler and Marco and everyone as well, but it is. So I think if you look out for to your point about earlier, I’m going to circle back to the start with why you ended up on AWS security, lower demand, not enough supply.

I feel it’s the same thing with resources as well. Lot of supply from AWS themselves, but not enough curated enough that, oh, why does this really make, I mean, I don’t, I’m not going to use all 200 services as you mentioned, and it’s rare that I’m going to launch like a, a spaceship or whatever the ground satellites in that we have.

So, I mean, I’ll be amazed if I do it, I’ll totally be going for that service, but I don’t see that happening, but in near future, I definitely recommend those. I do. I’m going to appreciate, really appreciate it. I mean, I know we just went over the one hour mark, but I’m good. One last section, it just three questions.

It just just to get to know you a bit and a for folks to get to know you a bit as well. So stop talking about technical things now. So I’ve got three fun questions. What do you spend most time on? Many are not working on cloud or AWS.

Scott Piper: So I try to do woodworking, which is like a, I guess, pretty common amongst tech [00:55:00] folks.

Now, specifically I try to create furniture that doesn’t have any screws or nails in it. Those are advanced technology that I don’t want. So I try to, I try to simplify things as much as possible. So like my bookshelf behind me, like that will hopefully get replaced soon. And I’ll put in my own bookshelf back there.

So I try and do a fair bit of that. And then also I’m going to live out in Utah where like hiking and skiing and cross country skiing and all that is, is super accessible. There’s tons of it out here. There’s places like Moab and Zion national park and you know, all these other national parks. So trying to get out and do those things as much as possible.

Well, there’s going to

Ashish Rajan: be an ad for Utah. Like now people are signing.

Scott Piper: I wanted this fwd cloud sec to happen here in salt lake city. Like everyone else. Oh yeah. Oh

Ashish Rajan: actually. Yeah, no this

Scott Piper: or all the other organizers, like, didn’t want it here. You know, they wanted like some random city and I was like, I was like, okay, first of all, salt lake city is way better than all those other cities.

And second of all, like I live here. It will be so much easier for me to like pick out a hotel and deal with the logistics if we just have it in a city where one of [00:56:00] us happens to live, you know? Yeah.

Ashish Rajan: That’s a good point, man. So this next question that I have is what is something that you’re proud of?

It is not only a social meal.

Scott Piper: I would say, so I’m pretty open about a lot of things, but so weightlifting, I’ve done some of that. And so so specifically power lifting or deadlifts. And so one day I looked up what the like record for dead lifting was for my weight class, for, you know, my age and things like that.

And powerlifting gets like super niche as well, where, you know, like, There a lot of people can win the award, you know, because you can get like very particular on things. But anyway, so I looked up what the dead lift record was because I felt like it was like, I was pretty good at it. And it was five pounds away from what I could deadlift.

And so I started focusing on that and it was like, and was able to to lift beyond that. But unfortunately, like due to COVID, all the competitions were, have been canceled. And so I haven’t had the opportunity to actually compete and get my name in the record books. So that’s, [00:57:00] that’s something that I’m proud of that I can pick up heavy things off the ground and put them back down again.

Ashish Rajan: Yeah. If you would describe it like that, because a friend of mine is doing power lifting or strong, man, I think something like this, look what it looks like a ton weighing the rock, like a ball basically just lifted up or started to all of a sudden. The, I mean, yeah, as you said, lifting something from the ground and putting it, putting it back then, great activity, man.

But I think good luck for the world record. I mean, I think it would be the overall

Scott Piper: state record, not, not the world record only the state record yet. So it’s a

Ashish Rajan: strange record. Oh,

Scott Piper: even it’s not even like the national record. So it’s like, it’s pretty niche, you know, like, and it’s kind of low for what it should be, but I’m still proud of it, you know?

Like, and it, and I get like my name in the record book, they’re like, oh totally, I’m totally going to get like a WWF style, you know, like wrestling belt to wear something like that. Super flashy, you know, just like advertise.

Ashish Rajan: Oh, Magna was saying you can lift AWS servers. Now that totally do that, man. Last question.

What’s your favorite cuisine or restaurant?

Scott Piper: So so Utah has a very good pastry scene [00:58:00] out here. And so so I mentioned this like recently on Twitter the Kouign-amann is like the ideal pastry or it’s, it’s, it’s probably like the sweetest and most buttery is pastry and it’s not very well known though.

But it’s it has a pretty long history out here in out here in salt lake city. Apparently we were like the third place in the U S to create that pastry and like the first place west of the Mississippi to, to sell that pastry. And so originally it started in France. But anyways, so that, that pastry called the kouign-amann is like probably my, one of my favorite things, but it’s, it’s super buttery, super sugary.

So you can only have it like once a year or something like that. Like, it can be pretty overwhelming.

Ashish Rajan: I’m going to definitely find a link for it and put it in the show notes as well. So where can people find you, man? And you’ve already mentioned fwdcloudsec , but where can people find you to connect with you and maybe get some training sessions happening?

Scott Piper: Yeah, so on Twitter so I don’t know if my Twitter handle is still visible there, but so it’s Dabadoo written in hex [00:59:00] characters, so it’s impossible to actually spell out.

Ashish Rajan: I’ll put a link in the show notes as well,

Scott Piper: and then summit route.com is my website for my business. And so you can reach out to me through that. It has my contact information, scott@summitroute.com.

And we’re reach out to me about AWS security training or potentially other AWS security consulting services as well.

Ashish Rajan: Awesome. And I’ve just finally come in from Chris saying it would be a record if you could leave all the books behind Scott as well. So it don’t don’t lift in though. Totally. We are.

You’re seen man. He could be like our security person. It’s lifting, breaking the stage record , That’ll be awesome. Cool. But dude, I enjoyed our conversation so much definitely have you over and we can talk for hours, but thanks so much for doing this, man. I really appreciate this. And I’m looking forward to having you again.

Yeah, will do. All right. for everyone else. I would love a saying we have an AWS security hub product manager coming in, so it would definitely going, and this has made, this is midweek episode, so you’ll probably see that soon, but, again, thanks Scott . And thank you everyone for tuning in.

I will see you next time.