Vendor Risk (Domain 4)

1. Vendor Risk (OBJ 4.2)

In this section of the course, we're going to cover vendor risk and how we manage and mitigate some of those risks as we deal with different vendors that work within our organizations. Now we're going to focus on objective four. Two, it states that you have to explain the importance of managing and mitigating vendor risk. After all, and technology, they're always evolving, and with it, new threats and vulnerabilities are being introduced into our landscape. As risk management professionals, we must carefully analyses any new product or technology to better understand the threats and vulnerabilities that may be introduced into our information systems when we install them. These new technologies are also going to impact the way our users interact with that technology, and this can bring additional risks to our information systems. But most importantly, these new technologies are often brought to us by third-party vendors, not our own internal developers. And that brings with it new risks that we must identify, manage, and mitigate. But what kind of threats should we consider when we adopt new technologies? Well, if we're going to buy a new piece of software, for example, we have to consider what kind of support we might expect if that company is going out of business.

This is often something that people overlook when they jump onto a new product bandwagon. But they need to know that there is additional risk to our organizations if we start to use small startup software over something from a bigger player in the industry, such as Microsoft. Now, user behavior is also constantly adapting and changing in response to the different technologies that we find in the marketplace. For example, 30 years ago, no one would have considered it possible that an employee could carry a device smaller than their house key and walk out the door with the entire copy of your office's database. But with the increase in storage capacity of micro, SD cards, and USB thumb drives, this is very much a reality these days. If you use third-party contractors as part of your sourcing strategies, what are you doing to ensure that this third party is trusted and trustworthy in handling your precious corporate data? In the days of old, organizations were most concerned with securing their internal networks.

Then the migration to email occurred, and security professionals had to start seeking to encrypt and secure those emails as well. These days, another migration has occurred into the world of instant messaging through systems like Slack, Skype, and even Facebook Messenger, and securing all these communication lines has now become a high priority. All of these instant message technologies, though, are also examples of third-party suppliers providing us with software as a service. So we need to consider all the different types of risk that are associated with the basis of our business operations being used on these supplier products. Now, how are you going to keep up with this tide of ever-changing technologies and user behavior? Well, first we have to monitor our users' behavior using technology and oversight. Next, we can mitigate, deter, and prevent risk through ongoing and continual training and by updating our security policies. And third, we have to be forward-thinking when we look to adopt new technologies and consider the possible user behaviors that are going to be associated with them. It's only by keeping up with the trends and making some estimations of our expected user behaviors that we can hope to get out in front of these new technologies and mitigate their associated risks.

So, as we move through this section, we're going to start by discussing some of the business models and strategies, such as partnerships, outsourcing, the cloud, acquisitions, mergers, divestitures, and demergers, because all of these business models and strategies will bring different risks to our company. Next, we'll dive into the different types of internal and external influences on your organization and its suppliers.

After that, we're going to discuss changes to policies, processes, and procedures, since every time you add or remove a new vendor or supplier, these things have to be modified or changed inside your organization as well to reflect the new ways of working with this new supplier. After that, we'll cover the shared responsibility model, the viability and support of the vendors themselves, third party dependency, and some additional considerations that you might want to think about. Finally, we're going to discuss the supply chain and the importance of looking into your supplier's supply chain and its security. So let's dive into this section on vendor risk.

2. Business Models (OBJ 4.2)

In this video, we're going to discuss business models and strategies such as partnerships, outsourcing, the cloud, acquisitions, mergers, divestitures, and demergers because all these business models and strategies are going to bring different risks to your company. The risk profile of an organization is heavily influenced by the business model that it embraces. Remember, a risk profile is an organization's willingness to take on and accept various levels of risk. When we talk about the risk profile of an organization, it's going to be determined by your organization's risk appetite and risk tolerance. For example, if our company is a brick-and-mortar restaurant, we may be less dependent on computer networks to conduct our business than, say, an e-commerce website would be. Therefore, our risk profile will look vastly different than that of an ecommerce company.

