CISSP Domain 2: Asset Security - A Secret URL Is Not Access Control (368)

Machine-generated from the episode audio, with names and acronyms corrected. Spoken wording is otherwise unedited, so expect the occasional rough sentence.

Why CISSP Requires Real Reasoning 0:17

Good morning, everybody. It's Shon Gerber with CISSP Cyber Training and hope you all are having a beautiful, blessed day today. Today's Monday, and we are going to be getting into some various aspects related to domain two of the CISSP exam. So this is going to be awesome. We're going to get into as we do on our typical podcast. We have an incident. We kind of go from the incident, we roll into some training around it, and then we finally end with some CISSP questions that you may end up seeing potentially on the exam. But the bottom line is we're not teaching you here how to basically pass the exam from understanding and memorizing questions.

We are here to talk about the information you're needed so that you can make a good logical choice when the question arises. I just I've always come to this point where you see a lot of people out there talking about how do I memorize these questions? And this works great when you're looking at other types of certifications, such as Security Plus, Networks Plus, and so forth. The questions being memorized can do a lot for you in those cases. But the CISSP is not that way. As we all know all too well, the CISSP is about understanding the knowledge behind it and making good logical choices as a manager or leader would.

So let's get into what we're going to kind of talk about from the incident that came up recently

Nine Million Images Left Unlocked 1:40

that basically caught my eye. So there was 9,042,977 image files. Yeah, that's that's a lot, and 450 gigabytes of images of people. This is adults, people could appear to be potentially miners. All of this was sitting in a database with no password on it and yeah, no encryption. So this is kind of a bad thing, right? Now I'm not saying that this information was stolen, breached, any of those types of activities, but this was discovered by a gentleman by the name of Jeremiah Fowler. And he found this cloud database that contained over 9 million images without any sort of authentication. And this was reported in Wired magazine.

So the bottom line on this is that anybody who knew of this web address could read all of it. It wouldn't matter if you had just the password, or there's no password, but it didn't matter anything else. As long as you had the web address, you were good. There were no access controls outside of that. So this is the part that makes the C as a CISSP lesson as well as a news story in itself. So the researcher reported that the company's defense was this. It wasn't really public because you had to know the specific URL, and that URL wasn't linked anywhere or indexed by Google.

Yeah, that's you guys are all going, oh my gosh. Yes, that's the case, right? It is comes right down to it is security through obscurity. And we all know that that is not a good defense. That's not a good control. Obscurity is not something you want to do. I I did all kinds of stuff in the red team world to try to obscure stuff to so people wouldn't see it. But if you looked hard enough, you could find what we were doing. Obscurity does not work. It's great in some specific situations where it can be helpful when you don't have anything else, but do not count on it as a control.

So again, there were their access control was this. They didn't have any. So if you're if you're going to get audited or any of these aspects, the auditor's gonna say, that isn't gonna really work for me. So this is domain two, asset security. And this is the domain most candidates study and the least that get quietly punished on exam day. And the reason is is because when you exam two is one of those who go, I got it, I got it, I got it. And sometimes you don't necessarily have it. So we're gonna kind of go over some few things that are gonna be important around this.

Now, if this is the first time you're listening to the podcast, I'm Shon Gerber. I have been a CISO, I've led red teams, I've taught in colleges. The ultimate goal is I'm here to help you pass the CISSP exam the first time. Not do like I did and fail it the first time. We want you to pass it the first time. So we're the three sections we're gonna get into is this incident, how it happened, and then basically I'm gonna talk to you about is how I would brief the board. The goal is I'm gonna use real terms, explain each one of them to you, because the exam is gonna ask you questions very similar to how you would respond to the board.

Working as a CISO, I had to do that, and this is an important part. You're not gonna have to dumb it down, because I hate that term, because you're not dumbing anything to anyone, because the simple fact of it is they are very intelligent in what they do, and you are very intelligent in what you do. You're basically gonna do the translation and help them understand what exactly is going on. The training's gonna go over domain two of class classification, ownership, handling requirements, and all the data lifecycle. This is all tied to a PowerPoint that is available to you at CISSP Cyber Training, and you can go through that as much as you'd like.

