Security Programs: Risk Assessment and Management

CHAPTER 5

THIS CHAPTER, SOMEWHAT LIKE THE LAST ONE, will serve as a good resource for any organizational member who is (or who might be) involved in security assessments and audits, as well as in risk management programs. In the last chapter, we introduced many regulations that require organizations to implement a risk assessment–based approach to their information system security. In an effort to meet this “due care” standard, many organizations are turning to best practices and control frameworks. Although the goal is to assist organizations with appropriate information technology (IT) governance, the increasing number of frameworks and best practices can add complexity and confusion to the process. In this chapter, we introduce security program management and the components of risk assessment and mitigation.

Although it is often tedious to keep abreast of checklist criteria for risk assessment, risk management, and regulatory and/or security compliance, it is an important task. The task is similar to the need for an accountant or bookkeeper to post a transaction in its proper place in the books, as opposed to a debit posted as a credit. Clearly, if done wrong, many problems can arise.

5.1 Risk Assessment and Management Overview

Security programs subsume risk assessments and risk management. Whereas other aspects of security programs deal with human resources or technological issues, the risk assessment and risk management aspects of a security program are administrative in nature—that is, they deal with the processes, rules, and procedures of security management. Risk assessment involves techniques to quantify and qualify the likelihood and impact of threats. To accomplish this, managers often use frameworks and technologies to identify information system assets and configurations, assess vulnerabilities to them, and survey for threats that are likely to exploit these vulnerabilities or otherwise lead to disasters. This is an important process to help managers to make informed decisions on how to best allocate their resources.

Risk management involves the enactment of security programs, and they are designed to mitigate the risks identified from the risk assessments. While the risk management process is itself administrative, it may call for the use of physical, human resource, or technological means to mitigate the risks, such as by conducting employee training to make those in operational roles more capable and to help reduce the introduction of new vulnerabilities into systems. With risk management, we are interested in minimizing the impact of exploits and disasters and in enhancing an organization’s ability to deal with new vulnerabilities and risks as they arise.

These parts of the security program involve contingency planning, including continuity planning and disaster recovery planning. The objective of contingency planning is to design ways to handle the circumstances in which an organization’s information systems and resources become compromised. The continuity planning aspect of this is specifically done to assist managers with ways to keep the operations up and running in case of a disaster or an exploit that results in a total outage. Disaster recovery planning involves the processes and procedures needed to make damaged systems and resources operational again. The planning falls out of the assessment processes and sets the stage for the management of risks. The complete role of a security program is to address all of the security components in an organization and provide managers with well-defined means of identifying risks and vulnerabilities and reducing them, and then monitoring for threats and rectifying them.

5.1.1 Security Program Overview

Many, if not most, organizations today depend extensively on their information systems and resources to function. As such, it has become imperative to manage information system security as a complete program with a defined scope and the support of executive leadership, and not only the responsibility of the IT department. The foundation of the security program should be a thorough understanding of the organization and the value of the information and information systems throughout the organizational echelon—the needs, goals, and priorities of the organization, and the organization’s behavioral and normative culture. Within this framework, a risk assessment can be accomplished, policies can be established, and controls can be selected and implemented to ensure that the information assets and their associated systems operate effectively and efficiently. Although many organizations do this as a matter of good business practice, those that are regulated may face heavy penalties for non-compliance, and therefore management involvement and support for the security program is crucial.

Among the activities that management should be involved in include establishing priorities, valuing assets, and assigning roles and responsibilities with appropriate accountability to ensure that the information security program is effective and responsive to the needs of the organization. Once the identification and valuation of the information resources have been accomplished, specific administrative, technical, and physical controls should be established to achieve the goals of the security program.

Administrative controls are those processes, rules, and procedures that establish what should, shouldn’t, can, and can’t be done with the information systems and other information resources [1]. Included within this area are the definitions and implementations of policies, procedures, guidelines, and standards. Technical controls are the logical controls that define the limits of the behavior of both information systems and those who access them. Identification and authentication mechanisms, firewalls, access control lists, and associated system and application software settings are examples of technical controls. Physical controls are those controls that exist in the physical environment and include locks, removal and proper disposal of unnecessary hardware, and environmental management systems ranging from fire suppression systems to barricades [2].

5.1.2 Risk Assessment Overview

