Ashish has over 13+yrs experience in the Cybersecurity industry with the last 7 focusing primarily helping Enterprise with managing security risk at scale in cloud first world and was the CISO of a global Cloud First Tech company in his last role. Ashish is also a keynote speaker and host of the widely poplar Cloud Security Podcast, a SANS trainer for Cloud Security & DevSecOps. Ashish currently works at Snyk as a Principal Cloud Security Advocate. He is a frequent contributor on topics related to public cloud transformation, Cloud Security, DevSecOps, Security Leadership, future Tech and the associated security challenges for practitioners and CISOs.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by our friends at Thinkst Canary. Most folks find out way too late that they’ve been breached. Thinkst Canary changes this. Deploy canaries and canary tokens in minutes, and then forget about them. Attackers tip their hand by touching them, giving you one alert, when it matters. With zero administrative overhead to this and almost no false positives, Canaries are deployed and loved on all seven continents. Check out what people are saying at canary.love today.



Corey: This episode is bought to you in part by our friends at Veeam. Do you care about backups? Of course you don’t. Nobody cares about backups. Stop lying to yourselves! You care about restores, usually right after you didn’t care enough about backups.  If you’re tired of the vulnerabilities, costs and slow recoveries when using snapshots to restore your data, assuming you even have them at all living in AWS-land, there is an alternative for you. Check out Veeam, thats V-E-E-A-M for secure, zero-fuss AWS backup that won't leave you high and dry when it’s time to restore. Stop taking chances with your data. Talk to Veeam. My thanks to them for sponsoring this ridiculous podcast.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. This promoted episode is brought to us once again by our friends at Snyk. Snyk does amazing things in the world of cloud security and terrible things with the English language because, despite raising a whole boatload of money, they still stubbornly refuse to buy a vowel in their name. I’m joined today by Principal Cloud Security Advocate from Snyk, Ashish Rajan. Ashish, thank you for joining me.

Corey: Your history is fascinating to me because you’ve been around for a while on a podcast of your own, the Cloud Security Podcast. But until relatively recently, you were a CISO. As has become relatively accepted in the industry, the primary job of the CISO is to get themselves fired, and then, “Well, great. What’s next?” Well, failing upward is really the way to go wherever possible, so now you are at Snyk, helping the rest of us fix our security. That’s my headcanon on all of that anyway, which I’m sure bears scant, if any, resemblance to reality, what’s your version?

Ashish: [laugh]. Oh, well, fortunately, I wasn’t fired. And I think I definitely find that it’s a great way to look at the CISO job to walk towards the path where you’re no longer required because then I think you’ve definitely done your job. I moved into the media space because we got an opportunity to go full-time. I spoke about this offline, but an incident inspired us to go full-time into the space, so that’s what made me leave my CISO job and go full-time into democratizing cloud security as much as possible for anyone and everyone. So far, every day, almost now, so it’s almost like I dream about cloud security as well now.

Corey: Yeah, I dream of cloud security too, but my dreams are of a better world in which people didn’t tell me how much they really care about security in emails that demonstrate how much they failed to care about security until it was too little too late. I was in security myself for a while and got out of it because I was tired of being miserable all the time. But I feel that there’s a deep spiritual alignment between people who care about cost and people who care about security when it comes to cloud—or business in general—because you can spend infinite money on those things, but it doesn’t really get your business further. It’s like paying for fire insurance. It isn’t going to get you to your next milestone, whereas shipping faster, being more effective at launching a feature into markets, that can multiply revenue. That’s what companies are optimized around. It’s, “Oh, right. We have to do the security stuff,” or, “We have to fix the AWS billing piece.” It feels, on some level, like it’s a backburner project most of the time and it’s certainly invested in that way. What’s your take on that?

Ashish: I tend to disagree with that, for a couple reasons.

Corey: Excellent. I love arguments.

