Vendor Risk (Domain 4)

5. Shared Responsibility Model (OBJ 4.2)

In this video, we're going to talk about the shared responsibility model, which is extremely important to understand, especially if you're using cloud-based business models within your organization. A shared responsibility model is a cloudsecurity framework that dictates the security obligations of a cloud computing provider and its clients. This way, you can ensure accountability. So if you're an organisation that has decided to useAWS, Azure, or Google Cloud, you need to know that there are certain roles and responsibilities that are going to be performed by Amazon, Microsoft, or Google, depending on which of those cloud offerings you chose. Now the other roles and responsibilities are going to be left up to you, the client, to be able to perform. Let's start by looking at the roles and responsibilities of the cloud service provider, who is known as the CSP.

Now, the CSP is going to be responsible for protecting the infrastructure that runs all the services offered in their service catalog. This includes the backend hardware, software, networking, and facilities that are all built to support the cloud services. The client, on the other hand, is responsible for varying levels of configuration depending on the level of service chosen, the management of the client's data, including how you're going to encrypt it, classifying your data and your assets, and using proper access management tools to apply the appropriate permissions to the resources that are going to be used by your organization. In general, anything that you can configure or manage the physical underlying hardware, it's going to be left up to the cloud service provider. But anything else, the configuration, security, permissions, and auditing, is going to be left up to the client to perform.

Under the shared responsibility model, there are inherited controls, shared controls, and customer or client-specific controls. Inherited controls are the ones that are fully controlled and managed by the cloud service provider. Basically, if the control is focused on physical or environmental conditions, it's going to be the responsibility of the cloud service provider. For example, making sure the data centre maintains the proper temperature or that there are backup batteries and generators. All of that is going to be the responsibility of the cloud service provider. With shared controls, these are going to be the ones that apply to both the infrastructure layer and the customer layers. Now, these controls may be performed by the cloud service provider or the client. It depends on your use case for these controls. The cloud service provider may create a method for the client to configure the controls by themselves and then apply them to the services they're buying. Let me give you a good example of shared control, something like patch management. Now, the cloud service provider is going to be responsible for patching and securing the underlying infrastructure, such as the hypervisors on the physical hosts. But you, as the client, are going to be responsible for patching your guest operating systems and the applications you're putting on those hosts as part of the virtualized hosts on the physical servers. Another example of a shared control is awareness and security training. While the cloud service provider must train their own staff, the client is going to be responsible for training their own staff as well.

This way, both parties will provide awareness and training, resulting in shared control. The third type we have is customer or client specific controls, and these are the controls that are solely the responsibility of the client. These controls are based on the specific applications and services that the client is purchasing from the cloud service provider, and therefore the client has to configure and secure them themselves. For example, if I'm using Amazon Web Services as my cloud provider, I'm going to be responsible as a client to provide service and communication protection and zone security by ensuring my data is being routed to the proper datacenters based on my specific security requirements. I would then configure this using AWS services based on the configurations I chose to apply. So in summary, when you look at the breakdown of the roles and responsibilities for a particular cloud service provider, in this example, I'm showing you Amazon Web Services. You can clearly see who's responsible for which functions.

If we're dealing with geographic locations such as regions, availability zones, and edge locations and their physical support, this is going to be the responsibility of the cloud service provider. If we're dealing with the hardware and infrastructure, this is also the cloud service provider's responsibility. As we move up the tech stack, we get compute storage, databases, and networking, and all of this is still the responsibility of the cloud service provider. Based on this diagram, you can also see that software is considered part of AWS responsibilities. But be careful here because we're talking about specific software. The software we're referring to here is not softwareinstalled by the client, but it's the software that's already installed by Amazon under a SaaS model. Now, in terms of client responsibility, the client has to actively protect their data, and they have to do this by configuring and using encryption. They're going to be responsible for installing, patching, and configuring their own operating systems if they're using computer services like EC Two within AWS. Any applications or data installed by the customer are also their responsibility, as well as access management, permissions, and identity management. So, as you can see, the closer we get to the end user functionality, the more and more of these things become the responsibility of the client. And in most cases, that's our organisation and our IT staff.

