Discussion 1

CHAPTER 1

Risk Concepts

In this chapter, you will:

•  Review basic security concepts

•  Learn about standards, frameworks, and best practices related to risk identification, assessment, and evaluation

•  Learn to describe how business goals, information criteria, and organizational structures affect risk

•  Determine how information systems architecture presents risk to the organization

•  Learn about risk ownership and awareness

•  Recognize legal, regulatory, and contractual requirements for risk management within the organization

This chapter will review a large portion of Certified in Risk and Information Systems Control (CRISC) Domain 1: Risk Identification with coverage of fundamental information security and risk management concepts. We’ll cover a good deal of the terminology associated with risk management and many of the core concepts you’ll need to be familiar with for the exam, but we will go into more depth on many of these concepts in later chapters.

The CRISC exam topics that we cover in this chapter are as follows and include the following domain objectives and knowledge statements:

•  1.6 Identify risk appetite and tolerance defined by senior leadership and key stakeholders to ensure alignment with business objectives

•  1.7 Collaborate in the development of a risk awareness program, and conduct training to ensure that stakeholders understand risk and to promote a risk-aware culture

NOTE    Throughout the book, the task and knowledge statements are listed in the order they are described in the CRISC Job Practice areas, not necessarily how they are presented in the chapter.

Basic Security Concepts

To successfully sit for the CRISC exam, you should be familiar with some basic security concepts. You can’t be expected to know how to manage risk in a security environment if you don’t understand the basics of security. We’ll assume you have some level of experience already as a security professional since risk management is a significant portion of (and a logical career progression from) the information security profession. You may also have had some level of experience in specific risk management processes during your career. As such, we won’t go into detail on the basic security concepts in the upcoming sections; this chapter will just serve as a quick refresher to remind you of certain security concepts.

The CRISC exam is not a technical exam; it is more of a process- and management-oriented exam, so we won’t delve into firewall configuration rules, protocol filtering, encryption, or any of the other fun stuff that security professionals do. We will, however, discuss a couple of other security concepts that are important to know for the exam since risk affects all of these concepts in different ways.

Goals of Information Security

Traditional security doctrine, as well as fundamental security knowledge you may learn from various training courses and on-the-job experience over the years, teaches that there are three fundamental security goals. These goals are what we’re striving for as security professionals; they are confidentiality, integrity, and availability. You’ll sometimes see these three terms strung together as an acronym, such as the CIA triad or, occasionally, as the AIC triad, depending upon the different security literature you read. In any event, these three goals are what you want to achieve for all of your information systems and data. They are also characteristics that you want all of your systems, processes, procedures, methods, and technologies to have. We will discuss these three items in the next few sections and why they are important to the security profession. We’ll also briefly describe some of the risks associated with these three goals.

Confidentiality

The goal of confidentiality is to keep information systems and data from being accessed by people who do not have the authorization, need-to-know, or security clearance to access that information. In other words, confidentiality means that only authorized individuals and entities should be able to access information and systems. Confidentiality can be achieved through a number of security protection mechanisms, such as rights, privileges, permissions, encryption, authentication, and other access controls. If the confidentiality of data or information systems is breached, you get the opposite of confidentiality, which is unauthorized disclosure. Unauthorized disclosure is a risk to data and information systems and one that we as security professionals struggle hard to protect against.

Integrity

Integrity is the characteristic of data that means the data has not been subject to unauthorized modification or alteration. In other words, it means data is left in the same state as it was when it was stored or transmitted. So, when it is accessed again or received, it should be identical to the data that was originally stored or transmitted. Integrity is achieved in several ways, by using checksums, message digests, and other verification methods. Data alteration is the opposite of integrity, particularly when the modification has not been authorized by the data owner. Data modification or alteration can happen accidentally, such as when it may be inadvertently changed because of human error or faulty transmission media. It can also happen intentionally (which is usually malicious in nature when this modification is unauthorized) by direct interaction with data during storage or transmission, such as during an attack, for example. This risk to data affects whether the data can be trusted as authentic or true, whether it can be read as intended, and whether it is corrupt.

Availability

Availability is when data and systems are accessible to authorized users at any time or under any circumstances. Even if data is kept confidential and its integrity remains intact, that does you no good if you can’t access it when you need it to perform critical business functions. Availability ensures you have this data (and the information systems that process it) at your fingertips. Just as confidentiality and integrity have their opposites, data destruction or denial of service is the opposite of availability. This risk to your information systems could prevent authorized consumers of that data or users of that information system from performing their jobs, thus severely impacting your business operations.  Figure 1-1  shows the relationships of the three information security goals to one another.

Figure 1-1    The three goals of information security

EXAM TIP    You will need to understand the definitions of the goals of information security well for the exam. Almost everything in information risk management supports these three goals, either directly or indirectly.

Supporting Security Goals

Popular security theory sets forth the three overarching security goals but also provides for auxiliary elements that support these goals in various ways. These are concepts that, both individually and combined, help you as a security professional to maintain data confidentiality, integrity, and availability, as well as protect your systems from unauthorized use or misuse. We’ll discuss these different security elements and other concepts, as well as how they support the three primary goals of security, in the next few sections.

Access Control

As a security professional, you probably already know that a security control is a security measure or protection applied to data, systems, people, facilities, and other resources to protect them from adverse events. Security controls can be broken down and categorized in several ways. Access controls directly support the confidentiality and integrity goals of security and indirectly support the goal of availability. An access control essentially means that you will proactively ensure that only authorized personnel are able to access data or the information systems that process that data. Access controls ensure that only authorized personnel can read, write to, modify, add to, or delete data. They also ensure that only the same authorized personnel can access the different information systems and equipment used to store, process, transmit, and receive sensitive data.

There are several different types of access controls, including identification and authentication methods, encryption, object permissions, and so on. Remember that access controls can be administrative, technical, or physical in nature. Administrative controls are those that are implemented as policies, procedures, rules and regulations, and other types of directives or governance. For example, personnel policies are usually administrative access controls. Technical controls are those that are most often associated with security professionals, such as firewalls, proxy servers, virtual private network (VPN) concentrators, encryption techniques, file and folder permissions, and so on. Physical controls are those used to protect people, equipment, and facilities. Examples of physical controls include fences, closed-circuit television cameras, guards, gates, and restricted areas.

In addition to classifying controls in terms of administrative, technical, and physical, you can also classify access controls in terms of their functions. These functions include preventative controls, detective controls, corrective or remedial controls, deterrent controls, and compensating controls. All of the different controls can be classified as one or more of these different types of functions, depending upon the context and the circumstances in which they are being used.

Data Sensitivity and Classification

Asset is a general, all-encompassing term that could include anything of value to an organization. The term asset can be applied to data, systems, capabilities, people, equipment, facilities, processes, proprietary methods, and so on; it is anything the organization values and desires to protect. Organizations normally determine how important their assets are to them and how much protection should be afforded to those assets. For example, intellectual property is an extremely valuable asset to the organization and is normally well protected. This is really the basic fundamental concept of risk management—how much security or protection a particular system or piece of data requires, based upon how likely it is that something bad will happen to it, balanced with what the organization can really afford to spend on the protection for that asset. To make reasonable decisions on how much security an asset needs, the organization has to decide how much the asset is worth to it. We’ll discuss worth in terms of dollars a bit later in the chapter, but for now let’s look at it from a perspective of asset sensitivity. In terms of sensitivity, you’ll usually see the term data sensitivity in particular, but you could also broadly consider sensitivity for any asset in an organization.