It's on my blog. So it's all there and available to you. And then we're gonna go over some CISSP questions, and that this one we're gonna get into some different ones that may be a little bit more unusual as usual. Uh, can you say that? The unusual as usual. Um, and we're gonna talk about some different traps that are involved with that. So, bottom line is you're gonna get a lot out of this episode, and that's the goal. We want to give you a lot of information so that you can pass the CISSP. Okay, so what does this come down to? Clarity Check is a reverse lookup service.

This is who the folks that got kind of not pwned, they just had data exposure. Uh, reverse lookup service, they deal with phone numbers, emails, vehicles, and images, all that kind of stuff, right? You've seen the pitch. You match with someone online and you want to know whether they are real or not. So you can avoid the catfishing aspect of this. And so you do that. You go check it out. Hey, is Sean real? Does he really look like someone that is a Greek god or does he look more like Elmer Fudd? Probably more like the Elmer Fudd. So that's but you're checking to make sure it's real, right?

So you upload a photo of them, the server searches the face across the internet and tells you where else it potentially shows up. So to do that, it takes photographs from the public, gazillions of them, millions of them, right? That's their business. And the people generally do get catfished and defrauded. So this tool helps them verify who they're talking to as somebody who's real. And that provides value. And we know working as a red team, my name was Jessica. Yes, and I was very pretty, and I worked very, very hard at getting airmen to basically say, hey, would you like to go out? And I say, well, before we do that, let's talk a little.

And so that point is the same concept. And this is a long time ago, so it's even harder today for people to distinguish between what is real and as an old person would say, what is memorex. So the first is what they collected. The service takes, uploads it from the public, and you upload a photo of someone else, right? Which means the person in the picture generally isn't the person using the service. That raises data minimization and lawful basis questions that are real questions, right? So if you had an ex-girlfriend and you decide you want to upload her picture to see where she's at, who has the rights to do that?

Do you have the rights because you have this picture? Does she consented to that? So yeah, it gets really squirrely real quick. The second problem is where did they do what did they do with it afterwards, right? That's the domain two lesson, and that's where we're gonna end up going. So, what this researcher found was that he found Jeremiah Fowler, that the database belonging to the service was sitting open on the internet. 9,442,977 images. Yeah, that's a gob. 450 gigabytes was all there and available, right? Profile pictures, screenshots, you name it. Adults, people who could potentially be miners, all of that stuff is out there and was available.

Now, no password, no encryption, nothing at all. So I want to be precise. This wasn't what it was and wasn't wasn't. Okay, so again, as we're talking out there and we're sharing all this stuff on the internet, we want to make sure that we're not disparaging anybody or anything or calling something what it is, what it actually isn't. So this wasn't a hack, right? Nobody broke in, nobody stole anything, as far as anybody knows. There's no evidence of malicious access at all. And as a security person, you are gonna see this happen time and again. You're gonna find these situations that occur. You're gonna stick your nose into something because you think, hey, I need to find out about this and this and this.

And next thing you know, you crack open Pandora's box and you find all kinds of things that you were not anticipating. And so there has to be a way to deal with that. Well, this is the situation that occurred. Nobody had to attack anything at all. The data was just simply readable by whomever asked. Now, I see this problem a lot in APIs, and we I talk about APIs a lot on the podcast because I think they are amazing. But I also think that they are the bane of everyone's existence because if they're not properly handled, they can provide all kinds of data. They're a hole in your network that you never had before.

So you got again, there's also have to be careful with the comment about no evidence, and that means what exactly what it says. So Mr. Fowler didn't see anything malicious going on, which doesn't mean anybody didn't read these files, but he did not see anything. So again, with no authentication, no unauthorized read, and an authorized one look identical, this is its own lesson and lesson about logging, right? If you don't have logging, how do you know what's going on? So the defense here is this is what the heart

Why Obscurity Fails As Security 9:15

of this episode. All right, so what is reported the company pushed back. Their position was that data was never really publicly exposed because you had to know the specific web address, and the address wasn't linked to any page that hadn't been indexed by the search engines. Or hadn't, they hadn't been in search, I should say. So the researcher's response was pretty straightforward, right? Those addresses were discoverable. Hello, I suck on them, and he basically saw that what was going on. And then there was no login ever required at any point. But set aside from the URLs being findable, I want you to look at this argument because this is where the exam is at.