6. Viability and Support (OBJ 4.2)

In this video, we're going to talk about viability and support. After all, when you decide to use a vendor or supplier, you need to be thinking long term as well as what they're offering you in the short term. If you don't, you're going to be accepting a large amount of risk, even without considering the cost associated with that risk. This all comes down to the vendors' viability, their long-term capacity to support your needs, and issues surrounding vendor lock-in and vendor lockout. First, let's consider the vendor's viability. After all, nobody wants to wake up one day, drive to the office, and find out the vendor who is responsible for doing a key portion of their IT infrastructure has simply gone out of business.

Viability is defined as the ability to work successfully. When we talk about vendor viability, we want to ensure that the vendor we're selecting will be around for a long time. After all, the average lifecycle of an IT investment for an enterprise organization is around nine years. So if I'm going to hire somebody to design and develop an entire backend system to run my company, I need to ensure that the company is going to be around for at least ten plus years. Otherwise, I'm going to be in trouble.

There is nothing worse than having a system that needs to be supported. But the company that sold it to you is now out of business. At this point, that system you're depending upon is now orphaned. There are no more patches, no more updates, and no more support. That is a horrible place to be an information security professional, because every day that goes by, that orphan software becomes more and more risky for your organization, both from a business standpoint and from a security standpoint.

So if you're hiring a supplier to build some kind of custom application for you, what should you do to ensure you always have access to the source code and that you can continue to work with another developer in the event that your chosen vendor goes out of business? You can use a source code escrow, which is essentially a source code. Escrow will deposit the source code of the software with a third-party Escrow agent. That third party is going to hold on to the source code, and they're not going to let you access it unless and until that software developer goes bankrupt or they otherwise fail to maintain and update the software as promised in their software user license. This way, the software developer is protected because you can't access the code while they're still in business. But you're also protected because if they go out of business, you can hire somebody else to take over the development and support of the original product if that vendor goes to punt. So when you're considering vendor viability as part of your selection process, you need to consider the combination of the vendor's inherent riskiness and the firm's tolerance for supplier-related risk.

As we look into risk associated with vendor viability, There are going to be two main categories that we need to consider: financial risk and strategic risk. Financial risk is assessed through simple analysis of the vendor's financial statements or their company's financials. This is a quantitative assessment. It's all about dollars and cents. Let's say, for example, I work for a large car company. Now, I want to select a company to create an embedded system for a new self-driving car that we want to develop. We're going to release this car in three years. Would I feel comfortable choosing a small, local startup? They have one to $2 million in the bank and they're spending $500,000 a month on payroll? No, because the chances are they're going to go bankrupt long before they deliver me a system in the next two years. So we have to consider these things when we think about vendor viability. The second type of risk associated with vendor viability is called strategic risk. Now, strategic risk is focused on the strategic viability of the vendor you're considering. This is a more qualitative assessment of the potential vendor. For example, is this company likely to be part of a merger or acquisition in the next few years? If so, that could be a good thing or it could be a bad thing. Because if they're acquired, it could be because a different company wants their technology and won't allow others to use it anymore. Let’s say, for example, you go and find that little start-up that was designing embedded systems for self-driving cars.

Now, if they have great technology, you might want to license it for use in your cars. But General Motors went and bought that company, and they decided no other car company could use those embedded systems except GM vehicles. That would be a huge strategic risk that you would be realizing, because that company you were relying on now got bought out. Another great example of this type of risk actually occurred with Netflix. Netflix used to have a license to stream Marvel and Star Wars movies, but Disney acquired both those brands over the past few years. So when the contract came up for renewal with Netflix, Disney refused to license those movies over to Netflix. Why? Well, Disney was going to be launching a service called Disney Plus, and they wanted big name franchises to only be found in one place for streaming on Disney Plus, not Netflix. So by relying on a third party vendor for their content, in this case Star Wars and Marvel movies, they were assuming a risk to their business operations. As they found out, having that as your only business model for the long term would not be viable. So they also started making their own studios and having their own TV shows and movies created exclusively for Netflix to prevent this kind of risk in the future. Another consideration you need to think about with vendors is a vendor lock in or vendor lockout. A client's vendor lock-in occurs when a client becomes dependent on a vendor's products or services and they're unable to switch to another vendor without substantial switching costs. Essentially, with vendor lock in, the supplier or vendor is trying to create a barrier to entry for smaller companies, and they prevent their customers from switching to a lower cost provider due to the higher upfront cost to switch. For example, my corporate cloud-based shared over 30 terabytes of data.

