Pass CompTIA CASP Certification Exams in First Attempt Easily

CompTIA CASP Certification Practice Test Questions, CompTIA CASP Exam Practice Test Questions

Want to prepare by using CompTIA CASP certification exam practice test questions efficiently. 100% actual CompTIA CASP practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. CompTIA CASP exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with CompTIA CASP certification practice test questions and answers with Exam-Labs VCE files.

Data Considerations (Domain 4)

8. Data Sovereignty (OBJ. 4.3)

Data sovereignty is the principle that countries and states may impose individual requirements on data being collected or being stored within their jurisdiction. Essentially, there are different rules in different areas of the world. So if you're in Europe, you have one set of rules. If you're in America, you have another set of rules. If you're in some other country, you have a third set of rules. And so, it's important to understand what those rules are and where you are. So how do these rules affect us as people on the Internet? Well, all that data has to be stored someplace, right? And so, some states and some nations may respect our privacy more or less than others. And based on that, you can determine where you want to host your servers for your organization. For example, let's say I choose to host my servers in the United States of America. Now, because of the location of my servers, I now have to follow American laws for them and the data they process. But if I decide to move to some countries in Africa or the Middle East or Asia, I now have to follow their rules. Those rules may not be as strict as the American rules. Or if I go to Europe, they have stricter rules than America does, especially in regards to the privacy of the end users of my systems. So, for example, let's say I moved my server to Germany. Now I'm in the domain of the European Union, and I fall under GDPR's provisions. If I'm dealing with GDPR, those protections are actually going to be extended to any European Union citizen while they're within Europe or within the European Economic Area or the EU. Now, technically, if you're a European Union citizen and you start travelling to a different area, you have now affected your data sovereignty because you're no longer protected by GDPR when you're, say, inside of Thailand, because you're now following the Thailand rules, not the European Union rules. And so if you're dealing with a local Thai company, they don't have to deal with GDPR regulations even though you're a European Union citizen. And this is why things get really complicated. That protection only applies to you while you're inside the walls of the European Union. It doesn't protect you once you move outside. Similarly, as an American company, I don't have to follow the rules for GDPR unless I'm actively targeting European Union citizens in my advertising of my products. Now, if I simply set up a website in the United States and offered my products in US dollars, and you, as an EU citizen, decided to go to my website and buy from me, there's really no GDPR protection for your privacy because you technically left the EU virtually to come by my store. I didn't target you directly as a European Union citizen. Now, this is the reason that we have to think about data sovereignty, because it affects you personally as you travel, but it also affects companies as we're deciding where to host our data, because the location of our servers will help determine data sovereignty. Now, before I end this lesson, I want to caveat it with this statement. The rules around data sovereignty are changing rapidly every single day for the exam. If you know the concepts I covered in this lesson, you're going to be fine with any questions about data sovereignty questions.But I am not a lawyer. And so if you're conducting international business and you need to determine the true data sovereignty of your data and how it's going to affect your business operations, please consult a lawyer. There are lots of different international lawsuits currently ongoing as I film this video, and they're trying to determine exactly how data sovereignty should be applied across the world, and the outcomes of those cases may change some of the things I said in this video. But for the exam, you're still going to be right if you use the information from this lesson to answer those test questions.

Risk Management (Domain 4)

1. Risk Management (OBJ 4.1)

In this section of the course, we're going to cover the concept surrounding risk management that you need to consider when you're trying to protect your organization's data. Our focus in this section is going to be on Objective 4.1. It states that, given a set of requirements, apply the appropriate risk strategies. Now, as we move through this section, we're going to start out by providing an overview of the different risk strategies that we can utilise when we're dealing with risk. Then we're going to dive into the risk management lifecycle, covering how we identify, assess, control, and review risks both internal and external to our organizations. After that, we're going to talk about different types of risk, such as inherent risk, residual risk, and risk exceptions. Next, we're going to cover the different ways to handle risk and to track risk, including transferring risk, accepting risk, avoiding risk, and mitigating risk, as well as the use of a risk register, key performance indicators, and key risk indicators. Finally, we're going to discuss the concepts surrounding risk assessments, including the likelihood of a risk occurring, the impact if it does occur, calculating risk using the exposure factors, asset value, single loss expectancy, the annualised rate of occurrence, the annualised loss expectancy, and much more. Now, this is going to be a really busy section,but it is a really important one, so you needto take the time to go through it. This is because risk management is at the core of your job as an information security professional. Remember, being able to understand the risks, put mitigations in place against those risks, and measure how we're really going to be spending money to prevent a risk from materialising is truly critical to the success of your organizations.

2. Risk Strategies (OBJ. 4.1)