Data (or other asset) sensitivity refers to how much protection the organization feels a particular system or piece of data requires, based upon its value to the organization and the impact if it were lost, stolen, or destroyed. For example, information published on the organization’s public website or in the company newsletter is public knowledge and is usually easily retrievable if, for some reason, the hard disk containing that data fails or is erased. Since the data is public, you may not consider that data to be very sensitive in nature and require little protection for it. On the other hand, customer order data is extremely important to the organization simply because its business operations depend upon that data in order to function and turn a profit. So, it makes reasonable sense that the organization would spend a little bit more time, money, and effort in protecting that particular data. Therefore, its sensitivity, or classification level, would be considered somewhat higher than public data. Generally, the higher the sensitivity of the data, the more protection it is given.

In basic security classes, you typically learn about the different classifications of data found in both commercial organizations and government ones. In commercial organizations, typical data sensitivity labels include Private, Company Sensitive, Proprietary, and so on. In the U.S. government, data sensitivity levels include Confidential, Secret, and Top Secret, and they are classified based upon the level of damage to the security of the United States that could be incurred if data at these various classification levels were disclosed or lost. Remember that data sensitivity is driven by the value of the data to the organization and by the impact if it is lost, stolen, or destroyed, and it is balanced by the commitment of resources the organization is willing to provide to protect that data. Data sensitivity and classification policies specify the different formal levels of sensitivity in the organization and what those levels require in terms of protection.

Identification and Authentication

Identification and authentication are often misunderstood terms. They are related, to be sure, but they are not the same thing and really shouldn’t be used interchangeably by a knowledgeable security professional. Identification refers to the act of an individual or entity presenting valid credentials to a security system in order to assert that they are a specific entity. When you enter a username or password into a system, for example, or insert a debit card into an automated teller machine and enter a personal identification number (PIN), you are identifying yourself. Authentication is the second part of that process, where your identity is verified with a centralized database containing your authentication credentials. If the credentials you have presented match those in the authentication database, you are authenticated and allowed access to the network or resource. If they do not match, you are not authenticated and are denied access.

There are several methods of identification and authentication, including single factor (such as username and password, for example) and multifactor, which consists of two or more of the following: something you know (knowledge factor), something you have (possession factor), or something you are (biometric or inherence factor). Authentication also uses a wide variety of methods and technologies, such as Kerberos and 802.1X, for example.

Authorization

Authentication to a resource doesn’t automatically guarantee you have full, unrestricted access to a resource. Once you are authenticated, the system or resource defines what actions you are authorized to take on a resource and how you are allowed to interact with that resource. Authorization is what happens once you’ve successfully identified yourself and been authenticated to the network. Authorization dictates what you can or can’t do on the network, in a system, or with a resource. This is usually where permissions, rights, and privileges come in. In keeping with the concept of least privilege, users should be authorized to perform only the minimum actions they need in order to fulfill their position responsibilities. Authorization has a few different components. First, there is need to know. This means there must be a valid reason or need for an individual to access a resource, and only to a certain degree. Second, an individual may have to be trusted, or cleared, to access a resource. This may be accomplished through a security clearance process or nondisclosure agreement, for example.

EXAM TIP    Understand the differences between identification, authentication, and authorization. Remember that identification is simply presenting credentials, while authentication is verifying them. Authorization dictates what actions an individual can take on a system.

Accountability

Accountability means that a person is going to be held responsible for their actions on a system or with regard to their interaction with data. Accountability is essentially the traceability of a particular action to a particular user. Users must be held responsible for their actions, and there are different ways to do this; it is usually assured through auditing. First, there must be a unique identifier that is tied only to a particular user. This way, the identity of the user who performs an action or accesses a resource can be positively established. Second, auditing must be properly configured and implemented on the system or resource. What you are auditing is a user’s actions on a system or interactions with a resource. For example, if a user named Sam deletes a file on a network share, you want to be able to positively identify which user performed that action, as well as the circumstances surrounding the action (such as the time, date, from which workstation, and so on). This can be accomplished only if you have auditing configured correctly and you take the time to review the audit logs to establish accountability.

NOTE    Although related, accountability is not the same thing as auditing. Accountability uses auditing as just one method to ensure that the actions of users can be traced to them and that they are held responsible for those actions. Other methods, such as nonrepudiation, are used as well.

Nonrepudiation

Nonrepudiation is closely related to accountability. Nonrepudiation ensures that the user cannot deny that they took an action simply because the system is set up such that no one else could have performed the action. The classic example of nonrepudiation is given as the proper use of public key cryptography. If a user sends an e-mail that is digitally signed using their private key, then they cannot later deny that they sent the e-mail, since only they are supposed to have access to the private key. In this case, the user can be held accountable for sending the e-mail, and nonrepudiation is assured.

Figure 1-2  summarizes the relationships between access controls, the supporting elements of information security, and the three information security goals. Note that there is no hard-and-fast rule about mapping security elements and access controls to security goals; all of these elements and controls can support any one or even more than one goal at a time. For example, encryption, a technical access control, can support both confidentiality and data integrity at the same time.

Figure 1-2    How access controls support security elements and information security goals

NOTE    Although other books may describe the supporting elements of the security goals differently, the basic ones we’ve described here are common and directly support the three goals of confidentiality, integrity, and availability.

Risk Management Concepts

Now that we have framed some of the important information security concepts, such as the security goals and supporting elements, we will explain the basics of how risk is managed with relation to these concepts. As this chapter covers the foundational concepts associated with risk, we’ll cover the different terms you need to know for risk management. Risk management is the overall process of developing a strategy for addressing risk throughout its life cycle and includes several components. These include risk identification, assessment, analysis, evaluation, and response. We’ll talk about each of these different processes later in the chapter, as well as throughout this book. For the exam, you’ll need to know how these basic processes work, and as you proceed through this book, you will learn how to perform each of these risk management steps.

Risk Terms and Definitions

To fully appreciate the overall concepts of risk management and prepare for the exam, you need to be familiar with several key terms and concepts. In the next few sections, we’ll explain several of these key terms and concepts. Understand, however, that risk can be a complex body of knowledge to comprehend, so these are explained only at the basic level during this chapter. We will go far more in-depth on each of these terms and concepts throughout the remainder of this book, including how the terms relate to each other in the overall risk management process.

Vulnerabilities

Vulnerabilities are weaknesses in a system, operation, or facility that would make these resources susceptible to being exploited by a threat. Vulnerabilities can exist in the way a system processes, transmits, or stores data; they can also exist in the technologies that make up a system or even in its design. Even people can have vulnerabilities; one such weakness that affects the people in an organization is complacency. This weakness might prevent them from always following security practices, for example, and allow a security threat to take advantage of that weakness. Facility vulnerabilities could include a lack of physical security controls, a “blind spot” near a doorway to a secure area where an intruder may hide, and so on. One of the first steps in managing risk is to identify all of the vulnerabilities that exist within a system or facility so they can be adequately addressed. This is usually accomplished by conducting a vulnerability assessment, which attempts to thoroughly identify any and all vulnerabilities inherent to a system and its people, operations, policies, procedures, and facilities. We’ll discuss vulnerability assessments more in  Chapter 2 , but for now keep in mind that while a vulnerability assessment can be conducted as a stand-alone type of assessment, it really doesn’t have as much value unless it is part of a larger risk assessment, where it can be brought into context with other important elements of risk.

Threats and Threat Agents

A threat is a danger of harm that can be enacted on an asset. The asset has to be in danger from this threat and, theoretically, if there is no danger, then there is no threat. Threats exploit specific vulnerabilities. A threat must have a matching weakness in a system that it can exploit, or act upon, if it is to be an effective threat. An example of a threat and vulnerability pairing might be the use of a weak encryption algorithm in a system (a vulnerability) and a cryptographic attack against that algorithm (the threat). If the system used a much stronger algorithm, then the vulnerability would not exist, and that particular threat would not be a danger or risk to the system for that specific instance. A threat agent is something that causes or initiates a threat against a vulnerability. In the example given previously, a hacker or malicious actor would be the threat agent that exercises the cryptographic attack (threat) against the weak algorithm (vulnerability).  Table 1-1  gives some other examples of threats, vulnerabilities, and threat agents to further emphasize these concepts.

