CISSP Domain 6.2: An AI Agent Was Told No and Got In Anyway (373)

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

Welcome And Domain 6 Setup 0:00

Good morning, everybody. It's Shon Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today is Monday, and we have what we always do on Mondays is release a podcast related to the CISSP and the various domains that are associated with it. And today's no different. Obviously, today we're gonna be getting into domain 6.2, and we're gonna get over control security testing and why that's important. But obviously, we usually have, as we start off on all this, we have an incident that kind of brings it to light where why the CISSP domain 6.2 is so important.

AI Agent Bypasses Portal Controls 1:03

Okay, this is on the hacker news. And the hacker news is the statement says OpenAI agent bypasses Australian Medicare portal controls to access non-public files. Okay, so let's get into this a little bit and you'll see how it's important to domain 6.2. So, in relation to this article, the health department's government website did exactly what it was supposed to do. It told them that no one can get in there, you can't get there. Access controls are exactly what they're supposed to be, and you're not allowed in. And you'd think that that would be what would stop it, right? And we deal with this on a routine basis in many different ways.

So there was no attacker, there was no keyboard that attacker at a keyboard that was going at this, there was no bad guys or girls in all of this. This was an AI agent running a research task. I mean, let's quote that: a research task about public health spending. And when that door wouldn't open, when it couldn't get what it wanted, I guess what you know what it did? Yeah, it went and found another way in. And we're seeing this more. This is dealing with all types of aspects related to AI activities. Now, the the twist on this is something that's kind of unique. So everything that the agent did is something that a penetration tester does on a Thursday afternoon.

So, and that's how this all occurred. Same actions, same sequence, and the difference between those two things is what? Yeah, it's a piece of paper. That is pretty much it. And so today we're gonna be talking about domain 6.2, and we're gonna be talking about conducting security control testing, and we're gonna get into half of it that gets skipped. Not the list techniques, but what makes running one of them a test in the first place. Okay, so we're gonna use an analogy in as we go down this path in this article. So think of it this way. So a lot of you out there have done security assessments.

Many of you have or dealt with them in some form or fashion, but also a lot of you probably have really never, other than hearing about it on the exam, have never really done them. So let's look at it this way. When we do security assessments, typically what they do is they're scanning, right? So think of it this way: think of a locksmith is coming to your door and they want to try to get in. They're trying to utilize the security tools, the security scanning tools to get into your place of work or house or whatever it is. Now, if that person who shows up to your house has a signed work order, that's typically what we would call a security assessment, right?

So someone actually has approval to go do that. Now, without one, the same locksmith with the same tools and the same types of activity on the lock, they're basically a burglar. And this technique is identical. So we talk about this when we're getting into from red team and white team and blue team and all these aspects of it. Is the fact of it comes down to is that you are trying to get into some area utilizing some technical skills that you have. And if you use your powers for good, it's a situation where you know what? That's expected. If you use your powers for evil, well, then you start breaking big rocks into little rocks.

And this is kind of where we're going with this. However, nobody did anything evil. Nobody did it, just setting the record straight there. No evil activities, as far as we can tell, have been accomplished. So in mid-June, an AI agent was given a research task, and they were to gather public data on government health spending. Public data, right? That was its job. That's what it was supposed to do. And if you haven't worked with one of these, an AI agent is basically a program. You give a goal to work on, and you say, This is where I want you to go, instead of a list of steps.

Step one, step two, step three. So you don't tell it how to do it, it figures it out the next move. And we've all worked with AI in different forms or fashions, right? It works wonders and it does a lot of great things and really does help in many ways to make your time much more efficient and useful. But when it figures out its own next move, that matters here in a big way. So it goes to the health statistics portal and the portal says, eh-no, you ain't getting in, not allowing it. Well, it tries again. The portal once again says, No, you're not getting in.

No, that's pretty cool if a portal can tell you that. But basically, right? It's it's saying no, you can't get in. And then it quit knocking at the front door and it went and asked a third-party website. Aha, so it's thinking outside the box. A public scanning service to go and fetch that page on its behalf. So the locksmith didn't pick your lock. He sent a courier that was there waiting to open the door for you, and guess what? Oh, it's a courier. You're not the evil guy. I'm gonna let you in. And that's what happened. Now, the interesting part when is that when I was doing red teams is the fact that we would try different approaches and different paths.