Let's assume I'm paying $100 a month for the service and a different cloud service provider. Let's say Amazon Web Services says, "Hey, we'll let you come over and give you $50 per month for the next 24 months if you switch to us." Well, that sounds like a pretty good deal, right? It's 50% off of my current costs. But that isn't the whole story. My current vendor might have a bandwidth pricing strategy that disincentives me from moving. For example, the Azure Cloud service provides free data when it goes into Azure from any other provider. But when you're ready to leave Azure, they're going to charge you about six cents per gigabyte. So for my 30 terabytes of data, it would cost me over $800 to get out of Azure and into AWS. So since I'd only save $50 per month for 24 months, I would actually spend more money this way because I would be spending $1800 upfront to get out of Azure, and I'd only save $1200 over the next 24 months by being with AWS.

Therefore, it would actually cost me an extra $600 to move away from Azure and into AWS. This is an example of a price-based vendor lock in. Another example of vendor locking occurs when technology becomes so embedded in your organization that, regardless of the price, people are not willing to switch away. For example, most offices rely heavily on Microsoft Windows and Microsoft Office, creating a virtual vendor lock-in for their IT staff. Even if the IT staff wanted to suggest a freeware product like Linux with OpenOffice, there would be so much resistance because the culture has created this lock in because everyone uses Microsoft. The reason vendor lock in is so dangerous to your organization is that you can essentially be held hostage, for lack of a better term, by your previous vendor. Now, let me give you an example here. Many software as a service products use this vendor lock-in to their advantage. Many of them give you a free trial, right? Well, in one large organization I worked at, we had a company give us a one-year free trial of their product. That's right, an entire year. And this wasn't a cheap product. Our staff loved using this product, and they liked it so much that they started putting tremendous pressure on the executives to buy it for us for the long term. The cost is $1 million per year. That's right.

This was a great way for that company to try to get people to use their product, fall in love with it, and then experience that lock in. I've worked with many SaaS products over the years, and they do a great job of migrating people into their products, but they make it truly awful for you to try and get your data back out when you want to move to a competitor. This is yet another form of vendor lock in’s before selecting a vendor, make sure you think about data transfer risk, application transfer risk, infrastructure transfer risk, and human resource knowledge risk to prevent vendor lock in. To prevent data transfer risks, you should use common standards instead of proprietary versions of software whenever possible. You also need to look at the costs associated with bringing data into the platform, as well as the cost of taking data out of the platform. To prevent application transfer risk, you need to ensure that whatever application you're developing can be deployed not just on Azure or AWS or Google Cloud, but all three of them. For example, all three support Python and Nodes, but Azure supports F Sharp, and Azure doesn't support Go or Ruby, but AWS and Google Cloud support both of those. So pick a language that works across all three platforms. Personally, I use Nodes for everything we develop in our company.

Now, to prevent infrastructure transfer risk, you need to ensure that your virtual machine formats are supported by multiple vendors as well. Some providers will have a proprietary format that supports some additional features, but those features may very well put you at the risk of vendor lock in’s make sure you're careful and do your homework in advance. To prevent human resource knowledge risk, you need to be careful about developing your human capital to be able to support multiple cloud offerings. For example, if our entire systems are built on AWS and my staff only knows how to do AWS, I can't easily move to Azure or Google Cloud because my human resources are now vendor locked into the AWS environment based on their skills and their competency. Now, being locked into a large vendor like AWS may not be a horrible thing because they have extensive vendor viability, but you are going to be subject to whatever cost hikes they decide to do over the coming decades because you're locked into them. These same concepts, though, do apply to smaller vendors too, and they can lock you in. So consider these four risks before selecting your vendor: Now, vendor locking can be a problem, but as long as you can continue to pay, you will still have access to your data.

