Which of the following is the biggest risk in using and user development to create a new information system?

Security risk management

“Security risk management provides a means of better understanding the nature of security threats and their interaction at an individual, organizational, or community level” (Standards Australia, 2006, p. 6). Generically, the risk management process can be applied in the security risk management context. Indeed, the risk management process advocated in ISO 31000 should be used as the foundation to risk management in the greater organization; however, security risk management has a number of unique processes that other forms of risk management do not consider.

The core of security risk management still remains identical to what has been discussed, with the addition of informing assessments, such as the threat assessment, criticality register, and vulnerability assessment. The relationship between risk management and these assessments provides what is considered security risk management (Figure 3.4).

In the process of establishing the context for security risk management, it must be stressed that for the success of the security program the process has to be in-line with the key objectives of the organization, considering the strategic and organizational context. In addition, the outcomes have to been presented from a business perspective, rather than solely as security mitigation strategies.

5.5.1 Overview

Information security risk management is the systematic application of management policies, procedures, and practices to the task of establishing the context, identifying, analyzing, evaluating, treating, monitoring, and communicating information security risks.

Information Security Management can be successfully implemented with an effective information security risk management process. There are a number of national and international standards that specify risk approaches, and the Forensic Laboratory is able to choose which it wishes to adopt, though ISO 27001 is the preferred standard and the Forensic Laboratory will want to be Certified to this standard. A list of some of these is given in Section 5.1.

An ISMS is a documented system that describes the information assets to be protected, the Forensic Laboratory’s approach to risk management, the control objectives and controls, and the degree of assurance required. The ISMS can be applied to a specific system, components of a system, or the Forensic Laboratory as a whole.

Risk Management

The Federal Information Security Management Act defines information security as “the protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction” in order to safeguard their confidentiality, integrity, and availability [1]. No organization can provide perfect information security that fully assures the protection of information and information systems, so there is always some chance of loss or harm due to the occurrence of adverse events. This chance is risk, typically characterized as a function of the severity or extent of the impact to an organization due to an adverse event and the likelihood of that event occurring [2]. Organizations identify, assess, and respond to risk using the discipline of risk management. Information security represents one way to reduce risk, and in the broader context of risk management, information security management is concerned with reducing information system-related risk to a level acceptable to the organization. Legislation addressing federal information resources management consistently directs government agencies to follow risk-based decision-making practices when investing in, operating, and securing their information systems, obligating agencies to establish risk management as part of their IT governance [3]. Effective information resources management requires understanding and awareness of types of risk from a variety of sources. Although initial NIST guidance on risk management published prior to FISMA’s enactment emphasized addressing risk at the individual information system level [4], the NIST Risk Management Framework and guidance on managing risk in Special Publication 800-39 now position information security risk as an integral component of enterprise risk management practiced at organization, mission and business, and information system tiers, as illustrated in Figure 13.1.

Despite the acknowledged importance of enterprise risk management, NIST explicitly limits the intended use of Special Publication 800-39 to “the management of information security-related risk derived from or associated with the operation and use of information systems or the environments in which those systems operate” [5]. System owners and agency risk managers should not use this narrow scope to treat information security risk in isolation from other types of risk. Depending on the circumstances faced by an organization, the sources of information security risk may impact other enterprise risk areas, potentially including mission, financial, performance, legal, political, and reputation forms of risk. For instance, a government agency victimized by a cyber attack may suffer monetary losses from allocating resources necessary to respond to the incident and may also experience reduced mission delivery capability that results in a loss of public confidence. Enterprise risk management practices need to incorporate information security risk to develop a complete picture of the risk environment for the organization. Similarly, organizational perspectives on enterprise risk—particularly including determinations of risk tolerance—may drive or constrain system-specific decisions about functionality, security control implementation, continuous monitoring, and initial and ongoing system authorization.