The claim is our protection is that we didn't publish the address. That's security through obscurity, which we have just kind of hinted to at the beginning. And the CISSP position that has never been real subtle on this comment, right? Absurdity, obscurity is absurd, right? It's it's not a control. It can supplement a control, but it cannot be the control at all. Because the real comes right down to is whatever type of control is there, it has to have the ability to act. It verifies an identity, it enforces a rule, or the records, what happened, it restores a state. Nobody knows where it is, does not fit any of those.

So this is what this is what I would talk to you about. If an attacker learns one fact, just one, does the protection collapse entirely? So if they know your name, can they get in? Do they know an address? Can they get in? Do they know a password? Can they then take over your entire domain? If that's the case, you know, right there, you that control does not work. So again, if it's yes, you don't have a weak control, you have absolutely no. So, how do we take this from an embarrassing story for this company and get into a teaching opportunity? The one goal that we want to get into is that I've dealt with in all my years of cyber is things happen.

People make mistakes, they do. So, how can you take the situation that you learn and turn it into a teaching opportunity? So the service's own published terms said that uploaded images would be stored for 14 days and then automatically deleted. Hmm. Were they? I don't know. The researcher found images with timestamps as well as well past the 14 days, still sitting there, still readable. So again, there's two failures there. They didn't have anything in place to protect it, and they didn't even follow their own policies. Policies are important. They're not just pieces of paper or electronic downloads that you go, checkbox, I am done. No, that is not the case.

So again, when you don't enforce it and you don't have automated deletion jobs, that is a big deal. So you need to plan for that. So I'll be blunt with you as a former CISO, a documented retention policy that nobody enforces is worse than having no policy at all. Because, and you see this all the time, especially as I dealt with different companies as a consultant, there's a lot of shelfware that sits on a shelf and nobody ever talks to it. Nobody ever does anything with it. So I want you to take away from this, and every GRC needs to understand this that if you have a product, if you have a PowerPoint, if you do any of these things that you have in place and they are not, you're not following them, they are not your control.

They are not something that should be followed, that should be followed. You should go and clean that up. So we take away this from the manager standpoint. So let's reframe all of it. Because when you walk away thinking somebody misconfigured a bucket, you learn nothing. So you're no closer to passing at all. So this looks like a configuration failure. It isn't. It's a classification failure. And classification is hard. People do not like to do it because it takes time, it takes dedicated thought, and you have to bring lots of people in on the discussion. It isn't just the cyber people, it is your legal team, it's your HR team, it's your IP team.

All of these folks are involved in this. So if those images had been correctly classified and they had been written down that something should have occurred, then what everything could have happened is if everything goes downstream, people then would have gone and said, okay, do I have this in place? Do I have that in place? Are the access controls in place? And all of that feeds from your GRC platform, your GRC mindset. So again, I want to bring this very close. Classification is what makes the other controls mandatory. That's its job. It's not the paperwork, it's the thing that converts. We should probably into we must.

And if you're going to be held accountable for this, you again, senior leaders must hold your people accountable for these things. They are not just a placeholder. So as we're looking at this line, I want you to take into the CISSP exam room. You cannot you can replace or you can reset a password, but you can't reset your face, right? So if all that information is now stolen about you, how does that affect the biometrics that are involved, right? A face, a fingerprint, a retina, these are permanent things. Expose them once, and a person carries that exposure for the rest of their life. So it's an important thing for you to think about is ensure that you have everything classified from your public, your internal, your confidential, your restricted.

All of those need to be involved. Okay, so that's the training. Or that I shouldn't say the training, that was the incident that just occurred, dealing with clarity check, right? So you go check it out, Malware Bytes has it. It also was on Wired Reports.

Cohort Invite And Study Push 14:22

Now, before we get into the training, one of the things I wanted to stress to you all is my CISSP cohort. I'm just gonna be very blunt with you. I just had two people that finished the cohort and they both just passed. Now, does that guarantee you if you go to the cohort, you're gonna pass? No. But they studied, they took the cohort, they took the information, and they did wonderful on the exam. So my cohort, still a few slots left. It's gonna be closing in about seven days. It'll be done. September 7th is when it will close and will not be able to be opened again for another couple months.

I gotta put potentially another one in a month, maybe two months. I don't know just yet, but for sure, this one is gonna be closing very soon. So if you haven't bought your ticket on the cohort and you want to get your CISSP done in the next eight weeks, now is the time to do it. There aren't many seats left. There really, truly aren't. I've only got like probably four seats left at this point, and I anticipate those will all be gone this week. So if you are listening to this podcast, I would go jump on it as soon as you can. And you want to get your CISSP done, uh, just telling you, if you want to get that done in the next eight weeks, this will help you with the cohort.

