Why is risk identification important to especially?

5.1.10 Proactive identification and management of risk

Risk identification and management is addressed as an important element of software analysis, which is fully explained in chapter 14, Software Analysis Practice. A risk is anything that could potentially be encountered that would negatively affect the achievement of project objectives. Since planning and design entail some form of decision making, it is best to identify the risks inherent with each alternative. This will enable the SWE-IPT to make architectural design decisions with more knowledge of the inherent risks being assumed. Risk abatement plans are encouraged to address risk-tracking procedures and the criteria that would initiate each contingency course of action.

3.2.2.1 Identification

Risk identification might be better called risk discovery and elucidation. The primary objective is to search out and identify any and all risks that may exist. To keep the process from being completely open-ended, a “preidentification step” is to define the primary perspective and context boundary of the overall risk analysis. Basically, this defines for whom the analysis is being done (e.g., the IT project manager) and what issues are in his or her area of responsibility. Anything outside this boundary must be considered as part of the project’s assumptions, i.e., risks whose consequences are being accepted. Correctly bounding the analysis is very difficult and is the greatest source of error in any analysis (Rescher, 1983).

To aid in the perspective and context boundary definition, it is usual practice to make a complete list of the project’s objectives, assumptions, expectations, and constraints, and then to check these for reasonableness. If the objectives are unreasonable, then the best risk management process in the world will not help. Similarly, if the assumptions are incorrect, the project’s likelihood of success will be, without a lot of luck, zero. If the constraints are too tight, again, success will be difficult to achieve.

Typically, the objectives are listed in order of priority as an aid to any risk management trade-offs that may have to be made later—low-level objectives may be traded off against level of risk. This implies, however, that a level of risk that is deemed (un)acceptable has been defined. The level of acceptability, called a project risk referent, is the point at which the project as defined should not proceed any further without a formal decision to continue as is, to revise the project, or to stop it. In practice, the project risk referent changes over time, being fairly loose in the project’s beginning, then becoming tighter as the project proceeds. Individual risks, once identified, will also have risk referents associated with them that indicate when they are unacceptable as well.

Identifying measurable risk referents is probably the most critical, but also hardest, activity to perform, as well as the one most often ignored in practice. There are no easy ways to combine individual risks into a single project-level risk or vice versa (Moore, 1983), although having measurable objectives of success and failure can help greatly. Poor definition of risk acceptability can lead to accepting unwarranted or unknown levels of risk, as happened in the Challenger incident (NAP, 1988). The launch criteria for cold weather were not clearly predefined, even though it was known that cold weather posed a strong possibility that certain components of the spacecraft would not work as designed.

When identifying IT-related project risks, at least four types of risks need to be examined: process risks, product risks, organizational risks, and business risks (Charette, 1990). Process risks are the risks that concern the processes being used to manage, acquire, design, develop, test, operate, and/or evolve the IT system. The quality of the IT system is highly dependent on the processes used to develop it. Missing or inappropriate processes can compromise the project.

Product risks are those that concern the IT system’s architecture and physical implementation. The architectural issues concern the overall design of the IT system itself (e.g., is the space/time complexity balanced, are the number of interfaces sufficient or too many, is the interface protocol correct), while the implementation issues concern whether the actual hardware used is reliable enough, whether the operating system being used is appropriate, whether the human interface is appropriate for the operator’s skill level, and so forth.

Organizational risks involve the “soft” risk issues: does the organization have sufficient numbers of qualified personnel, is the organizational structure efficient and will it help foster risk communication, are excessive levels of politics involved in the project, and so forth.

Business risks concern the business and financial issues that underpin the project, for instance, competitiveness, productivity, contractual, regulatory, and legal or ethical concerns. Business risks also involve market issues, such as customer-related concerns.

Risk identification strategies are fairly broad in scope, employing top-down as well as bottom-up search techniques. Along with the most common approaches of brainstorming and the use of checklists, quality management approaches such as root cause analysis and quality functional deployment (QFD) diagrams (Ross, 1988; Wilson et al., 1993) are often employed, as well as the analysis of hypothetical scenarios describing situations where different risks might occur (Schwartz, 1991).

