Site icon Easy Prey Podcast

How Secure is “In the Cloud?” with Randall Magiera

Easy Prey
“The majority of malicious actors are motivated by money. They want to get paid. So they’re going to use the cloud in creative ways to get paid.” - Dr. Randall Magiera Share on X

Just because something is in the cloud, doesn’t always mean that it is safe and secure and that you don’t play a role in keeping it that way. Those who move into the cloud need to understand cloud security best practices and how to implement them. 

Today’s guest is Dr. Randall Magiera. Dr. Magiera is a cybersecurity professional with over 15 years of experience in security management, change management, risk analysis, intrusion prevention and detection systems, and vulnerability assessments. He has a doctorate of science in cybersecurity, multiple advanced degrees in cybersecurity and technology, and certifications too numerous to list.

“Just because you have something stored somewhere doesn’t mean it is backed up by default.” - Dr. Randall Magiera Share on X

Show Notes:

“The problem is that people are not familiar with the technical aspect of going to the cloud.” - Dr. Randall Magiera Share on X

Thanks for joining us on Easy Prey. Be sure to subscribe to our podcast on iTunes and leave a nice review. 

Links and Resources:

Transcript:

Randall, thank you so much for coming on The Easy Prey Podcast today.

Thank you for having me.

Can you give me and the audience a little background about who you are and what you do?

I am an adjunct professor at Tulane School of Professional Advancement. I teach undergraduate- and graduate-level cybersecurity courses within the program. I've been in IT for about 15-20 years. I remember starting around 2000 dealing with Windows NT, Windows Server 2000—dating myself here. 

I picked up my doctorate in cybersecurity back in 2017 from Capitol Technology University, and have a decent number of wide-ranged certifications. Of course, I have the Microsoft certifications, the (ISC)² certifications, and all the typical stuff you'd expect from a cybersecurity professional.

That's awesome. What got you into cybersecurity?

I remember working as an IT professional, doing desktop support, doing the help desk, helping people, looking at systems, patching systems, and imaging systems. I'm just like, “Wow, a lot of these companies”—without mentioning who they are, of course—“this is not a very secure way of doing it.” I got more interested in cybersecurity realizing, “Hey, there's a gap and it's something that we need serious help with.” That's really what got me interested in it, specifically. 

With data information privacy, it's the same thing. I'm sure some of your audience has heard not only about GDPR in Europe and California CCPA. We've recently passed Virginia and Colorado privacy acts, which are pretty similar to CCPA. Then, of course, California themselves are updating CCPA with CPRA. 

It's a very interesting field to be in. Things are always changing, especially with cloud technology. When I started, the concept of cloud, no one would have thought of it. I think around 15 years ago—I could be wrong about that timeframe—is when AWS really started releasing their products along with Microsoft Azure and Google Cloud.

Just to see the way technology is advancing is awesome. It's interesting, especially as a security professional, and it's going to be interesting to see where things go in the next 15-20 years as well. I'm really excited about that and really nervous at the same time.

Yeah. I think AWS has probably gotten a bit of the brunt of the cybersecurity negative references. Not so much that AWS has inherently done things wrong or that they've intentionally done things wrong, but people using their platform haven't quite understood what they should be doing. I know in the news, over the years, we've seen, “Oh, there's an AWS instance that was compromised. AWS access wasn't set up correctly.” 

What should someone who's looking to go into the cloud be thinking about in terms of how do I keep this from being my database that gets public?

It's a great question. I’d like to back up. When we talk about the Cloud, AWS, Azure, Google, these systems in themselves are essentially secure, if you will. These companies, even the smaller companies like Digital Ocean, all go to great lengths to make sure that their product is secure, usable, and what have you.

Here’s the thing with cloud computing: it’s up to you to use it. If you use it wrong, that’s on you, the customer. -Dr. Randall Magiera Share on X

Amazon Web Services, Microsoft, Azure, and Google Cloud are all great products. These companies work really hard to make sure their products are secure and usable. But here's the thing with cloud computing: they provide this platform for you to use, and it's up to you to use it. If you use it wrong, that's on you as the customer. That's not on Azure. That's not on Amazon. That's not on Google.

