Home > Articles > Security > Network Security

Security Program and Policies: Governance and Risk Management

  • Print
  • + Share This
  • 💬 Discuss
This chapter is from the book
This chapter explains how to manage information security policies, describes roles and responsibilities related to information security, identifies the components of risk management, and shows how to create polices related to information security policy, governance, and risk management.

Information Security Policies (ISO 27002:2013 Section 5) and Organization of Information Security (ISO 27002:2013 Section 6) are closely related, so we address both domains in this chapter. The Information Security Policies domain focuses on information security policy requirements and the need to align policy with organizational objectives. The Organization of Information Security domain focuses on the governance structure necessary to implement and manage information security policy operations, across and outside of the organization. Included in this chapter is a discussion of risk management because it is a fundamental aspect of governance, decision making, and policy. Risk management is important enough that it warrants two sets of standards: ISO/IEC 27005 and ISO/IEC 31000.

Understanding Information Security Policies

Information security policies, standards, procedures, and plans exist for one reason—to protect the organization and, by extension, its constituents from harm. The lesson of the Information Security Policies domain is threefold:

  • Information security directives should be codified in a written policy document.
  • It is important that management participate in policy development and visibly support the policy.
  • The necessity of strategically aligning information security with business requirements and relevant laws and regulations.

Internationally recognized standard security standards such as the ISO 27002:2013 can provide a framework, but ultimately each organization must construct its own security strategy and policy taking into consideration organizational objectives and regulatory requirements.

What Is Meant by Strategic Alignment?

The two approaches to information security are parallel and integrated. A parallel approach silos information security, assigns responsibility for being secure to the IT department, views compliance as discretionary, and has little or no organizational accountability. An integrated approach recognizes that security and success are intertwined. When strategically aligned, security functions as a business enabler that adds value. Security is an expected topic of discussion among decision makers and is given the same level of respect as other fundamental drivers and influencing elements of the business. This doesn’t happen magically. It requires leadership that recognizes the value of information security, invests in people and processes, encourages discussion and debate, and treats security in the same fashion as every other business requirement. It also requires that information security professionals recognize that the true value of information security is protecting the business from harm and achieving organizational objectives. Visible management support coupled with written policy formalizes and communicates the organizational commitment to information security.

Regulatory Requirements

In an effort to protect the citizens of the United States, legislators recognized the importance of written information security policies. Gramm-Leach-Bliley Act (GLBA), Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley (SOX), Family Educational Rights and Privacy Act (FERPA), and the Federal Information Systems Management Act (FISMA) all require covered entities to have in place written policies and procedures that protect their information assets. They also require the policies to be reviewed on a regular basis. Each of these legislative acts better secured each person’s private information and the governance to reduce fraudulent reporting of corporate earnings.

Many organizations find that they are subject to more than one set of regulations. For example, publicly traded banks are subject to both GLBA and SOX requirements, whereas medical billing companies find themselves subject to both HIPAA and GLBA. Organizations that try to write their policies to match federal state regulations find the task daunting. Fortunately, the regulations published to date have enough in common that a well-written set of information security policies based on a framework such as the ISO 27002 can be mapped to multiple regulatory requirements. Policy administrative notations will often include a cross-reference to specific regulatory requirements.

User Versions of Information Security Policies

Information security policies are governance statements written with the intent of directing the organization. Correctly written, policies can also be used as teaching documents that influence behavior. An Acceptable Use Policy document and corresponding agreement should be developed specifically for distribution to the user community. The Acceptable Use Policy should include only pertinent information and, as appropriate, explanations and examples. The accompanying agreement requires users to acknowledge that they understand their responsibilities and affirm their individual commitment.

Vendor Versions of Information Security Policies

As we will discuss in Chapter 8, “Communications and Operations Security,” companies can outsource work but not responsibility or liability. Vendors or business partners (often referred to as “third parties”) that store, process, transmit, or access information assets should be required to have controls that meet or, in some cases, exceed organizational requirements. One of the most efficient ways to evaluate vendor security is to provide them with a vendor version of organizational security policies and require them to attest to their compliance. The vendor version should only contain policies that are applicable to third parties and should be sanitized as to not disclose any confidential information.

Client Synopsis of Information Security Policies

In this context, client refers to companies to which the organization provides services. A synopsis of the information security policy should be available upon request to clients. As applicable to the client base, the synopsis could be expanded to incorporate incident response and business continuity procedures, notifications, and regulatory cross-references. The synopsis should not disclose confidential business information unless the recipients are required to sign a non-disclosure agreement.