A method growing in popularity is to use “risk taxonomies” that provide lists of commonly encountered risks supported by questionnaires (Charette, 1989, 1990). The Software Engineering Institute (SEI) has developed a software project-oriented taxonomy that classifies risks into three major classes (Carr et al., 1993): product engineering, development environment, and program constraints. These classes are subdivided further into elements: for instance, product engineering is divided into requirements, design, code and unit test, integration and test, and engineering specialties. Each of these elements are again subdivided into attributes: for instance, requirements are divided into stability, completeness, clarity, and so on.

The idea is for a risk analyst to use the taxonomy to search for the most common sources of software project risk in a quick, repeatable, and measurable manner by asking project members a set of general questions—for instance, are the project’s requirements stable, complete, clear, and so on. From the answers received, a profile of the project’s risks can be obtained and captured for later evaluation, management, and historical tracking. The Software Engineering Institute has formalized their taxonomic identification approach into something called team risk management, which focuses on bringing into the process the customer’s perspective of the risks involved (Higuera et al., 1994).

The SEI taxonomy is not the only one available. Jones (1994) also lists different IT-related risks along with their possible causes, as does Boehm (1989) and the U.S. Air Force (AFSC, 1988).

Taxonomic approaches are useful because they are easy to use and understandable to most project members. Care, however, must be taken when depending on taxonomy-based risk identification as the primary means of identification, as such approaches are often limited in scope, especially if they are not constantly updated to reflect changes in technology or competition. Taxonomies also tend to examine risks in a static “snapshot” fashion, rather than in a truer dynamic and continuous manner. Further, taxonomies tend to weaken the link to the choice (i.e., risk event) that is creating the risk, as well as its root cause. In addition, many taxonomies do not list risks per se, but only risk drivers or factors (i.e., risk symptoms). It is important to keep the risk triplet discussed in Section 2.1.2 in mind when identifying risks, and to describe the risk in terms of a conditional event—if x, then y or z may occur.

Risk Identification

Risk identification consists of 5 main activities, as follows:

Identification of Assets—The objective for this activity is to identify the assets that are in scope for the risk assessment. This includes identifying the asset owner for the asset that was identified. In ISO 27005, assets are categorized as either primary or secondary. Primary assets are core process/activities and information. Secondary assets are hardware, software, network, personnel, site, and structure. The list of asset types in ISO 27005 is fairly comprehensive and can be seen in Annex B of the standards document.

Identification of Threats—The objective of this step is to prepare a list of potential threats for the asset. According to ISO 27005, people such as asset owners, users, human resources staff, and facilities management could assist in identifying the threats to an asset. ISO 27005 also states that internal experience, particularly based on incidents that have occurred or previous assessments that have been performed, should be considered. One of the most useful contributions of ISO 27005 is the inclusion of standardized threat catalogs. A sample threat catalog is provided in Annex C of the standard. This is a great reference for risk assessment practitioners, regardless of which risk assessment framework they are choosing and will be discussed in more detail in the Data Analysis chapter.

Identification of existing controls—The objective of this activity is to identify existing controls. The guidance provided within ISO 27005 for this activity is fairly open-ended and does not specifically address criteria or scale for the control review. It does provide references to information sources that may be able to assist in this activity. Some examples identified as good sources for conducting this part of the review are:

Documents that have information about controls.

People responsible for information security.

On-site reviews.

Review of internal audit results.

Identification of vulnerabilities—As the name implies, the goal of the activity is to identify the vulnerabilities for the asset. Though the narrative does not provide much information, Annex D of the standard does provide examples of vulnerabilities, which can be used as a helpful guide. ISO 27005 also provides specific information sources that can be used to identify vulnerabilities in assets. Some samples are:

Vulnerability Scanning and Penetration Testing.

Code Reviews.

Interviews.

Questionnaires.

Physical Inspection.

Document Analysis.

