Risk Strategies (Domain 4)

6. Security Controls (OBJ 4.1)

In this video, we're going to talk about security controls. Now, we spend a lot of time talking about risk, ways to mitigate it, and the security controls that we can add to prevent risks from being realised in our operational networks. But if we never review or test our security controls, our organisations can be extremely vulnerable. As information system security professionals, we spend much of our day reviewing all aspects of security, including device configurations, policies,procedures, and patch levels of our systems,in addition to continually conducting security training. In addition to these self-conducted reviews,we're also subject to outside audits,vulnerability tests, and pen tests too. All of these security control reviews will help make our networks more secure and should be conducted at least annually. When you're reviewing security controls,you should consider the following questions: What security controls are in use? How can we improve these controls? Are these controls needed? Has the architecture changed? Have any new problems been identified through trend analysis? What security controls can be added to solve these issues? By asking these types of questions, we can begin to perform a preliminary gap analysis. A gap analysis will compare the current performance of the organization's security posture to our desired security posture. If there's a gap, we can add additional controls. Then we can help close that gap and drive our organisation to a better security posture. But before you can do a gap analysis, you need to know where you're currently sitting in terms of security. So we're going to use benchmarks and baselines to determine that. As a security professional, it's important to be able to justify the expenditures that we need to provide adequate information system security. To do this, we often rely on measurements, keyperformance indicators, and other metrics to justify the current security level and the desired future security level. One of the most common methods of doing this is by using benchmarks and comparing them to the current baseline. Now, a baseline is a defined metric that's used as a reference point to compare against a future metric. This baseline is captured early on in the service management process, but if it's never updated or used for comparison against another given benchmark, then it becomes useless. Now, a benchmark is going to be a reference point that captures the same information as your baseline, but it does it at a different point in time in the future. In fact, if our organisation decides to conduct rebase lining, then the current benchmark could become your new baseline. Benchmarks are compared against the baseline to determine if our organisation is making progress towards our security goals. Baselines and benchmarks should be captured at similar times to ensure the network posture is comparable. So if you create your baseline at three in the morning, you shouldn't create a benchmark at twelve in the afternoon, because those are two very different times for most corporate networks. Further, your baselines are generally going to be captured over a longer duration of time, usually providing you with an average, whereas a benchmark can be a single point in time that's used to compare against the current baseline. Understanding your benchmarks and baselines really relies on a thorough understanding of your thresholds too. When dealing with security issues, you need to set up alarm points, and that's generally going to be based upon your thresholds. This is going to be whether you're going to have something that's high above or well below the baseline activity. These could be indicators of a security incident, and they should be investigated by your cyber security analysts. To effectively use these benchmarks and baselines,we need to be monitoring our current status and looking at trends over time. One way to do that is through continuous monitoring. Now, continuous monitoring is essential to good organisational security. After all, if we only did security checks once every six months, our organisation could have been under attack for a long time before we even discovered it. But in order to know what abnormal looks like during our continuous monitoring, we have to know what normal looks like. And that's why we create a good operational baseline. A baseline is going to establish what is considered normal in our organization. So if we're looking at our network utilisation and it's averaging 80% during working hours, that becomes our baseline. However, our baseline isn't set in stone, and it can be modified and changed over time as our network or services that it provides are changing.For example, if we look at our network utilisation today and it's 95% above the baseline,we should analyse why that's the case. Maybe somebody's excellent data out of our network is causing a spike in usage. Or maybe it's because we just hired 20 new employees—that's a lot more people using the network. If the increase is due to explainable reasons, like hiring new employees, and those additional users are using more bandwidth, then that is going to have to be updated in our baseline. Continuous monitoring can detect all kinds of issues in your organization. For example, if our users are normally logged in from 8:00 a.m. to 5:00 p.m., Each day, we see through Continuousmonitoring, there's a new user account that's logging in every night between 1:00 A.M. and 2:00 A.M. and 03:00 a.m. That could be a sign of foul play—either from an attacker or an insider threat. As we conduct continuous monitoring, we constantly evaluate our performance against our benchmarks and our baselines, which themselves are made up of a bunch of metrics. Metrics are now very important in most organizations. Senior leaders and managers love metrics because they provide a quantitative look at risk and the performance of your network. While properly collecting metrics is important, it's more important to ensure that the analysis of those metrics is being performed. It is through that analysis that the organisation can project their future needs and prevent problems from occurring. In most organizations, the security metrics budget and the overall reporting of security postures are the responsibility of the Chief Security Officer, or CSO. This person is going to work closely with experts within the organisation to determine what security is going to cost usassociated with our development, testing, procurement, fielding, maintenance, and personnel necessary for us to protect our organisational information systems. Our security metrics are used to determine long-term and short-term trends. In the short term, these metrics are used to determine the current daily workload and which incidents need to be responded to first. For the longterm trends, though, these metrics help to shape the future security budgets and the associated projects that we're going to need to be funding overtime to solve our more systemic issues. Now, guidelines need to be developed for all the different methods of collecting these critical metrics. Who is going to collect your metrics? What metrics are you going to collect? When are the metrics going to be collected? At what threshold will corrective actions need to be taken at all? These are things that should be covered by your guidelines. Metrics are the lowest level of data collection,but you can combine them together to create actionable information by using your analysts. These are called KPIs, or Key Performance Indicators, and they are a collection of metrics that we use to help manage an IT service process or activity. KPIs can either be quantitative, measuring the amount of something, or qualitative, measuring the quality of something. KPIs are used to determine performance quality, such as server uptime, the state of your cybersecurity, and other key performance areas. Now, a Key Risk Indicator, or Kri, is isometric to a KPI in that it contains numerous individual metrics bundled up together. However, a Kri is going to measure the possibility of a future adverse impact. Kris are used as an early warning device based on the collected and analysed metrics, and they determine how risky a particular activity or solution is to the organization. Now, once we have all these metrics, we can combine them to display the trend over time. When conducting cyber defense, one of the most important things an organisation can do to increase its security is to identify patterns of activity. By understanding your normal activity patterns,we can identify what is abnormal. Any abnormal activity should be investigated further to determine the reason behind it. For example, if a cyber defence analyst is looking through the Security Information Event Manager and they start seeing a workstation that's sending out a single ping every ten minutes, would this be abnormal? Well, Ping is a computer network programme designed to send ICMP echo request packets out to remote hosts to determine if they're online or not. So this might not be considered unusual in and of itself, but the fact that we're seeing only a single packet being sent is kind of abnormal. And the fact that we're seeing it once every ten minutes is kind of a certain schedule, which again, is more abnormal. Normally, when you see ping traffic being sent, it's sent continually if it's coming from a Unix, Linux, or OSX machine, or you're going to see a series of four requests if you're doing it from a Windows machine. Since we're only seeing a single request being sent, this is pretty unusual. Next, we have to consider the frequency of the incidents. We discovered that the singleping occurs every ten minutes. This is extremely unusual. In fact, since it's being set at a specific frequency, such as every ten minutes. This could indicate a malware infection with beaconing that's happening out to a command and control server. So, as you can see just from this simple malwarebeaconing example, trend analysis can be really useful in identifying issues and problems that need to be resolved. Furthermore, Trend Analysis is also going to be used to determine where to plan out your resources. Let's consider the example of an e-commerce Web store. The service designs a service for up to 100 users per day. Currently, we have a maximum peak of 5000 users per day. As we conduct trend analysis, we see that our site is adding about 10 visitors each month. This means that within the next five months, we're going to be at 100 visitors per day, and our server is going to be at maximum capacity. Doing a quick trend analysis here indicates we need to start budgeting, acquiring, and fielding additional web servers within the next five months. Otherwise, we might be at the risk of losing business due to our servers crashing.