There's this concept called “the shared responsibility model.” You can easily look this up on a Google search. Each of the major cloud providers has these. They say, “Hey, we're Amazon. This is what we're responsible for when you use our cloud service, and this is what you are responsible for when you use our cloud service.” 

When we talk about some of the data breaches that you've mentioned such as the S3 buckets being publicly exposed and data being leaked that way, that's on the customer. That's in their part of the shared responsibility model. 

It's important that when you go to the cloud to not just get your credit card out and sign up for AWS but to really take the time and research what you need to do to be secure when using that product. There are also lots of commercial products out there—I'm not going to plug anyone in particular—that can help you with this as well.

The shared responsibility model, was this buried in the terms and conditions, or is this something that anyone setting it up should have been abundantly clear, “Hey, this is public. Anybody can see this.” Even if you don't think anyone was going to figure out, this is my database.db, I kind of wonder how much responsibility—maybe a little bit more—should rely on the platform providers to make sure that it doesn't accidentally become public.

It's a great question. Unfortunately, there's no real way to properly answer that. It is something that's been publicly available from day one, but it becomes how much responsibility does Amazon, Microsoft, and Google have to push that on their users?

I know for a fact that these cloud companies, especially nowadays, do have these training events where they make people aware of, “Hey, these are the best practices when following AWS, when you're using Azure, or when you're using Google.”

It's a great question. At the end of the day, how much should the customer really be responsible for their product versus Amazon educating them or not educating them?

This isn't directly related to the shared responsibility model I just talked about, but obviously, Microsoft and Google encourage everyone to push their application development to their cloud. They have what's called the well-architected framework, which really is a set of best practices that Amazon will work with you to make sure that your environment is set up and optimized so your application can function as possible. You can push out updates, what have you. Part of that is being secure. It is really a great question. It is something that they make publicly available. 

As I said before, they're working hard to make sure people are aware of this because at the end of the day, like you said, in the news, you're seeing all these breaches and people are associating that breach with Amazon even if it wasn't directly their fault because of a customer not doing something properly.

I guess my mindset has always been that if I'm a network administrator and it's my network, for me, it's easier to think of my perimeter. “This is the edge of my network. This is where my database is inside of my network. I know how to protect it there.” 

Some of the confusion is that all of a sudden, it's now on a different network. It's on a different platform. It's in a different environment that these administrators just aren't familiar with. Is it just being lackadaisical about security? 

I think it quite frankly could be both. I would say it's more people not being familiar with the technical aspects of going to the cloud. 

For example, in AWS, when you create a new virtual server, Microsoft Windows, by default, it's going to open it up to the public internet. In AWS, the basic thing is not necessarily a firewall. It's called a security group. That's what is basically a firewall where you add rules saying, “Hey, only this IP can access this virtual server on this core or what have you.” But when you spin up that new virtual server, it does what's called a 0000.0 ingress, meaning that the whole world can access this server instead of locking it down to a specific IP.

If you're not familiar with the idea of a security group, how it relates to a firewall, and, really, the technical aspects of it, that could be at least where some of the confusion is versus some people just not wanting to be secure, which is definitely another part of it as well. 

In my professional experience, I've seen those scenarios. Obviously, without naming which companies they were at. I've seen that kind of setup as well. It can really go both ways. I think both of what you said are definitely part of it. There are probably even more reasons behind what we see today than what you said.

I think I've seen instances where sometimes I think developers—I’ll throw myself in this category as well—sometimes developers are lazy. While we're testing things, we turn off security. We minimize security because we just want to make sure the thing is working and then we'll ratchet down security later.

Do you see that sort of thing happening where it's like, “Well, we meant to come back and secure it after the fact,” or maybe even got access before the security was rolled in? Do you see people—as part of the development process—leaving security lax and then trying to tighten it up after the fact?

I can see that especially with not all but some startups. When you're following the agile software development methodology, the whole concept is to go quick, quick, quick. Let's move. We’ve got to get our application out. We have to get our CI/CD pipeline up and running. We need to get our updates out. 

Unfortunately, sometimes, things do get skipped. It's not always the developer being lazy. It's just that things happen or a bug gets reported by a customer that's a super high priority. All of a sudden, “Oh, yeah, I meant to do this, but it got moved to the next sprint or what have you.” 