Table 1-1    Examples of Threats, Vulnerabilities, and Threat Agents

As you can see from  Table 1-1 , a threat is only the presence of something that can exploit a vulnerability; the vulnerability can be a concrete weakness or even the absence of a security control within the system (such as a lack of backup power or data destruction policy, for example) that creates a weakness or vulnerability. The presence of both of these conditions at the same time creates the potential for danger or harm to a system, its data, the people, or the facilities. This potential danger is defined as risk, but we will present a more comprehensive definition of that term in the next few sections. From the table you can also see that both vulnerabilities and threats directly affect the three primary goals of security (confidentiality, integrity, and availability). Both threats and vulnerabilities can also be different combinations of administrative, technical, physical, and operational in nature.

Threat assessments are often conducted to identify matching threat and vulnerability pairings, as well as the threat agents that could exercise a threat. Like a vulnerability assessment, the assessment does not have to necessarily be part of but can definitely support risk management. Threat assessments are conducted using a wide variety of data, including historical trends, statistical analysis, industry data, and other information from sources including the government, vendors, and even the organization.

Impact

Impact is what happens to the organization or to the business when a weakness or vulnerability is exploited by a threat. Impact can be expressed as a level of damage to an asset or the organization itself. It can be seen as how the business or operations of an organization are affected by a threat that exercises a vulnerability. Impact can also be cumulative; several smaller impacts that affect different systems within an organization can be additive and create a much larger impact on an organization than any one of them would. Impact can be expressed in terms of revenue lost based upon a complete or partial loss of an asset or process. It can also be expressed in terms of other concrete numbers or, even in subjective terms, based upon how serious the organization determines the effect of the event to be.

Likelihood

Likelihood is the probability of a threat exploiting a particular vulnerability. During threat and vulnerability assessment processes, the organization will normally determine the seriousness of a threat in terms of its impact if it occurs, based upon a certain level of weakness in the system. The organization also routinely determines the likelihood of these threats, given existing security controls and protections for an asset in the organization. For example, the likelihood of an intruder that breaks into an extremely secure facility that has gates, guards, and guns surrounding it, as well as high security fences, might be extremely low. A different facility without all of these security protections might incur a much higher likelihood of the same threat. In addition to security controls protecting an asset, other environmental factors might come into play, such as the facility residing in a “bad” neighborhood, distance from police and other emergency services, motivation of the threat agent, and so on. All of these different factors, which are really unique to the operational environment and asset in question, should be considered when determining the likelihood that a threat could occur. As with impact, likelihood could be measured in statistical percentages or subjective terms.

Risk

The four elements just described—vulnerabilities, threats and threat agents, impact, and likelihood—combine to make up the fundamental parts of risk. Risk is sometimes a difficult concept to get your arms around because it can be explained with different definitions, especially within the security community. On one hand, risk is a relative level of danger or harm to an asset. It’s also sometimes defined as the likelihood of a negative event happening to an organization and impacting its business operations. Another way of saying it might be the likelihood of a threat exploiting a vulnerability, causing an impact to an asset.

In any event, risk is a combination of these four factors, and it is a value that can be relatively measured using these factors. For example, impact can be expressed in lost revenue (dollars), lost productivity (labor hours), or even loss of market share (a drop in sales). Likelihood can be measured as a statistical probability (a percentage, for example) or even a subjective measurement, such as high, medium, or low. Threats and vulnerabilities can be a little bit more difficult to assign concrete values to; usually these values are also subjective, such as high, medium, or low designations. Later in this chapter, we’ll discuss how these values can be measured and risk can be expressed, using either quantitative (expressed as numbers) or qualitative (expressed using subjective values) methods.  Figure 1-3  attempts to bring together all of these factors to illustrate their relationships, helping you to better grasp the concept of risk.

Figure 1-3    Threats, vulnerabilities, likelihood, and impact

Two terms associated with risk that we will briefly describe here include inherent risk and residual risk. Inherent risk is associated with any endeavor, including risk associated with technologies, business processes, markets, and so on. All endeavors that businesses embark on contain some inherent risk that may be both unique to the particular endeavor and common to a technology or process. Residual risk, which we’ll discuss in depth later in the book, is the risk that remains after we have taken steps to respond to risk, either by reducing it or by mitigating it. It is a commonly accepted fact within the risk management community that risk can never be entirely eliminated; it can only be reduced to a manageable or acceptable level. Residual risk is normally the amount of risk left over after you’ve taken these steps, which must then be accepted. We’ll discuss more about risk response in  Chapter 5 .

It’s worth mentioning here that organizations typically maintain data associated with risk, including identified threats and vulnerabilities, as well as their likelihood and impact determinations, in what is known as an enterprise risk management (ERM) program. In addition to being a system that records and assists in analyzing risk management data, ERM is also the formal management program, including processes and methodologies, that the organization uses to manage risk throughout its entire life cycle.

EXAM TIP    Understand the differences and relationships between the four risk elements of threats, vulnerabilities, likelihood, and impact. Threats exploit vulnerabilities, and the level of risk is based upon the likelihood of the threat exploiting a given vulnerability and the impact to the system if it occurs.

Risk Culture, Appetite, and Tolerance

An organization normally has a risk culture, which is essentially how the organization as an entity feels about and deals with risk. This culture is developed from several sources. First, it can come from the organization’s leadership, based upon their business and management philosophies, attitudes, education, and experience. It can also come from the organization’s governance. Remember that governance is essentially the rules and regulations imposed either by external entities (in the form of laws, for example) or internally by organization.

In any case, the culture of the organization really defines how the organization feels about risk and how it treats risk over time. As part of the organization’s risk culture, there are its risk appetite and risk tolerance. These are different terms you also need to know to understand risk. Risk appetite is, in effect, how much risk an organization is willing to deal with in any given endeavor. This is the general level of risk that an organization is willing to accept in the course of its business. An organization’s risk appetite is driven by the corporate risk culture, in other words, by the environment the organization exists in (market, regulation, and other external factors).

Risk tolerance, on the other hand, is the acceptable level of deviation in risk for a particular endeavor or business pursuit. Risk tolerance is how much variation from the expected level of risk the organization is willing to put up with. There’s a certain amount of risk in every business enterprise or pursuit; however, the organization may not be able or willing to tolerate large deviations from what it considers is its acceptable level of risk on an endeavor.

EXAM TIP    Know the differences between risk appetite and risk tolerance; risk appetite involves how much risk the organization is willing to endure, and risk tolerance is how much variation from that amount is acceptable to the business for a particular venture. Risk culture drives both of these factors.

Standards, Frameworks, and Best Practices

Managing risk is not an ad hoc process. It can be a complex effort and involves establishing a formal program with responsible people leading it. It requires developing procedures and processes that are defined, repeatable, and defendable. Fortunately, you don’t have to reinvent the wheel; most of this work has already been done for you in the form of established frameworks, methods, standards, and practices. One of the first things you’ll want to do when establishing a risk program is to understand what type of framework, processes, standards, and practices you will use since there is a variety to choose from. You must try to use the one that fits your organization the best, and you can’t do that unless you have at least a basic understanding of the more defined, standardized ones used in the industry. Let’s take a moment and discuss the difference between frameworks, standards, and practices.

