CCT 295: Practice CISSP Questions - Deep Dive (Domain 7)

Ransomware doesn’t wait for your change window, and neither do we. This episode takes you inside the decisions that matter when privileged accounts start hopping across systems, Exchange servers attract fresh exploits, and the clock is running on recovery. We open with the newest CISA guidance on Microsoft Exchange and translate it into moves you can apply today: enforce least privilege with a real PAM, choose stronger MFA than SMS, disable basic auth, and lock in transport protections that withstand downgrade tricks.

From there, we get practical about TLS and HSTS. Rolling TLS everywhere sounds simple until certificates, ciphers, and legacy services push back. We map a staged path that starts with critical links, reduces misconfigurations, and grows coverage without breaking internal apps. HSTS then adds a policy backbone that reduces user error, blocks session hijacking, and tightens browser behavior, with clear notes on latency, preload lists, and subdomain scope.

When incidents hit, priorities flip. We break down the right call when lateral movement continues during a ransomware event: disable privileged accounts and switch to preapproved emergency access. On evidence handling, we reinforce the nonnegotiable step for integrity—cryptographic hashing before and after imaging—plus secondary measures for custody and confidentiality. Disaster recovery gets the same scrutiny: meeting RTO while missing RPO means your backup cadence or replication policy failed, not your failover drill. We also cover immutable logs with WORM storage to prevent admin tampering and why emergency patches should be followed by a retrospective CAB review to keep governance intact after the fire is out.

If you’re preparing for the CISSP or sharpening day-to-day security operations, this session delivers clear, actionable guidance you can put to work immediately. Subscribe, share with your team, and leave a review to help more practitioners find these practical playbooks. What’s the one control you’d implement tomorrow to cut lateral movement in half?

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

Chapters

• 0:00 Welcome And Domain Seven Focus
• 1:20 CISA Guidance On Securing Exchange
• 4:20 Least Privilege, PAM, And MFA Choices
• 6:40 TLS And HSTS: What To Enable First
• 10:30 Patching, Zero Trust, And Upgrades
• 13:06 Program Plug And Study Resources
• 15:12 Deep Dive Q1: Ransomware Privilege Lockdown
• 18:40 Deep Dive Q2: Forensic Integrity With Hashing
• 21:05 Deep Dive Q3: RTO vs RPO In DR

Transcript

SPEAKER_00: 0:00

CISP sniper screen screen. CISP. Hi, my name is Sean Gerber. CISP and roll your cyber checker in the way.

SPEAKER_01: 0:25