Now, a bigger problem is vendor lockout. A vendor lockout occurs when you lose access to your data because the cloud provider has ceased operation. Now, let's say you decide to save some money and buy your cloud services from Dion's Discount Cloud US. Now, you are amazed at how low these prices were. They offer your lifetime access to store up to 100 terabytes of data for a single one-time payment of $99. Whoa, what a deal. You upload all of your data to the cloud, and about twelve months later, you realize you can't access your data. You go to log in and you get an error. The page could not be found. Uh oh, what happened? Where is your data? Well, this is essentially a vendor lockout. Essentially, this company went out of business because they didn't have a sustainable business model. This is why looking at the viability of a company is really important, just like we talked about at the beginning of this video. Now, usually a vendor lockout won't occur this fast, but instead they'll give you a month or two's notice that they're going to be shutting down, and then they'll give you time to download your data and move it to another provider. Most of the time, there have been some cases where a company essentially shuts down immediately and all the data is gone. So again, vendor lockout is a risk you need to consider as you think through the viability and supportability of your chosen vendor.

7. Dependencies (OBJ 4.2)

In this video, we're going to talk about dependencies and risk. This type of risk occurs when you're developing your own applications or when you're reusing applications from another vendor. For example, in my own company, we use a lot of different pieces of software from different vendors to sell our courses, deliver videos, and support our students. I have a few developers on my team, but the majority of their work is integration and customization, not full scale development from the ground up. So, third-party dependencies are something we are intimately familiar with. When you think of third-party dependencies, these are normally broken down into three separate categories: code, hardware, and modules. In my company, we almost exclusively use third-party dependencies, but we're going to discuss all three in this video.

If you or your vendor are building a piece of software that's going to be publicly accessible, like a web application, you need to pay special attention to the risks associated with these applications. There are almost no applications these days that are written completely by their own developers or vendors. Instead, most developers rely on third-party dependencies like library packages, Java Script, or CSS files. The problem is that even if your code is written extremely well from a security standpoint, if the third party dependencies have a security flaw in them, you just inherited that flaw into your own application, too.

All code is subject to the same types of vulnerabilities. Things like cross-site scripting, cross-site request forgery, quick jacking, injection flaws, and other types of attacks. Now, yes, you can scan and protect your own code from these attacks, but if you're pulling from someone else's library, you are also pulling in their vulnerabilities. For this reason, it's important to keep track of and monitor the common exposures and common vulnerability databases for those third party dependencies you're using in your applications. As the saying goes, a vulnerability in a third-party dependency becomes a vulnerability in your application. Nowhere is this more true than back in 2017 with Equifax, when they suffered a big data breach that exposed the sensitive data of over 140 million American consumers. What was the root cause of their breach? Well, it was a vulnerability in an open source third-party library that was used by Equifax when they developed their web application. The third party code is known as Apache Struts, and the vulnerability described was CVE 20 17 56 38.It was initially disclosed back on March 7, 2017.

By March 9, the Equifax system administrators were informed that they needed to patch their systems. By March 15, the administrators still hadn't patched their applications, and by the time it was too late, the attackers were already in their systems and breaching their systems using this well-documented vulnerability from the CDE. Now, remember, when you or your vendors are using third party dependencies, you are taking responsibility for the code you wrote and the code you didn't write. Next, let's take a look at hardware dependencies. Sometimes there are things in your network that are going to be installed by third party vendors and they take the form of hardware. For example, maybe you hired a vendor to provide your company with an intrusion protection system. To achieve this, they install the Rackmanted Appliance, a piece of hardware that's going to be configured and maintained remotely by this vendor. Well, most of these appliances have a combination of hardware and software that they use to operate. What if the hardware has a vulnerability in it? Who's going to be responsible for this? Well, since it's owned by the vendor, we're going to classify this as a third-party dependency, and they will likely be responsible for patching the firmware and operating this piece of hardware. But we still need to consider it part of our overall risk analysis because it is tied to our network.

