all right. The next element of security operations is looking at third party governments. And we're in the environment today where almost every organization outsources something. Whether we have vendors help us with application development or we need to
bring in additional programmers
because of shortage of staff or we bring in network engineers or we simply outsource certain service is to the cloud.
All of that falls under the category of third party. And if we're going to manage our third party access predictably and well, then we need governance in place.
So we do talk about these third party providers. Really? It's anything that were outsourcing. Whoever provides those service is that would fall under the category of 1/3 party provider. So we want to make sure that we understand a really important principle,
and you might just jot it down. I'm gonna say this very specifically.
Though you can transfer risk,
you cannot transfer liability or responsibility.
Can you say that again? You can transfer risk,
but you cannot transfer responsibility
Here's what I mean by that.
If I outsource something my dabba to a cloud service provider, okay, they're going to store my information,
all right, and that cloud service provider has a compromise.
I am ultimately responsible for the security of information that's under my ownership. As you know, a controller, for instance, the cloud service provider may have violated their service level agreement, and I may have legal recourse.
But as far as the responsibility for data protection, it's still me,
right? Just cause I hand off my dad, someone else doesn't alleviate my responsibility. If I'm a health care provider
and I collect information on patients and I stored at 1/3 party
whether or not that third party has a compromise, I'm still liable for that information under HIPPA.
Now again, it doesn't mean that there's no legal recourse. But as Faras HIPPA goes, or as faras laws and regulations about data protection,
I'm still ultimately liable for that. So I wanna stress now that I give transferring the risk means through the service level agreement, the cloud service provider or the third party provider may be forced to reimburse me,
but by that time I've already been found liable for violation, and ultimately one of my customers know they know that I have lost their data or that I've allowed it to be compromised. So we have to understand the liabilities with third Party.
Um, we have to understand who's responsible for what?
And then if we ourselves or third parties, maybe we're vendors on a project for another organization. What liabilities do we as individuals have a my liable for what my employees do? Maybe, you know, I have to be able to show due care and diligence.
And then what's the limit to that? Is an Internet service provider responsible for what their users do?
Do they have to turn over information on their users that have been found to be, uh, performing, You know, illegal activities through there? I s P service is it gets very, very tricky. So the idea is, How do you know? You know, by due diligence,
you do your research.
You have your service level agreement and make sure that the security requirements for your organization are documented in the S L A.
Now, when you're dealing with third parties, you're gonna have different types of procurement documents. Request for information. Just says, Hey, we're considering doing business with you. Tell us a little bit about your company. When were you formed. Who are your principals?
What's your credit rating? That type of information,
a request for quote says, and eat the service is what we charge me for them. Or usually it's more requests for proposals for doing service is I need 10 Dell computers. What's the charge? So that kind of ties in with maybe a purchase order, right?
A request for proposal says, Don't just give me a cost. Give me your approach in your methodology. So I'm looking to upgrade my existing network infrastructure. I'm gonna send request for proposals to many different vendors. And I'm going to see whose strategy is most in alignment with what our needs are.
Invitation forbid large scale contracts. We bring in vendors. We give them information at a vendor's conference and we asked them to bid on the project.
Now again, contracts are essential to third party governments to contract types that I would know. First of all, a memorandum of agreement and m o a memorandum of agreement. Or you could see it is M. O. U. Memorandum of understanding.
The two are technically different, but I think they'll use them both interchangeably on the exams. A memorandum of agreement. Memory engines of understanding are ultimately documentation
that defines expected responsibilities. So, for instance, if, um,
we're in, you're in a different department.
Or let's say I have an expectation that you'll show up even when the building operations air closed in the event of a disaster to restore backup tapes
that would be documented in an m. O u
ah, lot of times M o user for internal use and m o a. CZ or with external offenders. So I expect a particular vendor to provide gasoline in the event that we have a regional
power outage hurricane, something like that. And these are my expectations. Okay, that's memorandum of agreement or understanding service level agreements also legally binding documents that specify again
what the vendors gonna guarantee Tow us. Usually that's in relation to service or up time.
So you're gonna guarantee me 99.9997% availability. If I host my website on your service or if I buy your prop
so get really the big factor in third party relationships. It's our contracts. Are service level agreements again Legally binding. It transfers risk. It does not transfer responsibilities,
whatever the requirements are. I don't have any assurance other than what exists in the S. L. A