It's a structured plan, a structured format. It's gonna help you with the accountability, and I've got all kinds of diagnostic tools, questions, you name it, to help you pass this exam. So again, go check it out, CISSP Cyber Training and my CISSP cohort. Okay, so let's get into the training and what we're gonna talk about today. Okay,

Domain 2 Asset Security Basics 15:45

so this is the training is set aside and associated with CISSP Cyber Training, and we are gonna be going over domain two. This is domain two is asset security, and we're gonna be focused on classification. So ownership, handling, and the data lifecycle. So, what asset security actually covers? You know, basically, what do we have? Identification and inventory. You cannot protect what you have not found. That means you need to understand what is out there and what is in your organization and inventory this process, the basically the applications, you need to inventory the assets, you need to inventory as much as you possibly can so you know where you are.

And this can be very challenging, especially if you have a large organization. You need to also understand how sensitive it is. This deals with classification. It's judged on the impact of disclosure, alteration, destruction, and it's not on the volume or cost. The sensitivity is not necessarily in that space. Now, volume and cost can have a factor in your overall asset, but it isn't dealing with sensitivity. You need to also understand who is responsible. I will tell you, this is probably one of the biggest issues people struggle with is ownership and the various data roles. Without a data, without a named owner, nothing downstream is ever enforceable.

Because what ends up happening is everybody sits in the room and they all go, not it, not it, not it. And when they do that, nobody is the owner of it. So what must happen to it? Basically, what are the handling requirements and what is the data lifecycle? So, for an example, is if you have data that is extremely important for uh to be managed by lawyers or legal teams, that needs to have a different kind of life cycle. If you have data that can be set up and put into a long-term storage area, that has a different life cycle. All of these need to be defined and they need to be determined before you even start storing the data.

There needs to be some discussion around this. Now, this may change over time, and you may your thought process is that I gotta keep it longer, but that you need to really truly understand what is going to be happening to your data in the long-term plan. So classification makes controls mandatory, and we kind of talked about that earlier. The thought process is, and the comment is you should probably encrypt that. Basically, it competes with every other priority on the engineering board. And it loses, right? This is restricted, and the handling standard requires encryption at rest. Yeah, that's that's required by the owner. And guess what?

Oh, you have to do it. So it's an important part of this. So if you say you probably should, well, you need to get the owner involved and they need to make sure that they're aligned with it. And then at that point, when they define it is restricted, it will be encrypted and it will be protected. Otherwise, you get into this really squishy, wonky world that basically I don't, it's we talked about it at COPE. It's the tragedy of the commons. When if you have a common work area or a common place that uh like the coffee room, if nobody actually owns it, then no one really takes care of it.

Same concept with data classification. If nobody owns it, then nobody really takes ownership of it, and therefore nobody takes care of it. So we're gonna get into some different aspects around the types that you might see. So if you're looking at the slide or just listening on when you're driving to work, government, government and military. This is you're dealing with unclassified, you have sensitive but unclassified now, which is also called CUI, you have confidential confidential, you have secret, you have top secret. All of these are a fixed schema, right? So when I was in the military, you had unclassified information, you had confidential information, you had secret and top secret.

All of those things were available to you, but that's how it typically follows. In the commercial space, you have public, sensitive, private, or confidential. Organizations will come up with their own kind of nomenclature around this, but they do fall in these similar type of buckets, right? The public, the sensitive, the private, and confidential. Uh when I was working in the various companies I've worked with, I get confidential, I get restricted, I get private, those kind of come in. But you need to define what each of those company labels means. So what sets the level, right? Impact of disclosure, alteration, or potential destruction. So what ends up happening is if it's disclosed, how does that affect the company?

If it's altered and it's made, you know, like in the case of a formula for intellectual property, how does that affect you? Or if it's destroyed through malicious concepts, or even accidentally, how does that impact you as well? So classification converts we should into we must, and that's the entire function of data classification.

Roles Owners Custodians And Accountability 20:05

So now there's different types of data roles. Now you have your owner. This is your senior business manager as an example. This is the person who is accountable. They assign the classification, they approve access, and they set retention. I would say in many cases, when I was dealing with intellectual property, there were senior managers that were custodians of the information, but they weren't necessarily the owner. That was the CEO. But it depends on the organization and how you want to do it. The custodian, they deal with the operations and it can potentially be IT. Now, I saw when I was in IT myself, they would come up and say, if I was dealing with intellectual property, well, you guys own it.