7. Security Solutions (OBJ 4.1)

In this video, we're going to talk about security solutions. Now, whenever a security problem is identified in the network, it's our job as security professionals to find an appropriate solution for it. This can involve hardware or software upgrades, new technology being installed, or recommending configuration changes. Regardless of the solution, it requires us to create a prototype and test the solution before we roll it out across the entire enterprise. It is always a good idea to first create a prototype or conduct a test of the solution in a lab environment. This allows us to determine if there are any negative consequences associated with deploying the new solution. A new security solution can often cause operational problems on your network, such as decreasing response time or even shutting down entire services. We should always ensure that the key stakeholders are happy with our solution prior to deploying it across the entire enterprise. And we should also mitigate the risks associated with the solution down to an acceptable level before it is shielded. Thankfully, prototyping and testing have become much faster and easier these days because of virtualization. Due to the rise of virtualization technologies, it's quite easy to create a simulated live environment in which to deploy our solutions and then be able to see how they react to the changes. By ensuring the virtual environment is fully isolated, we can also prevent any negative effects on our production network. Once the solution is successfully tested in an alab environment, it's time for us to test it in a live environment. Now, it is best to roll out this test in a live environment in stages or patch rings and during low periods of activity to minimise any possible negative effects. Prior to rolling out our test solution to the live network, we always want to conduct a full backup of the system to ensure that we can roll back changes with minimal downtime and without any data loss. Now, as you develop these prototypes, you might also decide to use reverse engineering or a penetration test to identify how someone might attack your proposed solution. As they say, the best defence is a good offense. And so, as information system security professionals, we need to think like attackers to help secure our networks. Whenever we propose a solution to a particular network security issue, we should always ask ourselves, "How would an attacker break into my network if I had this in place?" Now, there are several IT certifications on the market that focus on an attacker's methodology and how to think like an attacker. Certifications like the CompTIA Pen Test, plus the Certified Ethical Hacker or CEH, And the Offensive Security Certified Professional (OSCP) is one of the best known in our industry. When examining a security solution, always think about the easiest way to circumvent the solution as an attacker. For example, if we install an expensive and well configured firewall, maybe the best way into our network isn't by going through the firewall but instead by conducting spear phishing using a social engineering attack or if we have a public office that uses wireless networking. Maybe the easiest method is for the attacker to pose as one of our customers and gain physical access to the building. The physical security of our office and server rooms is just as important as the technical controls that we're placing on them. Always consider how to protect the network both logically and physically from an attack. Again, you have to think outside the box and think like an attacker to fully protect your networks. While every security solution that we deploy should increase network security overall by aiding ourdefenses, it's also important to understand specifically what needs from our business we are going to solve with our security solution. Now, there are eight primary business needs that our solution could be addressing.These are performance latency,scalability, capability usability, maintainability availability, and recoverability. Performance is a technology's ability to fulfil its intended purpose or the efficiency with which it fulfils it. Every device in our network should have a set of performance metrics associated with it, even our security solutions. These performance requirements should be considered when we're procuring our security solutions. We also want to consider not just the current requirements but any future requirements we might know about. It's often best to install a solution that outperforms the current requirements in an effort to future-proof your solution. Latency is going to be the delay that occurs during the data processing of a network. A network with low latency has a short delay and is considered better in most cases. Unfortunately, as we add additional layers of security to our network, this often increases the latency and results in longer delays for our end users. The latency added by a security solutionhas to be considered when you're deciding to add that solution to the network. If the latency becomes too high, it may be time to look at a different solution for your given problem. Scalability is another thing we look at. Scalability is the ability for a technology to perform under an increased or expanding use case. A scalable system should be able to handle an exponential increase in requests from your users without affecting the overall performance of the system. This can be accomplished through load balancing,clustered servers, or even cloud architectures that use elasticity to expand the number of resources available on the fly. The next thing to consider is capability. Capability is the ability for a particular technology to perform a solution. For example, an IPS, or intrusion protection system, has the capability to detect and block a port scan that's going on against your network. This is distinctly different than the capability of anIDs or intrusion detection systems, which can detect theport scanning but can't react to it. When you're shopping for a new security solution, vendors are always going to doubt their capabilities in an effort to earn your business, and you have to be careful to make sure they're not lying to you and that they can actually do what you need. Usability is the ease of use of a security solution and how closely that solution matches our requirements. If a solution is highly rated in usability, it's easier for employees to learn that thing, which leads to a lower cost of ownership. Maintainability is the measure of how often the solution has to be updated, upgraded, or fixed. Now, this includes things like software patches, hardware refreshes, upgrading the software, and much more. If more maintenance is going to be required, the total cost of ownership is going to go up. Plus, maintenance can result in downtime and a loss of revenue. So maintainability becomes a very important to consider.Availability is the amount of time that a system is available for use and is often measured as a percentage. Availability is determined by holistically looking at your system and determining which components are likely to fail. Based on those failure rates, we need to figure out how long it would be down, how long it would take to repair, and how long before it fails again. For example, a network switch may have a mean time between failures of four years and get a high availability rating, or it may have a two-year rating, therefore it will have a lower availability. Recoverability is the probability that a failed solution can be restored to normal operations within a given time period. Recoverability is determined by researching the actions needed to restore the device back to normal operations, then determining how long all those actions would have taken you. Now, each of these business needs is important and they need to be considered. when you're analysing a new security solution. No single business need is always more important than the others. But depending on the particular technology or device that you're thinking about purchasing, we may weigh one of these factors more highly than others. Remember, during your career as an information system security professional, you're going to be asked to solve problems where there is no right answer. These problems aren't simply math problems, but rather opinions based on the experience that you have. These questions can truly be hard to answer because the answers can have farreaching consequences for your organization. For example, if we were asked 20 or 30 years ago if our company should start investing in virtualization technology,there was probably no clear answer to that. Virtualization at the time was untested and its future was uncertain. So should your company invest large sums of money in the hopes that this emerging technology might save them more money down the road? Well, when you're posed with one of these tough questions, what should you do? The thing is, you don't need to answer this right on the spot. Instead, you've got some time, so you should start becoming an expert on the subject. For example, you may not know everything about virtualization, but you could do some research and learn more about it. When you get these questions, they often don't come up in a meeting. We are expected to provide an instant analysis and response. Instead, they will usually give you at least 24 hours to go back and research and create the report and give the recommendation the next day. So when in doubt, ask for some time to research the answer and get back to the boss with a recommendation. When doing that research, don't rely on a single vendor's marketing materials. Instead, you need to look across numerous vendors, ask peers for help, and look for scholarly journals on the subject. As you become more knowledgeable in the industry, you're going to find that you're going to go back and research things a lot less and less each time, and instead, you'll be able to rely on your previous experience and judgment. Either way, though, you will need to weigh the answer by conducting a quick cost-benefit analysis of that solution, and then make the best,most educated guess that you can remember. Information is key in making the best decision, but don't become paralysed by overanalyzing every single option. Too often, I see people who suffer from paralysis of analysis, and they simply never decide. Instead, I want you to pick the best option, back it up with some solid reasoning, and then commit to it.

