Pass Your CompTIA CASP Certification Easy!

Prepare with top-notch CompTIA CASP certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All CompTIA CASP certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Business Continuity (Domain 4)

1. Business Continuity (OBJ 4.4)

In this section of the course, we're going to cover business continuity. We're going to be focused on objectives for four, explaining the importance of business continuity and disaster recovery concepts. Now, as we move through this section, we're going to start out by discussing business continuity planning and then diving into the fundamentals of a business impact analysis. Next, we'll dive deep into privacy impact analysis so you can better understand the importance of privacy in our organization's strategy and goals. Then we're going to discuss incident response planning, including the different roles and responsibilities involved during an instant response, as well as the importance of documenting your lessons learned from an instant response in your after-action reports. Finally, we'll discuss how you can test your business continuity, disaster recovery, instant response, and other plans within your organization. This includes the use of checklists, walkthroughs, tabletop exercises, full interruption tests, and parallel tests or simulation tests. Now, this section is all about following the old Boy Scout motto "Be Prepared" to ensure your organisation is prepared. We need to ensure we have resource plans ready to go, and we must ensure that they are practised and exercised at regular intervals. So let's jump into the section on business continuity.

2. Business Continuity Plan (OBJ 4.4)

In this lesson, we're going to talk about your Business Continuity Plan, or BCP. Now, business continuity planning or the creation of your business continuity plan is going to ensure that the organisation is able to recover from a disruptive event or a disaster. This is a specialised field within an organisation, one that takes a lot of planning and, fourth, is necessary to keep the organisation running smoothly during an event or incident. Now, there are two major terms associated with business continuity planning. The first is business continuity planning or the business continuity plan itself. This refers to the plans and processes used for your response to a disruptive event. Now. The second is a disaster recovery plan, or DRP. This refers specifically to plans and processes that are used during a disaster. Now, the disaster recovery plan is usually going to be considered a subset of a more complete business continuity plan. When you think about a BCP, this is a plan that's used for any disruptive event or any response to any kind of threat. Now, for example, what would you do if your domain controller fell victim to a ransomware attack and all your users could no longer log into the network? Well, this would be a disruptive incident, and it might activate not only your incident response plans but also your business continuity plans. That's what we're talking about here. Your business continuity plans are all about creating a system of preventative actions and recovery steps in response to threats that could materialise and disrupt your business. Now, your BCP may also cover non-IT things that could disrupt your businesses. For example, in my business, we rely heavily on our ability to take credit card payments online from our students. So if a merchant processing account was going to be cancelled for some reason, this would affect our ability to take payments from all of our students and would be a major issue for our company. So, as part of our BCP, we discuss how we're going to immediately switch to our backup credit card processor so we can continue our business operations and simultaneously work with our primary credit card processor to get them back online again and get our cards going. Now, if our primary processor can't get us back online within X number of days, where are they going to shift to a tertiary contract that we have set up that will allow us to continue operations indefinitely, even though that tertiary processor may charge us more for each processing transaction? This is the basis of a BCP. You plan for your primary, secondary, and tertiary actions because you want to continue your business operations. Now, another example I saw in a previous organisation was focused on what they would do if there were protests in the streets. Now, this was an IT organization, and it may seem kind of weird to you, but their headquarters is actually located near a major American city. When there are riots and protests in that city. It disrupted their business because their employees couldn't get to the headquarters to go do their jobs. Now, this was because the streets started getting barricaded,either by the protesters trying to make a pointor the police trying to hold back the rioters. After that incident, the company learned that they needed to have a backup plan for how they're going to keep their operations running all the time, even if they can't get people physically into the office. Now, we just spent a little bit of time talking about the basic idea of a BCP, but let's touch on the concept of a DRP as well. Now, a DRP is your disaster recovery plan, and these are a subset of your business continuity plans. It's going to focus on disruptive events just like a BCP would, but it focuses specifically on how to resume more quickly after you have a disaster. For example, my offices are located in Puerto Rico, which is very likely to suffer from hurricanes and earthquakes because of its location in the Caribbean. Now, RBCP contains a DRP portion that's focused on our response actions for both of those things. So if we have a hurricane, how can we keep our offices open and our servers online 24 hours a day, seven days a week? And if we can't, what are we going to do in response to that? What are we going to do if there's an earthquake, a fire, a flood, or another disaster? All those things are things we have to think about. For example, when we did our risk management analysis, we determined it was too risky to host our servers within Puerto Rico because of the threat of power losses due to hurricanes. So we instead built our entire backend infrastructure in the cloud, and we use AWS and Google Cloud. That way, even if we had a severe disaster in Puerto Rico, our operations could continue on.Another thing we did is split our staff across multiple locations, both within Puerto Rico and in a few other locations around the world. For example, my Student Success Team is split evenly between Puerto Rico and the Philippines. When there's a power outage in Puerto Rico, the Philippines team takes over operations and continues to work to make sure students are taken care of. Similarly, we've had floods in recent years over in the Philippines, and our Puerto Rico team had to step up and cover for the Philippines team because the Philippines team couldn't get to work. Now, this way, we can continue our operations even in the face of these disasters. So now that we've covered the differences between a BCP and the DRP it contains, for the rest of the section, I'm only going to refer to the business continuity plan. But when I do, remember, I'm referring equally to the BCP and the DRP it contains, because the only real difference is the type of event you're responding to. Is it an incident or is it a disaster? Now, the development of your business continuity plan is the responsibility of the senior managers within your organization. It's really up to them to drive this effort and ensure it's done properly. Without their support, the BCP's development is going to certainly stall out and fail. For this reason, it is the responsibility of senior management to set goals for the business continuity and disaster recovery efforts under their direction. A business continuity coordinator is going to be appointed, and they're going to lead the business continuity committee. This committee should have representatives from different departments across the organization: IT, Legal, Security, and Communications, just to name a few. This should not be done solely by the it people. We all need to work together. This committee will work to determine the recovery priorities for the various types of events that may occur, whether they are disruptive and will be covered by the BCP or a disaster that will be covered by our DRP. This committee is also going to seek to identify and prioritise all of our systems that we need to support for the continuity of the business, and then report that back to senior management. Now, another key part of a good business continuity plan is defining the scope of the plan itself. Otherwise, you may face scope creep. Again, this is a job for senior management because they need to determine the level of risk they're willing to accept based on the organisation's risk appetite and tolerance. The BCP can be broken down by business function or by geographical area if you're working in a very large organization. But again, all the pieces must be coherent and they must be able to operate together, especially during times of crisis. While you don't need to create a BCP for the CASP exam, you should know the seven major steps to perform as outlined in the NS special publication 834. The first step is to develop a policy for contingency planning. The second step is to conduct a business impact analysis. Your third step is to identify preventative controls. The fourth step is to create recovery strategies. The fifth step is to develop the business continuity plan. The 6th step is to test, train, and exercise the BCP. and the 7th step is to maintain the BCP. Now, we're going to talk more about some of these steps as we move through the course. Finally, when you're creating your BCP and your DRP, you need to consider what type of continuity you need to create using these different plans. From a technical perspective, we're going to break this down into four categories or types of continuity location: hot sites, warm sites, cold sites, and mobile sites. All right, let's take a look at each of these, and we're going to start with my favourite type of backup site, a hotsite. Now, a hot site is defined as a site that is up and running continuously, essentially at a moment's notice. We can switch our operations from our main site to our backup site with almost no downtime and no issues. Now, this is my favourite type of setup because it means you are always up and ready to go, and you can keep your business moving forward even when disaster strikes. But the drawback is that it's very expensive to have this kind of redundant site. For example, to truly have an on-demand and ready-to-go hot site, you're going to need to have two of everything. If I have a file server in the main office, I need to have another file server on the hot side. You're going to need to constantly update and communicate, and mirror the data between both sites so you have an updated copy at all times. Now, in the old days, this was extremely difficult and expensive to do. But the good news is, with cloud computing, this has become much, much easier because you can now have your servers hosted online at multiple locations simultaneously using AWS, Azure, or the Google Cloud Platform. Now, while this type of hot site for your servers is great, it doesn't fully consider everything you need in terms of a hot site. Again, what about your office building where your employees are actually going to do their work? For example, let's say there's a fire and your entire headquarters gets affected. You have smoke damage and water damage now because of this fire, and now it's going to take six months to rebuild your headquarters. Well, if you have a fully redundant cloud-based model for your hot site, this means all your data is up and running instantly and ready to go. But you had 500 people working in that office building, and now you need to find 500 desks, 500 chairs, 500 phones, 500 computers, and all that stuff to get ready to go so people can go to work because everything else was destroyed in the fire. This is why a "hot sight" is usually not used by most companies for their entire business. But instead they use it just for mission-critical things that have to be up 24 hours a day, seven days a week, continuously. Now, this brings us to our second category, a warm site. A warm site is not fully equipped like a hot site is. Remember, in a hot site, we have desks, chairs, network connectivity, computers, phones, software, and everything else we need. So an employee can simply walk in and start working. Well, with a warm site, we're not ready for an immediate switchover, but we can get up and running in just a few days. A warm site will already have the fundamentals in place. For example, the building has power, it has phone lines, and we have network connectivity. We may have some desks, but there may not be any phones or computers already installed. Now, if a disaster happens, we can then start installing the technology and get people up and running within a few days because we just need to buy some laptops, some monitors, and some phones. Now, the benefit of a hot site is its instant availability, but it comes with a very high price tag. Now, a warm site is a little bit cheaper, but you're giving up some response time because you have to wait a few days to get it up and running. That's the difference as you look at these things. The third category we have is known as a cold site. Now, this is going to add more time to our recovery, but it is cheaper than using a warm site. A cold site contains even fewer facilities than a warm site does. For example, one organisation I worked with in the past had a cold site that was essentially just an empty building they had a lease on. They paid a monthly rent for this building, and nobody worked there. The cold site had a few basic facilities likethe bathrooms and the tables and the chairs, butthere was no network connectivity, there was no phonelines and there was no computers. Essentially, it was an empty shell. And in the event of a serious disaster at their headquarters, they could turn this cold site into a new headquarters in about one to two months. Now, the final category we have is known as a mobile site. Now, a mobile site can be a hot site, a warm site, or a cold site. Basically, up to this point, I was discussing how you can go from one building to another with a hot, warm, or cold site. But with a mobile site, we don't even need buildings. Instead, we use independent and portable units to provide recovery. Most often, this takes the form of trailers or tents that are delivered to your location and connected to your power and Internet. And that way, you can get up and running pretty quickly. For example, the US military has something known as the DJC too. This is the Deployable Joint Command and Control System. This thing is an integrated command and control headquarters that can be delivered anywhere in the world within about 72 hours. Now, once it gets on the ground, it takes them around 24 hours to start providing some functionality and service. This system is made up of a series of tents, and they have generators for power, they have air conditioning, they have tables and chairs, they have phones, and they have network connectivity. And they can support up to 200 people inside one of these things. For example, after a major earthquake in Haiti back in 2010, the US Military deployed one of these DJC 2s there to act as a mobile command centre and run the recovery operations. Now, the great thing about this Pep Mobile Recovery site is that it is fully contained. They come with everything you need, including power, connectivity, and technicians to run the whole thing. So which of these sites should you use? Well, this is why senior managers need to be involved in the BCP creation process. Sometimes you're going to choose one of these, or you might choose multiple of these, breaking them out across different business functions, different scenarios, or different timelines. For example, in my company, we use a full-time hot site for our servers to ensure they're always up and operational at all times. But we don't use a full Web site for our employees. Instead, we have a small office and allow and encourage telework in our organization. So for the most part, most of my team members are working from their own home offices. Because we've built our entire technical infrastructure to support a fully remote workforce, If one of their home offices loses Internet or power, we could simply have them go to a local hotel, and as long as they have Internet and power in the hotel, they can reconnect and go back to work right away. Now, in addition to that, we also plan for power outages and Internet outages at our office because we have primary power delivered by solar panels, and then we have battery backups for the times the sun isn't out. Now, if we run out of battery power, we can also go to our backup generators, and we also have a connection back to the local power grid, so we can pull power from there too. If we needed to see for Internet connectivity, we do the same type of thing. We have three different connections to our office. The first one is a microwave link that gives us high-speed uploads and downloads. If that fails, we have a redundant connection from a local cable company that provides high-speed downloads but slower uploads if both of those fail. We also have a cellular modem backup, and this provides about 20 megabits per second of service for uploads and downloads. By layering our Internet connectivity as part of our business continuity plan, we know that our expected response in downtime would be for a primary Internet connection failure, for example, because we can shift to the second one in seconds or the third one in seconds after that. So when you're creating your BCP and your DRP, remember, you can't just think of the technology stack; you also have to think about where your people are going to work and how you're going to support them long-term as you attempt to continue to support your operations and your customers.

