17.  Functions will need to be identified and separated into isolated security domains. These isolated security domains will ensure the confidentiality, integrity, and availability of information for the overall system and for each node. Management may decide that a security control architecture (the composite of all controls within the design of the system addressing security-related requirements) will need to be established that defines isolatable security domains within the environment to ensure integrity within each domain, as well as between levels of sensitivity and domain boundaries.

18.  System reconfiguration plans will need to be developed. Additionally, procedures must be established for introducing new platforms to existing distributed systems. These procedures must describe how access controls, security features, and audit capabilities will be implemented before operational use, and how access will be granted gradually as controls are assured. In distributed systems with diverse platforms, a risk analysis will need to be performed to ensure that the combination of network operating system, platform operating system, and security software features on each platform meet security requirements for their roles in the system. The analysis is necessary to identify and develop reconfiguration and recovery options.

19.  Distributed system components must be capable of executing a controlled shutdown without impacting unrelated functions in other components. The mode (automated or manual) to perform a controlled shutdown should be based on predefined, documented criteria to ensure consistency and continuity of operations.

20.  System management will need to conduct impact assessment to discover, for each node and for the network as a whole, factors that may affect the system connectivity, including:

•  The type of information traveling from node to node.

•  The levels of sensitivity or classification of each node and of the network.

•  The node and network security countermeasures in place.

•  The overall distributed system security policy.

•  The method of information transfer between nodes and the controls implemented.

•  The audit trails being created by each node and the network.

THE SYSTEMS INTEGRITY ENGINEERING METHODOLOGY

From the previous discussions on understanding the control issues and concerns associated with fully distributed and/or dispersed interoperable systems, it is clearly evident that management must take a proactive approach to designing, developing, and securing its information resources. In order to address this dynamic environment in which the system development life cycle has been shortened from weeks and months to hours and days (e.g., LINUX development), management is faced with making real-time decisions with limited information and assurances.

The model used in the development of this methodology is a highly complex global, multicorporate, multiplatform, intra- and Internetworked environment that substantiates the need for a synergistic business approach for bridging the gaps between the four key area product development support functions: system design and development, configuration management, information security, and quality assurance. These systems encompass:

•  Some 3,600 personnel,

•  About 1,682 large mainframes, minis, and dispersed cooperative systems,

•  Five types of operating systems,

•  A variety of network and communication protocols, and

•  Varying geographical locations.

This approach forms an enterprise-wide discipline needed for assuring the integrity, reliability, and continuity of secure information products and services. Although the development and maintenance concepts for high-integrity systems are specifically addressed, the processes described are equally applicable to all systems, regardless of size or complexity.

Information Systems Integrity Program

Change is not easy whenever an enterprise considers reengineering its business processes. This kind of competitive business initiative typically involves redesigning and retooling value-added systems for new economies. Many of these are legacy systems which are being pulled along by new technology, making change very difficult to manage. The speed at which new emerging information technology is introduced to market has also made it difficult to maintain an information systems control architecture baseline. Continued budget constraints have become a recognized element in managing this change.

Exhibit 6.  Change Process

Systems Integrity Engineering Process

In today’s computing world, distributed processing technologies and resources change faster than most operational platforms can be baselined. As they evolve with an ever-increasing speed, organizations are challenged with an opportunity to maintain stability for growth and strategic competitiveness. Management must consider that sensitive business systems increasingly demand higher levels of integrity in system and data availability. Within this framework, reliability, through product assurance and security assurance constructs, provides a common enterprise objective. Accordingly, the scope of an enterprise-wide product assurance partnership and management-friendly metrics must be expanded to all four functional areas as a single, logical, integrated entity with fully matrixed management (i.e., both horizontal and vertical management control). The process in which requirements for new information technology are infused into the enterprise and managed becomes the pivotal business success factor that must be defined, disseminated, and understood by the key functional support organizations.

Exhibit 7.  Interdependencies of Change