- [Narrator] The security standards offered
by industry experts are an excellent starting point
for an organization's own security standards,
but they are rarely ready to use out of the box
and often require customization
to meet the organization's
security and business requirements.
Organizations often start with industry-developed
baselines and then add, remove,
and modify controls to develop their own security standards.
The purpose of these customization efforts
is to scope and tailor the standard
to meet the organization's specific needs.
For example, an industry standard might suggest
using full disk encryption to protect stored data
on an end point and suggest the use
of AES encryption with a 128, 192,
or 256-bit key.
The organization, however, might be
under a more stringent compliance requirement
that mandates the use of 256-bit keys
and specifically prohibits the use
of 128 or 192-bit keys.
In this case, the organization might use
the benchmark standard but modify it
to require the use of a 256-bit key,
removing the options to use
a 128 or 192-bit alternative.
The easiest way to document these changes
is to write a security standard
that references another standard.
For example, an organization might say
that we will adopt the Center for Internet Security
Benchmark standard for Windows Server
2012 R2, dated April 28, 2016,
with the following modifications.
First, we're going to change requirement 1.1.2
to set the password expiration period
to 180 days instead of the standard's
default 60-day expiration period.
Second, we're going to change requirement
1.2.2 to lock out accounts after five
incorrect login attempts instead of the standard's
10-attempt threshold.
These are just examples of some of the ways
that an organization might modify a standard.
The specific modifications will depend upon
the organization's own security and business requirements,
but the idea is they don't need to write
an entire standard from scratch.
They can simply reference an existing standard
and then just note the differences
where controls are added, modified, or removed.
Any customization that enterprises
do make to security standards
should tie back to clear security
and/or business requirements.
These deviations should include descriptions
of the impact of the change
on the confidentiality, integrity,
and/or availability of systems and information,
or the impact that the change
might have on compliance with other requirements.
Organizations might also apply
specific configuration standards
to high-value assets.
This may mean requiring more stringent controls
on certain systems and data elements
based upon the sensitivity of the data
or the criticality of the system to business operations.