But the thing was is we were very careful and cautious on how we did our work because we didn't want to get caught. Well, now AI can do all of that, and you don't have to worry about so much of just if it gets caught, it's like, oh, it's AI. Okay, shouldn't do that AI. So it's a very different, very different animal. So what came back were files that weren't public once it gained access to these systems, aggregated health statistics, internal file names. And to be clear, because some of the coverage on this has gotten a little squishy, there's no evidence that patient records were ever touched.

That was actually found what actually occurred was bad enough without anybody actually embellishing it, because there's really no purpose in all that. Because the reading of these files, if it were to be the case, really isn't the part that should be most concerning. The agency confirmed that this agent also wrote files to an internal server. So think about that for a second. Reading is looking, writing is leaving something behind. And there is not a rules of engagement document on this planet that lets a tester write to a system you sent them to to go look at it again. So this is an important part. This is and it's not what it saw, it's what it left.

Now it also wasn't one door. There were three other government bodies that may have been potentially interacting with this agent. And one of them, the bot protection that was incorporated, stopped it cold. So because it got stopped, what did it do? Well, it went after another pre-production server instead. It didn't give up, it just changed targets. And a month before all of this, there were two other attempts in the United States that didn't work, which kind of tells you the behavior was already there. And yeah, this is a robot or it's a crow, a piece of code. So interesting it is. I guess that's what Yoda would say.

Now, I want to be careful here. Nobody's established that a crime was committed. The government itself said it would seek advice on whether an offense even occurred. What is established is a lot simpler, and it's the reason we're talking about this at all at all. The control said no, not gonna happen. The thing on the other side, however, just kept going, and no one told to do it. No human, no person, no one told it to keep doing that. Okay, one more piece. So the provider of this AI tool found this item on their own, in their own reviews back in August. And they told the agency in September.

However, it was done by email to a public mailbox. That's nearly three months. The Prime Minister called that way too long, and their method of contacting them totally unacceptable. And honestly, yeah, I think that's fair, because realistically, that that's not right. When something like this happens, you don't just send it to a spam box. You actually have to get on a phone and call somebody. But I would say the other half to, because this is also true. They found it and they did report it, which is positive, right? We didn't just go and wash it and brush it under the rug. They actually did report it.

Okay, so let's look at this from the manager's

Why Authorization Changes Everything 8:37

perspective. So every control that got asked a question, it answered it correctly. Now I'm not going to sit here and tell you that nothing was defective because the files were retrieved and the files were written, but the controls that got asked, they still said no. What nobody has mentioned or has a definition of is who even allowed the doors to be pushed? Who allowed this to actually happen? Where did this go? And right there is the reframe. So if your organization has a penetration testing policy, go check it out this week with one question in the back of your cranium. Does it assume the tester is a person?

Somebody with the contract who read your scope and who stops when the scope says stop. Because an agent can't be a party to an agreement, right? It doesn't read your documents, and when it gets refused, it treats it as if it's an obstacle instead of an answer. So interesting it is, we think here. So something to consider as we go through all of this. Now, we're gonna be digging deeper into all these aspects here in just a minute in our training, but this is something that's really, really important. Because an agent can't be party to an agreement, right? It doesn't read your documents, and when it gets refused, it treats it as if it's an obstacle instead of an answer.

So, as this is an important part, as it reduced cyber risk, I'm actually putting forward some an AI governance program. And the program is imperative for organizations. And I'm focused on mid and small and small to mid-sized businesses, but the key on all of this is you have to have somebody accountable. Period. This gets resolved through accountability. And the person who has accountability understands what they're accountable for. So again, something to think about. We'll get into that at another time, but it's these types of governance is so important with this Wild West stuff in the AI world. So here's the thing somebody in your company is already wanting running one of these agents.

Doesn't matter. It's a matter, not a matter of if, it's a matter of when you find out. And I'm sure a lot of them are already sanctioned. I've talked to a couple different, I was doing a V CISO aspect, and one of those I know we are talking about different levels of AI in their organization, and they're sanctioned, right? It's an important part of what they do. But do you really have a good grasp of what these hangs are actually accomplishing within your organization? And is it written down? So when it comes right down to it, here's the question: go ask your data folks and your architecture people who can authorize the test, what is in scope and what is forbidden, even when it is in scope.