Ashish: I feel this in a healthy way as well. A, I love the analogy of spiritual animals where they are cost optimization as well as the risk aversion as well. I think where I normally stand—and this is what I had to unlearn after doing years of cybersecurity—was that initially, we always used to be—when I say ‘we,’ I mean cybersecurity folks—we always used to be like police officers. Is that every time there’s an incident, it turns into a crime scene, and suddenly we’re all like, “Pew, pew, pew,” with trying to get all the evidence together, let’s make this isolated as much—as isolated as possible from the rest of the environment, and let’s try and resolve this.

I feel like in Cloud has asked people to become more collaborative, which is a good problem to have. It also encourages that, I don’t know how many people know this, but the reason we have brakes in our cars is not because we can slow down the car; it’s so that we can go faster. And I feel security is the same thing. The guardrails we talk about, the risks that you’re trying to avert, the reason you’re trying to have security is not to slow down but to go faster. Say for example in an ideal world, to quote what you were saying earlier if we were to do the right kind of encryption—I’m just going to use the most basic example—if we just do encryption, right, and just ensure that as a guardrail, the entire company needs to have encryption at rest, encryption in transit, period, nothing else, no one cares about anything else.

But if you just lay that out as a framework and this is our guardrail, no one brakes this, and whoever does, hey we—you know, slap on the wrist and come back on to the actual track, but keep going forward. That just means any project that comes in that meets [unintelligible 00:04:58] criteria. Keeps going forward, as many times we want to go into production. Doesn’t matter. So, that is the new world of security that we are being asked to move towards where Amazon re:Invent is coming in, there will be another, I don’t know, three, four hundred services that will be released. How many people, irrespective of security, would actually know all of those services? They would not. So, [crosstalk 00:05:20]—

Corey: Oh, we’ve long since passed the point where I can convincingly talk about AWS services that don’t really exist and not get called out on it by Amazon employees. No one keeps them on their head. Except me because I’m sad.

Ashish: Oh, no, but I think you’re right, though. I can’t remember who was it—maybe Andrew Vogel or someone—they didn’t release a service which didn’t exist, and became, like, a thing on Twitter. Everyone—

Corey: Ah, AWS’s Infinidash. I want to say that was Joe Nash out of Twilio at the time. I don’t recall offhand if I’m right on that, but that’s how it feels. Yeah, it was certainly not me. People said that was my idea. Nope, nope, I just basically amplified it to a huge audience.

But yeah, it was a brilliant idea, just because it’s a fake service so everyone could tell stories about it. And amazing product feedback, if you look at it through the right lens of how people view your company and your releases when they get this perfect, platonic ideal of what it is you might put out there, what do people say about it?

Ashish: Yeah. I think that’s to your point, I will use that as an example as well to talk about things that there will always be a service which we will be told about for the first time, which we will not know. So, going back to the unlearning part, as a security team, we just have to understand that we can’t use the old ways of, hey, I want to have all the controls possible, cover all there is possible. I need to have a better understanding of all the cloud services because I’ve done, I don’t know, 15 years of cloud, there is no one that has 10, 15 years of cloud unless you’re I don’t know someone from Amazon employee yourself. Most people these days still have five to six years experience and they’re still learning.

Even the cloud engineering folks or the DevOps folks, they’re all still learning and the tooling is continuing to evolve. So yeah, I think I definitely find that the security in this cloud world a lot more collaborative and it’s being looked at as the same function as a brake would have in car: to help you go faster, not to just slam the brake every time it’s like, oh, my God, is the situation isolated and to police people.

Corey: One of the points I find that is so aligned between security and cost—and you alluded to it a minute ago—is the idea of helping companies go faster safely. To that end, guardrails have to be at least as easy as just going off and doing it cow-person style. Because if it’s not, it’s more work in any way, shape, or form, people won’t do it. People will not tag their resources by hand, people will not go through and use the dedicated account structure you’ve got that gets in their way and screams at them every time they try to use one of the native features built into the platform. It has to get out of their way and make things easier, not worse, or people fight it, they go around it, and you’re never going to get buy-in.

