The following discussions were a part of the Task Force deliberations and judged worthy of inclusion in the Task Force Report for reference only.
Information assurance is a term which can be used to describe the needed
IW-D capabilities (and associated protection) of an information infrastructure.
Some basic definitions are needed to understand the principles:
-Peacetime (natural disasters, sabotage, equipment and service failures, unintentional acts)-Crisis/mobilization (terrorism, low intensity conflict, conventional war)
-Simultaneous two-theater engagements
-Limited nuclear war (nuclear terrorism, uncoordinated/accidental, theater nuclear) Expanded nuclear (coordinated attack)
-Post-attack (recovery and reconstitution).
In the traditional systems engineering context, availability is a function of the reliability and maintainability of the system while integrity of data is a function of the quality (or grade of service) of the system transporting the data. In addition, these measures of system performance are traditionally based on design assumptions that disruptions are random in nature (e.g., component failures, human errors, and acts of nature).
Information assurance is not just a function of the reliability, maintainability,
and quality of the network or infrastructure. Information assurance addresses
the capability of an infrastructure to endure a variety of disruptions ranging
from natural disasters to accidents to intentional disruptions by the enemies
or by insiders. For example:
This perspective on disruptions poses challenges for the intelligence, operations, and training communities in defining the threat, which is essential for a reasonable articulation of information assurance principles.
There are substantial differences between designing a typical information system and designing a resilient information infrastructure capable of enduring in the face of intentional disruptions. A typical information system design assumes that all of the system components will normally operate properly, with the common failure mode being failure of individual components. A resilient information infrastructure design must be based on the assumption that only some of the components will operate properly at any point in time. A typical information system design will incorporate central control mechanisms, synchronized clocks, and other techniques to use resources efficiently. A resilient information infrastructure design must be based on some decentralization of control and independent operation of portions of the infrastructure. Information system design is typically based on efficiency while a resilient information infrastructure design must be based on effectiveness. For example, the entire field of fault tolerant computing is based on the introduction of redundancy into otherwise efficient systems in order to make them more effective, particularly against random disruptions. Similarly, the design of a resilient infrastructure will assure diversity of hardware and software so that a common failure mode will not result in an infrastructure failure.
In the context of information assurance, network operation, management, and maintenance should be viewed from a war fighting perspective. Personnel performing these functions (and users in some cases), should be able to detect, differentiate among, warn of, respond to, and recover from disruptions. Recovery from disruptions resulting from failures or attacks might involve repair, reconstitution, or the employment of reserve assets. In some cases, network managers may have to isolate portions of the network to preclude the spread of disruption. Given the speed with which disruptions can propagate through networks, these capabilities may need to be available in automated form within the network itself. Finally, there must be some means to manage and control these capabilities.
The underlying philosophy in information assurance and in satisfying the IW-D need must be that of risk management and not of risk avoidance. There are not enough resources to armor plate the infrastructure. Risk management suggests that the threat be defined, that measures be undertaken to reduce the realization of the threat, that countermeasures to threat occurrence be based on realistic application of resources and that response to and recovery from threat occurrences be part of the infrastructure. Finally, it will be necessary to assume some degree of risk while maintaining some minimum infrastructure operating capability.
Based on a review of existing documentation, a list of information assurance principles has been developed and is presented below. Because the infrastructure and the concept of information assurance are still under development, the list is not exhaustive.
The following operational information is required from CJCS and the
Commanders-in-Chief (CINCs) of the Unified and Specified (U&S) Commands
to quantify some of the principles:
Information Assurance Principles:
-Prevented when possible within cost constraints-Limited in the extent of their effect when prevention is not feasible
-Responded to prior to actual disruption when detected in time
-Traced to their source whenever possible within cost constraints.
-If they are disrupted, they do not react so as to disrupt neighboring components-Disrupted neighboring components do not disrupt the new component regardless of the neighboring component's behavior
-Disrupted components are quarantined until they return to normal operating behavior
-Network and system management services are notified of disruptions and quarantines.
The goal in postulating these information assurance principles is to eventually
outline a set of specifications (on the order of A-Level specifications)
that will shape the design and integration of the infrastructure or that
can be used as a part of the specifications for the acquisition of services
from the local and long-distance carriers and from information processing
vendors. In order to bridge the gap between the information assurance principles
and a set of specifications, it will be necessary to develop strategies for
providing the attributes. Some elements that might be considered in developing
those strategies include:
Successful implementation of information assurance will require a multi-disciplinary team capable of formulating a comprehensive set of requirements, knowledgeable of current and emerging technologies, capable of overseeing the design of the infrastructure from an information assurance perspective, and capable of managing the implementation of information assurance in the infrastructure.
The goal is to maximally improve DoD's information assurance as quickly as possible but "do it on the cheap" without involving unnecessarily complex technology, and without awaiting the outcome of R&D efforts now underway or that could be imagined.
It can be played two ways:
1. Assume that a given pot of money is available, take as a goal maximizing the protection of DoD information assets and internal systems soonest (i.e., little or no R&D), and decide how and on what to spend it.
2. As above in item [1] except first compile a reasonable list of actions to be taken, and then estimate the cost to do them.
Below are some options from which to select, but not a comprehensive or complete list by any means. The sequence in the list is happenstance.
1. Provide users of the most sensitive systems commercially available tokens of some sort to improve the user identification/ authentication act of logging on; e.g., SecurID cards.
2. The same as item [1] except do it for all users in an operational entity; e.g., the command-control chain, tactical logistics, forward air bases.
3. Increase the level of effort in the USAF program (briefed to us) by a factor of 3 to get it done sooner. Alternately, pick a different factor of speedup.
4. Examine the other military services to ascertain whether corresponding programs would be effective for them, or whether variations on the USAF approach would be more sensible.
5. Implement [4] with a projected time-to-complete of X years.
6. Industrial organizations who have had serious intrusions into their systems and who appreciate the importance of protecting against them have mounted massive internal programs to make every employee aware of the issue, of individual responsibility, and of the actions being taken by the organization. Notable among such examples is Citibank.
Mount an intensive all-hands awareness program of information assurance in some/all/each of the military services. Alternately, confine the program to those organizational entities that are "closest" to the information assets and in best position to take appropriate steps if informed.
7. Survey all installed info-systems in the military structure that are based on COTS software and/or hardware. Compile a corresponding list of the known security flaws and fixes for each of them, and institute an aggressive effort to make sure that all such fixes are properly installed, tested, and made operational in (say) 18 months, and that the relevant operational staffs are also well informed and trained.
8. Make the recently published NIST Handbook of computer security required reading for all personnel associated with the operations, maintenance, installation, design, procurement and upgrade of both hardware and software in key [or: all] information systems [Alternate: do this initially for all information systems based on COTS; but later, add the embedded systems as well].
Make this handbook also required reading for every training or educational course given to military personnel.
9. Survey all acquisitions of information systems and computer-containing weapon systems now underway and take such steps as necessary to guarantee that up-front design consideration has been given to information assurance, netsec, infosec and opsec.
10. Compile an inventory of all weapon systems that contain embedded computers and for each, define and characterize the line of responsibility, organization(s) and physical locations which support the deployed system. Hence, identify vulnerabilities and weak spots that might be exploited by an opponent; create plans to remedy these risks on a quick response basis.
11. Survey all deployed weapon systems that are computer-based with especial attention to all phases of maintenance and upgrades of software and hardware and to daily operations. The object is to identify places and means by which subversive actions could be taken to degrade or perturb weapon performance. The level of effort might be such that candidates for this examination will need to be ranked in order of importance and operational vulnerability.
12. As in item [11] but do for all support systems, whether CONUS or field deployed, that are not COTS-based but use specialized software and/or hardware.
13. As in [12] but for COTS-based systems.
14. Reconsider any/all of the prior suggestions from the point of view of likely geographic, cultural and infrastructure circumstances in which U.S. military forces might have to operate in the next (say) decade; e.g., SWA, Adriatic theater, mid-East, Korea. Object: to judge whether a different prioritization of effort would be suggested or warranted.
15. Begin an assessment of the civilian-infrastructure aspect of the issue; e.g., identify the military bases essential for an OCONUS deployment and do so for several different durations of engagement (e.g., weeks, months, years). Identify for each the present arrangements for provision of electrical power, of other energy sources, of communications -- especially telephone and PSN-based, and of off-base medical, personnel, or commissary requirements.
16. As in [14], but for long-term overseas bases; e.g., Europe, Japan/Korea/Okinawa.
17. Any/all of the above for the intelligence systems (sensors, ground stations, antenna farms. electronic establishments) rather than for the operational forces and the support structure.