[MUSIC] Part of the fourth module in incident security management is the testing of those plans, the IR plan, the business continuity plan, and the disaster recovery plan. Testing will help us identify any gaps, verify any assumptions that we've made. Test to make sure that we can recover based upon the pre-determined timeline. How effective is our recovery strategy? How effective are our people? And is the plan accurate and current? We test periodically at a minimum once a year. We put together the objectives for the test. We run the test, we looked to see if the test was evaluate effective. And then we look how can we improve this process, and then we scheduled the next test. What does periodic testing include? If you haven't tested a plan, there is an elevated risk because there's no guarantee that those systems can be recovered. Once you've defined the objectives, our job as citizens should be that there's somebody there, a third party that can monitor. My suggestion to you would be to get all of your auditing group and say, hey guys, we're going to be doing a disaster recovery plan. Why don't you come on down and watch? It's a free audit, bring them along, make them part of that process. Testing for the infrastructure is critical. There's no guarantee until you test that you can actually bring those systems up. So we need to know which applications are critical to the organization. What's the infrastructure that's needed to support those, and those are the things that we need to perform recovery testing on. What are the different types of test? There basically are what we call non interruptive tests and interruptive test. Checklists, I send each functional area a copy of their portion of the plan and I asked them to check it, to see if the parameter's right, RTO, RPO, WRT, and maximum tolerable downtime. Once we get every functional area to check it, then we get people together and we walk through a structured walk through. Do we have this sequence of events correct? And then I do a simulation, I identify half of the people and I say to that half, you're out sick, you've got the flu, you're in a hospital, you physically can't get to the site. Can the other half of the group do the test? Those three are non interruptive to the business. The two that do interrupt the business are parallel and full interruption. With parallel, I run the system at home, in the data center, and I also run the system at the alternate site, and I compare results. Are the results the same? With full interruption, I shut down my data center, my home data center, and I bring up that application at the alternate site. Best proof that you can recover that application. Well what about those test results? We need to verify that the results are complete. We use those test results to evaluate people's performance during the disaster recovery or the business continuity test. We determine if there is additional training that's required for people that might not have been part of the process. And we make sure that there's coordination between the team members, the customers, the external vendors, suppliers. The test results help us measure our ability and capacity, add that backup site to do the prescribed processing. Do we have the appropriate vital records there? Do we have the quantity and quality of equipment and supplies that we need to in order to be able to recover? And do we actually perform? We measure the overall performance, if you would, of that disaster recovery plan. Three different phases for test, we go through a pre phase or a pretest phase, getting everything ready so that we can go to do the second phase which is actually the testing itself. And then once we're done, we go into the third phase which is the post mortem or the lessons learned. When we look at metrics for recovery test, how long did it take us? What was the elapsed time? How much work was involved? How many of the vital records supplies critical systems were recovered on time? And what was the accuracy of the processing cycles that we encountered? [MUSIC]