A framework is a generally overarching methodology for a set of activities or processes. It may not get into the detailed processes and procedures; instead, it provides for a 500-foot view of the general direction and steps used to build a more detailed program or process. A framework is used as an overall architecture for a larger effort. A framework has characteristics that include defined steps and repeatability and can be tailored based upon the organization’s needs. In terms of a risk management framework, you may have a set of general steps defining how to approach risk management, including listing the processes and activities necessary to build such a program or effort. You would then break down these larger steps into specific supporting procedures for this effort based on the needs of your organization and based on standards (described in a moment). Frameworks are typically selected and adopted at the strategic level of corporate management and governance.

A standard is a mandatory set of procedures or processes used by the organization, and standards usually fit into an overall framework. Standards often define more detailed processes or activities used to perform a specific set of tasks. Standards are used for compliance reasons and made mandatory by an organization or its governance. The National Institute for Standards and Technology (NIST) standards are mandatory for use by the U.S. federal government, for instance, but are published as an option for private organizations and industries to adopt if they so choose. If an organization adopts the NIST standards for risk management, for example, then the organization may make them mandatory for use by its personnel. Then all processes and activities for a given effort within the organization would have to use and meet those standards. Some standards define the level of depth or implementation of a security control or measure. The Federal Information Processing Standards (FIPS) for cryptography and encryption are an example of this; they set forth the different levels of encryption strength for various cryptography applications that may be required in certain circumstances. So, if you create security policies and procedures for implementing cryptography within the organization, the FIPS standard could tell you to what level those policies and procedures must be implemented.

A practice is a normalized process that has been tried and proven as generally acceptable within a larger community of practice. Practices could also be developed by a standards organization or a recognized authority regarding a particular subject or particular process. Professional industry organizations or vendors often develop practices documents. You might also see “best practices” promulgated by various industries or organizations, for example. Practices are not usually mandatory but could be made mandatory by the corporate management or other governance if they were so inclined.

The next few sections give more detailed examples of some of the formal frameworks and standards you should be familiar with for the exam and in real life as a risk management professional. We recommend you pay particular attention to the ones developed and published by ISACA; these are listed in the exam task and knowledge statements and will likely be present in some form on the exam. Of course, in this book, we will give only a brief overview of each, so you should take the time to review the actual standards and frameworks in-depth before you sit the exam.

NIST Risk Management Framework

The NIST Risk Management Framework (RMF) is a six-step methodology that provides for risk management all the way through the information systems life cycle. The steps for the RMF are briefly described in the following sections.

Step 1: Categorize Information Systems    This step involves inventorying the types of information on target systems and assigning categorization levels to that information based upon the level of impact based upon if the security goals of confidentiality, integrity, and availability were affected or compromised for that particular information on the system. This step uses subjective values of high, medium, and low to assign values to each of the three goals for a particular type of information. Types of information processed on the system could include business-sensitive information, financial information, protected health information, and so on. FIPS 199, as well as NIST Special Publication 800-60, provides detailed guidance on categorizing information systems.

Step 2: Select Security Controls    Based upon these individual values, as well as an aggregate of them, step 2 involves choosing the applicable security controls you would assign to each information system. This step provides baselines of security controls based upon the high, medium, and low values assigned during step 1. If the aggregate value of information or a system has been rated as high, for example, then the high baseline of security controls is employed for that system. Once the security control baseline has been established, the organization has the latitude and flexibility to add or subtract security controls from the baseline as it sees fit based upon different factors including the applicability of some controls, the environment the system operates within, and so on. You can find the selected controls in the supporting NIST Special Publication 800-53, revision 4, which contains a catalog of all of the NIST controls.

Step 3: Implement Security Controls    In this step, the selected controls are applied to the information systems, and data is processed on those systems. This in itself is a large process that can cover a good deal of the life cycle of the system in question, and it may take significant time and resources. In this step, the organization is essentially securing the information system against any validated threats and protecting identified vulnerabilities.

Step 4: Assess Security Controls    This step is where a lot of security professionals who manage certification and accreditation activities or perform risk assessments come into the picture. During this step, the controls that the organization selects for the information system are formally assessed, verifying that they implement them correctly and validating that they perform as they were designed. They are assessed based upon their effectiveness in protecting against the threats they were implemented to protect against. During this step, the system is assessed in its current state, with all existing controls and mitigations in place. Based upon the assessment, there may be recommendations for further controls and mitigations, as well as alterations to existing security posture for the system. In this step, the level of risk to the system and its data is normally analyzed and determined.

Step 5: Authorize Information Systems    Step 5 involves the decision from the entity with the power to authorize a system to be implemented and put into operation. This decision is based upon various factors, including the level of risk assessed during step 4, the risk appetite the organization has settled on, and the tolerance for risk that the organization is willing to accept. The decision to authorize a system for use may also come with caveats, including conditional authorization based upon the continued mitigation and reduction of risk by the system or data owner. This authorization is a formal authority for the system to operate, made by someone with the legal authority to make that decision. It is typically in writing and valid for only a specified period of time, after which the system must be reassessed for risk and control compliance.

Step 6: Monitor Security Controls    Continuous monitoring of security controls defines step 6 in the RMF; just because an authorization decision is rendered doesn’t mean that the system will now be operated forever without continually monitoring its security posture for new or increased risks. Existing controls will be monitored for continued compliance and effectiveness against identified threats, new risks will be occasionally discovered for the system as new threats and vulnerabilities are identified, and the system will have to be reauthorized after a certain period of time. Note that the RMF is a cyclical process; all these steps will be re-accomplished for each system at various times over the system life cycle.  Figure 1-4  summarizes and illustrates the NIST Risk Management Framework.

Figure 1-4    The NIST Risk Management Framework (courtesy of NIST, from Special Publication 800-53, revision 4)

As you can see from  Figure 1-4 , each step of the RMF has associated NIST publications that provide guidance on performing that particular step. Additionally, however, there are also NIST publications that help you manage the overall risk process within the organization. These publications support the RMF by providing more detail on processes and activities, such as managing risk in the organization, implementing the RMF, and even performing risk analysis. The three primary standards that support the RMF are:

•  SP 800-30, Guide for Conducting Risk Assessments

•  SP-800-37, Guide for Applying the Risk Management Framework to Federal Information Systems

•  SP-800-39, Managing Information Security Risk

Keep in mind that there are other standards, however, that support the individual steps of the RMF. These three provide the overall guidance and detail concerning how to implement the RMF’s processes.  Appendix A  goes into detail on decomposing the different steps and associated publications with the NIST RMF, so see that part of the book for a complete breakdown of the framework.

COBIT 5 (ISACA)

Control Objectives for Information and Related Technology (COBIT) is a framework developed by ISACA; it covers several key areas in business governance and IT enterprise management. COBIT covers key areas in auditing, compliance, information assurance, IT operations, and security risk management. This framework has been around for several years and through several iterations; COBIT 5 integrates several other frameworks developed by ISACA into a single unified framework, including the Risk IT, Value (Val) IT, and the IT Assurance Framework (ITAF). It also provides for easy integration of other popular frameworks and standards, including The Open Group Architecture Forum (TOGAF), the Project Management Body of Knowledge (PMBOK), the Information Technology Infrastructure Library (ITIL), Projects In Controlled Environments 2 (PRINCE2), the Committee of Sponsoring Organizations of the Treadway Commission (COSO), and the many International Organization for Standardization (ISO) standards. This interoperability enables new users of COBIT to leverage any of these other standards they have already been using in their adoption of COBIT.

COBIT combines the best of tried-and-true standards into its fold; it is compatible with the principles of ISO/IEC 38500:2008, Corporate Governance of Information Technology, for example, and provides strategy and activities supporting those principles. COBIT also is interoperable, to various degrees, with standards such as the ISO/IEC 27000 series of standards and covers similar security and risk management areas under its domains.

