When transferring data between platforms, the classification access and the identity and authorization of the requester, the accredited classification range of the destination system, and destination level within that system should be authenticated. It is important to document any risks that have been accepted when classifying the level upon which a platform may process. This allows platforms under different management control to be evaluated for risks and have them taken into consideration when making reconfiguration plans. The transfer process must ensure that if the information fails to reach its destination the information is protected at the level required and appropriate warnings are raised.

A process will need to be implemented for introducing new platforms to an existing network. Cooperative processes will need to describe how the access control, security features, and auditability must be ensured prior to operational use of the new platform and how access will be granted. In a cooperative system with diverse platforms, a risk analysis will need to be performed to ensure that the combination of network operating system(s), platform operating system(s), and security software features available on each platform meet the access control and security requirements for that platform’s assigned role in the network/system. In cooperative systems, the differences in security software present on or available for each platform must be reconciled to ensure the consistent deployment of the system of controls. The results of this risk analysis must be used when developing reconfiguration and/or recovery options.

A risk assessment of security requirements must be a product of each formal review (i.e., system specification review, preliminary design review, critical design review, etc.) during the software development life cycle. In systems where several processes may manipulate a data object, state data must be maintained about the data object so that incorrect sequencing may be prevented and processing completion can be determined.

Software targeted for use in cooperative systems must be designed using the principle of loose coupling and high cohesion. Loose coupling indicates weak software module-to-module dependency. High cohesion indicates that a module performs a discrete function. In concert, the properties of loose coupling and high cohesion indicate a software module designed for independent performance. Using this principle produces software modules that can execute alone and enable the production of software which may degrade gracefully. Software targeted for use in cooperative systems must be designed so that each component is network topology independent. This will enable components to more readily be installed or reconfigured onto any platform within the network.

Components of cooperative systems must be designed to allow the removal of components to perform maintenance, testing, etc. with minimal impact to operations. Before an element can be removed from the cooperative network, the component must conclude all pending transactions. The work being performed by that component will need to either be done on another platform or the system must continue in a degraded state. Cooperative systems need to be designed with an operational capability for placing the components in a quiescent state. This operation must:

•  Cause a component to notify all other components in the system that it is about to terminate.

•  Cause all other components in the system to respond by ceasing any transmissions to that component.

•  Cause the component to conclude all pending transactions.

•  Cause the component to post notification that it is now quiescent.

An operational capability must also exist that allows the component to reenter the network in diagnostic mode for checkout and to notify other components that the component/platform is back in the network but not ready for operational use. Additionally an operational capability will need to exist to allow the component to reenter the system as active from the diagnostic mode and to notify other components that the component is active and fully functional.

INTEROPERABLE RISK ACCOUNTABILITY CONCEPTS

In designing and developing high-integrity interoperable systems, management is faced with the issue that connectivity is still a point-to-point transmission irregardless of the transmission mechanism itself. Unfortunately in today’s infrastructure, the majority of attention is focused on adding layers of protection, rather than building controls into the application systems at either end of the transmission. Even with advances in firewall technology, authentication processes, and encryption, management must address the issues of intrusion and infiltration into, as well as exploitation of their information resources by an increasing number of external threat manifestations.

Management must address the following key issues about risk, mitigation of risk, residual risk acceptance, and exercising a standard of due care in protecting its information resources. Additionally, management must recognize that an integrated intrusion detection process and penetration testing are integral components of today’s system life cycle. Penetration testing offers the only suite of tests that reflect “real-world” scenarios; and must be integrated into the verification and validation of a system’s productional acceptance criteria throughout all life-cycle phases. Intrusion detection, on the other hand, must be instantiated into the overall operational control, similar to, or as a part of the access control and audit.

Risk Accountability Associated with Developing, Maintaining, and Protecting Information Resources

Information security is still largely an unknown entity to most people. Managers can and often do ignore advice offered by security professionals. In the past, when the integrity, availability, or confidentiality of information systems was breached and damages occurred, the majority of damages were internal and simply absorbed by the organization. Limited incident investigation was performed. With the advent of virus infections and the susceptibility of interoperable, intra/Internetworked systems, management must take a proactive approach to managing and protecting its information resources.

Any organization and/or individual is liable when they act in a way that they should not have, or fail to act the way they should, and this act or failure results in harm that could have been prevented. Therefore, it is exceedingly important for management to fully understand the limits of liability associated with managing and protecting corporate information resources and which method of security management to implement.