In this lesson, we're going to focus on risk management strategies, both in theory and in their application to our networks and cybersecurity within the real world. So why should we care about risk management? Well, as a leader and a manager of IT networks, your job is essentially to manage risk for your enterprise. Every decision you make during the day is going to involve the acceptance, transference, mitigation, or avoidance of risk within your IT systems. So we need to cover all the facets of risk management, including risk assessments, risk measurement, risk handling, risk tracking, and the entire risk management lifecycle, as well as many other risk considerations. Now, I'm excited to share with you not only the theory and the textbook answers surrounding risk management, but also some real-world experiences that will help you understand the importance of risk management in your IT systems. But before we dive deep into those concepts of risk management, we first have to start with two basic questions What is risk? And where does risk exist? Now, risk, at its core, is the probability that a threat will be realized. Risk is a continual balancing act between vulnerability and threat. Now, in future lessons, we're going to discuss how we balance these things against each other in order to manage that risk. But for now, just remember that a vulnerability and a threat are at odds here. And when they come together and match up, we have a risk that can be exploited. Now, as cybersecurity professionals, our job is to minimise vulnerabilities. Vulnerabilities are any weakness in a system's design or implementation. We are granting control over vulnerabilities because they are caused by internal factors such as software bugs, incorrectly configured software, improperly protected network devices, a lack of physical security, and other similar issues. Vulnerabilities are within our control, or at least within our organization's control, for us to solve these problems. Now, whether we choose to address these vulnerabilities, though, is a decision in risk management. Conversely, as cybersecurity professionals, we cannot fully control threats but instead attempt to minimise or mitigate them. This is because a threat is anything that could cause harm, loss, damage, or compromise to our information technology systems. These threats come from external sources like natural disasters, cyberattacks, data integrity breaches, disclosure of confidential information, and many, many other issues that can arise during our daily operations. That brings us to our second question: Where does risk exist? Now, risk exists at the intersection between threats and vulnerabilities. And this is a key point to understand. If you have a threat, but there's no matching vulnerability to it, then you have no risk. The same holds true: If you have a vulnerability but there's no threat against it, there's also no risk. Let's consider the example of trying to get to work in the morning on time. Now, your alarm clock goes off just after 6:00 p.m. and you hop out of bed. You get dressed, you eat your breakfast, and now you have to get from your house to your office. But there are vulnerabilities and threats all around you that could cause a bad outcome, such as you arriving late for work. Now this is an everyday example of real-world risk management that you do without even realising it. Let's consider a few possible vulnerabilities in this scenario. One is that you may have forgotten to put gas in your car the day before. So we're going to call this the lack of preparation." Another reason might be that you forgot it was your day to drop off the kids at school before you drove to work. So this is something that's a scheduling vulnerability. There are lots of different possible vulnerabilities that could harm your plan to get to work on time. But you can control these vulnerabilities because they're all internal factors. Now there are several other threats to you arriving to work on time that are totally outside of your control. Or if there's a major traffic jam this morning, that would certainly cause a delay to your commute, and you're going to arrive late to work, which is a realisation of that threat. Another threat could be a natural disaster. Let's say there was an earthquake, which caused the road between your home and your office to be completely destroyed. Now I know that's a little melodramatic, but you're getting the idea here, right? You can't stop an earthquake. It's going to happen when the Earth wants it to happen. This is an external factor, and it's a threat to your arriving to work on time if it were to actually happen and materialize. So now that we have several threats and several vulnerabilities that we have, we have to think about what we can do about them. Well, if we're worried about being late for work, one thing we could do is wake up earlier. Instead of waking up at six, we'll wake up at five, and that gives us an extra hour of time. That way, even if an external threat like a traffic jam or an earthquake destroyed one of the roads to work, you could still have time to find an alternate route and get to your office on time. This is what is referred to as risk management. It's finding ways to minimise the likelihood of a certain outcome occurring and achieving the outcomes that you really want to achieve. In the case of information technology and cybersecurity, we want to achieve objectives like providing service continuity for our end users or maintaining the overall security of our IT systems.

3. Risk Management Lifecycle (OBJ. 4.1)

