-: Policy documents.
So before with can have a security architecture
that's really working well and develop it technically,
we have to figure out what the administrative controls
are gonna be, and a large portion of that
comes from our policy documents.
Now, policy documents are those
information security policy framework documents,
and there's four of them that we really focus on.
There's policies, standards, procedures, and guidelines.
We're going to talk about each of those in this lecture.
Policies are high-level statements of intent.
These are things that are gonna contain broad statements
about the cybersecurity objectives from the company,
like, for instance, we wanna make sure
we have the most secure network out there,
and we will do so by blank, blank, and blank.
These are these big vision statements
that are gonna guide all the other policies.
These policies set the framework for the organization
and their information security.
They're going to help you meet your business goals
and define roles, responsibilities, and terms
that are going to be used in all the other
security documents that we're gonna talk about.
Now, when we look at policies,
there's lots of different policies,
and depending on your organization,
you'll have some or all of these policies.
There's things like the information security policy,
the acceptable use policy,
the data ownership policy,
data classification policy,
data retention policies,
account management policies,
and even password policies.
Now, most of these are gonna be very high-level
and not get into the technical details,
because were gonna give that guidance
down in the procedures,
in the guidelines, and in the standards.
Now, who's gonna approve the policy?
Well, someone from the C suite,
and usually this is gonna be your CEO,
your chief executive officer,
your CISO, your chief information security officer,
your CIO, your chief information officer,
your CSO, your chief security officer,
and they're going to be the ones
who are going to approve it for the organization.
Now, why is this important?
Well, because without top management buy-in,
the policy is gonna be a waste of your time and effort,
because no one is gonna follow out.
You really need to use a top-down approach here
and get the C suite involved
and push that down to the mid-level managers
and then all the way down to the rest of the workforce.
Now, when we talk about standards,
these are really used to implement your policy.
They're gonna take that big, lofty ideas and goals
and really put some meat on those bones.
This is going to include mandatory actions, steps or rules
that are needed to achieve your cyber security.
Now this is approved by lower-level people than the C suite.
So, it could be your mid-level manager,
and it's their interpretation of that overarching policy.
This can be people like the director of information systems,
for instance, who runs your IT department.
And these standards, they exist inside industry
as well as inside your organization.
So, if you're looking at best practices,
you can start looking at ITIL or COBIT or TOGAF,
and you could take those frameworks and their standards
and bring them into your organization and apply them,
and that's going to give you a really good head start
on developing all of these standards
inside of your policies.
Now, when we talk about procedures,
we're talking about detailed, step-by-step instructions.
This is things that a person can take,
and they can go down this checklist essentially
and know how to perform an action.
For example, I had a service desk,
and we had created a step-by-step procedure
of how they should create new user accounts.
And it said when you create a new user,
you're gonna click here,
and you'll go on this system,
and you'll login using this username and password,
and it will tell them exactly
what groups to put the person in
and what to create the default password, all of that stuff.
This is gonna give you all of your security-related
policies, standards, and guidelines
into something that a frontline employee can use,
because the people who are working my service desks
that are creating these new accounts
were rather new employees.and so this made it
so it was really easy for them to follow,
step by step by step,
actual steps to create a consistent method
for achieving your security objective.
If everyone created the user accounts differently,
they may have put these people in different groups
with different permissions,
and that can cause problems for us.
By following a procedure, it gives them
exactly the way that they need to implement it.
Now, when we walk about guidelines,
these are not required actions.
They're just recommendations.
These are flexible in nature, and they allow
for exceptions and allowances during a unique situation.
So what's a good example of a guideline?
Well, an organization can create guidelines
for just about anything,
but let's say they created one to show users
how to store data files in a cloud service,
and how to encrypt those files.
So, for instance, your organization might be using Dropbox.
By default, the files in Dropbox
are stored with encryption by the Dropbox server,
but they're not encrypted by your users.
And we may have a policy
that any personal identifiable information
must be encrypted first by the user
before uploading to Dropbox
so that it's individual, each individual file is encrypted.
That might be a guideline.
It may not even be a required thing.
It may be we recommend you do this,
and that's where the guideline's gonna be there.
Now, the good thing about guidelines
are they're very easy to change.
You can change 'em very quickly and very easily,
and they don't have to go
all the way back up to the CIO for approval.
Instead, they're usually handled at a very low level,
and they'll just be dead by the director
of information systems or lower-level manager.
Now, are rules meant to be broken?
Well, most of the time, our policies,
our standards, and our procedures should be followed.
But every now and then,
there are things that you need to get an exception for,
and you need to ask permission
to break those established rules.
How are you gonna do that?
Well, that's gonna depend on your organization.
Your information security framework and policies
should have a method for gaining those exceptions.
You can have this exception being for a specific approval
to deviate from a policy, standard, or procedure,
and the way you're gonna get that is gonna be
whatever policy you guys use at your organization.
In my organization, for instance,
we have a standard that, if you're gonna get an exception,
it has to be signed by at least two levels of management,
your director supervisor,
and then the director of information systems.
If they've approved it
because they've done the risk study on it,
that can then become an exception that's used.
That is how we do our approval authority,
but your organization may be different.
Now exception requests can include lots of different things.
They can be any kind of exception against a policy,
standard, or procedure that needs an exception.
For instance, we may have a policy that says,
not one can do email on their personal cell phone,
and maybe the CIO's like, well, I have to use it,
so I need an exception,
and they put that through the process,
and it will get approved after a risk analysis is done.
That's probably a bad example, but you get the idea.
There's also other things
on the exception form you're gonna have.
It's what is the exception you want,
what's the reason for the exception?
What's the scope and duration of the exception?
Maybe the CIO's work phone had gotten broken,
and so he just needs it for a week
that we're gonna allow him
to use his personal phone to get his email.
Something like that.
So there'd bye scope and duration.
It's only gonna be applicable to these three users,
and only for this amount of time.
There's also the risk associated.
So we're gonna say, well, if he's gonna use
his personal phone, now we're getting into the risk
associated with the bring-your-own-device policy.
Is his phone secure?
Does he have antivirus on it?
Does he use Android, or is he using Apple?
All those kinds of questions
will go into that risk association.
And then finally, a description
of any compensating controls that will help lower the risk.
So, in this case, we might say,
well, he's using Android,
but he's got good antivirus software.
He only uses his phone for work anyway,
and so we think it's gonna be safe, right,
whatever that exception is.
And we'll go through an exception approval process,
and if it gets approved, we can implement that exception.
That's the idea here with policy documents.
Remember, four different types of policy documents, right?
Policies, standards, procedures, and guidelines.