Information security risk management may look somewhat different from organization to organization, even among organizations like federal government agencies that often follow the same risk management guidance. The historical pattern of inconsistent risk management practices among and even within agencies led NIST to reframe much of its information security management guidance in the context of risk management as defined in Special Publication 800-39, a new document published in 2011 that offers an organizational perspective on managing risk associated with the operation and use of information systems [7]. Special Publication 800-39 defines and describes at a high level an overarching four-phase process for information security risk management, depicted in Figure 13.2, and directs those implementing the process to additional publications for more detailed guidance on risk assessment [8] and risk monitoring [9]. In its guidance, NIST reiterates the essential role of information technology to enable the successful achievement of mission outcomes and ascribes similar importance to recognizing and managing information security risk as a prerequisite to attaining organizational goals and objectives. NIST envisions agency risk management programs characterized by [10]:

Senior leaders that recognize the importance of managing information security risk and establish appropriate governance structures for managing such risk.

Effective execution of risk management processes across organization, mission and business, and information systems tiers.

An organizational climate where information security risk is considered within the context of mission and business process design, enterprise architecture definition, and system development life cycle processes.

Better understanding among individuals with responsibilities for information system implementation or operation of how information security risk associated with their systems translates into organization-wide risk that may ultimately affect mission success.

Managing information security risk at an organizational level represents a potential change in governance practices for federal agencies and demands an executive-level commitment both to assign risk management responsibilities to senior leaders and to hold those leaders accountable for their risk management decisions and for implementing organizational risk management programs. The organizational perspective also requires sufficient understanding on the part of senior management to recognize information security risks to the agency, establish organizational risk tolerance levels, and communicate information about risk and risk tolerance throughout the organization for use in decision making at all levels.

Two Key Elements: Assessment and Mitigation

The practice of security risk management (SRM) begins with a thorough and well-thought-out risk assessment. Why? Because we cannot begin to answer questions until we know what the questions are—or solve problems until we know what the problems are. A good assessment process naturally leads directly into a risk mitigation strategy. These two key elements will be discussed further in this chapter and are mentioned at various points throughout this book with respect to specific protection applications.

Note: The following material is extracted from “Primer on Security Risk Management” and is used with permission.

Whether in the public or private sector, and whether dealing with traditional or cyber security (or both), asset protection practice is increasingly based on the principle of risk management. The concept is a perfect fit for the field of asset protection, since our primary objective is to manage risks by balancing the cost of protection measures with their benefit.

Tier 1: Partial

•

Risk Management Process—Organizational security risk management practices are not formalized, and risk is managed in an ad hoc and sometimes reactive manner. Prioritization of security activities may not be directly informed by organizational risk objectives, the threat environment, or business/mission requirements.

Integrated Risk Management Program—There is limited awareness of security risk at the organizational level and an organization-wide approach to managing security risk has not been established. The organization implements security risk management on an irregular, case-by-case basis due to varied experience or information gained from outside sources. The organization may not have processes that enable security information to be shared within the organization.

External Participation—An organization may not have the processes in place to participate in coordination or collaboration with other entities.

Enterprise Risk Management and Enterprise Security Risk Management

A trend today in the risk management field is enterprise risk management (ERM). Leimberg et al. (2002: 6) define it as “a management process that identifies, defines, quantifies, compares, prioritizes, and treats all of the material risks facing an organization, whether or not it is insurable.” ERM takes risk management to the next level. It refers to a comprehensive risk management program that addresses a variety of business risks. Examples are risk of profit or loss; uncertainty regarding the organization’s goals as it faces its strengths, weaknesses, opportunities, and threats; and risk of accident, fire, crime, and disasters. When all of these risks are packaged into one program, planning is improved and overall risk can be reduced. Because risks frequently are uncorrelated (i.e., all of them causing loss in the same year), insurance costs are lower. For instance, a company is unlikely to face the following losses in the same year: fire, adverse movement in a foreign currency, and homicide in the workplace (Rejda, 2001: 64–66).

Leimberg et al. (2002: 6) describe the trend of two separate and distinct forms of risk management. Event risk management focuses on traditional risks (e.g., fire) that insurance covers. Financial risk management protects the financial assets of a business from risks that insurers generally avoid. Examples are foreign currency exchange risk, credit risk, and interest rate movements. Various capital risk transfer tools are available to protect financial assets. ERM seeks to combine event and financial risk for a comprehensive approach to business risks.

Mehta (2010) differs from Leimberg by arguing for a more holistic approach to risks by including intangible assets (e.g., brand and customer relationships) that are typically not protected by traditional risk management. He notes that ERM is not always about reducing risks; it can address over-managing risk or not taking enough risk and exploiting business opportunities. Mehta writes that although much has been written about ERM, not all organizations have embraced the concept and some prefer the term “risk management” because adding “enterprise” creates a distraction about its meaning while managing risk is the important goal.

Another term with the word “enterprise” attached is enterprise security risk management (ESRM). Straw (2010: 58) writes that ERM includes ESRM, and similar to ERM, ESRM is holistic in its approach. He espouses the importance of interdependencies. For example, the risks resulting from a labor dispute disrupting supply chains and how all the units of a company work together to address all risks.

ASIS International (2010a: 4) research showed that top security leaders from major organizations are “deeply involved with evaluating and mitigating nonsecurity risks in their organizations.” Top nonsecurity risks included the economy, competition, regulatory pressure, and failure of IT systems. Skill sets required to succeed at ESRM focused on business management, leadership, and communication skills.

As explained in Chapter 18, ESRM also includes human resources protection (HRP). This is a broad concept that protects all employees and those linked to them (e.g., family and customers). Depending on organizational requirements, HRP can include workplace violence prevention, executive protection, safety, health, use of technology and social media, and personal and family protection. HRP is vital because people are the most valued asset to an organization and, depending on the type of harm to them, the consequences can be devastating.

Should a security and loss prevention executive or a CSO in a company be part of a company enterprise risk management committee? Why or why not?

Context Establishment

The context establishment process receives as input all relevant information about the organization. Establishing the context for information security risk management determines the purpose of the process. It involves setting basic criteria to be used in the process, defining the scope and boundaries of the process, and establishing an appropriate organization operating the process. The output of the context establishment process is the specification of these parameters.

The purpose may be to support an information security management system (ISMS); to comply with legal requirements and provide evidence of due diligence; to prepare for a business continuity plan; to prepare for an incident reporting plan; or to describe the information security requirements for a product, service, or mechanism. Combinations of these purposes are also possible.

Basic criteria include risk evaluation, impact, and risk acceptance. When setting risk evaluation criteria, the organization should consider the strategic value of the business information process; the criticality of the information assets involved; legal and regulatory requirements and contractual obligations; operational and business importance of the attributes of information security; and stakeholders' expectations and perceptions, and negative consequences for goodwill and reputation. Impact criteria specify the degree of damage or costs to the organization caused by an information security event. Developing impact criteria involves considering the level of classification of the impacted information asset; breaches of information security; impaired operations; loss of business and financial value; disruption of plans and deadlines; damage to reputation; and breach of legal, regulatory, or contractual requirements. Risk acceptance criteria depend on the organization's policies, goals, and objectives, and the interest of its stakeholders. When developing risk acceptance criteria, the organization should consider business criteria, legal and regulatory aspects, operations, technology, finance, and social and humanitarian factors.

The scope of the process needs to be defined to ensure that all relevant assets are taken into account in the subsequent risk assessment. Any exclusion from the scope needs to be justified. In addition, the boundaries need to be identified to address risks that might arise through these boundaries. When defining the scope and boundaries, the organization needs to consider its strategic business objectives, strategies, and policies; its business processes; its functions and structure; applicable legal, regulatory, and contractual requirements; its information security policy; its overall approach to risk management; its information assets; its locations and their geographical characteristics; constraints that affect it; expectations of its stakeholders; its sociocultural environment; and its information exchange with its environment. This involves studying the organization (its main purpose, its business; its mission; its values; its structure; its organizational chart; and its strategy). It also involves identifying its constraints. These may be of a political, cultural, or strategic nature; they may be territorial, organizational, structural, functional, personnel, budgetary, technical, or environmental constraints; or they could be constraints arising from preexisting processes. Finally, it entails identifying legislation, regulations, and contracts.

