Network policies.

In this section of the course,

we're going to talk about network policies.

When we discuss policies, we're not talking specifically

about technical controls anymore

like adding access control lists to our firewalls or routers

or enabling Mac filtering or even enforcing encryption

and all the other things like that,

that we do to better secure our networks.

No, those are considered technical controls,

and they're not the only way for us to secure our networks.

In fact, there are a lot of network protections

that will come in the form of administrative controls

such as policies.

So when we talk about policies,

remember that policies are one part of a larger concept

known as IT governance.

IT governance is used to provide us

with a comprehensive security management framework

for the organization, and that way we can build upon it.

Now this is done using policies, standards,

baselines, guidelines, and procedures.

Policies are going to be used to define the role of security

inside of an organization

and establishes the desired end state

for that security program.

This is usually going to be provided by senior management

and it's going to clarify

the level in which the organization enforces security

and how the organization will categorize the controls

that are going to be applied.

Policies tend to be very broad

and they provide the basic foundation

upon which standards, baselines, guidelines, and procedures

are going to be built.

Security policies are going to be divided into three levels.

This is organizational, system-specific, and issue-specific.

Organizational security policies

are going to provide direction and goals.

They're going to give you a framework

to meet the business goals

and define the roles, responsibilities, and terms

that are associated with it.

System-specific policies are going to address the security

of a specific technology, application, network,

or computer system.

These system-specific policies

tend to be much more technical

and they focus on protecting a certain piece of the system

or a certain piece of technology.

Issue-specific policies

are built to address a specific security issue,

such as email privacy, employee termination procedures,

and other specific issues.

As we move beyond policies,

we begin to enter the world of standards.

Now, standards are used to implement a policy

within an organization.

These are going to include things like mandatory actions,

steps or rules that are needed

to achieve the desired level of security.

After standards, we have baselines.

And baselines are going to be used to create a reference point

in our network architecture and design.

These baselines are used to document any kind of system

so we can go back later and compare it for analysis

against that baseline.

For example, we may have a baseline configuration

for our network switches,

and we can compare the running configuration on any switch

to our baseline at any time

to see what changes have been made by our administrators

or a possible attacker.

Next, we have guidelines.

Guidelines are not required or mandatory actions,

but instead, they're simply recommended actions.

Guidelines tend to be flexible in nature,

and they allow exceptions and allowances

when a unique situation is going to occur.

For example, let's pretend I have a guideline

that every employee gets one terabyte of storage

on our cloud servers.

That might be fine for most of the people who work here.

Now, our salespeople, and our accountants,

and human resources,

all of those folks

would have no problem fitting all of their documents

into that one terabyte of space

because most of what they do is text files.

Those users will have lots of space here.

But my video editor, she might come up and say,

"Hey, I'm running out of space.

I need at least five terabytes of storage."

Well, based on our storage size limitations,

if they're based on a guideline,

I can make an exception to that

and allow her to have five terabytes

instead of one terabyte,

because it meets the needs of her specific job role

because she's dealing with large video files all day long.

That's the idea of a guideline.

It's something that can be changed on the fly

and an exception can be quickly made.

Next, we have procedures.

Now, procedures are detailed step-by-step instructions

that are created

to ensure personnel can perform a given task

or series of actions.

These procedures are where those high-level policies

are transferred all the way down

through those standards and guidelines into actionable steps

that can be followed by a technician.

For example, your service desk probably has a procedure

on how to create a new user account.

This procedure encompasses

all of the security-related policies,

standards and guidelines to allow your frontline employees

to be able to follow the step-by-step actions

necessary to create a new account

and give that account the proper permissions,

the correct password strength,

and all of those types of things.

For the exam, I want you to remember

all the different types of policies we have

inside of our governance as we work our way down

from the more generic to the more specific.

This includes our policies, our standards, our baselines,

our guidelines, and our procedures.

Now, in this section of the course,

we're going to focus on Domain 3: Network Operations,

specifically in Objective 3.2.

Objective 3.2 states

that you must be able to explain the purpose

of organizational documents and policies.

So let's get started talking