Good morning everyone. It's Sean Gerber with CISSP Cyber Trading, and hope you all are having a beautifully blessed day today. Today is CISSP question Thursday. So we're excited about getting on with you all about some CISSP questions. And today they're going to be focused on domain seven. Yes, domain seven, this is what we talked about on Monday, was related to security operations in domain seven. And so now we're going to be rolling into some five deep dive questions related to domain seven. So what we're trying to do with the deep dive questions is spending a little more time drilling deeper into these questions and seeing a little bit more context around them. Rather than just rolling through a bunch of questions, knowing that, hey, you guys are listening to this as you're driving home. Let's just dig some into them a little bit deeper to give you a little bit more depth and clarity around some different topics. So that is the purpose behind it. Now, before we get started, again, we're going to talk about the article of the day. And this is comes from CISA. So this is the folks that are in charge of infrastructure for the United States. And they just published a new crucial new guidance on keeping Microsoft Exchange servers secure. Now, as we all know, we've seen a lot of hacks lately in the exchange environment. And it's becoming one of those where obviously if you get out access to people's emails, it can cause dramatic impacts to your organization. And so CISA is putting out some information related to this. Now, I'm going to just warn you this isn't groundbreaking, and this isn't like, oh my gosh, what are we going to do? This is this is the best stuff ever. Well, no, it's not like that. However, I mean it is good that they're bringing this information out. And I'm going to highlight some key concepts that you will already probably know by listening to this podcast, but at least at a minimum, you it's just reaffirming and reconnecting that these are important aspects within your company and what any organization should do. So again, this came out uh just as from the organization called IT Pro, and this is with Emma Woolcott, and she wrote this a couple days ago. And but she's talking about basically the surge in attacks against exchange servers and how this is a big factor for many companies. Well, one of the key some key recommendations that come out of this from these best practices that SISA is providing is one that guess what? You have heard this before is restrict administrative access to enforce at least privilege of exchange environments. Oh, shocker, right? So you least privilege, right? We talk about this all the time, but you know, as well as I know that least privilege is something that not everybody does. And they just they get it up, they get it going, they get it moving, and they forget that they should actually put some of these security controls in place to protect their exchange environment. So again, least privilege, right? You and you should store all the credentials for these individuals in what we call a PAM, right? Your privileged access management solution. So there's our again, least privilege, only certain people with certain roles should have rights to the access to the information and to be able to be able to make uh configuration changes to the overall Microsoft Exchange environment. Number two, which is a big factor, is multi-factor authentication. Yes, multi-factor, we hear it once again. Now, one thing I would add a little bit to this multi-factor piece of this is I would avoid the overall texting multi-factor. Now, it's an easy way to make it work, but as we all know, as we've listened to this podcast and also seen any sort of aspects that run into security people, they've all made the comment that texting can be intercepted, you can have issues related to it, and you want to avoid that at all costs. Now, not at all costs. You want to avoid it, right? You want to make sure that you are utilizing the right tools for the right purpose. So multi-factor authentication should be able and disable basic authentication, right? Makes makes sense. Apply strong transport security. Use TLS HSTS to disable and disable older protocols such as NTLM and enable extended protection for authentication services. Okay, so we're gonna dig a little bit deeper in the TLS and H HSTS. So as we know, transport layer security TLS is what's been around for a while now, and it is something that it's using for HTTPS, S SMTPS, LDL, LDAP with the S, F FTPS. I mean, all of these different types of secure aspects is using the ability of H of using TLS. So TLS is an important part of this, and it protects your data in transit, right? So eavesdroppers cannot read or modify. And then it also it's uses asymmetric cryptology, public and private keys for session setup, and then symmetric keys for data exchange. So again, it's a really good tool that a good capability, a good protocol that you can use within your environment. And I highly recommend you use TLS, especially between endpoints. An important part of this. Now, what we've talked about before is the fact that when you're using TLS, it does add complexity to your environment. So you want to make sure that you have a good plan related to it. If you're gonna start off with TLS, especially internally, you're gonna want to make sure that you set it up between critical servers, between point A and point B. I would not, unless you're a greenfield, deploying TLS to everybody right away will cause you a lot of headaches and challenges. So you want to make sure that you're doing it correctly. And I would start with point to point, one at a time, and just slowly move through your organization and enable TLS within your organization. The other one we're gonna talk about is HSTS, which is HTTP strict transport security. Now, HSTS forces brep web browsers to only communicate using HTTPS. So basically, obviously using TLS for that connection, and then base it allows people that are collect connecting to HTTP, colon, backwack, backwack. Uh, it will not allow them to utilize that capability. It forces everything to HTTPS. So it's an important part, right? And you can send it's you can have the set this up to be able to do this. Now it does add a little bit of latency, but at the end of the day, it's an important part of it. It prevents downgrade attacks, so attackers can't trick users into using an insecure HTTP connection. Um, it mitigates session hijacking and cookie theft, obviously, because all sessions will stay encrypted. And then it reduces user error. So the users are automatically using HTTPS without needing to know it. So this is HSTS. So again, you're coming down to TLS and HSTS, an important part of the overall security related to these exchanges. And this is kind of what they talked about in this basic uh update from SISA. Uh, they also recommended that you will maintain up-to-date software. Exchange servers must be running supported software, patch versions, don't be running old versions of exchange. Got it, right? That just kind of goes with it. Um, you need to make sure that there are cumulative updates. Again, so if you're running on an end-alive system, you should be migrated or decommissioned. I know we've talked about this time and again. You can't leave this old stuff just sitting out there. It's going to get pwned. It will happen. Adopt a zero trust approach. Again, reducing the attack surface by removing unnecessary services, enforcing segmentation, and monitoring any sort of lateral movement. So, again, these are all basic aspects, but you should go check it out. CISA has us put this out there, so go to the Cybersecurity and Infrastructure Agency, CISA's website, and they can look on this advisory. It comes about the different types of surges and different types of attacks that have been hitting the exchange environment. So, good idea. Go check it out. All right, so let's get started on what we're going to talk about today. But before we do, got to put a shameful plug out there for CISSP Cyber Training. Head on over to CISSP Cyber Training, lots of great content for you. It's amazing. Again, if you want the free stuff, I've got gobs of free stuff for you. Podcasts, study plans, you name it, it's available for you. My rapid review is there and available for you on my CISSP Cyber Training. Another thing, though, is if you need a little bit more concierge type of activity, a little more concierge help, go to my paid products. Again, I have some incredibly great pre paid products that are there and available for you at a very inexpensive price. A buddy of mine just got past the CISSP again, one of my students, and he just passed it, no problem. Why? Because he's used a lot of what we've provided to him. Now he also got information from outside of CISSP, but he took he paid for our silver program, did really well with it. We actually had some great conference and uh conference calls around it, and we talked about where his study plans were going, what are some different things he could do to change it, and then also gave him some areas to focus on related to the content within CISSP Cyber Training. So it was a great concept for him to be able to be successful. And this again was my silver program. But again, it may not be for everybody. That's okay, but go check it out to CISSP Cyber Training. Lots of great content there for you, free and paid. Okay, so let's talk about the questions today. Okay, domain seven, deep dive questions. Question one during an active ransom attack, the incident response team isolates the affected systems but notices lateral movement attempts continuing through administrative accounts. What is the most critical next step? A not off notify law enforcement immediately to preserve evidence integrity. B begin forensic images of all compromised systems. C. Rebuild compromised systems for from clean backups. Or D disable all privileged accounts and initiate an emergency access procedures. Again, so now we're talking about they isolate the affected systems, right? So they've you've done that. You are in the middle of an active ransomware attack, but you do notice that people are moving between systems. And they talk about specifically administrative accounts. So if you're dealing with administrative accounts, you're in the heat of battle. You don't want to actually have to go back and try to get a hold of people. You want to disable all privileged accounts and initiate emergency access procedures. This would be D. So this is an important part because now once you do this, so once you disable all of these uh accounts, you are going to have whatever vestige of a system that was going at the time is going to come crashing down. So you want to make sure that you're doing this correctly. And two, you want to make sure everybody knows that this is happening. Now, you want to be very careful with who you tell this to because I say we want to make sure everybody knows. You don't want to have everybody know. You want to have the key decision makers know what's actually going to be happening. Because if you communicate this too much and too broadly, the attackers will know what you're doing as well. But you want to basically shut down all privileged accounts and initiate an emergency access procedure, which would mean you have an incident response plan for emergency access. Right? Disabling them immediately will stop further spread and limits the attacker's control while maintaining essential operational access via the emergency credentials that you have created. Now, you will have to have created these emergency credentials ahead of time, and they should be stored within a PAM environment because if the attackers see that you're using those emergency credentials, they know what's happening. Now, most attackers, as you will be finally aware of, they will actually create multiple backdoors with multiple credentials. So depending upon how long they've been in your environment, uh, going, you're gonna have to do scorched earth probably and shutting everything down to get these folks eventually out of your environment. Question two, when performing digital forensics imaging, what is the most effective method to ensure evidentiary integrity? Again, from performing digital forensics imaging, what is the most effective method to ensure evidentiary integrity? A use cryptographic hashing before and after imaging to verify identical bitstreams. B store evidence copies on multiple media types for redundancy. C encrypt all evidence during storage and transmission. And D limit access to evidence to only the CISO and lead investigators. All right, so let's get started here. Which one do you all think it is? And the answer is A. Use cryptographic hashing before and after the imaging to verify identical bitstreams, right? So when you're doing this, you are hashing it, right? So you take a video, you take a picture of it, and this picture of it is, I mean, a forensics copy of it, you want to verify that they both match from a bit standpoint. Everything is identical. So that forensics copy would be an exact duplication. If there's any deviation, which would indicate tampering or potential corruption of the image itself. And I would highly recommend that once you take that physical, I would take a couple of them personally, and then I would then reinstall one of them. You know, that this would be one just to make sure that as you regenerate it, you reinstitute it, it doesn't just basically barf on itself and say it's not gonna work. So you're gonna want to make sure that you have a good solid copy before you move down this path. It is a fundamental principle of any sort of divid digital evidence integrity is to ensure that you do have an exact duplicate. And the bit part will be the figure to figure it out. Now, B, store evidence copies in multiple media types for redundancy. Now, the redundancy aids in the preservation, but it doesn't confirm the integrity. So you're gonna have the redundancy, which is awesome. Having copies is great, but it will not confirm the integrity of the file itself. Encrypt all evidence during the storage and transmission. This is encryption will protect the confidentiality, but not the proof of authenticity. So again, you want to have it protected, you want to have it in a spot, you want to have multiple copies, but that does not deal with the overall integrity of the system. And then limit access to evidence to only the CISO and the lead investigator. Well, access control is important, obviously, but secondary to validation. But when you it doesn't really help you when you're dealing with the most effective way to ensure the evidentiary integrity isn't limiting to just two people. Question three: an organization disaster recovery plan specifies a warm site with a 24-hour RTO and a four-hour RPO. So RTO is recovery time objective, and the RPO is recovery point objective. So basically they specify you have a warm site, 24-hour recovery time objective, and a four-hour recovery point objective. A major outage occurs. No. And the warm site is operational after 18 hours, but the data is only current to 10 hours before the failure. What control failed? Okay, so 18 hours, bingo, win. All right, but the data is only current for 10 hours before. Now your RPO was four hours. So what control failed? Hmm, don't really know. Let's see what we come up with. A failover readiness validation. B, RTO enforcement control. C, backup frequency control, or DR team communication plan. Okay, so we know that the RPO failed. We didn't have it within four hours, we had it within 10 hours. So that's not a positive thing, right? So the the RTO made it 18 hours. Woo-hoo, got it. RPO did not make it because it was 10 versus it's supposed to be four. So what failed? Well, the backup frequency control. Now, this doesn't necessarily mean this in in every situation, right? We know that. But then this specific situation with these specific questions and these specific answers, this specific question and these specific answers, is the backup frequency control. The RPO, four hours, defines acceptable data loss. You're willing to lose four hours of data. If the data is 10 hours old, the backup intervals potentially were not sufficient enough to meet the defined recovery objective. So this is an important part. If you don't, and I would actually have dealt with my RTO and or I should say my backup and recovery team multiple times on these topics, and I would tell them I'd have an RPO in this case of four hours. They would tell me, yeah, we're good. We're good. So then what we did was we would then go and decide to run a plant a test and see what would happen. Just as we suspected, four hours was not what was configured. It was basically something different than that. And then this actually brings back a lot of memories because it was anywhere from 10 to 12 hours that it would do it. And they thought that was sufficient, but they didn't understand the RPO piece of this from a DR point of view. So it's imperative that you talk to them about that. So failover readiness, what does that mean? So the warm site was operational within the RTO, but the failover readiness, so it worked. It actually failed over the way it was supposed to. Within you failed over to a warm site, you had RTO within 18 hours, it actually did what it was supposed to do. RTO enforcement control. Okay, the RTO is achieved, so it really doesn't matter. That isn't an issue. So when you look through these and you go, well, RTO enforcement, oh, that's it. That's it. No, it's not, it's RPO, not RTO. And then D, DR team communication plan. Well, communication wasn't indicated as a failure point, and that really was not something that you didn't need to worry about. So in this case here, you could potentially throw out B and D pretty quickly and narrow it down to just those two if you had any sort of questions. Because they B and D really weren't part of the question. They weren't as as important to it. You could kind of figure that one out. Question four, which of the following best addresses the security concern of log tampering by system administrators? So again, what best addresses the security concern of log tampering by a system admin? A enforcing multi-factor authentication for all admin logins. B sending logs to remote, write once, read many storage devices. So that's worm. Write once, read many. C, increasing logging retention, period. D limit log file permissions to read-only access. Okay, so now I've read those out. What is it? What is the best one that addresses the security concern of log tampering by system administrators? So the system admins are going in and they're gonna go muck with the logs. How do we avoid that from happening? And the answer is B sending logs to remote, write once, read many storage device. So again, you write it once, can't you can't do anything with it. It's remote, and you can read it as much as you want. And you can many can read it. So this does provide immutable logging, and then it prevents administrators, even with root access, from altering or deleting evidence of malicious activity. So again, it's gonna write it, and now they can't go in and actually modify the the additional or the original logs that were there. So let's walk through some of the questions that are not correct. Enforcing multi-factor authentication for all admin logins. So MFA. So MFA protects access, but not post authentication activity. So, like we talk about, the system admins are tampering with them. They've already made it through MFA, and so now they're tampering with the logs. MFA would not do anything to stop that because the admins are already in. Uh let's go C increasing logging retention period. The retention time doesn't protect the integrity of the overall system. So just in the logging retention aspects wouldn't mix or wouldn't adjust or affix if an admin is going in and changing the logs. Or D, limiting log file permissions to read-only access. Now, read-only permissions can be overridden by privileged users. This would be a good second step. So if for some reason you didn't put worm in place, limiting file permissions to read-only is positive. But in the case of this specific question where there's system admins who probably have privileged access are going to be able to have the ability to do this, you might want to bite off on that, but be careful with which one you do because you want to think about long-term strategy around these overall security mechanisms. So the answer is B. Question five, the last question. An emergency patch is required to address a zero day exploit impacting the production servers. Which step should occur immediately after emergency patch is applied? So the emergency patch is being pushed out because it's a zero day that's in active exploit mode. What should you do? A update the system baseline documentation to reflect the new configuration. B conduct a full regression test on the affected environment. C. Communicate patch completion to end users, or D. Submit the change change for respective review by the change advisory board. Okay, so the emergency patch has been pushed out. What are you going to do? Okay, what should you do? And the steps immediately should occur after an emergency patch is applied. That is the question. And the answer is D. Submit a change request in respect in retrospect for the change advisory board. And we talked about this in the podcast, right? The last this last podcast we had. And the found we deal with your change advisory board. If you have to put out an emergency change, you have the permissions of, depending upon as you build your board out, to push out that change immediately once you have the appropriate approvals to do so. But the change advisory board must be informed of what actually just occurred. And because of that, this is where you would go back in retrospective and let them know hey, we made this emergency change because of a zero day that was out there in the wild and we knew it affected us. We didn't want to wait for the overall change board. We wanted to get an emergency change in place. So just an important part of all of this. Now let's walk through the ones that are not correct. Update the system baseline documentation to ref reflect the new configuration. Yeah, so baselines again happens after the cab validation. So it doesn't really help you in this situation a whole lot. And it isn't really what the question they were asking for or the answer they were asking for. Conduct a full regression test on the affected environment. So regression testing is a valuable part, but it typically is a part of a planned change, and it's not part of emergency patches. As we talked about, a planned change, you would have some sort of regression testing that you have done. You've done a full test, regression test, and et cetera, et cetera. That would be part of your overall normal change process. In the case of this, this is an emergency change, so it's not part of that. Communicate patch completion to end users. User communication really isn't a part of an emergency change control. That you may have some key key users that may get notified, but for the most part, uh most users will not even know if an emergency change occurs until things start breaking on their systems. So the answer again is D. Submit the change in it for retros retrospective review by the change advisory board. Okay, that is all I have for you today. I hope you all have a beautifully blessed day today. I hope your CISSP studying is going well. Again, go check me out at CISSP Cyber Training. You can listen to this on all the wonderful podcasts that are out there and available and appreciate all of your support. Please email LipMe and let me know how this training has been helpful for you because again, we're trying to make changes to it to help you guys pass the CISSP the first time. So I thank you so much for joining me, and we'll catch you all 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. 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 left for the orchardopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Sniper Training and sign up for 363 CISSP questions to help you in your CISSP journey. Thanks again for listening.