3. Business Impact Analysis (OBJ 4.4)

Another crucial business document to consider when developing your security policy is your Business Impact Analysis, or Bia. Now, a BIA is a functional analysis that's conducted as part of the development of your business continuity and disaster recovery plans. A business impact analysis will list the critical and required business functions that might need to be maintained during a new disaster, including the necessary resources to maintain those functions and just how critical those functions are to your overall business. That business impact analysis is going to be a management-level analysis performed to identify the impact of losing organisational resources. This analysis can rely heavily on previously performed vulnerability assessments and risk assessments, or you may perform additional analysis separately. For example, if your organisation is located in Puerto Rico, Florida, or Texas, you need to consider what business functions are crucial to maintain if there's a hurricane heading your way. Not every function in your business is going to have to be done on a day-to-day basis and be considered crucial. Some of them may only become crucial if you lose them for a few days. This is why it's important to conduct a business impact analysis. When we talk about crucial functions, we often call these things mission-essential functions or "mess." Mission essential functions are the limited set of functions that must be maintained or resumed as soon as normal operations are disrupted. For example, in my own business, we perform a lot of different functions to make these courses and deliver them to you. But not everything we do is considered a mission-essential function. For example, let's take the example of this course. The ability of our students to watch the videos after they've purchased them is one of the mission-critical functions that we must prioritise and maintain at all times. You want to make sure you can watch the videos, take the quizzes and exams, and download the study guide. Now, from the business side, we also need to ensure that we can sign up new students, that we can process their payments, and enrol them into courses. So all of those things are going to be considered mission essential, and we want to make sure they work 24 hours a day, seven days a week, all the time. On the other hand, being able to respond to our students' reviews of our courses is not a mission-essential function. Now, it's a great thing to do, and we do read every review you submit and respond to it. But if I respond to it within five minutes of your posting or two weeks later, it really won't make a tremendous difference to you or our business. So we won't prioritise that as a function that must continue throughout a disruption or be restored shortly thereafter in the case of a hurricane or other disaster. The same thing is true of video editors and their job functions. Yes, they are critical to the success of my courses. But if they're without computers or power for a week or two, the business can survive. We would just have to play catchup once the power is restored. Now, I can't say the same thing about running our video servers, though, because if I told you that my servers were down for the next two weeks, you couldn't watch any courses, and that would probably bankrupt my business because you'd all leave negative reviews and comments and leave my courses. Now, that is the idea of what an essential business function is. So let's talk about how we conduct our business impact analysis in a more formal way than the quick way I just described it in my example. Now, like a risk assessment, the business impact analysis has four steps. First, we identify the crucial processes and resources in the organization. Second, we identify the impacts of an outage and estimate the downtime for those crucial processes. Third, we identify your resource requirements. And fourth, you identify the recovery priorities. Now, the first step is identifying critical processes and resources in the organization. Each of these processes and resources are then going to be assigned to a responsible party to gather the information concerning them. This data gathering can be accomplished using questionnaires, interviews, surveys, or even using some more technical metrics and methods. As your data is gathered, it's going to be analysed to identify any dependencies. For example, if I need a certain server to remain online, we also need to make sure we have power and cooling to support that server. The second step is to identify the outage impacts and estimate the downtime that could occur. Each asset is assigned a criticality level, such as critical, urgent, important, normal, and nonessential. Based on these categories listed in our disaster recovery plan, each asset is going to be prioritised for service restoration. Critical resources should be restored within minutes or at most an hour. While urgent ones can stay down for up to 24 hours, items that are classified as important need to be restored within three days and normal ones within seven days. If something is deemed nonessential, that means it's a service that could be disrupted for up to 30 days without really hurting your business. People must now be truthful and honest in their assessments of the criticality. Remember, if everything is considered your number one priority for service restoration, then nothing is really a priority, even within your categories. It's helpful to categorise things as part of a sequentially restored plan. For instance, if you have five servers that need to be restored and they're all critical, which ones should be the 1st, 2nd, 3rd, fourth, and 5th? You only have so many technicians available, and they can only focus on restoring one thing at a time. Now, downtime for an asset can occur for many different reasons, and each asset and component of a service can be tracked over time. to better understand those downtimes. This includes looking at things like your maximum tolerable downtime, meantime to repair, meantime between failures, recovery time objectives, work recovery time, recovery point objective, and recovery service level. Now, when we talk about a maximum tolerable downtime, or MTD, this is the maximum amount of time that a business can tolerate that asset or component being down. This is also sometimes called your "maximum period of time disruption," or "Mptd," or your "maximum tolerable outage," or MTO. The more critical a function is, the lower the maximum tolerable downtime will be. For example, if my credit card processing is considered a mission-essential function, I may assign a maximum tolerable downtime of less than 1 hour to this. This means if my credit card processing is down, I need to have plans in place to get it back up and running within 60 minutes. And I'm going to build all my backups and redundancies around that 60-minute timeline. to calculate your MTD. You're simply going to add up your recovery time objective, RTO, and your work recovery time, WRT. Now, the recovery time objective, or RTO, is the shortest period of time in which an asset or component should be fixed to prevent any negative consequences for the business. Essentially, your recovery time objective should be the acceptable downtime, and as such, it must be smaller than your maximum tolerable downtime. The RTO is a measure of when the system is going to be available again to start processing recovery work before you put it back into a normalised production mode. Now, the work recovery time, or WRT, is the difference between the maximum tolerable downtime and the recovery time objective. Basically, this metric tells you how much time was left over after a recovery time objective but before the negative effects started to be experienced. So your WRT is the amount of time it takes to get the critical business functions back up and running once your hardware, software, and configurations have been restored. Now, a lot of times people get confused here, and they say, "Jason, why isn't the MTD just equivalent to the RTO?" Well, there's a reason for this. It's that when you're dealing with complex systems and technologies, there are often multiple interconnected systems and they need to be resynchronized, the data needs to be tested, and anything that was manually captured during the downtime also needs to be put back into the system again before we can fully classify that system as fully up and operational. So this additional time for those functions is called the work recovery time, or the WRT. and that is the difference. So let me give you a quick real-world example here. In one of my previous organizations, we had a file server crash. The maximum tolerable downtime was 24 hours for this file server. Now, this was a big file server. It had, like, hundreds of terabytes of data. So one day we had a crash on that file server. Essentially, the backplane failed and it had to be replaced. So we powered down the server, replaced that backplane, and turned the server back on. That took us about 2 hours to get that file server repaired and back online. Now, our recovery time objective was 4 hours, so we were well within those limits because 2 hours is less than 4 hours. But due to that backplane failure, data wasn't syncing properly, and the drives became corrupted. So now we had to reset the drives and perform a file system utility to validate the data before it could be considered fully up and operational. So we started running the process, and it was estimated to take 67 hours to complete. Now, that was well beyond our maximum tolerable downtime of 24 hours. So we created a new shared drive for the organization, and they were allowed to use that in the meantime as a workaround. Now, while we're working on the full restoration of the old file server, they are all using this new file server. Now, the moral of the story is that just because the system was back online, it doesn't mean it was fully integrated back into the network and the data was synced back up. Instead, we were dealing with the work recovery time of 67 hours to get all that stuff done, and we had to add that to the RTO or recovery time objective, which we had met within 2 hours, to calculate our maximum tolerable downtime, or in this case, our maximum downtime. Next, we have MTTR, or the mean time to repair. This is the average amount of time it takes to repair an asset or component when a disaster or disruption occurs. Depending on the planning method used in your organization, we'll usually look at the mean time to repair on either a component or a system level. For example, let's say I have Auser's desktop and a memory module fails. How long does it take to repair that? Now, the physical actor replacing that memory module might take me 60 seconds. It's pretty quick to do, but there is time associated with identifying that issue, setting up a trouble ticket, gaining the new memory from the supply closet, shutting down the computer, putting the module into the system, powering on the system, verifying it works, and so on. So if we add up all that stuff together, maybe it's an MTTR of 54 minutes. We calculate this based on the average or "meanwhile" across all the similar repairs we've done for that issue over a given year or other period of time. Now, another mean time we have to measure is the time between failures, or MTBF. Now, this is the average amount of time an asset or component will operate before failing. When you purchase new devices, the time between failures is an important consideration. It's a piece of data that the vendor can provide to you while you're trying to make your decision. So let's use a memory module example from the user's desktop. How long should it work in between failures and before it needs to be replaced? Well, this is going to depend on a lot of factors, such as what model it is, what brand it is, the environment that desktops are being used in, and many others. But if you look at the manufacturer's documentation, they'll usually list the mean time to failure, and you can use that for your planning. For example, if you have a Cisco G2 router, it can run up to 300 0 hour, which means it has a useful life of five to six years. So you should plan to replace that router before it fails, which will happen on average. That time period between failure and five to six years This way, you can plan the repair of the router before it fails at some unknown time and causes downtime for your organization. Now, another important metric is the recovery point objective, or RPO. This is an established point in time when the disrupted asset or component should be returned to normal function. This is based on your criticality levels that we discussed earlier. RPO, in my opinion, should be used to determine how much data we can afford to lose in terms of time. For example, in my company, we perform hourly backups of our email servers, and we do this also for our shared drive. Why? Because we have determined that if a failure is going to occur, we only want to recreate work from the last 60 minutes. And so we pay for the systems in place to do those hourly backups. Now, in most large organizations, they perform backups every day. So they've decided to lose up to 24 hours of data, making their recovery point goal 24 hours. This again becomes a risk-tolerance decision based on your risk appetite. If you want to save money, you can decide to back up your systems only once a week on Sundays. If you do that, though, and you have a crash on Saturday, you just lost six days' worth of data. If your recovery point objective is seven days, then losing six days of data is perfectly fine. But if your recovery point objective is one day, then you can't rely on weekly backups. Instead, you need to do daily backups. Finally, we need to talk about the recovery service level, or RSL. This is a metric that's displayed as a percentage of how much computing power you need during a disaster. For example, let's say you work at a manufacturing plant and half of the facility gets destroyed by a fire. Well, you don't need 100% of your backend computer systems anymore, right? You're only going to need maybe 60% of them because you're still processing much less data than you were before, because half your factory doesn't work. So you would record your recovery service level as 60%, and that becomes your target to hit. Before you claim that you are fully recovered, remember that it is not done in a vacuum. So if there's a disaster, that's going to affect what your recovery objectives and levels become, since the business can change as a result of that disaster. All right, let's go back to our four steps of the business impact analysis and get into our third step. The third step is to identify resource requirements. During this step, we must document every resource required to support each asset at each criticality level. For example, if we determine that our e-commerce website is classified as critical, then we need to ensure the server remains up, including power, cooling, internet connection, credit card processing systems, and any other resources that support the function of that website. Our fourth and final step of the business impact analysis is for us to identify the recovery priorities. We do this by considering the criticality of each asset, the impact of the outage, and the terrible downtime, as well as any other resource constraints we may have, when we're identifying restoration priorities. These are generally classified as high, medium, and low. And it's important to note that these priorities do not provide the solution, only the priority. Instead, regaining these critical functions will be the responsibility of your DRP designers in the disaster recovery plan. So, in summary, when you conduct your business impact analysis, remember your four steps. First, identify the crucial processes and resources within your organization. Second, identify the impacts of an outage and estimate the downtime for those crucial processes. Third, identify your resource requirements. And fourth, identify the recovery priorities.