all about the different policies and plans and procedures,

hardening and security policies and common agreements

that you're going to find inside your enterprise networks.

(upbeat music)

Plans and procedures.

In this video, we're going to discuss

the various plans and procedures

that are used in the management of your enterprise networks.

This includes change management, incident response plans,

disaster recovery plans, business continuity plans,

system life cycle,

and standard operating procedures.

First, let's discuss change management.

Change management is a structured way

of changing the state of a computer system,

network, or IT procedure.

Change management is used to make changes to the secure

and known good baseline that exists in our network devices.

A good change management policy

is going to be designed to make sure that all the risks

are considered prior to implementing a change

to your systems or networks.

This ensures that our services remain stable,

reliable, and predictable,

even in the face of rapidly changing business requirements.

Essentially change management is a coordinated system

to account for any upgrades,

installations or network outages and repairs.

For example, let's assume that you need to upgrade a router

or switch in your network,

but you don't want to cause a bunch of unnecessary downtime.

Well, with change management,

we can ensure that all of our actions are pre coordinated

and approved by the relevant stakeholders

prior to us implementing a firmware upgrade.

After all, if I simply ran a firmware upgrade

in the middle of the workday,

I could cause a lot of unnecessary downtime for my end users

because they're relying on those devices

for their network connectivity.

This is because during a firmware upgrade,

that router switch is going to be taken offline

and it won't provide services to our end users

until the firmware has been properly flashed,

and then the configurations are reloaded.

Therefore we need to instead coordinate the firmware upgrade

for the right time so that it would be the least impactful

against our business operations.

For example, at most of my organizations,

we use the period between midnight and 4:00 am

to do our upgrades because

relatively few people are online

and working during those hours.

As you move through your change management process,

you're going to need to ensure

that the upgrade is being planned, approved as a change,

the relevant documentation diagrams are being updated

and our network documentation remains current

after we finish doing the change.

Next, we have incident response plans.

An incident response plan contains a set of instructions

to help our network and system administrators

detect, respond to, and recover

from network security incidents.

These types of plans

are going to address issues like cyber crime, data loss,

and service outages that could threaten our daily work.

Basically what we're doing here

is decide what we're going to do

if there's a security violation

and what are our response actions going to be?

Are we going to take the device off the network and wipe it

and then put it back on?

Are you going to handle it in-house?

Or are you going to fire an employee over it?

Are you going to call the police?

What is your plan going to be?

How are you going to respond?

Now, I don't have these answers for you

because all this is going to depend

on your organization's incident response plan

that you need to create.

When it comes to an incident response plan,

you need to cover six main steps or phases.

First; preparation,

second; identification,

third; containment,

fourth; eradication,

fifth; recovery,

and sixth; lessons learned.

Also, if you're intending to prosecute a computer crime

in conjunction with your incident response,

that's extremely important

that you maintain the chain of custody

over all the data and all the information being collected.

Next, we have disaster recovery plans.

A disaster recovery plan

is a documented structured approach

that documents how an organization

can quickly resume their work after an unplanned incident.

Now, these unplanned incidents

can be things like natural disasters,

power outages, cyber attacks, or other disruptive events.

Now a disaster recovery plan

will outline your processes and procedures

for shifting your operations

from your main headquarter facilities

to your disaster recovery sites,

such as a hot site, a warm site, a cold site,

or a cloud site.

Now remember a disaster recovery plan

is focused on business interruptions

that are caused by a disaster,

but these aren't going to include things

like everyday operational challenges.

For those types of challenges,

we instead need to look at a different type of plan

known as a business continuity plan or BCP.

Now a business continuity plan

is a document that outlines how a business

is going to continue operating

during an unplanned disruption in service.

Now, a business continuity plan is more comprehensive

than a disaster recovery plan,

and it contains contingencies

for lots of different business processes,

your assets, your human capital and business partners,

and essentially every other thing

and aspect that may be affected in your business.

Now, when you're dealing with a disaster recovery plan,

we're focused mainly on your technology and your facilities,

but a business continuity plan is much more in-depth

as it looks at how you're going to continue

all of your business operations.