I'm like, no, I don't own anything, right? I don't own any of your data. You guys own the data. You tell me what should be there and what should be protected. You gotta define that early. Now, your steward, this is where you have business and data quality. This their purpose is for data quality, business context, and they're not a security context at all. You have the controller, they decide the purpose. They decide why data is collected and how it is used. Your processor, this is your typically a third party, and they will process the data on behalf of the controller. So real CISSP vocabulary, they will, but it names it as an activity.

Processor is an activity, and they will do this on behalf of the controller. Now the controller and the processor can be the same people. I've seen this especially when you're dealing with GDPR. The controller and the processor are called out as the same. But it isn't always that case. Just so keep in mind the controller is they decide on purpose, the processor actually executes, and they're the one that does the activity. Subject, this is the living person, the individual, the data is about. And then user, anyone with potential need with access. So understand this key point. The owner decides, the custodian implements. Accountability does not delegate, not to IT or not to a vendor.

Key point the owner decides, the custodian will. We'll implement. So handling requirements following classification. Marking. So anyone who touches it knows what they have. Is it secret, top secret, private, confidential? What is it? It needs to be marked. If it's not marked, uh what is it? Storage, where it can live and what protections or controls are required there. This is where you have to define this. Again, this is where this, if that clarity check, and we read on the last bit on this incident, they didn't really define that. Transmission, how does it move? Is it encrypted? To what standard is it encrypted? Is it can it be put on thumb drives?

Is it carried in a briefcase? I mean, I don't know. It just depends. How do you deal with that? Access, who may see it and how is that proven? Retention, how long it is kept. This is a requirement and it's not an aspiration. You need to define how long you're going to keep it for. Destruction, how is it disposed of when the retention is over and it's done and it expires? So an incident that's on this list, right? Storage, if you have a situation that we talked about, that incident. The storage, there was no encryption at rest. Access, there was no authentication of any kind.

And then retention, they said 14 days published, and then it should be deleted. That was never enforced. So when you're dealing with that situation with clarity check, and then we talked about earlier on the incident. Again, the key piece in this is that all of these things, if they would have had defined classification around this, it would have defined the storage, it would defined the access, and they had the retention defined, but then there would have been some level of accountability to that. So again, nobody skipped a step. The steps were never mandatory because the data was never classified as anything in particular. It was just data.

So the data lifecycle, these are the different things you're gonna understand. So there's two things the ICS or the CISSP is gonna study or change you on or question you on. You can overcollect. Every record you hold is a record you can lose. It's also us from a standpoint, it's a legal liability in many cases. Data hoarding can be a problem, especially for a company. Now I'm gonna tell you this, right? So you're a company, you're storing data, you've got stuff going on, and you're doing nothing about or nothing bad at all. You are above average, you are a model citizen, but you know what?

You're a data hoarder. You like to keep your data because I just might need it. Well, something happens, something bad happens, and a legal team comes in and says, What kind of information do you have on X, Y, and Z? Now, I will tell you right now, I'm not a big fan of lawyers, except for if a lawyer is helping me. And then I'm very big fan of that. But when it comes right down to it, you all see in the news there are the slip and fall lawyers out there. In a wreck, need a check. Well, guess what? These kinds of folks are looking for every opportunity to basically take advantage of situations.

Now, in cases where people have been hurt and they need legal representation, you bet. That's I'm all for that. But unfortunately, it goes and takes different directions, right? And this is all opinion. This doesn't mean anything, other than the

Handling Retention And Secure Destruction 24:55

fact is that if you are a company and you're storing tons of data, you now have legal liability. Now, I'm not a lawyer, don't play one on TV, just being up in front and honest with you. That is just something from a recommendation and some experience that I've had. So if you've got data and you've got to keep it, keep it for just as long as you have to keep it, then get rid of it. So again, important. Destruction is a phase, not an afterthought. Data has an end of life and somebody has to own it and someone has to delete it. So if you look at the life cycle, you create and collect, you then store it, you use it over and over, you share it.

