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.
Security event is a term used to indicate any undesirable event that occurs outside of normal daily security operations. Typically, a security event relates to a breakdown in controls as defined by the security policies.
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:
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.
FRAMEWORK | SPONSORING ORGANIZATION | DESCRIPTION |
---|---|---|
COSO | COSO http://www.coso.org |
COSO is a framework for validating internal controls and managing enterprise risks. COSO is heavily focused on financial operations and risk management. It’s a widely recognized standard for providing reasonable assurance that an organization’s financial controls are working appropriately. |
COBIT | Information Systems Audit and Control Association (ISACA) http://www.isaca.org |
COBIT is a framework and supporting tool set that align business and control requirements with technical issues. COBIT is an international governance and controls framework and a widely accepted standard for assessing, governing, and managing IT security and risks. COBIT is extended with a series of other ISACA publications such as risk IT, which extends COBIT for IT risk management. COBIT maps to many major frameworks such as COSO, ISO, and ITIL. |
ISO | International Organization for Standardization (ISO) http://www.iso.org |
ISO has produced a vast array of standards supporting a number of different industries and business models. The ISO standards related to information security and IT risk are widely accepted as the leading international standards. The following is a sample of key ISO publications: ISO 20000—IT service management system ISO 27001—Information security management ISO 27002—Code of practice for information security management ISO 38500—Corporate governance of information security ISO 9000—Quality management |
ITIL | Information Technology Infrastructure Library (ITIL) https://www.axelos.com/best-practice-solutions/itil |
ITIL is a widely accepted international framework and set of best practices for delivering IT services. ITIL contains a comprehensive list of concepts, practices, and processes for managing IT services. |
NIST | National Institute of Standards and Technology (NIST) http://csrc.nist.gov/publications/PubsSPs.html |
The Federal Information Security Management Act (FISMA) requires federal agencies to follow a common set of security standards. These standards are provided by NIST and are known as the Federal Information Processing Standards (FIPS). |
PCI DSS | Payment Card Security Standards Council https://www.pcisecuritystandards.org/index.php |
The Payment Card Industry Data Security Standard (PCI DSS) is a security framework for any organization that accepts, stores, or processes credit cards. |
CIS Critical Security Controls for Effective Cyber Defense | Center for Internet Security https://www.cisecurity.org/controls/ |
First developed in 2008 by the SANS Institute, now managed by the Center for Internet Security. |
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:
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.
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:
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.
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.
When implementing an IT security policy framework, remember to align the framework to the business process. For example, ISO 27002 provides clear guidance and best practice recommendations on controls. This creates a clear linkage between the control and the business process. This allows you to see all the controls implemented to protect an end-to-end business process. This approach minimizes controls and prevents “silo” thinking about threats. Organizations use the frameworks to reduce costs and to meet regulatory compliance.
For example, assume you are assessing backup and recovery processes. If you follow the process, you can identify risks during the hand-off between technologies. Perhaps you can no longer restore a tape that’s been archived for several years. The backup technology in your data center was upgraded to a different format. Taking a look at the off-site inventory independent of the recovery aspect might miss this risk. Mapping out the process that controls the life of a backup tape is a better way to look at controls. A simple mapping might follow the tape from creation to transport, off-site storage, recall, recovery, and destruction.