CISSP Cyber Training Podcast - CISSP Training Program

CCT 346: CISSP Domain 7 - Testing Disaster Recovery Plans and Why BEC Still Works Despite MFA

Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur Season 3 Episode 346

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 26:53

Send us Fan Mail

MFA feels like the finish line until you watch a company wire tens of millions of dollars to an attacker without a single password being stolen. We dig into why business email compromise (BEC) still works even in “secure” environments, because the real target is the decision point: trust, timing, urgency, and authority. When attackers can spoof executives or use deepfake voice and video, the authentication layer often never gets challenged in a meaningful way.
 
We break down practical, real-world defenses that go beyond “more tools”: fixing payment and approval workflows, defining what counts as a high-risk transaction, forcing out-of-band verification using known contact details, adding mandatory pauses for unusual transfers, and training teams with realistic BEC scenarios during end-of-quarter and holiday pressure. The big takeaway is that blocked phishing emails are not the same thing as protected money movement, and leadership has to own that gap.
 
Then we pivot into CISSP Domain 7 with a clear, test-focused walkthrough of disaster recovery plans. A DR plan on paper is not resilience, so we cover the five primary DR testing types: read-through checklist, walkthrough and tabletop, simulation, parallel, and full interruption. You will learn what each test proves, why most organizations stop at simulation, and how to build toward higher-confidence testing without taking reckless risks.
 
If this helps you, subscribe for weekly CISSP-focused cyber training, share the episode with a teammate, and leave a review so more people can find the show.

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!

Welcome And What You Will Learn

SPEAKER_00

Welcome to the CISSP Cyber Training Podcast. Where we provide you the training and tools you need at the CISSP exam first time. Hi, my name is Sean Gerbert. I'm your host of the Action Packing Formative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cyber checkered in the light. Alright.

CISSP Cohort Announcement And Timeline

Why BEC Works Even With MFA

Workflow Fixes That Stop BEC Losses

DR Testing Types From Basic To Full

Read-Through Checklist And Key Roles

Walkthrough Tabletop And Moderation

Simulation Tests And Building Muscle Memory

Parallel Tests Moving People And Operations

Full Interruption Tests And Business Risk

Wrap-Up Resources Reviews And Free Questions

SPEAKER_01