4. Privacy Impact Assessment (OBJ 4.4)

Lesson, we're going to discuss what a privacy impact assessment is and its importance. Now, a privacy impact assessment, or PIA, is a process that assists organisations in identifying and managing the privacy risks arising from new projects, initiatives, systems, processes, strategies, policies, business relationships, and other events. A privacy impact assessment is essentially a type of impact assessment that is conducted by an organization, and typically, a PIA is conducted by a government agency or a large corporation that has access to a vast amount of sensitive and private data about individuals in or flowing through their data processing systems. During the privacy impact assessment, the organisation is going to analyse its processes to determine how they might affect or compromise the privacy of people whose data is being held, collected, or processed by that organization. Essentially, a PIA is designed to accomplish three things. First, the PIA seeks to ensure conformance with applicable legal, regulatory, and policy requirements for privacy. Second, the PIA seeks to identify and evaluate the risk of privacy breaches or other incidents and effects. And third, the PIA seeks to identify appropriate privacy controls to mitigate unacceptable risks. At the end of the privacy impact assessment, a privacy impact report is going to be created. This report identifies and records the essential components of any proposed system that contains significant amounts of personal information and establishes how the privacy risks associated with that system can be managed. While most privacy impact assessments only consider technical systems, some will go beyond that. And they'll also consider the effects on other organisations and their stakeholders that would be affected in some way by the proposed project or process. Remember, it's important to understand what type of data is considered privacy information within your organization. Although legal definitions do vary, personal privacy information typically includes a person's name, age, telephone number, email address, sex, health information, and other sensitive and personally identifiable information. This data may be captured by an organisation from its employees, its clients, its customers, or its business associates. So when should you conduct a PIA? Well, a PIA should be conducted whenever the organisation possesses sensitive information or if the security control systems protecting that private or sensitive information are undergoing changes that could lead to privacy incidents. A privacy impact assessment is going to provide several benefits for your organization. First, it provides an early warning system to detect privacy problems and build safeguards into your systems to prevent privacy incidents. Second, it can provide evidence an organisation tried to prevent privacy risks so that you can reduce your liability, negative publicity, or damage to your reputation. Three, it can improve informed decision-making by senior leaders. Fourth, it can help the organisation gain the public's trust and confidence in terms of their handling of the privacy issues. And fifth, it can demonstrate to employees, contractors, customers, and others that the organisation takes privacy seriously. Now, to conduct a privacy impact assessment, you can follow a simple four-step process. First, initiate the project by defining the scope of the PIA second. Conduct a data flow analysis by mapping out the proposed business processes that will handle any privacy-sensitive information third. Conduct a privacy analysis by completing a privacy analysis. Questionnaires. Reviews. Interviews and discussions and fourth, publish a privacy impact assessment report to document the risks and implications as well as what the organization's plans are to mitigate those risks. Now, as you can see, there are a lot of benefits to doing a privacy impact analysis, and by performing one early, you can incorporate results into your business continuity planning and disaster recovery planning. As privacy breaches have been on the rise in recent years and are a major source of business continuity and incident response efforts.