There are four major types of business models and strategies that affect an organization's risk profile. These are partnerships; outsourcing; the cloud; acquisitions; mergers; divestures; or demergers. We're going to dig into each of these as we go through this lesson and talk about the different business models and how they affect our organization's risk profile. Our first business model is a partnership. Partnerships can be formal or informal, and they establish a requirement for the exchange of information and sensitive data between two organizations. Partnerships can raise some unique security challenges, though. For example, do you trust that your partners going to protect your data to the same level as you do in your organization?

Are they maintaining a proper vulnerability management and remediation program? If not, our systems could be put at risk as well, because the interconnection of our systems with their systems could allow a new vulnerability to be exploited by a threat actor. Oftentimes, to combat this information, security professionals will use a third-party connection agreement, or TCA. This TCA is going to dictate the security controls that need to be put in place in order to protect the data that's being exchanged between these two partners. Now, there are other partnerships where the focus isn't on the exchange of data but instead is on the cooperation between two organizations to provide a shared service. If your organization is going into business with a partner, you should always have a third-party connection agreement or some other type of partnership agreement drawn up that's going to dictate the specific responsibilities of each party in the gathering, processing, handling, and storing of sensitive data.

The second business model we need to look at is outsourcing. When a business function or process is performed by a third party outside of our organization, this is referred to as outsourcing. A common issue with outsourcing is that your organization is going to believe they can transfer the risk to that third party. But in fact, that may not be the case. It's really important to look over your outsourcing agreement. Have you done a proper risk analysis of the functions being outsourced? Does the outsourcing agreement make it clear who's responsible for what security measures? Can your outsourcing provider meet all the legal and regulatory requirements that you want them to handle on your behalf? Outsourcing is normally going to involve contracting and procurement processes within your organization as well, and you need to ensure those processes have been evaluated from a risk management perspective too.

Your organization needs to ensure that the contract has language in it to specify your security requirements, but you also need to allow for a periodic review of the outsourcer to ensure they're actually meeting those requirements you specified. Another issue with outsourcing comes up when an organization outsources a single function to multiple vendors. Let's consider the example of a web hosting service. If our organization is going to outsource this to three different cloud providers, it can become an enterprise support issue because each provider has their own processes and procedures that our staff has to follow, and the architectures may not be compatible with one another. This can lead to longer delays when we're trying to implement security controls and decrease the overall security of our systems. The other issue with outsourcing is legal hurdles. Remember, the company we outsource to must follow their local laws as well.

If we outsource to a company with stricter laws than our own, we may be buying ourselves into an increased expense because now we have to meet all these additional regulations. This is just another factor to consider when weighing the risks and benefits of outsourcing a specific function or service to a third-party provider. Now, here's the dirty little secret that many outsourcers don't tell you when they offer their services. They also subcontract That's right, even though you contracted companyABC to be your web server, it may be that they turn around and outsource the delivery of that to company XYZ, and you don't even know that. If this happens, we need to ensure that the company that we originally outsourced to, for example, company ABC, is going to be checking to ensure that company XYZ is also meeting our security requirements in their delivery.

Otherwise, we can have a major liability for our organization and not even know it. Remember, just because we've outsourced the service doesn't relieve our organization of any legal or regulatory requirements for it. If we outsource this to a provider and they don't meet the legal requirements on our behalf, we're going to be the ones suffering the consequences for downstream liability of their actions. Now, when we talk about downstream liability, this refers to the liability that our organization suffers because a partner or outsource provider doesn't fulfil organizational or customer requirements. At the end of the day, our customers and regulators are going to be holding our organization to a specific standard, and they don't care whether we outsource the function or not. We can't simply say, "Well, my outsourcing provider didn't do it." It's not my fault because, guess what? It is your fault. That's what downstream liability is all about. We are going to be the ones who are held accountable and liable for this. This all comes down to due diligence and due care. Remember, when we talk about due diligence, this is defined as having investigated all reasonable measures to address a given risk. Due diligence is often confused by people with due care. Due care is defined as taking all responsible actions to prevent security issues or mitigate a possible security breach. The big difference here is that due diligence is all about gathering information, while due care is all about taking action. This concept applies directly to our outsourced providers too. We need to exercise due diligence in our selection process and ensure that we're conducting due care in their operations when they're fulfilling our requirements.