Identification of consequences—The objective of this activity is to determine the possible damage or consequences caused by an “incident scenario” or what other frameworks call a threat scenario. ISO 27005 provides a list of impact factors that can be used to identify and measure the consequences. Interestingly, when compared to most of the other frameworks, ISO 27005 leans towards identifying quantitative aspects of impact such as financial replacement value, and cost of suspended operations. Samples of these quantitative aspects of impact are provided in Annex C of the standard.

Risk identification and management

Risk identification begins with understanding the underlying factors that contribute to risk. Many of the same risk factors exist in a wide range of projects. Here are some of the most common risk factors, as cited by Keil et al.:6

lack of top management commitment to the project

failure to gain user commitment

misunderstanding the requirements

lack of adequate user involvement

failure to manage end-user expectations.

Keil et al. make a special point of using the word ‘commitment’ rather than ‘support’ as there is a large distinction between the two when it comes to the success of the project. ‘Supporting’ a project can involve simple one-off tasks such as providing money or empty words of support, whereas ‘commitment’ involves working actively on behalf of a project on an ongoing basis.7

Once you have identified your potential risks, you can use the risk categories below to help avoid them. These categories, developed by Steve McConnell, include:

Dependencies

Requirements

Management issues

Lack of knowledge

Dependencies are created by having one aspect of the project hinge on a single person's skills or availability. You can avoid dependent risks by creating more interdependence in your project group, sharing skill sets, and being more mindful of issues such as schedules and availability of group members with unique skill sets.

Requirements are basically what you need in order to get the job done. You can avoid requirement risks by keeping the overall vision for the project as clear as possible, creating agreement throughout your project group on what the requirements are, and being flexible when requirements change during the course of the project.

Management issues are generally due to lack of communication and lack of transparency during the project and within the group. Avoid management risks with better task identification and overall planning, being totally transparent in project tasks and who these are assigned to, making realistic commitments to the group, and keeping expectations reasonable.

Finally, lack of knowledge is self-explanatory as it involves members of the project group having inadequate knowledge to complete the task at hand. Avoid lack of knowledge by providing all anticipated training up front, especially regarding technology.8

Helpful hint 8

Consider this!

If you have a hard time imagining the potential risks that might be inherent in your project; consider this advice from librarians who responded to the survey that they learned the ‘hard way’:

Be extremely cautious about custom designing your own furnishings: one miscalculation and you may have to live with an inefficient result for a decade or longer.

Ensure that all light fixtures are accessible when bulbs burn out – unless you have a department who takes care of this.

If you are relocating, consider weeding your collection and filing any archival materials during the planning process and definitely before the move. Not only does this often decrease the amount of material that needs to be moved, but it is another opportunity to consider your collection in relation to your project.

If someone else is in charge of scheduling your move, or renovation, ensure that you let them know you want to be there and make sure you are around.

Consider planning areas for electrical outlets and infrastructure – think about future growth of your library and what it might look like in five years.

Consider closing the library completely during the renovations rather than trying to work and serve users inside a construction zone.

If relocation is involved make sure to select a good mover who has moved libraries before, is organised and pays attention to detail; get references from other libraries.

Ask a lot of questions about the plans and space allowed for the Library/Information Centre and make the time to measure the shelf space yourself. Don't wait for the planners/organisers of the renovation to come to you … you have to go to them!

Risk Management

Comprehensive risk identification, mitigation, and assessment is an important challenge. Risk management tends to focus on obvious risks and those receiving significant attention in the business community. Risk management will become a key consideration of investors since the issue is risk to their investments.

The agile enterprise should compile and maintain a risk management catalog of risks, mitigations, and levels of risk for the business as usual, as well as threats, initiatives, and external circumstances that bring new risks. These risk entries should be collected from leaders across the enterprise that are familiar with the risks of their operations. Activities driven by the sense and respond directory should adjust or add risks as appropriate.

Motivation and goals for stage B

In many management seminars and lectures, it is taught that you can’t manage what you can’t measure. Information risk assessment measures information risk and is therefore at the heart of the TIRM process.

The goal of this stage is to conduct a thorough identification, analysis, and evaluation of information risks; this is crucial if you are to effectively manage information risks.

Information risk identification is important; you have to understand how and where information risks occur. This identification process addresses the following questions:

Which information is critical for my business processes?