Ashish: Do you feel like cost is something that a lot more people pay a lot more attention to because, you know, that creeps into your budget? Like, as people who’ve been leaders before, and this was the conversation, they would just go, “Well, I only have, I don’t know, 100,000 to spend this quarter,” or, “This year,” and they are the ones who—are some of them, I remember—I used to have this manager, once, a CTO would always be conscious about the spend. It’s almost like if you overspend, where do you get the money from? There’s no money to bring in extra. Like, no. There’s a set money that people plan for any year for a budget. And to your point about if you’re not keeping an eye on how are we spending this in the AWS context because very easy to spend the entire money in one day, or in the cloud context. So, I wonder if that is also a big driver for people to feel costs above security? Where do you stand on that?

Corey: When it comes to cost, one of the nice things about it—and this is going to sound sarcastic, but I swear to you it’s not—it’s only money.

Ashish: Mmm.

Corey: Think about that for a second because it’s true. Okay, we wound up screwing up and misconfiguring something and overspending. Well, there are ways around that. You can call AWS, you can get credits, you can get concessions made for mistakes, you can sign larger contracts and get a big pile of proof of concept credit et cetera, et cetera. There are ways to make that up, whereas with security, it’s there are no do-overs on security breaches.

Ashish: No, that’s a good point. I mean, you can always get more money, use a credit card, worst case scenario, but you can’t do the same for—there’s a security breach and suddenly now—hopefully, you don’t have to call New York Times and say, “Can you undo that article that you just have posted that told you it was a mistake. We rewinded what we did.”

Corey: I’m curious to know what your take is these days on the state of the cloud security community. And the reason I bring that up is, well, I started about a year-and-a-half ago now doing a podcast every Thursday. Which is Last Week in AWS: Security Edition because everything else I found in the industry that when I went looking was aimed explicitly at either—driven by the InfoSec community, which is toxic and a whole bunch of assumed knowledge already built in that looks an awful lot like gatekeeping, which is the reason I got out of InfoSec in the first place, or alternately was completely vendor-captured, where, okay, great, we’re going to go ahead and do a whole bunch of interesting content and it’s all brought to you by this company and strangely, all of the content is directly align with doing some pretty weird things that you wouldn’t do unless you’re trying to build a business case for that company’s product. And it just feels hopelessly compromised. I wanted to find something that was aimed at people who had to care about security but didn’t have security as part of their job title. Think DevOps types and you’re getting warmer.

That’s what I wound up setting out to build. And when all was said and done, I wasn’t super thrilled with, honestly, how alone it still felt. You’ve been doing this for a while, and you’re doing a great job at it, don’t get me wrong, but there is the question that—and I understand they’re sponsoring this episode, but the nice thing about promoted guest episodes is that they can buy my attention, not my opinion. How do you retain creative control of your podcast while working for a security vendor?

Ashish: So, that’s a good question. So, Snyk by themselves have not ever asked us to change any piece of content; we have been working with them for the past few months now. The reason we kind of came along with Snyk was the alignment. And we were talking about this earlier for I totally believe that DevSecOps and cloud security are ultimately going to come together one day. That may not be today, that may not be tomorrow, that may not be in 2022, or maybe 2023, but there will be a future where these two will sit together.

And the developer-first security mentality that they had, in this context from cloud prospective—developers being the cloud engineers, the DevOps people as you called out, the reason you went in that direction, I definitely want to work with them. And ultimately, there would never be enough people in security to solve the problem. That is the harsh reality. There would never be enough people. So, whether it’s cloud security or not, like, for people who were at AWS re:Inforce, the first 15 minutes by Steve Schmidt, CSO of Amazon, was get a security guardian program.

So, I’ve been talking about it, everyone else is talking about right now, Amazon has become the first CSP to even talk about this publicly as well that we should have security guardians. Which by the way, I don’t know why, but you can still call it—it is technically DevSecOps what you’re trying to do—they spoke about a security champion program as part of the keynote that they were running. Nothing to do with cloud security, but the idea being how much of this workload can we share? We can raise, as a security team—for people who may be from a security background listening to this—how much elevation can we provide the risk in front of the right people who are a decision-maker? That is our role.