That's definitely a reason, but because of the way everything is, it's just really complicated. I can definitely see software developers—not because they're lazy, but just because they're bombarded with things and they have competing priorities that sometimes they forget to do, especially from what I've seen in lower environments.

You've got your production environment that's super tight and locked down the way it needs to be. You've got your application in front of a CDN—a content delivery network—what have you, but then you have these lower environments that you're using for testing changes. The security on them is a little more lackadaisical, obviously, than a production environment. That in itself isn't a significant risk to the organization regarding production data, but at the end of day, if people are able to compromise those lower environments, they can insert their own code, or more commonly, they'll just throw malware on there and just turn them into crypto miners.

Yeah. I have a funny story to tell about crypto mining. Sometimes, things are totally out of your control. I had gotten a support email from someone saying, “Hey, that's kind of rude of you. I did this with whatismyipaddress.com. Why are you crypto mining in my browser? That's a shady business.” 

I'm like, “I didn't do that.” They're like, “OK, let me look at the code.” There's nothing in my code. I won't say the name of the crypto mining tool because I don't want to go that route, but there was no reference to the mining tool whatsoever in any of my code. 

Maybe this guy doesn't know what he's talking about. I thought, “OK, let me go to a browser, look at all the connectivity, and watch all the things that are going on.” I did that, searched for cryptocurrency mining, and there it was. I'm like, “OK, so it's not on my servers. Where is this thing coming from?”

Like every website owner, you've got not necessarily plugins, but you’ve got JavaScript. It's Google Analytics. It's a GDPR, CCPA, and a privacy policy thing that pops up only in certain states. You've got ads and all these partners that do different things. 

Ultimately, one of my partners downstreamed to them some repository that they were using was compromised and it rolled that cryptocurrency mining script up into my website. Sometimes, it's multiple people are removed before these things happen and you don't know about it.

Yeah. In fact, it's great that you mentioned that. Like I said, we don't want to go too far down that, but just a couple of weeks ago, a popular JavaScript library—the NPM package—was basically, “OK, you're familiar with that, yeah?”

Let's talk about it. It's a little beyond my understanding, but let's talk about that. There was a fairly popular repository that was compromised. What was it, where was it used, and what happened?

It's the NPM package. It's part of a JavaScript library. This is not the first time this type of thing has happened, but they are basically malicious actors. I don't use the word hackers because it offends certain people in the industry when we're referring to hackers as bad people, so I just say malicious actors. 

The malicious actors basically insert malicious codes, primarily crypto-mining malware, but password-stealing malware. Basically, if no one's checking the source code and no one's checking the package, software developers all over the country and all over the world are using this popular package, so they're putting this into their application and rolling it out to production. 

These malicious actors got a heck of a lot of cryptocurrency getting mined through them. This is not that uncommon. It's happened more than once on open-source packages and even on closed-source packages. 

In the whole SolarWinds thing, they basically did the same thing. They're able to—for lack of a better phrase—infiltrate an update, insert their malware into an update, and get that update spread everywhere that runs SolarWinds. 

I think they caught a supply chain hacking, so to speak.

Absolutely. This is not uncommon. In fact, it's going to become even more common. That's why, especially as a software developer, I know we want to talk about cloud security, but when you're looking at these packages, make sure you're double-checking each package that you download, which can be hard because some production applications use dozens if not more of open-source packages to properly function. It's very interesting to see the way that malicious actors are now injecting source code into what they're doing.

It's devastatingly clever at times that it's becoming more and more complicated for the everyday person to know what is safe, what isn't safe, what should I be doing, and what shouldn't I be doing?

Yeah, especially crypto traders. I'm sure you've read about it, but there's malware out there that does nothing other than changing a wallet address to the people behind the malware. You're making a trade, you're copying and pasting that wallet address, and then next thing you know, it didn't go to where you wanted it to because there's malware on your system sending it to the wrong wallet. 

As you know, when you deal with crypto, once you click send, it's gone. It's like Venmo. Once you press that button, that money's gone. That cryptocurrency is gone. Sorry.

Cryptocurrency gives me the heebie-jeebies, not because of the technology, but by how it is so frequently used for nefarious purposes in terms of separating people from it.

One interesting thing—I’m sure you remember the Colonial Pipeline hack that happened. As I said before, I'm in Raleigh, North Carolina, so I felt the brunt of that—skyrocketed gas prices, gas shortages everywhere. People taking 15 buckets with them to fill them up because they think gas is going to be gone forever, whatever the reasoning behind it was. 

