- [Instructor] In this closer look segment,
we're gonna talk a bit more about policies and standards.
Now in the lesson,
we looked at the entire pantheon of governance documents:
policies, agreements, standards, guidelines, and procedures.
Now agreements are used to enforce policy
and standards are used to implement policy.
But what I find very often is there's a lot of confusion
between really what's the difference between a policy
and a standard and what belongs in a policy
and what belongs in a standard.
They are two different documents
but they are closely aligned.
And then our third document being our guideline
that we used to help our user community
implement our standard.
So let's take a closer look at a policy,
a standard, and a guideline.
Now we define policies and standards in the lesson
but I wanna do it again.
Our information security policies
codify high-level requirements
for protecting information and information assets
and ensuring confidentiality, integrity, and availability.
Codify high level,
that's the thing to remember.
Think about who approves policy.
Policies are approved by the board of directors
or the board of trustees or executive management.
They are setting the tone, the tenor, the direction
for the organization,
and they're also assigning roles and responsibilities.
So, that's what we expect to see in a policy.
We don't expect to see nitty gritty details.
In contrast, an information security standard
includes the specifications
for the implementation of the policy
and they dictate mandatory requirements.
So our policies give us to speak direction.
Our standards say, "Okay, based on the policy,
this is exactly how we're going to do it
and these are our mandatory requirements."
Who's involved in constructing standards?
Well, experts in the respective areas.
Technologists for IT standard,
trainers for education standards,
auditors for audit standards.
That we engage the experts that have
that very deep knowledge in their specific
and respective areas.
So let's take a look at a policy and a standard.
This is a section from authentication policy.
A is all about authentication factors.
It says that data classifications,
regulatory requirements,
and the impact of unauthorized access
and the likelihood of a threat being exercise
must all be considered when deciding upon the type
and number of authentication factors.
That the Office of Information Security
will make this determination
in conjunction with the information system owner
and that this process must be documented.
Now, you'll notice that we're not saying in a VPN,
you need to have this type of factor
and this number of factors.
For network login,
you need to have this type of factor
and this many for your smartphone.
We're not seeing any of that, right?
What we're getting is that here are the things
when you're making the decision about the standard
that you must take into consideration.
And there's roles and responsibilities
that the Office of the Information Security
will make this determination
in conjunction with the information system owner
and that we have to document this process.
We have to make sure it's a formal, documented process.
Then the policy goes on to say
that factor requirements must comply
with the minimum requirements or stronger detailed
in NIST SP800-63B Digital Identity Guidelines.
Why we be told that?
Because we're being told
that the organization has made a decision
to align with an external standard.
So when we're creating our standards,
we must align with those standards.
That's what we've adopted.
And that any changes in factor requirements must be approved
by the chief security officer,
the chief information officer,
and the chief operating officer.
Again, another role and responsibility.
So what are we seeing here?
Again, high level instructions.
We're being told about the external standard
that we're going to align with
and we've got roles and responsibilities.
That's what belongs in a policy.
Let's compare that with a standard.
This is a standard for a single factor memorized secret.
Now a memorized secret is just a fancy way
of saying password.
And I'm using that term
because that's what we actually see in NIST SP800-63.
And I really love the term
because our users can relate to it well.
They understand what a secret is
and they know what it means to memorize something.
So, memorized secret.
So the construction standard is very, very specific.
This is for single factor
which is what we normally think of as a password.
8 characters minimum,
64 characters maximum.
And here's what you can't have.
Repetitive which is three or more or sequential characters.
AAAAA.
1234.
ABCD.
You can't use a single dictionary word
and you can't use context-specific words
such as the name of a user company or department
and derivatives thereof.
Now you might be saying,
"Well, what about complexity?
Aren't we gonna tell them to use uppercase and lowercase,
a number, and a special character?"
And the answer is actually not.
Because in the NIST digital identity standard,
they've done away with that and says,
"You know, that just made it really difficult
for our user community.
And in the end, from a security perspective,
it really didn't make a lot of difference."
So even though this standard is fairly simple,
it might throw our users off.
So we are gonna have to find a way
to help them construct their password
in accordance with this standard.
But you notice the standard's very, very specific.
It's got input probably from people
in the information security department
or in the IT department, right?
And this is what is absolutely required, right?
These are mandatory requirements.
Now, let's look at a guideline.
Now, this is a guideline that was issued by NIST.
Now, that has three actually guidelines in one.
I like all three of them.
It's number two that's really of the biggest concern to us.
But the first one is don't rely on passwords alone
to protect anything you value.
Turn on multifactor authentication whenever possible.
Great advice.
But the second one is the one I love
in terms of this memorized secret.
Use a phrase with multiple words
that you can picture in your head.
So it's difficult to guess but easy to remember.
And the example they give is "sunwalkraindrive".
I love it.
"sunwalkraindrive".
It's long, you know?
But it means something to our users, right?
"sunwalkraindrive".
And then number three is just protect
your most important accounts like banking and primary email
by giving each a unique pass phrase.
So one in three great advice.
Two is the one that really aligns
with what we're trying to teach them right here.
Again, "sunwalkraindrive".
So just to recap,
policy, high level document
that codifies the requirements and expectations
for the organization as set out by board of directors,
board of trustees, or executive management.
Our standard are mandatory implementation details.
Our policies are generally approved
on an annual basis, right?
Standards, as long as they adhere to policy,
can be changed as necessary
and standards generally don't have to ever go
to the authoritative body like your board of directors
for approval.
And then guidelines are going to be audience-specific
and we're gonna develop our guidelines
to help our user community comply
with the required standard.
And that, my friends, is a closer look
at policies, standards, and guidelines.