Threats can come from both internal and external sources, and they are inextricably linked to vulnerabilities inherent in any given system, and exposures of those vulnerabilities are linked to a threatening agent. Thus for our purposes now, risk is defined as the chance (or probability) of something undesirable happening to individuals or the organization. The concept of risk exists in the realm of uncertainty and occurs when a vulnerability, either known or unknown, has a corresponding threat associated with it.

When the concept of risk is applied to an information system, we are referring to the chance that the system will not do what we expect or need it to do. Although that is a simple definition, it really is somewhat complicated in its implementation. However, it is an extremely important concept because it establishes the foundation and goals of risk management, which are to keep the system operating in a way that we expect and in a manner that meets our needs at the lowest possible cost, regardless of whether that cost is time, effort, or financial outlay.

Risk can be accepted, mitigated or reduced, or transferred [1, 3]. Accepting a risk usually implies that the probability of the threatened risk is low or that the cost-to-benefit ratio does not warrant the concomitant investment to try to prevent the threatened risk from occurring. For example, it might not be worth spending thousands of dollars on a fail over system for a web server that hosts a minor website. Mitigation is generally the attempt to improve a situation to an acceptable level given the constraints. As an example, a manager may opt for an open source or a free virus scanner such as the AVG-free version for an isolated office computer that performs a minor role, but upgrade to the AVG commercial version for office computers connected by a local area network.

Managers need to make both quantitative and qualitative assessments of risks to their organizations. As a generic example, risk factors may be placed into a spreadsheet and then given weights according to the risks managers might subjectively identify to various assets, systems, and services. The assigned weights given to the risks attempt to capture the potential damage that an exploit may cause if successful (see Figure 5.1). A tally of the threat weights can be computed to identify the greatest damage potentials. Much of what managers may decide in terms of risk probability and risk potential is a matter of judgment; others may be a statistical calculation or as computed probabilities.

5.1.3 Risk Mitigation Overview

Organizations invest in their information technology (IT) infrastructure because they believe that their investments will in some way improve their operations. Such thinking has been supported by research, which has shown that organizations that made significant investments in their IT infrastructure and resources tended to outperform those organizations that did not [4, 5]. Having a unique way of combining tangible and intangible resources, as defined by McKeen et al. [6], is called IT capability.

Research related to IT capability not only suggests a definitive relationship between IT investments and organizational value, but the components of IT capability are similar to those identified in best-practice and control frameworks, such as the Information Technology Infrastructure Library (ITIL) and the Control Objectives for Information and Related Technology (COBIT). Furthermore, research that has examined computer-related best practices, such as ISO 17799 and NIST Special Publication 800-53, suggests that the standards can be highly useful in mitigating risk [7]. What these best-practice and control frameworks have in common is the recognition of risk related to information systems.

FIGURE 5.1

Risks arranged according to probability and severity.

As indicated earlier, risk mitigation begins with the identification of assets such as systems, software, and information, and then assessing the value of those assets. Valuations include replacement costs of equipment, loss of revenue from lost services, legal liabilities, damage to brand or reputation, and the like. In most cases, organizations log capital purchases and issue asset tags for these items. It is important that this inventory be kept current and accurate. For this purpose, audits should be regularly conducted to reconcile the asset records with the inventory and to confirm the configurations. Having a clear idea of what assets the organization has and their values, they can be matched up with the risk assessments indicating the threats and their likelihoods and severities. Managers can then plan and manage the risks accordingly [2]. Implied in these activities are the importance of risk determination and control frameworks in giving guidance to managers.

5.2 Risk Determination and Control Frameworks

There are an abundance of risk assessment, control, and risk management frameworks. Some of the prominent abbreviations that we will expand on as we go along here are ITIL, ITSM, BS15000, ISO2000x, and a few others. The IT Infrastructure Library (ITIL) is a set of management best practices that was developed in the United Kingdom for information systems technology and has broad support throughout Europe and Canada. Information Technology Service Management (ITSM) is an IT management framework that implements the components of ITIL.

The main goal of ITIL/ITSM, in terms of most management frameworks, is to enable an organization to establish and manage its IT infrastructure in the most effective and efficient manner possible. The British Standard BS 15000/ISO 2000x takes these processes and divides them over five areas called Release Processes, Control Processes, Resolution Processes, Relationship Processes, and Service Delivery Processes. These areas are then implemented and managed to improve IT delivery efficiency and effectiveness in much the same way as in ITSM.