The reason I bring it up is because this is the first time I’m actually familiar with what happened, the FBI was actually able to recover some of the Bitcoin used for the payment to the actors behind the Colonial Pipeline hack. It wasn't a lot, but they were able to recover some, which typically goes against the way cryptocurrency works. I thought that was really interesting.

Yeah. I've been reading more and more cases where I shouldn't say the cryptocurrency transactions are being reversed, but somehow, they're able to get some of the money back after the fact. It's kind of interesting. I have not delved deep enough to understand the mechanics of why in certain circumstances they're able to get money back, but it's not what anyone should assume when it comes to cryptocurrency.

Absolutely, especially when actually paying a ransom for a ransomware attack as well. 

From my understanding with the Colonial Pipeline, they watched the Bitcoin being transferred from wallet to wallet to wallet. That's the way it works with malicious actors. I guess they were actually able to seize a couple of the wallets which is how they're able to recover some of the cryptocurrency in that particular case.

That makes sense. They were able to grab it before it got into a different account, all that kind of fun stuff.

Let's get back to cloud security. It's funny because I think of the cloud and I had a sticker once that cloud is just somebody else's computer, which it really is. There are some really amazing advantages to the cloud, pros and cons. 

I'm a huge fan of CDNs, which are content delivery networks. If you're a business or website operator and you have users from all over the world, CDN puts those assets in data centers down the street from your visitors as opposed to halfway around the world. 

I always joke when people visit my site. It's really nice that if they want to get a picture of me and they're in Singapore, they're getting it off a server in Singapore as opposed to that request going all the way to the United States, going to my colocation facility, and then going all the way back halfway around the world. It's really neat the way that stuff works.

I start wondering if we're going to start seeing not necessarily CDNs being compromised, but CDNs being leveraged in malware attacks and whatnot.

I don't doubt that that will happen at some point. As you know, CDNs host static content. There's nothing to stop a malicious actor who's able to gain access to someone's S3 bucket or wherever they store that static content, to modify it—whether it's a picture, whether it's a script, or what have you—and put their code in it. Then, that gets served up to the CDN who serves it up to users worldwide. If it hasn't happened—I haven't read of it happening yet—I think it's only a matter of time before it does.

I suppose cloud security actually works in reverse also in some respect in protecting platforms. Let's say I'm more familiar with Cloudflare. Cloudflare actually does have processes in place to mitigate SQL injection and very common attacks on websites. You can almost see cloud security as a service, so to speak, coming to fruition as well as protecting cloud assets from the public.

Yeah, absolutely. Some of the features at Amazon's WAF—Web Application Firewall)—like you said, protect the SQL injections. They can see requests from known bad IP addresses. They will alert you regardless of what your SIM is. You can use CloudTrail, which is their product, or you can export CloudTrail alerts to your own SIM regardless of what you're using. 

Absolutely they do that. They make those features available to their customers—usually at a premium, of course—so that they can protect their application. It's just one less thing that they have to worry about. They actually still have to ensure that their databases are properly designed in that they can't be hit by a SQL injection to begin with, but that extra layer of protection is always nice.

What do you see as the future risks of cloud platforms? Obviously, I think of things like China wants to make sure that if you're a cloud provider, data for users in China is stored on servers in China where we have access to it. What do you see as the future of the cloud and cloud security? Are we going to get to the point where we don't have 2TB of storage on our phone and it's just going to be nothing stored locally?

I think that is ideally the goal, to get everything up in the cloud, if you will. But with the laws and regulations that we're seeing, especially around Europe—you mentioned China wanting data from Chinese users stored in Chinese servers. 

If you're using Alibaba, which is the most popular cloud provider out in China, you don't want to use that. If you're in Europe, you have to worry about GDPR. If you're selling to EU citizens, you have to use a Frankfurt AWS region to store their data. You combine that with a CDN. It makes it a lot more reasonable to go to a German website. 

The future of cloud security is going to be really interesting because you have to remember that a majority of malicious actors are just motivated by money. They're financially motivated. That's the number one most common reason malicious actors are hacking.