Which information quality problems affect my organizational performance?

Information risk analysis is important in gaining an understanding of the likelihood and impact of these information risks. The analysis deals with the questions:

What is the likelihood of each consequence of an information quality problem?

How much does it affect my organizational performance?

Finally, information risk evaluation interprets the results into something that is truly meaningful. It focuses on answering the questions:

So, what does it mean for my organization?

How damaging are the identified information risks for my organization?

Do I need to take action?

Risk identification

All business areas within an organization include various activities and processes, which give several sources for risk. To manage and monitor risks efficiently in an organization, they need to be gathered and organized in an appropriate way, in a repository. This approach leads to a consolidated, organization-wide view of risk, indifferent of local interpretations and aggregation hierarchies, to monitor risk at a business unit level. This general repository needs to be completed with the local risks unique to each business unit with its particular responsibilities, which need to be identified and monitored.

Identification of risks specific to an enterprise is a critical step, since management cannot be expected to control risks they are unaware of. Risks can be identified, for example, by using event logs to extract risk events and risky situations; by eliciting expert opinions on what may go wrong in the enterprise; by simulating business processes and extracting a list of potential undesirable results; by systematically going through every existing business process and finding out problems; or by learning from experience of others, analyzing the risk events that materialized in similar businesses. Some of these methods produce only a list of risks, while others may produce accurate approximation of the frequency of the risk events actual occurrences. This frequency is used for calculating the expected potential damage that may become associated with a particular event and, consequently, for setting priorities of treating various contingencies.

Organizations ensure consistency in risk identification in two manners:

1.

Risk identification is achieved via a centralized library of risks. This library covers generic risks that exist throughout the organization, and associates the risks with the organization’s business activities. The library is typically created by using an industry list as an initial seed, and then continuously augmented.

Identification consistency is further aided by employing a classification model covering both risks and controls. Using this model, each risk in the risk library has an assigned risk classification that can be based on regulatory definitions, and each associated control also has a control classification.

The process of risk identification should be repeated at regular intervals as observed by Kenett and Raanan [4].

Key risk indicators, or KRIs, are metrics taken from the operations of a business unit, which are monitored closely in order to enable an immediate response by the risk managers to evolving risks. The number of risk indicators may be very large, thus making it very difficult to track, monitor and control. Therefore, a selected few risk indicators are chosen to serve as a warning mechanism for the Enterprise and are used as inputs to a risk management dashboard. These may be simple risk indicators, such as “number of bugs in the software project,” or compound indicators made up of direct risk indicators for a given area of activity [4, 7, 8].

Risk Assessment

The risk assessment stage combines risk identification, risk analysis, and risk evaluation. Risk identification is the first step in the risk assessment process and focuses on identifying the source of risk and potential events that could impact an organization's objectives. Risk identification also provides insight in the interaction between risk and threat. Such insight is an important process as each organization has a unique context and, therefore, needs to focus on different risks (Fischer et al., 2008).

At this stage all risk should be considered, as those not identified here may not be considered later. To extract all risks, there are many techniques such as brainstorming, workshops, scenario development, or group experience, but whatever method is used should promote open and frank discussion. Thus, the outcome is to produce a comprehensive list of risks that can be clustered into common types (Table 3.2).

Table 3.2. Typical Risk Clustering Groups

Risk analysis considers the previously identified risks and analyzes them through the study of their proxies, namely consequence (Table 3.3), likelihood (Table 3.4), and degree of existing control. It is important to note that such measurements of proxies will only serve to provide an estimation of the risk and the relationship between them cannot be assumed to be absolute nor linear.

Table 3.3. Consequence Scale

Table 3.4. Likelihood Scale

There are many techniques to populate these scales, although the most effective is to take a consensual group approach (Beard and Brooks, 2009). A consensual approach brings the relevant people together who have some degree of ownership of the risk, and as a group they agree on where the various risks locate on the two scales.

Existing controls need to be considered, as these controls could reduce either the consequence or likelihood of an event. Controls may be physical, procedural, or technology factors.

