10 Jul 2023 · 31 min
Rick Doten, VP of Infosecurity at Centene, talks cloud risk using three metaphors: tigers (real threats), paper tigers (overhyped), and elephants (ignored systemic risks). Human error causes most cloud incidents. Five fundamental controls matter most: asset inventory, data protection, configuration management, vulnerability management, and identity management.
Chapters
Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, and Anton Chuvakin, a Reformed Analyst and Senior Staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with your hosts and the rest of our Cloud Security Podcast listeners on LinkedIn. Today, listeners, another special episode that we did first as a video livestream. If you'd like to see the future video livestreams, please do follow the show and get all the posts when we have those coming up. You can also find this episode on YouTube preserved for posterity's sake. Anton, this was, I thought, an especially fun episode because, well, for 3 things. First, we had a guest who differentiated risk and emotional perception of risk. And I thought that was a pretty emotionally perceptive thing for a CISO to do.
Correct. The guest also struck me as somebody who is a really solid CISO who is also very at peace with the cloud.
Yes.
He isn't the cloud paranoid. We never asked him whether he's a rabid cloud fan, but my impression is that he embraces the cloud. He's okay with that. And to me, this is a very healthy attitude. I think that he operationalized it clearly. He deals with challenges and he uses the advantages. So to me, this was very almost a non-event approach, but it makes it good.
I think that's really true. He had a couple of other things that stood out to me beyond that, which is 2 things to cite. One, he had a really strong opinion about who should make business decisions and what things were business decisions versus technical decisions. And I think often security people lose that nuance and get hung up about that. And then finally, listeners, and this comes at the very end, so you're gonna have to stick around for it, he cited, I think, one of the most interesting answers to our question of what's the most important skill when hiring cloud security people. So, with that teaser, let's turn things over to Anton. Today's guest. Today, we're joined by Rick Doten, VP of Infosecurity at Centene. Rick, thank you so much for joining us today. We are delighted to have you. I think I have the pleasure of asking the first question, which means we're going to get right into it. I want to ask you to talk about realistic cloud risks, and I want to suggest a format for this that an old PM manager of mine, Shreyas, like to use. I want to talk about 3 categories of risk. We've got tigers, things that will actually kill you, paper tigers, things that look scary but aren't, and then elephants, things that nobody wants to talk about, but we should probably acknowledge that they're in the room before they step on us.
Yep. Oh, that's a really great way of putting it, and I appreciate the opportunity to be able to speak with you all. I'll start with the elephants first, really, because the elephants are kind of the fact that there might be infrastructure that goes down. 13 years ago, I was on the board of the Open Data Center Alliance. And the Open Data Center Alliance in 2010, our biggest concern was cloud platforms going away. There was some cloud instance in Europe that was being used by the Russian Business Network, and Interpol takes it down, and all your stuff is gone. And so there is a possibility that because all of your stuff is on somebody else's infrastructure, if something happens to that, then it goes away. That's kind of like the elephant that we don't wanna talk about because risk is risk, whether it's a tornado, a hurricane, an earthquake, or whatever. Business continuity now and then. I would say from the tiger, tiger that's really getting you is human error.
Hmm.
Because, you know, I'm very active in the Cloud Security Alliance. You know, they have a lot of great resources. On the board of our local chapter here in Charlotte. And we've released last year the 11 top cloud security risks, similar to like the OWASP Top 10, but we came up with 11 'cause I don't know, maybe they like prime numbers better.
A baker's 10.
Yes. If you look at them, most of them are related to human error, releasing, using poor secrets or having the secrets disclosed publicly, not having good configuration, not keeping things patched, not having proper controls, having too many privileges. All of these are our fault as humans. They're not the fault of the infrastructure, of the owner of the infrastructure, the The fact that you have a shared service model in cloud security, that's the fundamental that is about cloud, is that there's a shared service model, whether it's infrastructure as a service platform or software as a service. And that would gauge how much they're in charge and how much you're in charge. So it is not as much as the real tiger that's getting you is your own mistakes or errors or lack of keeping up with things.
Uh-huh.
The paper tiger that I think that everyone worries about is this multi-tenancy and this shared responsibility model that is like, well, if they have all these other customers that may be my competitors, maybe there's a thing that they can— it's like, no.
But the cross-tenant bounds are real, though, in some providers, maybe less so here at Google. But you read in the news— yes, I know, Tim. I know why you're smiling. I mean, they're real everywhere, but they are more common in some other places. And I don't mean the business risk, but kind of cross-tenant bounds when one tenant sees what another tenant is doing. I mean, they're not super top of the list, but they're on the list, right?
We need to understand that here in the US, we keep just rattling off Azure, AWS, GCP. But then at the same level is Alibaba and Oracle. And then there's 50 others across the US and the world that are kind of less focused on the kinds of things that we're working on. Is it possible? Yes. Is it likely? It is a lot less likely that that happens than you using a poor credential or you releasing your credentials and your stuff. More likely to happen. We need to focus on the thing that's likely to happen, the tiger that's sitting there waiting to crouch and jump on us.
Okay.
That actually makes total sense. So, we kind of went through some tigers, paper tigers, elephants. Let me try to kind of transport us to the world where people still believe that cloud is this creaky, risky thing, and they have some really— it's not even a paper tiger. It's almost like a toy paper tiger. I don't know. There are still people who think they can host exchange better themselves than its vendor or something. I don't mean to pick an exchange, even though, of course, we're all kind of picking an exchange here and there, but just genuinely people who believe they can run services better than cloud providers. What do you tell them? We can scream that these people are silly, But there's no point. These people exist, and they insist. So what do you tell them as CISO with a great track record in the cloud?
It's really about the difference between risk and security. And for years, when I used to do presentations, I'd talk about that risk is the calculation of the likelihood times impact, right? And security is an— and that's a calculation. And we have quantitative risk analysis that come up and tell you, you know, there is a likelihood of this type of event that will have this kind of impact. Security is an emotion. And that's the, you know, technically the definition is freedom from fear or anxiety. And so we're talking about the difference between your fear of the unknown and the things that are out of your control, which is an emotional reaction, but it's not a risk reaction. Because if you look at it, and this happened when I was a virtual CISO 8 years ago, and I had a big conglomerate in Mexico that I was working with, and they're like, oh, we wanna move our Exchange server, and we, you know, we're gonna have to sign off this stuff from Microsoft, and they're not gonna let us know if there's a, you know, all this stuff. And I'm like, listen, your Exchange server goes down like 2 or 3 times a month. It is flaky, it's out of date, it needs to be patched. You only have 2 people responsible for it. Offload that to somebody who has, you know, it's like the quickest way to get the upgrade to the latest version is just go do it as a service. And this is not just, you know, we're talking Exchange, but this is for everything, right? Anything that's a software as a service option, that is a much better option unless you have the staff who are experts at doing this. Even moving over to Google Mail is the same type of thing. It's like, hey, I could host, I don't know, is Finmail still around on Solaris? Anyway, and move that to Gmail, a lot better infrastructure. So it's about talking them down from the ledge of, are you insecure because you don't understand it, as opposed to, let's look at the reality of the likelihood, the impact, and the efforts that you need to maintain it to keep it stable, because resiliency is just as important a part of security as protection of data.
So I think there's a really interesting argument in all of that around expertise and learning cycles and delegating to people who are experts. Where does that argument stop? Like, is there a limit to where we should delegate security expertise to somebody else or operational expertise? Because I buy it, but I'm wondering what the limit is.
Yeah, no, all risk— it's so— it's a business decision. All risk can be accepted, mitigated, or transferred. CISOs are more like general counsels than we like to admit in that we provide the input, we provide the options, We provide the data on, here's the likelihood and here's the impact of it happening. The business needs to take the decision. Technical people don't make business decisions. And so whether or not they feel— whether or not we go to some software as a service over something we're doing internally is a business decision. It's my responsibility to say, this is the improvements we're going to get. This is the likelihood of something not happening because of doing that, or likelihood it will when you do. And then they can make the decision to choose to or not. So That transferring of that risk to a third party, as well as, and you're talking about like experts, the challenge, you know, it's a whole other, at RSA for the Cloud Security Alliance Summit on Monday, I was on the opening keynote panel where we talked about workforce development, talked about the right people. The reality is most of the cloud people and organizations are refugees from network or network security applications or infrastructure or other things that they kind of moved right into the cloud because that's a new thing and they have an interest in doing that. Yes.
Cloud immigrants or at worst, cloud tourists. I think we've been trying to use the term a few times. Exactly.
And now we've got cloud refugees to add to the mix. It's great.
Yeah. And so, it's very, very hard to find someone who has been doing it for 10 years because they happen to be some company that is native for 10 years, and they've worked on all this thing. And they're very expensive and very hard to find. Everyone wants them. So, the reality is the business decision, whether or not I have the resources and the effort and expertise to be able to maintain the security, the resiliency, and everything I need to make my business run, or whether it's a better business decision to offload it to somebody who has that expertise inherent.
Okay. I really like this answer. I wanna transition to a more technical question from here, which is talking about how do we reason with people who want to copy and paste their on-prem security approach to the cloud? How do we help these people?
You know, can I have a short rant?
Yeah, please.
Very short.
Go ahead.
A very short one. It's crazy sometimes when people show up and say, IDS, NDR, SIEM, log analysis, antivirus, load it up into a VM, shove it into the cloud, I'm secure.
So how do we help?
It's like hair pulling.
Yeah, but Anton, they were right for 30 years with that, and now they're not. So how do we help them appreciate that?
Right. It's funny because in the Cloud Security Alliance circles, we talk about how a lot of times people say exactly what you say, Anton, and we're like, Yeah, that's not how it works. And I was like, that's the future. That's not how it works. It was like, oh, I need an IDS for the cloud and the SIEM tool for it. I was like, that's not how it works. So Tim, the reality is that some people, it's kind of like their first step, right? Is like, I'm going to forklift what I have in a data center into virtual machines in the cloud. And then all the stack that they're comfortable with, like Anton said, is going to remain there and they feel better. Again, security versus risk. They feel secure because it's something they're safe with.
So it's a fancy security theater. It's a fancy form of security theater, essentially.
Yeah, I don't know if it's theater or comfort theater.
No, it's comfort. You know, there are people who I like to— when I was a virtual CISO, I ran into folks all the time who were stuck in suspended animation or arrested development. They were comfortable with how the architecture looked in 2013 or 2015. And that's how they were comfortable with that, with proprietary platforms and everything. And what you just described, is the same thing, is I may take it into a proprietary virtualization platform that I feel comfortable with, that still feels like persistent servers to me, and I'm comfortable with that. But it's not taking advantage of all of the benefits of the cloud and the elasticity and the on-demand and the, you know, self-provisioning and all the things that the cloud offers with temporary workloads and containers and expansion. You know, you lose all of that, but they're not ready for it.
So what do you tell them apart from, this is step 1? Like, what is the— apart from, You're okay if it's step 1, but keep walking? Is this the advice?
Well, it depends on— it's a business decision. I keep coming back to that. Ah, okay. It's true, but it's kind of like, what do I do with it? Do I have the runway to be able to say, I need to re-architect these applications to be in containers, in temporary workloads, with different API-driven, the whole thing that we have cloud-native applications? in modern cloud-native ways is a heavy lift. And you may not have anyone who knows how to do this, and you may be too expensive to do it, or you don't have the time. It's like, listen, I got to get out of the data center. It's cheaper to move up there than paying twice the price for the servers and the literal space and the cooling to move it up there. Fine. Get it there as a starting point, and then start to kind of move to take the small applications, do it cloud-native, feel good about it, and then start expanding. Very rare is because you also have a business that you need to run, right? Is you need to have dual modes where I still have this legacy thing that's going and I can't just like, we're going to shut down for 6 months where I hire a bunch of people to put this in and make it work. And then now we have the nirvana of all the cloud things. So there's a lot, as technical people, we see it, but technical people don't make business decisions. That's my mantra is like, it's the business decision. I just kind of say, how are we going to transition? And then they have to accept it and fund it and get the resources to do it.
Yeah. That mantra about technical people don't make business decisions reminds me of the IBM statement back in the '60s. A computer can't be held accountable, so it must never make a management decision.
Okay.
I don't know if that's an actual IBM quote, but it floats around the internet as one.
Right. Well, ChatGPT has taken that a different direction now, right?
Yeah, right. I think what Rick said in there, though, was really interesting, Anton. It leads into the next question in the doc really nicely.
I think it's the hybrid part, but also what I really wanted to say is that once you figured it out, sort of for one cloud, Bam, 2 more clouds fall on you, and in rare cases, maybe more than 2. So, I almost feel for people who sort of figured out cloud, and suddenly, they're in multi-cloud. And of course, their on-prem is still being dragged behind them, so they're in hybrid cloud, where they try to use some cloudy thinking on-premise with mixed results. So, what do you tell people in later steps of the journey, where they have to deal with more than one cloud and still deal with on-prem? What's the recipe for not failure? I think we are too— I'm not going to— I don't think we have recipes for success, but how about the recipe for not failure?
Well, understanding the risks of these. So when we talk about multi-cloud, it's important to kind of keep in mind that not everything is infrastructure as a service and cloud-native, greenfield cloud-native applications, right? You know, we have the Fortune 100 companies, and we have 5 million others who don't have acres of data center space that have this issue. Anybody in the 5 million, 99.99% of companies in the US are less than 500 people. Everything should be in the cloud. Don't even bother trying to do it otherwise. So when we talk about that small percentage that has data center space, has legacy applications in there and in cloud. And then the second thing is, when we talk about cloud, it's mostly software as a service or platform as a service. And the multi-cloud is usually like, there's maybe software as a service because you're using either Gmail or Office 365 for your mail.
Sometimes both.
And then you may have applications in Azure or AWS. So it's kind of, it's not like I have applications in all of them where I'm doing development in all of them. I'm using software as a service or platform in one, I'm doing development in the other, I may be doing something else in the other. So all of those things, you know, need to be in play. That's not all the same. So I was, I'm on the editorial panel for CIS Critical Security Controls. And one of the things that we've always said, and I've been part of it for 10 years, Number one is asset management. Know what you have, 'cause I can't protect what I don't know about. And then the basic thing, you're covering the basics well in all of them. Asset management, data protection, configuration management, vulnerability management, identity management. If I'm having all those things, and the challenge from multiple cloud is because often, and the bigger the company is, the more people are involved, there are different teams. You have the Azure team, you have the GCP team, you have the AWS team. You don't have somebody managing all of them. And so, particularly not from, you can federate the identities, but it's harder to federate privileged identities in that. And so, it's kind of like, and then you have the one on-premise, right? So, you have to be able to just know what you're dealing with and the assets it is for all those different things. My applications, my APIs, my data, where's my data flow, where's my backups, how's my backup going? Just kind of like having a handle and focus on the fundamentals and make sure you get those done right instead of trying to do the extreme, which is like, oh my gosh, I need to have some kind of thing to watch this in case this little thing happens or whatever. Focus on the fundamentals first.
You know, Rick, I hate to say this, but you're not making it sound easy.
Oh no, it's not easy.
You said the fundamentals, and the fundamentals was like 8 different things.
What do you mean? Buy CSPM isn't the answer?
No. No. And that's the thing that we need to keep saying. It's like there is no easy button for it. This is hard and you have to work on it. And it's kind of accept that this is hard. And anyone who's going to come to you with a magic box and say it's easy is lying. It is hard work. And that's why My main rant that I have is this difference between the haves and have-nots. You have the Fortune 500 and 5 million other companies. I'm in a Fortune 25 company. We are heavily resourced, we're heavily funded, we have lots of people, we got things covered, but we're in 0.000001% of just the US companies. And look at the Imtrends reports that your organization, Mandiant, just released a couple weeks ago, and you see that in Europe and in Asia Pacific, it's much worse from a security standpoint, even if the one metric that you look at is when incidents happen, is it being notified by a third party? That's just number one thing is third parties are notifying you that you have a problem before you know about it. This is a big challenge, and that's why we are not doing well as an industry, because it's hard and we keep being fooled that it's easy. And there's, of course, not enough people to do it, and not everyone— the people are not distributed properly, and it's a whole other thing.
You know, often our guests fill me with optimism. Today I'm not having that feeling.
No, no, no, no.
But there is a path. There is a path. You're right. I'm being realistic. The path is, again, focus on the fundamentals. And it doesn't take a lot of money. It doesn't take a lot of time to just say, I need to focus on making sure I know what's out there. And I'll crowdsource all the stuff on my premise, in my— the cloud. They know where everything is on the cloud. Just got to go to the right portals to get it. That's what I love about the cloud is nothing happens without being recorded, unlike on-prem, and that's great.
Oh my God, that's a fundamental difference that I think some people fail to appreciate between the cloud providers and anywhere else, is the robustness and survivability of the logging infrastructure.
Right. Now, on the incident response side, sometimes those logs are not easily accessible. Sometimes they get changed. Totally. Sometimes they're not complete, and sometimes timing is off, but it's there.
But you certainly don't have, like, log delivery issues and endpoint log tampering issues. There's fundamental advantages to a cloud operating model.
Right. But if you come back down to the fundamentals and just say, okay, particularly in the— and that's why I'm saying, like, if you don't have the resources, let that shared service model come into play. You're just dealing with the application, or you're just dealing with the credentials that you're getting. You're setting it up, you're doing low-code, no-code modification, as little as possible, so that all of the real heavy lifting heavy lifting of the metastructure is being handled by somebody else who has the resources to be able to do it. And so the path for people who don't have the resources is exactly kind of what you had said, Tim, is like, what's that line of outsourcing? If you don't have the resources, then leverage and lean on the outsourcing of the software as a service and all these other things, and then manage services to be able to manage it. If you do have the resources, then it's all on you. And the more of that responsibility is on you, Mm-hmm. to be able to have the right people to do the right things and get those things done. But we've made it a little easier to color by numbers in cloud, and because it's a very point-and-click kind of thing. Security, again, just think about the fundamentals. Am I protecting my data properly? Am I protecting my credentials properly? Am I using good credentials? Am I using multifactor? These are all fundamental things. And if you look at the hacks that happen, the most common ones and the ransomware, and even the ones related to the cloud, are not related to cloud insecurity. It's related to the stuff I said at the very beginning, Those top 11 things, which are human error.
Human error. Yep.
So if nothing else, reduce human error. Do more QA.
Yeah, reduce human error. So we've gotten a couple of questions in on the livestream, and I want to pivot real quick to those. And it's a hard pivot. There's no easy way to do it.
Nope, I'm fine with that.
2 questions I think are interesting. One from a former guest and other podcast host: what regulatory scheme do you dream of? Like, what would help you From a regulatory standpoint, maybe do your job better or sleep better at night? How could regulation help?
Oh no, another 30 minutes.
How about that?
No, no, no, this is a, this is a 45-second answer. I love this question. Honestly, is if we can get support to that 5 million companies who don't have resources, whether they're tax incentives, whether there is discounts, whether there is open up the GSA schedule to buy stuff very cheaply, whether there is incentives, you know, grants to security providers, the more we can help this 5 million other people that don't have resources, money, and time, all of us will be more secure. It's what can we do to be able to focus on them?
That's a really interesting answer.
That's a really good answer. Wow.
Wow.
Okay.
I did not expect that. How about that?
And it really was 45 seconds. Yeah. Second question from Trevon Pascal. What's your approach on threat management across hybrid and multi-cloud? And I think this is interesting too, because, well, I'm curious about your take. What fraction of threats that we're seeing out there really do span environments, and what fraction of threats that we're dealing with are in a single environment?
Yep, great question, but the wrong question. But I know your answer. And so the question is, because it's not just about the environment, it's about the organization, the size, the geographic— what country they're in, you know, how big they are, All these things equate to who are the threat actors. When I was a virtual CISO, I was CISO all around the world. The actors in South America, we never saw those in the US. So, ones in the US, we never saw in Europe, you know, et cetera, et cetera.
I wonder why that would be.
But the core to the answer is, it's not about threat management. This is the other thing that I kind of like to beat the drum of. It's about fixing things. We have no shortage of finding vulnerabilities. We have no shortage of tooling to tell us where problems are. And that's what the security team does. We have a challenge in fixing them. The security team doesn't fix things. IT fixes them. The infrastructure team fixes them. The people who are not security fix them.
But in the cloud, it's different though, right? A little bit.
No, it's not. This is really interesting. Go on, Rick. I like this.
Because we need to make it as easy for them to fix the problems than us finding them. We need to give them the reason. We need to give them the information. We can't just say, hey, I ran a vulnerability scan, or I did some attack surface management thing, and I'm going to throw over the fence this report, go fix it all. And they're like, listen, we're assigned other things. I don't know how this is real. Have you prioritized these things? Like, we need to do better on our side to say, this is defined for do these 5 things, and here's the link to it, or here's the pseudocode, or here's the code to add in, or here's configuration change, and I'm going to write the script for you to be able to execute the script, and I'm going to stick it into my workflow management system to press a button, it'll fix it. Press this button to back it out. It's about focusing. The short answer is focus on fixing problems, not finding more problems.
Interesting. Okay. That's another surprisingly deep answer for what seemed like a simple question. Anton, why don't you ask the next one then?
Yeah. So this question has been my obsession for the last maybe 3, 4 months. So I was really waiting for Rick to show up on the podcast so I can ask him. And I'm not joking. I'm not exaggerating. It's really it. Because you mentioned this whole haves and have-nots, kind of people with resources, people without resources. We do see companies with literally a security team of zero adopting cloud.
Yeah.
And sometimes adopting cloud at a large scale. So, it's almost like your advice about, hey, security team, focus on X instead of Y. Well, they ain't got any. There is no security team. So, what is your best cloud security advice to an organization without a security team?
Right. And I'm responsible for our subsidiaries, and some of the subsidiaries don't have any security folks, you know, and we are acting as their managed security service provider in the core company. And so the answer is like, get some somehow. It should be just like we may have outside counsel, get a virtual or fractional CISO, get some support, even if it's part-time, get some expertise, because it's not possible to be able to run a company safely And securely from harm from contracts, laws, regulations, et cetera, without some kind of counsel externally or part-time or whatever. It's the same thing we're dealing with the security. If you have IT folks and no security people, even if you, whatever you can afford to get 20% of a fractional CISO to help you figure things out, you need to have that. And that's just kind of like the bottom line is we can't afford not to have some kind of Just like legal expertise, we can't afford not to have some kind of security expertise, even on a part-time basis, because it's a business risk.
Okay. I would take that. I expected you to give me some magical answer about, oh, just do X and you're good.
No, because it is not easy.
Fine.
You know, it's not necessarily an easy thing. I mean, there are fundamental things. You know, you can go through some of the standard control frameworks and kind of say, okay, make sure I have these things in place, make sure I have this. It gets more complicated at that, but somebody needs to come in because, you know, one of the challenges that I had when I was a virtual CISO, I did a lot of work in helping people hire the first CISO.
Hmm.
And the biggest challenge is they would hire the wrong person or they want to hire the wrong person because they can't tell the difference between a good one and a bad one. And there is a confidence bias in security people. And there's also like a technology bias with usually the head of technology that interviews them. And most people don't need a tool jockey to come in there and buy a bunch of tools and put them in and configure them. When really they need is governance, and they need to be able to link the business to the technology, understand what the real risks are, understand what would be a bad day for the company, and then have the kind of infrastructure and the security architecture to help reduce that ability to have a bad day. And the 2 things that I saw most missing as a virtual CISO was a lack of governance, which is the business and the technology being linked together from a risk standpoint, and 2, an incident response process. What are you going to do if something goes wrong? Because that's going to go wrong. And some people had— a lot of people were well-instrumented. They had all the right tools. They were all blinking. They were doing stuff. They may not be logging anywhere. Certainly no one's looking at them. But if someone calls them and says, you have this problem, they don't know what to do. And so that's where you need to have, even if it's external support, even if it's part-time, just somebody who knows what they're doing to kind of help you.
You said something really interesting in there as well about the skills needed to be a successful CISO versus other roles in the security chain. I think that's a topic that probably merits its own podcast, Anton. We should have a long conversation about that. Yes.
Yeah.
Okay. So, Rick, I hate to do this, but we're just about at time and I do have to run eventually. So, I want to ask our traditional closing question. First, do you have one tip maybe for helping organizations improve their cloud security outcomes other than focus on the fundamentals? And 2, do you have recommended reading? And the recommended reading can be anything that you think people would benefit from reading of any sort, except Anton's blog.
And we know you have a sizable YouTube presence. We're gonna put a link to that for sure. But I would appreciate more guidance on this.
Yeah, no, absolutely. So when I talked about those refugees that become the crowd people, the number one skill I'd look for is scriptwriters. Because particularly among all the different clouds, it's like when you can do scripting, when you can do PowerShell, you can do Python, you can do, you know, That will make your life so much easier because this is not just a point and click. Point and click will get you somewhere, but scripting stuff to fix things, respond to things, pull things is going to get you head and shoulders above where, you know, you would be otherwise.
I believe that.
So that's number one. And then number 2, I would say go to the Cloud Security Alliance. The Cloud Security Alliance has so much free information available to download that is well researched by everybody in the industry. They've been around for 13 years. And, you know, they're on stuff on zero trust. They have recent stuff on generative AI. They have all kinds of things that are free. I mean, they give way too much away free, but it's great because they're supporting the community because they're so big. I'm, you know, and that's not just because I'm very active with them. It is a great resource for all things cloud across all the boards. And so that's where I would say if you want to have good cloud resources, that's the first place to go.
Well, Rick, I really appreciate the thoughtful take today. And you're right, there's Many hours more discussion we could have here. So, Rick, thank you so much for joining us. Everybody on LinkedIn, thank you for logging on and joining us for half an hour today.
Thanks a lot, guys. Really appreciate it. Thank you.
And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakin and @_TimPico. Tweet at us, email us, argue with us, and if you like or hate what you hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.
Bye.
Security.
Security.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google