We help them with the governance, we help with managing it, but we don’t know how to solve the risk or close off a risk, or close off a vulnerability because you might be the best person because you work in that application every day, every—you know the bandages that are put in, you know all the holes that are there, so the best threat model can be performed by the person who works on a day-to-day, not a security person who spent, like, an hour with you once a week because that’s the only time they could manage. So, going back to the Snyk part, that’s the mission that we’ve had with the podcast; we want to democratize cloud security and build a community around neutral information. There is no biased information. And I agree with what you said as well, where a lot of the podcasts outside of what we were finding was more focused on, “Hey, this is how you use AWS. This is how you use Azure. This is how you use GCP.”

But none of them were unbiased in the opinion. Because real life, let’s just say even if I use the AWS example—because we are coming close to the AWS re:Invent—they don’t have all the answers from a security perspective. They don’t have all the answers from an infrastructure perspective or cloud-native perspective. So, there are some times—or even most times—people are making a call where they’re going outside of it. So, unbiased information is definitely required and it is not there enough.

So, I’m glad that at least people like yourself are joining, and you know, creating the world where more people are trying to be relatable to DevOps people as well as the security folks. Because it’s hard for a security person to be a developer, but it’s easy for a developer or an engineer to understand security. And the simplest example I use is when people walk out of their house, they lock the door. They’re already doing security. This is the same thing we’re asking when we talk about security in the cloud or in the [unintelligible 00:14:49] as well. Everyone is, it just it hasn’t been pointed out in the right way.

Corey: I’m curious as to what it is that gets you up in the morning. Now, I know you work in security, but you’re also not a CISO anymore, so I’m not asking what gets you up at 2 a.m. because we know what happens in the security space, then. There’s a reason that my area of business focus is strictly a business hours problem. But I’d love to know what it is about cloud security as a whole that gets you excited.

Ashish: I think it’s an opportunity for people to get into the space without the—you know, you said gatekeeper earlier, those gatekeepers who used to have that 25 years experience in cybersecurity, 15 years experience in cybersecurity, Cloud has challenged that norm. Now, none of that experience helps you do AWS services better. It definitely helps you with the foundational pieces, definitely helps you do identity, networking, all of that, but you still have to learn something completely new, a new way of working, which allows for a lot of people who earlier was struggling to get into cybersecurity, now they have an opening. That’s what excites me about cloud security, that it has opened up a door which is beyond your CCNA, CISSP, and whatever else certification that people want to get. By the way, I don’t have a CISSP, so I can totally throw CISSP under the bus.

But I definitely find that cloud security excites me every morning because it has shown me light where, to what you said, it was always a gated community. Although that’s a very huge generalization. There’s a lot of nice people in cybersecurity who want to mentor and help people get in. But Cloud security has pushed through that door, made it even wider than it was before.

Corey: I think there’s a lot to be said for the concept of sending the elevator back down. I really have remarkably little patience for people who take the perspective of, “Well, I got mine so screw everyone else.” The next generation should have it easier than we did, figuring out where we land in the ecosystem, where we live in the space. And there are folks who do a tremendous job of this, but there are also areas where I think there is significant need for improvement. I’m curious to know what you see as lacking in the community ecosystem for folks who are just dipping their toes into the water of cloud security.

Ashish: I think that one, there’s misinformation as well. The first one being, if you have never done IT before you can get into cloud security, and you know, you will do a great job. I think that is definitely a mistake to just accept the fact if Amazon re:Invent tells you do all these certifications, or Azure does the same, or GCP does the same. If I’ll be really honest—and I feel like I can be honest, this is a safe space—that for people who are listening in, if you’re coming to the space for the first time, whether it’s cloud or cloud security, if you haven’t had much exposure to the foundational pieces of it, it would be a really hard call. You would know all the AWS services, you will know all the Azure services because you have your certification, but if I was to ask you, “Hey, help me build an application. What would be the architecture look like so it can scale?”

