Big Issue when it comes to IT security are third party agreements, there's more than a high probability that you're going to have to be dealing with third parties for all kinds of different situations. Now, what I want to do in this episode is actually talk about the legal ease, I guess, or the formality of the types of documents that we run into when we're dealing with third parties. It's not my job to tell you exactly what goes into these, but just more of an overview, so that if you come into a situation where you need to work with somebody to share data, or you want to go into business with another entity to make money, you have some idea at least of the type of documents that are out there. So what I'd like to start off with is a business partners agreement. A business partners agreement is the most generic of all the documents we're going to see in this episode.
If two entities want to do business together, they better to come up with some type of agreement, a good BPA is going to include number one, the primary entities who are the partners that are going to be working together. Second is going to be some form of timeframe. And if it is ongoing, then some methodology for dissolution in the future, if necessary. Third will be financial issues, things like for example, how much investment is each partner putting in? How much draw can each partner take depending on profitability, for example, and what type of auditing methodologies are going to take place? Next is management.
If you have partners, what are the functions of those partners? Also, when do we have partner meetings and the type of record keeping to be kept, as well as the location of all partnership records? bps are incredibly common in the private sector pretty much. Anytime you're going to be doing business with another entity. You're going to be setting up a BPA. Now, the other thing we see a lot is I am doing something to work in IT infrastructure, but I need some kind of service.
In particular I need, for example, an ISP. So in that case, I need to work out what's known as a service level agreement. A service level agreement is nothing more than an agreement between me who is getting the service and my service provider. Let's take a look at that. The first thing that any good SLA is going to have is the service to be provided. So if I'm going to be working with an ISP, it will define that I'm hoping to be provided internet at a certain quantity with a certain amount of time.
Second, will be some form of minimum uptime. In some situations, you can actually see a maximum uptime although that is fairly rare with SLA s. The big one is minimum uptime as well as potential penalties. Or discounts for not achieving a minimum uptime. Number three would be some form of response time. If this service is not working, what type of response time does the service provider guarantee to me in order to rectify the situation with response time would be, for example, contacts if I have a problem, who is my direct, ready to pick up the phone contact to deal with this particular issue, and last a start and an end date for this particular service. Now, being a private sector guy, I see a lot of CPAs and SL A's in my life.
However, there's a few other types of documents that I want to talk about that are, well, in my opinion, more governmental. Now, not to say these don't show up in the private sector, but you see them a lot within government entities. Now, the first one I want to talk about is called the interconnection security agreement or an ESA now the ISO has been around for a while but you really Got its big name from a very famous document called the NIS t 847. So this document really worked hard to quantify how to government entities in particular, United States, federal government entities can make data interconnections in a safe and secure way. So let's run through an ISO. The first part of any essay is going to be the statement of requirements.
Basically, we're asking two questions here number one, why are we interconnecting so from 10,000 feet? What is the motivation for this interconnection? Second, we define what systems are interconnecting. We don't just say what two organizations we're usually talking about one data center and a particular office type of description. Second, are going to be what NIS t calls system security considerations. So basically, They're asking a lot of questions here, exactly what information is going to be interconnected here?
Which direction? Is this information going to go? Does it go one way? Does it go both directions? Third, what services are going to be involved? Is this an HTTP connection?
Is this email? What exactly is the service that's being used here. And then fourth is going to be whatever authentication, authorization or encryption methodologies are going to be done to make that connection. Next, you're going to have some type of topological drawing. Now, what I mean by this is we have some sort of technical drawing that's going to show the actual connection locations, endpoints, IP addresses, CSU DSU, whatever you need to technically define how that's going to work. Last NIS t calls a signature authority.
Now really, what they're talking about here is a timeframe for this interconnection, as well as scheduling technical reviews and security reviews for that interconnection itself. Now if there's one thing I wanted you to notice was we were going through that is a is that it didn't talk about who's in charge or how much this is costing, or what if we have a legal issue. That's not the job of an ISO, the ISO is a technical document. So most of the time, especially when you're dealing with public entities that are trying to work together, most essays are reinforced with something we call a memorandum of understanding, or also known as a memorandum of agreement. And MLU or an mo a is not a contract, but it's pretty close to a contract, especially when you're talking about two public agencies that otherwise would have no formal legal methodology of dealing with each other.
However, it does look like a contract. For example, you'll have things like the purpose of the interconnection, why are these to different entities, making some form of third party agreement to interconnect whatever they might want to interconnect. Number two, you're going to have relevant authorities who are the people in charge on either end of this, who would be the people to speak for this particular not a contract. Number three, it will specify the responsibilities of both organizations, for example, downtime, responsibilities for billing, any legal issues that come out as a side issue this, it clearly defines what responsibility goes to what organization. Last it's going to define the terms of the agreement. For example, costs, if this entire mru is based on a leased line, who's going to be paying for it, how will the billing be handled?
And then last, like all good, not contracts, there will be stipulations for terminating or reauthorizing the interconnection on an as needed basis. I know a lot of these third party agreements start to come off like a bit of an alphabet soup, but the exam really does stress these, make sure you're familiar with the four different types of third party agreements we've talked about in this episode, and make sure you're clear as to the function of each one of those four