5.2.1 ITIL / ITSM

ITIL/ITSM is unique in that it focuses on the provision of IT as a service. Whereas previous versions of ITIL aggregated IT processes into one of two broad areas: Service Delivery, which is responsible for the management of services, and Service Support, which relates to the effective delivery of services, version 3 has at its core Service Strategy, with Service Design, Service Transition, Service Operation, and Continuous Service Improvement defining the remainder of the service life cycle. List 5.1 provides an overview of each area.

5.2.2 COBIT

Another popular framework is the Control Objectives for Information and Related Technology (COBIT). Like ITIL, COBIT defines, identifies, organizes, and links IT activities and resources to business processes to ensure that IT assets are secure, verifiable, and, in COBIT’s case in particular, auditable. The framework contains 34 processes, which are organized into four major areas: planning, building, running, and monitoring (see List 5.2).

Additionally, COBIT separates the framework components into control objectives with audit guidelines and control practices, activity goals for efficiency and effectiveness, and specific metrics that indicate organizational and process maturity, performance, and goal attainment.

5.2.3 ISO 27K IT Security Control Selection

Within the broader context of IT management, there are specific frameworks for IT security that enhance the generalities and, together, tend to be synergistic. The most popular among these security frameworks is the ISO 27000 family. ISO 27001/27002 (17799) are the de facto standards for information system security internationally. ISO 27001 provides guidelines that explain how to structure the information security management system (ISMS), analyze risks to identify suitable information security controls, and measure and improve the ISMS thereafter. It does not go into detail on implementing specific controls, but it does provide general guidance by reference to the standards.

The Information Technology Code of Practice for Information Security Management (ISO 27002) gives specific guidance in the “how” of information system security, is divided into 11 sections that broadly address information security, and provides guidelines and best practices for ensuring the security of all information assets, as seen in List 5.3.

Whereas ISO 27702 provides the controls, ISO 27001, Information Security Management System Requirements, provides an approach to managing security in a well-defined and systematic way. Additionally, it provides a means for an organization to certify its adherence to the security standard. We will discuss the ISO 17799-ISO/IEC 27002 and ISO 13335 in more detail in the section on risk management, and also in the chapter on operations management.

5.2.4 NIST 800-53

Another popular framework is the Recommended Security Controls for Federal Information Systems (RSCFIS), which is also known as the U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53. The framework offers specific guidance in information system security management and control selection. NIST SP 800-53 outlines security controls that are based on the Federal Information Processing Standard (FIPS) 199 Standards for Security Categorization of Federal Information and Information Systems. It was designed to give guidance for organizations implementing FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. NIST 800-53 organizes security controls into three classes and 17 associated families and provides guidance for establishing different groups of controls. Examples are seen in Table 5.1.

NIST 800-53 outlines two baseline groups of controls that are to be implemented on all information systems in an organization or unit. It also specifies system controls unique to an individual system. The partitioning of controls in this manner is both designed to be cost-efficient and to provide a central and standardized means of deployment and security assurance. The establishment of security control baselines designed to meet the organization’s specific policy requirements enhances this process. In addition to establishing the baseline framework, the publication provides guidance on the process of selecting and specifying security controls to manage risk through a nine-step process. The nine steps are seen in List 5.4.

5.3 Risk Management Frameworks

Risk management involves decision making according to assessments of vulnerabilities and costs. Vulnerabilities will continue to exist in complex information systems for the foreseeable future. Exposure of these vulnerabilities, whether known or unknown, can lead to loss. As such, there is an inherent risk associated with utilizing any information system. Understanding and managing risk is a key step in any information security program and is discussed in international standards ISO 17799 or ISO/IEC 27002, and ISO 13335, which are increasingly being utilized as organizational frameworks and guidelines.

Risk to an information system is the chance that the system will not do what we expect or need it to do. This simple definition illustrates what we are trying to do with risk management—meaning to keep the system operating in a way that we expect and that meets our needs at the lowest possible cost. Cost is another broad term often used, but it can be thought of as expenditures. Time, effort, and money are all items covered by cost. A thorough risk analysis will allow the owner of a system to make a decision on how to manage risk. In the case of risk acceptance, if the costs associated with mitigating or transferring the risk are greater than costs associated with the risk being exploited from a cost-benefit analysis, it would be better left alone [2].