Most of them aren't hacktivists. They don't care about who the person is or what they did. They just want to get paid. They're going to use the cloud in creative ways to get paid. I remember reading one thing recently, an article where some malicious actors—actually, they didn't go into great details—I wish they did—used AI to mimic the voice of a CEO and then used that to call the CFO to get a wire transfer going or what have you. They scammed the company using the CEO's voice using AI. 

Things like that are going to be more common. It's going to be interesting to see how the malicious actors will use the cloud further as a means to their end, whether they're hacking it directly or leveraging the cloud to do what they want to do.

I guess that is another thing that could happen. AWS has elastic computing where you can spin up hundreds of thousands of processes to do your AI work for you and then your bad actor doesn't have to have all that computer power themselves. They just spin up instances—probably ones that they've gained from other people's accounts—to do their dirty work for them.

Another thing that malicious actors probably do more often than we realize pretty easily is get someone's credit card information, open up an AWS account, spin up a bunch of EC2 Instances—the virtual servers—install crypto mining on it, and just mine away. 

Then, when the bill comes at the end of the month, the person cancels their card and the servers get shut down, but all the cryptocurrency that was mined, the malicious actors get to keep. It's not like Amazon can take it out of the wallet or anything.

Malicious actors are just going to use the cloud just like all other forms of technology: as a means to their end. It's going to be interesting to see how creative they'll get. We've seen some really cool stuff. 

Malicious actors are going to use the cloud just like all other forms of technology: as a means to their end. -Dr. Randall Magiera Share on X

In my personal opinion, what I think we're going to see more of are deep fakes. As technology advances, I think we're going to see more deep fakes. I don't really consider mimicking the CEO's voice in the thing I mentioned as a deep fake, but I think we'll start seeing more of that used by malicious actors, because using AWS, they have the technology to create whatever they want and use it however they want.

Yeah. To me, the most worrying is if you can do real-time deep fakes, once something like that can happen. It's one thing if a bunch of guys in their offices with a bunch of high-end computers and an actor look-alike can create their fake Tom Cruise running around the set. It took them hundreds of hours. It took them quite a few hours to create that video and lots of training, but it's not real-time. 

When people are talking about romance scams or whatnot, the common advice is, “Look, if they're not going to do FaceTime with you, if they're not going to Skype, if they're not going to do a Zoom with you and show a live video of them actually answering questions, then they're obviously a scammer. If they won't show up on video, then they're a scammer.”

But once you've got deep fakes that are real-time, the scammer can sit there in front of the computer, and it changes their face to match whoever it is. Now that they can talk at the same time and not have to make excuses about, “Oh, I'm halfway around the world, my internet connection is bad, let me just turn off the camera,” or, “My camera's not working,” I do wonder if that will be sourced through these cloud computing platforms.

As I said before, these platforms provide a virtually unlimited amount of computer power to whoever needs it, so I can definitely see that happening. That's something that AWS, Microsoft, Google, or anybody else who comes up through the ranks, it’s something they’re going to have to be cognizant of and they’ll practically work on themselves as well.

As I said at the beginning, I'm really interested to see where everything goes in 15-20 years. We're definitely talking about what will happen probably within the next 5-10 years.

That's a scary thing. Let's not just pick on Amazon here. Do you think with Microsoft Azure and Google Cloud that there's going to have to be a step up in taking responsibility or more ownership, so to speak, by the platform providers in enforcing security and watching out for things that are misbehaving on their platforms, as opposed to, “Oh, yeah, we just saw 40 instances spin up that are doing Bitcoin mining. Let's poke at that and figure out if that's a stolen credit card.”

At what point do they have some responsibility in this? Obviously, if it's Microsoft and someone burned a few 100 kilowatts of electricity doing cryptocurrency mining, it's totally trivial to their business model, but at some point, it becomes problematic. Do they have to take a bigger role in preventing this sort of thing from happening on their platforms?

It's a great question. It's something that I like to say people smarter than I should answer. One thing I will say, I normally do. 

If you want a great example of some of the lengths that AWS has done to protect their stuff, if you have a Git repo, go source some AWS credentials in one of your source files. You'll actually be pinged pretty quickly by AWS saying, “Hey, we found these credentials in your repo. Please do something about that because you probably don't want to do that.”

