Transcript
in the armored car, and then it's in a different vault. And like, they all have kind of their own methods of defense and their own patterns of attack. Correct. Oceans, I don't know what number we're on now. One of those. Oceans 28? I don't know. Something like that. Yeah. This is Compiler, an original podcast from Red Hat. I'm your host, Emily Bach, a senior product manager at Red Hat. And I'm Vincent Dainan, Red Hat's vice president of product security. On this show, we go beyond the buzzwords and jargon and simplify tech topics. And in this episode, we delve into the depths of data security. We've been talking about securing products and keeping malicious actors out of your stack. But what is it you're trying to protect? A big part of security is keeping data secret and safe. We're going to cover what that data could be, why it's worth protecting, and some of the basic policies that will build the foundations for securing an important resource. We spoke with Clarence Clayton, who leads a team of AI risk and compliance professionals here at Red Hat. And he explained what kinds of data organizations keep and why it's such a big target. Oh, I mean, it's, it's like the crown jewel to, you know, how a company operates. When you think of competitive intelligence, when you think of, you know, the secrets of like, you know, how Coca-Cola's recipe is made or, or, or KFC's, you know, herbs and spices, like the data is what is, you know, powering all of that. I mean, those are very, very broad examples, but companies every day, the data is sort of the lifeblood of their organization. And it's what allows them to be able to, you know, make money, service their customers and, and other stakeholders that they have, you know, obligations to. And so there's a, an obligation also and a duty to keep that data safe and secure. So it's really an organization's most precious asset in many ways. Secret recipes are definitely a category. What other kinds of information are we talking about here? I mean, it depends on the, on the space that you're talking about, right? So for a health care provider, probably the most important information for them is their patient's medical records. When you're looking at financial information, right, from a bank or any retail store, their, the list of their customers' credit cards, maybe not so much a brick and mortar type store, but an online store where they have recurring payments, think subscriptions, like they have to retain your credit information. Absolutely. And I think you, you hit on two of like the, the most in need of security types of data, but not all data is really created equal when it comes to that. Like there's a world of data outside of, you know, personally identifying things or financial or health types of information. Does this include like everything else too? I mean, there's some data that probably doesn't matter. I mean, I'll give, I'll give, I'll give a perfect example. For Red Hat, everything that we produce is open source. So exfiltrating our source code would be a very expensive things to do when you could just go to GitHub and get it for free. Exactly. Right? Like you don't have to work too hard to get that. Now, if you're a proprietary software vendor, exfiltrating, you know, like I know looking at my PlayStation, the source code for my PlayStation, right, that would probably be a big deal. Yeah. It's closer to your secret recipe kind of a thing there. If it's something that you need to protect or someone else can copy. Right. I think that makes sense. And I imagine there's going to be different levels of security needed depending on the value of said data. Totally. Absolutely. I mean, like all things, not all data is created equal. Exactly. Doesn't all need to be in Fort Knox, but you know, there, there might be a few different levels there. Correct. So, No, go ahead. Sorry. It's just really understanding what those levels are. So you understand the criticality of your data. What's important, what's not. Exactly. And I think a big part of that is what happens if it gets leaked. So like, what is that worst case scenario? What happens when data leaks? That's when you go into janitor mode. It's got to clean it up. Right. Because at that point you have an incident, something happened that shouldn't have happened. And now how do you deal with it? There might be ways where you can reclaim it. And there might be ways where you can't. Right. I mean, once it kind of hits, you know, a stereotypical dark web, like there's no getting it back. Right. Like, you know, go get a new credit card. Right. Like it's done. Not that I'm advocating for paying ransoms. Right. But like in the case of ransomware, right. You could get your data back if you paid a ridiculous amount in Bitcoin, perhaps. Exactly. So I think that ties into then the level of security is tied to the consequences of it getting out. Yes. And also, you know, the level of out it gets. Yes. So if I can put my, my old school system administrator hat on, this is where backups are so important. Yes, absolutely. 100 percent. Back up your data right now. Yes. Well, you can finish the episode and then go back up your data. There you go. So that's some good context about what needs to be protected. How do companies keep their data safe? So Clarence shared some of the basic policies companies can take to protect their data. So there are many different ways that I think of. One of the biggest ones that comes to mind is when you think about, you know, encryption, encryption at every layer, encryption at rest, encryption in transit, encryption at the web layer, encryption at the database layer. That is going to make it more difficult, certainly, to exploit that data or do anything with an environment if it should get compromised. If you don't have the keys, even if you got to the house, you can't get in the door, so to speak. When you think about it from another perspective is around what we call data minimization. So it's making sure that you're only processing the data that you need to do the job for as long as you need it. If the data is not there, then it can't be exploited. So you need to process and have the data you need to be successful and to meet your commitments. But once that data is no longer useful, just having it sit there allows it to, you know, collect dust, so to speak, and it can, you know, create some additional risks to the company as well. All right. There's a lot of good stuff there. So I'm going to break it out into a couple a couple sections. First of all, let's talk a little bit about encryption. How does it work? It is a secret decoder ring for those who are old enough to know what they are. Jokes aside, it's basically taking your data and using a lot of very fancy math that is way beyond my ability to explain. It uses cryptography like this math to change the data to a format where you require a key to decrypt it. Right. So basically, I can't think of a good analogy at the moment, but it's something that's hiding in plain sight in some way. Right. When you're looking at data moving, say, between your browser and a website, that you can see that there's a stream of data, but it's just a bunch of mangled characters that are completely illogical on their own unless you have the key to decrypt it on either end. Yeah. So matrix code, that's redhead. That's a blonde. The matrix. Yes, exactly. Yes. No, you're speaking my language because I had a whole big cryptography part of my life, too. But as the way I see encryption is along that scale, you know, there's the very basic one where an A is actually a B, so on and so forth. There's all the, you know, 13. Exactly. You can do all the puzzles that way. And then it gets a little further where like you shift it even more and then you go all the way through to like you have to know what specific book it's referencing in order to get the keys. And I think that's that's kind of the level of encryption, except rather than being like a book, it's a whole bunch of math in a secret place. Yes. Yes. It's just it's black magic somewhere. You know, it's I don't understand it. I don't pretend to. I use it, but I don't understand it. It's a trust me, bro. Yeah, exactly. Totally. Yeah. So he also talked a little bit about the different states of data. So there's data in the web layer versus at rest versus in transit. How does that affect how you deal with it, how you can keep it safe? Yeah. I mean, when you're looking at data in transit, for example, which I think Clarence was referring to as the web layer as well, like from a browser to a to a web server on either end, it's unencrypted and it's that transmission that encrypts it so that somebody who's lurking on the network, listening to traffic, you know, sniffing traffic can't actually decode or see what it is is being transferred. So you think about you're going to your banking website, you're putting in your password, your debit card number or whatever that you log in with. Those transactions can't be seen by somebody who's resident on the network. Only you can see it. Right. So that's the encryption in transit. It protects the data as you're moving it. Yeah. The encryption at rest is typically where would you you'd have like your laptop or a folder on your on your server where it's encrypted on the disk itself. And that was actually really interesting because we have a lot of requests for, you know, we need these things with data at rest. I always think, like, what is it what's the thing that you're trying to protect when you're using data at rest? Because in order to use that data, it has to be decrypted. So as soon as you boot that laptop, you boot that computer. All that data is unencrypted so that you can use it right in your day to day work. And then when you shut it off, then it's it's all encrypted. It's cold storage in a way. Right. So your your threat there is somebody stealing your laptop, turning it on and getting access to your data or stealing a machine from your data center to do that. Now, one's going to be maybe easy. Like my laptop could get stolen pretty simply at an airport or a Starbucks or whatever. Somebody backing up a truck to a data center and starting loading up racks of machines is probably a little bit different. It's a bigger endeavor for sure. Correct. Correct. And so and that's where you're looking at the data use. You know, do I encrypt it at rest for a certain type of application or a certain type of system? For sure. Yeah. It kind of sounds like a heist movie. It's like you take it from this vault. It's in the armored car and then it's in a different vault. And like they all have kind of their own methods of defense and their own patterns of attack. Correct. Oceans. I don't know what number we're on now. One of those. Oceans 28. Something like that. So we also talked a little bit about like the lifetime of data and how long you keep it. So depending on what kind of data it is, how long do we keep it? I mean, I think that basically boils down to regulations. Right. And I think Clarence noted it as well. The usefulness of the data. If I have a database full of credit cards that have expired, that's useless information. It doesn't serve me. I mean, even an attacker really can't do anything with it other than maybe get some PII. Yeah. Kind of. Right. Like, neat. This once existed. Right. But maybe I know that person's name. Yeah. And maybe there's an email address associated with it. So the credit card information itself no longer matters. But some of the other information might. There might be a useful stepping stone to some other sort of data that I might be interested in. Yeah. Gap in the armor. Right. But you're not keeping it for those email addresses. You'd be keeping it for those credit cards that you wouldn't be using anyways. So why keep it? Right. So, I mean, there should be a shelf life on data in terms of its utility. There also might be times specified by regulations like you can't keep person identifiable information for a person who hasn't visited your website for two years or whatever. Right. At that point, it's like, yeah, you should totally be getting rid of that information. Right. Yeah. So there's a difference between allowed to still have it and care to still have it. Yeah. And it's like we don't have to hoard this stuff. I mean, I know that data storage is cheap, right? Like hard drives don't cost as much as they did when I got my first two and a half gig hard drive for 750 bucks. I still remember this. Mind you, that was Canadian, so probably cheaper in the US. But I mean, even then, right, like data storage is so cheap, but that doesn't mean we should be keeping the stuff because we can. Yeah. This data does not spark joy. I will let it end its adventure with me. Right. If it's not useful, why do you have it? Exactly. I just should tell me that about all the stuff in my apartment. Well, that's for you to figure out. Fair, fair. All right. So we need to be aware of where the data is, which affects how it needs to be protected. And encryption is a valuable tool. So thinking about the life of the data is important as a last bit. Another aspect to keep in mind is the lifecycle of the data policies themselves. So it's one thing to know the basic policies for data security. But those policies change depending on where the data lives. And Clarence is here to explain how that's changed over the years. And the cloud is such a big part of how we operate. I'm going on a quick tangent. But I was telling some students one day about life before Google Workspace, life before Office 365 and how we used to have floppy disks that we would carry around. And even before USB flash drives and things like that. And they just couldn't even fathom what a world like that was. But believe me, it actually did exist. And I existed in it. So I say that to say, the cloud is awesome because it does reduce the infrastructure footprint that companies have to sort of self-manage. But look, there are situations where it makes sense to run something on-prem as opposed to in the cloud. So thinking about from a data residency perspective, where does it make the most sense to run the data and where do you get the greatest security? And maybe that could be in the cloud or maybe your environment is so secure that it makes sense to really harden it on-prem to keep people out. So that's just a consideration. You have to weigh the pros and cons and the risks and reward of both in cost and make the best decision there. There is a world of difference between the so-called sneaker net and the cloud, for sure. How does that change security policy? Well, I think that in a couple of ways, right? I mean, the first is accessibility of data. If it's in the cloud, by its very nature, it's probably accessible in theory to anybody on the planet. If it's in your data center or like me in my house, this is accessible to me and nobody else. Right. So, I mean, that's one of the things that would change from a location perspective. And then the other thing that I would think to as well is the skills that you have to secure it in the first place. I mean, if you're a company that doesn't have a lot of good systems administrators with security mindset, you might prefer to have your stuff in the cloud because there's somebody else managing that for you. Yeah. Right. I mean, not that you can get away. We know about all the leaky S3 buckets and stuff. There's still some configuration that needs to be done. But by and large, that cloud provider is managing the security of the thing, presuming you configure it correctly, versus me having to set up all the things myself in my data center. Yeah, like you can on some level outsource some of the expertise needed to keep it safe if you don't already have it. And that's exactly what you're doing. Yeah, exactly. And there's a real literal physical access question when it comes to on-prem and the cloud as well. Like, yes, if it were a heist, it's a difference between backing a van up to a building and, you know, just hacking something on the Internet. Well, and that's the thing, right? When you're looking at a lot of these cloud providers, I mean, these aren't small mom and pop operations. They employ a lot of people, a lot of expertise, because it's not just my data. It's not just your data. It's like hundreds of thousands of people's data that they have to protect. So they're invested in making sure that it's as robust and reliable as possible. Exactly. Exactly. It's like a bank with everyone's money versus, you know, whatever money you have in your house. It takes different levels of expertise. Correct. For me, you just need a hammer. For a bank, you need to be a little more sophisticated. Exactly. Exactly. The same is kind of true of data, if you think about it. But that raises the perennial question, you know, where do you store your data in the cloud or on-prem? They have differences and pros and cons and security levels. So what do you put where? I mean, I think it comes down to risk tolerance, preference and expertise. Right. You may have data that is so sensitive that you wouldn't trust it to the cloud. Yeah. But you better have the expertise to make sure that this so sensitive data is protected on-premise. Yeah. Right. So it's not just as simple like is on-prem more secure than the cloud or vice versa. There's a couple of different factors that have to come into play there. And so you really have to kind of think through again, like what's the worst that could happen and can I support this? Yeah. So so like pros and cons for each like cloud, it seems the pros are pretty easy to set up. You can outsource some of the expertise needed and it's pretty easily accessible if it's something you need kind of on a regular basis. But it might be a little bit more accessible than something like firmly on-prem. You might not have like total control over the servers themselves. So you might be subject to, you know, leaks that aren't necessarily your fault. Is that kind of the cloud world? Yeah. I mean, you're you're trusting your data and somebody else's data center and the people who physically operate that. Right. So I mean, there's an implicit trust in the organization that you're giving this to beyond just the cloud access. And we've seen this with security camera devices in the past. Yeah. Right. Where people at lunchtime were watching other people's camera feeds. Exactly. I mean, that's a little scary. Right. I mean, if you want to talk about personal data, I mean, a camera pointing into my living room. Pretty personal. Not what you want. Not what you want. But then on the flip side, you're also looking at cost. Yeah. Right. Because this this comes with cost. Now, depending on the size or the amount of data that you have, which kind of goes back to the early discussion of like, how much data do you keep? Right. That cost might be a determining factor. It might be cheaper for you to have it on prem because you have a mountain of data. Yeah. Or it might be fairly inexpensive to have it in the cloud because you have appropriate policies and you trim what you don't need and it's a manageable amount. I think there's also an element of like redundancy when it comes to the cloud, too. Like it's harder for a server to go out and you lose all your data, I suppose. Yeah. Your backups aren't as urgent if it's on the cloud because they're doing the back. That's part of the service. They're backing that stuff up for you. Presumably. Again, we trust we we trust that they do it. I haven't really heard of too many instances where data got lost in a cloud provider. But I mean, again, I'll put my tinfoil hat on and I'll still have a local backup on prem of that stuff that's out there in the cloud. Your chances are low, but never zero. Yeah. And then on the other side, for like the on prem aspect, the pros there got control. It's harder to access in general, which means typically more secure. Some secure, some expertise notwithstanding. What else am I forgetting there? Kind of from the pro perspective. Yeah. I mean, you have full control over it. Right. Like you can do whatever if you want to turn it off. We want to move it like you can do that very, very easily. Yeah. Gotcha. And then the cons are also probably a little bit more vulnerable to losing data. Power goes out, new flood or something. If you haven't backed it up specifically yourself somewhere, you might be out of luck. And depending on how robust your backups are, how often you need to do it. I mean, if you're looking at, I don't know, we'll pick on the stock exchange for a second. I mean, if you're not backing that thing up like every second, there's a very expensive data that you're missing. If your backup was an hour ago. Exactly. Can you imagine the amount of trades that happen in an hour? Like I can't even fathom the number. I think that's just a pro and con of the control aspect in and of itself. Like you've got total control, but you've got total control and total responsibility. Exactly. Right. You're not outsourcing any of that. You have to have the expertise and the capability to protect the data yourself. There you go. So when we're talking about how data is transmitted and where it rests, that's changed a lot with that introduction of the cloud. And those changes affect the security policies needed to keep that data safe. How much data do you actually need? Earlier, we talked about considering how long to keep data around, and Clarence also pointed out that organizations should be very thoughtful about what data they're collecting in the first place. And so what, again, we talk about often is that data minimization, that deleting data when you no longer need it. And even beyond that, only collecting the data that you need to achieve the desired business outcome. So if I'm just doing a transaction with you and sending you a marketing newsletter, I don't need to ask your gender. I don't need to ask your blood type. I don't need to ask your Social Security number. Those if those pieces of information are not necessarily relevant, processing them unnecessarily bumps up against privacy laws and best practices. And not only that, it really raises the risk to companies because now you're processing more sensitive information than you would maybe otherwise need to in your course of business. I think this is a really important point, because if I'm going to go buy a donut, I'm not going to bring my filing cabinet full of all of my financial information over all time. I'm going to bring a credit card. There's something to be said for collecting only the data that you need in a certain case. So do you have any advice or thoughts or strategies around identifying how much data you need for something? I mean, it's hard. Again, it's very context dependent. But I think the thing that I like seeing nowadays is we are less cavalier with data than we used to be. I mean, there used to be websites that I would attempt to sign up for and they started asking things. I'm like, you really don't need to know that. And so I wandered away. Right. Nowadays, we tend to ask for less information or only asking for it when you when you need it. For example, I like sites where it's like I'm going there for a trial basis and I don't have to provide a credit card until I've decided I actually want to sign up. The ones that want my credit card before, you know, they're giving me a 30 day trial, but at the outset they want my credit card. Less interested. Maybe I'll pass and go find something else. Yeah. Right. So, I mean, when it comes to how much data do you need, it's very dependent on your business. The only thing I would say is like only only collect what you really need, like have those data retention policies and those data collection policies that state we need this data interticulate internally for what reason? Absolutely. I think that's critical. And you mentioned something in there, too, around raising the business risk, like does having too much data actually cause risk to your business? I think so. I think if you have more data than you need and say that's potentially sensitive information and you're you suffer an incident, a breach of some sort, that data gets exfiltrated or exposed. I mean, your liability goes higher. Mm hmm. Right. Because this is information that you were interested with that you mishandled, for lack of a better term. And now it's out there and somebody has to go sign up for some credit reporting that they didn't intend to or what? I mean, again, depending on what the data is. Yeah. The outcomes could be severe. Absolutely. I think it goes kind of all the way from might be spending more on storage than you need to, all the way through to like real critical legal risks or damage to your reputation or the trustworthiness of your relationship with your customers. And, you know, there's consequences to actions. And I think that's worth taking into account before you ever start collecting data. Well, that trust is the biggest currency that any company has. And I mean, breaches happen. OK, I mean, and and companies survive it. Right. But if given a number of alternatives, no one's going to sign up for the least trustworthy. If there's no alternatives, they might. Right. Because they may have to. But if there's options, I'm looking for the one that's the most responsible. Exactly. Like you can you can survive your house burning down. That doesn't mean you ever want it to happen. And I think that's kind of the consensus of the approach on data leaks to don't want them to happen, even in the best case scenario. Yeah. So talk about identifying what kind of data you need, how it can raise your business risk, risk to collect more than that. What about the volume of data? Like, does the volume of data matter from a hardening standpoint? I don't know if it's the volume itself that matters, because, again, that's just disk space. I mean, at the end of the day, it's all disk space. Right. And if it's encrypted at rest, it's like, OK, the compute time to decrypt it as you're as you're going to use it or whatever. And I don't think that's like cost prohibitive in that sense. Right. But I think from a from a hardening perspective, it's not so much the volume that matters as I guess the way that you're structuring your data. Yeah. Because if you have data in multiple places that might open you up to more risk. Right. You may have a hard time like, oh, I've encrypted all these sources of data, but not these ones. Yeah. Or I didn't realize that we needed these sources of data and they were being used in some in some fashion with your organization. Right. Like a good data management policy as well. I don't think we've talked about that, but just managing your data well, knowing where it is, how it's being used, all of those things. I think those are things that will reduce risk and frankly, make things more operationally efficient. Yeah. I like what you said there about, you know, where all the data is, because I think it's not just collect the least amount of data you can manage. It's also have it in the least number of places that you can manage as well. A hundred percent. Like you, if you're looking at like, I have to go fix something or remove something. Where are all the places that that thing is stored? Like I better know or else the thing that's going to get exfiltrated is the thing that I meant to delete all the copies of 10 years ago, but I missed that one. Somebody snooping around and they find it and then, oops, now I have a problem. Yeah. And in a lower stakes kind of version of that, like that's something I come across in documentation a lot of the time. If you have something documented, like even just like a simple process in your product documentation and it's in more than one place, like that's more places you need to update it. It can get out of sync faster. It's harder to find where things are. It's harder to use. So it's minimization maybe is the name of the game there. Well, that and what what mistakes happen when, say, this is a policy or a process document and all of them, but one is been updated and the one guy who has emergency or regular course of work, they're referencing that outdated one and then they start doing things wrong. Exactly. That's, I think, analogous a little bit to the security aspect to the in that situation, it would be they find the one vulnerability. That's the one that they're going to hammer on. Yep. So any kind of last thoughts? I know we didn't really address the elephant in the room either. I think that's maybe something that you'll hear in the next episode. But last thoughts on data security in general. And I think we can allow ourselves a little talk about AI here. Yeah, I mean, the AI part aside, like the data security part is something that I think people don't think a lot about. Right. Like not to put too fine a point on it, but again, when people are looking at vulnerabilities in their estate. Yeah. Right. We talked about this a little bit in the prior episode. It's people, process and tools. We focus a lot on the software vulnerabilities. Right. And maybe a software vulnerability could expose some data in ways that we don't want it to. But those human problems, those human challenges that have access to that data. And this is where like data privilege comes into play. Becky, the secretary, doesn't require access to all the company information that HR has. Yeah. Because if Becky gets phished and she's like, tick, tick, tick, I've installed some malware and now they have access to stuff that she probably shouldn't have had access to in the first place. That's really bad. Exactly. Right. So it's the I think you had mentioned it before, the principle of least privilege or the principle of least amount of data that you have has to be useful, has to be sensible. I have to be authorized to use it. It shouldn't be a free for all. These are these are all part and parcel of it. And I think that that's those sorts of mechanisms would reduce the impact of some of these, you know, human driven breaches significantly. Absolutely. Every access point is a vulnerability and should be treated as such. It's up to all of us to make sure that we're handling data appropriately and keeping it safe. Right. What mitigations can we put in place proactively to prevent turning on full janitor mode and doing cleanup? Yes. No one wants cleanup. Let's let's avoid that. Clean up on aisle six. That's not what I want to hear. Oh, worst day ever. I promised we would only touch on it. And I know we've got a lot to say about AI in this space and we'll save it for the next episode. So join us again. We'll talk all about AI and its implications around data security all the way through what data can be used for in AI all the way through to self-policing. This episode was written by Johan Philippine. And a big thank you to our guest, Clarence Clayton. Compiler is produced by the team at Red Hat with technical support from Dialect. And if you like today's episode, don't keep it to yourself. Follow the show. Rate the show. Leave a review or share it with someone you know that really needs to have this information. And we'll see you next time.