COBIT consists of two layers in its model, governance and management, and separates those two layers into five governance processes and four management domains, respectively. These layers further break down into a total of 37 separate processes.  Table 1-2  quickly summarizes these layers and domains and the process they decompose into.

Table 1-2    COBIT 5 Layers, Domains, and Processes

Note that while COBIT covers a variety of business and IT processes and areas, those specific to risk management happen at both layers—governance and management—and are tightly integrated with other processes. COBIT in this regard is not a risk management framework per se, as is NIST’s RMF, but offers a broader view of management and governance across all major areas of a business. The next topic we cover, ISACA’s Risk IT Framework, supports COBIT and provides a more granular view of risk management practices and activities.

NOTE    Understand that while COBIT is important to the overall risk discussion, it is not a risk framework itself. It does, however, support management and governance of not only IT but other critical business areas as well. It also leads into a more detailed discussion on the ISACA Risk IT Framework, which does deal with IT risk.

The Risk IT Framework (ISACA)

The Risk IT Framework is a more concise, risk-related set of processes than offered by its related parent framework, COBIT 5. While COBIT covers the “big picture” of governance and management processes that support risk management programs in the organization, the Risk IT Framework gets more into the key processes of risk management, such as risk governance, evaluation, and response. The Risk IT Framework is also a mere summary of ISACA’s The Risk IT Practitioner Guide, available to ISACA members, which is an even more in-depth treatment of the processes and activities encountered during risk management.

The Risk IT Framework comes from traditional risk management principles of various enterprise risk management standards and describes activities and processes thought of as best practices in the industry. It provides a starting place for establishing these processes—sort of a map to navigate from a nonexistent or immature risk management program to a formalized, defined set of processes. The Risk IT Framework focuses more on the business risks of using IT in the organization’s structure and how risk is involved with the gap often found between IT implementation and business goals.  Table 1-3  lists the different domains of the Risk IT Framework model, with each of their three major processes.

Table 1-3    The Domains and Processes of ISACA’s Risk IT Framework

Keep in mind that we’ve covered only a few of the risk-related frameworks and standards available in the industry. Also, be aware that we’ve only scratched the surface of these bodies of knowledge in this chapter; a full discussion of every one of them is beyond the scope of this book. You should obtain and review these publications more before you sign up for the exam. There are also many other available frameworks and standards developed and promulgated by other professional organizations, government entities, industries, vendors, and so on. You should be familiar with as many of these as is relevant to your work since they help you turn risk management from “magic” into an art and science for your organization. The frameworks and standards we have described so far are the ones most relevant to your studies for the CRISC exam.

EXAM TIP    While you may not be expected to know the intricate details of each framework described here, it will be helpful to know at least the basic characteristics and descriptions of each. You may be asked to identify a particular characteristic of a framework on the exam.

Business Perspective of IT Risk Management

Up until this point, we have discussed risk strictly from an information security perspective; however, the business aspect of risk management is far more inclusive and broad than the information security focus we have presented so far in this chapter. Although, as an information security professional, you probably tend to look at things through a data protection lens, you must realize that information security risk is really a subset of the risk management considerations that affect the entire organization from a mission or business point of view.

There are several different perspectives of risk in the context of the business environment, most related to legal liability, governance, profitability, market share, and operations sustainability, to name just a few. We could also include risks to intangible elements, such as reputation, consumer confidence, shareholder value, and so on. Opportunity represents potential growth for a business, but opportunity always comes with some level of risk involved. The key to managing this risk is to balance risk of failure with the potential benefits of the business opportunity. Risk tolerance and appetite are factors that figure into this balance for the organization.

In this part of the chapter, we’ll cover the risk of information technology systems from more of an organizational and business perspective. We’ll explain different business and information technology structures and how they affect risk management within the organization. We’ll also cover infrastructure, platforms, and other aspects of technology that can introduce risk into the organization.

CAUTION    Remember that the focus on risk from upper management is usually on business risk, not merely IT risk. IT risk is only a small part of the risks faced by the organization in carrying out its mission and goals. You must sometimes frame risk in terms of the business mission, not only from an information technology perspective.

Business Goals and Objectives

Businesses exist with clear missions, goals, and objectives. The organization is in business for a particular purpose, not merely because people want to come to work every day and socialize. Missions, goals, and objectives directly relate to why the organization is in business in the first place, whether that is to develop and market a product or provide a service. Organizational senior management defines the business’s mission, goals, and objectives, typically on a strategic or long-term level. Senior management also defines the levels of risk tolerance and appetite, based upon factors that include the market space, operational environment, economy, governmental regulation, and so on. These risk levels directly articulate and support the business mission, balancing business opportunity that can generate revenue and move the business forward with potential negative events that may cause the business to fail, or at least have a detrimental impact to the organization.

TIP    Remember that risk appetite and tolerance are directly related to the business mission, although different business pursuits may have varying levels of each. Senior management sets those levels based upon the potential rewards from risky opportunities and the amount of loss the organization could endure if those rewards don’t materialize.

Business Information Criteria

Information is a commodity. Even if the company is in the business of producing goods to bring to market, it still relies on its information and its technology as enablers to produce those goods and deliver them to the market and consumers. Without the ability to generate, process, and otherwise use information, modern businesses would not be able to produce goods or services and compete in market spaces. So, any negative events that affect the organization’s ability to process information directly affect the ability of the organization to survive. Information technology directly supports business goals, objectives, and strategy. All elements of a business endeavor depend upon IT, including the organization’s information or data, its people, its line-of-business applications and systems, and its overall infrastructure, including all of its equipment and processes.

Information technology affects risks to the business enterprise in two ways. First, information technology is used to help protect the enterprise from risk; in other words, it serves to protect the information the business generates and relies on. That’s the purpose of having high-capacity storage, faster networking equipment, redundant systems, and security devices sprinkled throughout the infrastructure. The second way that IT affects risk is that it helps the organization to produce the information needed to fulfill its business goals and objectives in the first place. Without IT, there would be no information processed, no systems designed, and no advanced technologies developed for a business to take to market and compete with. So, IT serves to both protect information and generate it to advance business goals.

The information the business generates and uses has several key characteristics. First, it should be relevant to the processes it supports. It should also be timely; stale information can prevent a business from fulfilling its functions in both the short-term and the long-term. It should also be accurate and complete. This is where information integrity comes in, which is one of the goals of information security. Anything that affects the accuracy and completeness of information is a risk. Information should also be controlled for access. Again, you learned earlier in the chapter that confidentiality is one of the goals of information security; controlled access to information and the systems that process it is a must in order to maintain business function. As you might guess, another characteristic of business information is availability to the users who need it whenever and however they need it. This means that authorized users should have business information on a timely basis and in a format that suits their needs. Risk factors that affect any of these information characteristics, such as relevance, timeliness, integrity, confidentiality, and availability, must be considered in the overall risk management process for the organization. Any detrimental impact on these characteristics presents a risk to the business mission.

EXAM TIP    Many elements of risk management can be traced back to the three information security goals or the security tenets discussed earlier in the chapter. You should be able to examine risk and determine how it can be traced back to (and how it affects) those goals and tenets.

Organizational Structures

How the business is organized can help drive how it deals with risk, in several ways. Most businesses are organized from a functional perspective; in other words, there are departments and other hierarchical structures established to take care of specific functions that contribute to the business goals and objectives. For example, in a production-driven business, there may be a manufacturing or production department, an engineering department, a research and development department, or an assembly line. There will likely be additional departments that cover support functions, such as marketing, accounting and finance, public relations, and so on. A hospital, on the other hand, will be organized according to its specific functions, such as the emergency department, surgery, neurology, radiology, and so on. Businesses in other markets or areas will be organized differently as well. In any case, the organization of the business is structured as its mission and business purposes dictate. There are certain functions that may be found in any business and may deal with information technology, information security, or even legal compliance. These functional areas may have the primary function of dealing with risk, but an important thing to consider is that all different organizational structures, from lower-level work sections to higher-level departments and divisions, have responsibilities regarding risk.