One way to do this now is to check the National Vulnerability Database, or NVD. This is used to describe applications, operating systems, and hardware that have known vulnerabilities. So this appliance should be listed here. Also, when we think of hardware, we should be thinking about all the different subcomponents and modules that make up that hardware. For example, if I wanted to build my own appliance to provide IPS services, I would essentially need to build a Rackmanted Linux server with open source software like Snort, and then I'd have to have different modules like Network Interface Cards to properly connect the networktaps into my appliancebased IPS. This creates multiple areas of risk and vulnerabilities that you need to consider, such as the software, the operating system, and the hardware that make up the server, as well as the modules such as the Network Interface Cards. If you're using custom modules that perform specific functions, they often have firmware that contains specific code to run those functions. This is especially true of programmable logic controllers and other SCADA devices. Remember, most organisations don't develop their own modules and hardware, but instead rely on vendors and suppliers to provide components that can be connected to perform the functions we need. This, though, brings risks that must be managed to mitigate when we're adding them to our enterprise networks.

8. Considerations (OBJ 4.2)

In this video, we're going to discuss some considerations that we need to have concerning managing and mitigating vendor risk. First, we're going to discuss some technical considerations, such as technical testing, network segmentation, transmission control, and shared credentials. Then we're going to talk about meeting client requirements such as legal change, management staff turnover, and device and technical configurations. We'll also cover some geographical considerations and support availability, as well as the ongoing use of vendor assessment tools and some incident reporting requirements. First, let's get technical for just a minute. There are lots of different technical considerations that you need to think about in terms of working with your vendors.

Whenever a vendor installs something in your network, whether it's a piece of software, hardware, or even a small configuration change, you need to ensure you have it technically tested in place to determine if it was installed properly and if it may have created additional risk in your network. Technical testing is used to conduct unit level testing, performance testing, robustness testing, and vulnerability testing. For example, if a cloud service provider claims they can handle network loads of up to 1,000 simultaneous users, you want to validate those claims by conducting robustness testing using load testing. On the other hand, if you just received a new piece of software from a vendor, you might want to conduct a vulnerability scan against it to understand the risks associated with it prior to installing it on your network. These days, it is quite common to find vendors and suppliers that want to directly tie their networks into yours. For example, you may be outsourcing your customer service to another company, but they need to connect their system to yours to be able to access your databases and see your customers' purchase histories. Well, this connection adds a risk to your network, and it has to be considered.

Additionally, you may want to look at how you're going to add segmentation into the network to provide some added defences here. Back in 2014, for example, hackers were able to gain access to Target's point of sale systems because the store's HVAC vendor was connected to their network without proper segmentation. After all, why should the air conditioning system be on the same network as the point of sale systems that handle your credit card processing? That was a risky move and one that ended up very badly for Target. Now, another consideration that's technical in nature is transmission control. Transmission control involves electronic mechanisms that collect and process signals within your network. So are you going to rely on fiber,copper, or wireless as your transmission control? If you're using fiber, you're going to have additional costs involved, but it's not subject to electromagnetic interference or electromagnetic interception. With copper, you're going to save some money, but EMI becomes a concern. With wireless, there are no significant infrastructure costs because there's no cabling involved, but there's a huge risk of radio frequency interception and eavesdropping. So you need to weigh the risks involved with the transmission control method that your organisation wants to use. Fourth, we have shared credentials. This is another huge red flag and a major risk. Shared credentials occur when the same username and password are shared between the vendor and the client.

