SecurityMetrics Podcast | 13
Cloud Security Best Practices
When Liberty Mutual offered Craig Olsen a lateral leap from Developer to Security Analyst, he took it–and hasn’t looked back since. Now a Cybersecurity Architect at Liberty Mutual, Olsen reflects on the last fifteen years and his role in the transition from one-person internal security departments, to a full-blown industry with unique technologies, solutions, and issues.
When it comes to the cloud, many companies are unsure or hesitant. Some may not even know for sure if they’re using it. Often, this is based on a lack of understanding or familiarity with cloud security.
Craig Olsen sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) for an in-depth discussion about cloud solutions, including:
- What we can learn from companies who’ve experienced data breaches in the cloud
- How to leverage the unique qualities of the cloud to improve security and support growth
- Simple steps anyone can take to build foundational layers of security–areas like passwords, policies, encryption, and compliance
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Cloud Security Best Practices Transcript
Hello, and welcome back to the Security Metrics podcast. I'm Jen Stone. I'm a principal security analyst here at Security Metrics. And today, I have a super interesting guest on. His name is Craig Olsen. He's a cybersecurity architect for, Liberty Mutual Insurance.
Craig, welcome to the show. Can you tell us a little bit about yourself?
Sure. I'm glad to be here, Jen. A little bit about myself. Well, I've been involved in cybersecurity for over twelve years. I worked for a company called Liberty Mutual. You may or may not have heard of Liberty Mutual.
You may Tiny little company?
The the the Doug and Limu commercials. I think I get, people who like to do the Liberty Liberty Liberty jingle, and all that. So I've worked, worked there for about this is my fifteenth year. It is the only professional job I've had. It's the job I started right out of college.
Wow.
And, I always tell people, if you think you messed up an interview, I tell them, at least you didn't do what I did, which was show up a week early to do, which is what I did. So it always makes people feel a lot better because they're all, oh, I should've said this. I'm like, I showed up a week early. And I always say, I played it off as well. At least they didn't show up a week late.
So That would have been worse. Yeah.
They they somehow must have saw something through that, and they hired me. I started off as a developer.
I wasn't a very good developer, but I developed things. And, I didn't take down my company or anything like that. So Mhmm.
And so I guess a little bit about myself in terms of how I got to cybersecurity, because I think a lot of people wanna know that journey.
So about twelve years ago, going back to about two thousand eight, I kinda had this epiphany where it was that, security is one of those things that a company shouldn't outsource.
Mhmm.
And so, you know, kinda looking and recognizing there might be something coming down the line, like, oh, I don't know, maybe a recession.
You know, there was an opportunity to do a lateral move from being a developer just as just an analyst, security analyst. Mhmm. So I took the opportunity, and, I I've loved it ever since. And, it has provided a wealth of opportunity and experience.
About myself, I reside in Utah, the great state. I moved here about three years ago.
Awesome. And, before that, I lived in New Hampshire for the prior twelve years. And, so I I let, you know you know, go Sox.
We go Patriots. This is where your viewership just declines.
Everybody's like, oh, damn sure.
Yeah. One of those. Yeah. New Hampshire. Yeah. And, no. So I I loved it being out there.
For myself, I've been married, for for almost eighteen years, and I have one son who is six and keeps our lives very busy.
Oh, that's awesome. So so you're you're in security at you started off as a security analyst, so a fairly low level position there? Or was it a little tell tell me a little bit about your journey to where you are now with Where I'm at now.
It's been quite a journey. Yeah. It's so for over twelve years. So, yeah, I started off just as an analyst. I think I would run around and do risk assessments.
You know, one of the things that I was brought on was to take this crazy tool that was called a static code analyzer and try to scan applications. And I think the first one I scanned took four days, and I think I needed a doctorate to be able to review the results. And the person who wrote the app didn't understand any of it.
And so we were very much in kind of our infancy Mhmm.
Within our company. We had some security. We had that. I think as as, a testament to this is is during the great recession, as companies contracted, the two big areas within my company that grew, with security and mobile.
Oh, interesting.
Think about the App Store was kind of, you know, debuted and the iPhone and all that. So there was an opportunity for this new market, this new potential. Sure. So, yeah, I kind of moved up.
I've just stayed you know, moved around doing different things, specializing in app security. Mobile security was the thing that I specialized in for a long time. A lot of things with privacy, identity. And for the last five years, I've been focused on the public cloud.
Which is why we have you here to talk to us today.
Securing the cloud is a is a huge topic of conversation. It seems like more and more organizations are moving to the cloud. And I was really fascinated by your story because you helped with that migration to AWS as I understand it. Yeah. Yeah.
So I oh, sorry. I was gonna say I probably should say a little bit about Liberty just for a second, my company. Yeah.
You may have heard of us. You may not have heard of us. We're about fifty five thousand employees, worldwide in eighteen different countries of operation.
We have about five thousand IT employees and about two hundred in just security alone.
Wow.
So very large organization. I am not alone.
But sometimes I feel that I need a bigger army. And sometimes I look back and look for the cavalry, and they're not there. But, it is it is, it's great working amongst a lot of different people and a lot of technologies.
Excellent. And so, tell us about Liberty Mutual, is in AWS.
So tell us a little bit what about why you chose the the cloud to begin with.
Yeah. That's a great question.
There's two reasons. I'm gonna give you the first reason, and then you're gonna say what's the real reason, and that's number two. The first reason is that we had aging hardware. Mhmm. And the aging hardware was getting old and deprecated.
We built our own private cloud, and and so it was just the cost of of maintenance and all of this. Just, you know, it it the the ability to go to the cloud just seemed like a better idea.
So a decision had to be made.
A decision was made. Now I'm gonna be honest here. The reason number two is the real reason.
Okay.
Or one of the primary drivers. I I would say that there's multiple drivers and forces at play. And, yes, aging hardware is a reason to go to the cloud.
But one of the biggest ones was the ability for us to scale and move quickly. So, there's a project, and there's been a number of projects by large companies that deal with things like the autonomous driving car. And what really is interesting from an insurance company that from a from that term of disruption that is always thrown around in the industry, the idea that when Google says we're gonna self insure our car, you're gonna have every insurance company in the world with their ears perk up.
Mhmm.
Because if they can build a car that drives itself, that's got cameras and sensors all over the place, and it can replay any of those at any moment to prove that it wasn't at fault in an accident, then what's the need for an insurer?
And if you've got other technologies like IoT, like a Nest thermostat or others that can then warn you that, hey. Your house is getting cold. You might wanna act on it before your pipes freeze. Therefore, you have an insurance claim.
You need to do something. So to be honest, the big primary one of the drivers another primary, but a key driver was the ability for Liberty Mutual to move out of the traditional way of doing things and embrace different ways in the future.
And we we would do that and move rapidly and at scale and a global front is to go to the cloud because that gives us the ability to try out new markets, try out new technologies, try out new concepts, and rapidly move. And we couldn't do it at the pace by which we were doing it before. There was it was like a backpack of bricks that we were carrying along because it's mainframes and open VMS and all these old things. It it that to me so it's hardware. Yes. But, really, I think a lot of it was, as a company, we wanted to embrace all the benefits of elasticity, immutability, the ability to move quickly geolocation wise.
I I I I agree.
That that makes total sense. But then, sometimes, especially in more established comp companies, and maybe this is just my my perception from from the some of the customers that I deal with is, the more established an organization is, the more hesitant they are about new new, things like the cloud. So how did you get past, security concerns around moving to the cloud? Question.
Let me show you my work laptop. So, and and, but there's a sticker on it, and hopefully, we you can see that. Yes. It says there is no cloud.
It's somebody else's computer.
And that I've I've had that sticker for five years. And it was really interesting because we had a lot of our development community was just begging for the cloud. They saw a lot of the benefits of continuous integration, continuous deployment and delivery options, rapid scale to delivery. Like, they looked at it with, like, huge benefits.
And here's security. Right? We're on the other side of the table. And so their side of the table, they'd have these stickers that would like, I built my my data center in five minutes.
Uh-huh.
My other computer is an e c two, you know, a I've seen those stickers as well.
You've seen those. Right. Yeah. And so you have, like, this, like, you know, very much that. And then on the other side of the table, with all security, and we're like, it's somebody else's computer. Right? You know, it's and so from our our point, right, as security professionals, the ability to know possession, right, is a key attribute.
Sure.
You know, if I if I can't attest to certain things so there was some trepidation.
Yeah. And one of the things that's very interesting I like to tell people was back in we we started looking at the cloud about twenty fourteen, twenty fifteen, and there was a key incident that had happened, a key event that really got us nervous. And I always bring it up, and I say, how many people here and I would ask, you know, my students or anybody this. I'd say, how many of you have heard of Codespaces?
And you see people start looking around, like, I've never heard of Codespaces.
Well, you've you've never heard of them because they were murdered in the cloud. Oh. Because they were held ransom in June of twenty fourteen. Somebody got a hold of their master account and asked for a ransom.
Said, hey. You're gonna pay us. And the company refused. And so with that master account, they deleted their Amazon account. And in that account contained their backup, their code, and their data.
Oh.
And so the headlines at the time said murder in the cloud.
Okay.
And it really highlighted this, like, well, wait a minute. We're going to this cloud. Does that put us in a position of an of a of an incident where recovery is not possible?
Mhmm.
Because we had spent years and decades building out full redundancy in our data centers. We had multiple data centers around the United States, around the world. And we had tape backups, and we've got off-site storage, and we've got warm and hot site capabilities and all this. And then you're like, wait a minute.
If I'm going out to the cloud, I have to put a trust that's out there. And Mhmm. So there was some hesitancy from security. And a lot of it was just, particularly for myself and others, understand what the cloud is.
Right.
This is the part that I think that really confounds people because a lot of people think, oh, cloud is it's anti security. It's the anti pattern. You can't be secure in the cloud. And I disagree.
Yeah. I hear that a lot. And I also disagree.
Yeah. Yeah. I I think that that there are challenges and risks that come from operating the cloud, like backup and recovery.
But there I believe that from some of the benefits of the cloud that you have the capability of securing your your company's infrastructure better than you could on prem.
I I I am I'm with you on that. Because of the, the centralized nature of it, because of the, the standardization that you get out there, there there's a lot of reasons why I believe the cloud can be more secure than an on prem, development. But it's like you said, you have to understand what the cloud is and how to use it. For example, you know, you said, hey.
The these guys, they had all of their backups in one thing and deleted it. There's that is one key time where I see a lot of people very confused about what does the cloud give me. So I'll say, hey, Kate. Tell me about your backup and recovery, capability.
Tell me about your failover. Tell me about, you know, should anything happen. And they say, oh, I don't need that type of thing because AWS has it.
And and and I'm like, okay. AWS has it for their systems. And if you properly use it, then, yes, you also have it. But there is, an architecture piece that has to go in there. So, what I really liked when I originally talked to you about the cloud, we were fortunate enough to be on a panel together, for an ICS. Was it IC?
It was IC squared. Yeah.
That means we could meet together.
Yeah.
It was. I yeah. IC squared. That's right.
And, you you talked about mitigating risks in the cloud. And and so you've developed these kind of ten steps to mitigating the risk in the clouds based on defense in-depth. And now a lot of people have heard of defense in-depth, but some people haven't. So maybe just kinda cover that concept briefly for us.
Sure. Yeah. So defense in-depth, I think there's two simple analogies that people use. The most simplest one is is an onion, that you've got layers that you have to peel back.
There's one that I like to use, that's just, like, medieval castle structure on how the castle is built. Right? You know, just a couple of concepts around that. You've got a village.
The village is going to alert you when invaders are coming. Well, there's your there's a detection method right there.
Mhmm.
And you you usually have a moat. You've got a drawbridge. You've got different layers and courtyards. You structure the, staircases going up so that the people who are going up and trying to attack are having to use their left hand because of the way because of the way how they'd be drawing their sword.
The people defending it would be using their dominant hand. So you put all these layers into it so that you have depth. And I think that oftentimes, you know, sometimes companies try to do this, but what they end up doing is a really hard, crunchy shell Mhmm. And they got a really gooey center.
Right? And they say that, well, I have a firewall.
Yeah.
And then as soon as you you you get through that firewall, sky's the limit. Everything is yours.
Or I'll get this. Everybody needs a login. Terrific.
Yeah. Great. I I I agree. But what yeah.
Once you get through it, I think.
Yeah. What else do you get? Yeah. Yeah.
Yeah. And I would like to say that so the the steps that I kinda put here, I spoke at Utah State University last fall, and, I kinda did it for just steps that everybody can use. And I think that there's a lot of companies that are not sure about the cloud. They don't know about the cloud. There's some hesitancy to the cloud.
And and for the most part, they just don't know. And some of them, they they are like, I think we're using the cloud. Well, you probably should know if you're using the cloud. Right?
I mean, there's some of it that some of it are completely, like, ignorant. It's you're using the cloud, and you're there. And so I tried to structure this as just simple steps that anybody can do. And then, you know, just so that it gives them a little bit more.
Because the idea on this is if you could just start building a couple of those layers in here, then it just helps you. And then when you wanna get more in-depth, you know, there's plenty more you can do.
Then let's let's walk through some of these steps, starting with passwords.
Yeah. Password. So I I feel like this is kind of one of those standard security responses, like use.
And and I think the key on passwords isn't complex passwords. I think everyone knows this, and has been advocated for the last few years. It's not complex passwords. It's long passwords, long passphrases.
Right? Sixteen characters, twenty characters, whatever that is.
Sure.
The key is length. And it's one of these that it's amazing where companies, you know, still have old policies.
They have no idea.
So with passwords kinda comes up with other types of things. Right? Well, you know, do you deactivate users? You know, do you actually have permissions of, you know, what these people allowed to store? But I often talk about bonus points and that notion of a password manager.
Probably eight, nine years ago was probably a foreign concept that people like, what is this crazy technology you're talking about? And nowadays with, you know, things like LastPass being relatively available and even on your phone where they've got password scores, there's no excuse, to not utilize these types of things. So I think the key is is that the password is the front door into any infrastructure, whether it's your your company's infrastructure, your cloud infrastructure. Just have long sixteen plus character passphrases, that that you have at least some assurances that, you know, it's not gonna be easily guessed by a computer.
And this can be configured in the cloud. So, whether it's AWS or Azure or, Azure for us, Hicks or or GCP. Right? The Yeah.
Yeah. That any of these platforms have a way that you can go in and configure password length and password complexity if that's your if that's your jam. But, so making sure that those are actually set, not just a a recommendation or a training item with with users. You know?
It's like it Yeah. That you can have a bunch of employees in the company, and they say, oh, please do a long password. And everybody goes, okay.
So Exactly. I I'm fine if this is my long password. Like, that that's fine. But, yeah, I I I it's very interesting because we're creatures of habit.
And so we tend to not change things, and it's always kind of fun when I would, you know, tell people over the years. It's like, oh, well, I've got, like, an eight character password that has to be rotated every ninety days. Right? And things like PCI require ninety days.
And and so you're like, well, you know, chances are you're only gonna change one or two of those characters every ninety days. Yeah. You know? And and so now now I've got kind of a formula.
Mhmm. I've got a pattern to go after it. And how is that any better? So I think just it's passwords.
It's just basic we can talk for hours on, like, the path.
But I just wanna kinda emphasize, if you got any form of cloud, anything, just just put a policy in to make sure that you've got, you know, adequate length protection on it.
And use a password manager. I do. I think it's great. And closely related to passwords is multifactor authentication.
Yeah. This one, and there's been a lot of conversation over this few years, especially recently with things like, you know, YubiKey and smart card things. There's, you know, you know, a knowledge based behavior is starting to kind of pick up here a little bit more. But just the the notion of what is multifactor authentication, the ability for it to be that additional factor, you want this for the account. And this really kinda goes back to that story I alluded to earlier with with Codespaces.
Right? Because it was just that compromise of that master account, and then they've got the keys to your kingdom at that point. And and even even more so, the the email by which that account is also tied to should probably have a strong password and different password and the multifactor is set up. So I feel like there has to be this notion of, you know, it's why why attack the bank when you just attack the email and reset the password back to the email? Like, you know, let's make sure we put in the right depth here. Well, MFA is is a key component. It definitely makes it harder for threat actors to be able to and try to impose upon your your access.
The the extra credit on this one, and I think you know this, is try not to use the SMS, based, you know, just because SMS can be easily spoofed. You can ask the Twitter CEO of that recently where he was able to be compromised through that. So, there's wonderful apps you can install on your phone that, generate that one time password.
Use that.
And and, I don't know about you, but I now have, four different authenticator apps on my phone for different things. Wouldn't it be nice if if I could use just one authenticator for all of these things?
I'm down to two. I'm down to two. I use Authy because I love Authy because I can control the authentic I can control the encryption key, and I can also back it up.
And which is really great. So that way from a recovery standpoint, right, that's always the fear is if I lose, you know, I I lose the device, and then I gotta go through this lengthy process of pulling out the here's my printed one time passwords that I stored in some of the location and trying to reset all of them. So Authy allows you to have that backup. And then the other one is the, Microsoft Authenticator. Right.
Which, I would suggest this. And if you've got this is this is all of a sudden. I love the idea of trying to go passwordless. And I know Microsoft has been pushing for that. If if you can do it, do it. You know, whether that's Duo or Microsoft, you know, the ability just to eliminate a password and just have that tie to the device where it's just, an approved, it makes the user experience better. World of difference.
Agreed.
Alright. So moving on to the third thing in your list is encryption. Talk a little bit about encryption and why it's important.
Well, I want to talk about why encryption in the cloud is different.
Oh, okay. That we we sometimes confuse this. We think, you know and and, Jenna, we were on the panel back in January, and you've probably heard this phrase where if you think encryption solves your problems, you either don't understand encryption nor you understand your problem.
Or you're being Exactly.
Yeah. Because once you have something encrypted, it now becomes a key management problem.
Mhmm.
How do you secure the key to that?
So the reason why I wanna talk about why encryption is different in the cloud is because this is the key thing. Encryption is a wonderful thing that allows us from a regulatory compliance perspective to attest to a number of things.
Mhmm. Right?
And in the cloud, the notion of it being somebody else's computer, encryption is a key thing that separates that. Now the way how Amazon works and how many of these other cloud providers work is the encryption that is used is a volume level encryption.
So think of it as just a self encrypting drive Right. That you would have in your data center.
And that self encrypting drive, if you throw it on the back of a truck and it's driving off to some mountain that's got a lot of iron in it, and it hits a bump, and this drive falls off, and someone picks it up, and they go plug it in, they can't see the content.
They can't see the contents. Yeah.
So, therefore, we get, you know, safe harbor protection, so we don't have to worry about breach notification because we have that. It's the same thing with why we encrypt our laptops. Right? We encrypt them. We encrypt our phones so that we we don't have to tell people that there could have been their data on that.
Highly applicable to mobile devices. To devices that we expect to to go someplace, possibly get lost, possibly get stolen.
Exactly. So you say, well, what about the cloud? Well, so the cloud works in that this volume level encryption. And I have to say this because the only thing that encryption protects you from in the cloud is the cloud provider itself.
Right.
So volume level encryption. So when we encrypt an s three bucket in Amazon, we are protecting that data from Amazon. And so that when Amazon gets subpoenaed and they march in and grab that server and dump the contents of it, and our data is chartered across all of it, that our data is encrypted. And we don't have to say, hey, customers.
Your data was included with this, and it was unintentional.
Right.
And that's the reduction. But the key is understanding what it protects, but also recognizing what it doesn't protect. It doesn't protect me from accessing that same s three bucket. I'm still gonna see the data in clear text as if I would on the network. And so I think that sometimes people kinda go, oh, well, everything's encrypted.
Yeah.
Well, it is encrypted. And the key to encryption in the cloud, particularly from a regulatory compliance perspective, is if you can control access to the to that server. So I can create an immutable instance where no human has access to that. Everything's built through code, built through pipelines.
No one has access to that. Therefore, now that volume level encryption, our data is encrypted.
Agreed.
I can't see it. So there is, from a compliance perspective, value in just that notion, but people have to understand what that means. I hear you. Access to that server. I see it.
And here's what's difficult is that, if you get maybe an assessor who isn't as familiar with some of these cloud concepts, they're that that's not going to be good enough Or that's going to be that's gonna cause them heartburn because they don't know how to write about it. Because sometimes, for example, PCI has some very specific language. And then you're supposed to write to that specific language. And sometimes, the way the cloud does things, it it it's absolutely adequate and it's absolutely covered, but then you go to write it and you go, oh, I sound like I don't even know what the question is asking Yeah.
Because I'm answering it in a different way. Or do I really want to do a, compensating control for this when when the reality is that it's not compensating for anything. This is just not something that happens in this way there. Right?
Yeah. And so so one of the things that that I generally recommend to people who ask me about this is if you are super clear about how the compliance requirements work and how your cloud provider or cloud solution covers those those requirements, you're going to win your your battle a a lot quicker without having to do stuff that's kinda dumb.
Yeah. Now a lot of one of the fundamental principles that I operate in security is can you defend it? Yeah. And that goes from anywhere.
It's we're gonna make a decision. Well, can you defend it? Right? Can you tell me, you know, tomorrow, a week from now, a month from now why you did this?
Oftentimes, there's this idea in security that we have to go for perfection.
Right.
And I am I am under the opinion that pretty good will always be better than perfect, unless you're the government guarding the nukes. Right? Then you have to have perfect security because that's required. But for the average company, pretty good is is better than perfect because perfect is hard to prove. It's very expensive to implement. It's very hard to maintain.
And so for that, it's like, you know, can you can you just tell a good story? Right?
Yeah. And active actively doing business is very different from, not deploying a nuke. So so there's that Exactly.
You know? And I think it's very interesting even just like on risk. Right? Sometimes, you know, especially cybersecurity professionals, we we like to throw risk around.
We say, that's very risky. Right? And then we say, that's gonna be a risk, and we may quantify it with some range. But we also have to remember that we work for a company, and that risk to the business of not doing something or exploring new markets may be greater than any of that cybersecurity risk that's there.
And so I think sometimes, you know, that the the traditional security, you know, we have that curmudgeon. Right? The the Ministry of No. Right?
Yeah.
I think I've been called the Fourth Reich a couple of times.
So oh, dear.
Yeah. It's like the department of no. Right? You know, it's the department of no. And and, I often say it's no.
We should be the department of how. And it's not how could you, but it's it's how can I help you? And it's recognizing you need to get to this place, And how can I help you along the way that I can tell a really good story that when we get audited, we can defend the decisions that we made?
Yeah.
And I think oftentimes people just shoot for perfection and then realize it's too hard and then they end up doing nothing.
Right. Rather than how do I do business and yet still and I I take that approach as well even as an auditor. And so I think that that opens it up the conversations up. So I get to hear a lot of more interesting ideas from people because I'll get calls six months after naught at six months before they even have to to have the next one.
And and they're saying, hey. We're thinking about doing this thing, but we want your opinion on it. Here's what here's what we're gonna try and here's why. And so I get a business justification.
I get their ideas. And then I say, okay. Here's some of the things that might, catch you up. And so so it's that active interesting how can we make the security work around your great new idea.
And and those are some of the best as a as a security professional, those are some of the best conversations I have.
Absolutely agree. I love those proactive conversations. I love our security champions.
The ones that are when I when I talk to them, it is they already know exactly where my concerns are. And I think that one of the things I do wanna say is in our journey to the cloud, six years ago, there was a lot of head butting. Mhmm. And then what I think was is over the few years after that, we realized, that we didn't need to, that we had the same goal.
They did our architects on the development side, they don't want our developers just to go out and and push terrible code up Sure. Because it it causes instability within the organization, and it'll so they had some of the same reasons. So availability was just as much of a concern as we were. They they don't want people having production access because, well, if you make a change in production, it's not in a build pipeline, then well, then if the next time you do a build, you lose the changes that were made.
Right. And so they're sound they become our biggest champions.
And I think that that idea in fact, as an auditor, you might find this different. Where we kind of we headbutted, but we had to find that common enemy.
Mhmm.
And so we turned to the common enemy, which was audit. Yeah. Because that would they would come in there and swing. And I used to say, I'm like, look.
You're gonna have, you know, a stack of audit findings this big unless you fix this particular problem. Yeah. They don't want that. They don't want that audit finding.
They don't wanna have to deal with that.
So they're like, hey.
Help me. I can help you.
And that has been just an amazing journey That is great.
Recognizing that the developer is not my enemy. They are my friends, and they are trying to do the right thing. And I think sometimes security kinda gets that wrong. Right? Unfortunately, we think, well, vulnerabilities are given by developers.
No. They don't yeah. No. No. And if you have the right auditor, that they it it's a a journey of discovery on what's working and what's not, against whatever they're assessing against.
Right? And so Yeah. Then it becomes Yes. In instead of making your auditor your enemy, it's what is that compliance statement that we are altogether trying to figure out how to solve.
Exactly. So getting everybody on the same team, for sure. For sure.
Yeah. Okay. Let's move.
Yeah. So yeah. Let's move on. We I we can keep talking.
Oh my gosh.
We could We could Seriously, we could talk about any one of these seven part series.
Forever. But, Hunter's gonna yell at me if we make this a three hour podcast. So moving on to logging.
Moving on to logging. Yeah. So I think one of the things that we talked about I I we kind of talked about, like, one of the reasons why the cloud has benefits And that when I made that statement that has the capability, one of the fundamental what I think is benefits of operating in the cloud environment is a single visibility plane.
Right. It sure makes it easy as an auditor.
Yeah. And and well, exactly. You think about it on your your traditional data center. I got Syslogs over here.
Yeah.
I have network firewall logs over here. I need to aggregate them over here. You're trying to aggregate this entire thing. In the cloud, you have a single visibility plane Mhmm. That's associated to the management plane. And the key on this one that I always tell people is is just make sure that logging is turned on.
Right.
And and it's not hard. It's there's just ways to always just say, yep. Always make this turned on. You can write Lambda rules to always just make sure that logging is turned on for the services you consume.
But have it there. It's part of telling that good story Yeah. Is the ability that you can say, this is what we did, who did it, why they did it. And and and and so that's why I feel like sometimes we just we assume things are always turned on.
But they're not.
They're not.
Double check. Yeah. It's a it's a quick look at the dashboard. Yeah. For sure.
And that's that logging is related, in a lot of ways to the managed services portion of AWS or of any cloud servers, actually.
Yeah. So managed services, I think, is one of the key values that we have within the cloud. And and anybody who has struggled with the idea of trying to patch servers.
Mhmm.
The idea that one of the key benefits in the cloud is that I can make that a contract item and a requirement for a provider.
Yeah.
And I think about something like the rational database service in AWS. That's RDS. And you can run Oracle, SQL Server, MS SQL, Postgres, Aurora, whatever that's out there, MySQL. And what's great about that is it's a it's a database platform, but Amazon is required to do the patching.
Yes.
And so if you think about this idea where it's like, I don't have to patch the database servers.
Like, what like so you consume managed services. I think there's that idea where it's like SaaS over PaaS over IaaS is kind of the ranking that we always do. Mhmm. Because the further you go down the stack, the more you have to do.
And if you're already in an environment where, you know, why should I spin up an Oracle instance on a e c two instance and have to try to harden that Oracle instance and patch the e c two instance and Yeah.
Don't do that. Deploy it very easily. Just pass that burden off. Right? We talk about risk transference.
Transfer that away.
The extra credit on that one is just make sure especially in RDS, there's little things like little, small versions. Like, they'll always do the patch in the major versions.
Mhmm.
But companies, you know, people could sometimes uncheck a little box that they can kind of avoid the the minor upgrades.
Mhmm.
So I I don't want people to do that, so we just make sure everybody does it.
But Nice. Yeah.
You know, consume anything managed.
It just makes life easier.
Yeah. From from my perspective, every organization I go into that that uses the cloud, the more they abstract their, operations to the services level rather than deeper down in the stack, the the more secure they that they tend to be.
Yeah. And the faster they can move. You know? I think, you know, the the big the big trend that, I've I've noticed over the last couple of years is this concept of serverless.
Yes. And it's really interesting when you talk to people because it's like, we'll run a vulnerability report. There is no server.
Well, there isn't a server.
It's just not yours.
Right? It's not it's not your responsibility. It's somebody else's.
Exactly. So I've I've left shifted that away. And so now I'm just running code. I'm running code. I'm doing this one microservice here, and I do this thing here. And it's amazing, like, the how much that feeds in agility and scale and velocity, you know, these these buzzword bingo terms that people throw out. But, yeah, it definitely helps us move quicker.
When I have a new customer and I do that initial audit review with them and and they tell me I don't have an operating system, you guys are the best. I do a little happy dance. It's great.
You just, like, grab a whole section and be, like, delete. Right? Yeah.
Yeah.
It's all gone. Yeah. I I didn't think that that's the future. Now, obviously, it's how do you secure serverless is you know, there's a reason why these little startup companies have been bought out rather quickly.
Mhmm.
Because it's it's an opportunity. How do you get in that run time? You know? How do you look for, you know, areas of indicators or compromise? So serverless isn't perfect, but, from a development scale, it moves really, really fast.
It it does. Alright then. Backups.
Backups. This this really kinda comes back to the the code spaces story that I shared earlier.
Have a good story when it comes to backups. Nothing says you cannot back up back to your internal network. Nothing says you can't back up to another cloud provider. Nothing says you can't back up to another account.
The key on this one is tell a good story. What you what I would suggest is companies not try to create, like, a backup account Mhmm. And back up everything there because now you might as well just have a gold mine with some arrow signs on it. Because it's like, well, forget attacking the app.
Just go after the backup. And I think that there also needs to tell a good story around recovery.
Uh-huh.
Right? You know, it's great to have, you know, processes that can always back up, but who's authorized to initiate that recovery?
Right.
And where can they recover to? We often talk about, like, you know, the largest one of the largest Amazon, regions is US East one. It's in Northern Virginia.
Sure.
And there's five availability zones. And so you're kind of everyone's stacked. Now if if US east one goes down and everyone wants to recover to US east two, which is somewhere in Ohio, there's three availability zones, which means it's not big enough to take the gigantic funnel that's gonna be, you know, coming in there. So Right. Part of your backup needs to consider, okay, if I'm gonna replicate to another region, what is that gonna look like? If I'm gonna recover to another region, is everyone else recovering at that same point too as well?
Sure.
And just have, like just have a plan. Right? Tell a good story on it. Back up on prem, other locations.
Just don't put yourself in a position where recovery is not possible.
Right. And it's important to note that some for example, if you're in the HIPAA space, you have availability.
That's a critical thing. Whereas if you're in the PCI space, it is confidentiality and integrity. Right? So so so knowing what you have to provide for might change your backup strategy a little bit.
Great point. Yeah. Even for privacy, if you've got, GDPR. Right? Country of origin and residency are huge requirements.
And so, you know, you don't wanna back up to another region that is out of compliance with things like GDPR. So I think a lot of it is just trying to have that plan and just think through it. Who's authorized to recover?
Yeah.
You know you know, do we allow that? Right? Or is that kind of a break the glass model where, like, we only allow people to have that? Because last thing you want is somebody to, you know, attack your application and then blow away your backup.
Sure. And then having input from the business so that the technical side can make good decisions on on these things. You know? You don't wanna have, you wanna have an emergency mode operations for HIPAA where PCI might be able to be down for a couple of days. But how is the technical side supposed to know this if the business isn't part of the planning process?
Agreed. Agreed. And they have to have those conversations. We had a a a opportunity to look at, like, backups for one of our our call centers.
Mhmm.
And it was, you know so it was having conversations with the business that if this thing happened, how do we reroute some of our telephony systems over here, and what would we do on that? And then with that, you brought up a great concern with especially if you're a company that takes credit cards, now you have to make sure it's PCI. Right? So that you're you're you're you're blacking out when someone says, oh, sure.
Here's my credit card number. So there's a lot of considerations that have to play into that. I feel like sometimes we just think, well, it's in the cloud. It's backed up.
Yeah.
Like, that's what the cloud is.
It's just a big backup storage. And and, the the number of people that I've seen, their eyes get big Yeah. And you start seeing the nervous sweats kind of, you know, as you start explaining code spaces and all these things that yeah. Just you you might wanna tell a good story.
Because at some point, if you have to tell that story and it's not there Yeah.
Update that resume. So there it is.
Hopefully not.
Hopefully not. Right? Okay. Positive on this podcast.
Dip. Positive. Usually. Tell us about access.
Yeah. This is really the key is is a lot of it is around how we access the cloud. So, we I I talk about you know, we did passwords before. We talked about MFA.
One of the key just there's opportunities to use modern auth is one of the great things, whether that's, you know, single sign on services that you get, that are OpenID or OAuth or SAML.
Mhmm.
Make sure I think on that one is is try to set that up. There's value in the ability for you to maintain governance over your accounts.
Yes. What you don't want is is that people are setting up their own accounts Mhmm. And, then they leave the company, and you can't pull that back.
Mhmm.
You can't retain that back. So I feel like, especially for smaller companies, that tends to be more of a they just don't have a good story to tell around Right. How how access is granted and and stuff like that.
Sure. They don't understand that you provide access to a role, not to an individual. Because the minute you start providing access to individuals, it gets too granularized, and then you don't know how to kind of well, I don't know what they have access to as they have changed jobs several times in the same company. Right? Or Exactly. Or we don't know that we've gotten every piece of it when they when they left the company. And so making sure, like, the word you used was governance, and that is key in access matters.
Yeah.
Oh, no. Absolutely. And I think one of the most I I I one of the most powerful concepts in the cloud is also its most confusing, and that's identity and access management.
Right.
It's the idea that I can do as fine or granular controls that I wanna do. Mhmm. But what happens is is that, well, you know, I you know, it it even happens in the network security group space. Now, I'm a developer.
I'm trying to get my code in for a sprint. You know, I've got a demo. You know, I I gotta get this thing done, and I'm trying to figure out the security group rules. And I may have taken a networking class at one time in college.
I remember a few ports, so I'm kinda punching in a couple of the ports along the way. I deploy my app. It's not working. And so what do I do is I go to the security group, and I just change it to a zero dot zero dot zero dot zero slash zero.
And then I deploy my application, and it works.
It Uh-huh. Works.
And then I say, I make a little note, come back and fix.
Yeah.
And I know and I don't come back and fix that. And I feel it's the same way with I'm it's that we we try to be granular and say, I only want this role, the ability to maybe read certain assets within this certain instance. Or I only want them to do certain things within an s three bucket. And we start, I'm trying this and I'm trying this, and then there's two hundred I'm permissions just for e c two. Then finally, you just go, you know, if I just do, e c two star on a resource star, everything works.
And It's the wrong way to do it.
Yeah. It magically works, and so does everybody else, and so does the rest of the world.
I think the big All the hackers works for them too.
Exactly. Right? You know, think of it. There have been a number of profile breaches that have been with, with, like, Amazon s three. There was a Verizon NICE breach a number of years ago where Yeah. An employee accidentally opened up the s three bucket bucket to the world.
Yeah.
And, millions of records were exposed in the process. And, that can be solved. Mhmm. Absolutely be solved. And it just so I think sometimes when we look at the cloud and we look at the opportunities, it's I hate using the word solve for stupid, but it's it's the biggest fear that I have is I it's the it's the unintentional.
Yeah.
It's someone accidentally doing an error or doing something that causes this door to open and then allows this flood to happen. The intentional stuff, I'll have to deal with those later.
Right.
But the accidental That's so hard for you to tell.
Right? Yeah. It is. Having someone having that on their, you know, job, on their mind, and and everything with that.
So So we talked about managed services.
What about cloud services?
Yeah. So cloud services. So this is very interesting. So when we think about, the different types of cloud services actually, I have a note here. I wanna make sure that I actually pull this up here so I I get this one exactly right. Because, oh, yes. This is it.
If you're not using a certain thing, a cloud service, turn it off.
Yes.
If and that's, I think, sometimes as we come in and we start testing things out and we say, oh, I'm just trying out. I'm gonna deploy in, basic HTML website, to an s three bucket, make it open to the world. Yeah. I didn't really wanna do that anyway, so you kinda forget about it. And it's still left there. And it still now is that gateway. And so I feel like the cloud is one of these things that, especially in AWS, there's a hundred plus services.
Yeah.
And and and and so there's a security side of this, but let's be honest. There's also a cost perspective. You pay per consumption.
Mhmm.
You know, and so it's one of these models.
And and and I think sometimes people get confused where, you know, the value of the cloud is the ability for it to scale up and down. You pay for what you use. If you're gonna throw something out there that is always on and you want it to be redundant, so you spread it over multiple availability zones. And, oh, by the way, I wanted to have a non prod version that's also redundant.
I know that same instance four times over, and then you wonder why it's four times more expensive in the cloud than it would have been on prem. Right. And so, you know, build to the cloud. But if you're not using it, turn it off.
One of the one of the critical things that I always ask for is I wanna print out of all your services, and I want a business justification for every service that you're using. Because from an from my perspective, every every service is a potential vulnerability. Right? That's Yeah.
That's why I care about it. But when I ask, tell me the business justification for each of these, they say, well, I don't know. I'm like, well, if you don't know, then you shouldn't be using it. Well, we can't just turn it off.
Well, you better figure it out.
That's that's you're absolutely right. I think you hit it right on the the nail on the head on that one because Amazon built AWS because that's how they run their entire company. Yes. So any company can run an entire organization out there.
And they've got everything from VPN services to identity services, everything in between. And if you've already got a VPN service that you're using for your company, then disable. And you can use things like service control policies, that you can put on the organization that then govern for your entire infrastructure. Then never allow anybody to deploy that.
Right.
So just turn it off. But to your point, like, why are you using this service out here? You should be able to know what you're using from a cost perspective, from a security perspective, because there may be things that you don't want. There's a thing like simple mail service, SNS, and or SMS.
SMS. Simple notification service. SMS. And you think about that from, you know, so from our company's perspective, we have, internal SMTP relay servers that we built that when comp when you send email to it, it cannot be sent outside the organization.
Mhmm. That's it. We've built the rules. We've built spent a lot of time building this out.
And we've also got all the other rules that go with email, right? You've got record, you've got retention policies and email encryption, and you're going to take this SNS service and you're going to give it to a developer and say, do secure things with it. They don't know. They just want to send an email.
Alright. Yeah. So in that way, it's like if you know, for our point is is you don't need to use this service. Go consume this other server that's already built over here because of all of the complexities that come with it.
Right. I think sometimes with DevOps, we think, like, I have to own the entire ops chain of it. And it's like, well, yeah, I think ops is you consume things. Right.
You consume centralized services.
Not everybody should be spending up their own No.
B to b services.
Exactly.
That's a lot a lot of management, a lot of headache that come with that.
Yeah. So we only have two more points here, in our list. The second to last one you're doing okay so far.
Yeah. The second to last one is network access.
Yeah. So network access. I think this one really kinda comes down to, like, how are you gonna connect to the cloud? Mhmm. And there's a number of ways how you, as an organization, need to kind of approach this. You can build a VPN tunnel.
You can completely separate it out. You don't even have to have that connection. You if you get really ambitious and you're looking for high speed connections, you can go to, you know, colo facilities like Equinix, and you can go into things like Direct Connect Mhmm. That have a very strong backbone right into the the backbone plane of, of AWS. So you have to be able to look at that. You know, are you gonna allow employees to access, you know, development from home, on personal devices? So I feel like sometimes, you know, networking in the cloud kind of changes a little bit, and I kind of alluded to the notion of of security groups.
Mhmm.
Right? A security group in the cloud, in AWS, is it's it operates on an overlay network, which is just a network on top of another network. And that security group is not protocol aware. Mhmm. You could define a port, but it's not protocol. So if I were a a nefarious hacker, and, I wanna tunnel an SSH session right through DNS at port fifty three, if the security group is gonna allow that on an egress out, nothing's gonna stop it.
Right.
And so I feel that, you know, some ways when we look at network access, that the ability to look for, like, malicious traffic moving laterally, there's there are things that are coming out that are trying to improve upon that.
Mhmm.
But in the cloud itself, I can't go buy a physical IPS, you know, IDPS device and just drop it in their data center because they won't allow me access into when I hook that into the network, how do I know to only inspect these packets and ignore the nine hundred thousand other competitors or Sure. You know, other companies' packets. Right?
Mhmm.
It presents itself some different questions. So I think that when organizations look at networking in the cloud, consider a lot of things. Consider how you're gonna have are you gonna allow access into the cloud? You're gonna create, like, a cloud, like an Internet gateway? You're gonna allow outbound access through a proxy? How are you gonna are you gonna white list? Are you gonna do site categorization?
Because that's all configurable. And if you don't have a good story to tell about how you set up the cloud, well, then someone's gonna say, I need to send this data here, and they're gonna set that thing up, and they're gonna open that access, and bam, you're out.
Yep. Exactly.
So just, you know, in a process, define strategies around how you're gonna do things.
A lot of times, I ask people to look at, like, the cyber the cyber kill chain. Like Absolutely. Any communication path is is a potential for, malicious, activities. Right? And so if you think, at what point is this can we kill this activity? At what point can we be can we be aware of it? And that, I I think, speaks a lot to how you configure networking in in the cloud.
Exactly. Yeah. It's it's one of these. I think, you know, there's so much customization. I think, you know, companies just need to have a to consider a lot of different options.
You know, it's are you do you treat the cloud as an extension of your data center, or is it a completely different isolated data center? Right. Do you want to have connections back in with your internal, you know, company? You know, there's some challenges that come with that.
Right. You know, especially if you're gonna be quick hitting things like active directory.
Yeah. I was just gonna say, if you're gonna have LDAP connectivity into the in into the cloud, that raises all sorts of additional questions and and needs.
A lots of questions. Yeah. Absolutely. Especially when you can kinda consider, like, you know, for the longest time, we we we have a traditional DMZ model, right, where you would have, you know, a separate area. And and, you know, companies build out a separate active directory domain for that that DMZ.
And so just make sure that you're not putting yourself in a situation that you deploy an application that requires a domain to join and that you don't have that separation, that segregation.
Yeah.
That if that gets popped and then suddenly it's a straight shot right to your internal domain controller, Boom. The heartbeat of your company can be compromised. Right? It's lights out. Right.
So Yeah.
Every every every, architectural decision has to come with a risk assessment.
From a, you know, malicious standpoint. How do we or even a stupidity standpoint? Because, honestly, you've gotta take that into consideration.
I saw all of it. When I do risk assessments, it starts at the top. It's external actors. It's internal intentional. It's internal unintentional.
Right? You cover integrity, confidentiality, and availability. The big thing I've been covering a lot is around possession and utility or other areas. So it's a lot of it is really trying to make sure that you have a good idea of understanding what is your risk. Right? I think in the cloud, you know, it's it's it's not that there's a lower risk. It's a different type of risk.
Right.
And this idea that, well, hey. Everything is possible. Well, yeah. Everything is possible. Like, everything's awesome. But, like, really, the key in risk is probability.
Right.
Right? So it's telling that story and then making sure that the right people understand that risk and are willing to accept that risk. And in cases of, like, managed services, transfer the risk.
Right.
Right?
Yeah. To people who they do the same type of security all the time on that aspect.
Okay. So final one is what is stored?
Yeah. This one is and as basic as this sounds, I am surprised in my conversations.
Do you know what your data is, and do you know where it's at? And then who has access to it?
You know, with a lot of different companies, you ask a single question. Should every employee in your company have access to all your data? And you usually see them kinda go, well, no. Right?
And then you ask them, well, what what data do you not want people to have access to? Right? Is it Colonel Sanders' extra crispy, you know, recipe? Is it the Coca Cola formula?
There's something that sits out there. There's some intellectual property. There's something that that you want to protect.
And that may be your customer's data. That may be, you know, how you operate.
And so the idea is that if you're gonna have a cloud environment, know what's out there. Because the first step to secure something is that visibility of knowing what's there. And then you can start going through all the other processes to sit there and go, alright. Well, how am I gonna secure this, and who should have access, and how long should they have access for? And, you know, all these other things come into play. But the amount of times where it's like, well, my company is using Dropbox. Would you know what's stored in Dropbox?
I mean no. I have no idea. You know? But if you go talk to Dropbox, they'll say you got a thousand accounts with your company's email address, and their their that data is connected with all these other companies. Do you know about why they're doing businesses with this?
No? That's it's hard stories to tell. And I feel that, like, as basic as the cloud is, and, you know, it's very complex, but also basic. But if you can't answer that question of what is stored, why is it stored, who should have access to it, start there.
Yep. Can't protect it if you don't know where it is.
Ex exactly. And if you're if you're a company like a pharmaceutical and you're developing a billion dollar new drug, like, you know, maybe a vaccine for a particular, you know, SARS COVID two kind of thing, Like, you know, do you trust putting it out in the cloud? You know, you better make sure you've got all the controls around that that you feel comfortable with that because that's that's worth a lot of money.
And that was such a great list to go through. And and, honestly, we could spend an hour on each one of those topics. I sure your time today. What does, what's the rest of the year look like for you? Are you speaking anywhere? Are you people wanna connect with you? Like, how do people learn more about what you got going on?
I'm on LinkedIn. I'm not very active on well, I'm I'm on it.
A lot of people trying to sell me products.
No. So in terms of twenty twenty, so I applied to speak at the IC Squared Security Congress in November. I think that was scheduled for Orlando, and they think they just announced a couple weeks ago that they're gonna go digital only.
That I put in for went went in for a presentation to talk a little bit more about my company's journey, to the cloud. It's, based off a presentation I gave to the Utah chapter, IC squared, last year. And it's it, it's called an angsty journey.
And I call it two lies and a truth.
And it's it talks about the idea that in that five, six year journey, you know, what I learned as a security professional, what caused me to change and view the cloud differently.
I think oftentimes in the world, we have to consider we have to consider because when we start to consider things differently, we tend to act differently Yeah.
Instead of saying, well, it's always done this way. It's always done this way. Right. And you can't look at the cloud as a data center.
It's a completely different model. I think Yeah. You know, early days of security was is we kept trying to assess it from it's just another data center. Well, it's not.
It's not.
And so that I put that in. Whether it get approved or not, great. If not, you know, I, I hope to present it to a a broader audience because there's value in that lesson learned. And in that, I provide some really strong, recommendations of things that, I experienced.
And, one of a couple of them we talked about. One of them was, like, don't forget serverless.
Yeah. And I think it's Yep.
Wow. This thing is not going away. It's gonna pick up steam. So Mhmm. You know, that kinda caught us flat footed when all of a sudden our developers were running thousands of Lambda processes. We're like, alright.
How do we What do we do with that?
Yeah. Yeah. They're asking for a vulnerability report. How do we get that?
So Well, this has been really terrific, and and, I found a lot of value in in what you had to say. Thank you so much for joining me today, and I I hope to, connect with you again in the future.
Let's do part two. I can we I've got or three. I don't know.
Maybe I've been in the reception, but we've got and there's Cook me up some more topics, Craig.
Yeah. And I think just the conclusion that I would give is is I think companies, you know, they're we tend to be a little afraid of things that we don't understand, and, security tends to be a little bit more standoffish about the cloud. But, again, reemphasize that I firmly believe the cloud has the capability to secure your company's data better better than you could, you know, in your normal data centers.
Absolutely agree with you.
Keyword is capability.
Alright. Well, thanks, Craig. You take care, and we'll talk to you again.
You're welcome. Thanks for having me, Jen.
Thank you for joining us again at the Security Metrics podcast. I hope to see you again next week. Thanks for watching. To watch more episodes of Security Metrics podcast, click on the box on the right. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)