Preparing for Disasters (both Cyber and Natural): Cloud Security | Intel Technology
(bright music) - [Narrator] You're watching Cyber Security Inside, a videocast where you can discover what you need to know about cyber security. Here are your hosts, Tom Garrison and Camille Morehardt. - Hi, and welcome to the Cyber Security Inside podcast. I'm your host, Tom Garrison, and I'm here as always with my co-host Camille Morehardt. And today our guest is Jo Peterson.
Jo Peterson is the Vice President of Cloud and Security at Clarify 360. So welcome to the podcast, Jo. - Oh, thanks for having me. - So can you start off with just talking a little bit about your background? - Sure. I'm the Vice President of Cloud and Security for Clarify 360. We are a data-driven sourcing advisory that does benchmarking consultancy, and we're focused on IT Infrastructure.
We work a lot with the holdings of private equity. - We wanna talk today a bit about the cloud and cloud infrastructure and so forth, and so maybe we can start off with just maybe at the highest level, what are some of the trends that you see happening in the world of cloud and as it intersects with security? - Oh gosh, there is so much happening. Recently, one of the major cloud hyperscalers had an outage. They actually had a couple in a row, and the customer community is talking about resiliency in the cloud. That's a big topic right now. You know, cloud systems are expected to always be on, and news like that makes the headlines.
So what I'm hearing customers talk about is maybe the need to rethink a strategy about having all their eggs in one basket. And we think it's really important to talk about resiliency. We think it's important to talk about the idea that you can do some things as a customer to maybe not start again, do everything from scratch, but maybe think about, do you have things, like high availability, also known as HA, built in? Are you housing workloads across multiple availability zones? Are you supporting region routing using things like domain name services? Are you backing up your data? Are you encrypting that data? Those are sort of some of the things that customers are top of mind with right now.
- What are some of the sort of the dirty secrets of the customers that they're not gonna admit to anybody else, but maybe in talking to you, what are some of the embarrassing questions they're asking or some of the things that they've admitted that they haven't been doing yet that they feel like they should be? - I would like to spin that maybe a little bit of a different way. I like to think of it in terms of sort of health checks or best practices for cloud data security. We think and we talk to them about some basic hygiene things that you should be doing, like have you secured your user endpoints? That translates into all endpoints. You might have the users squared away, but maybe you don't have your VM squared away.
Maybe you don't have your server squared away, so that's something to think about. And have you implemented encryption? Are you controlling user access? I don't think it, it surprises me, but it shouldn't surprise me. The vast majority of cloud breaches happen with unsecured assets, and they happen because somebody made a mistake somewhere, and that's usually internally.
So let's think about things like the shared responsibility model, because the shared responsibility model is different for each cloud provider and it's different for each product within that cloud provider. So are you and your team sure about what your responsibility is as it relates to that cloud provider and that particular product, and it gets even crazier when you're dealing with multiple clouds. It's a lot for anybody to sort of remember. Hey, look at your cloud usage policies, and I know it seems super simple, but practice good password hygiene. Who's got the passwords to this stuff, right? So those are some of the things we talk to them about.
- An area that I'd like to try to poke on for a second is this notion of, I mean, recently, and it's not just Amazon, but Amazon's been in the news, some pretty high profile outages, other CSPs same as well. And you mentioned about the idea of having sort of multi-cloud and the ability to if one goes down that you as a company who's relying on that backend infrastructure, you could fail over to another provider. First of all, how prevalent is that? That's a standard computer server thing that's been in the industry forever, but at the cloud level, obviously there's a whole different level of complexity.
So is this a concept or does it exist today, and how do you see it progressing over time? - What I see is I see the more mature shops doing distinct workload placement. So they'll have a policy and a list of criteria about where they're gonna put a particular workload. And I don't necessarily, it's not an idea of sharing that workload across multiple providers, 'cause that really is not happening so much. What we see more is we see hybrid environments. So we'll see an on-prem instance of a particular workload and then some portion of that workload in a cloud. And from a best practice standpoint, what we are seeing happen is we're seeing some of the the things that I mentioned from the more advanced shops come into place.
Like they are taking that workload and they're placing it across multiple availability zones so that they've got some redundancy built in, right? So they're doing everything to sort of ensure that that workload's protected along its journey as much as possible. - Are you saying that somebody would take a single kind of a thing, like, I don't know, payroll, whatever you wanna pick, and you would have the ability to do it on-prem and you would also have the ability to do it in a CSP, for example? - Well, some portions of that application might be housed on-prem. So for example, depending upon cost optimization, for example, that might be a reason.
You might have some of the data stored on-prem for that application because it's become too costly to run in the cloud all the time based upon egress, based upon bandwidth and latency. So you might have some of the storage for that application on-premise, and you might be doing some of the compute for the workloads, for the newer portion of the workloads in the cloud, right? And you might be transversing back and forth. So that would be an example of perhaps somebody utilizing an on-premise portion of that same application versus a cloud portion of the application. - Are you saying best practices to say, at that cloud service provider, it's not just enough to have several instances in one availability zone? They require that workload not to be across multiple geographies, multiple availability zones, so that if one of them goes down, the other guys are still up and running, is that? - That's it, that's exactly right. So you might have it in a hyperscaler location in California as your West Coast presence, but say we have an earthquake out here, you might decide to have a presence on the East Coast as well, and you do that via application load balancers.
So you load balance the application in the different availability zones. - Is that the definition of an availability zones? It's a geographical thing or are there other definitions? - Yeah, it's primarily the definition of availability zone, would be the idea of geographically balanced infrastructure. - It seems like, and this is kind of where Camille was going I think too, that the notion of availability zones was what you just described before, which is like natural disaster stuff. There's a big fire, there's an earthquake, there's a whatever.
But what we're talking about now in the press is somebody didn't secure an endpoint or something happened, and so that the idea that one particular set of servers goes offline, I just wonder if the sort of definition of availability zones needs to change so that it's not geographically dispersed. So you're gonna fail out of California and you gotta jump over to your East Coast presence, but instead, maybe they're within California, there's four different availability zones, even within the same data center so the whole thing doesn't come crashing down. It's just... - Yeah, you could do it how-- - Is that a thing, or? - You could do it that way, too. I mean, wherever the disaster happens, it's still a disaster. So if you're running in a different availability zone, you're theoretically dealing with a whole 'nother stack of infrastructure, so it doesn't matter, right? So you're right, it could come on either side of the equation.
Disaster's disaster - In terms of best practices, is this something that's pretty broadly known today? Like, is this basics that people would ask for a cloud service provider. Somebody who's going to Amazon today and they say, "I need to host some backend workloads and whatnot," is it very common for them to say, "And Amazon, I want you to have this "in four different availability zones "just in case something goes down." Is that best practice today? - I'm gonna tell you what I see and then what's reality or what's out there and what's reality. All of the hyperscalers do a really great job of helping to inform and educate potential clients. So every one of them has guides, how to guides, right? But at the end of the day it's you building your infrastructure.
So what I see happen in shops that don't have a thick bench, a lot of help, is they'll go to a managed service provider, a CSP first, to get that sort of architectural best practice from that company, and they'll learn as they go. It's training wheels. And it's a good idea. If you don't have a team that's ramped up, if you have a team that's ramping up, if you need somebody to sort of help you along and hold your hand, you're not sure of the security checks to put in place, for example, it's a really great way to start as you're building out your cloud environment.
- Have you seen any other kind of adaptation to the it seems to be increasing number of attacks, cyber security style attacks versus say a natural disaster? I mean, have you seen any other kinds of changes or structural changes or definitional changes because of that? - Well, cloud is a teenager, right? And it's growing up, and there's things that are happening as it grows up and matures, right? The world around it's changing and its world is changing, so there's this sort of dual effect. So we are telling customers that you may wanna take a look at things like cloud configuration automation and consistent enforcement. Do you have those things in place? If you look back 10 years and you look at now, I mean, we are using way more SaaS applications, so what's your policy around connecting to other SaaS applications, and how are your users connecting to that cloud environment? Because everybody works from home now.
Everybody's remote. If you look back at VPN, it was the 80/20 rule. 80% of the workforce was in the office and 20% was remote. Now that's reversed.
So does a technology like VPN for how we connect to all of our mission critical applications still hold? Maybe, and maybe not, and maybe it's time to do an identity-based. VPNs look at the device. They don't look at the user, so that there's no identity parameters about who's coming in to that environment, so maybe we should rethink who we're letting in the door, right? Because these are the companies' crown jewels. So things are changing.
Companies are embracing multi-cloud. Visibility is a big deal. How do you see what you have? Those are some of the things that we are seeing change sort of ubiquitously, and it's security and it's network and it's the cloud itself.
- I wonder if for our listeners that may thinking about moving some workloads off into the cloud, what sort of questions would you recommend them ask their potential cloud service provider partner, right? In their selection criteria. What are some of the things that may uncover either a CSP's strength in areas of security and manageability, or maybe uncover some weaknesses that you would be like, aha, this is a red flag for me? - Before you accept a date to the prom, make sure of the dress you're gonna be wearing, and what do I mean by that? Know what your inventory is first. You'd be amazed at how many customers...
You know, when I was a young engineer, they used to tell us to keep it simple, right? How many customers don't have a baseline inventory of what they have. So if you're not sure what you have and you're not sure how many applications you wanna move to the cloud, get that squared away first. And I tell you that because that will help you decide who you're gonna pick as a partner to go to the dance with, and then you can start to look at things like, have I selected the cloud I wanna go to? Well, if I've selected a cloud, I wanna look for competencies around that particular cloud, and there are some really solid, competent partners that have specialization in each of the clouds. Now, there aren't that many that do all the clouds, so that's really something to ascertain.
Start to look at their engineering bench. How deep is it? How long have they been doing sort of cloud journey work? Are they competent in the different areas of cloud journey work? Meaning can they do an application rationalization, because if they can't do an app rat, chances are they're not gonna be able to do a really good job of managing your environment. They're not mutually exclusive, but there's some things to look for, right? So I look at some of that. I look at some of how long they've been around, how deep is their bench, how much experience do they have, how long they've been doing this, which cloud are they most competent in? Those are some things I look at. - What kinds of things are still strikingly different among cloud vendors? Of course, I'm kind of going toward privacy and wondering if there's sort of a comprehensive approach there, but maybe there's something else you could help us understand.
- If you look at their competencies, every one of the hyperscalers do great work and every one of them have really built out their practices and they're just solid. So it's not gonna be a matter sometimes of the best compute for me, which cloud can do the best storage for me? Those are table stakes. It becomes, who's got the easiest to follow security for me and who can help me, particularly if I'm a multinational, meet some of the different country regulations that I have to encounter. And they're all different, and it's becoming more of a thing. So you really need someone that can sort of guide you along.
Hey, in Germany, for example, the data can't leave, so how do I handle that? In Spain, it's got a different set of rules, and who can guide me along there? - So let me ask you one of the other big buzz terms is thrown around all the time, and that's AI and machine learning. How do you see AI and ML affecting the use of the cloud? - I kind of was looking this up and I thought, I was surprised by the numbers that I saw. Current estimates expect today's 2.5 billion ML market, cloud ML market, to reach 13 billion by 2025. That's a pretty big increase, right? And Deloitte put out a 2020 study of AI and it revealed that 83% of organizations expect AI to be critical to their business success in the next two years. So cloud drives measurable benefits for AI programs.
It helps you improve efficiency, decision-making, competitive advantage. I think they sort of go hand-in-hand, so I think we're just gonna be seeing more AI and cloud together, like peanut butter and jelly. - Now that's interesting. - I think we're gonna see AI utilized in the cloud, particularly around BI, that's what I think. - Just to push on that one a little bit more, because I think 10 years ago it was sort of like IOT is gonna drive the cloud and we're gonna have all new kinds of workloads and use cases that we've never seen before.
And now we're hearing AI is what's gonna drive the cloud. This is gonna create all kinds of new use cases and workloads that we've never seen before. So is there anything else kind of on the horizon that you think maybe isn't top radar for everybody, but that's gonna kind of sneak in there and make a pretty big difference with respect to cloud? - Personally, I think we're gonna see, particularly in certain verticals like retail, healthcare, we're gonna see these edge cloud deployments.
And he who has the data and he who uses the data are gonna be first. So you're gonna see market disruption. You're gonna see first to market advantage by companies that are using that edge, that customer data, most creatively, that's what I think. - I couldn't agree with you more.
It's all about the data. It always has been about the data, especially as the datasets get so large. The person who controls that has a huge advantage.
Jo, this has been great. We've really started to scratch the surface on a vast topic we could have spent hours and hours really talking about. Really neat about these things, but thank you for walking through that. But before we let you go, we do have one more segment that we love to do, and today we've built up expectations, at least in the pre-call here, that we all have good fun facts.
So Jo, we'll let you go first. What is your fun fact for the day? - Oh, okay. So I knew that I wanted to be an engineer at age four, when I retrofitted my Easy-Bake oven with a bigger light bulb so it would cook faster.
So it got me thinking about three modern world inventions that were invented by women that most folks can't or don't wanna live without. And the first was the mechanical dishwasher, and that was created by a woman by the name of Josephine Cochran. She was an American inventor and she patented the dishwasher and she sold rights to KitchenAid in 1916. And Cochran is still listed as one of the founders by KitchenAid of the dishwasher. Mary Anderson invented windshield wipers. And my favorite one was Ruth Graves Wakefield, who invented the chocolate chip cookie.
Who wants to live without a chocolate chip cookie? - What is life without a chocolate chip cookie? - I don't know. - All right, those are excellent. Thanks, Jo. Camille, what is your fun fact? - Yeah, I like all three of those. So my fun fact is about the wombat, which is a marsupial in Australia.
And the really weird thing about the wombat, well, there's probably a few things that are quite unusual, but one of the really weird things about the wombat is its little pouch, that characteristic thing that marsupials have where they give birth and then the babies crawl into the the pouch and they carry them around. And the wombat carries a baby around for about five months in the pouch. But the pouch on a wombat faces the opposite direction of all the other marsupials. So if you see a kangaroo, picture of a kangaroo, the little baby kangaroo can kind of poke its head out the top of the pouch. Well, the wombat pouch faces the other direction, and the reason I'll just quote-unquote they suppose that's the case, is that they're extensive burrowers and tunnelers.
And so the concept is maybe they can tunnel and they don't end up filling the pouch up with dirt or mud. - Now wombat's four-legged, right? So they're not upright like a kangaroo, 'cause otherwise-- - Right. - Gravity would want it to fall out. - They look a little bit like marmots, but they can be anywhere from like 40 to 70 pounds. - That's cool. All right, well, so I have to give credit to my daughter for this one.
She is a biochemistry major and she's about to graduate, and she said, "Dad, I got this really cool fun fact. "You gotta use it." So here it is. Did you know that the most powerful bacterial toxin is botulinum toxin, which derives its name from the Latin word for blood sausage, where the bacteria occasionally thrives. The potency of botulinum toxin depends on whether you eat it or inhale it, but one gram of this stuff can kill about a million people. No other toxin is more powerful, but you might ask, well, how does it work? How does it kill? - I wasn't gonna ask, but I have a feeling you're gonna tell us.
- Well, because my daughter's a biochemistry, she's gotta tell me how it works, right? So botulinum toxin is an enzyme that is basically taken up into the muscle fibers, and the toxin itself digests these key proteins needed for the muscles to operate properly, and specifically the synaptic, it's called synaptic vesicle release. Who the hell knows what that means? But anyway, basically the muscle doesn't work anymore because there's nothing transmitted there. And so that means that the muscle, it cannot contract, which I think is pretty interesting, so that's how it works. But it is interesting, this is the other part of the fun fact, is that because it's so toxic, you would think like we would stay away from this crap all together. However, botulinum toxin is also used to treat wrinkled skin, Botox. It's the same stuff.
And in that therapy, doctors inject a small amount of this botulinum type toxin into the muscles under the skin, and as we just found out that that means that the muscles can't contract anymore and they in fact become paralyzed, and the wrinkles subside, so that's how it actually works. Pretty cool, huh? - That is cool. I did know about the Botox situation there. - I knew about the connection between botulinum toxin and Botox-- - Yeah. - But I did not know how unbelievably toxic it is. On that note, Jo, thank you so much for joining.
I think it's a great conversation and I'm sure we will get lots of good listenership as a result. - Thank you for having me. It was fun. (bright music) - [Narrator] Thanks for joining us for Cyber Security Inside. You can follow us here on YouTube or wherever you get your audio podcasts.
- [Man] The views and opinions expressed are those of the guests and author, and do not necessarily reflect the official policy or position of Intel Corporation.
2022-06-22 07:01
