SMBs - Hierarchy of Business-Security Documents 2015-11

ABW Consulting Services
© 2014-2015. ABW Consulting Services. All Rights Reserved.
Relating to Business Strategies & Operations
to Cyber Security Policies & Procedures
(Rev. 11/20/2015)

Introduction
 Background
Best practices for Information Security Programs involve a hierarchy of documents; although,
many organizations (both large and small) may not have resources (or intention) to create and
implement all of the identified documents. At a minimum (for “common practice”), there should
always be operational level policies that dictate what can and cannot be done and procedures
that provide steps for how to protect an organization’s information assets.
The sets of documents are divided into Organization-Level and Operational-Level.
 Organization-Level Documents
These documents are comprised of overarching business strategies which set the overall business
purpose and direction for a 3- to 5-year period. These documents are generally reviewed on an
annual basis, but only updated when necessary, at least every 5 years. Approval authority for
these documents belongs to an organization’s governing body (e.g., Board of Directors) or
Executive Committee (e.g., President/CEO, CFO, COO, CIO, etc.), depending on the size of the
business and its governance structure. How these strategies are implemented fall under the
Operational-Level Documents.
2

Introduction (cont’d)
 Operational-Level Documents
In order to implement the upper-level strategies, an organization should have operational policies
to dictate what should or should not be done (i.e., what is allowed or prohibited), and operational
procedures to dictate how things are done. In addition, an organization may have specific
standards or guidelines providing technical details in support of specific policies or procedures
(e.g., defining password complexity requirements). Having these three operational levels of
documents (policies, procedures, and standards/guidelines) can assist organizations in making
changes as technologies evolve, because each document type has a different source and approval
level.
Unlike the higher level strategy and policy approval requirements, usually operating procedures
and standards can be approved and implemented with department-level approvals (e.g., under
authority of the CIO, IT Director or an organizational IT governing board/committee); although
they should also require review by some sort of IT Security Committee, depending on the
organization’s governance structure and process. This means the procedures and standards,
which the policy should require to be reviewed at least annually, can be amended and updated as
needed to keep pace with changes in technologies, without all the higher level political processes
(by a governing body).
3

Typical Hierarchy of
Documents
4

Risk Management Plan
(Information Assets Risk Analysis Matrix)
5

Typical Organization
Documents
6

Documents (cont’d)
7

Organization-Level
Documents
 Business Plan (or Business Strategy)
 Includes Vision, Mission, Purpose, Business Strategies
& Financial Forecasts (3–5 year outlook)
 Reviewed Annually, Updated Every 3–5 Years
 Risk Management Plan
 Identification of primary business risks and potential
impacts (matches 3–5 year period for Business Plan)
 Strategies for risk avoidance and risk mitigation
 Includes levels of “acceptable risk”
 Plan and strategy for addressing physical, economic,
and cyber risks
8

9

Organization-Level
 Information Technology Strategy
 Direction for use of Technology (3–5 year horizon)
 Outline of Near-Term Action Plans (1–3 years)
 Information Security Strategy
 Direction for Securing Organization’s Critical
Information (3–5 year horizon)
10

Operational-Level
Documents
 Overview
The following Operational-Level Documents, which are considered subordinate to
organizational strategies, should be created and implemented to execute the organization’s
Information Security Program. Those documents, marked with an asterisk (*) below, are
considered to be mandatory and necessary components for successful implementation of a
security program.
(NOTE: policy titles will vary from one organization to another.)
 Business Continuity & Disaster Recovery Plan
 Information Technology Disaster Recovery Plan *
 Physical Security Plan
(continued on next page)
11

Operational-Level
 Information Security Policy *
 Information Security Standards *
 Information Classification Standards *
 Data Security & Encryption Standards
 Identity Management Procedures
 Information Security Audit Procedures
 Information Security Testing Procedures
 Computer Security Incident Response Plan/Policy *
 Acceptable Use Policy *
 Red Flags Program Policy (1)
(1) Dependent on federal law applicability
12

Document Descriptions (1)
 Business Continuity & Disaster Recovery Plan
“Business Continuity” refers to the ability to maintain a sustainable level of
business operations over an extended duration (weeks to months) after a major
disaster.
“Disaster Recovery” refers to the ability to restore some critical operational
services in the immediate time period (hours to days) after a disaster.
This plan will usually have an organization-wide component, and may also have
division-level, department-level or workgroup-level plans which are more
focused on the near-term recovery from a disaster and then for continuing,
longer term business operations. This plan should contain a component for how
IT services and data will be used for longer term business continuity. This
document may also be referred to as a “Continuity Of Operations Plan” (COOP).
13

 Information Technology Disaster Recovery Plan *
This plan is for the more immediate recovery of IT data and services, to support the
organization’s business functions in the case of a disaster; it must include how data
and services (e.g., hardware and software) will be backed up or replicated, usually in
off-site storage of backup files/media and creation of “warm” or “cold” data center
facilities (or having redundant equipment within an existing facility).
 Physical Security Policy
This policy should be tightly coupled with the Information Security Policy, and
should cover the organization’s necessary site/facility and personnel security
measures for day-to-day operations.
14