In general, a disaster recovery plan or DRP

is going to be referenced

as part of your business continuity plan or BCP,

and the two will work very closely together

when you have a real disaster,

like a hurricane, a fire, or a flood that occurs.

Next, we need to consider the system life cycle plans.

System life cycle plans

also known as the life cycle planning

is going to describe the approach that you're going to use

to maintaining an asset

from its creation to its disposal.

Now, in the information technology world,

we normally have a five phase life cycle

that's used for all of our systems and networks.

This includes planning, design,

transition, operations, and retirement.

Phase one is planning.

Planning involves the planning and requirement analysis

for a given system,

including outlining the architecture

and identifying the possible risks.

Phase two is design.

Design is going to involve the outlining

of the new system or network,

including what interconnections there's going to be,

what technologies will be used,

and how it should be implemented.

This can even include some building of the new system

or even a prototype to validate the architecture

that we want to use.

Phase three is transition.

Transition involves the actual implementation,

which could involve coding some new software,

installing the systems,

or cabling up the networks and their configurations.

All of this is going to be a part of taking this asset

and moving it from a prototype or an initial build

into something that's ready for full production and use,

that's why we call it transition.

We're transitioning it into production and use.

Phase four is operations.

Operations is where the system or network

is now going to be used on a daily basis to do productive work.

In general, about 70% of a system's lifecycle

is going to be spent during operations.

Now, operations includes

things like the daily running of the asset,

as well as updating it, patching it,

fixing any issues that may occur and things like that.

This is often referred to as operations and support

because we're going to conduct our break fix actions

during this portion of the asset's life cycle.

Our fifth phase is retirement.

Retirement is the end of the life cycle

and it occurs when the system or network

no longer has any useful life remaining in it.

At this point,

a single device or your entire system or network

could be retired and the assets will be disposed of

as part of this retirement.

For example, if you had a network switch

that's been used for the last five years,

it's probably reaching the end of its useful lifespan.

So it needs to be replaced with a newer model,

and then we're going to retire that old switch.

Before we throw it away though,

it's important for us to think about that device

and how we're going to sanitize it

or clear it of any configurations or sensitive information

using our proper asset disposal procedures too.

Next, we have standard operating procedures.

Everything we spoke about so far

has been at a higher and more generic level,

but a standard operating procedure or SOP

is a set of step-by-step instructions

that are compiled by an organization

to help its employees carry out their routine operations.

Standard operating procedures aim to achieve efficiency,

quality output, and a uniformity of performance

while they reduce misconfigurations

and a failure to comply with regulations.

For example, our disaster recovery plan

might say that within 48 hours

of a named hurricane reaching our city,

we need to ensure that all of our diesel generators

have been refueled.

Now, this is a single one-line statement

from a disaster recovery plan or DRP,

but that statement doesn't tell you how to actually do it.

Instead, you'd pull out the standard operating procedure

named fueling the generators,

and this would tell you how to perform the operation.

So if I was told to refuel the generators,

I could pull out this SOP and follow it step-by-step,

step one; call the fuel company and schedule a delivery,

step two; turn off the generators

and open the storage tanks,

step three; put the diesel into the storage tanks.

You get the idea here, right?

Now, there might be 5 or 10 or 20 steps to this procedures

as part of this SOP,

but in a disaster recovery plan,

it's just one line that says,

you need to do this thing known as refueling the generators.

So remember when it comes to managing your networks,

there are lots of different plans and procedures

that you may come across.

We just covered a few in this lesson

that you may get asked about on the exam,

but in the real world,

there are many others too.

For the exam, remember,

we have change management, incident response plans,

disaster recovery plans, business continuity plans,

system life cycles,

and standard operating procedures,

to help us manage our networks.

Hardening and security policies.

In this video, we're going to talk about

the various hardening and security policies

that are used in securing your enterprise networks.

This includes password policies, acceptable use policies,

bring your own device policies, remote access policies,

onboarding and off-boarding policies, security policies,

and data loss prevention policies.

First, we have password policies.

Now a password policy is a set of rules created

to improve computer security by motivating users