If the costs associated with the countermeasures outweigh the costs associated with the risk being exploited, then we are interested in mitigating or reducing risk. This is the most common use of information security, and any “owner” of an information system must find a balance between the costs of mitigating the risk and the costs of exploitation. Finally, transfer of risk occurs within the model of insurance. For a given fee, another agent will accept the costs associated with exploitation of the risk.

5.3.1 OCTAVE

OCTAVE, or the Operationally Critical Threat, Asset, and Vulnerability Evaluation methodology, was created by researchers at the Software Engineering Institute at Carnegie Mellon University to provide a structured means of helping an organization understand and conduct an information security risk assessment. The OCTAVE method is primarily qualitative and consists of eight steps divided over three phases in which an organization identifies its information assets, identifies and examines the threats and vulnerabilities associated with those assets, and develops a security strategy to address the risks identified. Although there are different OCTAVE methodologies based on the organizational need, the original OCTAVE methodology, specific phases, and process [13] are seen in List 5.5.

Although it is beyond the scope of this book to cover the full OCTAVE method, an overview is appropriate. In the first step of phase 1, before the evaluation begins, the staff involved must prepare for the evaluation by securing senior management support, selecting appropriate representatives from operational and IT areas, and ensuring that everyone involved in the evaluation is appropriately trained in the method.

Once the site team is established, a meeting must be held with senior management representatives to identify current information assets, their required level of protection, known threats to the assets, and the current administrative, technical, and physical controls in place to provide security for the assets. An understanding of the operational areas to be covered by the evaluation is determined and the team conducts similar meetings with the operational managers, area staff, and finally the IT department. The information gathered from the meetings is used to construct threat profiles that are utilized in subsequent phases.

In phase 2, the site team works with the IT department (or the department in the organization responsible for information systems and information systems security) to identify and evaluate the specific information systems associated with the assets identified in phase 1. The information systems then undergo a vulnerability analysis to identify strengths and weaknesses with the technical controls established, and a summary report is completed.

In phase 3, information gathered from phases 1 and 2 is consolidated and evaluated to determine the value associated with the information assets and whether loss associated with the assets would result in a high, medium, or low impact to the organization. A similar process is conducted with the identified risks, resulting in a framework that allows the site team to develop a protection strategy, risk mitigation plans, and an action list that identifies specific short- and long-term actions to be taken to reduce or manage the identified risks.

This is reviewed with senior management, adjusted to the specific goals and needs of the organization, and finalized for implementation. In the more recent OCTAVE Allegro [14], the structured risk assessment is similar, although the steps have changed to reflect a streamlined approach, which includes the (1) establishment of risk measurement criteria, (2) development of an information asset profile, (3) identification of information asset containers, (4) identification of areas of concern, (5) identification of threat scenario, (6) identification of risks, (7) an analysis of the risks, and (8) the selection of a mitigation approach.

5.3.2 NIST 800-30

Earlier, we mentioned the NIST SP 800-53 as a risk determination and control framework. The complement to that specification is the NIST SP 800-30, which contains provisions for risk management. In addition to providing guidance for risk management in the software development life cycle (SDLC), it provides a nine-step methodology for conducting a risk assessment, identifying appropriate controls for the associated risk, mitigation strategies, and standards of practice for continuous risk evaluation and assessment. The nine steps are illustrated in List 5.6.

Similar to the OCTAVE methodology, the first step in the NIST 800-30 risk management process is the definition of the scope of the project. Additionally, it is during the first step of the process that system information is collected through questionnaires, interviews, document reviews, and automated system scanning tools. This includes identification of the hardware and software, the associated data, the users, the mission and purpose of the system, and the level of importance of the data to the organization. Functional requirements, policies, controls, and system architecture are also identified and delineated in this step.

In the second step, Threat Identification, the assessment team utilizes the information gathered in step one to identify and evaluate potential threats to the IT system and operating environment. Included in this step are evaluation of potential natural threats, such as floods, earthquakes, and lightning; human threats, such as intentional and unintentional acts that cause damage to the system; and environmental threats, such as pollution and long-term power outages.