Yeah, it's awesome. And then you go, okay, we got to keep this for a next X amount of time. But then you have a defined time of after X amount of time has been archived, you destroy it. Again, lots of reasons. You just by if it's not even talk about the legal aspects of it. Let's just go into the fact that data storage in of itself is extremely expensive. So you want to destroy it. So the remnants, you need to know the difference. These differences cold when you're taking the CISSP. Clearing, what does clearing mean? It's overriding, so normal recovery fails. Media stays in the organization.

That's that's just designed, right? You're overriding. Purging, this is a much stronger thing, and this resists laboratory recovery. You can't necessarily pull stuff out. Doesn't mean you can't get it if it's put into an investigation, but it's much harder. Media may actually leave and may be there. Destruction, this is where you physically are dealing with some sort of destruction to it. Shredding, disintegrating, incinerating, pulverizing, running a hammer on it with a screwdriver through it, anyway you want to do it. Okay? Now, when you deal with de-gausing, this is a purging technique. This is not a category. So the categories are clearing, purging, and destruction. But degousing is a technique and it works only on magnetic media only.

SSDs will not work, right? Now there's crypto erase. This is also a purge technique. And destroying is the key. The ciphertext is unrecoverable. Again, it's you're just purging the data. You're getting rid of the crypto that encrypted the data that is there, the overall signature. So you connect to this, right? Inist 888 has three categories clear, purge, destroy. Degaussing and crypto erase is basically sit inside the overall purge category. That is an option that lists that as a fourth and fifth category is a distractor. So when we talk about distractors on CISSP Cyber Training and at our cohort, then we have a thing called spot the trap.

If you go ahead to spot the trap, degousing and crypto erase are not categories. They are basically ways to enforce or to basically go through and purr part of the purging environment. So again, don't bite off on that. So retention. Policy is not enforcement. Policy is the how, the long, and the why, right? How long, how, and why are you going to do this? Regulations, contracts, business needs, all that stuff is written down. Okay. Enforcement is something that actually deletes it, an automated or monitored process with an owner who says delete it. Evidence is a response to get it actually completed, right? It's logs, reports, anything that the auditor can read, that all of these files were destroyed and sent to the shredder R Us.

You've got to make sure you have some sort of evidence to prove that. So again, in this case of this incident, the images were deleted, supposed to be deleted after 14 days. But in reality, millions of the images were substance substantially older than that. And they were still present and readable. The policy existed, but nobody actually did the enforcement. Again, an unenforced policy, a documented policy that nobody actually deals with is worse than no policy at all. So obscurity is not a control. We kind of talked about this earlier. It isn't. A control has to act. Preventative, detective, corrective, deterrent, recovery, directive, compensating. Whatever the type you use, it has to be able to act.

And that's an important part of this. So if can you verify the identity in this situation with an incident? No. Did it enforce a rule? No. Was there a record of the event? No. So none of that stuff had any controls at all on any of the information that was there. They just said because you couldn't see it, it was hidden. It was good. So we're going to look at Kirchhoff's principle. And this deals with crypto. A crypto system should remain secure even if everything about its design is public, with the sole exception of the overall key. The URL is not a key. Keys are managed, rotated, and recruit revocable.

If you just have a URL, that is not that case. So you need to understand that. So if an attacker learns one fact and the protection collapses entirely and completely, that is never a control. It was considered a secret. So when classification happens, who is the person who owns it? So when is that increasing at creation and acquisition is when you need to have an owner for the data that's being set up? This is reviewed on a schedule and on change. Now what I mean by that is that if you say you have a company and through MA they purchase this company and they have all this data, the owner of that is X and Y and Z.

Okay, but at a period of time, you're going to go through and reevaluate whether this is the right person to own this information or not. And this is what ends up happening. So some of the data could be declassified with time, some may become more sensitive as it accumulates. Is there an aggregation problem? Thousands of harmless reckless can't add up to something that it is not. I'll give you an amazing example of this. So when I was in the red teams, we would go out and we would try to capture or liberate as much information as we possibly could with the goals of finding out what was in there.

Well, as we just sucked down tons of unclassified information, eventually you got to a point where you could piece enough of it together to go, I went from unclassified to something more than that. And so that's an important part of having thousands of air quotes harmless records can add up to be a big problem for many companies. Not just the military, but any company that deals with this. So again, we're gonna break down this. Who are they? Data owners, they assign the classification. Security, they define the schema and the handling standards around this. So you as security folks are gonna help them understand what they should do to best protect it.