to create dependable, secure passwords,

and then store and utilize them properly.

This document will promote strong passwords

by specifying a minimum password length,

a complexity requirement requiring periodic password changes

and placing limits on the reuse of passwords.

Once you create your password policy,

it's important to educate your end users on the requirements

that are set forth in this policy.

Also, you want to create guidelines and standards

within your organization based on your password policy

and use those to implement the technical controls

that will enforce the requirements set forth

in your password policy.

Next, we have acceptable use policies.

An acceptable use policy or AUP

is a set of rules applied by the owner, creator

or administrator of a network website or service

that restricts the ways in which the network website

or system may be used and sets guidelines

as to how it should be used.

Now, essentially, this is a policy that governs

the use of the company equipment and its internet services

by its employees.

So what kind of things might you find in an AUP?

Well, this is really going to depend on your organization

and its requirements.

At one of the large organizations I used to work for,

they had restrictions that prevented employees

from accessing websites like eBay,

because you shouldn't be buying and selling things

while you're at work.

They also prevented employees from accessing pornography

or gambling websites.

Another organization I worked at restricted,

the use of Facebook while at work,

because they didn't want people spending their time

on social media during the workday.

But like I said,

this is really going to depend on your organization.

In my company, I don't block Facebook

because I want my team members there

because I want them to be in our Facebook group

and interacting with our students

in the Dion training Facebook group.

As you can see, there's really no one size

fits all answer here,

but for the exam, if you start seeing things

that talk about what things an employee can and cannot do,

what they're allowed to do with company equipment

and internet services,

your correct answer should be unacceptable use policy

or AUP.

Next we have bring your own device policies.

Bring your own device or BYOD is going to allow,

or sometimes encourage employees to access enterprise

networks and systems using personal mobile devices,

such as smartphones, tablets, and laptops.

Some organizations are fully embracing a culture

of bringing your own device

while others have rejected it completely

because it does bring up different security risks

that you have to think about.

After all, let's say I'm able to bring my laptop to work

and connect it to your network.

Now, any malware issues I have on my device

are now going to be a part of your network too,

and it can spread.

BYOD also has a lot of challenges with maintaining

a proper configuration baseline too,

because the company doesn't technically own that device

and therefore they can't patch them or upgrade them

automatically using their patch management processes

because the employee owns that device.

Now, on the other hand,

a lot of companies really love BYOD

and this bring your own device policy because it means

they don't have to buy you a laptop or a cell phone

or a tablet because you as an employee are simply going to

bring your own personal device and do your work on it.

This will save the company money in the short term,

but again, there's a lot of security concerns here

you have to worry about.

When the data goes onto that device,

whose data is it?

Is it the company's data or is it the employee's data?

Who has the rights to it?

Where do you draw the line between what personal data

can be on that laptop and what is going to be business data

that has to be properly secured.

These are all things you have to think about, right?

If there's going to be an incident,

can the company take your personal devices as evidence

during the investigation?

Can they require you to reformat and purge

all your information from your smartphone,

including all the pictures of your kids?

That is something you have to think about.

As you can see, there are a lot of questions

that come up when you start using a bring your own device

or BYOD policy.

In general, I recommend against using a BYOB policy

in enterprise networks.

But if you are going to embrace a BYOD policy,

then I suggest you create a segmented network

where your BYOD devices can connect directly to the internet

and then use cloud hosted resources,

instead of going into your local network directly.

Next, we have remote access policies.

Now a remote access policy is a document that outlines

and defines acceptable methods of remotely connecting

to the internal network.

For example, are your employees allowed to be connected

to internal network resources such as your email server

directly over the internet?

Now, in most cases,

you're not going to configure your email server

to allow this to happen because it opens you up

to a whole bunch of vulnerabilities.

Instead, you may choose to enable a web mail server

that sits in a screen sub-net or a DMZ,

and then allow your employees to connect to that,

and it will be used essentially as a jump box

into the exchange server.

Or your remote access policy might decide that you're going to

allow employees to use their corporate laptops,

to connect to the internet over a VPN connection.

This way, they're going to be connecting to your network,