5. Incident Response Plan (OBJ 4.4)

Eventually, a security incident is going to occur. It's just a matter of time. And when it does, how is your organisation going to respond? Well, the way we respond to an incident will determine just how much damage that incident can cause to our organisation and how much it's going to cost us in reputation, time, and money. Therefore, it's important for us to think about how we're going to respond before it's actually time for us to respond. And so it's a great idea to have an incident response plan in place. This plan should be formally written, well communicated across the organization, and most importantly, it needs to be followed during an incident. There are six steps to every good incident response: detection, response report, recovery, remediation, and review. Let's take a minute to look at each of these. First, we have detection. If you haven't detected the incident, then we can't start responding to it. The key to detection is using good detective controls, things like logging and auditing, as well as having a good array of host-based and network-based sensors across our information systems. Second, we have responses. The response to the incident should be appropriate for the type of incident. Our plan needs to address some typical responses, as well as how long each response should take us. For example, if we found evidence of data being exfiltrated from our network, we want to know how long it's going to take us to stop it immediately to prevent the loss of more critical data from our network. Third, we need to report. Again, our plan should address how quickly an incident must be reported up through management and to what level it needs to be reported to.For example, if I have a laptop that's lost, who needs to be notified and how quickly? If our credit card database was breached, who needs to be notified and how quickly? Again, this is going to vary depending on the incident at hand, but our plan should at least provide employees with an acceptable baseline that they should be striving for. Fourth, it's time to recover. Recovery is all about restoring the network to a functional state. If our email server was breached, how are we going to restore email services to all of our users? We might want to rebuild the mail server, or we might want to take the current one offline and restore a virtual server from the last known good backup. Again, this is going to depend on the incident, but the goal here is to restore functionality as quickly as possible so our users can get back to work during the recovery. Fifth, remediate. Remediation involves eliminating any traces of the incident or hack from our networks. Whereas recovery was focused on restoring services, remediation is about getting services back to a known good configuration and making sure we remove all traces of malware, misconfigurations, and other vulnerabilities that led to that incident. in the first place. Finally, six reviews after the incident has been resolved and after we've recovered our services and remediated the issues, we now have a little more time to discover exactly what led to this incident. Was it caused by an employee clicking on a spear phishing email? If so, we may need to institute better user training. Was it caused by malware that infected our server because the vulnerability management programme wasn't being performed properly because of an insufficient tool? If this is the case, we may need to obtain additional funds in order to purchase the appropriate tool and perform better. Regardless of the root cause of the incident, the review stage is important to understand exactly what happened with this issue and to share the lessons that we learned with other personnel inside the organization, as well as to prevent the same type of incident from occurring again. Now, one way we do that is to create an after-action report after each incident response is conducted. This After Action Report, or AAR, is also sometimes referred to as a Lessons Learned, or LR. Now, this report is going to provide insight into the specific incident and how to improve response processes in the future. One primary goal in information security is constant progress. Every day we aim to be better and more secure than we were yesterday, so we can stop more attacks. Remember that complacency has no place in the cybersecurity workforce, and lessons learned and after action reports are one of the methods of continuous improvement that we employ. After the initial crisis of the security incident is over, security professionals should stop and take some time to document exactly what happened. This will take the form of a Lesson'sLearn or After Action Report, depending on yourorganization's preferred terminology, whichever you call it. This document is going to contain the details, the root cause, and the solution we use for a given security incident. This detailed analysis of the incident also includes how the organisation can do better next time, including what worked well during our response, what didn't work well, and any proposed changes to the network to prevent this issue from happening again. Before drafting up this document, meetings and interviews are going to be conducted with those who are involved in the instant response. These fact-finding meetings should occur as close as possible to the end of the response. That way, the important details are not lost to the passage of time. While we have focused on our discussion hereon of lessons learned and after-action reports in the context of a security incident, they could also be conducted after any major organisational challenge, including major upgrades or installations on your network, major configuration changes, or other events. These reports will enable us to bring to light any issues that may arise during the execution of the incident response plan, allowing us to resolve them in the long run. There are a lot of benefits to creating these lessons learned and after-action reports. By documenting these things, it's going to provide us an opportunity to share that information across different Incident Response teams, as well as being used during the development of our future Incident Response plans, during updates, and for the generation of indicators of compromise and sensor refinement for monitoring and updating our change control process. Now, up to this point, I've spoken a lot about incidents, but we also have events. So what's the difference between incident and an event? Well, an event is simply a change in the state of security or operations. Events can be positive or negative. An incident, though, is a negative event that impacts an organization's security or operations. For example, if a user attempts to log into a system but enters the wrong password, this will get logged as an event. Now this is a single negative action, and we're going to log it, and that's pretty much all we have to do. But if the same user attempts to logon several times to another user's account and eventually guesses their password, that becomes a breach, and that is now an incident. When you have an incident, it needs to be investigated and resolved by your Cyber Security Incident Response Team, or CSERT. Now, this team is going to be made up of a manager, cybersecurity personnel, a representative from the legal counsel, and possibly somebody from public relations or human resources, depending on the type and severity of the incident. Now, there may be a standing order in your organization, while other organisations may decide to just stand one up and stand it down as needed for each individual incident response. Some organisations instead decide to outsource their incident response, relying on highly trained experts like the Microsoft Incident Response Team or Mert instead of fielding their own organization's CSER team. This way, they can handle technical breaches by using this outsourced team instead. Either way, the CISO should be the single point of contact for security issues within your organization. Now, the CSIR should be provided with the rules of engagement for conducting their investigation. This will give them the authority and scope to conduct the investigation, and it creates the left and right boundaries for the team. For example, what should they do if theydiscover an insider threat to the organization? Should they continue to investigate or should they stop and seek additional guidance from management? These are the types of things you're going to list in your rules of engagement. Another question answered by the rules of engagement is when they involve outside entities in the investigation. Can we bring in outside contractors? What about law enforcement? These are the types of things we have to address inside of our ROE, and we need to address them as an addendum to our organization's Incident Response Plan. Now, let's take a few moments and talk about the different roles and responsibilities that exist within the Cybersecurity Incident Response Team. These roles include the incident responsemanager, security analyst, triage analyst, forensicanalyst, threat researchers, a representative formanagement, human resources, legal counsel, publicrelations and technical subject matter experts. First, we have the incident response manager, who is also known as the team lead. This person is going to oversee and prioritise actions during the detection, analysis, and containment of an incident. This is a position I have personally filled many, many times, and I can tell you it's a difficult one that requires a lot of good soft skills in addition to those traditional, in-depth technical skills that some other positions are going to require. This is because your Instant Response Manager or Team Lead is going to be responsible for conveying information about the response and recovery efforts up to the executives and management within your organization. Oftentimes, they can also be thrust into the role of being the public face of the company to the media or law enforcement during that incident response. Your second position with us is known as a security analyst. Your team needs to have one or more of these security analysts assigned in order to work directly on the affected network and to play detective in order to determine exactly what happened up to this point. Security analysts are now assigned to one of two categories, though some analysts may work in both categories concurrently when dealing with minor incidents. The first of these is known as a Triage Analyst. A "triage" analyst is a type of cyber security analyst that's assigned to work on the network during the incident response and filter out the false positives by properly configuring intrusion detection and protection systems, as well as performing ongoing monitoring analysis to detect any new or potential intrusions during the incident response. The other type of security analyst we use is what's known as a forensic analyst. Now, a forensic analyst is going to be more focused on the detective work and try to piece together exactly what has already happened on the network. Now they're going to focus on recovering key artefacts and evidence from the network and then use these to build a timeline of the different events that led up to the incident itself, and that way we can better understand what happened. But far beyond that, you also want to have a threat researcher who's going to be another key member of your team. These threat researchers are going to be able to complement your analysts by providing threat intelligence and overall context during your Instant Response. These specialists work to always remain up to date on the current threats that you're facing as an organisation as well as within your specific industry, as well as keeping up to date with previous incidents that may have occurred. I like to think of these people as a cross between a futurist in terms of predicting what the bad guys will do next and a historian in terms of knowing all the bad things the bad guys have done in the past. Threat researchers can help us build a better security and defence posture because they're going to be able to help us stay one step ahead of the bad guys who may have already broken into our network, and we're trying to get them back out. Now, in addition to all the critical roles I just talked about, we also want to expand our team with additional cross-functional support. This can include people from management or the executive team, someone from human resources if you're dealing with an employee insider threat, or an attorney or lawyer in the case that the company wants to take legal action against a perpetrator or attacker. Sometimes you might even have somebody from public relations, because you may have media interests in this event as well. Now, in addition to all those people, you may have to pull in technical experts on specific systems—people like system administrators, network administrators, or database administrators—to help you get back to normal operations as part of that response. All of these are considered cross-functional support because they're coming from outside the Instant Response team itself and from across the entire organization. So when you're creating your incident response plan, remember that it's important to plan not just for the technical response, but also the business and public relations response as well. The CSIR team should be cross-functional, handling the incident from start to finish while coordinating those actions across the technical and business portions of your organization.

ExamCollection provides the complete prep materials in vce files format which include CompTIA CASP certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to CompTIA CASP certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.