Now, the next model we need to cover is cloud computing. Cloud computing appears to be on everyone's mind these days, especially with Amazon Web Services, Microsoft Azure, and the Google Cloud Platform, as well as many others out there, touting the cost saving benefits of utilizing the cloud for your data storage and virtual server needs. But you have to remember that sometimes the cloud is not going to be the right answer for your organization. In fact, in some regulatory situations, we may not even be legally allowed to utilize public cloud infrastructures. A good regulatory example of this is found in the government sector, where the use of private clouds is required because they believe the public cloud is insufficient for security.

For a contractual example, we only have to look at our credit card processing agreements, which may have stipulations in them that say things like you can't use a shared server or you can't have an account outside of your home country. Both of these could be limitations that are going to create limitations on where we can put our servers and what cloud options we could use. Otherwise, we would be increasing our liability. Now, if we do use a public cloud, how are we going to ensure the security of our data? How do we know that our data is being kept separate from other organizations' data on that same infrastructure? As we've mentioned before, we can outsource the service, but ultimately, we're still responsible for the security of our data. So what specific cloud-based threats should we consider? Well, if you understand the concept of elastic cloud resources, you know that virtual servers are created and destroyed based on the level of usage and demand. When there's a period of low demand, virtual servers are taken offline and destroyed. When the load increases, new servers are added, but they may not be added to the same physical hardware.

This could lead to problems with data remnants, and we have a risk that the old physical servers have remnants of our confidential data still residing on their hard disks. Now, some clouds are created as hybrid clouds, and they tout the benefits of both private and public cloud infrastructures. While this does have the benefits of both, it also has the drawbacks of both because you're utilizing some cloud infrastructure and some private. Now, there is a third type of cloud you may come across as well, known as a community cloud. Now, a community cloud is normally run by a third-party organization or a cross-company team of providers that are sharing resources across multiple organizations with the same needs. This can help to drive down the price of providing that service because we're all working together. But it also increases the vulnerabilities of the member organizations because they're sharing data in this shared cloud.

Essentially, when you become part of a community cloud, you’re becoming part of a quasi partnership, and there are risks to doing that as well. The next business model or strategy we need to discuss is acquisitions and mergers. Acquisitions and mergers may occur between different organizations, and during that time, their networks and information systems may be combined. This can be a difficult time for organizations, and it's one that can introduce a lot of different risks. Sometimes organisations will even migrate to a new network instead of combining the two existing networks because there's so much risk involved. Either way, a lot of change is going to occur in a short period of time, and that means we have a higher level of risk. One of the largest challenges in the merger of networks is that the companies are utilising different types of hardware, different types of software, and different types of peripherals. This makes it challenging to support both networks while trying to determine what the future network is going to look like. It's really important that information security professionals take some time during the acquisition ormerger process to perform due diligence and begin to fully understand the other network. Then a penetration test of both networks should be conducted prior to moving forward. This will help both parties understand the risks as they currently exist.

Next, an Interconnection Security Agreement, or Isa, should be developed for these two systems, as well as conducting a risk analysis of the acquired company's information systems. Any extremely high-risk systems should be taken offline prior to the merger of the two networks. For example, let's say you found a Windows 2003 server at the other company. We need to require them to remove it prior to connecting our two networks to ensure the security of the combined network is going to remain high. While acquisitions and mergers are challenging, divestures and demergers are even more so. Divestures occur when a part of the company is spun off to form its own company. Now, during this time, the team is going to have to decide how the divested company is going to get its IT services. Will the old company still provide it, or will the new company take part of the network and some of the employees with it? These are some of the tough questions you have to think about, and you have to figure out what the answer is because each answer signifies a different level of risk.