Lesson: We're going to talk about the risk management lifecycle. Now, this life cycle is how we deal with risk every day in the real world. as we identify risk, assess risk, control risk, and review risk. As we conduct enterprise risk management, we need to use a comprehensive process of evaluating, measuring, and mitigating the many different risks that occur within an organization. This is important because in all of our organizations, we are going to face risk. There are risks to our systems, there are risks from attackers, and there is risk from the environment. And we're going to talk all about this throughout our risk management journey. So what exactly is risk management and why is it adopted by organizations? Well, quite simply put, risk management helps us see all the different risks that are out there, and then we put controls in place to help bring the level of risk down to an acceptable level. As an organization, we adopt risk management to ensure our confidential data stays, well, confidential. and we want to make sure that all of our customer data and all of our corporate data doesn't get into the hands of unauthorised parties. Now, we also want to make sure that we avoid financial losses. This can occur by people attacking our systems and damaging our resources, or it can happen by attacking our data and having data leaks. All of these are things that can cost us money. And so by doing proper risk management, we can minimise that and avoid these kinds of financial losses. Risk management can also help us to avoid legal troubles. If we have our systems hacked, that data could be breached. And if it is breached, we can have legal consequences for that, such as civil lawsuits for not properly protecting that data. So we want to make sure we're avoiding any legal issues by doing risk management properly. We also want to ensure that we maintain a positive brand image. This is important because even though you might be protected from the legal ramifications of a breach or you're able to mitigate those costs, you still have your brand being tarnished here, and that is something that you can't get back very easily. They say it takes decades to build a brand, but only moments to destroy it. By performing risk management activities, we can ensure that we're able to establish trust and mitigate our liability. All of this is involved in your business relationships between you and other businesses as well as between you and your clients. Finally, we need to perform risk management in order to meet our stakeholders' objectives. Now, in a business, we have lots of different stakeholders. This includes our shareholders in the company executives, in the company managers and technicians, and even in our customers. All of these stakeholders have objectives, and if we're not doing proper risk management, we can't meet their objectives and get them what they need. Now, just for a moment, I want to take a sidebar and talk a little bit more about these stakeholders because this is a really critical concept. You, as a cybersecurity professional, are not going to be making all the risk decisions. You're just not going to be doing that. That's not your job. Instead, these decisions have to be made by different business stakeholders, by a different project management team, by the customer service team, or whoever is relevant in that situation. Now, as a cybersecurity professional, you're in a unique position to understand all the different technical risks that are going to exist out there. And so it is your job and your duty to take those, make them easier to understand, and bring them to the attention of the right key decision makers.And that's why it's important for you to understand risk management and the risk management process because you're going to have to plug into that process to be able to get your points across and be able to get the right controls in place to mitigate these risks. All right, now let's talk about the risk management lifecycle. The first step in the risk management lifecycle is to identify the risk. Risk identification considers all types of risks or uncertainty that may impact our ability to achieve our set of objectives. Essentially, the identification process is a form of brainstorming where all the possible risks are going to be listed out. Once we have this list, we'll move into a more formal process to assess, control, and review these risks. To do that, we're going to use the Go-To Guide for Risk Management. This is known as "managing information security risk" and it's a publication put out by NIST, the National Institute of Standards and Technology. This publication is NIST Special Publication 839. If you want to look it up and download a copy for yourself, just go to Google and type in NIST SP 839. Now, this publication is an excellent starting point for applying a process for risk identification and assessment. Now, when you look inside this guide, you're going to see a diagram that contains a few bubbles that represent the components of information security risk management. These bubbles assess, respond, and monitor according to the exam objectives that CompTIA uses. They refer to these as assess, control, and review, but they really mean the same thing. Now notice there are three corners here in this triangle, and in between all these, you see the word frame. Now in between all four of these bubbles, we have information and communication flows going up and down, left and right, because all these different pieces of risk management and this framework are going to talk to each other, and so we can get information and pass it between all the different areas. Now let's take a look at each of these four dots and what they represent. First. We have frames. Frame represents our true goal in risk management, which is to establish a strategic risk management framework that's supported by decision makers, key stakeholders, and others at the top tier of the organization. Now, when we talk about Frame, our goalhere is to create this framework that everythingelse is going to reside around. As a cybersecurity professional, you're not going to be the one creating the frame portion. Instead, you're going to be working a lotmore in the Assess, Respond, and Monitor areas. But Frame is going to dictate all three of those because it sets out the strategic framework for your organization. So now that we have a framework to use and we've identified a long list of possible risks, it's time to assess those risks. Now, as a cybersecurity professional, it's going to be your job to identify and prioritise the different business processes and workflows in the organization. When you start looking at this from the asset perspective, this is where you're going to be doing system assessments to determine which of these assets are there and which assets support the workflows inside the business. As you start to identify that, you're going to be able to identify different risks to each of those systems. Maybe there's software that hasn't been patched that would be a risk. Maybe there's an attacker who's going after a particular type of system, and your organisation operates those types of systems. Well, that's also a risk. These are the things you have to assess to understand what the current risk level is. Next. We have responded Now, Respond is called Control by CompTIA in the exam objectives, but in the publication guide, it is known as Respond. The reason for this, which is called "responder control," is because we are now focused on placing mitigations in place to lower the risks that we just assessed. So these controls can be classified into seven different categories. Things like people, process, technology, and protection help detect, respond, and restore People, process, and technology are three areas that can be used to mitigate risk by implementing proper controls. People are focused on controls and mitigations. They're going to be establishing a cultural framework that focuses on reducing risk and increasing security. Processes are all about rules, regulations, and oversight. Technology involves putting the right systems in place to automate processes and make them smarter and more effective. Additionally, we have protect; detect; respawn; and restore. These four categories also overlap with the people, process, and technology categories. And there are three categories that are going to be implemented within Protect, Detect, Respond, and Restore. Now, Protect is focused on providing appropriate safeguards to ensure delivery of critical infrastructure services. Detect is going to be focused on defining the appropriate activities to identify the occurrence of an event. Respond is concerned with carrying out the necessary actions in response to a detected incident. Recover is focused on identifying the appropriate activities to maintain plans for resilience and restore any capabilities or services that were impaired due to an incident. As I said, these four categories are often broken down into the specific types of mitigations that are being used. For example, if you're doing something in managerial control, you're focused on people. Operational controls are focused on process. Technical controls are focused on technology. Now, as a cybersecurity professional, you're never going to be able to get the risk down to zero, but we can mitigate it down to what is considered an unacceptable risk to the organisation based on its risk tolerance. The final area we need to consider is monitoring, or as CompTIA calls it, review. When we monitor or review, we're going to evaluate the effectiveness of the risk response measures and identify changes that could affect risk management and those processes we've put in place. Because we've already identified the risk, the last thing we need to do is monitor and review. We assess the severity of that risk. We responded to that risk by implementing controls, and then we're going to monitor to make sure those controls are acting effectively and giving us the risk mitigation results that we intended to get. The final thing I want to talk about briefly is how we measure risk. Now, a formal risk analysis is conducted to make a risk determination. During this analysis, there are two different ways that we measure risk. We can do this qualitatively or quantitatively. Qualitative risk analysis uses intuition, experience, and other best practises to assign nonnumeric values to a given risk value. These non-numeric values could be below, medium, high, or critical. Or you could use another categorization system if you desire. The best practises include techniques to measure risk such as brainstorming sessions, focus groups, surveys, interviews, and estimation of the likelihood of events occurring using the Delphi method. In a qualitative assessment, things are going to be measured more based on a feeling or opinion about how risky something really is. We might categorise these as high, medium, or low. Like I said before, in this case of qualitative methods, we aren't really looking for an exact dollar amount or a metric, but instead we're just trying to get an understanding of how risky something is in relation to other things. When conducting a qualitative risk analysis, it is critical that the team has the necessary experience and knowledge of the various threats being analyzed. Because it is highly subjective in nature, the analysts must use their experience to rank the threats based on proposed impact, severity, lost potential, and likelihood of occurrence. The biggest downside with using qualitative risk analysis is that dollar values are not provided, and this hinders cost-benefit analysis and future budget forecasting. Now, on the other hand, you can use quantitative risk analysis, which uses numeric values and monetary values for all parts of the analysis. This includes numerically assigning values to the value of the assets, the threat frequency, the severity of vulnerabilities, and the impact of realisation of a given threat. Quantitative risk analysis eliminates much of the guesswork and estimation from risk analysis by converting it into a large math problem. Instead, we have equations that we use to determine the total and residual risk, and it can provide us with a cost directly associated with each of those risks, which the accountants really love. All right, let me give you a quick example of using risk determination in the real world. Now, without having to calculate the cost of a car accident, I still know how risky it is for me to get in the car and drive to work every day. It's a relatively low risk. I've been driving to work now for 20 to 25 years, and I've never gotten into an accident on my way to work, so I find that to be a low-risk event for me. This is a qualitative measurement, though, because I didn't do any kind of math problems to figure it out. I just had this feeling that it was a low level of risk. Therefore, it's not a quantitative measurement. Now, if instead I needed to calculate exactly how much it would cost if I did get into an accident on my way to work, I could calculate that down to the exact dollars and cents using a math problem and a calculation for it. If I were running an insurance company, for example, I'd need to have a quantitative risk measurement assigned for each person that I'm insuring because I need to properly charge my customers. Now, as the driver of the car, I make that decision every morning to get in and drive to work. That is something I can do qualitatively. I don't need to know that it's going to be $99.58 if I get into an accident this year. Instead, I just need to know if it's a low risk, a medium risk, or a high risk that's sufficient enough for me to make the decision of whether or not to get behind the wheel. In the real world, most risk determinations and risk analyses will use a hybrid approach. This is because there's often not enough data to accurately use only a quantitative method and be able to do these math problems. So you have to combine it with some qualitative analysis. Furthermore, there will always be some level of subjectivity in the data, so most analyses will be a combination of quantitative and qualitative approaches. We'll talk more about these concepts, along with how you can actually calculate the quantitative risk, as we go through the rest of this course.