“So, right now we are a small pizza-size ten-people team”—I’m going to use the Amazon term there—“But we want to grow into a Facebook tomorrow, so please build me an architecture that can scale.” And if you regurgitate what Amazon has told you, or Azure has told you, or GCP has told you, I can definitely see that you would struggle in the industry because that’s not how, say every application is built. Because the cloud service provider would ask you to drink the Kool-Aid and say they can solve all your problems, even though they don’t have all the servers in the world. So, that’s the first misinformation.

The other one too, for people who are transitioning, who used to be in IT or in cybersecurity and trying to get into the cloud security space, the challenge over there is that outside of Amazon, Google, and Microsoft, there is not a lot of formal education which is unbiased. It is a great way to learn AWS security on how amazing AWS is from AWS people, the same way Microsoft will be [unintelligible 00:19:10], however, when it comes down to actual formal education, like the kind that you and I are trying to provide through a podcast, me with the Cloud Security Podcast, you with Last Week in AWS in the Security Edition, that kind of unbiased formal education, like free education, like what you and I are doing does definitely exist and I guess I’m glad we have company, that you and I both exist in this space, but formal education is very limited. It’s always behind, say an expensive paid wall sometimes, and rightly so because it’s information that would be helpful. So yeah, those two things.

 Corey: This episode is sponsored in part by our friends at Uptycs. Attackers don’t think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That’s U-P-T-Y-C-S.com. 

Corey: One of the problems that I have with the way a lot of cloud security stuff is situated is that you need to have something running to care about the security of. Yeah, I can spin up a VM in the free tier of most of these environments, and okay, “How do I secure a single Linux box?” Okay, yes, there are a lot of things you can learn there, but it’s very far from a holistic point of view. You need to have the infrastructure running at reasonable scale first, in order to really get an effective lab that isn’t contrived.

Now, Snyk is a security company. I absolutely understand and have no problem with the fact that you charge your customers money in order to get security outcomes that are better than they would have otherwise. I do not get why AWS and GCP charge extra for security. And I really don’t get why Azure charges extra for security and then doesn’t deliver security by dropping the ball on it, which is neither here nor there.

Ashish: [laugh].

Corey: It feels like there’s an economic form of gatekeeping, where you must spend at least this much money—or work for someone who does—in order to get exposure to security the way that grownups think about it. Because otherwise, all right, I hit my own web server, I have ten lines in the logs. Now, how do I wind up doing an analysis run to figure out what happened? I pull it up on my screen and I look at it. You need a point of scale before anything that the modern world revolves around doesn’t seem ludicrous.

Ashish: That’s a good point. Also because we don’t talk about the responsibility that the cloud service provider has themselves for security, like the encryption example that I used earlier, as a guardrail, it doesn’t take much for them to enable by default. But how many do that by default? I feel foolish sometimes to tell people that, “Hey, you should have encryption enabled on your storage which is addressed, or in transit.”

It should be—like, we have services like Let’s Encrypt and other services, which are trying to make this easily available to everyone so everyone can do SSL or HTTPS. And also, same goes for encryption. It’s free and given the choice that you can go customer-based keys or your own key or whatever, but it should be something that should be default. We don’t have to remind people, especially if you’re the providers of the service. I agree with you on the, you know, very basic principle of why do I pay extra for security, when you should have already covered this for me as part of the service.

Because hey, technically, aren’t you also responsible in this conversation? But the way I see shared responsibility is that—someone on the podcast mentioned it and I think it’s true—shared responsibility means no one’s responsible. And this is the kind of world we’re living in because of that.

Corey: Shared responsibility has always been an odd concept to me because AWS is where I first encountered it and they, from my perspective, turn what fits into a tweet into a 45-minute dog-and-pony show around, “Ah, this is how it works. This is the part we’re responsible for. This is the part where the customer responsibility is. Now, let’s have a mind-numbingly boring conversation around it.” Whereas, yeah, there’s a compression algorithm here. Basically, if the cloud gets breached, it is overwhelmingly likely that you misconfigured something on your end, not the provider doing it, unless it’s Azure, which is neither here nor there, once again.