And to make matters even more difficult, what if that spun off company was bought by another company? How are we going to ensure that the purchasing company gets all the parts of the company they paid for, including the data and information, and not anything they didn't pay for? Again, these are the challenges of divestitures and demergers. So if you're facing an acquisition, a merger, a divestiture or a demerger, we need to remember the five steps of due diligence that we need to perform. First, define a plan to set and measure the security controls along the way. Second, identify gaps or overlaps in security between the two networks. Third, create a risk profile for the risks in moving the data. Fourth, priorities process refinement based on findings. Fifth, ensure auditing and compliance personnel are using the same framework.

3. Influences (OBJ 4.2)

Drafting security policies to help manage and mitigate risk There are many internal and external influences that we have to consider in balance. Competitors, auditors and audit findings, regulators, clients' requirements, top level management, and de primers all provide influences that are going to affect our security policies. In business, it's always important to not only look inward at ways to improve our business, but we also need to consider the competitive landscape by looking outward at our competitors. By considering what our competitors are doing in terms of security, we can conduct due care while also considering what is normal and reasonable. Now, it's also important to understand that just because a competitor does something, doesn't mean we have to follow suit. Auditors and their findings can also help provide accountability to our organizations.

These audits can be conducted by third parties or our own teams, but either way, their results are going to influence our security policies. It's good practice to conduct internal audits at least quarterly and external audits at least annually. The ISO IEC 27,000 series provides some standards for conducting audits and serves as an excellent baseline for you to consider. Regulators are going to have a more stringent influence on our security policies if our organization works in a regulated field such as banking, healthcare, broadcasting, and numerous others. If our organization falls under regulations, this means we are often going to have third parties perform audits and analysis of our organization and report its findings back to the regulators to ensure we are in compliance. This analysis can occur as either an on-site assessment, a document exchange review, or a process and policy review. An onsite assessment is going to involve a third-party team coming to your organization and performing an inspection.

A document exchange and review involves providing copies of our documentation, either in hard copy or by electronic means, for review by the regulators. A process or policy review is like a document review, but instead it focuses just on our policies and processes. Now, our next influence on our security policies is going to be our clients. Clients come in two forms: internal and external. Our internal clients are our own employees who use our information systems for their jobs. They may have certain needs, like the ability to conduct remote access to the network over a VPN,and that's going to influence our security policies. But we also have external clients, and they influence our security policies too. For example, if our organization is hired to provide cloud storage for another organization, they may have certain encryption requirements that we need to meet in order to gain their business. Another influence we have on our security policies is top-level management, often referred to as the C-suite.

These are senior executives like the chief executive officer, the chief financial officer, the chief information officer, and the chief security officer. And they tend to focus their decisions on business needs rather than thinking about information system security. Now, while some of these folks may have limited knowledge or concern for security, they do hold a very large portion of the vote because they control the budgets. Now, it's our job as security professionals to influence these people into caring about security enough for them to adequately supply a security budget for us to use in providing our services. The final influence that we need to cover is called deep parameterization. When I first started working in the information security field over 25 years ago, we placed a big emphasis on the security of our network at the perimeter. Now, as we looked at the border, we said, "If I can control what comes in and out of my networks, I can secure my network." For this reason, we put up firewalls and other security measures at the network boundaries and our gateways.

These perimeter-based techniques are no longer sufficient because a lot of our networks have evolved and our perimeters aren't as well defined as they used to be. This is because we have things like telecommuting, mobile devices, bring your own device policies, the cloud, and outsourcing. This constant change in the boundary of our networks is referred to as "deeperimeterization," and it has a major influence on our security policies and the risks we have as we manage and mitigate them. Now, telecommuting continues to rise in popularity, especially since employees can be just as effective at home as they are in their office, especially due to things like virtual private networks. Now, employees can access their work resources from the comfort of their own home by establishing a secure tunnel back into the office network. Yet this introduces numerous security risks to the organization as well, such as what hardware is going to be used and is no longer physically inside the office, secured by things like fences and security guards, as well as the technological challenges of ensuring their software remains up to date with patches and virus definitions.