So I did in the past with I had red teams, you had a specific scope that you had to stay within. And there were certain caveats that were forbidden. Those need to be understood in documentation, and everybody needs to understand and play in those rules. And if the answer is when you're dealing with the scope aspects, well, we've got a vendor and they said they send us a report, that's procurement. That's not rules of engagement, that's the problem right

CISSP Cyber Training Options 11:34

there. All right, let's get into our training then. Okay, so this is 6.2 security control testing authorization scope and a line nobody writes down, right? So, quote here is a test can be an intrusion, can be one of the same actions in the same order against the same system. However, one is a signature and maybe one doesn't. So before we get started, I gotta throw out a shameless plug, right, for CISSP Cyber Training. So I've got the accelerator, my pro, and my sprint cohort are main three products that I offer at CISSP Cyber Training. $19 a month for the accelerator, it's amazing. It'll help you if you're a self-study person and you want to get at it and get your test done on your own time.

It's got a plan, it'll help you with that. It's awesome. The $39 a month one is the same process. However, it gives you access to me. We have a monthly meeting. We also have access to my CPE Insider, which is a great program for you to get once you get your C your CISSP to maintain your CPEs, and it is an incredible part. A lot more hands-on, one-on-one, and some also special content that is primarily between that's available to you from the cohort. And then finally, the sprint cohort. This is my live eight-week session that's all set up with people that are passing the CISSP exam.

Right now, I've been having great success. A lot of folks are giving great feedback. And again, feedback on some things we need to tweak, but also a feedback on how they like the program. Go check it out at CISSP Cyber Training. Uh, one of the guys that I had, Ray, he just got done passing the CISSP. He made this comment as well as the fact that this is beyond what we're dealing with from a big, expensive $10,000 CISSP program. Now, I'm not taking any shade on any of that. If you want to spend your week doing that and you have the budget to do it, you should do it.

This program is designed specifically for individuals who want to be able to work on it on their own in a condensed environment, but want the accountability to ensure that they can get this test done in a timely manner and they can pass it the first time. And guys have been passing. They have, they've been passing. I haven't had anybody fail yet. That doesn't mean anything other than the fact that they've been had some really strong candidates, have done a great job. But that being said, a cohort, if you're interested in your CISSP to get it knocked out in the next eight weeks, it's there for you.

Next one starts in November, November 17th. It's a morning cohort. Trying that out. Some people have given me feedback that they want to do some in the morning. That's when we're kicking it off, is in the morning, starting on November 17th, a Tuesday. So again, that'd be from 7 a. m. to 8.30 a. m. Central Time. Okay, so let's get into what we're going to talk about today.

Domain 6.2 Testing Terms Decoded 14:06

So there are five subdomains with 6. or domain 6. And we're going to be going over the second one, 6.2, which is dealing with conducting security control testing. So 6.2 carries the longest technique in the domain, and it's one people revise as a vocabulary list because there's lots of different things in it. Now we're going to get into, and we've talked about this at CISSP Cyber Training many times related to the different types of testing that's available. But this is a different, unique approach because of that last incident article we had. And now that we're dealing with AI, it's turning it all on its head, and it's just going to be very, very interesting.

I'm really looking forward to it. It's going to be kind of fun to see how this plays out. It could also be kind of scary, but we'll worry about that when that time comes. So we talked about a locksmith earlier, right? So this is how it's set up. This same locksmith, same tools, one piece of paper. Now you're going, what does that mean? Okay, so if you have a signed work order, like we mentioned, right, that's a security assessment. That's being allowed to go do it. Before I had anybody come in and work on and doing an assessment within our organization, they have an MSA, they have an SOW, uh, there's people that have gotten potentially NDAs, all those three things have been signed.

And those are all being done in place, ready to go. So if the event that something goes sideways, you've got good scoping, you've got it tailored, you've got it set up, where you can go, where you can't go, that's typically a security assessment. So the locksmith model is who asked for it, which doors are on the list, uh, what he may or may not be able to do if they get inside, and then who calls when that person gets in. That is a security assessment. All my red teaming time, we had very tight scope on what we could do. Now, flip side, if you're a burglar, yeah, I just same concept, right?

