ITS 305 - Security Policies and Auditing
Chapter 6, IT Security Policy Frameworks
Chapter 7, How to Design, Organize, Implement, and Maintain Security
This lesson covers chapters 6 and 7. It discusses areas of IT security
policy frameworks, factors to consider when creating them, implementing
them, and maintaining them. Objectives important to this lesson:
- IT security policy frameworks
- IT program framework policies
- Business factors relating to building a policy framework
- Information assurance factors to consider
- ISS factors to consider
- Best practices
- Designing policies
- Contents of a policy framework
- Implementing policies
- Policy change control
- Maintaining policies and standards
- Best practices
This chapter begins with a definition of an IT security policy framework.
Unfortunately, it is only a list of components found in a framework, so
it would tell you little if you do not understand the items listed there.
Before continuing, review lesson 1 and compare it to this week's list
- Policies - rules about the conduct of our organization with regard
to particular actions (we will limit ourselves to particular models
chosen by the IT department); how we will approach the expectation
- Standards - a method or process that may be procedural or technical
(orders are to be placed by approved requesters within each work area);
what steps are to be followed to assure general compliance with policy
- Baselines - standards from which other standards are developed;
we might have a baseline standard that all PCs will come from one vendor
contract with a minimum feature set, and specific standards for advanced
models for IT system developers
- Procedure - a detailed set of steps to follow to be in compliance
(requests are to be made to your manager, who will forward approved
requests to your authorized requester); variations or limitations that
apply to specific work areas, to be followed if they apply to your area
- Guidelines - a suggested addition to any of the items above that is
recommended but optional (submit your requests two weeks before the
end of a quarter to allow processing time); do this to make it work
- Taxonomy - a set of definitions of how terms are used in our
organization; this can also mean naming standards for objects in our
organization, used in Active Directory or a management program; naming
systems can be based on location, use, categorization, department or
division ownership, or other concepts important to your organization
The author has thrown in some new ones. I made them bold in the
list above. His comments on page 144 about growing a library of these
documents being like growing a tree is a pretty good analogy. Like a tree,
the parts of your business need to grow, to reach maturity,
to produce fruit or nuts or seeds, and to be cut away to
make room for new growth when they are no use any longer. The pieces of
your policy framework should be expected to do the same. We need new rules
about new products, new problems, and new changes
to the environment.
The text talks about risk again for a bit. The author defines two phrases
that may be misunderstood:
- Risk appetite - The upper limit of risk that is acceptable
in pursuit of a goal
- Risk tolerance - The amount of variance in risk that is acceptable
to an organization
Risk appetite is a measure of the greatest risk that is
allowed to be undertaken. Most organizations are cautious about risk,
if there is a significant impact. Risk tolerance is a measure of
the difference between the highest risks, lowest risks,
and average risks in an organization. No one minds low risk, but
risks that are too high, too different from our standard operation,
will cause too much variance in the performance of the company.
The next topic is called by two names: program framework policy
and information security program charter. Both phrases are almost
indecipherable, so let's see what the author means. The word program,
which appears in both names, refers to a broad authority to make
rules and procedures regarding information security that must be followed
by all employees in the organization. The word charter in the second
phrase also refers to the authority being granted to the people
managing this program. Four common names for the officer who runs such
a program appear at the top of page 147. Such authority must be granted
by the legitimate owners or operators of the organization. We have already
been sold on the idea of a framework containing all the concepts in the
list above. The program framework policy, or program charter, is meant
to be an even larger concept, one that establishes the legitimate rights
of the office administering it.
The text lists four areas of concern within the program framework
policy. Don't be confused, it still includes all the bulleted items
above. It also includes these:
- Purpose and mission of the program - The text discusses
this area with terms that sound unrealistic. Yes, the program should
support the goals of the organization. How does protecting our customers'
data conflict with the goals of any organization. The purpose
is to perform the basic functions of an information security department,
and to protect our assets. Alignment with the mission goals of the organization
is more of a political statement than a useful one.
- Scope of the program - A discussion of the scope of the program
depends on what our assets are, what our budget is, and how we decide
which risks to protect ourselves from. There will never be enough money
to do everything we want to do, so we have to live within our means.
- Responsible parties who will implement the program -
This area makes it clear who has what responsibilities with respect
to carrying out the procedures, notifying staff of policy, and making
sure that these people do their jobs.
- Compliance management - The program requires that people follow
the rules, and must also allow for monitoring performance for compliance
and for violations. It must allow for policies to be created by the
proper part of the organization (such as Human Resources) with regard
to discipline for single, multiple, and repeated violations.
The text moves on to discuss well known framework models (security
management models) that are often chosen by organizations as the basis
for their own frameworks. To put this in perspective, imagine three
phases of a project to develop your security management standards,
as described by last year's text:
- First, select a security management model
that fits your organization's needs and goals.
- Second, write your own security framework
document, a plan that outlines
the work needed to adapt the model
to the realities of your organization.
- Third, create the security blueprint,
which is a working, operational
document. It describes how your organization will meet
each applicable requirement of your security model, through the goals
that are established in your framework.
So, that means you need to create the framework and the blueprint, but
your first goal is to select a model
that makes sense. You see what I mean about different terms in different
books? They really mean the same things. You just have to get an idea
about the concepts first to see that it is the same message.
How do you select
a model? Sometimes, a model has been selected
for you by another part of the organization (upper management)
and you simply have to use it. The good news is that whichever model was
chosen, it will probably work after being customized into the blueprint
for your organization.
(Control Objectives for Information and Related Technology) - not discussed
in detail in the text; follow the link to the left to see details
27000 Series (International Organization for Standardization)
- see the list of topics in document 27002 on pages 150-153
(National Institute of Standards and Technology) Models
- see the brief discussion on page 153, and the table on pages 154-155,
principles in NIST Special Publication 800-53
(formerly Information Technology Infrastructure Library, now just ITIL)
- not mentioned in this text; see the ITIL official site
for more information; it was created by the British government and has
become a world wide standard
- The image on the right links to another standard, from a hardware
vendor. You may find that the model offered by Cisco
explains the concepts more clearly than the web site above.
The text continues with a section on standards. Note that the
definition at the top of of this web page only says a standard contains
steps to follow to be compliant with a policy. The policies are meant
to be general, and related standards are meant to be more specific.
This often means that standards need to be:
- clearly written (so people will understand them)
- repeatable (so the same results can be expected)
- pursuing a known goal (part of the policy)
- applicable to the people following them (so those people
can actually perform the steps)
Page 157 discusses two types of standards:
- Issue specific standard - This kind of standard can relate
to new technology or a new situation.
- Issue statement - This part of the standard would commonly define
terms used to discuss it, define what the perceived risks might
be, and what employees are expected to do.
- Organization position - Why does the organization want us to follow
- Applicability - What is the scope of the policy and this standard?
Specific rules about how to apply the standard.
- Roles and responsibilities - If the standard requires approvals,
who approves and who makes requests.
- Compliance - This is the part that tells us what people are not
allowed to do, how they will be monitored, and what discipline is
to be expected for noncompliance.
- Points of contact - Who to ask if you have questions, where to
find this standard in the library, who to ask for help if the standard
does not work.
- System specific standard - A standard for a system (like a
network, or an application with many users)
- Who is allowed to use this system?
- Are only specific users allowed to modify it? If so, who are they?
- Are there firewall rules, domain rules, or port rules for this
system? This is especially important for public facing systems.
- Are users allowed to access the system remotely? Must they use
a VPN to access it?
The text continues with a discussion about procedures and why
we need them. Typically, a procedure is used when a standard has a large
scope, and it must be followed differently by people in different jobs,
or who are operating in different countries. The things a standard tells
us to do usually are smaller in scope than the standard that it modifies,
because of job duties or because of local regulations that differ from
place to place.
Guidelines are mentioned briefly. The text observes that guidelines
start out as suggestions, which often become standards if
they work out well.
The text reminds us that policy frameworks, like anything else in business,
may be affected by their cost and by the impact of their
controls on employees, customers, and business processes.
There is no way a program that is too costly can be adopted. Likewise,
we cannot introduce security in a way that keeps our employees from working
or keeps our customers from doing business with us.
The text reviews the five pillars of Information Assurance, reminding
us that our policy framework must support all of them. They were discussed
in lesson 1:
- Confidentiality - we do not allow access to any resource unless
there is a reason for that access
- Integrity - making sure that no one changes data who has not
been authorized to do so
- Availability - data must be available to authorized users when
they need it
- Authentication - the security needs of the system must be matched
by the level of confidence we have in a user's identity
- Nonrepudiation - tracking of events and files must prove that
a particular user took action, authorized access or payment, or simply
was on the system
The text amplifies on this theme a bit, listing some other risks that
our framework should guard against:
- Unauthorized access
- Unauthorized use
- Unauthorized disclosure
- Disruption of services
- Destruction of assets
The text also offers some best practices regarding policy frameworks:
- Let the staff know about the framework - no one follows rules they
do not know about
- Remind staff about the framework - make people aware that security
is also up to them
- Select a framework model that fits your organization, then customize
it as needed
- Learn from the mistakes of other companies - I recommend that you
regularly read Brian Krebs' website, Krebs
on Security for news and analysis
The chapter begins with some advice about writing all of our security
documents clearly. It implies that we should be using a middle of the
road grade level for our documents, making them easy for most people to
understand. I am not surprised that the author finally gets around to
saying that we should answer the six basic questions I mentioned in the
ITS 421 class this term. Let's use the same reference:
This is another way of looking at the
rules you need to implement on your network. Explain them. A good
idea is to memorize a line from Rudyard
Kipling about six
honest serving men:
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
(The rest of the poem is not important in this context. Yes, you should
read poetry. And science fiction, and detective stories, and lots of other
- Who does this policy affect?
- Why is the policy needed?
- What is the policy about? What are we allowed to
do and not allowed to do?
- When is the policy going into effect? When are we
subject to it, and when are we not?
- Where does this policy apply? Only at home? Only at remote
- How will it be monitored? How will compliance be
measured? How do we request exceptions or report problems?
The author takes a moment for another point before continuing on this
topic. He quotes another text on page 176, to illustrate the idea that
some security framework models use an Architecture approach. This
is the approach taken by the Cisco model that is linked above.
So what is architecture, with regard to frameworks? If you search the
web for an answer, you will find other definitions than the one the author
intended, so let's examine his concept.
Consider the diagram on page 177. It shows a classic four by four grid.
The x axis shows increasing service standardization from left to right.
The y axis shows increasing service integration from bottom to top.
|High Service Integration
|Low Service Integration
|| Low Standardization
In the chart above, I have shown the same data, but added some color.
The progression from low to high service integration (purple scale),
considering only that change, takes us from a diversified model
to a coordinated model.
- Diversified - this model does not share data well from one
entity to another, systems are independent and require knowledge of
each one to support them
- Coordinated - this model can share data across the enterprise,
making it a better solution; this model is achieved by more standardization
The progression from low to high service standardization (blue
scale), considering only that change, takes us from a diversified
model to a replicated model.
- Diversified - this model does not use the same services from
one entity to another, services vary across locations and systems
- Replicated - this model has common services across the enterprise,
providing a common, more familiar interface, making it a better solution;
this solution is achieved by more central control of services
The last option includes both levels of integration, taking us to a unified
- Unified - this model has the benefits of both of the better
models, it can share data across the enterprise and it has common services
across the enterprise, making it the best choice
The text presents a long list of principles on pages 178 and 179
that should guide us in making policies. They are guides, not rules, so
we should use our judgement when making policies which become rules. Some
highlights from the list:
- Accountability - Make it clear whether a person is responsible
only for his/her own actions, or for those of all people
below him/her in the organization chart
- Awareness - Tell people what the rules are, remind
them from time to time, and make the rules easy to find on the
organization's internal web site
- Multidisciplinary - Tell people in every type of job
what they need to know to do their job correctly in compliance with
- Integration - make sure your policies support each other
and do not contradict each other
- Defense in depth - make sure that we have multiple layers
of defense, and that controls are different from one layer to
the next, so a particular exploit will not be able to penetrate all
layers of defense
Several other principles are valuable as well, so you should read
all of them. Let's have a discussion about them on Blackboard this
A classic point of confusion is covered on page 180 and 180. The text
presents two different methods of categorizing security controls.
Remember that any control will fit in both categorizations,
not just one of them. They were also mentioned in chapter 2.
Categorizations based on control type (and who would administer it):
- Physical controls - These
include any physical barrier, like a locked door or a fence, as well
as security cameras and guards
- Administrative controls -
These include the procedures
to create security policies and the security
policies themselves. Security policies are rules about
"the actions that users may
do, must do,
and must not do". I
have reworded it here, because "cannot" and "must not"
do not mean the same thing.
- Technical controls - Actions
that are performed by devices
(technical solutions), such a firewalls denying packets.
Categorizations based on the function of a control:
controls - used to discourage
attacks; applied before an
attack; example: warning attackers
that we are protected
- Preventive controls - used
to prevent attacks; applied
before an attack; example:
using a firewall to block traffic
for specific ports; these controls are typically automatic controls
- Detective controls - used
to detect an attack or intrusion; applied during
an attack; example: using a Intrusion
Detection System; these controls are typically manual
- Corrective controls - used
to reduce damage and restore
to service; applied after
an attack; example: using an emergency
cleaning program on a USB memory stick, so that a computer can
controls - alternative controls that are used when normal controls are
not possible; applied during
an attack; example: disabling switch
ports to isolate devices or LAN segments
controls - any type of control may be a mitigating control if it finds
or notices errors and presents
a method to correct them
- Recovery controls - controls that restore service to its state
before the attack
The highlighted categorizations above are the ones your text does not
Moving ahead to page 185, the text begins several pages of sample templates.
There is a template for a policy, a standard, a procedure,
and a guideline. If your employer has been using such documents
for a while, there is probably an enterprise standard you would
follow. If this is not the case, the samples offered in the chapter give
you an excellent place to start making a template for your organization.
Let's do one or two of those as an assignment this week. The best
way to provide a job aid like this is to provide both the template and
an example of your enterprise documentation that uses it. As an assignment,
follow the template for a policy that starts on page 185, and write a
policy that would make sense to you.
The text begins a new section on page 190 about creating and implementing
policies. It lists four steps, but it expands on each of them.
- Building consensus on intent - This means to consult the various
authorities in your organization about the policy itself. What is the
policy about, and why are we writing it? These questions
must be answered before you can begin to write it. The authorities are
approving the concept of the policy at this stage, not its final version.
- Reviews and approvals - In a sense, this is the same as the
step above, except that it happens after each draft of the policy
document. Note the list on page 191 of four types of staff who should
review the policy for its accuracy and compliance with other policies
and procedures in the organization:
- Technical personnel
- Legal authority
- Human Resources
- Audit and compliance staff
- Publication - There should be a library of some sort,
whether a shared folder in the file system, an intranet web site, or
another form of data sharing within your organization. The text mentions
placing the original documents in the library with links to PDF
copies. In practice, it is often best to keep the originals off line,
and to store PDF versions as the ones the general staff may access.
In a well run library, there will be follow up dates for reviews, revisions,
and eventual retirement of policies.
- Awareness and training - As we have discussed before, the organization
has an obligation to inform staff about new or changed
policies, to keep them aware of continuing issues, and to train
or educate staff as needed to perform their jobs properly under
such policies. Training means to show someone how to do a job. Educating
means to teach someone how a thing works, so they might think for themselves
as needed, and continue to learn about the tools in question.