|
|
ITS 305 - Security Policies and Auditing
Chapter 1, Information Systems Security Policy Management
Chapter 2, Business Drivers for Information Security Policies
Chapter 3, U.S. Compliance Laws and Information Security Policy
Requirements
Objectives:
This lesson covers three chapters. It introduces the
student to concepts that cover how policies are made and used,
and why
policies are important to an organization. Objectives important
to this
lesson:
- Information systems and information security
- Quality control and quality assurance
- Information systems security policies
- Governance and legal compliance
- How policies fit in an organization
- Threat, vulnerability, and risk
- Business risks
- Risk exposure vs. liability
- Reducing risk
- Operational consistency
- U.S. compliance laws
- Government drivers to implement regulations
- Aligning policies with regulations
- Leading practices
Concepts:
Chapter 1
This chapter begins with a definition. Information systems
security is about protecting information and the systems that
store and
process it (Johnson, page 4). This is a little circular, but the
meaning is clear. The next sentence is more precise. We protect
against
risks, because they may allow unauthorized access, use,
disclosure,
disruption, modification, or destruction of our assets. Perhaps we
should review some terms:
- Asset - information, property,
people or anything else that we care about
- Threat - a potential form of loss or
damage; many threats are only potential threats, but we
plan for
them because they might happen
- Threat agent - a vector for the threat,
a way for the threat to occur; could be a person, an event, or a
program running an attack
- Vulnerability - a weak spot where
an attack is more likely to succeed; a reason
that makes us more likely to suffer damage from an attack
- Exploit - a method of attack
- Risk - the probability
of a successful
exploit, and the impact
of that exploit (There are
ways to calculate this.)
- Policy - a plan that influences
decisions;
a guiding principle for decisions and actions;
a set of rules about what actions are acceptable
and what actions are unacceptable
The author tells us on page 5 that his discussions are from
the formal perspective of using a life cycle for creating
policies to protect our assets. The life cycle used in this
discussion
is from the Information Systems Audit and Control Association
(ISACA).
It
is described as a framework, which typically means that it is
meant to
be customized by each user. This framework is called Control
Objectives for Information and Related Technology (COBIT).
The
text tells us that the COBIT information systems security
management life cycle consists of four domains. That
is a
hint to us that each of them is about one phase of
the
process, and each of them includes many parts.
The four domains:
- Align, Plan, and Organize
- Build, Acquire, and Implement
- Deliver, Service, and Support
- Monitor, Evaluate, and Assess
As you may notice, these four domains apply very well to
system development processes, which is helpful. Policies may need
to be
developed for a system as it goes through the stages of
development.
The four domains are meant to be done in sequence,
each building on the work
of the previous domain.
Align, Plan, and Organize (First Domain)
Moving ahead to page 6, the author begins a discussion of the first domain: Align,
Plan, and Organize. Note in
the graphic on page 6 that this domain is the only one that
provides
input to more than one successor. It's outputs
flow to the second and third domains.
The Align, Plan, and Organize
domain is where we learn about the user requirements, the needs of
the
organization, and the goals of the organization. We should be
thinking
about new policies that
may be
needed, about managing the IT
assets,
and about Service Level
Agreements
(SLAs). The text stresses
SLAs. These are agreements
about the
services we will receive, and about the services we will provide.
In
either case, the agreement should specify:
- what service will be provided?
- under what circumstances is it provided?
- with what frequency or standard of promptness is it
provided?
- what level of performance is acceptable?
- how will these criteria be monitored?
- what is the recourse to be followed if this SLA is not met?
The text recounts a few details about the Target data
breach of 2013. Read
the article on Mr. Krebs' web site (you have to scroll a bit to
see it)
and you will see that the author agrees with the reports when he
says
that Target did not establish a necessary security control, or did
not
enforce it. This points out the necessity of having proper
controls,
and making sure they are being used.
This phase includes identifying the threats,
vulnerabilities, and risks associated with this
organization and its activities. This knowledge is handed off to
the
people who conduct the next phase.
Build, Acquire, and Implement (Second Domain)
This domain assumes we have obtained the requirements for our
system in the previous phase. The word build
might be
better understood as design
and create.
The text points out that creating policies
and controls cannot be
done
without proper input from the previous phase. This phase also is
concerned with changes to
existing systems,
adding new systems, and managing the changes that will
take
place. The people working on this phase need to plan
for and manage the changes that will take place
for the
systems and the people who use them.
The text lists several outputs for this phase:
- equipment is acquired and implemented
- policies, procedures, and guidelines
are written
- controls are built into the systems
- teams are trained
Deliver, Service, and Support (Third Domain)
In this phase, risks are minimized. The text tells us that
this phase makes changes to any controls, policies,
procedures, contracts, and SLAs that are
not working, based on observations, reports, and data on
operations.
This assumes that you can still make changes in contracts
and
SLAs. Some environments would not have those options once such
agreements are in place.
The text lists several outputs for this phase:
- contracts and SLAs may be modified
- daily operations are monitored, managed,
and supported
- operational problems, configuration
problems, and security issues are examined and resolved
Monitor, Evaluate, and Assess (Fourth Domain)
Controls are tested and monitored in
this phase. Testing takes place on the entire environment.
We
determine whether the controls are serving the big
picture
goals (business requirements, strategic goals) of the
organization. The
system is assessed and audited several ways:
- Self-assessment - usually performed by internal
quality assurance and quality control staff
- Internal Audit - people inside the
organization perform the audit and report to a
controlling body
or committee
- External Audit - an outside entity performs
the audit, concentrating on organizational aspects that require
an independent
agent's view
- Regulator Audit - done when aspects of the
organization fall under government regulation or legal
requirements
Information Assurance
The text introduces a new concept on page 9. We are told that Information
Systems
Security (ISS) is concerned with protecting all
of our organization's information. We are also told that Information
Assurance (IA) is a subset of ISS. IA
is
concerned with protecting information that is being
processed or being used. Why do we care about that
subset?
The text makes it a bit clearer by listing the "five pillars of
the IA
model". You will recognize most of them:
- Confidentiality - a concern of ISS and IA
- Integrity - a concern of ISS and IA
- Availability - a concern of ISS and IA
- Authentication - a concern of IA
- Nonrepudiation - a concern of IA
This makes no sense, because we have already been told that IA
is part of ISS. There seems to be agreement on lots of web sites,
including the Department
of
Defense, that IA does embrace these five concepts. So, what
about the two new ones?
- Authentication - making sure of a user's identity
- Nonrepudiation - keeping records of what users do on
the system
The two concepts, when taken together, mean that we have confidence
about who we have allowed into our system, and we are
tracking what they do, so there is no denying
(repudiating) their actions. The text continues with a longer
discussion on each of the five points.
- Confidentiality - the text uses the phrase "need to
know" as a measure of this concept; 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; this may be done by imposing
limits
on access, or by limiting the kinds or level of changes a user
is
allowed to make, such as restricting a user's view to data they
actually own
- 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, perhaps requiring multifactor and biometric ID in some
cases
- Nonrepudiation - tracking of events and files must
prove that a particular user took action, authorized access or
payment,
or simply was on the system; this can include digital signatures
being
placed on everything a user processes
Governance
Governance is usually implemented as a process
of approval or disapproval of all significant
changes to a system. As the text explains, a good governance
process will examine the rules that it enforces and
recommend
changes to them when they do not, should not, or should no longer
apply
to the requests that are being turned down. The text also points
out
that when the process of approval/denial takes place before
an action is taken, that makes it a Quality Assurance
process.
If the process of approval/denial takes place after
an
action is taken, that makes it a Quality Control process.
A typical governance process will consist of several layers,
attempting to coordinate requests with the operational and
strategic
needs of various elements of the organization. It is often true
that a
request will have to go through several layers of approval before
it
runs into a need that creates a conflict. Examiners on committees
at
each level need to have an understanding of the big picture, and
of the
needs of their specific organizational areas. Governance is
especially
important when processes are examined by government auditors, and
can
show that an organization is making the best effort possible to
comply
with laws and regulations.
Policies
 I think the author started on the wrong
