What are the 3 major levels of information systems?

III.B. The Operational Control Level

At this level, information systems ensure that the operations are performing within the guidelines and parameters that have been established for them. These parameters might reflect elements that are primarily technical, such as error rates or conformance to dimensional tolerances, or they might reflect managerial issues such as those related to controlling warranty costs or the organization's response times for responding to customer inquiries.

Often, computerized operational control systems operate on an “exception reporting” basis, i.e., they are programmed to highlight parameters whose values lie outside some prescribed range. For example, such systems might indicate when parts are being produced that do not fit within dimensional tolerances or when the level of accounts receivable has grown to some level that it should be of concern to management.

At this operational control level, routine evaluations of operational activities are also performed, for instance, reports are prepared daily, weekly, or monthly on the conformance of various activities to their budgets and on the quality levels being achieved. These evaluations usually involve comparisons over time, such as month-to-month, or comparisons with comparable indices from past years. They may also involve the use of standards that are developed from external sources such as the use of “benchmarking” data from other companies that are known to be high performers in some business process or area of operations and/or the use of standards developed from statistical data supplied by trade associations or information vendors.

Managing the Information Security Program

The organizational information security program provides overarching operational guidance for information system-level security management. This guidance includes policies, procedures, and standards that system owners and common control providers should follow and the definition and implementation of organization-wide management, operational, and technical controls. Many of the activities performed at the organizational information security program-level stem from FISMA requirements specifying responsibilities for each federal agency. These include [13]:

Performing periodic risk assessments of information security risk associated with agency information and information systems.

Creating risk-based policies and procedures to cost-effectively reduce information security risk to an acceptable level, address information security throughout the life cycle of each information system, and ensure compliance with FISMA requirements.

Developing organization-level plans and defining standards or templates for subordinate plans for providing adequate information security for networks, facilities, and information systems.

Providing security awareness training for personnel and contractors managing or using agency information systems.

Conducting periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices.

Developing a process for planning, implementing, evaluating, and documenting remedial action to address deficiencies in agency information security policies, procedures, and practices.

Developing and implementing procedures for detecting, reporting, and responding to security incidents.

Developing and implementing plans and procedures to ensure continuity of operations for information systems.

Warning

System authorization efforts undertaken without close coordination with information security program tend be less cost-effective, requiring more resources or taking longer to execute, and may result in a higher proportion of system-specific controls than the system owner can justify. This is especially true if the system owner and the authorizing official have differing perspectives on the extent to which the information system should follow policies and procedures or leverage other guidance provided by the organizational information security program.

The NIST FISMA Implementation Project issued guidance to federal agencies on each of these requirements (Table 1.1 maps FISMA requirements to corresponding NIST Special Publications) and in 2009 revised Special Publication 800-53 by adding a program management control family with a set of security controls applicable for all information systems and security control baselines but implemented and assessed at the information security program level. These controls, listed in Table 5.1, correspond to key FISMA provisions as well as agency responsibilities and requirements for information resources management detailed in OMB Circular A-130 and other applicable government-wide guidance.

Table 5.1. Program Management Controls Required in Federal Agencies [14]

Among the changes to Special Publication 800-53 NIST proposed for Revision 4 is the addition of four more program management controls addressing information security program responsibilities, including implementing an insider threat program, information security workforce development program, operational security program, and a process for overseeing information system level testing, training, and monitoring to ensure consistency and validate adherence to organizational risk management strategy and priorities [15].

Develop Contingency Planning Policy

Contingency planning policy is typically developed at the agency level, rather than the individual information system level, often as a component of organizational policies for continuity of operations. System owners should consider the functional, technical, and security needs of their own systems in the context of agency contingency planning policy, to determine whether any system-specific policy statements are required to extend or differ from agency policy. Contingency planning policy defines the agency’s contingency objectives, identifies contingency and continuity planning drivers applicable to the agency, and establishes expectations and responsibilities for system owners and others with roles in the contingency planning process. Contingency planning policies should specify agency requirements and standards for systems categorized at different FIPS 199 impact levels, and identify obligations for systems that support mission essential and primary mission essential functions. Special Publication 800-34 specifies the following elements contingency planning policies should address: [35]

