So far we've discussed things like governance and the elements of security,
but in the end,
security is a theoretical activity until we back it up with
practical implementation of concepts.
This is why we need policy, procedures, standards, baselines, and guidelines.
The idea of a policy hierarchy is that at the top you actually have laws and
the actual strategy of the organization as we saw earlier,
but these are what feed into the development of the
policies of the organization.
We could also say that a lot of the policies of the
organization are influenced by risk,
what risk does our business face so that we develop
policies to respond to those risks as well?
But policies themselves are high‑level statements of what we'd like to do,
so therefore,
we need to take those ideas or concepts of policy and turn them into
practical steps through things like procedures,
standards, baselines, and guidelines.
We also see in this slide we have then functional policies, whereas policies
themselves should be non‑technical in a more of a high level.
We often need policies specifically dealing with a certain technology
such as a policy about acceptable use of the internet or a policy about
some type of remote access or wireless use.
Those are functional policies just about that one topic so
we don't have to change and update the overall policy
every time technology changes.
Policies themselves tell us what we can and what we cannot do
and that way they provide direction for us.
We know what's acceptable, what management states is allowed,
but in some cases is not allowed as well.
A policy is issued by and signed by management to say that
this is what we agree to that you should do,
and therefore, it has authority by that.
A good example is an acceptable use policy.
If you have internet access, what is acceptable?
Some companies say only business, other companies say well any reasonable use,
so it depends a little bit on the culture of the
organization of what types of policies they create.
When we look at procedures, we know the problem with policy is that it's theory.
This is what's acceptable use of the internet, but
then how do we actually enforce that?
For this, we need procedures.
A procedure mandates that how something should be done.
If a person violates a policy, what do we do, for example.
Take the example of a new user starts with the organization.
We should have a clear procedure on how to set up that new
users account so that all users accounts are set up properly
and according with good practice, for example,
and these very often are by their very nature step‑by‑step actions,
do this, then do this, then do this.
Something we'll look at,
especially in domain two when we look at incident response.
Here are the steps we take when there is an incident, for example.
The overall objective of a procedure is to be the legs or
the support for the policies intent.
What was the policy trying to do?
And procedures help interpret what that policy's intent is.
We also have standards.
Standards are good things, so things are done in the same way.
For example,
we could have a standard that says here is our required
solution for anything from equipment,
you're going to buy a laptop or a desktop or you're going to buy software,
for example,
so that we're all using that same type of configuration and it
makes it much easier for us to support it,
for example.
A standard is often based on good practice,
the things we've learned that work, and that,
of course, could even be things like an international standard.
We have what's known as the ISO/IEC 27001.
That defines something known as the Information Security Management System.
It defines what a good security practice should be, and many
organizations have adopted that standard as the template to
use for their security program,
and they'll even seek to be recognized as compliant with
the requirements of that standard.
When we look at baselines,
we're saying here is the minimum acceptable level of action.
For example, you may not have to have a high level of security in the system,
but you at least have to meet this minimum acceptable standard.
And in that way,
a baseline helps to ensure that nothing can connect to our system,
which is not at least at that acceptable level.
We often use this when we're looking at things like equipment configuration.
Any device connected to our network must have,
for example, antivirus on it,
must have up to date patches for the operating system.
Those are baselines.
We also have seen baselines with something like a minimum password length.
Your password must be at least eight digits long.
It could be more, you could exceed the baseline,
but no one could have a password that's not at least eight characters long.
We also have guidelines.
Guidelines are suggestions, they're recommendations,
they're not mandated like a policy, procedure, standard, or baseline is.
You must follow those procedures and baselines,
but you don't necessarily have to follow a guideline,
it's a suggestion.
For example,
we said before that there was a baseline your password
had to be eight characters long,
but a guideline could say here is some suggestions
on how to choose a good password,
some things you can do to make your password of an acceptable level of strength.
You don't have to follow it necessarily,
but at least it's good information and a recommendation that could be followed.
The key points review.
We've looked at some important things here.
The use of policies and procedures because a policy is theory,
it's management's intent, but it doesn't necessarily say how to do something.
So therefore,
the policy is of little value if it's not supported by
something like a procedure which says here are the
instructions of what to do and how to do it.
We can say here the main goal or main purpose of a policy is to
demonstrate that management is committed to certain behaviors as
part of their information security program.