|
|
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 disscussion 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 mitigatinng 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.
|