That's good. They're actively scanning to make sure that credentials haven't been exposed, and if they are, they're proactively alerting you to it.

Yeah. They do some stuff, but at the end of the day, from a legal perspective, you signed a contract with Azure. You signed a contract with Google. If you mess up, unfortunately, it's on you. It's not on them.

Without naming names, I've dealt with a company that has a third-party company delete their production data. They were using one of the major cloud providers. They spent one-and-a-half weeks working with a cloud provider—the third-party company, that is—to try and record the data, because for a reason, they also deleted the data and the backup, which we really don't want to go into right now. 

They spent one-and-a-half weeks going back and forth with the cloud provider saying, “Hey, how can we recover this data?” The cloud provider basically said, “Part of terms and conditions. Once you delete the data, it's on you.”

Another great example of this is Codespaces. Do you remember Codespaces? Just for the listeners who have not heard of it, Codespaces is a now-defunct company. This was, I believe, a decade ago. 

Codespaces was trying to compete with GitHub. They were a repo for all your source code. What happened was they were hosted on AWS, just like almost every company nowadays. A malicious hacker was able to gain access into their system, so they sent an email to the CEO or to one in the security team and said, “Hey, listen, I have access into your environment. If you don't pay me off, I'm just going to basically delete everything.”

When they got the email, of course, they didn't pay him. They just went and changed their logins thinking everything was good. But what happened was that the malicious actor had created another account that apparently they've missed. The malicious actor then logged in and deleted most of their production environment and deleted all their backups, shutting them down.

They contacted AWS. They said, “Listen, this was a malicious actor. This wasn't something we accidentally did. Can you help us?” Unfortunately, Amazon said, “No, we can't. We don't retain that data. Once it's deleted, whether it's done by you or somebody else, it's deleted and it's gone forever.”

It's a really complicated scenario. I'll be interested to see, like I said, people smarter than me think of how these scenarios can change or what AWS can do or should do to potentially cut off future security instances.

They do some stuff today. Like I said, checking and scanning GitHub, scanning source codes is a great example. I’m sure they do a lot more than I'm telling you about, but the question is at what point is enough and, “Hey, you did something stupid. I'm sorry, but it's on you.”

I think it's a really good point to mention that I hadn't actively thought about it that if stuff is deleted out of a cloud instance, it's gone. It's not like I have a physical server in a data center somewhere. Sure, I can grab that out, take it to a drive recovery place, and they can do their best to recover some data from it. 

These cloud platforms probably have to go to some fairly extensive lengths to make sure that if someone gets ahold of one of the drives from their data center, that it actually can't be recovered. That brings up interesting issues of backup and having your backup in an instance or in a position where it can be disconnected and should remain disconnected when you're not actively backing up.

Yeah, absolutely. I'm sure it's in their SAC report. I obviously can't discuss their private SAC report, but I'm sure they use full-disk encryption and have a number of controls in place to ensure that their disks are encrypted, so if someone somehow manages to sneak a disk out and walk away with it, they can't recover anything from it. 

With a number of services that are out there, not only are their regular backups, but their Glacier, which is kind of cold storage because it's technically sitting in a disk on a shelf and when you want it, you have to wait a half hour for the automated arm to go grab the disk, plug it in, and get your data on backup. It's interesting.

Another thing to mention is the way a lot of these cloud providers work. It depends on the service, but just because you have something somewhere—like if you have an EC2 Instance, for example—there's no guarantee that it's even backed up, to begin with, by default. 

I'm going to go with an AWS because it's the one I know the best. Your AWS's S3—they’re simple storage services—it's actually backed up in multiple locations. The way AWS works is you have these regions. You have US east, you have west, you have Frankfurt, and then you have what is called availability zones. The availability zone in itself is a data center. The region is simply a location. 

When you spin up that EC2 instance, that server—unless you paid that extra money for it to be in a different AZ or multi-AZ—is just in that one availability zone. If something happens to that availability zone, your environment's gone, especially if this stuff's not backed up. 

The S3 servers by default are in multiple AZs, but the EC2 instance isn't. None of these major cloud providers have a track history of losing data and losing AZs, but there are scenarios where it has happened in the past. It's one other thing for people to think about when you're using the cloud. I personally like that it's an extra feature because it gets people to think about it.

