WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 00:00.800 --> 00:28.860 All right, let's take a look at 00:28.890 --> 00:34.460 Module 21, which deals with business continuity and disaster recovery. 00:34.490 --> 00:37.900 It's incredibly important. 00:37.930 --> 00:39.420 It's often overlooked. 00:39.450 --> 00:41.740 It's often under driven. 00:41.770 --> 00:43.620 It's often out of date. 00:43.650 --> 00:47.120 It's often inaccurate in what looks good 00:47.150 --> 00:52.140 on paper and what actually can take place in restoration procedure. 00:52.170 --> 00:53.660 Incredibly important. 00:53.680 --> 00:57.860 It needs to be properly planned, properly 00:57.890 --> 01:04.290 updated, properly practiced or trained on in a continuous basis to ensure that the 01:04.320 --> 01:11.160 business can continue to function in the absence of availability of critical 01:11.190 --> 01:14.560 resources or outages or whatever the case may be. 01:14.590 --> 01:17.600 This is a very important subject. 01:17.630 --> 01:20.700 I cannot understate that. 01:20.720 --> 01:22.280 The problem with a lot of business 01:22.310 --> 01:27.240 continuity and disaster recovery plans is that they're extremely outdated. 01:27.480 --> 01:32.920 Business disasters and catastrophes don't happen very often, so you can get a false 01:32.950 --> 01:36.290 sense of security that if it did happen, we'd be able to restore. 01:36.320 --> 01:39.520 When you've developed your continuity plan, your disaster recovery plan, it's 01:39.550 --> 01:42.740 been sitting on a shelf gathering dust for four or five years. 01:42.770 --> 01:45.200 Once this is developed, first off, a 01:45.230 --> 01:49.780 company without a business continuity plan, disaster recovery plan is 01:49.810 --> 01:54.140 hugely vulnerable to potentially going out of business forever. 01:54.170 --> 01:59.680 A lot of companies operate in really thin margins, and you'll see statistics like 90 01:59.710 --> 02:03.440 % of the companies on the planet, if they had to close their door for seven 02:03.470 --> 02:06.740 days or longer, would shut their doors entirely. 02:06.770 --> 02:09.820 Now, we've seen a lot of resilience, 02:09.850 --> 02:13.500 especially in the recent years with the pandemic. 02:13.530 --> 02:17.440 I think we've seen a lot of unexpected resilience. 02:17.470 --> 02:20.060 We've also seen a lot of unfortunate closures. 02:20.090 --> 02:26.580 But some of this stuff we can really plan for, some of this does come a left field. 02:26.600 --> 02:28.680 Nobody really expected a pandemic of this magnitude. 02:28.710 --> 02:31.680 But things like regional disasters and 02:31.710 --> 02:35.560 floods and hurricanes and so forth happen on a pretty regular basis, and we 02:35.590 --> 02:39.260 can pretty adequately prepare for those situations. 02:39.290 --> 02:41.450 First off, business continuity planning, 02:41.480 --> 02:51.200 or BCP, is often seen with the /DRP, which is Disaster Recovery Procedures. 02:51.440 --> 02:55.220 BCP/DRP, they're the same conversation. They're different, though. 02:55.250 --> 02:59.980 Business continuity planning is ensuring that the business entity is 03:00.010 --> 03:04.260 able to continue functioning in a disruption. 03:04.290 --> 03:07.380 We have disruptions, we have catastrophes, we have disasters. 03:07.410 --> 03:09.540 Disaster recovery planning 03:09.570 --> 03:15.420 ensures that the assets or the resources that the business entity relies upon 03:15.450 --> 03:21.160 are restored and usable again in a disaster, catastrophe, or a disruption. 03:21.160 --> 03:24.800 Let's go ahead and define disruption, disaster, and catastrophe pretty quickly. 03:24.830 --> 03:27.610 A disruption is a minor hitch. 03:27.640 --> 03:30.540 Hard drive fails in a server, that's a disruption. 03:30.560 --> 03:33.420 Does that mean we have to pull up stakes and move to an alternate site? 03:33.450 --> 03:34.060 Not at all. 03:34.080 --> 03:37.680 That means we're going to put another hard drive in or let the Raid Subsystem 03:37.710 --> 03:43.060 compensate for it, but a disruption doesn't affect the entire facility. 03:43.090 --> 03:47.610 A disaster renders the facility unusable for a day or longer, 03:47.640 --> 03:52.800 and a catastrophe destroys the facility, meaning that when you resume operations at 03:52.830 --> 03:57.200 an alternate site, when you resume back to the primary site, it's no longer there. 03:57.230 --> 04:02.460 You have to plan for new construction or relocation to a new location. 04:02.490 --> 04:06.940 You want to consider local regional disasters. 04:06.960 --> 04:08.920 We're going to talk a little bit about subscription sites. 04:08.920 --> 04:10.080 I'm going to throw some things in here 04:10.110 --> 04:13.500 that we don't necessarily see directly referenced in the slides 04:13.520 --> 04:16.880 that I like to talk about when I talk about business continuity planning. 04:16.910 --> 04:19.180 Bc describes the process and procedures 04:19.210 --> 04:23.840 followed by the organization to ensure continuity, ability to perform critical 04:23.860 --> 04:26.300 business functions during and after disaster. 04:26.320 --> 04:27.880 An ISO standard defines it as the 04:27.910 --> 04:32.140 capability to organization to continue delivery of services and products 04:32.160 --> 04:35.100 at acceptable predefined levels following a disaster. 04:35.130 --> 04:36.620 Who determines acceptable? 04:36.650 --> 04:39.660 Everybody all together now, senior management. 04:39.690 --> 04:42.380 It's business centric strategy, 04:42.410 --> 04:46.320 emphasizes more on maintaining business operations than IT infrastructure. 04:46.340 --> 04:48.700 So, the DRP is mostly the infrastructure. 04:48.720 --> 04:51.700 Okay, the first thing you do is an 04:51.720 --> 04:56.780 organizational analysis, which we're going to have a slide that illustrates that. 04:56.800 --> 04:59.160 But you'll do a risk analysis of the organization. 04:59.190 --> 05:01.500 We'll call that a business impact analysis. 05:01.520 --> 05:05.300 But the first thing you have to do is figure out how do we do what we do here? 05:05.330 --> 05:07.580 It sounds like an obvious question, 05:07.600 --> 05:10.200 but you'll be amazed how quickly you're going to get to it. 05:10.200 --> 05:11.300 I don't know. 05:11.330 --> 05:14.060 So how does this system work? 05:14.090 --> 05:15.140 I don't know. 05:15.160 --> 05:19.340 Bob actually implemented that, and he's been retired for four years, and it's a 05:19.360 --> 05:22.760 Unix box and nobody ever pays attention to it because it just keeps running. 05:22.760 --> 05:24.340 I don't think we've ever rebooted that thing. 05:24.360 --> 05:28.420 You're going to get to a I don't know or 05:28.440 --> 05:31.560 unfamiliarity with how something works, how are you going to be able to 05:31.560 --> 05:33.920 reconstruct something if you don't know how it works. 05:33.950 --> 05:38.860 This is a great opportunity to fully document how everything works, 05:38.890 --> 05:44.000 how it can be restored, and also allows for a possibility of updating 05:44.030 --> 05:49.540 legacy systems that may not be restorable in the event of a disaster and disruption. 05:49.560 --> 05:52.300 The first thing you're going to look at is what do we do here? 05:52.320 --> 05:54.200 There're different models for doing that. 05:54.230 --> 05:58.000 ZAP and frameworks and models, which define the who, what, where, why, when, 05:58.030 --> 06:01.060 and how do we do things here at X, Y, Z company. 06:01.090 --> 06:05.540 The first thing you look at is what do we do here? 06:05.570 --> 06:07.700 Oh, we improve quality of life through 06:07.730 --> 06:10.680 innovative polymers and plastics development and so forth. 06:10.680 --> 06:12.420 No, no, no, no, no, no. What do we do here? 06:12.450 --> 06:14.200 Oh, we make money. 06:14.480 --> 06:18.860 You look at how the organization generates revenue, which is what keeps it going. 06:18.890 --> 06:23.360 That makes it possible for them to fulfill their mission statements and business 06:23.390 --> 06:26.560 objectives and philanthropic operations and so forth. 06:26.560 --> 06:28.660 But if you're not generating revenue, you're dying. 06:28.690 --> 06:31.260 That is the lifeblood of any organization. 06:31.290 --> 06:33.460 How do we make money? 06:33.480 --> 06:36.180 What are the critical processes for making money? 06:36.210 --> 06:38.420 How do we keep that going? 06:38.450 --> 06:41.320 You will prioritize those processes based 06:41.350 --> 06:44.220 on how they contribute to generating revenue. 06:44.250 --> 06:46.360 When you say it like that, it sounds very 06:46.360 --> 06:48.300 materialistic and so forth, but it's a fact. 06:48.330 --> 06:52.260 That's what drives corporate functionality, revenue. 06:52.290 --> 06:53.500 How do we make money? 06:53.530 --> 06:55.620 How do we continue to make money? 06:55.650 --> 06:57.360 How can we 06:58.400 --> 07:02.300 adopt alternate methods, resume operation sites to continue to generate revenue? 07:02.330 --> 07:06.340 You're going to prioritize your critical time sensitive processes. 07:06.360 --> 07:10.900 You're going to identify your departmental relationships and interdependencies. 07:10.920 --> 07:13.140 You're going to map the whole thing out in 07:13.170 --> 07:18.540 a business organizational analysis and a business impact analysis. 07:18.570 --> 07:19.700 All right, so BCP is 07:19.720 --> 07:22.280 about keeping the company up and running in the event of a disaster. 07:22.300 --> 07:26.860 The business entity disaster recovery refers to the organization's ability to 07:26.890 --> 07:29.800 restore business data and applications after a disaster. 07:29.830 --> 07:34.380 So, this is the assets that the business entity relies upon. 07:34.400 --> 07:37.660 Our DR activities include the recovery of systems and people responsible for 07:37.690 --> 07:42.780 rebuilding data centers, servers, or other infrastructures damaged by a disaster. 07:42.800 --> 07:47.480 Remember, disaster just makes this facility or site unusable 07:47.510 --> 07:51.500 for a day or longer, usually means recovering somewhere else. 07:51.530 --> 07:53.540 It's a data centric strategy 07:53.570 --> 07:57.820 where emphasis is on quickly restoring the organization's infrastructure and data. 07:57.850 --> 08:02.940 The objectives, reduced downtime faced by an organization during and after disaster. 08:02.970 --> 08:07.540 Like everything else, proper planning ensures this happens in a timely fashion. 08:07.570 --> 08:11.300 But like everything else, proper planning is never enough. 08:11.330 --> 08:15.680 What looks good on paper doesn't necessarily map to reality. 08:15.710 --> 08:17.500 So, you got to practice this. 08:17.530 --> 08:21.620 You've got drills, you got full interruption test, you have parallel test 08:21.650 --> 08:25.940 to ensure you're able to actually do this in a live scenario. 08:25.970 --> 08:28.940 Reduce the losses accrued during an after disaster. 08:28.970 --> 08:32.860 Recover data that is damaged due to a hardware failure. 08:32.890 --> 08:35.600 There's more than that. 08:35.630 --> 08:37.420 Business continuity management then 08:37.440 --> 08:41.220 ensures your organization's operations are not affected by disruptive incidents, 08:41.250 --> 08:45.720 responsible for business recovery, crisis management, incident management, which 08:45.750 --> 08:51.060 we've already talked about, emergency management, and contingency management. 08:51.080 --> 08:53.680 The goals, ensure organizational 08:53.700 --> 08:58.200 resilience to disruptive incidents and disasters, equip an organization to 08:58.200 --> 09:00.760 respond effectively to threats from natural manmade disasters. 09:00.790 --> 09:04.020 We're talking a lot of risk analysis here, right? 09:04.050 --> 09:05.940 Including technological disasters and 09:05.960 --> 09:08.380 protect the business interests of the organization. 09:08.410 --> 09:13.160 Remember, we've got natural and we've got manmade and we've got politically 09:13.190 --> 09:17.420 motivated, a bunch of subcategories of threat sources. 09:17.440 --> 09:19.700 Our implications of business continuity 09:19.730 --> 09:24.000 management, update the overall BCP based on employee training, exercises, and 09:24.030 --> 09:27.960 reviews, manage recovery of applications, and the continuation of business 09:27.990 --> 09:30.580 activities in the event of a business disruption. 09:30.610 --> 09:34.820 A couple of things off the slide here. 09:34.850 --> 09:37.000 A business continuity coordinator is going 09:37.030 --> 09:40.860 to be delegated by or designated by senior management. 09:40.880 --> 09:43.140 They're going to be in charge of putting the whole thing together. 09:43.170 --> 09:47.800 They're going to recruit representatives from all the business units and functions. 09:47.820 --> 09:51.880 They're all going to come together and they're going to get an idea of what could 09:51.910 --> 09:55.340 happen, how bad would it be, interdependencies and so forth. 09:55.370 --> 09:58.500 You have representation from all the various departments, 09:58.520 --> 10:02.000 which you've got managers, you have technical types to get a realistic view of 10:02.030 --> 10:05.620 the threats that you face, and then you do a risk analysis. 10:05.650 --> 10:07.980 It's like any other risk analysis. 10:08.000 --> 10:09.660 You look at things like natural disasters, 10:09.690 --> 10:13.500 outages and so forth, and you look at how you're going to respond to it. 10:13.530 --> 10:15.700 Restoration orders, prioritization. 10:15.730 --> 10:19.460 A lot of this stuff is based on performance metrics, 10:19.490 --> 10:23.920 maximum tolerable downtimes, recovery time objectives, and recovery point objectives, 10:23.940 --> 10:27.140 which I'll sprinkle those in here in the appropriate slides. 10:27.170 --> 10:29.600 The business impact analysis is nothing 10:29.630 --> 10:33.500 more than a risk assessment to the organization itself. 10:33.530 --> 10:35.240 Systematic process determining and 10:35.270 --> 10:38.140 evaluating the potential effects of an interruption, 10:38.170 --> 10:42.400 disaster, disruption or catastrophe, to critical business operations as a 10:42.430 --> 10:44.940 result of a disaster, an accident, or emergency. 10:44.970 --> 10:47.480 Ascertains recovery time and recovery requirements. 10:47.510 --> 10:53.180 Recovery time is recovery time objective. 10:53.200 --> 10:56.540 There's also a recovery point objective. 10:56.570 --> 11:00.260 Then you've got what are called maximum tolerable down times. 11:00.280 --> 11:01.780 MIT, where did that come from? 11:01.810 --> 11:05.940 Maximum tolerable down times are maximum tolerable outages 11:05.970 --> 11:10.300 that are defined as the absolute longest you can be without something. 11:10.330 --> 11:16.300 When you establish these metrics, then your RTO is directly related to that. 11:16.330 --> 11:17.700 Pretty straightforward. 11:17.730 --> 11:21.140 How long can we be without this resource at the most? 11:21.170 --> 11:23.020 Four hours. Fantastic. 11:23.040 --> 11:24.420 We now have a recovery time objective. 11:24.450 --> 11:27.660 We need to resume within that four hours. 11:27.690 --> 11:32.140 That is measurable performance, especially in your interruption test. 11:32.170 --> 11:35.400 RPO is a recovery point objective, which 11:35.430 --> 11:39.780 states we need to be able to restore business data up to a certain point. 11:39.800 --> 11:41.680 For example, let's say you have a disaster 11:41.710 --> 11:47.240 on Friday and your RPO is no more than a day behind in backups, you have to restore 11:47.270 --> 11:50.700 your data sets to at least Thursday or Wednesday evening. 11:50.730 --> 11:52.740 It's the point at which you recover to. 11:52.760 --> 11:54.780 There may be some loss of data there, but 11:54.810 --> 11:59.300 RPOs are defined and also approved as acceptable by management. 11:59.330 --> 12:03.340 The underlying assumption in a BIA is that while each component 12:03.360 --> 12:05.480 of the organization depends on the continuous function of every other 12:05.510 --> 12:08.360 component, there are critical interdependencies. 12:08.380 --> 12:10.580 Some components are more crucial than others. 12:10.610 --> 12:11.620 Guess what they get? 12:11.650 --> 12:15.140 Asset values like any other asset. 12:15.170 --> 12:18.140 They get prioritized based on criticality, 12:18.170 --> 12:21.380 they get assigned a higher value, they are addressed first. 12:21.410 --> 12:25.420 Hence, these critical components should receive a larger funding and 12:25.450 --> 12:28.760 the recovery should be prioritized in the wake of a disaster. 12:30.600 --> 12:32.020 All right, so just like everything else, 12:32.050 --> 12:36.860 we spend more money towards what causes us potentially the most pain. 12:36.890 --> 12:40.920 The business impact analysis happens in multiple phases. 12:40.950 --> 12:43.580 We got a five phase scenario here as 12:43.610 --> 12:47.100 illustrated in a Certified Cybersecurity technician. 12:47.120 --> 12:50.120 You may see some different models depending on other sources where you read 12:50.150 --> 12:54.460 it, but they all follow a pretty common set of phases. 12:54.490 --> 12:57.620 Phase 1, the initiation of the BIA. 12:57.640 --> 12:59.400 Initiated upon the approval of senior 12:59.430 --> 13:03.200 management, senior management should always drive these projects. 13:03.230 --> 13:05.700 That's defined as a top-down approach 13:05.730 --> 13:08.380 which helps to ensure the success of the project. 13:08.410 --> 13:11.020 The initiation phase can be divided into two steps. 13:11.050 --> 13:14.980 Step 1, describing the objectives and the scope of the BIA. 13:15.010 --> 13:17.740 Scope, really important. 13:17.770 --> 13:23.080 Without scoping a project, you never have any certainty as to how much you're going 13:23.100 --> 13:26.300 to accomplish, and you always have this thing called scope creep. 13:26.330 --> 13:28.880 So, you need to find exactly what you are 13:28.910 --> 13:33.040 targeting and what you're going to accomplish, then you know exactly when the 13:33.070 --> 13:38.060 BIA is complete, and you don't have branch offices and things like that creeping in. 13:38.080 --> 13:41.280 Scope creep is when you keep adding things to the 13:41.310 --> 13:43.780 project that weren't laid out ahead of time. 13:43.810 --> 13:46.300 That means your timelines go on and on and on. 13:46.330 --> 13:50.540 Also, project milestones and timelines, really important. 13:50.570 --> 13:53.420 Without due dates and deadlines, nothing gets done. 13:53.450 --> 13:58.140 Without an expiration date or a drop-dead date, things just go on and on and on. 13:58.170 --> 14:00.880 You keep wrapping things in. 14:01.080 --> 14:05.700 Step two, forming a business impact assessment project team. 14:05.730 --> 14:07.260 Then you go into phase two. 14:07.290 --> 14:12.180 In phase two, the BIA project team adopts different information gathering methods 14:12.210 --> 14:14.660 such as interviews and questionnaire surveys. 14:14.680 --> 14:16.480 You're going to start interviewing and 14:16.510 --> 14:21.340 collecting information regarding, Hey, what threats might we face? 14:21.370 --> 14:24.760 This is standard risk analysis, which risk 14:24.790 --> 14:28.220 analysis we'll be talking about in the next module. 14:28.250 --> 14:33.980 Risk analysis gathers information in quantitative and qualitative metrics. 14:34.010 --> 14:38.740 Quantitative gives you hard and fast numbers, dollars and cents. 14:38.770 --> 14:43.100 Typically, you look at number of dollars lost, that thing. 14:43.130 --> 14:47.580 In qualitative, it's based on importance and, say, severity. 14:47.600 --> 14:49.800 On a scale of 1 to 10, Bob, how bad do you think that would be? 14:49.830 --> 14:51.340 I think it'd be a 6. 14:51.370 --> 14:54.140 A lot of times you'll average those values. 14:54.170 --> 14:57.500 There's lots of different ways to collect qualitative information. 14:57.530 --> 15:02.820 Interviews, questionnaires, focus groups, storyboarding, Delphi method, etc. 15:02.840 --> 15:04.300 The collected information is reviewed, 15:04.330 --> 15:07.900 documented, and summarized in tables, schedules, and diagrams. 15:07.930 --> 15:10.820 Phase 3 deals with the analysis of the information. 15:10.840 --> 15:13.840 Information collected is evaluated and reviewed manually or screened by computer 15:13.870 --> 15:18.700 systems to provide a prioritized list of business process or functions. 15:18.730 --> 15:24.200 Again, prioritized means the heaviest emphasis on a scale of 1 to 10 ratings, 15:24.230 --> 15:30.980 the higher rated qualitative metrics, also the most danger of dollar loss from 15:31.010 --> 15:34.580 quantitative definitely pushes something up the scale. 15:34.610 --> 15:40.420 You prioritize what is going to cost you the most harm, cost you the most money. 15:40.450 --> 15:42.460 Phase 4, documentation and findings. 15:42.490 --> 15:45.740 Findings are documented and the BIA report is prepared. 15:45.770 --> 15:48.640 Then phase 5, the final report is submitted to senior 15:48.670 --> 15:52.020 management for approval or decision making. 15:52.040 --> 15:53.560 Senior management relies on the report for 15:53.580 --> 15:56.800 developing strategies for DRP and for meeting a BCP. 15:56.830 --> 15:59.820 Now, senior management checks off on things. 15:59.850 --> 16:04.580 It makes it sound like they're actually crafting the disaster recovery. 16:04.610 --> 16:07.140 But management, it's not their job to 16:07.170 --> 16:11.620 craft the continuity planning or the business or the DRP. 16:11.640 --> 16:13.420 They're going to let those better, sooner 16:13.440 --> 16:16.560 qualified put that together, but they're going to oversee, they're going to drive 16:16.580 --> 16:19.820 the process, and they're also going to prove the final results 16:19.850 --> 16:24.300 on the recommendations of those who they've delegated to do the work. 16:24.320 --> 16:25.640 But you always check in with senior 16:25.670 --> 16:30.300 management, even if they're not developing the program, they're driving the program. 16:30.330 --> 16:33.020 A recovery time objective, I went ahead of 16:33.040 --> 16:35.220 the curve here a little bit of the slides on this. 16:35.250 --> 16:36.740 Recovery time objective, 16:36.770 --> 16:40.160 maximum tolerable length of the time a computer system network or 16:40.190 --> 16:44.400 application can remain dysfunctional after a failure disaster. 16:44.560 --> 16:48.480 It defines the extent to which an interruption affects normal 16:48.510 --> 16:52.420 business operations and the amount of revenue loss due to such an interruption, 16:52.450 --> 16:55.600 it's expressed in minutes, sometimes hours. 16:55.630 --> 16:58.260 But an example, an RTO of 45 minutes 16:58.290 --> 17:02.940 implies that IT operations must be restarted within 45 minutes. 17:02.970 --> 17:05.010 That's all stuff you can measure. 17:05.040 --> 17:07.290 Without measurable performance, you have 17:07.320 --> 17:11.570 no idea whether or not everything that you're putting together is realistic. 17:11.600 --> 17:14.720 You get this down on paper and then you practice, practice, practice. 17:14.750 --> 17:20.600 If you don't hit your time objectives, you revise, you practice again. 17:20.840 --> 17:22.920 A recovery point objective, again, is the 17:22.920 --> 17:26.240 maximum time frame which for the organization loses data after a major 17:26.270 --> 17:30.860 outage, provides a foundation for designing a DR and BC solutions. 17:30.880 --> 17:32.600 Every organization must calculate how long 17:32.600 --> 17:35.560 it can operate without the required data before suffering a failure. 17:35.560 --> 17:38.940 So, you get up to a certain point, there will be a certain degree of loss. 17:38.970 --> 17:41.460 You don't have backups that are up to the minute. 17:41.480 --> 17:43.080 Sometimes you do have their disk-to-disk backups.