The problem with that modeling, once you get a little bit more business sophistication than I had the first time I made the observation, is that you can’t sit down with a CISO at a company that just suffered a data breach and have your conversation be, “Doesn’t it suck to be you—[singing] duh, duh—because you messed up. That’s it.” You need that dog-and-pony show of being able to go in-depth and nuance because otherwise, you’re basically calling out your customer, which you can’t really do. Which I feel occludes a lot of clarity for folks who are not in that position who want to understand these things a bit better.

Ashish: You’re right, Corey. I think definitely I don’t want to be in a place where we’re definitely just educating people on this, but I also want to call out that we are in a world where it is true that Amazon, Azure, Google Cloud, they all have vulnerabilities as well. Thanks to research by all these amazing people on the internet from different companies out there, they’ve identified that, hey, these are not pristine environments that you can go into. Azure, AWS, Google Cloud, they themselves have vulnerabilities, and sometimes some of those vulnerabilities cannot be fixed until the customer intervenes and upgrades their services. We do live in a world where there is not enough education about this as well, so I’m glad you brought this up because for people who are listening in, I mean, I was one of those people who would always say, “When was the last time you heard Amazon had a breach?” Or, “Microsoft had a breach?” Or, “Google Cloud had a breach?”

That was the idea when people were just buying into the concept of cloud and did not trust cloud. Every cybersecurity person that I would talk to they’re like, “Why would you trust cloud? Doesn’t make sense.” But this is, like, seven, eight years ago. Fast-forward to today, it’s almost default, “Why would you not go into cloud?”

So, for people who tend to forget that part, I guess, there is definitely a journey that people came through. With the same example of multi-factor authentication, it was never a, “Hey, let’s enable password and multi-factor authentication.” It took a few stages to get there. Same with this as well. We’re at that stage where now cloud service providers are showing the kinks in the armor, and now people are questioning, “I should update my risk matrix for what if there’s actually a breach in AWS?”

Now, Capital One is a great example where the Amazon employee who was sentenced, she did something which has—never even [unintelligible 00:25:32] on before, opened up the door for that [unintelligible 00:25:36] CISO being potentially sentenced. There was another one. Because it became more primetime news, now people are starting to understand, oh, wait. This is not the same as it used to be. Cloud security breaches have evolved as well.

And just sticking to the Uber point, when Uber has that recent breach where they were talking about, “Hey, so many data records were gone,” what a lot of people did not talk about in that same message, it also mentioned the fact that, hey, they also got access to the AWS console of Uber. Now, that to me, is my risk metrics has already gone higher than where it was before because it just not your data, but potentially your production, your pre-prod, any development work that you were doing for, I don’t know, self-driving cars or whatever that Uber [unintelligible 00:26:18] is doing, all that is out on the internet. But who was talking about all of that? That’s a much worse a breach than what was portrayed on the internet. I don’t know, what do you think?

Corey: When it comes to trusting providers, where I sit is that I think, given their scale, they need to be a lot more transparent than they have been historically. However, I also believe that if you do not trust that these companies are telling you the truth about what they’re doing, how they’re doing it, what their controls are, then you should not be using them as a customer, full stop. This idea of confidential computing drives me nuts because so much of it is, “Well, what if we assume our cloud provider is lying to us about all of these things?” Like, hypothetically there’s nothing stopping them from building an exact clone of their entire control plane that they redirect your request to that do something completely different under the hood. “Oh, yeah, of course, we’re encrypting it with that special KMS key.” No, they’re not. For, “Yeah, sure we’re going to put that into this region.” Nope, it goes right back to Virginia. If you believe that’s what’s going on and that they’re willing to do that, you can’t be in cloud.

Ashish: Yeah, a hundred percent. I think foundational trust need to exist and I don’t think the cloud service providers themselves do a great job of building that trust. And maybe that’s where the drift comes in because the business has decided they’re going to cloud. The cyber security people are trying to be more aware and asking the question, “Hey, why do we trust it so blindly? I don’t have a pen test report from Amazon saying they have tested service.”

