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

BackgroundBest 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 DocumentsThese 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 DocumentsIn 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



Typical Organization 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



Typical Organization Documents (cont’d)

9



Organization-Level Documents (cont’d)

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

OverviewThe 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 Documents (cont’d)

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