Roles and responsibilities.

Scope as applies to common platform types and organization functions subject to contingency planning.

Resource requirements.

Training requirements.

Exercise and testing schedules.

Plan maintenance schedule.

Minimum frequency of backups and storage of backup media.

As the key system-specific artifact produced in the contingency planning process, the information system contingency plan should reflect organizational policies for contingency planning and for related functions, including information and physical security, system operations and maintenance, and emergency preparedness and response. Agencies do not develop contingency planning policies or contingency plans in isolation, but instead should recognize the interdependencies between contingency planning and subordinate processes like disaster recovery planning, as well as with information system security planning and continuity of operations planning.

Risk Management Process

Before the allocation46 of the security controls, the organization needs to understand the risks by conducting a risk assessment. Both NIST (800-37 Revision 1—RMF Step 2) and the ISO/IEC (27001—Clause 4.2.1.d–g) address the selection of security controls before and after the risk assessment. In addition, NIST and the ISO/IEC have a separate function within the risk management process (discussed in see chapter: Risk management) where the risks are evaluated based on criteria established during the framing (or context definition) step. This criterion assists in determining which of the risk response (or risk treatment) options in Table 7.3 would be appropriate as a treatment for the risk.

Table 7.3. Comparison of Options for Risk Response or Treatment

One notable difference between the NIST and ISO/IEC processes is the explicit requirements for the acceptance of risk defined in the risk treatment plan and the residual risk acceptance. For example, NIST does specify the acceptance of risk; it is performed as a result of the approval of the system security plan (800-37 Revision 1—RMF Step 3) and authorization to operate (800-37 Revision 1—RMF Step 5). However, both the NIST and ISO/IEC risk management processes include the ongoing monitoring where risk management becomes a continual process.47

Define ISCM Strategy

ISCM strategy development occurs at all levels of the organization, as each tier typically has its own monitoring objectives and needs some level of performance measurement and assessment of control effectiveness. Continuous monitoring strategy at the information system level addresses requirements specified for individual systems, while mission and business and organizational strategy typical spans multiple systems to provide visibility into overall security status. At all levels, ISCM strategy reflects organizational risk management objectives, particularly including risk tolerance, so that agencies can structure their monitoring programs and supporting activities to deliver the information necessary to manage risk to acceptable levels on an ongoing basis. As reflected in Special Publications 800-137 and 800-39 and other federal guidance risk tolerance drives continuous monitoring strategy, and determining organizational risk tolerance is an executive responsibility [27,28]. Organization-wide monitoring strategy may be developed at either organization or mission and business tiers; depending on the size and structure of the organization, there may be overlap rather than clear separation between tier 1 and tier 2 roles for various aspects of ISCM strategy definition. Information system-level ISCM strategy depends in part on organizational strategy, which defines monitoring objectives, reporting requirements, and policies and procedures related to monitoring activities. At the organizational level, ISCM strategy specifies or incorporates policies and procedures including [28]:

Definition and determination of security metrics.

Maintenance and update or revision of the monitoring strategy.

Assessment of security control effectiveness.

Security status monitoring and reporting.

Risk assessment and security impact analysis.

Configuration management.

Implementation and use of standard monitoring tools.

Establishment of monitoring frequencies.

Specification of measurement methods, including sampling where applicable.

Training personnel in ISCM roles.

ISCM strategy should follow applicable organizational policies and procedures and address any system-specific or security control-specific information gathering needs to enable ongoing determinations of security status and security control effectiveness. Where system monitoring uses consistent processes and tools and data obtained from monitoring is produced in a consistent format, system-level continuous monitoring information can be combined and compared to present an aggregate view of security. System-level ISCM strategy may extend organizational strategy where needed to support ongoing authorization or satisfy operational security requirements driven by the technical architecture of the system or the functions the system performs.

Warning

