- In this lesson 23.2,
we're gonna laser focus in on governance documents.
The governance documents are used to communicate direction,
expectation, and rules.
The governance documents are going to be derived
from the information security strategy.
And where does the strategy come from?
The strategy is derived from the desired or future state.
So we determine our future state.
From there, we get our strategy.
And then from there, we develop our governance documents.
And that will ensure that our governance documents
are strategically aligned
with the objectives and goals of the organization.
So let's look at governance communication.
I wanna show you the sort of the pantheon
of all of our different types of communication.
We have policies.
Policies are supported by standards.
Standards are supported by procedures.
There are different types of procedures.
We have simple step, hierarchical, graphic, and flowchart.
Standards are also supported by guidelines.
And policies are also supported by agreements.
So we're gonna be talking about policy, standards,
procedures, guidelines, and agreements.
Now the objective of a policy, really any policy,
is to communicate and codify management's requirements,
and to provide direction.
How we need to act?
What we need to do?
Now information security policies
codify high-level requirements,
and I can't stress that enough.
High-level requirements
for protecting information and information assets
and assuring are fundamental principles of confidentiality,
integrity, and availability.
Now policies should be approved and authorized
by the organization's highest governing body.
So that might be a board of directors,
your board of trustees, right?
It might be agency leadership.
It might be up the chain of military command.
In a small business, it may be literally the owners.
But they should be approved and authorized
by the highest governing body in your organization.
Now well-developed policies
generally remain relatively static
over extended periods of time.
You wanna reauthorize them annually,
but most part modifications should be pretty minor.
And then we use agreements to legally enforce policies
and related governance publications.
But I wanna go back
and really stress that policies are high-level documents
that all those implementation details
do not belong in a policy.
We're gonna see that those belong in a standard.
And because the implementation details
are not in the policy,
that means that policy
can remain relatively static over time.
So let's do a survey of different types of policies
that you may be interacting with.
We have our information security policy.
Now our information security policy
will have a lot of different sections, right?
It might have information about,
you know, risk management and access control
and authentication and remote access.
And you know, physical security for, you know,
our data centers and our wiring rooms,
might have a section on cloud, on training, right?
Everything that has to do specifically
with information security or cybersecurity
would be in our information security policy.
Our business continuity policy is very complimentary
to our information security policy
and is how we are going to continue to operate
as an organization in adverse conditions.
A very important policy,
but it's not part of the information security policy
generally because, right?
It's really applicable
to every business unit in an organization.
The same thing of our disaster recovery policy, right?
That's gonna be high-level governance document, right?
About how we would recover from a disaster.
And then we have our incident response policy, right?
And we talked about this one a little while ago, right?
About all the components
we need to have to have in an incident response plan.
And then of course, all of those are referred to
or just that we need to have them actually in the policy.
We have a software development lifecycle policy
that our developers or coders will use
if we're developing any software in our organization.
We may have a configuration and change management policy
that may in fact be part of an information security policy.
It may be part of an IT policy.
Very often, it's actually going to be its own policy
because it is applicable across so many areas.
A risk management policy,
but how we are going to manage risk.
Now part of a risk management policy.
There may be references to risk
in our information security policy.
But again, a risk management policy
tends to be enterprise risk,
not just information security risk.
And then an acceptable use policy known as an AUP,
which is an end-user-oriented policy.
And it's a policy that we create
to really help our users understand
how they are supposed to behave.
And we'll dive a little bit deeper into that one.
So I said that our policies
were really, really high-level documents.
So where do those implementation details belong?
Well, they belong in standards, right?
Standards are the precise specification
for the implementation of policy
and dictate mandatory requirements.
The standards absolutely, absolutely must be unambiguous.
When we group standards together,
we refer to them as a baseline.
Baselines are the aggregate of standards
for a specific category or grouping,
such as a platform or a device type
or ownership or a location.
And then optionally, we might have guidelines.
Guidelines help people understand and conform to a standard.
The guidelines should be customized to the intended audience
and are not mandatory, but definitely very useful.
So let's look at the relationship
between a policy and a standard.
I'm gonna give you an example.
A policy might be multifactor authentication
is required for access to data
and systems classified as confidential.
That's a high-level statement.
We're saying that for any data
and system classified as confidential,
we have to have multifactor authentication.
What we're not saying
is the type of multifactor authentication
we're going to have
or any of the criteria around those factors.
That detail all belongs in your standard.
So your standard might be multifactor authentication
required for data and systems classified as confidential.
Factor one will be an eight-digit numeric pin.
European characters changed every 90 days.
A factor two will be a biometric fingerprint.
Those are the implementation details.
And those are mandatory.
So policy, high-level standard implementation details.
So we didn't even have to say
what type of multifactor it was in our policy.
And that gives our management a lot of latitude
for how they're going to apply that policy.
And that means we don't have to go back
and change the policy
every time maybe there's a change in technology.
So policy, high-level standard
is our implementation details that are mandatory.
Procedures are instructions on how to carry out an action.
Now procedures focus on very discreet steps or actions
with a specific starting point and ending point.
So we have four types of procedures you wanna recognize.
Simple step, hierarchical, graphic, and flowchart.
A simple step is just what it sounds like.
It lists sequential actions.
No decision making.
Step one, step two, step three, step four, step five.
Hierarchal organizes the instructions
in a hierarchal structure
where each level is nested within the one above it.
Graphic presents in pictorial or symbol form.
We'll use a flowchart to communicate a process
or when decision making is required.
So yes, no, stop, go, if then.
That'll all happen in a flowchart.
And then we have plans.
Plan is a detailed strategy
or tactic for doing or achieving something.
Now the function of a plan is to provide instructions
and guidance on how to execute
or respond to a situation within a certain timeframe,
usually with defined stages and with designated resources.
So plans we would expect to see in an organization
would be things like our disaster recovery plan,
our business continuity plan,
our incident response plan, our communications plan.
Now I mentioned when we were doing our survey of policies,
the acceptable use policy.
I wish this had a different name
because it's really the exception
to everything I just told you about policies.
The acceptable use policy
details your user community obligations
pertaining to information and information systems.
So even though it has the word policy in it,
it has a lot of details.
It really explains what you can and can't do
as well as some other information.
But what I really wanna stress here
is even though it says the word policy,
it's going to have a lot of implementation details
or required or expected actions and activities.
So the AUP is gonna contain rules that specifically pertain
to acceptable behavior,
the activities that are required
and actions that are prohibited.
But all we want in our AUP
are things that really are applicable to our user community.
And I want you to think about the AUP
as a teaching document.
It's a teaching document that develops awareness
and teaches the importance of information security
or cybersecurity practices.
Now the AUP should be written in a language
that can be easily and absolutely unequivocally understood.
So what are some of the common elements of an AUP?
Data protection, authentication,
application, communication, internet, mobile device,
remote access and incident reporting.
So data protection would really explain
their data classifications and the handling standards
for the different classifications.
Authentication would include things
like our login requirements
including password standards and use of tokens or biometric.
The applications would be about procurement
who can get an application, right?
Installation and licensing.
Communication would be about written
and verbal communication use and limitations.
So what you can and can't say
including in your personal email or social media.
The internet would be about internet use,
activity, and engagement.
Mobile device is the use, configuration, activity,
and device protection.
Remote access, again use of remote access,
configuration type of activity,
and the physical security
if you're doing remote access,
let's say you have a home office.
And then incident reporting.
Instructions on how to spot
and how to report suspicious activity.
Now there may be more pieces
than that in yours or on ones that you see.
But these are then the fairly standard common elements.
Now there may be two agreements
that you are required to sign before you have access
to information or information systems.
One is known as an NDA, non-disclosure agreement
also called a confidentiality agreement.
And of course, the second one,
which you will be required almost everywhere,
is the acceptable use agreement.
An NDAA, non-disclosure agreement
or confidentiality agreement establishes data ownership
and the reason that data is being provided or being shared.
It stipulates data use criteria.
It protects data disclosure,
'cause it says how under what circumstances
can this data be shared or disclosed?
It does prevent forfeiture of patent rights
and it is survivable.
It survives the relationship.
So even though you may not be an employee there anymore,
if you have signed an NDA agreement,
it will have a timeframe.
So maybe for five years after you've left the organization.
Now the acceptable use agreement
or the acceptable use policy agreement,
the user acknowledges that they understand
and that they agree to abide by the acceptable use policy
including any violation sanctions
up to and including termination.
Now that agreement that they're signing, right?
Should really clearly state
if and how the user will be monitored
and the limitations of privacy.
So what their privacy expectation should be?
Now the agreement should be executed
prior to being granted access to any information
or information systems.
Which means during the orientation,
we're gonna give someone the acceptable use policy
and the corresponding acceptable use agreement
and maybe the NDA agreement.
During that orientation,
we really want to go
through that acceptable use policy with.
Then we want them to understand, right?
What the expectations are.
And we really want them to make sure
that they get it all before they sign the agreement.
And that my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
Question one, high-level governance document.
One, two, three.
That's gonna be a policy.
Number two, mandatory implementation requirement
related to policies.
One, two, three.
It's gonna be our standards.
Number three, specific instructions for carrying out a task.
One, two, three.
That's gonna be a procedure.
Number four, a detailed roadmap
for doing or achieving something.
One, two, three.
That's a plan.
And lastly, number five,
an agreement that should be executed
prior to being granted access
to information or information systems.
One, two, three.
That's gonna be our acceptable use agreement
or acceptable use policy agreement.
All right, let's do a security in action
about developing a policy.
During a routine software audit,
numerous instances of unlicensed operating systems
and applications were identified.
This violation appeared to be unintentional
and related to the proliferation of virtual machines.
Now in addition to fixing the issue ASAP,
the audit report also recommended developing a policy
and supporting governance documents.
And you've been assigned the task.
So what's your plan of action?
So just our review, we had this routine software audit
and we found that we had numerous instances
of unlicensed operating systems and applications.
We don't think it was intentional.
It's just unintentional
and probably 'cause we just have a lot of VMs,
a lot of virtual machines around.
So you had to fix that, the licensing issue ASAP.
But the audit report said, you know what?
We need a policy
and supporting governance documents about this.
And you have been assigned this task.
So what's your action plan?
Go ahead and put me on pause.
Think about that action plan
then come back and we'll talk about it.
Well, first of all,
remember a policy is a high-level document.
We don't want a lot of implementation details in our policy.
So research, solicit input,
and write a policy that is strategically aligned
with the organizational objectives,
but very high level, right?
And then be sure to gain consensus.
Get people to agree and buy in to this policy.
Writing a policy that nobody agrees with, nobody likes,
and nobody wants to, you know, abide by or enforce,
well that's useless.
So we've gotta gain consensus.
And sometimes that means there's multiple rewrites
of a policy till we get there.
Then you're going to submit the policy for authorization.
So you'll probably submit it first
to maybe the steering committee.
You'll get their, you know, blessing on it
and then it will go up to the board of directors.
And then you're gonna wanna develop
corresponding standards, right?
Those are those, you know,
precise mandatory implementation details
if applicable guidelines, right?
And if applicable procedures.
And then you're going to wanna publish
those documents, right?
In a publicly accessible manner
however you do your digital library in your organization
and you're gonna wanna provide training
to the applicable user community.
And if you think that this is actually a user issue as well,
you're probably gonna wanna add it to the AUP,
the acceptable use policy.
Now more than likely, your users probably
don't have the right to install software, but maybe they do.
And if they do, you'd wanna add this to the AUP as well.
Doing all that, security in action.
There you go, your word cloud.
I think the thing that people struggle with most, right?
Is the difference between a policy and standard.
So make sure that you have a lot of clarity
about what's different between the policy and the standard.
All right, when you're ready, let's do a quiz.