Working in IT well before the cloud, the companies I worked at had a data center. If something happened to that data center, we'd be messed up. “I'm sorry, the production's down,” what have you. Talking with management, it's been hard to get that colo backup or a warm DR, a cold DR, or what have you if you're getting your data offsite. 

Whereas with cloud, it's just an extra charge to do multi-AZ. You’ve just got to convince management that, “Hey, yeah, this is unlikely to happen, but for an extra $50 a month or whatever the charge is, we just put this button in. If this area does go down, we're not losing everything and we can be back up pretty quickly.” 

That's one of the things I do like about cloud computing: it builds in DR. -Dr. Randall Magiera Share on X

That's one of the things I do like about cloud computing: it builds in DR. It makes it a heck of a lot simpler for environments than in your traditional data center where you literally have to have a colo, a reciprocal agreement with a different company, or in some cases literally build your own data center halfway across the county, the state, the country, wherever your DR or coordinates work.

By DR you mean disaster recovery, correct?

Yes. Disaster recovery, absolutely.

We easily get into lingo when we talk tech. There's a company that I had done business with. They built their own colocation facility in their own building—a really nice facility—and they have massive storage requirements. But the hassle for them was to build a disaster recovery. Like, “OK, how do we do disaster recovery on the other side of the country such that if something happens to our building, we still have our data, it's still somewhere else, and it's still safe?”

I think this is actually true. Most people's view of data backup is, “Well, if I've got that hard drive and it's sitting in my closet, I've got a backup.” My opinion will be, “Well, if your house burns down, it's not really a backup.” Three copies, two locations, multiple formats, multiple locations, in the cloud, physical, other sides of the country.

Other sides of the world.

That truly is one of the amazing things about cloud platforms. When they're operated properly, something goes down, it morphs around it, the backup instances happen transparently. Maybe with Facebook's outage recently, that's the scenario when the cloud does not perform well.

It's a risk when you tie everything to a single system, when that single system doesn't work and you can't get into your data center to fix that system because the door lock is tied to that system, which doesn't work and you have it fail-secured not fail-opened. It becomes a problem. 

Like you said, one of the things about the cloud is if you can sit down with your company's management and hammer out what disaster recovery requirements are—which is a challenge for a lot of IT professionals. Probably a lot of your listeners are probably sitting there thinking, “Yeah, good luck handling that conversation with my boss.” But hammering those out and actually figuring out what your company wants, needs, and is willing to pay for, with the cloud, you can do that pretty easily.

When you know what you want to do, it can be fairly simple. Like you said, it's just a feature switch. Enable this and this is where I wanted to go. Although I guess I always say, “Always test and try to figure out how to flip that switch yourself.” 

I can't tell you how many people I've talked to who thought they were doing backups of whatever and when something failed, they went to the backup, it was empty, the process had failed six months ago and never recovered, or the tapes were bad because they've never been replaced after being swapped out every day for 16 years. 

Always test the backup plans. Always test the security. Make sure it's doing what you think it's doing.

Yes, and always test your DR. That's common even in using a cloud provider for backups for your disaster recovery. It's still a best practice or requirement for some compliance stuff.

Test your backup, test your DR, and make sure you actually have something that functions or is the same. Say you've been paying for these servers and it doesn't actually function on you, then you didn't need it.

Test your backup, test your DR, and make sure you actually have something that functions or is the same. -Dr. Randall Magiera Share on X

That's the time that you don't want to find out that it's not working.

Exactly.

Let's wrap up here. If people want to find out more about what you do, about your classes, where can they find that?

I am an adjunct professor at Tulane School of Professional Advancement. I have undergraduate and graduate classes. Just feel free to google Tulane SoPA—School of Professional Advancement. You can find anything there. 

You can always reach out to me directly if you have more questions. I am on LinkedIn. Just search Randall Magiera. I'm always happy to chat about […] and whatever topic that you guys like. 

To learn more, just google Tulane SoPA. We have a great program and lots of very interesting classes. I teach the cloud security class, and I've got some really great examples of real-life breaches that I incorporate into the class material. It's good stuff, it's a good program, and obviously a great school. It's Tulane University.

Awesome. We will make sure to link to both your LinkedIn profile and to your page on Tulane. Thank you very much. Have a great day.

Thank you, you too.

 

Exit mobile version