Mobile devices are also becoming more prominent as well. Whether it's a mobile phone, a smartphone, or a tablet, more devices are being done on the go than ever before. Organizations need to consider how they're going to manage all these mobile devices securely and how they're going to let them connect back into the network, as well as how they're going to protect the data that's stored on these devices when they get stolen. Next, we have BYOD, or bring your own device. And this takes mobile devices a step further when it comes to security risk. Instead of the organization buying, configuring, and securing a device like a smartphone or laptop, they're going to simply let their employees do it. So if we want to bring a laptop into work and plug it into the network, go right ahead. You can do that under BYOD. As you can guess, this brings a lot of challenges to the network operators and defenders. But a lot of organizations are opting to utilizeBYOD because it gives convenience to the employees and a lot of cost savings to the employers because they no longer have to spend money on laptops or smartphones for each and every employee. So you need to ask yourself, how are you going to support all these various types of hardware and software? Remember, we're no longer supporting just a few models of laptops anymore.

Now we have to support every version of Windows, Mac, and Linux that an employee might want to use. This is an operational nightmare. But more importantly, it is a security nightmare too. Now you have to ask yourself how you are going to support all the various types of hardware and software that somebody might connect to your network. Instead of you supporting just a few models, you now have to support every single version of Windows, Mac, and Linux that an employee might want to use and bring on their device. Now, this has become an operational headache, but more importantly for us, it's a security nightmare.

Our employees may or may not be running the proper security tools like firewalls, antivirus, and others to protect our network when they connect their devices to it. If we allow BYOD, we have to think through how it's going to be supported, protected, and managed on an enterprise scale. Now, there are many dangers to BYOD, so be very careful if you start to implement it within your organization. The cloud also continues to move the perimeter of our networks. What used to be in our data centers onsite can now be anywhere across the globe, whether we're using a public, private, hybrid, or community cloud. Each of these extends and changes our perimeter. This must be considered during the analysis of our organization's perimeter when we're evaluating it for security risks. We're further extending our perimeter because our data is not only on our network, but now it's also on our partners network.

And we have to understand how our outsource provider is going to handle our data, how they're going to process our data, and how they're going to receive our data. Often, this is going to be done by connecting our network to theirs, which permanently extends our perimeter. Other times it's going to be on a more temporary basis. Either way, though, we have to understand the risk and liability that we are assuming when we partner up with an outsourcing provider. So, in summary, it's really important to consider all the internal and external influences when you're drafting your security policies because you're attempting to manage and mitigate risk. This includes things like your competitors, your auditors and audit findings, regulators, client requirements, top level management and deeper minimization.

4. Organizational Changes (OBJ 4.2)

In this video, we are going to talk about organizational changes. Our organizational security policy needs to evolve and change over time. The policy is going to be shaped by numerous factors, including the business model, technology, environmental regulations, and emerging risks. We need to consider each of these factors when we develop our security policies. Otherwise, we may get blindsided by new problems that we should have anticipated and mitigated against. Now, while some of these factors, like our organizational business model and the technologies we utilize, may be obvious factors, others, like the environment, are a little bit more complex. Now, when I talk about the environment, I’m not necessarily referring to forests and oceans, but instead to the environment that's internal or external to our organization. Our internal environment refers to the culture of our organization. Some organizations are controlled through a top-down approach in which senior management initiates changes, supports them, and directs those changes to take place within our security programmer and our associated policies.

Other organizations have more of a bottom-up culture, and in this case, the staff is going to create changes and then garner senior management support for them. If we need to create a security policy in this type of organization, it can pose additional challenges during the adoption phase because we have to fight to garner support for the change and get it implemented throughout the organization. On the other hand, when we talk about the external environment, we're referring to the rest of the industry, including our peers and our competitors. The changing landscape of our industry may require changes to our security policies as well. For example, as entire industries shifted their focus and migrated to the cloud, security policies had to be adapted and changed, as did their business models. Many of these factors are interrelated, and they affect each other too. Because of all these constantly changing factors, it's important to review our security policies often and regularly. An annual review is considered best practice for the organizational security policy, an annual review is considered a best practice.