Studies have shown that over 42% of people share their work logging credentials to work with other people on team projects or other thirdparty vendors to get work done. Also, 81% of data breaches have been traced back to poor password security practices. For this reason, it's highly recommended that both the employees and the vendors use their own passwords when they access the system. Additionally, if there's an issue, you need to be able to know who caused the issue based on the credentials used by that vendor or employee, as opposed to everyone pointing their fingers at each other. Another set of considerations we have to think about is our vendor's ability to meet client requirements, such as our legal requirements, change management requirements, staff turnover requirements, and device and technical configuration requirements. As part of vendor risk management, it's really important to identify your customers' requirements, and in this case, your organization is the customer, and you need to use those as the basis for your risk assessment as you begin to work with the new vendor. To ensure a vendor performs at the levels agreed upon, it’s important to have a legal contract in place. This will ensure the vendor knows what's expected of them, and the contract will usually contain penalties for failing to comply with those roles and responsibilities. Second, you should ensure that you have clearly identified how the change management process is going to work with that vendor. Is the vendor allowed to push updates at anytime, or do they need to coordinate them? First, will the vendor be responsible for problems that occur when the change is implemented, or is that the responsibility of the client or customer? These are the types of things that must be considered when working with a third party vendor instead of using your own in-house IT staff.

If you're having embedded contractors, who are technically vendors, you need to ensure both you and they understand what their roles and responsibilities are when it comes to change management. Third, we have staff turnover. This is especially important if you're working on a long-term fee for service type of contract. In one organisation I worked in, we had 40 people who were embedded as contractors into my IT staff. The contract company is responsible for the hiring and placing of these 40 people, but they did it based on job descriptions that we provided. The company received a payment for every person that worked there, and then, in turn, they paid these contractors. Now, if they only had 35 of the 40 positions filled, they were only paid for 35 roles. I know that sounds good, but the problem is I need all 40 roles, so I'm now operating without the people I need because they didn't hire a person in time. This is something that only a contractor could fix for me. I couldn't hire those people because we had a contracting place, and when the contractor hired somebody, it might take them two to six weeks before they were actually sitting at a desk in my offices doing meaningful work. So you need to think through how staff turnover is going to occur, and in that way you can prevent a loss of human capital. Other vendor contracts may be based on a level of service. I had one contract for a service desk that used to be based on the number of roles,such as 15 people providing 24/7 support.

Over time, that contract got renegotiated by our business side to save some money, and they decided to focus on a service level agreement instead. Something like 95% of all service calls have to be answered and solved within five minutes. Well, this allowed the vendor to determine exactly how many people they needed to do that job, and quickly we saw that we lost six people, bringing us down to nine support agents instead of 15. This led to slower resolution times overall, but still within the five minute SLA. So the vendor was well within their rights to reduce the staff count from 15 to nine people to save money on their end. These are some of the risks you need to think about when negotiating contracts or relying on outside vendors. Fourth, we need to talk about devices and technical configurations. When you're thinking about your devices, who's responsible for the device and its configuration? Is this something your vendor is responsible for? How about the security of the device? What about the operational and maintenance functions? Who's doing which thing? Well, this depends on your contract, and you need to ensure your contracts are written to provide the support you need and expect to meet the requirements you have as the client. Next, we need to talk about geographical considerations when we're choosing a vendor. Geography does matter. When you select a vendor, are you going to choose somebody in the same state or country as your organization?

If so, this can simplify things because you are both subject to the same set of laws and regulations. If not, you need to consider things like international laws, regulations, data sovereignty, cultural differences between organizations, and things like time zones, currency differences, and so much more. For example, one of our software suppliers is located in Australia for one of our underlying SaaS products. Now, most of the time, this isn't an issue for us, but sometimes I need support and I can't get a hold of anybody. This is because they only do support from 06:00 a.m. to 06:00 p.m. Australia time. But if I'm having an issue at 11:00 a.m. Puerto Rico time, it's 01:00 a.m. In Australia, So they're not going to answer my call. Another key consideration is your support availability. Does the vendor provide 24/7 support, or is it only available during normal business hours? Now, this is something we struggle with. In my own company, for example, we have students who are located all over the world, but we're a relatively small team.