8. Cost of a Data Breach (OBJ 4.1)

In this lesson, we're going to dive into our second case study. Now, I really like this one. It's about the Equifax breach. If you're not familiar with it, I'm going to give you the 50,000 foot view here. 145 million Americans were affected by this Equifax breach. This is one of the largest data breaches of 2017. The attack happened back in July of 2017 and the attackers used a vulnerability in what's known as the Apache Struts framework. Now, we don't have to dig into the technical details of what Apache Struts is, but essentially this framework is used to make web applications. There is a vulnerability in the Apache Struts framework that was released back in March of 2017. If you stay with me here, I just said that this breach occurred back in July of 2017. How many months later is that? March, April, May, June, July. They had five months in which they could have solved this problem. It is now CVE 2017, 5638. It was released on March 6, 2017, to the entire world. And over the first six days of that vulnerability, as it was out across the Internet,there were thousands of attacks that were occurring. How do you mitigate this vulnerability? Well, if you look up the CVE, which is the common vulnerability exposure code, you'll find a couple of things. You can mitigate the risk of this vulnerability by upgrading Apache Struts to either version 2332 or 2510, blah, blah, blah. You get the idea here. You can also just use a different multipart parser and not use Apache Struts at all. Basically, change the software, which would avoid the issue completely. So we can mitigate it by patching it and upgrading, or we can avoid it. This goes back to our four things we can do with risk right now. If you decide to avoid this and change to another software, you're going to have to rewrite all your code, retest all your code, and redeploy all your code. That can take a long time. And definitely, you can see why five months wouldn't have been enough there. But if you want to mitigate it and upgrade the system, you could have updated Apache Struts, recompiled your code, retested it, and then redeployed it. It's a much shorter process. How come they didn't get it done within five months and still got around to it? Well, because there's a huge cost there and they were doing the mitigation, or having thought of what they should mitigate, whether they should, whether they shouldn't,are they going to accept the risk? All of that takes time in large organizations. In this case, they accepted the risk. They never made a move to go ahead and upgrade until after the breach occurred. So they didn't avoid it and they didn't mitigate it. How much would it have cost them to upgrade the system and fix the code before the breach happened? Well, some estimates put it at around three and a half million dollars. Between the manhours, the salaries, and the downtime to reprogram the website over those four or five months and get all that stuff fixed, it's a large sum of money, and somebody probably went and said, "We'll get around to it eventually." And so they accepted the risk. Now, whether they really said that or not, I don't know. I don't work for Equifax. I wasn't in their boardroom. I didn't get to make those decisions. But at some point, they decided—and they didn't fix the vulnerability, and they didn't mitigate it by default. If you don't fix the vulnerability, if you don't mitigate the vulnerability, if you don't avoid the vulnerability, then guess what? You've accepted it whether you knew it or not, because that vulnerability still existed and it was still exploited. So what was at risk here by Equifax? Well, if you know anything about credit bureaus,you know that they have a lot of detailed information on all of these 145,000,000 Americans. They have Social Security numbers, dates of birth, names, addresses, credit card accounts, credit card balances, and loan balances. All that sort of stuff is sitting there on your credit bureau reports. And that's what Equifax was holding here. So you have to ask the question, how much is security worth in this situation? Now, that's a big question that you're going to be facing in all of your roles as an IT manager or an executive. How much is security really worth? I said, we can guess that. It may have cost three and a half million dollars to fix this vulnerability. Before the breach happened, well, after the breach, in quarter three of fiscal year 2017, how much did Equifax spend? As of September of 2017, only two months after the breach, they had already spent over $55 million on security products and another $17 million on consulting fees. As part of the incident response from this breach, they spent $14.9 million on customer support calls because 145 million people were calling them saying, "What did you do?" How did you lose my data? They have additional costs that are still being counted up, and this is amounting to things like $50 to $100 million. And when you start adding all this up, you're getting a number of about $200 million for this breach. This is a big breach, and it costs a lot of money. All of that could have been prevented for three, four, or five million, but after the cat's out of the bag, you've already hurt your reputation. You spent a tonne of money playing cleanup and trying to catch up to this response effort. The old saying that an ounce of prevention is worth a pound of cure is no more true than in cybersecurity. It is much cheaper to try and prevent the issue ahead of time than to clean up after you've had an attack. Equifax ended up spending millions and millions of dollars. Estimates are between $150 and $250,000,000.because they didn't make the right decision to mitigate, transfer, or avoid the risk. Instead, they made the decision to accept the risk by not taking any actions. And that's where we have a problem, because you have to remember, you now have to live with that decision. I'm sure you've seen the news. If you haven't, go ahead and google the Equifax breach. She was fired as the chief technical officer as a result of it. When someone has a data breach the size of this one, someone is going to lose their job. And you just have to hope that it's not you. There are lots of things that happened here,let alone all the victims, because all the data is now out on the internet. This was a major, major, major issue and a failure of risk management.

ExamSnap's CompTIA CAS-004 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, CompTIA CAS-004 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.