Good morning, everybody. It's Sean Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today is Monday, and we are having an amazing day today. Today is going to be one of those aspects where we're going to be covering disaster recovery plans. Yes, this is part of domain seven of the CISSP exam, and we're going to be getting into some of the nuances of it. But before we do, we also have some, we're going to be talking about an article that I saw in the CSO magazine, and it's related to MFA attacks utilizing, or I should say, BECs utilizing MFA. And but before we get into all of that, really wanted to put out a shout-out real quick for a new program that I'm putting out for the CISSP. And I'm pretty super excited about this. I've had feedback from people that have listened to the podcast saying, I want to take the exam, but I don't know what to do. And also when it comes down to it, the self-study stuff is great, but I really want something that's more structured. So I'm putting together a cohort. And this cohort is going to be starting July 7th. And the goal is over eight weeks. We are going to go week by week. We're going to be stepping through the CISSP so that when you get done at that eight week at the end of that pipeline, you are ready to take the exam. And you're going to schedule the exam. You're going to be ready to go. So that eight weeks, two months, if you get into this and what you're doing self-study aspects along with our cohort, you are going to be in a position that pass the CISSP exam. No question about it. I know it can happen. So we're going to get into that. You go to my website, CISSP Cyber Training, check it out. There's some great stuff there on what you need to do to get that cohort. But let's get into what we're going to talk about today. Okay, so the article we're going to be getting into is from CSO magazine, human-centric failures. So why the BEC still works even with MFA? So the core problem is that BEC is a thriving even when MFAs are deployed. And you're probably asking yourself, well, maybe what is a BEC? So a BEC is the business email compromise. And this is when an organization or somebody is targeting a company that sends out comp emails that are focused specifically on business activities. So what is going on with that? So in many modern attacks, there's no account is technically compromised, right? The MFA is simply irrelevant. And the reason behind that is these attacks succeed at the decision point, not the authentication layer. And how that comes into play is if you're sending an email to somebody to try to make a decision to forward money or to transfer money. It's at a decision of the decision makers to do this. And attackers are exploiting the trust, the timing, and potentially ingrained human habits that people have specifically around this. And so it comes into ZFI, the CEO, says, Hey, Julie, I need you to text or I need you to wire a bunch of money to me at X, Y, and Z. And Julie, maybe she's done this at some point in time. So now she has that frame of reference. So she'll do it. Well, it's becoming a bit more of a challenge, especially with AI. And how does this come into play? Well, let's kind of pull out a couple real world examples of where the BEC has been effective. And I'm going to include some of the aspects that I've dealt with when it comes to personal life. But when a one of the real world examples is the Toyota Rokushu in 2019. I said Boshuku. Boshuku. That's it. They lost$30 million when an employee wired funds after receiving a cloned email with urgency tied to production timelines, right? So big thing, production goes down. We need money. Please do that. This happened in 2019. There was a recent one that happened, and this is really interesting, is a roop engineering in 2024. Now they lost 25 million. Okay, 25 million, just like the guys lost 30 million. These are 25 million dollars after an attacker used deep fake video and voice to impersonate a senior manager on a video call. No stolen credentials, pure social engineering. So this is big. I mean, you know, back in the old days, I used to be uh Jessica, and Jessica was a very attractive young lady, and she was one that would go and solicit information from aviators in the military. Well, that all I have was a picture and some texting back and forth. Now you have audio of Jessica. You could have potentially picture video of Jessica. All of those things can come into play, and that's why it's a decision point. It's not the actual piece of this where the MFA will allow it, even if they say, Well, yeah, Joey says I need to get it. Joey says I need to send the money. Then you go and you click the MFA. So MFA doesn't control how people make the decisions under pressure. The adversary in the middle phishing attacks can now bypass MFA entirely. Now, EDR endpoint detection and response is an important part of all of this, but it's not the financial approval. Workflows usually are not tied to EDR. This is where you have to build the processes within your organization. And these are built for most processes within companies are built for speed, not for verification. Sometimes you need to slow down to speed up, and this is a factor, especially when companies are saying we need more automation. Well, automation is great. I totally love automation. However, there are places within your business, there's critical processes that should never be automated. Or if they are automated, they have checks and balances in place to stop any level of potential attackers gaining access. So you need to fix the workflows, define what counts as high risk, first-time payments, vendor banking, charting changes, executive wire requests, all of those are considered high risk requests. You need to require out-of-band verification using known contact details. Never info from the email itself, ever, right? Because all that stuff can be spoofed in any form or fashion. Add mandatory pauses before large or unusual transfers. Any large sum of money, I mean over X, depending on what your company is. So if you're a small business, maybe it's$10,000. If you're a big business, maybe it's$50,000. But you need to have pauses for large or unusual transfers. And then you need to route payment keyword emails to a risk review group before they're delivered. Again, you have to train your people to be think differently. Now, when it comes to that, training people to think differently, you need to, in your phishing environments, simulate real BEC scenarios with urgency, authority, and business context. You need to run exercises around end-of-the-ycles. I ran to this personally, is that even though if you send out an email, that's great for your testing, send it out during the times when they are expecting to be doing end-of-quarter type activities. Now, if your business reconciles your books every month, then they do end-of-month type of activities. But you need to make sure that you plan this around when people are going to be sending money. Also, when it comes to the holiday periods, what happens during the holidays? People want to go home. Well, an email comes in. You got to transfer money. Oh, I just want to go home. I don't want to deal with this. What do they do? They ship the money. So again, think about all these different things that go on. Now, what I come back to on this part is leadership must own this. No question about it. You need to make sure that your leadership is involved, they fully align with what you're doing, and they assign BEC risk ownership to the finance leadership or a cross-functional risk committee. Again, stop measuring success by blocked and phishing emails alone. You need to train your people on BECs. So the bottom line of this article, and I've a lot of stuff that I've kind of brought in there as well, is attackers don't need to break your MFA. They just need to trick your team into doing it, right? And business workflows must be treated as security critical systems, not an afterthought. So align the people, the processes, and the technologies. So verification is routine and authority is never, ever, ever assumed. Make sure you define that really well. It's an important part, and I highly recommend that. So, all right, so that's what we're going to talk about there. That's the article from CSO magazine, human-centric failures, why BECs continue to work despite MFA. Okay, so let's get into what we're going to talk about today. But before we do, have a quick plug again. Go look at the cohort at CISSP Cyber Training. Two months, get your CISSP done, join the cohort. It's what's going to help you get this done. You don't have to worry about a lot of other things other than allowing two weeks and then some study time. You need to make sure you have a plan for that. Okay, let's get into domain seven, seven dot one two test disaster recovery plans. Okay, so disaster recovery plans, as we all know, are an important part of any organization. And you need to have a plan on how to test these. So you need to create the plan, is the first step. So if you haven't already created your disaster recovery plan for your company, do that today. Get that going. Even if it is only on a bar napkin, it's an important part to begin this first step. Now, let's just say you have created this plan, you've got the documentation, everybody's aligned, it's all singing. Birds and little flowers and unicorns are all dancing around. Everybody is excited. So what do you do? Well, testing the plan is an important as is more is just as important as creating it. And you need to make sure that you test it because just because you have it on paper does not mean anything. That's just on paper, right? That makes your the uh auditors happy, but in reality, that is the minimum of it. So testing should be scheduled and prioritized, they should be set up specifically for what you're going to do, and you need to make sure you connect with the leaders in your company about when you're going to be testing. So this should be a thought-out process. This should not be adjunct or adjunct, ad hoc. And it should be something that is totally out there that you are putting together. Now there's five primary testing types. So we have a checklist, scripted, or reading test, and potentially tabletops. That's your first one. You then have a walkthrough. You walk through this specifically on how you would do this, potentially pulling up all the aspects related to it. You would then do a simulation test of some kind. And this would be where you maybe use some of the pieces of your DR disaster recovery plan. You maybe uh get a hold of the right people. You're you're doing a little bit more of a simulation with it. There's the parallel test. This is where you're actually doing a test in conjunction with what you're doing on a daily basis. So all of that is being done. So you've got your normal system up and operational, you then have your parallel test that's operating similar. And then you have a full interruption test. Now, the full interruption test is where you swing everything over to your new DR environment. That is obviously the capstone of this entire event. You this is something you would not want to do right away. I would highly recommend you don't do that right away. That will get you fired and will make people very, very unhappy. The read-through checklist. So, this is the most simple thing to you can do to conduct your organization within your organization. The per this is the most critical part of the beginning of any of these processes. And the reason is is it's to walk you through do you have what you need to begin this overall process? Now, one of the key aspects is going to be around who are the key folks that are gonna be involved with you during this process. And this would be your public affairs, your legal team, your IT team. Those are the key folks. Now, you your senior leaders, you may not want to bring them in just yet, specifically related to opportunity costs. So, how does that play into it? Well, you have a senior leader that's making X an hour, and you bring them in to talk about your DR plan. That is fine, and that needs to occur in future iterations. However, during this first initial read-through and walkthrough, it might not be the most cost-effective use of their time. So you may want to just get some folks in here, some key individuals, make sure legals is involved, and obviously and make sure your public affairs, because they're gonna be the ones that are gonna be out there talking to folks about what has actually occurred. You do need to make sure that your senior leaders are aligned, make sure they know what's going on because they're the ones that are gonna end up having to deal with this and buy off on it in the future. So they need to be aware, but they don't necessarily need to be in this read-through aspects of it. Now, this also allows for individuals to be part of the exercise. It evaluates how do they understand what's coming in, how's it going out, how's this overall this breathing of this process occurs. So, an example would be is when I had many, I've done many of these, and when I first come into an organization, public affairs, the legal team, even in some cases IT, don't really truly understand what this is. So, therefore, it's important for you to do this work beginning process so that they can understand it and they then can start putting their mental head around what are they going to do in the future and how's this gonna benefit them and the company. This also allows for you to evaluate and determine what will and what won't work. You're gonna be as you talk to people, you're gonna go, well, this application, we're gonna want to bring it back. And you're gonna go, they're gonna go, well, that application probably won't come back because of X. An example I had of this is when we had a company and they had a manufacturing facility, and I talked about this manufacturing facility, this critical system, that it would come back up online. The response I got back was, no, if that facility goes down, this is not coming back up online. It also is to help the business leaders understand that if that facility goes down or if the internet goes down, what do they lose when this situation occurs? So it's a great conversation starter. You need to introduce personnel to the process. This may be very new, like I mentioned earlier to these folks. They may not understand it. It may be a brand new concept to them that they've never had to deal with. So again, make sure they're under they're tied to it. You validate the scenarios that could occur versus wildish and outlandish situations. And what will happen is you're gonna go down a rabbit hole and they're gonna go, well, what if this? What if that? And next thing you know, you're gonna have these crazy, well, you may, but have these crazy ideas of what could possibly occur. And they could, but in reality, you're but need to look for something that is more solid from a scenario standpoint. These crazy ideas, they're as great as they may be and as out there as they might be, you need to make sure that you have at least the base foundation scenarios thought out, well rehearsed, and well planned before you start bringing these ones up that might not be as real that you may occur. Now, the next one is a walkthrough or a tabletop. Now, this is a structured process or walkthrough. So the last one was a little bit more ad hoc. It was more to get people aligned with it, understand what's going on, what you can do to help, and then get them understanding the overall process. But the next one, this walkthrough, is where you're actually doing a tabletop. You have it's the structure already done. You're now bringing some people, key people in, and you're gonna go over what are some different types of scenarios you may occur. This is a great process for testing emergency management processes, such as communications, logistics, those types of aspects. Do you have the people where you need them? Do you have power? Do you have food source? I mean, is there availability for people to eat? What are the latrine facilities like? All of those key pieces are gonna be things you're gonna walk through on the tabletop. Now, those will provide members of the DR plan written guidance. So out of this, so out of this tabletop, you're gonna have a findings of what's gonna occur. Now, you're also gonna have to have some sort of written guidance around how your DR plan will work. Now, what I say that is your first DR plan might be a little bit rough, might be a little bit kind of just added together with some baling wire and bubblegum. But when you after you get done with this tabletop, the goal is to take the findings from this and then enhance your your DR plan to meet the needs of this. So you make changes as needed, and you will this will be an iterative process. You're gonna keep doing this over and over and over as time goes on, and you're gonna refine and get your DR plan in a much better position. You're gonna want a moderator and a team member to sit around the table. The moderator is gonna talk through this, is gonna guide the people on which way to go. The moderator is a key part of it. Now you're gonna want to ask yourself can you moderate this by your own folks internally, or do you have to hire a third-party consultant to do this? Here's my recommendation. As you're starting off, don't hire somebody. That that that could be great to get you kind of a foundational piece, but I would recommend that you at least do the first few on your own to really understand the process, define what you want. So you have some at least some conversational things to ask the moderator before they come in. Because you can bring a third party in to help you build your DR plan, but they're not gonna know your company. You need to really embed yourself in this so that you know your company and what is the best for it. Now, if you bring in a third party at a later time to help you with maybe fine-tuning it, that's one thing. But by then, you have a good understanding of your company and how your disaster recovery plan should work. You need to evaluate various scenarios during this rate read-through checklist. Again, that's the one that we did earlier. You need to look at some of the different scenarios that you actually went through on that. Now, again, it's an iterative process. This isn't okay, I created it and then I'm done with it, and I set it on a shelf. You can do that. You can create this thing, put it on a shelf, never to see it again. And then when something happens, which I guarantee you will, you are not gonna know what to do. You may have some some nuances to it, but in reality, you're gonna go scrambling. Probably for the DR plan and then potentially for a new job because it's not gonna go well. This is gonna take time and effort and energy for this to all work. The simulation test. This is very similar to the structured walkthrough or tabletop. However, what's going to happen is that some of the scenarios that you've come up with, you are actually going to attempt to probably do a test. You're gonna go and maybe pick a couple of the systems that are in your scenario and then try a disaster recovery plan on them. So it's again, you're taking the structured walkthrough, and you know that you let's just say, for example, you have databases that house some of your most important information for your business. You then will then in turn take that and work to do a recovery of that database. Now, I would recommend that you have adequate backups in place, you have a good plan on how this is going to go down, and you definitely don't use something that is a critical to business function. You want to use something that's non-critical. The purpose of this, and even if this is a system that you've backed up routinely over and over again, that is totally fine. What you want to do is you want to get into the people, the mental gymnastics, the muscle memory that's going to have to occur on what you need to do. So you're gonna go, you're gonna bring everybody in, you're gonna go through this scenario. We're gonna go, let's go ahead and call the IT people to reboot uh and reinstall this image for our database. Okay, great. They did it. They call you back. You now say, let's go ahead and make sure that the database has all the right information in it. Run your diagnostic checks to make sure of that. Yes, it does. Okay, let's do a sample and let's make sure that it's up and operational. Yes, it is. Let's go and do a take a picture of that, and we can store it within our audit and assessment risk environment. Do you do that? So, all of these things are just these step-by-step processes by which you're going to deploy this. And the goal then is you start small on a non-critical system. As you then do begin to do this more, you will then move into more critical systems. And you may even, before you get into this, we want to talk about next the parallel system, you may even start with some critical systems before you go down the parallel path. And they may be nuanced one-off type systems. Now, I will tell you that most disaster recovery plans stop here. Many people don't go beyond the simulation test. They just don't. One, they don't have the time and energy to do it. Two, they may not have the capacity for the people to do this. Or three, based on the risk profile of the organization, they feel confident that they have enough of the simulations that have gone through. We have enough backup and recoveries in place. We don't need to go through the entire litany of full restore of most critical systems. Now, again, just keep that in mind. This is where most people stop. Maybe a question they ask you on the CISSP about that, but know in fact that the parallel test and the the next one I go on after that, the full interruption, those typically are not done by most organizations. But you should strive to get there. I think if you can do that and strive to get into the parallel and the full interruption, you are put your company in a position where you are extremely resilient against some of these areas that are going on. Now, the parallel test. This is where you recolocate key personnel to alternate recovery site. This is where you may have a recovery site that's set up in a warehouse. This is where you locate them to that. Your employees will then operate a disaster recovery plan based on what you've already created. So again, you you pick them up, you move them, you make sure you have the power there, you have the food there, you have the facilities there. All of that is in this parallel test. Now, the main facility is not impacted, right? So no tornado has hit it, no stray backhoe has taken it out. You are just in the position of picking up and moving people to this. So as you see, this could be a very big impactful event, especially to operations that are going on. So you may want to consider doing this maybe on a Saturday. Uh, and then obviously you'll be paying your people in time and a half or for whatever you're be paying them for that. But you'll want to make sure you build that into your budget that you're gonna be requesting their services on a Saturday. Saturday. Now, would it require everybody? No. Would it require some key people? Yes. And so you're going to need to work through all of that with your folks. But you'll need to maintain your day-to-day activities. Again, this is parallel test when what's going on. It will not impact your critical business system, but it will impact your potential people that are working on that critical business system. Then the last one is a full interruption. This is where you do a full test with an operational equipment. This is where you swing from production to test, and then you run in the test environment. Now, I'll tell you, many people will not do this for sure. The reason is because I just don't have the one, the capabilities to do it, and two, the more or less the manpower to do something like this. However, what I say, this is that you don't have to think about moving and migrating an entire data center over. You can think about, hey, I have five main critical systems. They are the most important to my company. And I feel confident that we have during these downtimes, let's say June is a bad time for your business. It's just real slow. Well, this is where you would build up. You're going to do a full swing in June of say 2026, where you're going to swing over your five critical systems to this production. So you plan on it, you have it set up. It's a year-long process to do this. And again, it will take somebody most likely to lead this organization, to lead this plan. It typically doesn't work well as a secondary job unless you have a very small organization. But if you have a big organization, you're going to have dedicated people to do this specifically. But you have a time and place where you'll spend and you'll say in June, we're going to go and swing everything over. Now, in some cases, people will go, all right, we are going to have slow times in June, and then we have slow times in January. So what we're going to do is we're going to swing from production over to our DR environment, and we're going to run from basically June until January. And then in January, we're going to swing it back to the production. This can happen. People have done this. I've seen people that do this and they do it very, very well, and they have a resilient organization. Now, is their entire organization resilient from malware? No. That would be too cost expensive, it'd be too cost prohibitive to do something like that. And so therefore, what they do is they find their critical systems, their most critical systems, and they are the ones that they move and they migrate over during this testing. So it's an important part of all of this is that you figure out your full interruption of when you want to do this. Now it does incur some significant risk. You need to have a good plan for this. And it really requires a really strong plan with full business integration and support. The business has to be aligned with this plan. When it comes to the partial or the parallel aspects of this, you can get business alignment, but they'll allow this type of activity because it's working in parallel to their operations. It's not really affecting them. But the moment you do a full interruption and it impacts business operations potentially, you're going to need significant horsepower behind you to do this. It's the best option for you and your organization to ensure that you have a resilient company that can withstand any sort of malicious attack or any sort of physical situation. So again, full interruption is the best, but not everybody does it. Okay, that's all I have for you today. I hope you guys enjoy this. Go check out CISSP Cyber Training, lots of great stuff. Look at my cohort. If you're looking to get your CISSP done in eight weeks, we have a plan for you. We can knock this out. It's like a boot camp, but uh it's going to be in a situation where you based on your schedule and your studying habits. If you are the self the person that wants to self-study and has eight weeks to do it and doesn't have 10 grand to spend on a boot camp, my cohort is the thing for you. Go check it out. There's a banner for it. You can sign up for my wait list, and we can then go ahead and get you started. We'll be getting January or July 7th is when we're planning on making this happen, July 7th, and it's going to go for eight weeks starting in July. Okay, hope you all have a wonderful 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.

SPEAKER_00

Thanks again for listening.