I've split my team across two time zones, locating them in Puerto Rico and the Philippines to better serve our students and cover more of each day. But we're still not 24/7. In fact, we advertise our support time as Monday through Friday, nine to five Eastern Standard Time. So if you email my support team, you're going to get back an automated response telling you that those areour hours and you can expect to receive answers as soon as we can get to you. But every day we have some student located somewhere in the world that's emailing us at 01:00 A.M. Our time, and again at 02:00 A.M. and again at 03:00 a.m. Why aren't we answering their questions? Well, like most things in life, it comes down to cost. For us to provide 24/7 support with an average resolution time of under five minutes, it would cost hundreds of thousands of dollars per year. And we're a small company. We can't afford to do that. If we wanted to do that, we would have to increase the cost of our courses by a lot. We decided that most of our students would rather pay nothing for the course and instead wait up to 24 hours to get responses to their emails. This is an organisational risk versus reward decision that we had to make, and some students may not agree with it. If instant support is something you require, then guess what? I'm probably not the right vendor for you. But if you want a great course at a lower price, we're here for you.

The same holds true with the vendors that we hire. Do you really need to require 24/7 support? Do you need just Monday to Friday during regular business hours? These things matter because by not having 24/7 support, you're assuming some risk and some delay in getting a response when something goes down. But you're also paying a lot less than you would otherwise. Another consideration is how are you going to judge and assess your vendors? This is a form of continuous monitoring and an important thing to think about when you're doing outsourcing services. For example, the service desk I mentioned earlier that we outsourced to gave us a monthly assessment. At the end of every month, we received a report using the vendor's assessment tool that showed how many trouble calls they got, what the response time was, and a score that the end user gave them on a one to five scale, indicating whether they were happy or not with the service. By using this ongoing tool, we could quantitatively see if the vendor was meeting the requirements for our contract, and then we could tell if we were going to continue with them when it came time for contract renewal. Finally, let's talk for a moment about incident reporting requirements.

If you outsource the service to an advertiser, what are their requirements in terms of reporting an incident to you? This again depends on your contracts and your requirements. To minimise your risk, you should require all vendors to report incidents to you. A best practise is to create a formalised process and incident report form for your vendors to utilize, so they can provide you with all the details you need in order to make a response decision. This should include things like what the incident was, any indicators of compromise, what the incident confirmed, when it occurred, who was notified, and other pertinent facts. Now, I know we covered a lot in this lesson, but we really only scratched the surface in terms of considerations. This is why it's important for you to gain experience in the business and cybersecurity worlds as you rise to higher and higher levels of technical leadership and management in your career.

9. Supply Chain (OBJ 4.2)

In this video we're going to talk about the supply chain and specifically how to assess your vendor supply chain to increase your visibility in it and why it's so important. When you think about the supply chain, you have to think about all the components that go into a particular product. So, for example, when I buy something off the shelf and I get something like a router or switch, there are hundreds of different pieces inside, and each of those pieces could have been tampered with by somebody along the way. Now, by conducting a supply chain assessment, you're going to be able to understand where all those parts come from and if you can trust that end product. Now I'm not saying you need to go down to the individual component here, but you do have to understand where you get the devices from that you're going to be putting on your network and if you can trust them. After all, we're trying to conduct secure work within an insecure environment like the Internet.

So we need to be able to mitigate the risks that are caused by the vendors in our supply chain. To create a trusted environment, an organisation really has to ensure the operation of every element. This includes the hardware, the firmware, the drivers, the operating system, and the applications and ensures they're all consistent and tamper resistant. If you can do that, you're going to create a trusted computing environment. Now, in some organizations, this is really, really important; in others, it's not nearly as important. And so this is going to be one of those areas where your risk appetite as an organisation is really going to define how much time, effort, and resources you're going to devote to the concept of a supply chain assessment. When you're trying to select a new vendor, you should conduct due diligence. Remember, due diligence is a legal principle that says the subject has used best practice or reasonable care when setting up, configuring, and maintaining a system. When you're trying to hire a vendor, you need to ensure they have done their due diligence on their supply chain, and then you're going to do your due diligence on that particular vendor.