using a trusted device, that corporate laptop using your

standard baseline configuration security protocols,

and they can validate their identity using whatever

authentication and authorization procedures

you have to ensure the security of your network.

This again goes into your remote access policy.

What type of services, whether they're VPNs or other things,

are you going to allow your employees to use?

Again, as you start creating your remote access policy,

it's really going to be based on your risk tolerance

and your operational needs,

and it is going to be dependent on your organization.

Next, we have onboarding and offboarding policies.

Now an onboarding policy is a documented policy

that describes all the requirements

for integrating a new employee into the company

and its cultures, as well as getting

that new hire all the tools and information they need

to be able to do their job successfully.

Now, an offboarding policy is a documented policy

that covers all the steps necessary

to successfully part ways with an employee

following their resignation or termination.

When you do this well, a clear off-boarding process

will ensure a smooth transition for both your company

and the departing employee.

Now a good onboarding and offboarding policy needs to extend

beyond the information technology realm.

But for our purposes, we're focusing really

on the IT side of things.

For example, when somebody is hired,

how is that new employee going to get their account created?

How are they going to be issued a new laptop

or smartphone or tablet?

How are they going to be given access

to different network resources

like the company shared drive?

All of these are things that need to be documented

within the onboarding policy and it's associated procedures.

On the other hand,

when an employee resigns or is terminated,

how are you going to remove them from all their accounts

and accesses?

How long do they have before their accounts can be deleted

once they transfer?

Do you need to archive their data for historical purposes

and record-keeping, or can you delete it all?

Do you need to take back equipment like a laptop

or a smartphone or a tablet?

How are you going to refurbish it so it's ready to be issued

to the next employee who's hired into that position?

All of these are things you need to cover

inside your offboarding policy.

Next, we have security policies.

Now a security policy is a document that outlines

how to protect the organization systems,

networks and data from threats,

including computer security threats,

and how to handle situations when they do occur.

A security policy is going to identify

all of a company's assets as well as the potential threats

to those assets.

Now, in many organizations

there may be a single overarching security policy,

that's going to contain all the other security policies

underneath it.

Things like the AUP, the BYOD,

the password policy, the onboarding policy,

the offboarding policy and many others.

In other organizations, they prefer to break apart

the larger security policy

into smaller individual policies

for use within the organization.

Finally, we have our data loss prevention policy.

Now a data loss prevention policy is a document

that defines how organizations can share and protect data.

It's going to guide how data can be used in decision-making

without it being exposed to anyone

who should not have access to it.

Now, the goal of a data loss prevention policy

is to minimize accidental or malicious data loss.

These policies need to cover the entire network,

not just your file servers or your email servers.

In my organization,

we use a data loss prevention system

based on our organizational DLP policies.

Our DLP system goes through our network

and inspects any data being sent or received.

For example, if our system detects that

a large amount of data is being sent out of our network

to a site like Google drive or Dropbox,

it can create an alert and tell our system administrators

that we need to investigate that.

This way we can look at, what particular employee

was sending, what particular documents

and decide is that legitimate or not.

In some cases, an employee might need to send

a large amount of data, but in others they shouldn't

be sending large data files.

And that may be them trynna steal data from our systems.

For example,

let's say that my DLP system created an alert

because one of my employees was uploading

all the video content from this course

into one of our video servers

or to one of our video distribution partners.

That might be 50, a hundred

or 200 gigabytes of data or more.

I guarantee that our data loss prevention system

is going to flag on that amount of data,

leaving our network from a single user

or a single workstation,

because this is typically an indicator of a compromise

for a data breach or data exfiltration attack.

My DLP will flag this data transfer

and based on our policies,

it may even block this data transfer from occurring.

Now our administrator can review that flagged alert

and look at the content and determine

is this somebody who is stealing from us

or is it someone doing their job

and they have a legitimate reason to do this?

For example, if I have my video editor,

we might see that she just uploaded this brand new course

to one of our distribution partners.

And she did it all in a one day period.

So she had to upload two or 300 gigabytes of data

so we can prepare to publish this course.

That would be fine.

