Each community of interest has a role to play in managing the risks that an organization encounters. Because members of the information security community best understand the threats and attacks that introduce risk into the organization, they often take a leadership role in addressing risk to information assets. Management and users, when properly trained and kept aware of the threats the organization faces, play a part in early detection and response.
Management must also ensure that sufficient time, money, personnel, and other resources are allocated to the information security and information technology groups to meet the organization’s security needs. Users work with systems and data and are therefore well positioned to understand the value these information assets offer the organization. Users also understand which assets are the most valuable. The information technology community of interest must build secure systems and operate them safely. For example, IT operations ensure good backups to control the risk of data loss due to hard drive failure. The IT community can provide both valuation and threat perspectives to management during the risk management process. The information security community of interest must pull it all together in the risk management process.
All communities of interest must work together to address all levels of risk, which range from disasters that can devastate the whole organization to the smallest employee mistakes. The three communities of interest—InfoSec, IT, and general management—are also responsible for the following:
- Evaluating current and proposed risk controls
- Determining which control options are cost-effective for the organization
- Acquiring or installing the needed controls
- Ensuring that the controls remain effective
Because threats to assets are constantly changing, all three communities of interest must conduct periodic managerial reviews or audits, with general management usually providing oversight and access to information retained outside the IT department. The first managerial review is of the asset inventory. On a regular basis, management must ensure that the completeness and accuracy of the asset inventory is verified, usually through an IT audit. In addition, IT and information security must review and verify threats and vulnerabilities in the asset inventory, as well as current controls and mitigation strategies. They must also review the cost-effectiveness of each control and revisit decisions for deploying controls. Furthermore, managers at all levels must regularly verify the ongoing effectiveness of every deployed control. For example, a business manager might assess control procedures by periodically walking through the office after the workday ends, ensuring that all classified information is locked up, that all workstations are shut down, that all users are logged off, and that offices are secured. Managers may further ensure that no sensitive information is discarded in trash or recycling bins. Such controls are effective ways for managers and employees alike to ensure that no information assets are placed at risk. Other controls include following policy, promoting training and awareness, and employing appropriate technologies.
As mentioned in Module 3, policy communicates management’s intent for the outcome of an organization’s effort. For RM program development and implementation, the project leader, in cooperation with the governance group, drafts a risk management policy. This policy converts the instructions and perspectives provided to the RM framework team by the governance group into cohesive guidance that structures and directs all subsequent risk management efforts within the organization.
The RM policy, much like the enterprise information security policy (EISP), is a strategic document that formalizes much of the intent of the governance group. While no two policies are identical, most include the following sections:
- Purpose and scope—What is this policy for and to whom does it apply?
- RM intent and objectives—What is the general view of RM by the governance group, and how will that be translated into goals and objectives for RM for the entire organization?
- Roles and responsibilities—A list of the assignments and expectations for each constituent responsible for the RM program. These lists should specify who will be involved (usually by position) and what their involvement is by group:
- Oversight and governance group
- RM framework development team
- RM process implementation team (if different from framework)
- Business units
- IT department
- Information security group
For example: The chief information security officer will serve as project team leader for the RM framework development team and is responsible for ensuring completion of the framework and implementation of the process within the timelines, budgets, and other constraints specified...
- Resource requirements—A list of the resources allocated to the support of RM as a program and to the framework and process teams. The resource list should be compatible with the roles and responsibilities specified earlier.
- Risk appetite and tolerances—A summary of the expectations and preferences of executive management regarding the level of risk the organization is willing to tolerate.
- RM program development guidelines—Organization-specific instructions to guide the development and implementation of the RM effort. These could include a need to comply with specific regulations, to follow a particular methodology (which could either be incorporated into this RM project or in place of it), and any other special considerations the governance team wants to make known.
- Special instructions and revision information—Guidelines for the planned review and revision of the policy document, including information on “who,” “how,” and “when.”
- References to other key policies, plans, standards, and guidelines—A list of key documents (internal or external) that the organization should remain cognizant of during the development and implementation of the RM program.
In this stage, the framework team begins designing the RM process by which the organization will understand its current levels of risk and determine what, if anything, it needs to do to bring those levels down to an acceptable level in alignment with the risk appetite specified earlier in the process. Designing the RM program means defining and specifying the detailed tasks to be performed by the framework team and the process team. Once the framework itself has been designed and completed at least one iteration, most of the work of the framework team involves oversight of the process rather than developing the framework.
As you will learn later in this module, a wide variety of methodologies are available for conducting risk management. At this stage, the organization may simply select an “off-the-shelf” implementation of such a methodology, which it can use as is or adapt to its needs. The organization may even decide to develop its own methodology. Whatever it does, this is the phase of the RM framework in which the entire RM program is decided and the corresponding details are specified.
In addition to coordinating with the governance group on the tasks outlined in the previous section, the framework team must also formally document and define the organization’s risk appetite and draft the risk management (RM) plan.
As the governance group communicates its intent to the RM framework development team, it also needs to communicate its general perspective on what level of risk is acceptable and what risk must be reduced or resolved in some fashion. In other words, the RM framework team needs to understand and be able to determine whether the level of controls identified at the end of the risk process results in a level of risk that management can accept. The amount of risk that remains after all current controls are implemented is residual risk. The organization may very well reach this point in the risk management process, examine the documented residual risk and simply state, “Yes, the organization can live with that,” and then document everything for the next risk management review cycle.
The difficulty lies in the process of formalizing exactly what the organization “can live with.” This process is the heart of risk appetite. Documenting risk appetite as part of the RM framework development effort is often a vague and poorly understood proposition.
According to KPMG, a global network of professional firms providing audit, tax, and advisory services:
A well-defined risk appetite should have the following characteristics:
- Reflective of strategy, including organizational objectives, business plans, and stakeholder expectations
- Reflective of all key aspects of the business
- Acknowledges a willingness and capacity to take on risk
- Is documented as a formal risk appetite statement
- Considers the skills, resources, and technology required to manage and monitor risk exposures in the context of risk appetite
- Is inclusive of a tolerance for loss or negative events that can be reasonably quantified
- Is periodically reviewed and reconsidered with reference to evolving industry and market conditions
- Has been approved by the board
The KPMG approach to defining risk appetite involves understanding the organization’s strategic objectives, defining risk profiles for each major current organizational activity and future strategic plan, and defining a risk tolerance (or risk threshold) for each profile.
Risk tolerance works hand in glove with risk appetite, as it more clearly defines the range of acceptable risk for each initiative, plan, or activity. If an administrator is asked what level of attack success and loss he or she is willing to accept for a particular system, the answer should provide insight into the risk threshold for that system, as well as that for the data it stores and processes. If the answer to the question is “absolutely none,” the administrator has a zero-tolerance risk exposure for the system and requires the highest level of protection. A realistic tolerance usually falls somewhere between “sporadic hardware/software issues” and “total destruction.”
The synthesis of risk thresholds becomes the risk appetite for the organization. Risk thresholds are more tactical or operational in nature, and the risk appetite is more strategic. The final result of risk assessment is the formalization of risk appetite in the risk appetite statement, which is part of the RM framework policy.
0 comments:
Post a Comment