䡲 Allocating information assurance functions to a physical and logical architecture
䡲 Designing the Information Assurance Center (IAC) to implement the information assurance architecture
䡲 Balancing information assurance risk management and other IATF sys- tems engineering considerations within the overall context of cost, schedule, and operational suitability and effectiveness
䡲 Participating in trade-off studies with other information assurance and system engineering disciplines
䡲 Integrating IA concerns with standard systems engineering and acqui- sition processes
䡲 Testing the various systems to verify information assurance design and validate information protection requirements
䡲 Supporting the customers after deployment and tailoring the overall process to their needs
Activities performed by the IATF should begin alongside the system engi- neering activities to ensure that information assurance is built into the overall IT system. Considering information assurance objectives, requirements, func- tions, architecture, design, testing, and implementation simultaneously with the corresponding system engineering analogues allows information assurance to be optimized based on the technical and nontechnical considerations of the particular system.
Requirements Analysis
Discovering Information Assurance Needs
The IATF will begin with a review of the user’s mission needs, relevant policies, regulations, standards, and threats with respect to information in the user environment that was defined by the system engineers. The IATF then identifies the users of the information systems and information, the nature of their interaction with the information systems and information, and their roles, responsibilities, and authorities in each stage of the information assurance system life-cycle. The information assurance needs should come from the user’s perspective and not overly constrain the design or implementation of the IAC.
In an Information Assurance Policy and Procedures Manual or the Security Concept of Operations (CONOPS), the IATF should describe, in the user’s language, how information assurance supports successfully achieving the mission or desired market capability in the overall IAC environment. When the information assurance needs of the IAC are discovered and described during this activity, the information assurance processes surrounding the IAC will develop as an integral part of the overall system development process.
110 Building A Global Information Assurance Program
Mission Information Assurance Needs
The role of information and information systems in the larger mission and functions of the IAC must be considered. The IATF must consider the impact to the mission of organizational elements — people and systems — losing the use of the IAC, the information systems or information that they depend on; specifically, the loss of confidentiality, integrity, availability, nonrepudia- tion, or any combination thereof. At this point, the IATF has begun to elicit information assurance needs from the user.
Users know best the importance of their information, but usually need help in discovering their protection needs and priorities. Discovering the customer needs leads to the information assurance needs in terms of what information could be used to harm the mission if it were disclosed, modified, or lost. The IATF should be able to:
䡲 Assist customers in modeling their information management process 䡲 Assist customers in defining information threats
䡲 Assist customers in prioritizing protection needs 䡲 Prepare information assurance policies
䡲 Achieve customer agreement
Identifying needs is a customer interface activity performed by the IATF to ensure that the mission/business needs include information assurance needs and that the system functionality includes the information assurance function- ality. The IATF brings together security disciplines, technology, and mecha- nisms, and applies them to satisfy the protection needs of the customer. The result is an IAC that includes the information assurance architecture and mechanisms that best meet the protection needs within the cost, performance, and schedule allowed by the customer.
The IATF must adhere to the customers’ priorities in designing protection for the IAC, for the information systems, and for the information that the systems perform functions on, based on an assessment of the information and systems’ value to the mission. The role of information and information systems in supporting the mission should be described in terms of:
䡲 What kind of information records are being viewed, updated, deleted, initiated, or processed (classified, financial, proprietary, personal, pri- vate, etc.)?
䡲 Who or what is authorized to view, update, delete, initiate, or process information records?
䡲 How do authorized users use the information to perform their duties?
䡲 What tools (paper, hardware, software, firmware, and procedures) are authorized users using to perform their duties?
䡲 How important is it to know with certainty that a particular individual sent or received a message or file?
Threats to Information Management
In terms of what the IATF must address, the technical system context must identify the functions and interfaces of the IAC’s information system that interacts with elements outside of the system boundaries. The context should address physical and logical boundaries and the general nature of the inputs and the outputs to the information system. Included in the context is a description of the bidirectional flow of the information carried on signals, energy, and material between the system and the environment or other systems.
Both intended and unintended interfaces with the environment and other systems must be considered. Part of describing unintended interfaces is describ- ing the threat environment to information and information systems. A threat is defined as the potential for circumstances in which some agent might take some action, which could cause some event, having a consequence that could result in a harmful impact. The threat context will be described in terms of:
䡲 Types of information
䡲 Legitimate users and uses of information 䡲 Threat agent considerations
䡲 Capability 䡲 Intent 䡲 Willingness 䡲 Motivation
䡲 Damage to mission
Information Assurance Policy Considerations
The IATF must consider all the existing information assurance policies, regu- lations, and standards that are binding on the organization and develop a system information assurance policy. The most important issues an information assurance policy must define are:
䡲 Why protection is needed and
䡲 What protection is needed, not how protection is achieved
Just as in the systems engineering process, the IATF must consider all the existing policies, regulations, and standards that are binding on the organiza- tion. For example, national, executive level, Department of Defense, and Navy policies may bind a U.S. Navy base. These all must be considered as inputs to the formulation of a local information assurance policy for a particular base.
112 Building A Global Information Assurance Program
Two examples of existing policies that prevail throughout the federal government information assurance field is the Office of Management and Budget Circular A-130 [OMB A-130, 1996] and Public Law 100–235 [PL 100–235].
Both delineate requirements to protect all U.S. government information systems to the level commensurate with the risk, to define roles and responsibilities of individuals authorized to have the information, and to develop and imple- ment appropriate security plans that address continual administrative support throughout the system life-cycle. The same wording could be used in industry.
The most important issues an organizational security policy must define are:
䡲 The resources and assets the organization has determined are critical or need protection
䡲 The roles and responsibilities of individuals that will need to interface with those assets (as part of their operational mission needs definition) 䡲 The appropriate way (authorizations) authorized individuals may use
those assets (security requirements)
A multidisciplined IATF team of systems engineers, information assurance system engineers, users’ representatives, accreditation authorities, and design specialists is needed to develop an effective organizational information assur- ance policy. The IATF needs to work together to ensure that the various inputs to the policy are correctly and completely articulated, and that the resultant policy is correctly stated and consistent.
Senior management must issue the organizational information assurance policy. It needs to be decisive and set a direction to enable lower-level decisions to be made. The policy must be available to, and easily understood by, the entire workforce, even if that workforce is global in nature. There must be a procedure to ensure the policy is enforced throughout the organi- zation, and the workforce must understand the organizational and personnel consequences if the policy is not enforced. Although the organizational infor- mation assurance policy must be updated as conditions warrant, a high-level policy should be relatively constant. For specific guidelines, see the following:
䡲 DoD Directive 5200.28, Security Requirements for Automated Informa- tion Systems (AIS) [DoD5200, 1988]
䡲 Director of Central Intelligence Directive 1/16, Security Policy on Intelli- gence Information in Automated Systems and Networks [DCID 1/16, 1988]
䡲 Internet Security Policy: A Technical Guide, and Introduction to the Internet and Internet Security, both located at http://csrc.nist.gov/
Define the Information Assurance System
In this phase of the information assurance system engineering life-cycle, the user’s description of information assurance needs and the information system environment are translated into objectives, requirements, and functions. This
Information Assurance Objectives
Information assurance objectives have the same properties as system objec- tives. Each will be unambiguous, measurable, verifiable, and traceable to an information assurance need. The rationale for each objective should explain:
䡲 The mission objectives supported by the information assurance objec- tive
䡲 The mission-related threat driving the information assurance objective 䡲 The consequences of not implementing the objective
䡲 Information assurance guidance or policy supporting the objective
System Context/Environment
The technical system context identifies the functions and interfaces of the system that interact with elements outside of the system boundaries. In the case of the information assurance system, the mission objectives, nature of the information, mission information processing system, threats, information assurance policies, and facilities strongly affect the system context. The context of the information assurance system should address physical and logical boundaries between it and the mission information processing system, other systems, and the environment. Included in the context is a description of the bidirectional flow of information inputs and the outputs, signals, and energy between the system and the environment or other systems.
Information Assurance Requirements
The IATF will need to perform a requirements analysis that includes review and update of prior analyses (mission, threat, objectives, and system context/
environment) conducted as part of the systems engineering process. As the information assurance requirements evolve from the user needs to more- refined system specifications, they must be sufficiently defined to permit system architecture concepts to be developed within the integrated concurrent systems engineering process. The IATF will examine, with other information assurance system stakeholders, the set of information assurance requirements for cor- rectness, completeness, coherence, interdependence, conflicts, and testability.
The information assurance functional, performance, interface, interoperability, and derived requirements, as well as design constraints, will go into the Operational Requirements Document (ORD) of the system.
114 Building A Global Information Assurance Program
Functional Analysis
Functional Analysis
The IATF will use many of the systems engineering tools to understand the functioning and allocation of functions to various information assurance com- ponents. The IATF must understand how the information assurance subsystem is part of and supports the overall system.
Design the Information Assurance System
In this activity, the IATF will need to build the system architecture and specify the design solution for the information assurance system. As the IATF proceeds through this activity, it will continue to:
䡲 Refine, validate, and examine technical rationale for requirements and threat assessments
䡲 Ensure that the set of lower-level requirements satisfy system-level requirements
䡲 Support system-level architecture, component, and interface definition 䡲 Support long lead-time and early procurement decisions
䡲 Define information assurance verification and validation procedures and strategies
䡲 Consider information assurance operations and life-cycle support issues 䡲 Continue tracking and refining information assurance relevant acquisi-
tion and engineering management plans and strategies
䡲 Continue system-specific information assurance risk reviews and assess- ments
䡲 Support the certification and accreditation processes 䡲 Participate in the systems engineering process
Functional Allocation
As the system functions are assigned to people, hardware, software, and firm- ware, information assurance functions are also assigned to these system elements.
As functions are allocated to components, the components become responsible for satisfying the corresponding functional and performance requirements as well as a subset of the overall system constraints in the problem space. Various information assurance system architectures will be examined, and the IATF will negotiate an agreement on the information assurance system architecture with system stakeholders that are both conceptually and physically feasible.
Preliminary Information Assurance Design
The entry conditions to this phase are, at a minimum, stable agreement on information assurance requirements and stable information assurance system
of the higher-level specifications occur before the Preliminary Design Review (PDR). IATF activities for this activity include:
䡲 Reviewing and refining Needs and System Definition activities’ work products, especially definition of the component-level and interface specifications
䡲 Surveying existing solutions for a match to component-level requirements 䡲 Examining rationales for proposed PDR-level (of abstraction) solutions 䡲 Verification that component specifications meet higher-level information
assurance requirements
䡲 Supporting the certification and accreditation processes
䡲 Supporting information assurance operations development and life- cycle management decisions
䡲 Participating in the system engineering process
䡲 The PDR results in an Allocated System Baseline Configuration.