Development of information system-level continuous monitoring strategy should be an integral part of the system authorization process, leveraging the analysis that goes into security control selection and control assessment and enabling an efficient transition from strategy to execution when the system receives authorization. System certification and accreditation activities in many organizations emphasize the achievement of system authorization at the expense of planning for post-authorization activities. Similarly, system owners may perceive less need to develop system-level monitoring strategies when organization-level ISCM strategy, policy, and program management are in place. Organizations with well-defined continuous monitoring programs can reduce the risk of system owners devoting insufficient attention to planning for ongoing security operations by ensuring that authorizing officials, senior information security officers, and ISCM program managers engage in information-system level planning and strategy development, and by making system ISCM strategy documentation a prerequisite for successful system authorization.

Continuous monitoring of all security controls implemented for an information system is rarely feasible from the standpoint of technical capabilities or cost justification. The ISCM strategy defines expectations about how many and what types of controls will be monitored and standard or recommended monitoring methods. System-level strategies that call for selective monitoring typically involve a choice to monitor a subset of controls all the time, or all of the controls on a periodic basis, in accordance with organizational policies and procedures on monitoring frequency. Similar choices need to be made at the organization level, where agencies may choose to monitor a representative subset of their total inventory of systems or to monitor all systems but do so on a non-continuous basis. Agencies can leverage many of the control assessment methods and procedures in Special Publication 800-53A to help determine the most appropriate types of monitoring to implement. Several considerations influence whether using sample populations will provide sufficient information to support risk management decisions, including what metrics monitoring data supports, the level of information already known about the systems and controls subject to monitoring, variability (or consistency) among system-specific control implementations, and the cost and practicality of performing assessment tests or procedures [29].

Risk Assessment Hierarchy

Risk assessments can be conducted at all three tiers in the risk management hierarchy:

Tier 1 (organization level);

Tier 2 (mission/business process level); and

Tier 3 (information system level).

At Tiers 1 and 2, organizations use risk assessments to evaluate areas such as systemic information security-related risks associated with organizational governance and management activities, mission/business processes, enterprise architecture, or funding of information security programs. At Tier 3, organizations use risk assessments to more effectively support implementation of the information risk management life cycle processes and activities described in Chapter 5. Figure 6.5 illustrates the risk management hierarchy defined in NIST SP 800-39, which provides multiple risk perspectives from a strategic to tactical level. Traditional risk assessments have generally focused on Tier 3, which can result in overlooking other significant risk factors more appropriately assessed at Tiers 1 or 2. Risk assessments also support risk response decisions at different tiers of the risk management hierarchy.

NIST Special Publication 800-55 Revision 1—Performance Measurement Guide

The NIST in the United States has also made significant contributions to the production of guidelines and definitions on the use of security metrics. NIST Special Publication 800-55 Revision 1, Performance Measurement Guide for Information Security, describes the processes and methodologies that link information system level security performance to organizational agency performance through the organization’s strategic planning processes. By doing so, the processes and methodologies help demonstrate how information security contributes to accomplishing organizational strategic goals and objectives. NIST cites that the performance measures developed according to NIST SP 800-55 will enhance the ability of organizations to respond to government mandates and initiatives (i.e., Federal Information Systems Management Act or FISMA). The measurements standard focuses on three key measurement categories: implementation measures, effectiveness/efficiency measures, and impact measures. NIST SP 800-55 recommends when establishing a measurements program, the organization should follow the steps of:

mapping measures of the information security program performance to information security goals and objectives across the range of security controls;

mapping measures corresponding to security control families or individual security controls directly to the individual security control(s);

use the data describing the security control’s implementation and security program performance to generate required measures.

In the absence of any preexisting framework, a top-down or a bottom-up approach for determining which metrics might be desirable could be used. Meaningful and well-designed metrics and measurements for a business or organization are created and selected by carefully defining their scope and purpose. In this form, metrics can be used to address a wide range of information security management issues including measurement of progress in achieving goals and objectives, adherence to internal control procedures, justification of budgets and investment, and effectiveness of training and awareness program.