The custodians implement the required controls that are there. Now you may, as a security professional, be consulting with the custodians to ensure that it's being done correctly. But the custodians are the ones that implement the required controls or at least define them. Then legal and privacy, these set the regulatory floor based on what the information that they know. So where's the failure in this? If nobody is named, no owner, so no classification, so no handling requirements, so no controls, everything stays optional, and optional controls lose to deadlines every time. Every time you have a situation and there's a deadline, and I'm like, you gotta put encryption.

Yeah, we'll do that later. We'll do it in the next sprint. Yeah. If there's no requirement for it, the next sprint will happen and it won't happen there either. So again, I'm just speaking from knowledge and from experience, yeah, watch out for that. So there's five takeaways. Classification makes controls mandatory. The owner decides the custodian implements, handling requirements follow automatically, and a policy without enforcement is not a control. And then the last one, which is the most impressive, is obscurity is not a control. Right? Again, if no one leaks the if it if if it no Okay, so let's get into some CISSP questions.

CISSP Practice Questions And Traps 32:31

So activity Okay, so a retailer contracts a marketing technology vendor to run a facial matching for an in-store loyalty program. The retailer decides which images are collected for what purpose and how long they are kept. The vendor stores the images in its own infrastructure and performs the matching. The exposure occurs at the vendor and then an exposure occurs at the vendor. Investigators find the images were never assigned a classification and nothing ever deleted them. Who's accountable for the classification and retention decisions? A the vendor since the exposure occurred and its infrastructure. B the retailer as the data owner, C, the vendor as the data processor, or D, both parties equally as defined in the contract.

Okay, so think through this again. Where is the trap that's built into this? Who is accountable? So you got a retailer, they're working with a marketing vendor, to run facial matching to an in-store loyalty program. The retailer decides with images are collected and for what purpose and how long they're kept. The vendor stores the images and performs the matching. The exposure occurs at the vendor, right? Investigators find the images were never assigned classification and nothing ever was deleted. So who is accountable? And the answer is B. The retailer as the data owner, because they're the one that set this whole thing up. Now the easy trap would be both, right?

The STEM name's the owner without using the word, but who decides the images are collected? The retailer. For what is the purpose, right? The retailer is doing it because they're trying to understand that and they're the ones that want it. So that's the definition of a data owner, right? The custodian implements it, right? The accountability does not transfer when you outsource the work. Key part. The trap in play is C is tempting because data processor is the generally correct term for that vendor. And under GDPR, they are the vet, they are the processor. But what was it asking for? It was asking for who is accountable.

So this is the trap and it rolls you into. So you gotta read and understand it. Who's accountable for the classification and the retention decisions? Processors describe what you do. The owner describes who decides. Those are different acts of different kinds of aspects that are going on. Okay, so next question. Following an exposure of 9 million biometric image files, a service provider states that the data was never publicly exposed. Oh no. Their position, the storage location, required knowledge of a specific URL, and that was not linked from any page that had not been indexed by search engines. No authentication was required at any point to retrieve the files.

Sounds familiar. How should a security manager characterize this protection? A compensated control adequate given to the low likelihood of discovery. B, a not a control at all. Obscurity does not constitute access controls. C, a preventative technical control that was weakly implemented, or D a detective control since access attempts could be logged. Okay, so this one's kind of an easier one, right? Because we kind of know what the plan is here and what is the answer. And the answer is B. You're right. It's not a control at all. Obscurity does not constitute any sort of access control whatsoever. Because a URL is not the a key.

It's not any sort of encryption whatsoever. It's just a URL. And just because you don't know about it or you make it like 5,000 characters long, that doesn't mean it's going to be a great uh control at all. So it's an important part, right? So in the case of my business, right, in case of CISSP cyber training, I do use obscurity with some of the URLs, but I also have access controls that limit what people can do with it and what they can gain access to. So again, it's an important part. So what's wrong is C is a best distractor on this slide, right? It catches the thoughtful people, a preventive technical control that was weakly implemented.

Sounds mature, right? Obscure obscurity through what am I trying to say? Security through obscurity, right? It sounds like, well, they did a very poor job, but okay, they got it. But that isn't it, right? The issue is it's not even a control whatsoever. Okay, next question. A service's published terms state that an uploaded facial images are stored for 14 days and then automatically deleted. A security review finds substantial volume in those images, well past the 14 days aging. Still present and readable in storage. The data was unencrypted and no authentication was required to retrieve it, which represents the most significant deficiency in the organization's retention and destruction of practices.