Typical Policies
15

 Information Security Policy *
This policy provides for the overarching protection of the organization’s
information and technology assets; which must be applicable and enforceable
across all divisions, departments, and employees, as well as anyone else who
has access to the organization’s systems, and include third party vendors,
partners, and clients; the policy must reference applicable standards and other
subordinate documents (e.g., operating procedures) which provide the technical
definitions and details about how the policy is to be implemented. The policy
should contain a requirement for training of employees and acknowledgement
they understand the policy.
16

Typical Procedures &
Standards
17

 Information Security Standards *
These are internal standards, usually adopted by an IT governance board, which
provide details about security configurations, settings, and other applicable
standards (e.g., password complexity and auto-expiration) to implement the
related policies; these standards should coincide with adopted national or
international standards (e.g., NIST, ISO/IEC, COBIT).
 Information/Data Classification Standards *
These standards define the different classification levels (or types) of information
or data which must be secured; starting with open and accessible “public
information,” to “internal (sensitive) information” (which may still be subject to the
California Public Records Act or federal Freedom of Information Act),
“personal/private information” (e.g., related to employees and their benefits), and
“confidential information.” The security standards and security policy should
dictate who (by job role) is authorized to access which levels of information and
what controls should be in place for each level of protection. The policy also
needs to specify roles and responsibilities of Data Owners and users.
18

 Data Security & Encryption Standards
These standards help define what measures, including encryption, need to be
used for data at rest (saved on storage media), data in transit (active network
traffic), and data in use (part of an open user application); and should also include
when different levels of encryption are required, especially when transmitting
confidential data to external parties (e.g., employee benefits data sent to an
insurance carrier).
 Identity Management Procedures
These procedures (including user roles and access controls) define the lifecycle of
a user account, from initial request (for internal employees or any non-employees
who are authorized to access the organization’s systems), account creation with
user roles/groups assigned to limit access rights only to those systems and
applications allowed, disabling an account after a specified period of inactivity
(non-use), and terminating an account when the person leaves the organization.
19

 Information Security Audit Procedures
These procedures should be aligned with other standards (e.g., COBIT, ISACA)
and dictate the types and frequencies of security audits to be performed, as well
as who the audience will be for different audit results - some may be for internal
use only, while others may be public information.
 Information Security Testing Procedures
These procedures define the types and frequencies of security testing to be
performed; this can range from simple tabletop exercises, to other pen-and-paper
drills or using a virtual environment to test security staff skills, to internal or
external penetration testing of actual organizational networks and systems (using
internal staff or hiring a certified security tester).
20

 Computer Security Incident Response Policy *
This policy dictates roles, responsibilities, and provides a plan of action to be
taken before, during, and after a “Computer Security Incident,” based on
identified standards and best practices. This Incident Response Plan follows the
same general procedures as Crisis Management or Emergency Management,
with a goal of stopping and containing the security breach or other identified
security event (e.g., malware infection, denial of service attack or web site
defacement), and restoring systems to normal operations. This policy also
provides steps for preserving potential evidence, when there might be future
legal action (either criminal or civil).
21

 Acceptable Use Policy *
This policy dictates what is acceptable use, and what is not acceptable use, of the
organization’s IT resources, specifically including Internet access and Email, and
including whatever other systems the organization wants to address (for example:
telecommunications devices, cell phones, smart phones, etc.).
 Red Flags Program Policy (**)
This policy (Identity Theft Awareness & Training) must be adopted and approved by
the governing body (i.e., Board of Directors) and must affirmatively state that the
organization has a program in place (as defined within the policy) for training
employees in the recognition of “red flags” that indicate possible identity theft;
including what actions employees should take with affected customers, and also what
steps the organization takes to help make its customers aware of identity theft issues
and how they can recognize when they might be a victim.
(**) May be required by federal law, depending on “creditor” status.
22

Prioritizing Information
Security Measures
Most of the preceding documents will usually contain some basic information
related to a particular Information Security strategy, plan, policy, procedure or
standard, which is understandable to non-technical staff and managers. The
lower level documents (especially procedures and standards) will contain more
complex and technical details related to the functions and responsibilities of the
IT group and Information Security staff. One of the responsibilities of the
highest level person in charge of overall Information Security (e.g., Chief
Information Security Officer or Information Security Manager), is to translate
the lower level technical details into simple business management language, so
that non-technical managers can participate in prioritizing which security
measures are to be implemented over a certain period of time and at a certain
cost limit. A key to the success of having necessary Information Security
controls implemented is to relate specific measures to their ability to reduce or
mitigate a business risk. The goal will be to first protect those Information
Assets with the highest risk and work through the priorities for each asset at
decreasing levels of risk until management is willing to accept a risk without
implementing any security measure (based on prior business risk analysis).
23

SMBs - Hierarchy of Business-Security Documents 2015-11

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à SMBs - Hierarchy of Business-Security Documents 2015-11

Similaire à SMBs - Hierarchy of Business-Security Documents 2015-11 (20)

SMBs - Hierarchy of Business-Security Documents 2015-11