The Risk application has been designed to complement the organisation framework for managing risk. Where an organisation has a well matured framework, the application will enhance the requirements in areas such as continuous improvement, assisting and enhancing the organisations internal and external communications and integration into organisations processes. The Risk application can also assist organisations as they embark on establishing a risk framework, such areas as building templates to compliment the requirements of the risk management policy, establishing accountability and resource management throughout the whole of the organisation.
The risk management strategy is one of the key outputs of the risk framing component of the NIST risk management process. Typically developed at the organization level, the risk management strategy specifies procedures and methodologies with which mission and business and information system risk managers perform risk assessment, risk response, and risk monitoring activities. As illustrated in Figure 13.3, the risk management strategy reflects organizational governance decisions in terms of risk assumptions, risk constraints, risk priorities, risk tolerance, and risk acceptance criteria and may—particularly under centralized governance models—also prescribe risk assessment, response, and monitoring practices and methodologies to be used at mission and business and information system tiers. Determining and communicating organizational risk tolerance is one of the most important elements in risk management strategy, as tolerance levels influence all risk management components . Risk tolerance is also a fundamental input to information security management activities conducted throughout the steps in the Risk Management Framework, affecting security control selection, security control assessment, contingency planning, continuous monitoring, and system authorization decisions.
Risk management strategies for business continuity and disaster recovery planning require a review of the risks and plans for addressing, or mitigating, each of those risks to an acceptable level. In some cases, risks are accepted as is; in other cases, risks are transferred, and in still other cases, risks are minimized to a level acceptable to the organization. One of the fundamental tasks in managing IT risk for BC/DR planning focuses on backup and recovery strategies to ensure the confidentiality, integrity, and availability of data in both the production environment and the DR location.
The risk management strategy reflects the organization’s view of how it intends to manage risk—potentially of all types but at least within a discrete category of risk—including policies, procedures, and standards to be used to identify, assess, respond to, monitor, and govern risk. The strategy specifies strategic planning assumptions, constraints, decision-making criteria, and other factors influencing risk management in the organization, including context-specific and overall articulations of organizational risk tolerance. Risk management strategy identifies senior leaders and other stakeholders with significant decision-making authority and, in the context of describing risk governance, should clearly describe the information flows and decision-making processes related to risk management. Following NIST guidance to agencies in Special Publication 800-39, comprehensive organizational strategies for managing the risk associated with agency information systems include clear expression of risk tolerance, preferred or endorsed methodologies for risk assessment, primary risk response alternatives, descriptions of risk-based decision criteria and decision-making processes, and organizational approaches for monitoring risk . The development and implementation of the organizational risk strategy is assumed in NIST guidance to be the responsibility of the risk executive (whether that role corresponds to an individual, a group, or an organizational function).
What is software risk analysis? A software risk assessment applies classic risk definitions to software design and produces mitigation requirements.
The original version of this article was published in IEEE Security & Privacy Magazine.
Risk analysis is often viewed as a “black art”—part fortune telling, part mathematics. Successful architecture risk analysis, however, is nothing more than a business-level decision-support tool: it’s a way of gathering the requisite data to make a good judgment call based on knowledge about vulnerabilities, threats, impacts, and probability.
Established risk-analysis methodologies possess distinct advantages and disadvantages, but almost all of them share some good principles as well as limitations when applied to modern software design. What separates a great software risk assessment from a merely mediocre one is its ability to apply classic risk definitions to software design and then generate accurate mitigation requirements. A high-level approach to iterative risk analysis should be deeply integrated throughout the software development life cycle.1 In case you’re keeping track, Figure 1 shows you where we are in our series of articles about software security’s place in the software development life cycle.