4. Risk Types (OBJ. 4.1)

To properly manage risk, we must categorise that risk. One of the ways we categorise risk is by identifying the different risk types that exist, such as inherent, residual, and exceptions. Inherent risk occurs when a risk is identified but no mitigating factors have been identified and applied. For example, if I'm going to drive to work, there's an inherent risk that I could get into a car accident and be injured. Now, in everything we do in the real world, there is an inherent risk there. If I'm going to install a software patch on my domain controller, there's a risk that that patch might be faulty, and it can prevent the domain controller from working as designed. If my office is in a location in the world that has hurricanes, like Puerto Rico, then there's an inherent risk that our officers can lose power for a few days if a hurricane hits the island. Essentially, inherent risk is the level of risk in place prior to us taking any mitigating actions to reduce the impact or the likelihood that that risk could be realized. If you have a computer that is connected to the Internet, there is an inherent risk that it could be attacked. For example, if an advanced persistent threat wants to target your network, it's only going to be a matter of time and resources before they're going to be successful in exploiting it. This doesn't mean that we should give up on applying controls to make our organisation more secure. Instead, we must accept that there will always be some inherent risk in our operations that cyber attackers will attempt to exploit in order to exploit our systems. Now, the second type of risk we have is known as residual risk. Residual risk occurs when we calculate the risk after we apply our mitigations and our security controls. So going back to the advanced persistent threat example, we may decide to create an operational policy to secure our network as we go through.And we're going to ensure that every system is fully patched and compliant, and we'll make them as secure as we possibly can. But there is still a residual risk there that a zero-day vulnerability could be discovered by an advanced persistent threat, and they're going to be able to exploit that vulnerability to gain access to your networks. That residual risk, that amount of leftover after we've applied all of our controls, is important to understand when you're conducting your risk management. The final type of risk we have is one known as a risk exception. Now, a risk exception is any risk that is created due to an exception being granted or a failure to comply with corporate policy. Essentially, think of it this way. Your organisation implemented a security policy that says all users must change their passwords every 90 days because this helps to prevent brute force attacks. Well, your CEO decides they don't want to follow this policy because they hate having to remember new passwords. Therefore, they had the IT department put an exception on their user account that lets them change their password only once a year instead of every 90 days. This exception to policy now creates a risk to the organisation, and this risk is known as a risk exception. In general, you should avoid allowing risk exceptions to occur in your organization. But if you do need to use one, you should have a process in place to track these exceptions. You need to be able to measure the potential impact of allowing these exceptions, and you need to implement compensating controls to help mitigate these additional risks. Additionally, an exception shouldn't become a way of life in your organization. Instead, they should be issued for a short period of time while waiting for a longterm solution or an overall policy change. Bye

5. Risk Handling (OBJ. 4.1)