track this time. A policy is not a document, or even a series of
them, although a policy is often stored that way. A policy
is a rule, or a set of rules, that affects how we
want our organization and its employees to function.
As the text states, the idea behind a policy may start with a principle,
which is often a broad, general statement of what we believe to be
right, true, or beneficial. A policy is
more detailed, and more specific about what we expect our people
to do. The list on page 16 shows us a hierarchy of related
concepts:
- Principle - a general statement about what we
believe or require in our area of authority (we will use only
two
computer vendors at a time); what we expect
- Policy - 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
- Standard - 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
- 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
- Guideline - 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 better
- Definitions - when there is room for misinterpreting
any of the above items, definitions should be offered to clarify
their
language and intent; if you didn't understand something, read
this
The set of related concepts above needs a name, so the text
refers to the set of all such items that relate to each other as a
policy
framework. Note that the items near the top of the list are
more
general, and they become more focused and specific as we move down
through the first four bullets. The text spends several pages
telling
us why policies (and the other items in a policy framework) are
important and needed.
- They are the first line of defense from internal and
external attacks.
- They control and manage changes to our systems.
- They provide a statement about who does what in an
emergency.
- They reduce the cost of wasted or counterproductive efforts.
- They provide a means to comply with laws and regulations.
The text warns us that simply making a policy does not
guarantee it is a good policy. Policies should be reviewed
before and after they are put in place. New
policies or revisions may be needed when processes are
changed,
when systems are changed, when "improvements" are
made,
and when problems are being resolved.
Chapter 2
Chapter 2 begins with discussion of business drivers,
The most obvious one is money.
The chapter presents some examples of data breaches that caused
companies to spend millions of dollars in reparations to customers
whose personal data were exposed. In a case like that, there is
also
the loss of good
will and customer
loyalty to be considered,
which will affect future earnings for the company. When a breach
is the
result of improper or missing precautions, the company may be
subject
to fines from the government as well.
So, what do we do? As the text has already explained, we need
useful security policies. We also need security
policy
compliance:
the people in the organization need to follow the policies. People
are
not always thinking about security, so we need to create security
controls which can be devices,
procedures, or policies
that are meant to increase security for an enterprise. Increasing
security can also be
described as decreasing risk.
The text begins
by saying that we could classify security controls as one of three types:
- 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 cannot do".
- Technical controls -
Actions that are performed by devices
(technical solutions), such as firewalls denying packets.
The author goes on to explain that all three types of
controls
have the same subtypes. Deterrent and Compensating
controls are not listed
in this text.
- Deterrent 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
controls
- 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 be usable
- Compensating
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
- Mitigating controls
- any type of control may be a mitigating control if it finds or
notices errors and
presents a
method to correct them
The text warns us to avoid having too many
policies and too many controls. People will be lost if there are
too
many to remember, and they will have little chance of complying if
the
the policies and controls are too hard to follow. Make fewer
policies, and make controls easy
to use to get better compliance.
The text tells us that we will benefit from a security
awareness program for our employees. Employees whose daily jobs do
not
address security issues need to be reminded about the rules we
need
them to follow. The text offers a list of principles that apply to
employee training and awareness programs:
- Repetition - reminding
users about security
issues from time to time helps them stay aware of them
- Onboarding - new
hires should be made aware of security policies when they start
their
jobs
- Support - policies
should be supported from all
levels of the organization, starting at the top
- Relevance - tell
employees why we have
rules,
not just that we have them
- Metrics - measure
your success by asking employees what they know or have learned
The text explains that a reduction in risk will occur with a
successful security awareness program.
The text spends some pages talking about various kinds of
assets to protect. We should assume we want to protect all of
them.
Let's skip to another objective on page 45. We are told that a
business liability happens when a business cannot
meet its obligations.
These obligations come in two types: legal obligations and
promised
commitments. Legal obligations are, of course, things the
organization
is required to do by law. Promised commitments are related to
explicit
or implicit contracts, such as failing to provide a promised
product or
service.
The text tells us we should have policies to protect the
company from the actions of employees that may create a liability.
There are five recommended steps on page 46 that support this
concept:
- Policy - Have
clearly stated policies about customer information that inform
our
employees of their responsibilities.
- Enforce - The text
says to "express strong disapproval when policy is not
followed". I
think we need to clearly state that there is progressive
discipline that will be applied when employees do not follow
policy.
- Respond - Incidents
that cause a breach of security require a quick and effective
response
to limit damage, and to correct problems when they arise.
- Analyze - Determine
the cause of problems, and resolve those causes.
- Educate - Train
employees in their duties, and in security concepts that affect
their
jobs.
One of the critical policies you should have is an Acceptable
Use Policy, which tells
employees what they are and are not allowed to do with the assets
of
the organization, such as telephones, cameras, computers, and
links to
the Internet.
The chapter ends with some thoughts about operational
consistency. There
should be policies that address doing things well and doing them
the
same way every time (assuming we have the kind of operation that
needs
such a policy).
- Manage - Manage how
processes are done, and respond to deviations from processes
- Measure - Measure
our outputs, such as volume, consistency, quality, waste,
production
cost
- Review - Assess
processes and products to make sure both are acceptable
- Track - Report,
analyze, and record defects, errors, and incidents
- Improve - Make
changes to policies and procedures as needed
Chapter 3
The text discusses a few laws that are relevant to information
system security. Be aware that there are many others.
- Federal Information
Security Management Act (FISMA,
2002) - mandates that the Federal government and its contractors
follow
a common set of information security standards. The standards
are set
by the National Institute of Standards and Technology (NIST).
- Health Insurance Portability and Accountability Act (HIPAA,
1996) - Establishes a large, complicated rule set for storing
health
information in a common format, making it sharable, and making
it a
crime to share it with people who should not have it.
- Gramm-Leach-Bliley Act (GLBA,
1999) -
also called the Financial Services Modernization Act;
deregulated banks
and financial services, allowing each institution to offer
banking, investments, and
insurance services
Included three rules that affect privacy. The Financial
Privacy Rule allows people to opt out of having their
data
shared with partner companies, but it is usually implemented so
that it
is easier to allow the sharing. The Safeguards Rule
requires that companies have data security plans. The Pretexting
Rule tells institutions to implement procedures to
keep from
releasing information to people who are trying to gain
information
under false pretenses (pretexting). (They had to be told
to
do that?)
- Sarbanes-Oxley Act (Sarbox, 2002) - a reaction
to
corporate
fraud and corruption; provides penalties up to $5,000,000 and 20
years
in prison for officers who file false corporate reports
- Family Educational Rights
and Privacy Act (FERPA,
1974) - Requires that schools, such as colleges and
universities,
protect the privacy of their student records, and provide
students
access to their own records
- Children's
Internet
Protection Act (CIPA,
2000) - A law that means to
protect children from obscenity, pornography, and harmful
material.
This law requires libraries to use filtering software on
computers used
by minors, and also allows librarians to provide access
without the
filter to adults who request such access.
There are many other such laws. The list above only deals with
some of the ones in the United States.
In the following pages, the text recommends the selection of
an approved security framework, or model, on which to base the
creation
of the framework that will be used in your organization. It
mentions COSO,
COBIT and ITIL.ITIL is also the last topic in the
chapter. It is recommended for its relevance to IT organizations
in general.
Before the end of the chapter, we are shown a few industry
standards.
- Payment Card Industry Data
Security Standard (PCI
DSS,
2006) - A global standard for processing payments by bank cards,
credit
cards, and debit cards. It was created in 2006, but there have
been
updates since then. It requires that an organization taking
payments of
this type have and use security policies. It also requires that
the
card processor have a secure network, protect cardholder data,
manage
vulnerabilities, and have strong controls. Obviously, this
standard has
not always been followed.
- Statement on Standards for
Attestation Engagements No. 16 (SSAE16,
2010) - A standard for audits that includes standards for
security
controls. A Type I audit reviews controls, but a Type II audit
tests
the controls as well.
|