Once all risks have been annotated with a consequence and likelihood measure, the sums of these measures need to be ranked. One of the most effective methods is to use a risk matrix (Table 3.5), which should be weighted to consequence for the majority of assessment. Such weighting allows for some degree of social expectations, dread of the event, and people better understand outcomes (consequences).

Table 3.5. Risk Matrix

The outcome of the risk matrix should be a list that commences with the most extreme assessed risk and scales down to the lowest.

Risk evaluation allows the decision-makers to make an informed decision, based on the outcome of the risk analysis section. The risks—in particular, the extreme and high-ranked risks—should be aligned and checked with the initial risk management context. In addition, decision such as whether the risk needs to be treated and its priority, what activity is to take place, and should the risk be reviewed need to be considered?

In reality, there is generally an arbitrary line drawn just below extreme and high risks, which ensures further action of these risks are undertaken (Table 3.6).

Table 3.6. Risk Rating Descriptor

Risk Assessment

This process comprises three subprocesses, namely risk identification, risk analysis and risk evaluation. The process receives as input the output of the context establishment process. It identifies, quantifies or qualitatively describes risks and prioritizes them against the risk evaluation criteria established within the course of the context establishment process and according to objectives relevant to the organization. It is often conducted in more than one iterations, the first being a high-level assessment aiming at identifying potentially high risks that warrant further assessment, whereas the second and possibly subsequent iterations entail further in-depth examination of potentially high risks revealed in the first iteration. The output of the process is a list of assessed risks prioritized according to risk evaluation criteria.30

Risk identification seeks to determine what could happen to cause a potential loss and to gain insight into how, where, and why the loss might happen. It involves a number of steps, namely identification of assets; identification of threats; identification of existing security measures; identification of vulnerabilities; and identification of consequences. Input to the subprocess is the scope and boundaries for the risk assessment to be conducted, an asset inventory, information on possible threats, documentation of existing security measures, possibly preexisting risk treatment implementation plans, and the list of business processes. The output of the subprocess is a list of assets to be risk-managed together with a list of business processes related to these assets; a list of threats on these assets; a list of existing and planned security measures, their implementation and usage status; a list of vulnerabilities related to assets, threats and already installed security measures; a list of vulnerabilities that do not relate to any identified threat; and a list of incident scenarios with their consequences, related to assets and business processes.31

Two kinds of assets can be distinguished, namely primary assets, which include business processes and activities and information, and supporting assets, which include hardware, software, network, personnel, site, and the organization’s structure. Hardware assets comprise data-processing equipment (transportable and fixed), peripherals, and media. Software assets comprise the operating system; service, maintenance or administration software; and application software. Network assets comprise medium and supports, passive or active relays, and communication interfaces. Personnel assets comprise decision makers, users, operation/maintenance staff, and developers. The site assets comprise the location (and its external environment, premises, zone, essential services, communication and utilities characteristics) and the organization (and its authorities, structure, the project or system organization and its subcontractors, suppliers and manufacturers).32

Threats are classified according to their type and to their origin. Threat types are physical damage (fire, water, pollution); natural events (climatic phenomenon, seismic phenomenon, volcanic phenomenon); loss of essential services (failure of air-conditioning, loss of power supply, failure of telecommunication equipment); disturbance due to radiation (electromagnetic radiation, thermal radiation, electromagnetic pulses); compromise of information (eavesdropping, theft of media or documents, retrieval of discarded or recycled media); technical failures (equipment failure, software malfunction, saturation of the information system); unauthorized actions (fraudulent copying of software, corruption of data, unauthorized use of equipment); and compromise of functions (error in use, abuse of rights, denial of actions).33 Threats are classified according to origin into deliberate, accidental or environmental. A deliberate threat is an action aiming at information assets (remote spying, illegal processing of data); an accidental threat is an action that can accidentally damage information assets (equipment failure, software malfunction); and an environmental threat is any threat that is not based on human action (a natural event, loss of power supply). Note that a threat type may have multiple origins.