In most industries, If a large change occurs prior to an annual review, then an out-of-cycle review can also occur. An example of this occurs when a new advanced cyberattack method is discovered, because it's going to require us to immediately review our security policy, look at our procedures, and determine how we're going to mitigate against this new threat. Developing a policy is a lot of work, but luckily there are numerous frameworks out there that provide standards from which we can build upon. For example, the International Organization for Standardization, or ISO, and the International Electro technical Commission, IEC, have created the ISO IEC 27,000 series, which provides us with a nice list of standards for us to develop and maintain an information security management system, including a good security policy.

There are dozens of different standards created under the 270 series umbrella, and for the exam, you don't have to memories them all. Instead, just remember that the ISO IEC27,000 series covers many different standards, guidelines, and controls for just about every aspect of good information system security management. Some organizations now have a contractual requirement to become ISO 27,001 compliant. If your organization is one of these, then you may need to conduct a risk assessment or risk analysis to support your compliance. A risk assessment or risk analysis determines a quantitative or qualitative estimate of risk related to a well-defined situation and a recognised threat. Simply put, it's going to be used to identify vulnerabilities and threats, to assess their impact if they were realized, and determine which controls are going to be used to mitigate against them.

Now, there are four main steps to conducting a risk assessment or risk analysis. First, you need to identify the asset and its value. Second, you need to identify vulnerabilities and threats. Third, you need to calculate the probability of the threat being realised and its impact on the business. And fourth, you need to balance the threat impact with the cost of mitigating against it using appropriate countermeasures. We need clear guidance and scoping from senior management before we begin conducting an arisk assessment on everything. What exactly do they want to consider in scope? Most organisations don't have enough time or money to assess everything. So instead, management has to put some left and right boundaries on the process so we know what assets will and will not be considered for our assessment. Remember, without upper management support and approval, the risk assessment is doomed to failure. We really do need some top-down management and oversight for this process to be effective. Next, we have the statement of applicability that's going to be created. This is known as an SOA.

It identifies the controls picked by the organization and explains why those controls are considered appropriate based on the output of the risk assessment. If our organization is trying to gain or maintain ISO 27,001 compliance, remember, it's important to tie each of these selected controls back to the original risk that you identified for mitigation. While it is a best practice to document why certain controls were not selected, it is not a requirement for gaining compliance under the ISO 27,001 certification. In addition to making policy changes, we also need to change our processes and procedures too, because our processes and procedures are the methods used by an organization to implement their security policies.

So your processes are going to be a collection of activities that work together for a specific outcome or goal, such as the delivery of a given service to a customer. Procedures, on the other hand, are a step-by-step list of the policy standards and guidelines as they're being carried out daily in the workplace. These processes and procedures, just like policies, will morph over time and adapt based on the same five factors we discussed earlier: business, technology, the environment, the regulations, and the emerging risks. So what does this look like in the real world? Well, in one of my organizations, we were using the Microsoft Internet Information Services, or IIs, to host all of our websites. All of our policies, procedures, and processes were all developed around this hosting solution.

A few years later, we decided to migrate our websites over to Linux servers running Apache. All of our policies didn't have to change much, but our processes and procedures had to be completely rewritten because setting up new users and websites requires different steps on an Apache solution than it does on an iOS solution. Remember, though, the policy should be developed prior to developing your processes and procedures. Once you have a good security policy in place, it's going to affect the creation of numerous processes and procedures like your change management process, the configuration management process, the network access procedure, the wireless access procedures, the web hosting procedures, and many others.

Study with ExamSnap to prepare for CompTIA CASP Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, CompTIA CASP Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide CompTIA CASP Practice Test Questions & Exam Dumps that are up-to-date.