The organization must look at its structure and decide how each individual unit will manage risk at its own level, understanding that risk management must be uniform throughout the entire organization. Another consideration is that risks tend to “roll up,” or be combined at the higher levels of organization. For example, risks that the accounting department incurs are only part of the higher organizational levels’ risks and included in the risk management processes. Each lower-level unit in an organizational hierarchy has risks that are part of the next higher levels’ risk considerations. While individual units may be responsible for only a small piece of the overall organizational risk, their parent units also bear responsibility for managing that risk, as well as the risk of other subordinate units. Another concept relating to organizational structures is that the risk incurred by one part of the organization is borne by all parts of the organization; there is almost no such thing as risk that affects only one small part of the business. Risk ripples across the entire organization in some way.

Each individual unit, whether it is a unit in the lower levels of the business hierarchy or at the highest levels, must take steps to identify, evaluate, and assess risks at their level. Risks may be thought of as tactical, operational, and strategic. Tactical risks are those that are encountered by smaller-level production sections, in other words, those that carry out the day-to-day work of the organization. Operational risks can span several work units and relate to how the business conducts its functions, as well as how the different work units interact with each other. Strategic risk is borne at the higher levels of the organization, including senior management, and involves risks incurred by leading the business toward opportunities and away from decisions that exceed the organization’s capacity for risk appetite and tolerance. Respectively, these three types of risks also correspond to short-term, mid-term, and long-term risks.

Regardless of the level of risk incurred within the organization, there must be an enterprise risk management strategy and program in place to deal with the lower-tier, middle-tier, and higher-tier risks, as well as ensure that all of the risks are managed consistently and uniformly. Governance from the higher levels of the organization affects risk appetite and tolerance and shapes the organization’s risk management strategy throughout all the different hierarchical levels. Organizational structure must support that governance, as well as clearly define lines of authority and responsibility in terms of risk leadership and management.

Information Systems Architecture

The information technology architecture within the organization affects the risk of the business in several ways. Aspects of IT architecture risk include interoperability, supportability, security, maintenance, and how the different pieces and parts of the infrastructure fit into the systems development life cycle. The business views IT as an investment of capital funds, much as it would facilities and other equipment, as a means to an end in supporting the business mission. Information systems represent risk to the business because of the aforementioned interoperability, supportability, security, and other issues. It costs the organization money to maintain and support all of the IT assets within the company, in the form of parts, training for administrators and users, and upgrades. There are also the intangible aspects of IT, such as business value and liability. IT systems affect the bottom line of the organization, so there’s a lot of thought put into managing risk for them. Additionally, you should take care to remember that information technology risk is only a piece of the entire enterprise risk picture. In the next few sections, we’ll talk about different aspects of the information systems architecture and how they contribute to the overall enterprise risk in the organization.

Platforms

Platforms are the operating systems and distinct architectures the business information systems run on. Businesses could use the Windows and Unix platforms or the Intel and SPARC platforms. Platforms are an element of the IT infrastructure that contributes to the information security and business risk for several reasons. First, it costs to simultaneously maintain different operating systems and environments that come in different platforms. Platforms also introduce risk into the environment in the form of interoperability, security, and supportability. A diverse platform environment (with mixed platforms, such as Windows, Linux, Macs, Unix, and so on) can affect interoperability with other systems because of differing versions of software and different network protocols, security methods, and so on. A diverse environment can also affect supportability because the organization must maintain different skill sets and a wide knowledge base in order to support the diverse platforms.

On the other hand, maintaining a homogeneous environment can reduce costs, ensure interoperability, and allow a more common set of security controls and mechanisms, such as patch management and configuration management. However, there is even risk involved in a homogeneous platform environment because of the likelihood that a vulnerability discovered in one system would also be shared in many others, offering a wider attack vector for a potential malicious actor. It is really a matter of the systems development life cycle (SDLC) as to how and when platforms are developed, introduced into the infrastructure, implemented, maintained, and, eventually, disposed of, and there is risk inherent to all of these different phases, which we’ll discuss more in  Chapter 2 .

Networks

A network is another aspect of the IT infrastructure that inserts risk into the business environment. While networks are necessary to carry data both within and outside of the organization, these benefits do not come without some degree of risk. Risk can be introduced from a variety of issues, such as unsecured protocols, lack of encryption for data in transit, improper data or system access through weak authentication mechanisms, interception and modification of data, and so on. Networks should be designed to carefully control traffic during all aspects of data transmission, routing, and reception in order for a network to be considered secure.

Applications

Applications introduce risk simply because in this day and age they’re so critical to the operations of businesses. Businesses need not only basic word-processing and spreadsheet software but also complex databases, line-of-business applications, specialized software, security software, and other types of applications. Applications have to be managed to their own life cycles as well; they’re constantly being patched, upgraded, superseded, and replaced by better, faster software with more features that usually cost more. Risks that are inherent to managing applications within an organization include supportability, backward compatibility, data format compatibility, licensing, and proper use.

Adding to this complexity are the decisions an organization makes in terms of selecting proprietary software, open source software, general-purpose commercial software, or highly specialized software. All of these different categories incur different levels of cost, supportability, licensing, and feature sets. Interoperability also plays a part in application risk, like it does with other infrastructure components. Applications that do not use common data formats or produce usable output for the organization create risk of expense or additional work that goes into transforming data between incompatible applications. Applications also introduce risk into the business environment with the level of security mechanisms built into them and how effective those security mechanisms are in protecting data residing in the application.

It’s worth mentioning here that web-based applications, in addition to presenting the same risks as normal client-server apps, also have their own unique risks. Security is a definite risk imposed by web-based applications since they often directly connect to unprotected networks, such as the Internet. Other risks include those that come from the wide variety of web programming languages and standards available for developers to use.

Databases

Databases, as a subset of applications, impose some of the same risks that applications and other software do. Additionally, databases incur risks associated with data aggregation, compatibility, privacy, and security. Aggregation and inference are risks associated with database systems. Unauthorized access and data loss are also huge risks that databases introduce into the enterprise environment.

Operating Systems

Although we discussed platforms in a previous section, it’s worth mentioning operating systems as their own separate risk element in the IT infrastructure. Platforms and operating systems are sometimes used interchangeably, but truthfully, a platform is more a hardware architecture than an operating system categorization. A platform could be an Intel PC or a tablet chipset, for example, which is designed and architected differently and run on totally different operating systems. Different operating systems, on the other hand, could run on the same platform but still introduce risk into the organization, for the same reasons discussed previously with applications. First, there are interoperability and supportability risks and all of the other issues that go hand-in-hand with the normal operating system life cycle, such as patch and vulnerability management. Licensing, standardization, level of user control, and configuration are also issues that introduce risk into the organizational computing environment.

EXAM TIP    Although information security professions tend to focus more on the technical aspects of IT risks, for the exam keep in mind that all IT risks contribute to the overall business risks in the enterprise as well. Make sure you look at the larger picture beyond the IT realm.

Managing Risk Ownership

It makes sense that the organization owns all of the risk that it incurs, which is definitely true to a certain extent. However, within each organization, there are areas that “own” their own piece of risk; in other words, they are responsible for managing it and responding to it. In some cases, they are also responsible for identifying, analyzing, and evaluating risk as it pertains to their functional or defined area. Risk ownership is an effort that requires risk owners to take responsibility for their areas of risk and ensure that they are properly managed throughout its life cycle. In this section, we’ll cover risk ownership in-depth and how it relates to the concepts of risk tolerance and appetite that we discussed earlier in the chapter.