Vulnerabilities are classified according to the asset class they relate to. Therefore, vulnerabilities are classified as hardware (susceptibility to humidity, dust, soiling; unprotected storage); software (no or insufficient software testing, lack of audit trail); network (unprotected communication lines, insecure network architecture); personnel (inadequate recruitment processes, lack of security awareness); site (location in an area susceptible to flood, unstable power grid); and organization (lack of regular audits, lack of continuity plans).34

Risk analysis is done either quantitatively or qualitatively. Qualitative analysis uses a scale of qualifying attributes to describe the magnitude of potential consequences (low, medium or high) and the likelihood that these consequences will occur. Quantitative analysis uses a scale with numerical values for both consequences and likelihood. In practice, qualitative analysis is used first, to obtain a general indication of the level of risk and to reveal the major risks. It is then followed by a quantitative analysis on the major risks identified.

Risk analysis involves a number of steps, namely assessment of consequences (through valuation of assets); assessment of incident likelihood (through threat and vulnerability valuation); and determination of the risk level. We discussed valuation of assets, threats, and vulnerabilities in an earlier section. Input to the subprocess is the output of the risk identification subprocess. Its output is a list of risks with value levels assigned.

Having valuated assets, threats, and vulnerabilities, we should be able to calculate the resulting risk, if the function relating these to risk is known. Establishing an analytic function for this purpose is probably impossible and certainly ineffective. This is why, in practice, an empirical matrix is used for this purpose35. Such a matrix, an example of which is shown in Table 53.2, links asset values and threat and vulnerability levels to the resulting risk. In this example, asset values are expressed on a 0–10 scale, whereas threat and vulnerability levels are expressed on a Low-Medium-High scale. The risk values are expressed on a scale of 1 to 7. When linking the asset values and the threats and vulnerabilities, consideration needs to be given to whether the threat/vulnerability combination could cause problems to confidentiality, integrity, and/or availability. Depending on the results of these considerations, the appropriate asset value(s) should be chosen, that is, the one that has been selected to express the impact of a loss of confidentiality, or the one that has been selected to express the loss of integrity, or the one chosen to express the loss of availability. Using this method can lead to multiple risks for each of the assets, depending on the particular threat/vulnerability combination considered.36

Table 53.2. Example Risk Calculation Matrix.

Finally, the risk evaluation process receives as input the output of the risk analysis process. It compares the levels of risk against the risk evaluation criteria and risk acceptance criteria that were established within the context establishment process. The process uses the understanding of risk obtained by the risk assessment process to make decisions about future actions. These decisions include whether an activity should be undertaken and setting priorities for risk treatment. The output of the process is a list of risks prioritized according to the risk evaluation criteria, in relation to the incident scenarios that lead to those risks.

Risk Assessment

This process is composed of three subprocesses: risk identification, risk analysis, and risk evaluation. The process receives as input the output of the context establishment process. It identifies, quantifies, or qualitatively describes risks and prioritizes them against the risk evaluation criteria established within the course of the context establishment process and according to objectives relevant to the organization. It is often conducted in more than one iteration, the first of which is a high-level assessment aiming to identify potentially high risks that warrant further assessment; the second and possibly subsequent iterations entail further in-depth examination of potentially high risks revealed in the first iteration. The output of the process is a list of assessed risks prioritized according to risk evaluation criteria.

Risk identification seeks to determine what could happen to cause a potential loss and to gain insight into how, where, and why the loss might happen. It involves a number of steps, such as identification of assets, identification of threats, identification of existing security measures, identification of vulnerabilities, and identification of consequences. Input to the subprocess is the scope and boundaries for the risk assessment to be conducted, an asset inventory, information on possible threats, documentation of existing security measures, possibly preexisting risk treatment implementation plans, and the list of business processes. The output of the subprocess is a list of assets to be risk-managed together with a list of business processes related to these assets; a list of threats on these assets; a list of existing and planned security measures, their implementation, and usage status; a list of vulnerabilities related to assets, threats, and already installed security measures; a list of vulnerabilities that do not relate to any identified threat; and a list of incident scenarios with their consequences, related to assets and business processes.