But I'm not asking permission. I'm just going in and doing whatever I want to do, and I've done that too. I've gone in and basically got into buildings and stole all kinds of stuff and ran away and got into a getaway car. Uh, all legally, of course, but yes, same concept. That is burglary, and that usually carries some level of payment and penalty that goes with that. So, again, this is an important part. A technique will never tell you whether it was authorized. If the exam option describes an action, look for who approved it before you pick it. Uh, authorizations are imperative. Again, thinking like a manager and how the importance of that.

Now, this is the list that everybody memorizes. You got vulnerability assessments, log reviews, code reviews and testing, test coverage analysis, breach and attack simulations. Those are key terms. And I have them on my cheat sheets that you can get available to you at CISSB Cyber Training. Uh, they're part of my cohort program. Uh, penetration testing, synthetic transactions, misuse case testing, interface testing, compliance checks. Oh my gosh, you're like, oh my goodness, how do I deal with all of these things? So knowing the list is not the skill. Matching the technique to the named failure is the skill. And we're gonna get into some of those here in just a second.

One finds it, one proves it. So let's kind of walk through this. So you have a vulnerability set assessment and you have a penetration test. We're gonna kind of go through those two paradigms. If a question and answer says, What weaknesses are present? That would be a vulnerability assessment. Can this weakness actually be used? That would be a penetration test. So again, you're scanning for weaknesses, which ones, all of them are present. A penetration test is can this specific weakness actually be used to take over my blank? Now, what's the typical outlook output? A list is typically the setup on a vulnerability assessment. It's a laundry list of different aspects that you would go through.

And so you'd go through each of those and start checking them off one by one by one. Now, a penetration test is a demonstrated path end to end. So we would do this typically. We would go in, we go run into a block, we pivot, we pivot, we pivot. You keep pivoting until you get to the end goal. Sometimes you had to you hit a roadblock and you have to back out and then go down a next place. And all of that is a demonstrated path. Now, breadth, this is usually my what's the scope of that? What does that look like to you? A vulnerability assessment is wide.

You're casting a wide net. Everything, a very large group, is in scope. In most cases, a very large swath. Penetration test is very narrow and it's very targeted, and it's very scoped out on what you can and cannot do. Now, that scope may it may be narrow, but it may still be pretty wide. There might be a lot of room to play in there, or it could be very, very restricted. It just depends. But think about it that way. Now, how is this run? How are vulnerability assessments run? Well, they're typically automated and they're often set up on a continuous format. I'd have them set up on a weekly basis and they would just chukunk, chakunk, chakunk.

They would keep going, right? And they'd have a report, you go deal with the report, deal with the issues you have, and you move on. A penetration test, this is a person or a group of people that's very time-boxed and scoped, which we kind of already mentioned. Very limited, very specific. But one thing that we did when we do penetration tests is we would also try to do the tests on the time when people were working. So you could have it set up on different types of the calendar, you could have it different types of the day. But the ultimate goal is it is time boxed, and you usually have a very limited time in which you can operate.

So what does it tell you? Right? The vulnerability assessment will tell you about the control. Is that control restricting you? Is it limiting you at all? Is it stopping what's happening? The penetration test is looking for the chain of controls. What are they? One, the two, the three, all of those different chains of controls as they go deeper and deeper into the bowels of the organization. So, what makes a test a test?

Rules Of Engagement That Prevent Harm 19:50

So authorization. Who said yes? Management in writing with the authority to accept the risk if things go sideways. Not the team that wants the test, no, not that. Not the auditor that wants the test, no. It is management, someone who is accountable and responsible. They are the ones that are signing for it. What is in bounds? Name systems, name networks, named accounts, the time window, everything there is listed out by default, not by exception. So what is forbidden? What is the rules of engagement? That is the key part here. This is read, but not to be modified. As an example, do not exfiltrate, do not persist.

When should you stop? If you run into this server, what should you do? I had specific servers that were like, if you're in this area, you're in this network, repeat, I repeat, back out, do not go any further, do not do anything with those servers, do not do anything with those networks. If you get into there, stop, call us immediately. Again, and if something breaks, you have a person to call immediately. That is the key on all this. In the incident that we just talked about, that agent, that AI agent, had none of these. It didn't have authorization, it didn't know what the scope was, and it didn't have anything specifically calling out what it could and couldn't do.