The selection of the metric should be able to answer what objective is being sought. Ouedraogo, et al. (2013) [1], assert that a good metric should always satisfy the criteria of meaningfulness, measurability, correctness, and usability. Meaningfulness requires that the metrics and measurements should be focused and their value should be easily recognizable and apparent to the intended audience. Correctness is the metric’s context, completeness, and objectivity to what is being measured. Measurability requires the metric to have the attainability or availability with sufficient accuracy to be measured. The criteria of usefulness entail the metric’s efficiency, scalability, and cost-effectiveness. Each metric should be questioned for its appropriateness using a standard set of questions.

Mission and Business Processes

Enterprise risk management considers risk associated with all operational aspects of an organization. At the mission and business process level, risk managers evaluate the risk to the organization that could result from implementing business processes; NIST designates processes designed and operated with such risk in mind as “risk-aware.” Organizations need to understand business process risk to ensure risk management practices are consistent with organizational risk management strategy and to be able to develop and execute processes sufficiently resilient to perform as intended in the face of potential threats. Risk determination at the information system level may be extended or aggregated to the business process level when processes rely on specific information systems. Federal standards and guidance—including the security categorization approach in FIPS 199—address information and information systems, but not the processes supported by information systems. The specification of risk-aware business processes logically extends the sort of analysis performed for information systems, potentially even leveraging the high-water mark categorization approach used to relate information to information systems. Risk awareness at this level requires senior leadership and business process owners to identify and understand the kinds of threats that can adversely affect their ability to perform mission and business functions, the nature and severity of adverse impacts that could occur due to information security risk, and the expected resilience to such impacts feasible for a given process definition [30]. Risk-aware business processes and resilience requirements also help determine the set of viable risk responses for risk identified at the mission and business tier.

Planning

Federal government agencies are responsible for integrating information security management with strategic and operational planning processes [1], which in practice means incorporating security within IT strategic planning, enterprise architecture (EA), capital planning and investment control (CPIC), and budget preparation and execution. Statutory regulations on federal information policy and information technology management [2] and key guidance to agencies on the management of federal information resources all emphasize the coordination of information security and risk management with multiple other planning and operational management functions [3]. Integrated management of federal information resources applies at all tiers of the organization, but at the information system-level the point of integration is often the system development life cycle (SDLC), which reflects perspectives from multiple management disciplines, as illustrated in Figure 6.1. Current federal guidance to agencies on information security risk management emphasizes the close alignment between the SDLC and the Risk Management Framework, most clearly indicated in Special Publication 800-37 Revision 1, which identifies the relevant SDLC phases for each task in the RMF [4]. Information systems typically receive funding through one or more agency IT investments, so from a financial management perspective system owners also need to coordinate security planning with CPIC processes and requirements applicable to the investments that provide funding to their systems and security management activities [5].

Note

One of the challenges system owners face is adhering to the different life cycles and phases associated with different information resources management disciplines, both within their agencies and in government-wide guidance. Official guidance to agencies from OMB specifies a performance improvement life cycle for IT management with three phases—architect, invest, implement—that correspond to distinct EA, CPIC, and SLDC processes, respectively [7]. The RMF overlaps to some extent with all of these processes, and NIST offers explicit guidance on integrating security activities with commonly used CPIC and SDLC processes [5,8]. None of this guidance is prescriptive and agencies have the flexibility to define and follow their own methodologies. The most current NIST documentation on the RMF emphasizes integration with the SDLC, so system owners should validate the extent to which the phases referenced in Special Publication 800-37 align with the standard life cycle processes defined in their own organizations.

Planning for any information resources management effort, including information security, involves specifying the set of tasks that need to occur, the personnel and other resources required to complete each task, the schedule for completing each task, and the inputs, outputs, and dependencies for each task. Information resources management planning occurs at strategic, tactical, and operational levels and may address entire organizations, business units or operating divisions, investments, or systems. In government organizations, planning at the information system-level focuses on projects, a term OMB defines as “a temporary endeavor undertaken to accomplish a unique product or service with a defined start and end point and specific objectives that, when attained, signify completion” [9]. Agencies often emphasize planning in the initiation phase of the system development life cycle because the development of a project plan is typically a prerequisite to securing project funding through the budgeting process and proceeding to development or acquisition [9]. To plan effectively for information security risk management activities, system owners need to consider three overlapping perspectives:

