A big issue when it comes to I.T. 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 fees 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 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.
BP aides are incredibly common in the private sector pretty much any time 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 I.T. 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 us is the big one is minimal 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 BPA is an SL 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 I'm 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 essay.
Now the essay has been around for a while but you really got its big name from a very famous document
called the NIST 800 dash 47.
So this document really worked hard to quantify how two 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 essay
The first part of any essay is going to be the statement of requirements basically that we're asking
two questions here.
Number one why are we interconnecting so from 10000 feet.
What is the motivation for this interconnection.
Second we define what systems are interconnected.
We don't just say what two organizations we're usually talking about one data center and a tickler office
type of description.
Second are going to be what NIST 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 HDTV connection.
Is this e-mail.
What exactly is the service that's being used here.
And then fourth is going to be whatever authentication authorization or encryption methodology is are
going to be done to make that connection.
Next you're going to have some type of top alogical drawing.
Now what I mean by this is we have some torrent of technical drawing that's going to show the actual
connection locations and points IP addresses CSU D.S. use whatever you need to technically define how
that's going to work.
Last NIST 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 I say 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 NASA.
The essay is a technical document.
So most of the time expressly 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 M-O you or an M.O. A is not a contract.
But it's pretty close to a contract expressly 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 aren't these two 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 of
this.
It clearly defines what responsibility goes to what organization last it's going to define the terms
of the ingredient.
For example costs if this entire amélia 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 re-authorizing
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.