A 14-day retention period was too long for biometric data. B. The retention period should have been published in the public terms. C. The retention requirement was never enforced by automated verified processes, or D. Authentication was never required to access the storage location. And the answer is C. The retention requirement was never enforced by automated verified processes, right? So D is true, and it's more than that. It's a single worst security failure in the whole story. Those images are readable by anyone who asks. So if you are the CISO, that's what you fix before anything else. But why is it wrong? So it asks about retention and destruction.

Missing authentication is an access control failure. Real, it's varied, real, it's severe, and it belongs in a different category. But they were asking about retention and destruction. So the answer would be C. Okay, next question. You are the CISO of a large retailer, a different company, same failure mode. An exposure like the one just described has been contained and the effective storage secured. Your board asks a single question. What one change would most reduce the likelihood of this occurring anywhere else in your environment? Your organization operates several hundred storage locations across three cloud providers, accumulated over eight years and multiple acquisitions. Which do you recommend?

A implement automated data discovery and classification across all data stores. B enable encryption at rest across all storage locations. C require multi-factor authentication on all administrative accounts, or D commission a pen test of the public-facing environment. And the answer is A. An automated data discovery and classification across all data stores. It's really hard to know what you have until you figure it out. And if it's been eight years and multiple acquisitions, that's the best thing for you to do at this point. You need to know what is out there so you can best protect it. B is the practitioner's reflex, right? Everything needs to be done with encryption.

Encrypting everything at rest is good. It's achievable. Let's do that. But that isn't the case in this situation, right? Encryption changes what the exposure costs you. It does not change how likely it's going to happen. The board asked about likelihood, right? An encrypted bucket you do not know about, and you still don't know about, and you don't even know exists, you don't even understand how the likelihood is. So they asked you, what is the likelihood about this happening? Comes back to

Program Options And Closing Requests 39:40

you gotta know what you're trying to protect. I say this time and time again, it's really hard to fly an airplane if you're blind. Okay, so the pattern across all four of these, it was never about asset security. Activity is not accountability, right? You gotta make sure you understand who is accountable. Weak and absent are different. So a weak control still acts, but an absent control is very bad, right? It has no control of anything. A right failure, wrong category. One of the scariest true things you can run into is often the kind of failure that you were asked about in the test is different than the actual category they're getting into.

And then impact is not likelihood, right? The control that reduces the exposure cost is one, is not one that reduces how likely it is. You need to match the variable that was basically named. So none of these four of the asset security knowledge, they're exam reasoning, and that's an important part for I keep coming back to is you can have all the knowledge, but you can also work your way to reason through this exam. If you understand how to take the the questions, dissect the questions, take your time, quality over quantity. If you do that, you have a much better chance of passing the exam the first time.

Okay, so there's lots of different things for me. As far as I want to just kind of quickly show you before we end, there's I have my accelerator program, I have my pro program, and I have my live cohort of program that's available for you as well. The cohort is going to be stopping, we're gonna be starting our cohort September 8th. I'll be stopping all people coming in. I've only got a few slots left. I purposely keep it small so that we can have that intimate way of getting all the knowledge you need. I do not try to fill this with 30, 40 people. I got 16 people so that there's accountability.

It's kept small and we do them every eight weeks. So it's an important part for you to kind of consider. Then there's also the pro and the accelerator. If you're trying to do self-study aspects of it, the accelerator is for you. It's $19 a month and it works well. It'll get you everything you need to know to get ready for the CISSP exam. The pro is a bit more, it gives you all this stuff with the accelerator, but it also gives you my CPE insider, as well as there's times that we have monthly cohort challenges that we talk and we go through everything once a month on different types of questions and different types of things that you might be struggling with.

And that's live one-on-one with me once a month. And it's kind of in a group session. I shouldn't say it's not one-on-one, it's in a group session together, but that is on a monthly basis as well. So again, go check it out, CISSP Cyber Training. I hope you guys are doing well. I hope you get this made some sense to you. And if you can give me some feedback, I would love to have any feedback that you can provide to me. So thank you so much, guys, and we'll catch you on the flip side. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback.

Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 363 CISSP questions to help you in your CISSP journey. Thanks again for listening.