Organization-level planning for information resources management in general and for information security program management in particular.

Investment- or project-level system planning with a scope incorporating all functions and activities included in the system development life cycle.

System security planning, either as a set of tasks and activities within a broader project planning effort or as a distinct project.

System owners are actively involved in both overall system planning and system security planning, but depending on the size and complexity of the system and the way the organization manages it, different personnel may be responsible for developing and executing plans for different activities. The degree of integration between planning for security tasks and system-level project plans also depends in part on the way the system owner and the organization choose to acquire or perform key security services such as security control assessment and continuous monitoring. Some organizations explicitly incorporate security functions in system development, implementation, and operations and maintenance projects—whether those projects are staffed by government personnel, contractors, or some combination—while others establish internal security capabilities or services used across multiple systems. No single approach is preferred in all circumstances, but system owners need to consider the relationship between security and other system-related activities in order to plan appropriately for the completion of necessary security tasks. The tasks in the Risk Management Framework apply to major applications and general support systems that may encompass multiple applications within their boundaries, meaning that RMF planning is relevant for both individual systems owners and common control providers.

What Are Security Requirements?

Requirements are the functional properties that an application or system must support in order to fulfill its intended objectives efficiently and effectively. Requirements can be broad and wide ranging, addressing everything from graphical user interfaces to engineering feeds and speeds.

Security requirements are a subset of the overall requirements, but a frequently overlooked subset. Security tends to sit mostly in the background like plumbing; therefore security requirements and the controls and safeguards that meet the requirements can be overlooked and even ignored. Finding a methodical way of managing security requirements provides a great benefit because of this behind the scenes status.

NIST 800-53r41 presents three tiers of security requirements and capabilities: organization, business process, and information systems. (Previous versions of NIST 800-53 referred to the tiers as “business,” “operational,” and “technical.” No doubt the NIST had logical reasons for renaming these tiers, probably reflecting changes in scope, evolution in thinking, and even a touch of militarization of the US federal risk management process (consider that merely a casual comment)—but the old titles where perhaps easier to understand, if even they were slightly less accurate under the new definitions.)

As NIST itself says in 800-53r4:

To integrate the risk management process throughout the organization and more effectively address mission/business concerns, a three-tiered approach is employed that addresses risk at the: (1) organization level; (2) mission/business process level; and (3) information system level. The risk management process is carried out across the three tiers with the overall objective of continuous improvement in the organization’s risk-related activities and effective inter- and intratier communication among all stakeholders having a shared interest in the mission/business success of the organization.2

Tier 1 provides a prioritization of organizational missions/business functions which in turn drives investment strategies and funding decisions—promoting cost-effective, efficient information technology solutions consistent with the strategic goals and objectives of the organization and measures of performance. Tier 2 includes: (1) defining the mission/business processes needed to support the organizational missions/business functions; (2) determining the security categories of the information systems needed to execute the mission/business processes; (3) incorporating information security requirements into the mission/business processes; and (4) establishing an enterprise architecture (including an embedded information security architecture) to facilitate the allocation of security controls to organizational information systems and the environments in which those systems operate.

Determining what parts of the organization’s information technology infrastructure demand the implemented of higher assurance security functionality is a Tier 1/Tier 2 risk management activity (see Fig. 3.1 in this chapter). This type of activity occurs when organizations determine the security requirements necessary to protect organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation. … After the security requirements and security capabilities are determined at Tiers 1 and 2 (including the necessary assurance requirements to provide measures of confidence in the desired capabilities), those requirements/capabilities are reflected in the design of the enterprise architecture, the associated mission/business processes, and the organizational information systems that are needed to support those processes3 (NIST 800-53r4, Chapter 2, p. 25).