This includes things like ensuring their cybersecurity programme is properly resourced and you also want to make sure they have their security assurance and risk management processes and programmes in place. By doing this, it will help make sure they have a vowed organisational process and ways of doing due diligence within their own organisation as well. Another thing you want to look at is the product support lifecycle. If you're going to buy a product, you need to make sure they're going to be available to support it for the long term. This goes back to vendor viability. For example, if you buy Microsoft Windows, you know they're going to be able to give you patches and updates and support for a certain amount of time. They have this as an end of life day, and they tell you up front that that's part of the product support lifecycle. Do you even know if you're going to be around in five years if you buy a product from a brand new company, do you even know they’re going to be around in five years?

When you have a problem and you need to solve it, this is the type of thing you need to think about as part of your due diligence. Another thing to consider is whether they have the proper security controls in place for their confidential data. If you're giving them access to your data because they're a software as a service provider, then you need to make sure they have the proper security controls in place to ensure your data remains confidential. And if something goes wrong, will they be there to help you? This idea of supportability is an important consideration as part of your supply chain assessment. If you have to conduct an incident response or a forensic investigation, will that company be able to support you and provide you with assistance? Finally, you need to think about general historic information about this vendor when you're conducting your supply chain assessment. When you look at a company, do they have a strong financial statement? Are they going to be in business next year to support your needs? Or are they a fly-by-night organization, and they'll be out of business in the next six months?

These are all things you need to consider as you're doing your due diligence. Your due diligence should now not only apply to your suppliers but also to your contractors. If I'm going to hire people to work on my team as contractors, I need to do due diligence on them to make sure I can trust them. The last thing we need to talk about in terms of the supply chain assessment is the hardware itself. Now, we mentioned earlier, you have to think about where the hardware comes from, and then based on your organization, you're either going to have more or less of a risk appetite for that hardware. For example, one of the organisations that has a very low tolerance or low risk appetite for hardware is the Department of Defense. So they created something known as the Trusted Foundry. The Trusted Foundry is a microprocessor manufacturing utility that's part of the validated supplychain, one where the hardware and software do not deviate from their documented functions. And again, this was created and operated by the Department of Defense, which is the US Military. Because if they're going to put a microprocessor on a jet or a bomb or something like that, they need to make sure it does exactly what it's supposed to do each and every time and nothing else. That's what the Trusted Foundry programme is all about. Another piece of the supply chainassessment that we consider in regards to hardware is the source authenticity.

This is a process of ensuring the hardware is procured tamper-free from trustworthy suppliers. Now, the idea here is that when you go and get something, you need to know where your stuff comes from. So if you need a new router, do you buy it directly from Cisco or from one of the authorised resellers, or are you going to go on eBay and buy a second-hand one? Well, depending on which way you procure this router, it's going to be more or less trustworthy. There is a much greater risk of inadvertentlyobtaining counterfeit or compromised devices if you're buying them from secondhand stores or aftermarket sources. So whenever possible, go straight to the source. In this example, go to Cisco. After all, when I look at these routers and switches, just by looking at them, I can't tell if they've been modified on the inside by having additional modules or rooted firmware installed. This is something that can be done inside of those machines, and it can go undetected for a long period of time. There have been many cases where malware has been embedded into the firmware of these devices or put on extra chips inside of these devices for months or years before they were discovered. All during that time, these devices could have been spying on the users of your network and sending back information to an attacker. So you need to be careful with this stuff, and you have to get visibility into your supply chains by conducting these supply chain assessments on your vendors. So do you have to do one for every single vendor? Well, no, but you should determine where your risk tolerance lies. And anyone above that level of risk should be subject to a supply chain assessment as part of your procurement process to protect the security of your network.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap CompTIA Advanced Security Practitioner (CASP+) CAS-004 certification video training course that goes in line with the corresponding CompTIA CAS-004 exam dumps, study guide, and practice test questions & answers.