They say that the only constant is change,
and that is certainly true in information technology.
There will be constant changes occurring in your network.
You may need to upgrade software on a workstation,
on a firewall, on a switch.
You may need to make changes to a firewall configuration.
Or you may need to modify or add different configurations
to a router or switch.
Of course, the concern we have when making any type of change
is that we could be affecting the uptime and availability
for that device or other devices that might be on the network.
This is a significant concern for information technology,
because making a single modification in one place
can have a dramatic impact on other components.
The need to make these changes is
something that occurs all the time in IT,
and we want to be sure that our implementation of these changes
will not cause any problems elsewhere.
Because of that, organizations tend
to have a very formal change management process.
This starts with setting policies
that will determine how often changes are made,
the duration or time frame in which these changes can
be made, the process to perform the actual installation
or change on the network, and then,
of course, some procedures to fall back
if those changes don't happen to work properly.
Organizations that don't have a formal change control process
tend to do things very chaotically, and very often
without any type of planning.
Trying to implement a change control process where
one doesn't already exist can be challenging,
but it will result in a much more
stable and much more managed rollout of these changes.
Another set of important plans and procedures
you should have in your organization
is what to do in the case of a security incident.
There can be many different kinds of security incidents.
For example, you might have a user clicking an attachment
inside of an email--
it executes malware and becomes embedded
into that person's workstation.
That malware then communicates to other external servers,
and information that you had inside of your private network
now could be made available to the public.
Another security incident might be a distributed denial
of service attack, which could cause outages
or downtime for your systems.
Or you might be a victim of extortion.
There could be confidential information that's
stolen by the hackers, and they want some money
or they're going to make that information public.
Or this could be a simple misconfiguration,
where a user might install peer-to-peer software, which
would allow someone from the outside
to access that internal system.
If you're interested in getting an overview of how
to handle these security incidents,
you can refer to the National Institute
of Standards and Technology document SP800-61 Revision 2.
This is the Computer Security Incident Handling Guide.
Inside of this handling guide, you
can read about the incident response lifecycle, including
the preparation for these security incidents,
how to detect and analyze these incidents,
how to contain, eradicate, and recover,
and finally, the post-incident activity.
Of course every organization has their own way
of handling these security incidents,
but this might give you an overview
of where you might start.
Another concern we have is the unavailability
of our systems because of some type of disaster.
It's very common for organizations
to have a disaster recovery plan so that the information
technology team will know what to do if a disaster occurs.
One of the challenges when putting together a disaster
recovery plan is there can be many different types
of disasters.
These could be natural disasters,
such as a flood or a tornado.
It could be a technology or a system failure,
and you need to recover that system as quickly as possible.
Or this might be a human created disaster,
where someone accidentally hits a water line,
and now you have to deal with flooding in the data center.
Disaster recovery plans tend to be very comprehensive and very
detailed and cover many different types of situations.
These will usually include a recovery location, especially
if you're building or facility is no longer available.
There may be a data recovery method,
especially if you keep data off-site, or in a way that
can be easily restored.
There may be application restoration concerns.
And of course, you need to make sure you
have IT staff and employees so that you
have some way to recover those systems and applications.
Sometimes when disaster occurs, there's
a delay before the recovery process can begin.
In those situations, you need some type of alternative plan
so you can keep the business up and running.
We refer to this as continuity of operations planning.
Or COOP.
That's because even though we commonly rely on our computer
systems to be able to provide us with these applications,
there may be a non-technical way to be able to perform
the same functions.
For example, you may be able to write down manual transactions
instead of typing them into a computer.
You may be able to provide paper receipts instead
of printing something out on a laser printer.
Or instead of processing your credit card transactions
automatically, you can call each transaction in and process them
manually.
This is obviously a set of processes and procedures
that needs to be documented and tested
prior to a disaster occurring.
That way, we know, if we happen to have a disaster,
we can immediately go to our documentation
and know what we can do to keep everything running.
Another important concern with process and procedure
is what we do with the equipment that we're no longer using.
This is part of the system lifecycle,
so we need to know how to dispose
of assets such as desktops, laptops, tablets,
mobile devices, and anything else
that may contain company data.
This might also be a legal issue.
In some organizations, certain types of data legally cannot be
destroyed.
So you need to make sure that you're destroying data that
would no longer be needed, but you're keeping all of the data
that you've been mandated to protect.
An important key with this is making sure
that all of the data that you have internally
is not being made available to others.
And it's very easy for someone to rummage through the trash,
find a hard drive, and suddenly have access
to data that you had no intention of making
available to the public.
As you can see, there are many different concerns
across many different parts of the organization when
it comes to protecting data.
We need to have some way to document and maintain
what the standard operating procedures might
be for your organization.
Most organizations will maintain either
an online or offline version of a standard operating procedure
manual so that what to do if a device fails
or you have some downtime.
The standard operating procedures
might also give you information on what
to do when a facilities issue occurs
so you know exactly who to contact to resolve that issue.
These SOPs might also document your process
for change control.
So when you're performing a software upgrade,
or you need to perform testing, all of this information
will be clearly documented in your standard operating
procedures.
The common thread is that all of these have been documented
and everyone knows where to go to review and understand
exactly what these policies might be.
We often find ourselves working with third party organizations
to provide services for our company.
In those situations, you need some type of agreement
so that everyone knows exactly what level of service
is expected.
One way to provide that agreement
is through the use of an SLA, or service level agreement.
This is an agreement that documents
the minimum terms to provide these services or products.
Usually, this may include an uptime requirement, a response
time agreement, and it's commonly
used between a customer and a service provider
so that everyone knows what the expectation is
when that service is provided.
Most service level agreements are formal documents
that are signed, but if you need an agreement that
doesn't have quite that level of urgency,
you may want to use a memorandum of understanding, or an MOU.
Both parties to this agreement would
come to terms on what this memorandum of understanding
would include, and it usually would also
have statements of confidentiality.
This is often an informal letter of intent,
and it might lead to a service level agreement,
but by itself, an MOU is usually not a signed contract.
If you ever had a meeting with a third party that
had private information or something that
was company-confidential, they may
have asked you to sign an NDA.
The NDA is a non-disclosure agreement.
It's an agreement between parties
that this information will stay confidential,
and there will be penalties if that information was
provided to a third party.
This is commonly used to protect private business activities,
trade secrets, or anything else that
might be specifically listed in the non-disclosure agreement.
Some of these agreements are unilateral,
where only one side needs to maintain the confidentiality,
but in many cases, the NDA is bilateral, or in some cases,
multilateral, so that everyone involved with the conversation
is not able to speak of anything mentioned in the meeting.
These are almost always signed contracts
that include very specific details as part of the NDA.