It just decided, hey, that doesn't work, so I'm gonna try this. I'm gonna try this, I'm gonna try this, and it keeps trying it, right? So, rules of engagement is one that many candidates do not understand, and it's the one where this incident specifically broke. It was not defined well in this overall AI goals. It wasn't designed at all. It just basically decided to do what it wanted to do. So let's look about this incident. What exactly happened? It asked for data that it was entitled to. And this was an authorized test, it was designed to do that, and it was set up to go do that.

So that's all in scope. Was refused specifically by the access controls that were there, and that was logged, reported, and should have stopped it at that point. It should have said, Oh, I can't do it, done, not going any further. But what did it actually do? It kept going. So it routed the request via a third party, which is very interesting in the fact that it decided to go. Vote to a third party to get this done. So you should have had it set up specifically around scoping that it needed explicit permission to do this. But it didn't, no permission existed and it didn't have any checks and balances, so it just kept on running.

It read non-public files, and if this was in scope, if they were to be named, that's fine. But nothing was named. And so they didn't know. It just kept on Gooing this thing. And then it wrote files to an internal server. Any rules of engagement would have set up specifically that you were allowed to read, but you are not allowed to write. And it did that. That would have been forbidden by any rules of engagement had specifically had up or set up. And what actually happened? Nothing because nobody had written down any sort of rules of engagement. So the point of this is different. You really have to understand this AI system is going on its own.

It's going rogue and is trying to do what it is basically created to do. So you're going to have to make sure that if you're setting these kinds of scans up, especially with third parties, you need to have very strong rules of engagement defined, and they need to be in some level of paperwork, paper that you have, some sort of contract that is specifically set up for you and your organization. So if you're looking from the CISSP standpoint, that is a huge deal. So what are rules of engagement actually should say? They basically should come down and say you have action limits, read only or read and write.

Nearly always it's read-only. I have yet to see where it would be read write. Now, in the government set situation, we had a little bit broader abilities. And I would actually go and deposit Trojans in certain places to be able to gain access. And that was a right situation. But we had the language to allow us to do that. Persistence, there should be no back doors, no scheduled tasks, no accounts left behind. We were very clear on that. You had to make sure nothing was left behind. No evidence at all was ever left behind. Now I would be lying to you if I said that that never happened, but it did.

Once in a while, and yeah, then people got mad. But persistence, again, you have to define that in your rules of engagement. Stop conditions. When does a test stop? Production outages, real customer data, evidence of prior intruder, all of these things are important that you have set up as a stop engagement. How do they handle the data? If something is found, where's the evidence stored? How is it destroyed? All of those things would be defined in your rules of engagement as well as most likely in your SOW that you may have created. Time windows on which you may run the test outside of the time windows, who's who is authorized to run them.

And then the finally it comes down there in the highlighted bucket, the highlighted area is a point of contact, a named human reachable on both sides. We did have that. You had one person that you contacted all the time. I've really had a couple. We'd have the legal team, we would have the police officer, the main one that was running it, as well as the commander. And all of those are named people that we could call at any point in time and they would answer. So again, something to think about when you're dealing with uh with an exam. Scope says which systems. Rules of engagement say what is forbidden at the system and what is in scope.

If an exam option conflates them, this is a distractor. If it starts messing them up, it's a distractor to kind of push you down the wrong path. So black, white, and gray box.

Box Testing And Control Validation 25:15

So let's get into those a little bit. You hear those terms a bit. So a black box is you have no internal knowledge of what's going on. This simulates the outsider, it's realistic, it's slow, it takes time. White boxes, you have full knowledge, basically the source architecture, credentials, and so forth to be able to get into this. And that allows you to move much quicker through the organization. Now, sometimes you'll start with a white box and you may end up moving into a gray box area. But bottom line is white box allows for much more expedient use. Downside is, is it's not truly hacked, acting like a hacker because they're already coming in with a little bit of knowledge.

