CCT 291: CISSP Rapid Review Exam Prep (Domain 7) - Part #2

You can harden your network and still miss the front door: aging edge devices with elevated access, thin logging, and long‑ignored firmware. We dig into the uncomfortable truth behind “set it and forget it” firewalls, VPNs, and gateways, then lay out a practical Domain 7 playbook that helps you detect faster, respond cleaner, and recover without chaos.

We start with the incident management sequence that actually works under pressure—detection, response, mitigation, reporting, recovery, remediation, and lessons learned—showing how legal timelines, stakeholder updates, and RTO/RPO planning fit together. From there, we map the controls that pull their weight: next‑gen firewalls and WAFs, IDS/IPS, smart whitelisting and blacklisting, sandboxing that anticipates time‑bomb malware, and when to lean on EDR, MDR, and UEBA to cut through alert fatigue.

Then we get hands‑on with vulnerability and patch management, focusing on asset inventory, critical‑first prioritization, scanning automation, and staged deployments with real rollback plans. We connect the dots to change management so fixes don’t become outages. Resilience gets its due: backup integrity and rotation, hot/warm/cold recovery sites, multi‑region processing, HA pairs, QoS to preserve critical traffic, and fault‑tolerant design that keeps services running when parts fail.

Finally, we round out security operations with disaster recovery drills—from tabletop to full cutover—plus business continuity planning that aligns cyber recovery with revenue‑critical processes. Physical security and personal safety close the loop: layered access, surveillance, environmental controls, and travel and duress protocols that protect your people as well as your data. If you’re preparing for the CISSP or sharpening a real program, you’ll leave with concrete steps to reduce risk now and a roadmap to mature over time.

Enjoyed this deep dive? Subscribe, share with a teammate who owns Domain 7, and leave a quick review to help others find the show. Your feedback shapes future topics and tools we build for you.

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 Domain 7 Part Two Setup
• 0:59 90s-Era Flaws On Modern Edges
• 5:21 Treating Edge Devices As Attack Surface
• 7:51 Incident Management Lifecycle Overview
• 12:31 Detection To Reporting In Practice
• 16:00 Recovery, Remediation, Lessons Learned
• 18:28 Preventive And Detective Controls
• 25:13 Whitelisting, Blacklisting, And Automation
• 29:06 Sandboxing, Honeypots, And AI Tools
• 32:46 Patch And Vulnerability Management
• 39:40 Change Management Essentials

Transcript

SPEAKER_00: 0:00

CISP sniper screening screening and tools. CISP. Hi, my name is Sean Gerber. Provided the information you need. CISSP exam. And roll your cyber checker in the point. Alright.

SPEAKER_01: 0:25