Yes, I do have a certificate saying it’s PCI compliant, but how do I know—to what you said—they haven’t cloned our services? Fortunately, businesses are getting smarter. Like, Walmart would never have their resources in AWS because they don’t trust them. It’s a business risk if suddenly they decide to go into that space. But the other way around, Microsoft may decides tomorrow that they want to start their own Walmart. Then what do you do?

So, I don’t know how many people actually consider that as a real business risk, especially because there’s a word that was floating around the internet called supercloud. And the idea behind this was—oh, I can already see your reaction [laugh].

Corey: Yeah, don’t get me started on that whole mess.

Ashish: [laugh]. Oh no, I’m the same. I’m like, “What? What now?” Like, “What are you—” So, one thing I took away which I thought was still valuable was the fact that if you look at the cloud service providers, they’re all like octopus, they all have tentacles everywhere.

Like, if you look at the Amazon of the world, they not only a bookstore, they have a grocery store, they have delivery service. So, they are into a lot of industries, the same way Google Cloud, Microsoft, they’re all in multiple industries. And they can still have enough money to choose to go into an industry that they had never been into before because of the access that they would get with all this information that they have, potentially—assuming that they [unintelligible 00:29:14] information. Now, “Shared responsibility,” quote-unquote, they should not do it, but there is nothing stopping them from actually starting a Walmart tomorrow if they wanted to.

Corey: So, because a podcast and a day job aren’t enough, what are you going to be doing in the near future given that, as we record this, re:Invent is nigh?

Ashish: Yeah. So, podcasting and being in the YouTube space has definitely opened up the creative mindset for me. And I think for my producer as well. We’re doing all these exciting projects. We have something called Cloud Security Villains that is coming up for AWS re:Invent, and it’s going to be released on our YouTube channel as well as my social media.

And we’ll have merchandise for it across the re:Invent as well. And I’m just super excited about the possibility that media as a space provides for everyone. So, for people who are listening in and thinking that, I don’t know, I don’t want to write for a blog or email newsletter or whatever the thing may be, I just want to put it out there that I used to be excited about AWS re:Invent just to understand, hey, hopefully, they will release a new security service. Now, I get excited about these events because I get to meet community, help them, share what they have learned on the internet, and sound smarter [laugh] as a result of that as well, and get interviewed where people like yourself. But I definitely find that at the moment with AWS re:Invent coming in, a couple of things that are exciting for me is the release of the Cloud Security Villains, which I think would be an exciting project, especially—hint, hint—for people who are into comic books, you will definitely enjoy it, and I think your kids will as well. So, just in time for Christmas.

Corey: We will definitely keep an eye out for that and put a link to that in the show notes. I really want to thank you for being so generous with your time. If people want to learn more about what you’re up to, where’s the best place for them to find you?

Ashish: I think I’m fortunate enough to be at that stage where normally if people Google me—and it’s simply Ashish Rajan—they will definitely find me [laugh]. I’ll be really hard for them not find me on the internet. But if you are looking for a source of unbiased cloud security knowledge, you can definitely hit up cloudsecuritypodcast.tv or our YouTube and LinkedIn channel.

We go live stream every week with a new guest talking about cloud security, which could be companies like LinkedIn, Twilio, to name a few that have come on the show already, and a lot more than have come in and been generous with their time and shared how they do what they do. And we’re fortunate that we get ranked top 100 in America, US, UK, as well as Australia. I’m really fortunate for that. So, we’re doing something right, so hopefully, you get some value out of it as well when you come and find me.

Corey: And we will, of course, put links to all of that in the show notes. Thank you so much for being so generous with your time. I really appreciate it.

Ashish: Thank you, Corey, for having me. I really appreciate this a lot. I enjoyed the conversation.

Corey: As did I. Ashish Rajan, Principal Cloud Security Advocate at Snyk who is sponsoring this promoted guest episode. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment pointing out that not every CISO gets fired; some of them successfully manage to blame the intern.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.