Gray box, on the other hand, is a user account with some documentation. So you got a little bit of information, but you don't have enough to be able to do as much as you could with the white box. So again, black box, white box, gray box. Black box is one people misread as unauthorized or unannounced. It's neither of those. The four nobody revises. Misuse case testing, synthetic transactions, coverage analysis, and interface testing. Misuse case testing, this is where they're being used in a way that they were not designed for. It's classically by hostile or someone that's trying to abuse something in place. Synthetic transactions are run on a schedule to confirm a service still behaves correctly.

Coverage analysis measures how much of your testing it actually reaches, and then interface testing is looking at APIs, all those different assets between the systems and the person. So it's an important thing for you to understand each of those. Three things that are not the same. A penetration test, a red team, a breach and attack simulation. Penetration test, can this weakness be manipulated? Can it be used? A red team. They're to know out how good is your detection and your response. They're getting in. How are you seeing them? What are you doing to stop them? And then breach and attack simulation. Do our controls stop known techniques?

Again, this is continuous control validation. So again, the incident named, no adversary, and no catalog technique. Two of these three answered a question it never ever raised. So how did we get here? So a policy that you have in place typically assumes a tester is a person. You need to really evaluate your policies and ensure that it could be a tester or person or it could be something autonomous. So you have your contract tester, they assign agreement, they read the scope documents, they know when to stop versus your autonomous agent, they're not in that place. So you need to make sure that there's a name to it.

And I can't stress this enough to make sure your people are aware before they go and kick these types of activities off. Because again, authorization attaches to a human who answers for the activity. It's this is not a technology question.

CISSP Practice Questions Walkthrough 27:49

Okay, so here are four CISSP questions that we're gonna go over to specifically go related to what we've covered today. So again, you are a security leader at a government agency that runs a health statistics portal. A notification email from the AI provider has just been verified. It states that an automated agent worked around the portal's access controls, retrieved non-public aggregate statistics, and internal file names, and also wrote those files to an internal server. Sounds familiar. The access occurred roughly three months ago. What should you establish first? A. Whether the individual patient records were among those files the agent retrieved. B. How the portal's access control configuration permitted the request to succeed.

C. Whether the incident meets the threshold for notification to the National Cybersecurity Center, or D what the written files are, whether they are still present and whether anything has executed them. So again, this happened. You have a notification from an AI provider. This happened three months ago, and this AI agent worked around you. So again, thinking like a manager, what should you do first? And the answer is D, right? The written files are what are they? Whether they're still present, whether there's anything that's executed them. What you're really doing here is think about it this way. You have to build up, you're going into this cold, you don't have any knowledge.

So you have to understand what are the questions that you would ask because you're going to be asked questions from these different types of auditors. So you have to be prepared to answer them. So go in it with the at that attitude. What are the written what are the written files? Where are they still present? Is there anything that executed on them? What actually happened with them? Where have they been stored? What tell me more about this? Those are important parts that are for you to be aware of. Now, where's the trap? The one that people will glob onto really quick, because one, it's usually the first one, is also the fact is whether the patient records were retrieved.

So, yes, that's an important part, but that is not first. That's probably like like 0.45 or 6, right? Somewhere down the line a little ways. Finding out how this all occurred and where is it happening and what actually came above and how did this information happen is more important because let's just say it's patient health records, but what if it was something else? What if it pivoted to that wasn't what it was after? So you need to understand that piece of it. Okay, so let's look at answer B the root cause, not the triage. Understanding how the request succeeded is the fix, and the fix comes after you have contained it.

Containment is the first thing, but you need to understand what's going on with these systems. Answer C is the obligation, and it's not first. Reporting a requirement is important and the clock is real and you must do this. However, it is not something that must be done immediately. Now, it should become very quickly, but you need to have an understanding of what exactly the problem is because they're going to come around and start tapping you on the shoulder and say, tell us about this. And if you don't have any answers, that's not a good place to be. Okay, so next question. Still at the agency, the board has asked you what you're doing about it.

And your assessment vendor has offered four engagements against the agency's public facing data services. Your concern is specifically around the automated client, the refused by a control. You may find an unanticipated path rather than stopping. Which engagement addresses that? So that's your concern, right? You're still on this problem. What are we going to do? They've basically offered four engagements against the agency's public-facing data service, and you don't know what you should do about this. So A, a red team engagement measuring how quickly your team detects and responds to a sustained adversary. B, misuse case testing that models non-human client being refused and exercises what it does next.