Another related area to risk ownership is that of risk awareness training. The reason this is related to risk ownership is that everyone in the organization, including those responsible for managing risk, must be aware of how risk is identified, evaluated, managed, and responded to throughout the organization. They should also be made aware of the risk management strategy the organization uses and their role in that strategy. This section will also cover risk awareness training and how to implement it within the organization.

Risk Ownership

Risk ownership is a concept that provides a focal point for responsibility and accountability for managing risk throughout its life cycle, including identifying it, assessing and evaluating it, responding to it, and monitoring it. Risk owners take responsibility for risk in their own functional domains within an organization, although you should understand that the risk from several areas is usually “rolled up” into overall organizational risk and is owned by the senior executives or board members who are legally responsible for the organization. There are several components to risk ownership.

The first component is governance. Governance, remember, can be external laws and regulations that the organization is required to comply with. It can also be internal regulations and requirements set by senior leadership within the organization. As part of governance, the organization should set a formal risk strategy and risk management plan, which should detail how risk ownership is defined within the organization. Risk ownership may be defined by functional area, hierarchy within the organization, or any number of other factors.

Other components of risk ownership include responsibility, accountability, and the ability to control the resources that can effectively manage risk (people, funding, equipment, supplies, facilities, and so on). Responsibility means someone has been given the formal authority to manage risk, either by position or by specific appointment from the organization’s leaders. A risk owner may have responsibility for a specific area of risk. Responsibility also means that the risk owner bears the burden of being held accountable for their actions in risk management. Accountability means that risk owners must be prepared to take the consequences for success or failure of the risk management efforts. Finally, risk owners must be given the resources and the authority to control those resources in order to effectively manage risk within their area of responsibility. If they have the responsibility and accountability but don’t have any control over resources to help manage risk, they will be quite ineffective and won’t be able to meet their responsibilities.

EXAM TIP    Remember that regardless of what area within the organization is considered a risk owner, ultimately the responsibility for owning and managing risk belongs to the highest level within the organization. This would likely be either the person or the group that has legal liability and responsibility for the organization, such as the chief executive officer (CEO) or the board of directors, as appropriate.

Risk ownership is directly affected by appetite and tolerance. Since these two factors are derived from the organization, they are defined by senior leaders and management, boards of directors, shareholders, and other key entities within the organization. Governance can also help drive risk appetite and tolerance; the organization may establish rules and regulations that strictly limit or are less restrictive toward taking and managing risk. The organization’s take on appetite and tolerance directly affects risk ownership because risk owners must manage the risk within their areas based upon these two factors in order to be in line with the organization. Senior leaders, shareholders, and boards of directors must establish the organizational risk culture in order to give boundaries to risk owners within the organization. They may also require that risk owners consult and validate risk decisions with senior management, based upon different threshold or tolerance levels.

EXAM TIP    Remember that risk acceptance and tolerance come from the senior management levels of the organization and drive the organization’s risk culture. They also drive how risk ownership is defined and structured within the organization.

Risk Awareness

Risk awareness is a necessary part of risk management. It can’t be viewed as simply just another two-hour training session to check a box for management or compliance. Risk awareness is essential because it helps form and maintain the organization’s risk culture. It also educates personnel at all levels of the organization, including employees, managers, and senior leadership, on the organization’s risk strategy, its appetite and tolerance levels for risk, its risk management plan, and other relevant topics necessary to manage risk in the organization. Beyond the education on organizational governance and risk management processes, awareness training can give all members of the organization the knowledge they need to better identify, assess and evaluate, and respond to risk. Risk awareness training may be required for compliance with governance in some cases, but even if it’s not, it should be considered critical to the overall risk management strategy in the organization and given its due consideration in the organizational priority list. The next two sections will discuss the different tools and techniques used in risk awareness training and how to develop a risk awareness program within an organization.

Risk Awareness Tools and Techniques

Like most training, risk awareness training should meet several criteria. First, it should be geared toward specific groups of audiences. This might include basic employee training that everyone receives, more advanced training for managers or senior leaders, and in-depth training for those personnel with assigned risk management responsibilities, such as risk owners, risk analysts, and so on. Second, training shouldn’t be a one-time event. Periodic, recurring training is a good idea simply because it can be used to reinforce and refresh stale knowledge and bring trainees up-to-date on the latest tools, techniques, and risk considerations. Finally, risk awareness training should be well organized and conducted by knowledgeable instructors, both from inside and outside the organization. Internal trainers can give the benefit of the organization’s specific views on risk culture, appetite, and tolerance, while external trainers bring the benefit of objective knowledge and risk management methods from industry.

The subject of the training depends upon the audience, of course. The basics may include familiarization training with rules and regulations regarding risk within the organization, as well as the basic steps of risk management. Basic concepts and definitions may also be provided in familiarization training. Specific training on risk management techniques and tools may be reserved for those employees who have direct risk management responsibilities. There also may need to be training for senior leadership on how to develop risk management strategy and plans for the organization.

There are several ways that an organization can deliver risk awareness training; different combinations of all of them should probably be used to deliver an effective training program. Classroom training is, of course, one standard method. Other methods might include individual-based training that comes from reading, computer-based training, and so on. Employees might also be required to read a risk management handbook that defines the different rules and regulations covering risk within the organization. Specialized training on risk management might have to be provided by an external training provider for those individuals with defined risk management responsibilities.

Developing an Organization Risk Awareness Program

Establishing a risk awareness program in an organization can be a challenge. One way organizations fail is to simply direct someone to develop a training program when the organization has not even established its risk management strategy or plans. Developing the organization’s take on risk is an essential first step before implementing risk awareness training. The organization has to develop, formally if possible, its stance on risk appetite and tolerance, as well as its risk management strategy. It should decide what risk management methodologies it will use, as well as what standards and frameworks. Only then can a training program be developed based upon a good solid risk management framework within the organization.

Establishing the risk awareness training program also requires buy-in from management at all levels. The program should be adequately funded, and allowances should be made for employees to be able to take part in the training. Management should be committed to risk awareness training as part of its overall risk management strategy. Sufficiently trained and experienced instructors or a training program manager should be selected in order to develop and maintain the program. Finally, the training program should articulate not only the risk culture of the organization but also the different risk management needs the organization has. These might include its specific risk factors, threats, vulnerabilities, and so on, taken into account when the training is developed. Employees who participate in risk awareness training should be able to easily put into practice the concepts, tools, and techniques they learn. Additionally, the training program should be periodically evaluated for effectiveness, as well as updated with current risks, governance, tools, and techniques.

Beyond initial or recurring risk awareness training, ongoing communication within the organization is a must for effectively managing risk awareness. Employees in general, but also specifically those with key risk management duties, should be given information on an ongoing basis regarding organizational risks and how to manage and deal with them. Obviously, some information would be restricted from the general organizational population, but specific instances of threats and vulnerabilities, risk factors, and so on, should be provided to risk managers in key areas so they can keep updated on the most current risk posture for the organization.

Exercise 1-1: Developing a Risk Awareness Program

Review any risk awareness training programs, procedures, or documents within your organization. How often is training conducted? Is it geared toward both the general population of the organization and the specific key roles and responsibilities? Does it cover not only regulations but also risk management methodologies and frameworks? What suggestions could you make to your organization regarding the improvement of its risk awareness training program?

TIP    While training programs are sometimes the first things that are cut from the budget or the last things to be developed in a program, don’t underestimate the importance of risk awareness training within the overall risk management strategy. Not only can training make the risk management process within the organization more effective, but it can also help reduce or mitigate risks by itself since it also has the effect of educating people on risk and this alone may even help minimize it.