Setting up and maintaining the organization for information security risk management fulfills part of the requirement to determine and provide the resources needed to establish, implement, operate, monitor, review, maintain, and improve an ISMS.13 The organization to be developed will bear responsibility for developing the information security risk management process suitable for the organization; for identifying and analyzing the stakeholders; for defining roles and responsibilities of all parties, both external and internal to the organization; for establishing the required relationships between the organization and stakeholders, interfaces to the organization's high-level risk management functions, as well as interfaces to other relevant projects or activities; for defining decision escalation paths; and for specifying records to be kept. Key roles in this organization are the senior management, the chief information officer, the system and information owners, the business and functional managers, the information systems security officers, the IT security practitioners, and the security awareness trainers (security/subject matter professionals). Additional roles that can be explicitly defined are those of the risk assessor and of the security risk manager.

Developing a Security Policy

Developing a security policy is the single most important step in security risk management. Security policy is the glue that binds the various efforts together. It provides the statement of goals and intent that the security infrastructure is designed to enforce. In many respects, it is better to have a policy and no firewall rather than firewall and no policy. With policy, you can know what it is you need to do, and take the necessary steps to ensure your goals are achieved. Without policy, any control you deploy will be hit or miss, and there is no guarantee you will achieve your purpose. Because the fundamental issues of security come from control of the details, your overall security is probably weakened.

All sites have some policy, of course. If nothing is written down, then the policy exists in the consensual cultural expectation. People probably have some expectations: That their PC will turn on in the morning, that they can access their e-mail without it being distributed to competitors, that the file they were working on yesterday will still be there and contain the same information when they closed the application. Sometimes policy can be inferred: For example, many sites adopt an “arbitrary network traffic can go out; only a specified set of traffic—mail to the mail server, Web clients to the public Web server can go in as a default information flow-control policy. Most people understand and accept the principle of least permission, and these are probably in the informal policy.

Documentation is important, however. People need guidance on how to handle the information, services, and equipment around them. Is it acceptable to load games on the office PC? Allowing uncontrolled applications runs the risk of a potential loss of system integrity. Many sites discourage such behavior, but then allow it on field worker laptops as an acceptable compromise when it comes to security, utility, and morale. Is it acceptable to receive personal e-mail on your corporate account? Allowing such things runs the risk of increased network utilization, and the transport of Trojans into the corporate network, but at the same time encourages increased literacy and raises morale. Policy needs to be written down so consensual policy can be made clear to all members of the community. Likewise, managers ideally need to make trade-offs to ensure due protection of corporate assets while optimizing worker efficiency.

Policy does not need to be overly complex. Indeed, it’s best to make policy short. A policy framework can establish the overall guidelines—to borrow a Judeo-Christian metaphor: The Ten Commandments of security might be better than the security Bible. Most people only need those Ten Commandments. Where necessary, there can be a security Bible, which provides more detailed guidance, and provides documentation on security control configuration or security architecture strategies, but policy, at its best, should be holistically integrated into the people, processes, and technology that provides secure business information flow.

Persistence of Risk Applied to the NIST Framework

The Persistence of Risk measurement is indicative of the quality and consistency of security risk management processes. In addition to trending, persistence reveals temporal information that can be used to measure the NIST Identify and/or Protect Functions and therefore be used to specify a NIST Tier rating.

For example, the proliferation of stale accounts and/or hosts with high CVSS ratings would argue that information security risk management processes were less than repeatable. Therefore, the Identify and/or Protect NIST Functions would be rated accordingly. Again, the specific criteria used to justify a NIST Tier rating such as the magnitude of the Persistence of Risk measurement must be determined for each organization.

Summary

This chapter describes and explains the importance of several organizational factors that influence the success of information security risk management at both organizational and individual information system levels. Specifically, it highlighted the essential role of senior leadership support, the organizational information security program, effective planning and resource allocation, and performance measurement and management in establishing and maintaining compliance with security laws, regulations, and policies; consistently executing the Risk Management Framework for agency information systems, and enabling the achievement of mission objectives and program outcomes. Collectively, these success factors greatly enhance the ability of an organization to manage information security risk and to demonstrate the value and otherwise justify investment in information security programs and associated activities.