The third step, Vulnerability Identification, seeks to identify those properties of the system that could be exploited or exacerbated by the threats identified in step two. The information derived from steps two and three are combined to form Vulnerability/Threat pairs that list the vulnerability, a potential threat source, and the action the threat could engage in to exploit the vulnerability. The vulnerabilities themselves are identified through standard sources, such as vulnerability databases, scanning, audit reports, and vendor information. This can also include active vulnerability testing methods, such as “red team” or penetration testing. Any weaknesses identified in step three are used as input to step four.

In Control Analysis, the vulnerability/threat pairs are compared to existing or planned controls, and a determination is made as to the sufficiency of the management (administrative), operational (physical), and technical controls. A checklist is often utilized at this stage to compare the controls to the vulnerabilities/threat environment, and adjustments to plans are made.

In the fifth step, Likelihood Determination, a quantifier of high, medium, or low is assigned to each threat/vulnerability pair to indicate the likelihood of each individual vulnerability being exploited in the given threat environment. A high quantifier indicates that there is a great likelihood that the threat will exploit the vulnerability and that the in-place or planned controls will have little effect. A medium quantifier indicates that the threat may be significant but the controls are likely to be effective, and a low quantifier indicates that either the threat is negligible, or the controls are effective, or both.

Step six is Impact Analysis and is a determination of what the consequences of a successful exploitation of vulnerability will mean to the organization. Generally, this is described in terms of degradation to the information security triad of confidentiality, integrity, and availability with respect to each resource and again described as high, medium, or low.

The impact statements from step six feed into the Risk Determination of step seven. It is in this step that the likelihood, the impact, and the control sufficiency are utilized to create a risk-level matrix in which the assessment team generates an overall risk level for each observation. The determination of risk is a factor of the likelihood of the threat attempting exploitation and the impact to the organization should the exploit be successful. The results from this step, a quantification of risk as high, medium, or low for each threat, are the basis for step eight, Control Recommendations.

In step eight, management must be involved to make a determination as to what level of risk the organization is willing to accept for each threat. This will drive the evaluation and recommendation of specific controls, whether administrative, technical, or physical, for each threat. Step nine requires the results and underlying reasoning for decisions made in each of the prior steps to be documented in a report or briefing that can be utilized by management to make decisions on business arrangements related to the risk assessment. As discussed earlier, this may include assumption of the risk, implementation of controls to attempt to mitigate the risk, or transfer of the risk through insurance or some other means. These are not mutually exclusive areas, but may be combined in a variety of ways.

5.3.3 Using Frameworks for Implementing Plans

Now that we have covered a variety of frameworks, we will briefly illustrate how a framework might be used in the implementation of risk mitigation plans. Risk is often represented in the function: f (risk = (threat × vulnerability)). A question managers often ask is how to translate this function into something tangible. Later in this textbook, we will go into more specifics about this, but for now, an example might be useful to show how framework criteria we have covered might be translated into risk mitigation actions. For this example, we will use OCTAVE, presented earlier, but at a simplistic level and with a single example to make it amendable for our illustration purposes. As a refresher, it involves building asset-based threat profiles, identifying infrastructure vulnerabilities, and developing a security strategy and plans.

Suppose our company had a web-based application written in JAVA, which allowed managers to track their plan to actual budgets via a login with a browser. We first need to develop a threat profile—and for this example, we will focus specifically on the login, and more specifically on password protections. Next, imagine that our system uses a mandatory access control in which users are required to change their passwords every 90 days to a randomly generated password supplied to them automatically.

Now let’s say that we conducted an evaluation and found that many managers were writing down their passwords and had taped them to their keyboards because they could not remember them. From our assessment, we determined that the threat is high = 8 and the vulnerability is moderate = 5. This results in a risk factor of 40. We rated the threat as high because the password generated for logging in to the budget tracking system is the same password that is required to log in to the computer and all of the other company systems because we synchronized passwords for single sign-on purposes. If one password is compromised, all passwords are compromised, so the threat is high. However, it only applies to the local area network, so only an internal threat, such as another employee, a contractor, or a night janitorial cleaning crew would be able to use this login information; thus the vulnerability is rated medium. Let’s further say that the risk of 40 is among the highest risks calculated compared to other risks we evaluated, so it requires our immediate attention.

We then interview the managers and learn that those who are doing this do not realize that a password compromise could lead to other compromises, such as an employee who wanted to look up pay and performance data to use in a scam. We then develop a security awareness program, and we develop a system that provides users with a cryptographic key phrase to remember (with hints in case they forget it) so they can log in to a system that renders their passwords over a secure channel. Although such a system could still be compromised, it substantially lowers the risk factor, and so we can then attend to higher risks.