We'd mark the alert as normal and acceptable,

and we'd move on with our day.

But again, this is all going to be dependent

on your data loss prevention policies.

And what's going to trigger inside your company.

In your company, if you had a single person

sending 50 or a hundred gigabytes of data,

that would probably be extremely suspicious in most cases

and needs to be investigated further.

As part of your DLP policy, it's always important

to set proper thresholds.

When is your DLP going to alarm?

What is the amount of data transfer or the file types

that it's going to consider acceptable or out of baseline?

What file formats are you going to be able to transfer?

And which ones are going to be blocked?

Are you going to allow people to transfer database files

or zip files or PowerPoint files?

All of these are things that DLP can block

or alert on depending on how you configure it.

So as you look at all these different things,

you need to define that in your data loss prevention policy.

Now, remember when it comes to securing your networks,

there are lots of different hardening techniques

and security policies that you may come across.

We cover just a few in this lesson

that you may get asked about on the exam,

but in the real world there are tons

of other ones out there.

For the exam, I want you to remember

that we have things like password policies,

acceptable use policies,

bring your own device policies,

remote access policies,

onboarding and offboarding policies,

security policies,

and data loss prevention policies,

and what each one is used for.

Common Agreements.

In this video, we're going to discuss

common types of agreements that are used

in our enterprise networks.

Some common agreements are things

like non-disclosure agreements or NDAs,

a memorandum of understanding or MOU

and a service-level agreement, an SLA.

First we have non-disclosure agreements or NDAs.

Now, a non-disclosure agreement

is a document agreement between two parties

that define what data is considered confidential

and cannot be shared outside of that relationship.

Now, NDAs are often used by organizations

to protect their intellectual property,

and they're either going to be between two different

organizations or between an organization and its employee.

Now, why would an organization require their employee

to sign an NDA?

Well, it's because those NDAs can be a form

of non-competitive clauses inside

of an employment agreement,

or the company might fear that that employee

might take the information

they're learning from the organization

and go off and start their own business

or disclose it to their competitors.

Now, if two organizations are working jointly

on a project system or network,

they can also utilize a non-disclosure agreement.

This allows the companies to share the type of data

they need to in order to develop this product

without fear that the other company is going to steal

their trade secrets.

Keep in mind though, a non-disclosure agreement

is an administrative control not a technical control.

There is nothing in the system that is going to prevent

one of these people from sending data to the others,

if all you have is an NDA,

they only have the word and signature on that piece of paper

that promises not to do it.

Now, if you want to get some technical controls involved

with an NDA, you can do that using a DLP

or data loss prevention system,

but the DLP is the technical control

not the NDA in that case.

An NDA is considered a legally binding agreement

and it carries penalties for breaking the NDA,

including fines, forfeiture of intellectual property rights,

or even jail time in some extreme circumstances.

Next, we need to discuss an MOU

or memorandum of understanding.

A memorandum of understanding is a non-binding agreement

between two or more organizations

to detail what common actions they intend to take.

Essentially, this is a formal version

of a gentleman's agreement,

because it's actually written down and signed

by both parties and it isn't really legally enforceable.

Essentially, this is like a handshake deal,

but slightly more formalized because we wrote it down

and we both signed it.

For example, if you and I both agree

that we were going to go into business together

on a joint project, we could create an MOU

that outlines what things each of us

is going to be responsible for doing.

So, you might say that you're going to do A, B and C

and I'm going to handle X, Y and Z.

We would write that down inside of an MOU,

we could sign it and then at anytime we can look back

on that document, if we have a disagreement in the future

and say, "But Hey, you said you were going to handle item B,

"and I said, I was going to handle item Y."

But if I didn't do item Y, you can't sue me

just because I didn't finish it,

because this agreement is non-binding.

Now, a memorandum of understanding

is often referred to as a letter of intent.

Because again, it's an intent to do something

it's not a requirement to do it.

It's often going to be used within an organization

by two or more smaller internal divisions

because of this non-binding legal status.

So, for example, I used to be the director

of an IT department for a really large organization.

And I was responsible for managing the service desk

as part of my responsibilities.