Legal and Governance

An organization’s way of dealing with risk—how it formulates strategy, risk management plans, risk response methods, and so forth—comes from a desire to succeed in its business, mission, and goals, of course. But risk management can also be compulsory and not just a smart way of doing business. How an organization manages risk is often directive in nature and can come from different types of governance. Governance includes laws, regulations, and statutes, of course, but it also includes organizational directives. Policies, as well as the procedures and standards that support them, are also considered governance. Depending on its source, different types of governance may be legally binding or not. Obviously, laws and statutes are legally binding, while organizational policy may not necessarily be so.

As a risk manager, you should know something about the various laws and regulations that require an organization to engage in a definitive, coherent risk management strategy and process. While a detailed legal discussion of the dozens of laws and regulations that compel an organization to establish a risk management program are beyond the scope of this book, you should have an understanding of some of the key directives that govern risk management with regard to information protection. This section will discuss a few of those key regulations, as well as how to identify the governance that applies to your organization and how that governance drives your risk management strategy.

Laws, Regulations, and Standards

Many of the different laws and regulations that govern risk management in organizations are business sector and data specific; that is, they specifically apply to a particular area or type of data. For instance, the Health Information Portability and Accountability Act (HIPAA) requires hospitals, doctors, clinics, and other healthcare providers to establish a risk management program to protect sensitive healthcare information. HIPAA wouldn’t apply to a bank or financial company, although other laws would. We’ll discuss some of these in the upcoming paragraphs.

One of the most common laws requiring risk management within the information technology world is the Federal Information Security Management Act (FISMA) of 2002. FISMA applies to all U.S. federal government agencies, requiring them to establish information security programs for all federal systems, as well as report risk management and compliance information on an annual basis. FISMA is implemented using various programs within the federal government, depending upon the agency. For example, the U.S. Department of Defense implemented FISMA using the Defense Information Assurance Certification and Accreditation Program (DIACAP) as its vehicle for IT risk management in 2006 but has since replaced it (in March 2014) with NIST’s Risk Management Framework. The RMF, as described earlier, provides a risk management process for use in all federal agencies.

The aforementioned HIPAA applies to healthcare providers in the United States and specifically requires that a formal risk management program be established in its Security Rule subsections. The rule further states that risk assessments be performed on all systems that process electronic protected health information (EPHI). Healthcare providers are subject to periodic audits to verify that the provisions requiring risk management are followed.

The Payment Card Industry Data Security Standards (PCI-DSS) were developed by the members of the payment card industry, such as Visa, MasterCard, and so on, to establish a recognized set of standards for information security that applies across all industry partners (for example, banks, retailers, and card issuers). While more technical in nature, the standards require information security policies, vulnerability management, and other risk-based security controls to protect cardholder data.

Financial institutions (banks, brokerage companies, and so on) are the primary focus of the Gramm-Leach-Bliley Act (GLBA), although it also applies to some extent to other organizations. GLBA requires periodic risk analysis performed on processes that deal with nonpublic financial information and personal financial data. While GLBA was primarily designed to allow certain types of financial institutions to merge and interoperate, important risk management requirements were also put into place with this law, such as the Financial Privacy Rule, the Safeguards Rule, and the Pretexting Protection. These rules were included in this legislation to protect consumer privacy, establish information security safeguards (including risk management and analysis), and guard against social engineering attacks, respectively.

Identifying Legal and Governance Requirements in the Organization

Regardless of the type of market or segment in which your organization is involved, there are likely requirements levied by the law, regulations, contract requirements, and even internal organizational policies that require some type of risk management program to be developed and put into place. Obviously, if your organization is a federal agency, a healthcare provider, or some type of financial institution, then you probably fall under the requirements from one of the laws described earlier. Additionally, if you process any type of consumer credit cards or maintain financial information on individuals, they likely fall under at least the PCI-DSS, if not others. However, even if your organization does not fall under one of the previous categories, you may have legal or regulatory requirements to maintain a risk management program. Often, businesses are members of the industry associations or professional organizations that require risk management as a condition of membership. Additionally, contractual agreements with other organizations often have stipulations built in that require risk management.

Some of these nonregulatory requirements may include requirements for the organization to have a risk management program, for the organization to perform risk assessments and analysis, and for the organization to demonstrate due care and diligence in reducing or mitigating risk. While some of these requirements might not be specifically stated as “risk management” activities, they may come in the form of requirements to maintain security policies, require separation of duties or data, implement standard safeguards (such as strong authentication and encryption methods, for example), and periodically test systems for vulnerabilities. Regardless of how they are stated in policies or contracts, these requirements can be legally used to determine liability for an organization in the event its risk management activities are ever questioned.

When determining legal or regulatory requirements for risk management activities, you should consult with both your organization’s legal representatives, as well as its executive management. You should also research any requirements levied by external organizations or contractual obligations. You must take these requirements into account when developing a risk management program, as well as when developing an information security program. These requirements will likely impact the organization’s stance on risk, as well as its levels of risk appetite and tolerance.

Exercise 1-2: Identifying Legal, Regulatory, and Contractual Requirements

For this exercise, you should attempt to identify and record any legal, regulatory, or other requirements levied on your organization that require a risk management program or activities. You could consult your legal department, talk to senior management, or even perform research on similar organizations. In your attempt to identify these requirements, you may actually uncover other sources that could require risk management activities within your organization. How do these requirements affect your business? Do they influence the organization’s risk appetite and tolerance levels? How are information security programs developed and implemented to meet the requirements for risk management levied by these laws, regulations, or contract requirements?

Chapter Review

In this first chapter, we discussed fundamental concepts of both security and risk management. The three goals of security, known as the CIA triad, are confidentiality, integrity, and availability. Supporting these three goals are other elements of security, such as access control, data sensitivity and classification, identification, authentication, authorization, accountability, and, finally, nonrepudiation.

Risk management is the overall process of developing a strategy for addressing risk throughout its life cycle and includes several components, including risk identification, evaluation, and assessment. We discussed the different concepts associated with risk management, including the threat agents, threats, and vulnerabilities that are associated with assets. We also looked at the variables that affect how these elements create risk: likelihood and impact. The relationships between these elements are what define risk. We also looked at the organizational culture and examined the definitions for risk appetite and risk tolerance.

We then defined standards, frameworks, and practices, and we detailed some of the ones relevant to risk management. We looked at the NIST Risk Management Framework, COBIT 5, and the Risk IT Framework.

We then looked at the business perspectives of IT risk management and discussed how risk from the IT perspective is only a subset of the overall enterprise risk. We examined how business views risk from a mission perspective and covered the criteria business information must meet in order to support that mission. Organizational structures also affect the overall business risk since how the business is organized affects how it incurs and manages risk. We also looked at various elements of information systems architecture and some of the inherent risks involved with those elements. Platforms, networks, applications, databases, and operating systems are all elements of the infrastructure that contribute not only to the IT risk but also to the overall enterprise risk.

We then examined concepts of risk ownership and risk awareness. Risk ownership, while ultimately held by the senior levels of the organization, is also shared by people who have responsibilities and accountability to manage risk within their areas of control. Risk awareness is an educational program that should be implemented to provide the right level of risk-related training to both employees and managers. Risk awareness training can actually help reduce risk throughout the organization. A risk awareness also means keeping the members of an organization informed on the current risk environment.

Finally, we concluded this chapter with a discussion of legal, regulatory, and contractual requirements levied on organizations that make risk management programs and activities mandatory. We discussed a few examples of common laws, such as HIPAA, GLBA, and FISMA, as well as the PCI-DSS; they require organizations to implement and maintain formalized risk management activities.