Topic Questions

5.1: What standard provides an extension to ISO/IEC 15408?

5.2: OCTAVE is primarily what type of method and has how many steps?

5.3: COBIT separates the framework components into:

___Stages and practices

___Goals and processes

___Control objectives and control practices

___Regulations and laws

5.4: Risk transference means:

___Patching systems so that risks are mitigated

___Placing the burden of risk on another party

___Litigating against an attacker

___Moving a threat from one area of a system to another

5.5: ITIL/ITSM is unique in that it focuses on the provision of information technology as a service.

___True

___False

5.6: Which of the following is part of ISO 27002:

___Build asset-based threat profiles

___Risk = threat X vulnerability

___Cost/benefit analysis

___Organizing information security

5.7: ISO/IEC 19791 provides an extension to ISO/IEC 15408.

___True

___False

5.8: NIST SP 800-30 is a risk determination and control framework.

___True

___False

5.9: The first step in the NIST 800-30 risk management process is the

__________

5.10: NIST SP 800-53 outlines security controls that are based on__________.

Questions for Further Study

Q5.1: Explain how regulations, standards, and laws affect what managers ought to do regarding security.

Q5.2: Discuss some ways (both qualitative and quantitative) that managers might assess risk.

Q5.3: What are some primary characteristics between risk assessment and risk management that managers need to consider?

Q5.4: Provide a description of one other risk management framework not discussed in this chapter.

Q5.5: Develop a short scenario on how one of the frameworks presented in this chapter could be used in a risk mitigation plan.

References

1.  Purser, S. (2004). A practical guide to managing information security. Boston, MA: Ar-tech House.

2.  Gibson, D. (2011). Managing risk in information systems. Boston, MA; Jones & Bartlett Learning.

3.  Straub, D. W., Goodman, S., & Baskerville, R. J. (2008). Information security: Policies, processes, and practices. Armonk, NY: M. E. Sharpe Books.

4.  Santhanam, R., & Hartono, E. (2003). Issues in linking information technology capability to firm performance. MIS Quarterly, 27(1), 125–153.

5.  Bharadwaj, A. S. (2000). A resource-based perspective on information technology capability and firm performance: An empirical investigation. MIS Quarterly, 24(1), 169–196.

6.  McKeen, J. D., Smith, H. A., & Singh, S. (2005). Developments in practive XVI: A framework for enhancing IT capabilities. Communications of the Association for Information Systems, 15, 661–673.

7.  Ma, Q., & Pearson, J. M. (2005). ISO 17799: “Best practices” in information security management. Communications of the Association for Information Systems, 15, 571–593.

8.  Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J., & Rance, S. (2007). An introductory overview of ITILv3. London: The UK Chapter of the itSMF. Retrieved September 29, 2011, from http://www.itsmfi.org/content/introductory-overview-itil-v3-pdf

9.  ISO/IEC 27001:2005. (2005). Information technology—Security techniques — Information security management systems—And requirements. Geneva, Switzerland: International Organization for Standardization.

10.  NIST SP 800-53. (2005). Information security—Recommended security controls for federal information systems. NIST Specification 800-53. Retrieved from http://csrc.nist.gov/publications/PubsSPs.html.

11.  Nichols, R. K., Ryan, D. J., & Ryan, J. J. (2000). Defending your digital assets against hackers, crackers, spies & thieves. New York, NY: McGraw-Hill.

12.  Bace, R. G. (2000). Intrusion detection. Indianapolis, IN: Macmillan Technical Publishing.

13.  Alberts, C., & Dorofee, A. (2003). Managing information security risks: The OCTAVE Approach. Boston, MA: Addison-Wesley.

14.  Caralli, R. A., Stevens, J. F., Young, L. R., & Wilson, W. R. (2007). Introducing OCTAVE Allegro: Improving the information security risk assessment process. Pittsburgh, PA: Software Engineering Institute.

15.  Larsen, M. H., Pedersen, M. K., & Andersen, K. V. (2006). IT governance: Reviewing 17 IT governance tools and analyzing the case of novozymes A/S. Proceedings of the 39th Hawaii International Conference on System Sciences.