C. Breach an attack simulation, running known attack techniques continuously against your controls. Or D an external penetration test with full scope access across every public-facing service. Okay, so again, you're at the agency, there were the boards want to know what's going on. Your concern is specifically that an automated client refused by a control when it got stopped may find an unanticipated path. Which engagement addresses that? And the answer is B. Misuse case testing, that model, a non-human client being refused, and the exercise is what it does do next. Okay, again, the question comes around there as you're trying to use the misuse this, the system, what is it going to do?

If you misuse it, if I use it in a way that's not designed for, what's going to happen? A red team engagement's the easy one to grab, right? Hey, it's a red team. Let's get them in here and help me find the problem. That's not the right answer. Just because of the fact is that that's like step five or six after you've got to figure it out what actually happened and how, because this system was misused, how did someone gain access to it? So again, important part. Do not bite off on the first one that makes logical sense because you're gonna bite off on. You're gonna think, hey, that's what I need to do.

All right, next question. Your review established that the portal refused every request that reached it directly. The access controls behaved exactly as configured. What succeeded came through a third party and the controls did that the controls did not recognize. Assume for this question that the portal had been classified as low risk and left out of the scope for every assessment and scanned for over four years. So you need to know where else that same condition exists. What must the assessment program add? Okay, so you've basically found that this you've got this system out there, it's been scanned multiple times and it hasn't been looked at for over four years.

So what's going on here? What must the assessment program go to? What must be added? A coverage analysis. This is applied to the testing program itself rather than to any one system. B, penetration testing because a vulnerability scan only identifies no weaknesses while the test demonstrations demonstrates exploitability. B or C, compliance checks against security control baselines across systems currently in the assessment program, or D, synthetic transactions that exercise the portal's query pass on a continuous schedule. Okay, so they're looking what should the assessment program add to the mix? Answer is A. Coverage analysis, right? You need to understand where all of this is in place.

This is how understanding how much coverage do you have, what where are the different venues or different aspects that you may have the same type of situation. This is again knowing your environment. Coverage analysis applied to your testing program itself is more important than any one specific system. So that's the gap. Now, the one the trap is a pen test, right? Because the scan, you find it, you go there, it proves the problem. But that's the trap. You want it, you have to figure out the overall analysis and where you have a bigger problem. Finally, the last question. Now on the other side of it.

Your organization, your data team wants to run autonomous agents to gather information from external public websites. You're just gonna go right back into the fire. Your policy for activity against the systems you do not own defines authorization, scope, and rules of engagement for employees and for contract contracted third parties. Hmm. As a security leader, what should you decide? A require the agents to honor robots. text directives and publish rate limits on every targeted site. B. Require the data team to obtain written permission from the owner of every site with an agent will visit. C. Extend the policy to cover agents acting from the organization's behalf with named owner accounts for each one.

Or D. Add the agents to the scope of the next scheduled penetration test so that their behavior is assessed. Okay, so now which one should you do? Which one should you decide? And the answer is C. A key part in this is extending the policy to cover the agents acting on the organization's behalf. With accountability, we talk about this. You gotta have accountability, and that's the importance of this. So extend your policy to cover the agents acting on the organization's behalf. This is just all the stuff that we're gonna be dealing with here in the near future. Now, the trap, a honor robots. txt and the published rate limits.

Yeah, is it it is responsible and as a good engineer would build, right? They would do that, they would set that robots. txt up specifically, and they would put rate limits on what it couldn't do, could and couldn't do. But that's the technical aspects of this. You gotta look at it from the manager's perspective. So again, things to think about related to this various aspects and authorizations and the use of AI. Okay, so that's all I've got for you today.

Reviews YouTube And Free Questions 36:21

Again, three different ways you can study with me at CISSP Cyber Training, my accelerator, my pro, and my sprint cohort. Go check them out. If you're looking to get your CISSP done, this is the way to do it. No question about it. Again, if you want to go take a week-long cloak course, go for that. That's the way you should do it. But if you're self-studying, this is the proper way to handle it to make sure you have access to all the information you need to pass the CISSP the first time. All right, have a great day, and we'll catch you on the flip side.

See ya. 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 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.