Two kinds of assets can be distinguished: primary assets, which include business processes and activities and information; and supporting assets, which include hardware, software, network, personnel, site, and the organization's structure. Hardware assets are composed of data-processing equipment (transportable and fixed), peripherals, and media. Software assets are composed of the operating system; service, maintenance, or administration software; and application software. Network assets are composed of media and supports, passive or active relays, and communication interfaces. Personnel assets are composed of decision makers, users, operation/maintenance staff, and developers. Site assets are composed of the location (and its external environment, premises, zone, essential services, and communication and utilities characteristics) and the organization (and its authorities, structure, the project or system organization and its subcontractors, suppliers, and manufacturers).

Threats are classified according to their type and origin. Threat types are physical damage (fire, water, or pollution); natural events (climatic, seismic, or volcanic phenomena); loss of essential services (failure of air-conditioning, loss of power supply, or failure of telecommunication equipment); disturbance caused by radiation (electromagnetic radiation, thermal radiation, or electromagnetic pulses); compromise of information (eavesdropping, theft of media or documents, or retrieval of discarded or recycled media); technical failures (equipment failure, software malfunction, or saturation of the information system); unauthorized actions (fraudulent copying of software, corruption of data, or unauthorized use of equipment); and compromise of functions (error in use, abuse of rights, or denial of actions). Threats are classified according to origin into deliberate, accidental, or environmental. A deliberate threat is an action aimed at information assets (remote spying or illegal processing of data); an accidental threat is an action that can accidentally damage information assets (equipment failure or software malfunction); and an environmental threat is any threat that is not based on human action (a natural event or loss of power supply). Note that a threat type may have multiple origins.

Vulnerabilities are classified according to the asset class to which they relate. Therefore, vulnerabilities are classified as hardware (susceptibility to humidity, dust, or soiling; or unprotected storage); software (no or insufficient software testing, or lack of an audit trail); network (unprotected communication lines or insecure network architecture); personnel (inadequate recruitment processes or lack of security awareness); site (location in an area susceptible to flood, or unstable power grid); and organization (lack of regular audits or lack of continuity plans).

Risk analysis is done either quantitatively or qualitatively. Qualitative analysis uses a scale of qualifying attributes to describe the magnitude of potential consequences (low, medium, or high) and the likelihood these consequences will occur. Quantitative analysis uses a scale with numerical values for both consequences and likelihood. In practice, qualitative analysis is used first, to obtain a general indication of the level of risk and to reveal the major risks. It is followed by a quantitative analysis of the major risks identified.

Risk analysis involves a number of steps, such as assessing consequences (through valuating assets), assessing incident likelihood (through valuating threat and vulnerability), and determining the risk level. We discussed valuating assets, threats, and vulnerabilities in an earlier section. Input to the subprocess is the output of the risk identification subprocess. Its output is a list of risks with value levels assigned.

Having valuated assets, threats, and vulnerabilities, we should be able to calculate the resulting risk if the function relating these to risk is known. Establishing an analytic function for this purpose is probably impossible and certainly ineffective. This is why, in practice, an empirical matrix is used for this purpose. Such a matrix links asset values and threat and vulnerability levels to the resulting risk; an example this is shown in Table 34.2. In this example, asset values are expressed on a scale of 0 to10, whereas threat and vulnerability levels are expressed on a scale of low–medium–high. Risk values are expressed on a scale of 1 to 7. When linking the asset values and the threats and vulnerabilities, consideration needs to be given to whether the threat–vulnerability combination could cause problems to confidentiality, integrity, and/or availability. Depending on the results of these considerations, the appropriate asset value(s) should be chosen: that is, the one that has been selected to express the impact of a loss of confidentiality, integrity, or availability. Using this method can lead to multiple risks for each asset, depending on the particular threat–vulnerability combination considered.

Table 34.2. Example Risk Calculation Matrix

Finally, the risk evaluation process receives as input the output of the risk analysis process. It compares the levels of risk against the risk evaluation criteria and risk acceptance criteria that were established within the context establishment process. The process uses the understanding of risk obtained by the risk assessment process to make decisions about future actions. These decisions include whether an activity should be undertaken and sets priorities for risk treatment. The output of the process is a list of risks prioritized according to the risk evaluation criteria, in relation to the incident scenarios that lead to those risks.