Now, my service desk provided assistance

to several thousand employees across multiple countries.

There was one critical business unit that wanted to have

at least one tier two service desk agent located

in their specific building at all times

because their building was a little bit further away

than our headquarters was.

Now, this way, if something went offline in the network

that tier two agent didn't have to get in their car

and drive from the headquarters to this branch office,

which was about an hour away,

and that way they could immediately start

the restore process because they're already sitting

in the building.

Now, I thought this was a pretty good idea.

So, we agreed to it and we wrote up an MOU.

The leader of that part of the organization and I

both wrote down what we were going to do.

I said, "I'm going to provide one full-time

"tier two service desk agent and I'm going to have them do

"all their daily functions out of your building."

In return, they said they would provide

my tier two agent with a small office

and a dedicated parking spot.

We both wrote all this up,

we put it in the MOU and we signed it.

This way we were able to minimize the time

to repair for lots of critical issues

that happen at this business unit,

because the guy was already sitting in that building

as a tier two agent.

Now, this wasn't a binding agreement on either of our parts.

At any time I could have said,

"You know what, I think I need Tom to come back

"to the main office and I can't have him sit

"in your office five days a week anymore."

Or "Maybe I need to have Tom work out of the headquarters

"for Mondays and Tuesdays but on Wednesday,

Thursday and Friday he can work in your unit."

Now, the other business unit leader couldn't really complain

because he had no way of forcing me to keep Tom

in that building for all 40 hours every single week,

because we had this MOU, which is non-binding.

Now, this MOU does give us some formality to our agreement

that we had made between the two directors.

This was the director of operations

and myself as the IT director.

But at any time we could modify it or break it

without any serious consequences.

As I said, MOUs are usually used internally

between two business units as in my previous example,

but they can also be used externally

between your organization and one or more

other organizations.

There are some consortiums out there

that have multi-party MOUs with five or six

or seven organizations that all come together

to do a common thing or a common goal.

But remember it is not legally binding

when you're dealing with MOUs.

So at any time these partner organizations

could simply leave and there'll be no consequences.

Next, we have a service-level agreement or SLA.

Now, a service-level agreement is a document commitment

between a service provider and a client

where the quality, availability and responsibilities

are agreed upon by both parties.

Service-level agreements are primarily concerned

with the ability to support and respond to problems

within a given timeframe while providing

the agreed upon level of service to your end users.

If you work in the IT service management realm already,

you are probably already familiar with SLAs.

SLAs are going to be used to provide a written agreement

for not only the security priorities

but also more importantly, your operational priorities.

It also is going to outline the responsibilities, guarantees

and warranties for a given service and its components.

For example, in one of my previous organizations,

we didn't want to keep a bunch of extra switches and routers

in our supply closet in case one of them broke.

This would be really expensive

to have all this extra gear just sitting there.

So, we opted to have a service-level agreement

in place with our supplier.

And that agreement said, "If a router or switch failed

"and we couldn't get back online within 10 minutes,

"they would bring us a new device

"within four hours of the outage."

Now, these service-level agreements can really help bring

some predictability to an otherwise hard to predict area,

like when will a device fail?

SLAs can be really good in this case,

but only if your service provider is going to live up

to their end of the agreement.

Now, another place you're often going to see SLAs

is in regard to your internet connections,

or when dealing with internet service providers

or cloud service providers.

For example, my internet service provider

has a service-level agreement with us

that says they're going to maintain an uptime of 99.999%,

which equates to having no more than five minutes

of downtime per year.

Now, because it's a service-level agreement,

if they don't meet that uptime requirement,

what's going to happen?

Well, that depends on your agreement

and your underlying contracts.

In our contract, we actually get a refund

for the entire monthly service fee

if they can't maintain the uptime they promised in the SLA.

This is their penalty for not meeting the SLA

and it works essentially like a fine

that they pay back to us.

Some contracts have these and some contracts don't,

it just depends on how you negotiate your deal.

So, remember when it comes to agreements used

in our a network management we have three main types.

We have non-disclosure agreements,

memorandums of understanding and service-level agreements.