Good morning everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today is CISSP question Thursday, but it's we're gonna have a little change of plans today. We this is going to be part two of the CISSP rapid review exam prep for domain seven. So rather than have the questions, I wanted to finish up the second part of this domain because as we know, domain seven is quite large and we had to break it into two sections. Part one was on Monday, part two is today. So we're pretty excited about that. But before we get started, I wanted to share an article from CSO magazine. This is related to network security devices endanger the organizations with 90s eras flaws. Now this isn't 90s technology, but it's 90s eras flaws. So what does that actually mean? Well, as we all know, there's a lot of different things that go on with organizations. And if you've been in any sort of cybersecurity for any length of time, you understand that this is a different situation than we've ever experienced before. And so as a process of doing that, we are learning a lot around how we should protect and manage these cybersecurity systems within organizations. And what that comes down to is that they're mentioning the fact that there, since many of these organizations are utilizing security appliances such as firewalls, VPNs, and gateways that have not actually been touched in many, many years, what's happening is there's uh buffer overflows, command and sequel injections, and path traversals that are actually being exploited by numerous companies out there. And really it comes down to is people set it and forget it in many of these different appliances that are external to the web, which I just struggle with this. I never understand why this happens, but I can see how it happens. The reason what's happening is edge devices are being exposed to the internet, which we often know. And they've been virtualized, but in many organizations, they actually had physical applications or physical devices that are sitting out there that haven't been touched for many, many years. And they often lack the full logging or EDR capability that current systems within the networks do have. And as a result, because they also have to have the internet level facing capabilities, they also have privileged access. So many of the accounts that can gain access to these systems are ones that have the ability to do things within your organization. Now, again, this comes back to having a good architecture and someone really truly understanding what are the credentials that are allowed out there in these externally facing systems. And if you if you don't have a good architect or someone that understands this, you better find one because realistically, this is if if this happens to you, this is bad juju, bad things can happen. But attackers are shifting from basically phishing to exploiting network edge vulnerabilities, and because many of these appliances are using C and C sharp and C code from multiple years of having acquisitions, they're actually creating debt that is not being addressed. And I can personally speak from this myself, as we did acquisitions with the company I was with, where they were very challenging acquisitions and they had very old stuff. And as you had to figure out, okay, as I bring this old stuff into my environment, how am I going to manage moving it out at some point? So there is a lot of challenges that are dealing with these network edge devices. And so, as it comes down to uh you're gonna have to address this in some form or fashion. So vendors are struggling to monetize these old architectures and the various code code bases, and this also happens within the critical infrastructure areas as well. So it's it's one of those aspects where coders are developing these this context, and especially now the code that we're using from API-based uh to JSON to Python to all these different types of languages that really didn't exist 15-20 years ago. Now it's actually there, this old stuff is just being left aside. One of the parts that I used to work on is systems, a Vax system, and it used very old code. I think it was cobalt, if I'm not mistaken, and they had to get developers to help with the cobalt code because it was just so specifically old. Uh, so again, this is what's happening now to the things that when I was younger was the new and upcoming code is now becoming old, kind of like me. But so one of the issues that are coming in is one of the recommendations that we they're they're saying in this article that you should consider doing is treat all edge devices as part of the attack surface, which I pause there for effect. That should be a no-brainer, right? But there the people obviously are not doing it. So you need to really look at that as the overall attack surface and not as them being specifically inherently secure because they are on the edge. You also should not rely on third parties to update these systems for you as well. You need to make sure that you are also managing them and looking at them as well and keeping updated on how their updates or their firmware updates are occurring within these systems. You also need to maintain an inventory of all security appliances and track the firmware versions and prioritize timely patching and integrate device logs into your security operations visibility. All of those are key factors in what you're doing. And then factor in any vendor security maturity into the procurement and risk decisions. What does that really basically mean? Well, if you're gonna be having some any sort of procurement piece of this, how do you end up building on these systems? And the fact is that once they go end of life, how do you manage that? Well, you when the previous life, when we would do end-of-life situations with different uh capabilities, and you're you're oh, let's say, for example, you had a firewall that's sitting out on the edge and you knew that it was going end of life, you started planning that out about a year and a half out. One, because you had to get in the procurement cycle, and two, you also had to get into the deployment cycle, the change management piece of this. So it is a very big process, and it's something you need to constantly be aware of and attune to. Now, this includes risks for training and awareness programs, also to counter the security device blind spots that it may have. So, again, legacy systems are going to be a major risk for any organization, and this is where this talks about it in this article, and that you really need to understand what are the vendors that you're bringing in here, as well as your own systems that you have uh inside your organization. It's a big deal. So, the more you can have a better handle on it, uh it again this comes down to device management and then ensuring that all devices within your organization are considered vulnerable. Now, I get it, some systems that may be within the bowels of your environment may not be as vulnerable, they may not be as critical, but you should consider all of them as a gateway for bad guys and girls to gain access to your network. So always think about that whenever you're deploying any sort of system. Okay, so let's get into part two of the CISSP Rapid Review Domain 7. Conducting incident management domain 7.6. We're almost halfway there. So detection, this is the process of identifying cybersecurity events or an anomaly. Now we talked about this relies on the tools such as a sim, IDS or IPS, and threat intelligence and human vigilance. So you needed to be able to detect it. This is where you're dealing with incident management. Response. This is the immediate actions taken upon detection of an incident. This involves initial triage, validation, activation of an incident response team. The mitigation piece of this is action taken to limit its scope and impact of an incident. So you're mitigating it, and this could also contain your containment strategies as well. So detection, response, mitigation. So it kind of follows that order. You'd find it. Oh no. You respond, yes, we're gonna get it. Mitigation is okay, now what are we putting in place to stop it from going any further? Then you have reporting. Haha, do you got to tell the boss? I just screwed up. No, you you have to communicate, you need to communicate with everyone. Uh that this includes all internal stakeholders. Now, I I do mean I don't mean everyone, I mean yes, internal stakeholders, keep key factor. Management, legal, HR, all of those folks. You need to let them know. And potentially regulators, law enforcement, and the potential affected customer. So, but there's a process. Once you discover that you have a problem, you don't just go tell all of them at the same time. Yeah, that your legal team would not be happy with you if you did that. You you need to have a very coordinated conversation uh when you're dealing with reporting. This ensures timely and accurate information and dissemination. And also when it comes to legal aspects, there are requirements. So, like uh NYDFS, I think it's 72 hours you have reporting. There's various other organizations or between 24 if you go into China to up to 72 uh for breach response. So that just depends on the country you're in. It depends on what the requirements you may have, but you do need to do some level of reporting. This ensures timely and accurate information dissemination and ensuring that everybody has got all the information they need. Recovery, this is restoring the affected systems and services to normal and secure operations. This is from the backups. Remember, we talked about you have a backup and then you do a recovery. Well, here you go. Now you're in the recovery phase. This is focused on recovery time objectives, RTOs, and recovery point objectives. This is where your data is stored, right? So how fast can you recover it and at what point is this data being recovered? So if the recovery point is five minutes, you know you've lost five minutes of data. If it is instantaneous, then you haven't lost data. Uh, if your recovery time objective is, is that you have a certain amount of time to get your information back together, uh, that would be could be anywhere from an hour, seven days, two weeks, whatever. Uh, you have a recovery time objective that needs to be considered. Remediation. This is where you're addressing the root cause of the incident. Now you've fixed it, you've got to deal with it, uh, you've you've backed up recovered, you're in business, now you've got to try to remediate what the dickens happened and how do I prevent this from reoccurring in the future. This includes patching vulnerabilities, reconfiguring systems, and updating security controls. Remediation is a big factor, and many times once you fix the problem, people just go, okay, I'm good, no problem, and they don't go back to the remediation issue as much as they should. They they address the initial problem that they got hacked by, but they don't really look at the overall underpinnings of why it happened. Uh so rats why remediation, it's an it's a big step, and you really need to take the time on remediation uh for your company. Lessons learned. This is a final area where it's a formal review process after the incident to identify what went well, what went wrong, and what can be improved. Basically, the good, the bad, and the ugly. Uh, that all needs to be considered from a lessons learned standpoint. This feeds back into policies, procedures, and technology, as well as training for continued enhancement of your security program. So now you gotta go and reinvest yourself. Look, what do I do? How do I make it better? So on and so forth. It doesn't stop once you get the bad guys and girls out. You it's just an ongoing issue. Um, and and the problem is if you also were accepted, this might be the person who's replacing you doing this. Uh, but that not to say that that would happen, of course not, but yes, sometimes after an incident, uh either the CISO decides to leave or is forced to leave, one of the two. Uh, because it's it's a very it's a it's a very significant emotional event that occurs in your life. And I don't recommend it. If you can avoid it, avoid it. Domain 7.7. This is where you operate and maintain detective and preventive measures. This is your firewall, next generation web application and network firewalls. This is a network security devices that are designed to monitor and control incoming, outgoing network traffic on a predefined security rules. And these types are part of a traditional network firewalls. So you have your next generation firewalls, you have your web application firewalls. If you're dealing with um the what do you call it, the cloud, you're dealing with security groups, uh, different types of words, but they're basically the same thing. Uh, your firewalls are a great tool to help limit the amount of activity somebody can gain within your network, and I highly recommend that you use them. Uh, they're probably kind of like one of the foundational pieces. If you don't use these, then you really got a problem. Now, you might be using something else because um, for some reason, like a security group, you might be using that and not using firewalls because you're in the web, uh, or are you all on a third party, but you want to consider their use in some form or fashion. Intrusion detection systems, IPSs. We talked about those pretty much where you're at their network host and they look for different types of activities, they will actively block or modify traffic in real time. That's your IDS and IPSs. Now we're getting into whitelisting and blacklisting, yes, whitelisting, this is an access control strategy that explicitly allows only approved items, applications, IP addresses, etc., uh, to be implicitly denies all others. So those are all allowed in. Uh, blacklisting basically is an access control strategy that denies malicious items such as malware hashes, malicious IPs, uh, and it implicitly allows all others. So it's basically focused on, hey, if it's a bad site, I'm blacklisting it. Uh if it's a good site, I'm gonna only do whitelisting areas that I'm gonna allow to occur. Now, the blacklisting is easier, but the downside with the blacklisting is that these folks may there might be a situation where they the IP is not considered a malicious IP and it is allowed in until it is then uh registered as a malicious IP. And then therefore it becomes a problem. So whitelisting is can be very problematic for your company if that you're just only explicitly allowing only approved items, you can actually end up causing a denial of service to yourself. So we would blacklist typical any sort of IP that came from malicious, it was automatically blacklisted, knowing full well that that did not protect us from everything, and that we would then when a new IP came up, it would be put into the blacklist. Uh, a lot of times we had this set up on automation. That's a key factor if you can automate this because manually going in and doing this is quite tedious and painful. Third party security services, this is where security functions or operations are outsourced to external parties. Aha, manage security service providers or MSPs or MSSPs, uh, they will provide you that information or that capability. Uh and so you want to, if you're not going to do it internal, you definitely want to outsource it. It can include services such as managed detection and response. They also have uh EDR is another part of this, is where your uh endpoint detection and response, uh, security monitoring and penetration testing. They can provide all those things. Sandboxing, this is a security mechanism for running untrusted code or applications in an isolated environment. This prevents potential threats from affecting the host or the network. You put them in the sandbox, they play in the sandbox. Uh, if they're a cat, they do other things in the sandbox, but you you basically run untrusted code in there and wait to blow it up and see what happens. Uh, if it works, great. If it's got malicious stuff, it stays in the sandbox and it's never allowed out. Uh so sandboxing works really good. The downside is we used to put stuff in sandbox and it was in there for a period of time. Uh the bad guys and girls got smart and they put timers on their code so that it wouldn't run its malicious code for a period of time. So that the sandbox would go in, it would look for it to detonate, nothing happened, you'd be allowed to have that information go to your network. And then what happens is after a period of time, seven days, it pops up and comes to life. Uh so yeah, that that was that's not good. Uh okay, we're dealing with honey pots and honey nets. A honeypot is a security resource intentionally designed to be attacked and compromised. The honey net is a network of honey pots used to gather information about attacker tactics, techniques, and procedures. Uh so I've used these with meh meh kind of capabilities. Sometimes they work. Um, I would say I haven't had seen many people go to them. Uh so therefore, is it working? Maybe. Um are there bad guys on your network? Maybe, maybe not. But it yeah, they're kind of one of those that I'm not a big fan of. Now, it's not because they're not good, it's just because I I've had limited um successful use with them. But honey pots are out there and they're designed to be attacked and compromised. So if they're if you're dealing with a hacker that is of any worth, he'll know it's a honeypot. Uh, if you're dealing with somebody who's more or less just kind of flies by the seat of their pants, they probably wouldn't realize that it's a honeypot and they would attack it. Uh, anti-malware, this is software designed to prevent, detect, and remove malicious software, malware from a computer system. This includes antivirus, anti-spyware, and anti-ransomware capabilities. So this is your anti-malware part, and this works really well from your systems being an automated plan. Machine learning and artificial intelligence-based tools, this is becoming a bigger factor in our entire ecosystem. This is where you will leverage these to the algorithms specific to you to analyze vast sets of data sets, uh, identify anomalies, and detect sophisticated threats. This works champ like a champ. This to me is where your tier one threat analyst that you're dealing with, your sim, this should be all AI-based. Because realistically, the tier one threat folks, they're missing stuff all the time. And it's not because they they're bad, it's just because you're looking at so much data, you just you lose sight of it. So using AI tools and machine learning where it can correlate, much better solution. Uh, and it's used in areas like UEBA where you're dealing with insider threat and threat detection, automated incident response, etc. So those are all important parts within the AI space. Domain 7.8, this is where you implement and support, or this is implement and support patch vulnerability management. You need to have a vulnerability management program within your organization, typically called uh a VRM. And if you don't have this, shame on you. Sorry, shame on you. You should have something. If anything, just put on Microsoft's automatic patch, just do that at a minimum. Uh, this is where you'll implement and support patch management. This process includes identifying applicable patches, testing them in a non-production environment, and deploying them across the enterprise and verifying they have a successful application. This applies to operating systems, applications, firmware, and network devices. You need to patch everything. Yes, you do. And it might be in a situation, well, you know, it's in a critical spot, which we can't really patch it because it'll cause an outage. Yeah, you do. You need to patch it worse there than anywhere else. Or you're in a situation where, yeah, we're men, we're separated from the Everworld network, and therefore you can't gain access to us. So because you can't gain access to that network, we're not going to patch it. No, wrong idea. You need to patch it. Please patch. That stuff's out there for a reason. Uh if you don't do that, you're just you're basically you're saying you give up, and that's not a good place to be. Implement and support vulnerability management. These are different phases that you'd have to manage through this. The phases are identification, assessment, prioritization, remediation, and verification. So identification is using vulnerability scanners, pen tests, and code reviews along with threat intelligence to help you identify the overall vulnerabilities that you may have. The assessment is analyzing the identified vulnerabilities for severity, exploitability, and potential business impact. Again, if you don't have a program, focus on the criticals, get the criticals taken care of. Then go to the highs and get focus on those. Then maybe, maybe do the mediums, lows, eh, eh. If you can't get to those, it's understandable because there's a lot of lows. There just truly are, and you would be doing patches forever. So, but if you don't have it and play, if you if you're starting Greenfield brand new, then definitely put it in place at the beginning. Do not wait. Prioritization, this is ranking vulnerabilities based on risk, which and which is likelihood and impact, and critical or asset criticality. Remediation, this is where you're applying the patches, reconfiguring the systems, or implementing compensating controls to mitigate the situation. And then finally, you're dealing with verification, confirming that the vulnerabilities have been successfully remediated. Again, that's domain 7.8. Now, what are some key considerations you need to worry about with domain 7.8? Automation, leverage tools for automated scanning. Please, that's much easier. Patch management and deployment, uh, as well as tracking your efficiency and consistency. Now, I will say, okay, I'm gonna take one thing back. Automating patch deployment can be is should definitely be the goal, and that's where the maturity aspects come to. Doing that right out of the gate, yeah, don't do that right out of the gate, unless it's like Microsoft patches, because those are usually pretty good. But doing it yourself with your with your own tool, doing automated patch updates, not a good idea. You will break stuff, and then people will want you fired and they'll bring out pitchforks and torches, and it would be bad. So you need to, if you're gonna if you're just starting into this, you need to do it slowly. It's like dipping your toe into the really cold, deep plunge cold thing, right? Yeah, you don't want to do that, just you should just jump in. But don't. That's a really bad analogy for patch management, by the way. But you want to make it slow, slow. Like I think it's a hot tub, and you want to slowly just get into the hot tub. Yeah, do this slow. Uh policy procedures, establishing clear policies for patch frequency remediation and vulnerability scanning schedules. You need an asset inventory, very important. Must have an asset inventory. Again, it's really hard to protect something you don't know exists. Uh, it's foundational for effective patch management and vulnerability management. Change management integration, yes, we talked about that, where you have some sort of change management and then finally reporting. If you don't report it and you don't track it, it didn't happen. And your senior leaders are going to want to know. Now, they don't want to know all the details like we installed this JavaScript patch on x.1.2. No, they don't want to know that. As much as you may think they want to, they really don't. Uh, but you need to at least tell them how hey, how are we patched at an overall standpoint? Is it like 10%, 20%? What are we doing? They need to be aware of it because again, it's all about risk. Join 7.9. This is understanding and participating in change management. We met we briefly mentioned this. So, what is the change management process? This is controlling, tracking, and documenting all changes made to an organization's IT infrastructure. It's to minimize risks associated with changes, prevent unauthorized modifications, and ensure that you are basically stable and secure. Now you participate in this change management process through a different couple different ways. Security representation, security review, approval, testing, documentation, and rollback planning. So security representation. You need to have a security person on the change management board. When you're doing these changes, who's a security person, the billy button, who's gonna be there? Then there needs to be a security impact review done on any of the proposed changes for that identify potential vulnerabilities or risks introduced. So, what does that mean? You are gonna be patching, let's say, um, a very old system and you're using a patch that just rolled out. You want to really look at that pretty hard because what's gonna happen is did you test it? Did you get it approved? Did you what'd you do with that? Because the moment you push it out there, you and I both know it will fall over, and therefore then you will fall over because someone will be mad at you. Uh approval, you need to provide security-specific approvals or recommendations for changes based on risk analysis. Test it, you need to ensure that it had proper security testing and it's integrated into the change validation process. This does not mean that your change is gonna go out on Friday. Well, they typically don't do it on a Friday, they do it on a Monday. Your change is gonna go out on a Monday, and you're just going, I'm putting this in right now on Friday afternoon, not really have tested it. Yeah, it's gonna be good. It'll be all be good. No. You if you're gonna be doing that, you need to push it out to about two weeks, give yourself a week of testing, and then push the change. Again, you cannot impact business options unless the you have a dumpster fire, everything is on fire, and things are going bad. Well, then you just push out stuff. Then that's fine because you're already dealing with the fire, you might as well just do it. Documentation, this is where you verify the security considerations, risks, and controls related to the change are properly documented. And then rollback planning. This ensures that secure rollback procedures are defined in case a change introduces unforeseen issues. Rollback procedures are important. Yeah, you deploy it and then oh no, this isn't working. Rollback, rollback, pull out, pull out. You know, that's just not good. Yeah, that's not a good place to be. And been there, done that, had the t-shirt. And then you know when you get really bad when the heat just rolls up the back, your back. It starts at your feet, goes up through you, and then rolls in the back of your ears, and you're like, no. Yeah, then it's just oh, I suck so bad. Yeah, that had it, been there, done that. If you're an IT, you'll have had it too. And all of you out there are probably laughing because you all can relate. So, 7.10 backup storage strategies. This is defining a method and locations for storing backups on-site, off-site, cloud. Where are you gonna put it? How are you gonna manage it? And this includes media rotation, encryption, and integrity checks for the various store backups. Do you have a plan for that? Recovery strike site strategies. You have a hot site, warm site, and cold site. Your hot site is a fully equipped off-site data center with hardware, software, connectivity, ready for immediate activation. So it's ready to go. What do you do is push a button and you're in hot site mode. Yes, no, it's and that those work well. A hot site is good, and you need to make sure you test them, and a lot of times they'll fall over to a hot site a couple times a year. Uh, hot sites are very expensive, very expensive. So you need to make sure that you need a hot site within your company. Can you, and this is all off RTOs and RPOs, right? So your warm site, this is a particularly where you're it's a it's a partially equipped uh off-site location with necessary infrastructure, but requires additional hardware and configuration for activation. This these are probably typically where many people work, and they will probably wouldn't even deal with a physical equipment. A lot of it's in the cloud, which makes it a much easier um situation. And then that was where a good warm site would be, is kind of some sort of cloud capability. Uh, it it takes some time for you to make sure everything's up to date. And what we do in these situations is about every six months you would ensure that it has the most current software, most current systems, etc. That's so it's ready to go. Cold site is a basic off-site facility with infrastructure, i.e. power and cooling, but requiring all the hardware, software, and data to be brought in. This is where you'd have like a location that's got the comms already to go. You've got your cooling set up, everybody's ready. But what you do is you go, okay, our building is now no longer used. It's a hazmat situation. Uh the septic tank exploded and now there's poo everywhere. Okay, so that happens. Oh no, what are you gonna do? We're gonna go to our cold site. And that's where you have an off-site area. It could be a hotel room, right? That has everything you need to be able to work. Uh, that is your cold site. So we're dealing with multiple processing sites. Utilizing geographic dispersed data centers, especially in the cloud, is really good to redistribute your workloads. It enhances resilience by allowing operations to continue from an alternate site if one goes down or fails. Now you're dealing with system resilience, high availability, quality of service, and fault tolerance. What are those? Well, our system resilience, you want to make these systems able to recover quickly from any sort of disruption and maintain acceptable service levels. High availability is you're designing systems to minimize downtime by eliminating single points of failure throughout redundancy and failure mechanisms. So your high availability systems that are already in place, you're going to utilize those. You you may have already built that into your overall architecture and you have high or HA, call them HA, and they could be an HA pair. Now, your quality of service is where you're prioritizing network traffic to ensure critical applications and services receive the bandwidth and the low latency. So the point is you have software that's out there doing QOS for you. Something is labeled as critical, it is allowed network traffic. Other things that are not labeled critical are deprioritized, and therefore they're not allowed as much uh bandwidth time. Now, this is a big factor, especially if you're dealing with high, you have low or high bandwidth requirements and you have low capability. This can also occur during a denial of service situation where uh your pipe that's coming in is getting flooded with all sorts of packets, and therefore you're having to manage that. And and you have a limited amount of outbound data that can go out. You'll use QoS to help limit that. Fault tolerance is the ability for a system to continue operating without interruption even when one or more of this components fail. This is where you also run into the HA pairs. Uh, if you have an HA pair that's fault tolerant, something goes bad, uh, it will now work for you in place of that. Domain 7.11. Implement disaster recovery processes. DR is a big deal, and it's it's something that you need to consider. A lot of times people don't even mess with it. So response. This is your initial actions taken upon detection of an incident. This involves triage, validation, and activation of your IR team. So something bad happens, your incident response team now kicks in gear and is in place. They're running. Your personnel, this is where you define roles, responsibilities, and escalation paths for incident response team members. So your people that are there, what are their roles? What are the responsibilities that need to be defined ahead of time? And then what is the process for which this is going to occur? This only happens really well if you exercise it. Yes, you need to do some sort of tabletop exercises to make this happen. This ensures availability of trained staff to handle various incident types, etc. So again, that's the personnel piece of this. You need to have them defined, you need to have your availability, and they need to be trained. Communications, this is where you're establishing clear protocols for internal notifications, management, legal, and HR. What are they going to do? How are they going to do it? Who are you going to contact? Ghostbusters. No, you're not going to call Ghostbusters because that does that kind of help you. But the management, HR, and legal team, they'll help you. Actually, they'll probably make your life worse because they're going to ask you a million questions over and over and over again. But you need to have clear protocols in place for these internal communications. You need to define procedures for external communications, i.e., regulators, law enforcement, and affected parties. Yes, you need to have this defined immediately with how you're going to handle your law enforcement and regulators in the event something bad is going to happen. Assessment, restoration, training awareness, and lessons learned. What are these? Well, your assessment is determining the scope and impact and root cause of the incident. How did it occur? What are you going to do? How are you going to manage it? It involves forensic analysis, evidence collection, and vulnerability identification. So, again, in your DR process, how are you going to assess the problem? How are you going to restore it? What are you going to bring? It back to again back to RTOs, your recovery time objectives, and your recovery point objectives. How do you bring them back to a recovery or to an operational state from when they were in a bad state? So that's your restoration process. And again, defined, has to be defined and available for people. Training and awareness, education personnel on instant response procedures and their roles. They need to be trained. They need to have routine training. It isn't just you do it once in the year and you don't have to do it again. You may want to do it multiple times. And again, this can be done with your security awareness, or it can be done during exercises or tabletop exercises you have set up. This again, this is to the point of conducting regular exercises to test response plans and improve team readiness. Lessons learned this is a formal review process after an incident to identify what worked well and what needs improvement. So the lesson learned is a big factor. You need to do these at the end of every incident to find out what did go well and what do and give pats on the back to people who did well. And then also what are areas that you should have probably not missed and done better at. Feeds back into policies, procedures, and security controls. This is where that continuous loop is. You will go back in and change your policies and procedures to meet what you learn from your lessons learned. So it's an important part. Domain 7.12, 7.12. Does that test your disaster recovery plans, DRP? Right? So that's how do you test this? So this is a tabletop. We mentioned this just a little bit previously. This is a discussion-based exercise where participants walk through simulated incident scenarios. I know a lot of guys that do this very well. So if you need one, let me know. I can help you. It focuses on reviewing plans, roles, responsibilities, and communication flows. This is an interesting part, and I would highly recommend you do this with an IT group as one group, then you do this with your senior leadership as another group, and then you do one together with your IT and your senior leadership. It's very different dynamic, and you can learn a lot by doing it this way. This would include all your senior leaders. Some of your senior leaders go, I'm too good for this, I don't have time. Yes, I've had that happen. And yeah, but you know what the funny thing about is they're gonna be the first person screaming at you when their business can't perform because they have no money, because everything's broken. Yes, you need to educate these folks on how this works. Focuses on reviewing plans, roles, responsibilities, and the overall communication flows, which I kind of talked about already. It's a structured walkthrough, a more detailed exercise where teams physically walk through specific steps of a plan. So the tabletop is you talk through it. The walkthrough is that, okay, what would you do? Okay, now go do that. Uh why are you doing this? Go do that. This involves reviewing documentation and validating procedures in a step-by-step manner. Kind of similar to what you would do when you're sending the Apollo missions. Okay, step one, check. Step two, check, step three, and so forth. You walk through the overall documentation, and you realize when you get to step three, you go, oh, wait a minute, that's like 1970s. That's not gonna work. Then you can now make changes to your documentation, and it works well. Simulation test, this is an exercise that simulates real world incident in a controlled environment. This would be where you set aside a potential network part. Or we did this where we had an area within AWS that was represented our network, and we would then run through a real world incident and see how people would operate. Uh, operational teams and systems testing, technical controls, response procedures, all these folks would be involved in everything of this simulation test. This is where you're not doing it on your actual network, you're doing it on a pseudo-network that would look or kind of seem similar to what you currently have. Now, understand that this can be extremely expensive in a large organization, so you may want to try just parts of it. But the ultimate goal is to see how your folks respond, how do they find anything that's going on in your network? Parallel test. This is a test where recovery systems are brought online and a secondary site, but production operations continue at the primary site. So you use data from your primary site, you send it to your secondary site, and you bring it up online, and everything is running. Yeah, it's working great, but you're not doing a full interruption test. This is just where you're running it. They're running parallel, side by side, everything's working fine. This validates the recovery site's functionality and capacity without interrupting the live service. So capacity is a big deal, especially if you've never brought it up. Uh, you're used to your systems, you've slowly built these systems up to a certain size over time. And now you have another site which you need to actually run it in parallel to figure out, oh, wait, we're missing this database. Oh wait, we're missing that. That's a really great important part of doing a parallel test. It's expensive though. It's gonna be expensive to do a parallel test. It will be. And then once you get it up and operational, I would then roll into the full interruption test, which is a comprehensive test where primary production systems are intentionally shut down and operations are fully transferred to the recovery site. Parallel test is running, shut one down, one's operational. That and then that people do that for a period of time and then they bring this one back up, run parallel, bring the one down. Okay, so that's the full interruption test. This provides the most realistic assessment of your organization's ability to recover and resume critical functions. So participating in business continuity planning 7.3. This is identifying critical business processes and conducting a BIA or business impact analysis to determine RTOs and RPOs and developing recovery strategies and documenting your BC plan. Now, BC and DR are very different, they are very different animals. Uh, they get used a lot together. The the terms get used interchangeably in many ways, but they're not. They're very different. Uh, the the point of this is focused specifically on business continuity, ensuring the business is running and operational. Uh, role of security, the security professionals contribute to ensuring BC plans incorporate cybersecurity considerations such as data integrity, secure recovery environments, and incident response and integration. Now, the risk team may be the ones that are doing a lot of your BC stuff, uh, but it could be you. I was highly involved with my BC people because security was such a huge factor in this of data integrity, data storage. Uh, when you bring the systems back up and operational, are they are they be able to run? Uh this happened. We put a really good plan in place right before COVID hit, and it was actually a huge blessing that uh we didn't anticipate is that when we recovered to uh when COVID hit and everybody went working from home, we boom, we were up and operational in no time because we had good BC plans enabled. Now you need to participate in BC exercises. These are typically a range of tabletop exercises that are discussion-based. Two, you could get a full scale simulation, which we did, uh, and you test the actual recovery procedures that would occur. These are really great products, uh, and I would highly recommend that you do once you determine your critical business systems, you do a business continuity exercise of some kind. Again, at the end of it, lessons learned. Post-exercise reviews are crucial to identify areas of improvement and update the BC plan. Once that's done, you need to update it. You have to, you just don't do the exercise. You have to take the information from the lessons learned and not put those in a file somewhere. You need to actually implement them within your organization and the documentation that you have. Facility security. This is domain 7.14. This involves site selection, building construction, and perimeter defenses such as fencing, lighting, and gates. This includes environmental controls such as HVAC, humidity regulation, and water detection systems. So your facility security is an important part, and you wouldn't know that a security professional, yes, you will probably be the person that's going to help them with facility security. Uh, with as a consulting gig, one of my partners, uh, he's actually going to do a facility uh security review here at a couple locations on the East Coast this next week. So for security reviews are an important part. Physical access controls, these are the mechanisms to restrict access to facilities, rooms, and sensitive areas. The examples include locks, manual electronic access control systems, card readers, biometrics, and security guards. Do you have these in place and are you watching them? Surveillance, this is monitoring activities within and around facilities to deter, detect, unauthorized access or suspicious behaviors. Uh so one thing around this is you'll see a lot of times there's cameras up in the corners. Yes. Is somebody watching them 24-7? No. Now it used to be, or there wouldn't a lot of them didn't even have cameras in there because cameras were expensive. CCTV is extremely expensive. But now with the Wi-Fi stuff that's out there and the availability, and really it's really good. Uh, I you used to think, well, there's no camera in that little bubble there. Yeah, no, there's probably a camera in there, most definitely. However, is it being monitored 24-7? Yeah, no, it's probably not. Uh, but it's being recorded and stuck somewhere. Alarm systems and motion detectors, all of those are part of your surveillance plan and your CCTV overall strategy. Environmental controls, these are where systems are designed to maintain optimal operating conditions for IT equipment and prevent damage. Again, you have your uh data center that has raised floors where all the uh wires go, and then you have very cold HVAC that's going in there and it's making it extremely frigid. Yeah, I remember those days. Oh my gosh, you're just like freezing inside those rooms, and you're you're just like, oh, yeah, that was bad. Uh, this includes fire suppression systems such as inert gas, sprinklers, power conditioning, your UPS generators, and temperature and humidity control. All are part of your environmental controls for your data centers. You need to understand that for the CISP, most definitely. You need to just kind of have a good grasp of that. Equipment security, this measures uh to protect individual hardware and components from theft or tampering. Are your laptops and desktops connected to your desks so that that someone just can't walk off with them? This involves secure racks or your server racks as well. Uh so do you have cameras that are watching people coming and going, equipment cages and protecting network cabling? I did have a situation where an individual uh who was being fired went by these he knew what were the critical cables, and he just got the snippers, went snip, snip, snip. And yes, the whole organization shut down. It was amazing. And yes, that was a bad day for him and a bad day for us. Uh quickly realized what had occurred, but actually it took a while to figure out what exactly happened because it was like everything went down. I'm like, what the dickens is this? Until we did a little bit of snooping and then realized, oh, he severed those cables. Nice. That was awesome. Not really. No, we were not very happy. We used his word in his name in vain many, many times. Uh 7.15, again, 15. Address personal safety and security concerns. Travel. You need to implement some level of security protocols for employees traveling, especially to high-risk areas. This includes secure communications, device protection, and awareness of local threats. Security awareness training, you need to educate personnel on physical security policies, procedures, and best practices. This includes training on recognizing suspicious behavior and reporting incidents. All that should be done. You should have a security awareness training enabled for your company. Emergency management, this is developing and implementing plans for responding to various emergencies, i.e., natural disasters, fires, active threats, etc. And then focus on the evacuation procedures, shelter-in-place protocols, and communications during a crisis. So you need to have all of these things kind of developed and baked out. Now, even if they're not done to a point where they are at 100%, at least having them on a piece of paper so that they've been thought of is an important part. Duress, implementing mechanisms to signal a threat or force compliance without alerting the attacker. You need to have duress signals. In the case of my ice cream has a banana and frosting on it, that would be it really wouldn't be a good uh duress signal. But it could be yellow unicorns. Um my wife and I had a situation when I flew B1s that if something was going down, we wouldn't talk about security. But if I told her if it was this is bad, right? This is when something's really bad, I gave her a code word that said, if I call you and tell you XYZ, you need to read that is not good, and you need to get the kids and you need to head the heck out of town. So again, those are areas that we would talk to our parents, our kids about and our my wife about, so that she knew a duress word. This includes duress codes for access control systems and silent alarms. Uh so again, you want to make sure that you have thought about this. This I would say this one, the duress codes, uh, is probably one that is least utilized. Uh now in some areas where it's highly effective, yes, but it's it's probably one that most people forget about and don't actually talk about. Okay, so that is all I have for you. This is a long one. Yeah, holy moly, right? This is this is rapid review domain seven, security operations. It's a lot. But if you want this video and you want other content that helps you study for the CISSP, head on over to CISSP Cyber Training. Again, tons of free resources available to you. Lots of free stuff. I did, and we did that on purpose, right? So that you can pass the CISSP. However, if you were like me and you wanted something curated and you want data that you can kind of grasp a hold of and a process by which you can follow, like a boot camp of some kind, you want the paid resources. Yes, there's over 50 hours covering all the CISSP content, 1,500 plus questions, all of that is available to you at CISSP Cybertraining. All right, thank you so much for everything, and I hope you all have a beautifully blessed day. 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 Skyber 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 Sniper Training and sign up for 363 CISSP questions to help you in your CISSP journey. Thanks again for listening.