Who Authorizes Information Security Policy?

A policy is a reflection of the organization’s commitment, direction, and approach. Information security policies should be authorized by executive management. Depending on the size, legal structure, and/or regulatory requirements of the organization, executive management may be defined as owners, directors, or executive officers.

Because executive management is responsible for and can be held legally liable for the protection of information assets, it is incumbent upon those in leadership positions to remain invested in the proper execution of the policy as well as the activities of oversight that ensure it. The National Association of Corporate Directors (NACD), the leading membership organization for Boards and Directors in the U.S., recommends four essential practices:

  • Place information security on the Board’s agenda.
  • Identify information security leaders, hold them accountable, and ensure support for them.
  • Ensure the effectiveness of the corporation’s information security policy through review and approval.
  • Assign information security to a key committee and ensure adequate support for that committee.

Policies should be reviewed at planned intervals to ensure their continuing suitability, adequacy, and effectiveness.

Revising Information Security Policies: Change Drivers

Because organizations change over time, policies need to be revisited. Change drivers are events that modify how a company does business. Change drivers can be demographic, economic, technological, and regulatory or personnel related. Examples of change drivers include company acquisition, new products, services or technology, regulatory updates, entering into a contractual obligation, and entering a new market. Change can introduce new vulnerabilities and risks. Change drivers should trigger internal assessments and ultimately a review of policies. Policies should be updated accordingly and subject to reauthorization.

Evaluating Information Security Polices

Directors and executive management have a fiduciary obligation to manage the company in a responsible manner. It is important that they be able to accurately gauge adherence to policy directives, the effectiveness of information security policies, and the maturity of the information security program. Standardized methodologies such as audits and maturity models can be used as evaluation and reporting mechanisms. Organizations may choose to conduct these evaluations using in-house personnel or engage independent third parties. The decision criteria include the size and complexity of the organization, regulatory requirements, available expertise, and segregation of duties. To be considered independent, assessors should not be responsible for, benefit from, or have in any way influenced the design, installation, maintenance, and operation of the target, or the policies and procedures that guide its operation.

Audit

An information security audit is a systematic, evidence-based evaluation of how well the organization conforms to established criteria such as Board-approved policies, regulatory requirements, and internationally recognized standards such as the ISO 27000 series. Audit procedures include interviews, observation, tracing documents to management policies, review of practices, review of documents, and tracing data to source documents. An audit report is a formal opinion (or disclaimer) of the audit team based on predefined scope and criteria. Audit reports generally include a description of the work performed, any inherent limitations of the work, detailed findings, and recommendations.

Capability Maturity Model (CMM)

A capability maturity model (CMM) is used to evaluate and document process maturity for a given area. The term maturity relates to the degree of formality and structure, ranging from ad hoc to optimized processes. Funded by the United States Air Force, the CMM was developed in the mid-1980s at the Carnegie Mellon University Software Engineering Institute. The objective was to create a model for the military to use to evaluate software development. It has since been adopted for subjects as diverse as information security, software engineering, systems engineering, project management, risk management, system acquisition, information technology (IT) services, and personnel management. It is sometimes combined with other methodologies such as ISO 9001, Six Sigma, Extreme Programming (XP), and DMAIC.

As documented in Table 4.1, a variation of the CMM can be used to evaluate enterprise information security maturity. Contributors to the application of the model should possess intimate knowledge of the organization and expertise in the subject area.

TABLE 4.1 Capability Maturity Model (CMM) Scale

Level

State

Description

0

Nonexistent

The organization is unaware of the need for policies or processes.

1

Ad-hoc

There are no documented policies or processes; there is sporadic activity.

2

Repeatable

Policies and processes are not fully documented; however, the activities occur on a regular basis.

3

Defined process

Policies and processes are documented and standardized; there is an active commitment to implementation.

4

Managed

Policies and processes are well defined, implemented, measured, and tested.

5

Optimized

Policies and process are well understood and have been fully integrated into the organizational culture.

As Figure 4.1 illustrates, the result is easily expressed in a graphic format and succinctly conveys the state of the information security program on a per-domain basis. The challenge with any scale-based model is that sometimes the assessment falls in between levels, in which case it is perfectly appropriate to use gradations (such as 3.5). This is an effective mechanism for reporting to those responsible for oversight, such as the Board of Directors or executive management. Process improvement objectives are a natural outcome of a CMM assessment.

FIGURE 4.1

FIGURE 4.1 Capability maturity model (CMM) assessment.

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus