How do you choose among the many IT security policy frameworks promoted by government agencies, corporations, and many others? There’s no simple answer. Your choice will depend on your industry, as well as your management view of risk and any bias within your organization. You should focus on selecting the standards that are widely accepted.

No security framework can prevent all security breaches. At some point, a security event will happen. It could be as simple as someone sharing a password with someone else or loaning a security badge to a colleague to provide (unauthorized) access to a restricted data center. Or it could be a criminal stealing customer data. Whatever the security event, an assessment of why the breach occurred and what controls failed should be conducted. Depending on the severity of the security event, regulators may ask for answers. Adopting the right security policy framework helps demonstrate to regulators that your organization followed industry norms. Equally important, the effective adoption of a security framework demonstrates that when a security event occurs, the organization can effectively respond to minimize impact to the customers and shareholders.

FIGURE 8-1 depicts a simplified framework domain model. Notice that a significant portion is dedicated to the governance and management of risks. This establishes the principle that managing risks and understanding business are core competencies. More comprehensive frameworks recognize that the effectiveness of controls relies on the understanding of the business process. Understanding the business process allows you to better identify risks and design effective controls.

Your first step is to determine the scope of coverage for your framework. Then, you can use it as a filter to make sense of the various frameworks to choose from. Even a simplified framework domain model can help you recognize your organization’s key areas of concern. You can create a framework that addresses specific weaknesses and aligns to your business requirements. Once you understand those requirements, you can use the following steps to select industry frameworks to consider:

1. Review industry regulatory requirements. For example, a government agency is required to implement the Federal Information Security Management Act of 2002 (FISMA).
2. Look to your auditors and regulators for guidance. For example, major external audit firms may have adopted Committee of Sponsoring Organizations (COSO) and Control Objectives for Information and related Technology (COBIT) as part of their controls testing.
3. Select frameworks that have maintained broad support in the industry over time. These are the frameworks that could be considered industry best practices.

Find out which frameworks are used by peer organizations. This can validate your approach. Many industries tend to share the same risks and leverage the same frameworks. TABLE 8-1 contains a sample of IT security policy frameworks. These frameworks that are commonly adopted across an industry define the best practices of an organization. Best practices are typically the common practices and the professional care expected for an industry. This is not a comprehensive list; there are other heavily used frameworks, including industry-specific frameworks. The frameworks in Table 8-1 represent different widely adopted framework approaches.

Even the short list of IT security policy frameworks shown in Table 8-1 provides a wide array of approaches and choices. Organizations often combine these frameworks to draw upon each of their strengths.

For example, a single organization could adopt the following:

• COSO for financial controls and enterprise risk management structure
• COBIT for IT controls, governance, and risk management
• ITIL for IT services management
• PCI DSS for processing credit cards
• ISO for broad IT daily operations
• CIS as a broad-based cyberdefense framework

The combination of frameworks in this example provides a comprehensive view of business risk and information security. The combination would represent an organization’s security and risk framework. It starts with COSO, which provides a strategic and financial view of risk. COBIT links business requirements with technology controls. ITIL provides best practices for delivery of IT services. PCI DSS provides highly specific technology requirements for handling cardholder data. You could also substitute ISO for any of these layers or mix and match other frameworks to create a comprehensive policy approach.

Let’s compare and contrast COBIT and ISO. Although these frameworks may overlap in the topics they cover, they differ greatly in their approach. COBIT covers broad IT management topics and specifies which security controls and management need to be in place. However, COBIT is often silent on how to implement specific controls. ISO, on the other hand, goes into more detail on how to implement controls but is less specific about the broader IT management over the controls. In this way, both frameworks complement each other. As a result, many organizations adopt both.

The power of the frameworks in Table 8-1 is in their flexibility and modularity. They are flexible in that they can align with each other or be implemented by themselves. They are modular in that you can pick and choose the component or set of objectives you wish to implement. An exception to this rule is PCI DSS. An organization required to adhere to PCI DSS must implement all of its requirements.

Risk Management and Compliance Approach

To deliver value, a framework must manage and dispose of risk daily. You will often hear the term disposal of risk. Once a risk is identified, you must decide what to do about it; you must decide how to “dispose” of it. This can mean either adding a control so risk no longer exists or accepting the risk. When you accept a risk, it doesn’t mean you ignore it. Typically, if you accept the risk, you would consider the need to monitor for it and to create a detective control. In that way, when it does occur, you can detect it and take measures to minimize its impact.

For example, suppose you are concerned about malware. Changing a firewall rule to stop individuals from browsing the Internet would reduce the likelihood of malware. This would be unpopular with employees. Beyond that, though, Internet access may be essential for the business to operate. So, you do your best to prevent as much malware as possible by installing appropriate software on the network and endpoint. Where you cannot prevent a risk, you monitor for suspicious traffic and respond as needed. In essence, you accept that no software can prevent every possible malware attack.

Although the previously mentioned frameworks all have unique approaches, they share some of the same characteristics:

• They are risk-based.
• They speak to the organization’s risk appetite.
• They deal with operation disruption and losses.

The risk appetite refers to understanding the level of risk-taking within the business. This approach understands the business and its processes and goals. It’s the overall risk the organization is willing to accept. A key measurement is the cost of risk mitigation. The risk appetite is driven by the amount of risk reduction the business is willing to fund.

NOTE

A framework that is risk-based focuses on the highest risk to the organization’s objectives. This includes considering business objectives, legal obligations, and the organization’s values.

The goal of these frameworks is to reduce operation disruption and losses. The frameworks reduce surprises. They ensure risks are systematically identified and reduced, eliminated, or accepted.

The ISACA Risk IT framework extends COBIT and is a good example of a comprehensive risk management approach. You can implement the ISACA Risk IT framework alone or as part of a COBIT implementation. FIGURE 8-2 is an overview of the Risk IT process model. The Risk IT framework is built on three domains: Risk Governance, Risk Evaluation, and Risk Response. Each of these domains has three process goals. Each process goal is broken down into key activities. For this discussion, this section will focus on domains and process goals.

The Risk Governance domain provides the business view and context for a risk evaluation. This ensures that risk activity aligns with the business goals, objectives, and tolerances. This includes aligning to business strategy. This domain ensures that the full range of opportunities and consequences is considered.

The Risk Evaluation domain ensures that technology risks are identified and presented to leadership in business terms. Formal risks are analyzed, and processes are created to assess impact. This domain also creates a risk repository of all known risks. This further enhances the risk analysis and reporting.

The Risk Response domain ensures risks are reduced and remediated in the most cost-effective manner. This domain coordinates risk responses so that the right people are engaged at the right time. This prevents risks from increasing in magnitude. Processes are established to manage risk throughout the enterprise to an acceptable level.

These domains build on each other, creating flexibility and agility. You can discover a potential threat in the Risk Evaluation domain and quickly assess its impact using the Risk Governance domain. In addition, the framework can quickly identify and coordinate a response to any risk.