We've talked a lot about risk up to this point, but now let's talk about the basic strategies of how we can conduct risk handling. In every risk management program, there are essentially only four things you can do with risk You can avoid risk, you can transfer risk, you can mitigate risk, and you can accept risk. Risk avoidance is a strategy that involves stopping a risky activity or choosing a less risky alternative. But how does that really apply to our IT networks? Well, let's assume that we have a network comprised of 100 computers, but only 15 of these are running Windows Seven. Now, if you know anything about end-of-life and unsupported software, you know that Windows 7 stopped receiving official support from Microsoft back in January of 2020. To avoid the risk of running unsupported software like Windows 7, we have two choices: we can take those computers offline, meaning we stopped that risky activity, or we can upgrade the computers to Windows 10, a newer and still supported operating system, and therefore we are choosing a less risky alternative. When we talk about risk avoidance, we're basically talking about eliminating the hazards, activities, and exposures that could negatively affect us. For example, in my own company, we ended up choosing risk avoidance for a CompTIA exam voucher sale program. We started to see a sharp increase in fraud from people buying our exam vouchers using stolen credit cards. In just one month, one out of every two vouchers we sold ended up being disputed as fraud by the victim's credit card company. This means my company lost not just the voucher but also the purchase price we collected from that stolen credit card and a dispute fee. So we made the business decision to stop selling exam vouchers in certain geographies in certain countries because the rate of fraud was simply too high in those areas and we wanted to avoid that risk. Now, the second thing we can do with risk is to transfer it. Risk transfer is a strategy that passes the risk on to a third party, most commonly an insurance company. A great example of this is that if our organisation was worried about the risk of our server room being destroyed by a flood, we could go out and purchase insurance. This way, we're transferring the risk of losing all those assets to that third-party insurer. Now, if a flood actually happens, they're going to write us a big check to replace all our equipment and pay for the data recovery team to come out and restore our data and services. The third thing you can do with risk is to mitigate it. This is probably the most popular thing we do with risk in the real world. Risk mitigation is a strategy that seeks to minimise the risk to an acceptable level that an organisation is willing to accept. Now, for example, if we're running a server that has been identified to have five critical vulnerabilities, two high vulnerabilities, four medium vulnerabilities, and 17 low vulnerabilities Our risk management programme may have a policy that states any server with critical vulnerabilities needs to be taken offline. But if we patch those five critical vulnerabilities, they might be willing to accept the residual risk of high, medium, and low vulnerabilities to allow us to keep that server connected because the overall risk is now mitigated down to what is considered an acceptable level. Let's go back to my earlier example of fraud that occurred with our gift voucher programme and take a look at that as an example. Now, there are some countries where we did experience fraud, but it was at a lower level. For example, our United States Voucher programme experiences fraud on a regular basis, but we've put into place certain mitigations to block some of that fraud from occurring. And we've gotten it down to a low enough level of fraud that we're comfortable continuing to offer the discounted vouchers to our students without losing money overall. Therefore, we made the risk decision to accept the residual risk after we applied those risk mitigations, and we continue to sell vouchers in certain areas of the world. The final thing we can do with risk is to accept it. Risk acceptance is the strategy that seeks to accept the current level of risk and the cost associated with that risk if it were realized. In general, this is the correct strategy if the asset is very low cost or the organization's impact is considered low. For example, we may choose to transfer the risk of a server being damaged because it costs about $10,000 or more to buy a new server, but we would simply choose to accept the risk of a laptop being damaged because we could replace that for three or $400. So how are you going to determine which risk handling action you need to take or when you've applied enough mitigations to accept the residual risk? Well, as in most things in life, it's all about how much risk you're willing to accept. Now, every organisation is unique, and they have to be willing to accept a different amount of risk based on their business and their operations. There's actually a term for this. It's known as the "risk appetite." The risk appetite is the amount of risk that an organisation is willing to accept in pursuit of its objectives before action is deemed necessary to reduce that risk. Often the term "risk appetite" is also risk attitude" or "risk tolerance." For the CasPlus exam, these three terms are used interchangeably, and you may find that this occurs in the real world as well. So if you see risk appetite, risk attitude, or risk tolerance, we're talking about the same thing. In some organizations, though, they make a distinction between risk appetite and risk tolerance. When people talk about this, they're talking about risk appetite and referring to the general level of risk that the organisation is willing to accept. Conversely, when they talk about risk tolerance in these organizations, they're referring to a specific maximum risk the organisation is willing to take regarding a specific identified risk. So when we're thinking about risk appetite, it's an overall thing. Risk tolerance is a specific thing. All right, let's use a real-world example here. I have two cars at my house. One is a Tesla Model Y, and the other is a 2011 Mini Cooper. Now, the Tesla is obviously much more expensive, and it's also much more expensive to fix if I get into an accident. So when it came time to buy auto insurance for my household, I had to make a risky decision based on my risk appetite. Overall, I'm not completely risk-averse, but I'm also not risk seeking.So I don't have a low-risk appetite, but I also don't have a high one either. I'm somewhere right in the middle. Let's call me a three out of five on my risk meter. So now when my insurance company called and we started going over the coverage and the prices, I had to figure out what I wanted to buy. We talked about the cost to insure each of these two vehicles. And when it came to the Tesla, I decided to get full coverage because the risk was too high for me to feel comfortable paying for it myself if I got into an accident and destroyed the car. But when it came time to ensure that Mini Cooper, I looked at the cost and weighed it against the risk. If I bought full coverage, they were going to charge me $2,500 per year. But if I bought just coverage to cover somebody else's car if I got into an accident, they were willing to do that for just $300 a year, about half the price. So basically, I would be paying $100 more per month to get full coverage on my Mini. And so I did the math in my head, and I decided that if I only had one accident while driving in the last 20 years, the risk seemed low enough for me to accept this risk. So essentially, for that car, my risk tolerance was higher than my risk tolerance for the Tesla. And so you can see my overall attitude toward or appetite for risk was medium, but I had different levels of risk tolerance for each individual asset, one for the Tesla and one for the Mini. So, as you consider your organization, keep in mind that a higher-level decision maker will have established an overall risk appetite for the organization. Then you may find that there are different risk levels in different product lines, different departments, or even with certain servers within a department or division. This risk appetite and risk tolerance will affect the decisions that you're going to make in regards to using risk avoidance, risk transfer, risk mitigation, or risk acceptance. So as you decide which of these four you're going to choose in your risk handling, remember, there's always going to be a trade-off that has to be made. Increasing the level of security increases the project's cost. Also, if you add more security, you often reduce the usability of the system. And this is the neverending tradeoff that occurs between usability and security. For example, I worked for one organisation that required users to access their work email only from a dedicated smartphone that the organisation issued to them. But this is a huge expense, so not everybody could access their email after hours because only 5% to 10% of the people actually got one of these devices so they could have this dedicated smartphone. This was a security decision, but it led to the service being much less usable because 90% of the people—or 95% of people—couldn't access their work after hours. So the bosses would be, frankly, sending out emails at 8:00 p.m. when something went wrong, and then they were surprised when none of the workers responded. And the reason was that the workers didn't have a phone, but the bosses did. And so the boss would say, "I sent this email and I marked it urgent." And the person says, "That doesn't matter because you made a system that was so secure I can't get it unless I drive into work and check my email." So that's the idea here. When we talk about usability versus security, you have to keep this in mind when you're making your security decisions and your architecture decisions. Remember, we don't do it just for the sake of it. We do it in order to empower the business and its users to do the real work of the company. If you work for CocaCola, for instance, your job is to keep the systems up and running securely so the rest of the employees can make and sell more sugar water. Keep this in mind when you're determining the actions you want to take during risk handling, and balance that against your organization's risk appetite as well.

6. Risk Tracking (OBJ. 4.1)

Risk identification and risk assessment are important, but it is really risk tracking and monitoring that lie at the heart of risk management. Risk tracking, also known as risk monitoring, is the activity of systematically tracking and evaluating the performance of risk mitigation actions against the established metrics throughout the lifecycle of an identified risk. To help track your overall risk, you need to use a risk register. Now, a risk register is a tool that's used to identify all the potential risks inside a system or organization. The risk register should include each identified risk, a description of that risk, the level of that risk, the likelihood of that risk, the owner of that risk, the mitigation measures implemented against that risk, and the residual level of that risk. For example, let's say I have identified that a data leak is one possible risk. I could describe it as a possibility that the release of sensitive or protected data to an untrusted environment will occur. Now, the level of risk for this could be set qualitatively as high, or we could calculate it quantitatively and come up with a figure like $500,000 in cleanup costs if this risk is realized. As for the likelihood, we're going to place this at medium because data leaks occur quite often in the ecommerce world.

As for the owner of that risk, this is goingto be the person who is responsible for managing thethreats and vulnerabilities that might exploit this risk. So I might assign this one to my chief operating officer because she's in charge of all of my IT team and all of our student success team. The IT team would be really useful in implementing any technical mitigations. And the Student Success Team, which is my largest team, is going to be the ones who are most likely the ones causing an unintentional data leak because they deal with the sensitive data on the human side of our business. Now, since both of these departments work for my CLO, I'm going to make her my risk owner for this particular risk. Next, we're going to consider the mitigation measures that we've applied or will apply to this risk. For example, maybe we're going to install a new data loss prevention SaaS product that's going to monitor and prevent data leaks for us. Also, we may have our IT team ensure that the server is always patched against known vulnerabilities within three days of release. After that, we're going to reassess our risk and determine its residual level. In this case, I'm going to classify it as a low-level risk because we implemented the DLP system and the server patching that we just implemented. So we went from an inherent risk of medium to a residual risk of low after we applied those mitigations. Now, you're going to need to do this for every risk in your organization, and you're going to spend more time and provide more details for the higher and more common risks. For example, I might say that an alien invasion or a zombie apocalypse is a possible risk, but it's highly unlikely. So I'm going to spend very little time, money, or effort planning against those risks. Instead, I'll simply accept them based on my personal beliefs and my risk tolerance. In addition to creating a risk register, your organisation may create a risk dashboard that's made up of KPIs and Kris. Now, a KPI is a key performance indicator. KPIs are used to gauge and measure different things within your organization. For example, you may measure your scalability, reliability, or availability, and all of these will inform your overall risk posture. Scalability is the ability of a system to handle an increase in demand without impacting the application's performance or availability.

For example, in my company, we built our entire architecture on serverless technology. So we are highly scalable, and we are not at risk of a self-imposed denial of service because we had too many students in our course all at the same time. Now, this is because of our highly scalable cloud architecture. We know that we are scalable and have a high scalability score. In contrast, reliability is the probability that a system will meet certain performance standards and produce the correct output at a specific time. So here we're going to be measuring if the system will perform as it should for 30 days without any kind of failure. The higher your reliability, the longer the period of time between a failure.Availability is going to be the percentage of time that the infrastructure, system, or solution is operational under normal circumstances. So to calculate availability, we simply take the total uptime and divide by the total lapse time during a specified period. For example, if my company's website was down for 6 seconds over the last week, that would be enough time for an availability of 99.99%. This is known as the five nines of availability. Yes, only 6 seconds per week of downtime andthat is the gold standard inside of availability. That means you only get five minutes per year of downtime if you're going to go for five nights. Now, as you can see, KPIs tend to be the metrics and numbers, and things become easily measured when you're using KPIs. Now, Kris, on the other hand, are key risk indicators, and they're used to measure risk instead of system performance. Kris are going to help you determine how much risk the organisation is exposed to or how risky a particular activity may be. Often companies will use KPIs and Kris interchangeably, but in reality, Kris is supported by the underlying KPIs. For example, the risk of my web server being down may be a Kri, but the actual scalability metric, reliability metric, and availability metrics that help calculate the Kris are all KPIs themselves. Remember, key performance indicators help us measure your business's performance. but key risk indicators help us quantify risk.

7. Risk Assessment (OBJ. 4.1)

Lesson: We're going to talk about risk assessment. Now, a risk assessment is a tool that is used during risk management to identify vulnerabilities and threats, to assess their impact, and to determine what controls to utilize. This is also known as risk analysis. There are four goals to risk assessment: First, classify assets based on their monetary value. Second, identify vulnerabilities and threats. Third, determine the threat's probability and impact. And fourth, balance the threat's impact with the cost of the countermeasures. Now, organizations, managers, and the risk analysis team are going to determine which assets and threats are going to be included prior to starting out with a risk assessment or risk analysis. Based on this selection, the project is then scoped to the proper size. The list of assets and threats should be provided to management for their approval. Who is then going to finalise the budget for conducting the risk assessment project? Risk assessments should be conducted prior to any mergers, acquisitions, or deployment of a new technology. These risk assessments can identify areas that could pose a problem during the implementation of these types of changes to an organisation or its systems. Remember, risk assessments can only be successful when they're supported by senior management. It is the management's role to define the purpose and scope of the analysis as well as to apply the appropriate level of resources such as time, money, and personnel to ensure the successful completion of the analysis. All right, let's dive into how a risk assessment calculation is actually performed. First, we're going to consider the likelihood of a risk being realized. Now, the likelihood of a threat is a measure of the probability that a particular risk will be realised and impact your organization. As we discussed, there are many threats and vulnerabilities, but not all of them will cause an impact on your organization. For each of them, the potential for loss must be considered, and the probability of this loss occurring is then called the likelihood of a threat. The likelihood of a threat is influenced by many different factors. For example, your organization's geographic location will influence the likelihood of a particular natural disaster occurring, for example, an earthquake or a hurricane. Other organisational factors, like the type of technology used in its security posture, will also affect the risks that are introduced by humans. Threat likelihood levels are usually going to be categorised as high, moderate, and low. The likelihood will be determined by taking into account the motivation sourced, the analysed rate of occurrence, and trend analysis. Motivation is what causes someone to act. That person could be our organisation or the threat actor. Some threats simply don't have any motivation, such as an earthquake. But human threats do have motivation behind them. These motivations could include acquisition or theft, business advantage, damage, embarrassment, or technical advantage. Understanding the motivation behind a threat can help organisations determine the best risk mitigation strategy and the best controls to put in place to protect against that threat. Now, there are two major sources of threats, internal and external. These two types were then subdivided into hostile and non hostile.Just like motivation, it's important to understand the source of the threat to better protect our organisation from it. The second thing we need to consider is the magnitude of the impact that would occur if a risk is realized. The magnitude of impact is an estimation of the amount of actual damage that a negative risk can achieve or the amount of opportunity cost if a positive risk is realized. This is also known as risk impact, and it can be measured financially using quantitative methods or subjectively using qualitative methods. When rating risks, we usually use a scale with negligible losses being classified as low level and significant losses being classified as high level. Most often, though, managers really like to see these risks represented using quantitative methods that result in a financial number. These fiscal values allow personnel in the organisation to better understand the cost associated with a given risk and its impact. The two most common calculations used in determining the magnitude of impact are single loss expectancy, or SLE. an annualised loss expectancy, or ale. Single-loss expectancy is the cost associated with the realisation of each individual threat that occurs. It is calculated by multiplying the asset value AV with the exposure factor EF, and that is simply the amount of the asset value that's going to be lost if the threat is realized. For example, let's say I have a file server that's an asset with a value of $10,000, and there's a given threat of power failure that would reduce the functionality of this file server by 20%, meaning its exposure factor is 20%. The SLE for a power outage would then be $2,000 because 10,000 times 20% equals $2,000 Now, the annualised life expectancy is the expected cost of a realised threat over a given year. This is calculated by multiplying the single lost expectancy by the annual rate of occurrence, or Aro. The annual rate of occurrence provides us with an estimate of how many times per year a given threat might be realized. Again, this is not an exact science, but rather an educated guess based on previous trends and consultations with subject matter experts. So let's go back to my file server example. We anticipated a single $2,000 loss. Now, if we lose power three times in a year, that would be $2,000 times three times a year, which gives me a $6,000 annual loss expectancy. But on the other hand, if we only expected to lose power once every two years, we would instead multiply the $2,000 from the single loss expectancy by 50% or one over two because it happens one out of every two years. This gives us an annual loss expectancy of only $1,000. Now, why is it important to understand the annual loss expectancy? Well, if we're afraid of the loss of power, there are lots of controls that we can put in place to prevent it from occurring. If we wanted to, we could add up all the construction costs and all the equipment costs of building redundant power to our server room, and then we could determine if it was really going to be worth the investment. For example, if it's going to cost us $200,000 to build a summer room that would never, ever lose power, how long would it take for us to make up the initial investment by offsetting that risk that we calculated? Well, if our annual loss expectancy is $6,000 because we lose power three times a year, it would take us 33 years to make up for that capital expenditure. This calculation is going to be the basis for determining your ROI or return on investment, and it helps decision makers decide if they want to accept the risk or put those controls in place. So, based on the magnitude of impact here, it wouldn't really make sense to go forward with building a better server room to address this threat. So we're not going to implement that control because it would take us 33 years to get our money back. Now, let's talk a little bit more about ROI. A return on investment is simply a ratio that considers how long it's going to take to make up for the expense or the investment by preventing the risk from occurring. The money that an organisation gains or loses after an investment is going to be referred to as an ROI, or return on investment. When an organisation is trying to determine whether or not to fund a security increase, it's going to be viewed through the lens of return on investment for the organization, because most organisations are businesses and they're in the business of making money. In its simplest terms, the return on investment tries to determine the expected fiscal gains for the improvements over your current methods, and then it balances those gains against the cost of implementing those changes. While return on investment can be easy to calculate for a business investment, it isn't as easy when considering investments in reducing risk. Instead, when we view return on investment and risk, we need to consider how we're minimising the chance of a loss occurring. To do this, we need to consider our six types of loss: loss of productivity, loss of revenue during an outage, data loss, data compromise, the cost of repairs, and loss of reputation. A loss of productivity occurs when there's downtime or repair time. Whenever people can't use the system to do their job, we have a loss of productivity that's being realised by our company. A loss of revenue occurs during an outage if your system is required for you to receive payments and provide services. For example, when I was a teenager, I worked at a grocery store. When their credit card terminals were down, they lost revenue because some shoppers didn't carry enough cash or checks. For them, they would simply abandon their shopping carts and go buy their groceries elsewhere. This type of loss is extremely common in ecommerce businesses. Now, on the other hand, you can also have data loss. If your data is lost, it's going to take you some time to perform a recovery from a backup. This downtime reduces your productivity, resulting in a productivity loss. Additionally, if the data can't be restored due to a damaged backup, the data might need to be recreated, and this causes additional expense and cost to you. Data compromises are going to occur whenever there's a disclosure or modification of data. This is an extremely bad thing if the data is compromised because it could contain intellectual property or personally identifiable information like a person's Social Security number. The cost of repairs are the actual costs that an organisation has to pay to procure and replace new hardware and software, as well as the labour time to get those things installed. Loss of reputation, on the other hand, is going to occur whenever a security incident occurs. When data breaches and other security incidents occur, consumers are often reluctant to trust that company again with their data, so they begin to shop at other places. This cost is extremely hard to quantify, but it is nonetheless a true loss to your organization. Now, when we calculate the return on investment, we must decide what to measure and how we're going to perform our estimates. There are two common methods we can use: payback and net present value. Payback is the calculation that simply compares the annual loss expectancy against the expected savings from implementing a control. For example, let's say I install a piece of hardware that costs me $1 million and is going to last three years. Now, this piece of hardware is going to prevent data breaches from occurring on my network. So should I do it? Well, maybe. We need to figure out what the ROI is here and the payback. So if we believe a data breach has an annual loss expectancy of $1 million and our payback is going to occur in the first year, that means I definitely want to do this, because this piece of gear lasts three years. So the first year it paid for itself, and the next two years, I'm saving a million dollars per year because I'm preventing all those data breaches. Now, that is a great deal, and I would definitely do this program. Now, on the other side, we can look at things using net present value, or NPV. Now, NPV looks at payback a little bit differently because it considers something known as the time value of money. This is because money spent today is not the same as money spent tomorrow. Now, in fact, we need to make sure we discount our money when we're looking at things over time. We do this by using what's called a discount rate. It makes tomorrow's money equal to today's money. Now, if this doesn't make sense to you, just think about how much a new house costs. Back in 1960, it might have cost $10,000, but today, that same house might cost you $100,000. Money across time is simply not equal. So to account for this, we need to discount the yearly savings by the assumed discount rate. Let's assume for the sake of easy math that the discount rate is going to be 10%. in our example. Earlier, I said I could save $1 million every year by installing this device. For the first time, our money is discounted by 10%. So the formula becomes: net present value equals $1 million divided by 1.1, which is 10%. This is going to equal $909,090. In the second year, our money is going to be discounted by another 10%. So our net present value becomes $1 million divided by 1.1 to the second power. Because it's our second year, this is going to equate to $826,446. Notice that in just two years, our million dollars' worth of today's money is now considered to be only worth $826,446. Why is that? Well, it isn't because of inflation, but rather because of the combination of inflation, opportunity costs, and other financial factors, which is why we chose a 10% discount rate. Your organisation is going to have their own discount rate that they use for calculations. So be sure you consult with them when trying to determine the net present value for your own analysis. I'm using 10% here just to keep things easy. Now, another thing we need to consider when it comes to countermeasures is the total cost of ownership, or TCO. Now, often people are short-sighted and only consider the initial cost of the organization. But your TCO, or total cost of ownership, is much more than that. Your total cost of ownership is a financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or service. Let's say I'm going to offer you a new programme that's a software as a service product and I'm going to charge you ten cents per active user every month. Or you can have a single cost of $499 per month with unlimited users. Which one should you choose? Well, that really depends on how many users you have, right? Doing some quick math, we can find that if we have fewer than 5000 users, the cost per user is going to be lower. But as soon as we have 5000 users or more, we're going to save money by choosing the $499 per month plan. But to make matters more complicated, this particular SaaS product will only let you choose your plan when you first enroll. So whichever one you choose, you're going to be stuck with it forever. Now, which one is the better deal? Well, again, this depends on your organisation and your growth projections. If you expect to eventually hit 5000 users or more, then 499 per month would still be the better choice for you if you're going to be using that software for a long time, like 20 years or more. But if you're going to be slow to grow and it's going to take you lots and lots of time, well, you might be overpaying for lots of years before you hit that magical crossover point of 5000 users. So remember, when you're looking at countermeasures, you also need to ensure you're considering not just the base price, but all the other parts that go into the total cost of ownership. For example, you have labour costs. How many person-hours are you going to be using to support this measure? Now, if it takes 5 hours per month and your average technician's salary is $40 per hour, that's a cost of $200 per month that you need to add into your total cost of ownership. So if there's another solution out there and it's only going to take 1 hour per month to manage, that saves you $160 per month or $1,920 per year. So you now need to account for that when deciding which countermeasure is better for you to choose as you look at the total cost of ownership over a normal ownership cycle, which is normally going to be three to five years. Now, in terms of risk management, the "total cost of ownership" is going to refer to the overall costs associated with running your organization's risk management program, which includes all the cost of insurance premiums, administrative costs, losses incurred, and other financial costs. This total cost of ownership is then going to be compared to the organization's revenue and assets, providing us with a method to assess the organization's cost versus their growth rate. This total cost of ownership can be compared not just internally against your organization's own trends but also against the industry standard to determine if the amount of spending is considered reasonable. By calculating and considering the total cost of ownership, an organisation can identify inefficiencies in their risk management programmes and work to drive down costs and save the organisation more money. Now, the total cost of ownership is often viewed as a method of determining where to cut costs. And for this reason, it's often opposed by personnel within the organisation itself because they fear that the funding for their projects could be cut. So be aware of that when you're looking at this. So, when you calculate the total cost of ownership, there are a few basic rules you need to remember. First, industry benchmarks aren't always representative of your organization. Second, minor risks should be covered within the organization, not through insurance. Third, utilise risk management software to help your decision-making due to the complexity of risk. Fourth, consider the value of risk management when you're rebudgeting, because it isn't just about saving money. Fifth, total cost of ownership analysis doesn't instantly save you money. Those savings are realised over time. and six, the organisation cannot solve all possible problems. So sometimes the solution has to come from external specialists and by purchasing insurance. Next, let's talk about two important metrics that are often used in risk assessments, MTTR and MTBF. Now, MTTR is the mean time to recovery or the mean time to repair, and this is the average time that a device will take to recover from a failure. The MTTR would usually be part of your maintenance contract, and this is where the user is going to pay more for a system with a lower MTTR. An MTT of 24 hours is going to be more expensive than one for seven days. So as you're deciding on your risk tolerance and trying to determine how long you can afford to be down, the MTTR is an important thing to consider. For example, I once worked for an organisation that had an MTTR contract with Cisco for our routers and switches. The business folks negotiated a contract for three days. Then when a critical router failure occurred, they were upset that it took us two and a half days to get back online. Well, two and a half days is less than three days. So Cisco was well within their rights, and they were within their contract terms. Now, this is something that we had to go and bring up, and we had to discuss it when they went to renew the contract and figure out if we could afford a faster MTR. This is why understanding your MTTR is really important because you're going to get what you pay for. The other metric that's important to understand is MTBF, or mean time between failures. Now, the "middle" time between failures is the predicted average time that will elapse between a failure of a component during a normal system operation. For example, if you have a Cisco 29-60series router, it has an expected useful life of about three years, and the mean time between failures is listed at around 29 0 hour.Now, if you do the math, that means the mean time between failures is actually set at 3.3 years. So, as you're doing your risk assessments, it's important to know what your MTTR and your MTBF are before you go into doing your risk assessments. This is going to affect your operational capabilities, and you need to put the right risk mitigations in place. You're going to do that based on how often things break or how long it takes you to get it back online. Finally, we need to discuss gap analysis and trend analysis. With a gap analysis, we're going to look at the performance we're experiencing and the performance we expect to provide our users. So if we have an expected uptime of 99.9% and we measured over the past month and we finally reached 93%, we have a gap, and we need to increase our availability. Now, we need to find out what's causing this decreased performance, and we need to figure out how we can eliminate those risks that are causing those things to be realized. and causing the extra downtime. This is essentially what we're doing with a gap analysis. Trend analysis, on the other hand, is going to provide us with methods and processes to take our historical data and provide us with a baseline and a future possible projection of our risk. These baselines provide us with a good starting point to consider, and as we track those trends, we should take note of the variances in the data and the patterns. As security professionals and nationals, we should continually research the growing trends across the globe, especially with regard to our own specialised industries. This is how we can better understand the common risks in our field and how we can better protect ourselves from those threats.

So when looking for preparing, you need CompTIA CASP certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, CompTIA CASP exam practice test questions in VCE format are updated and checked by experts so that you can download CompTIA CASP certification exam practice test questions and answers files in VCE format.