An Exploration of Information Security Aspects
in the Thirty Elements of Systems Engineering

Julie JCH Ryan

Prepared for
EMGT 283 Spring 1998

4 May 1998

Introduction

The thirty elements of systems engineering describe the activities and processes that occur over the life cycle of a system. As described in current form, the thirty elements relegate aspects of information security (such as computer security and communications security) to specialty engineering fields – engineering expertise that is used on some but not all system efforts. This distinction may have been appropriate at some time, but is increasingly a dangerous invitation to disregard a crucial aspect of every systems engineering effort. By characterizing information security as a specialty field, program managers and systems engineers are implicitly given the latitude to decide whether or not information security is a necessary field for their specific effort.

For those who are not trained in the area of information security, a tendency is to consider it a matter appropriate only to projects like communications networks or human-safe computer systems. However, it is exceedingly rare today for any system to be developed that does not incorporate some aspect of information technology. Floodgates on dams are controlled remotely – through the auspices of information technology. Roadways are monitored – using information technology. Cars are augmented with many computer systems to enhance performance. Industrial processes are controlled and managed using highly sophisticated information technology. Often these control mechanisms utilize internet protocols over public networks. Interconnectivity between disparate elements is emphasized to increase efficiencies and reduce costs, with such interconnectivity made possible by information technology. In short, information technology is ubiquitous. So, too, are the concomitant challenges of assuring information content, access and infrastructure while maintaining confidentiality, integrity and availability. This is the challenge of information security.

With this inclusion of information technology into all aspects of products and systems, it is increasingly important that the system engineering process take information security into account at every step of the process rather than treating it as a specialty subset. The fact of the matter is that while information security does in fact require highly specialized knowledge, it can not succeed if treated as a unique or specialty area. It is not a feature to be added on as needed, but a characteristic of a system that entwines every aspect of a system. It is to a system as blood vessels are to a corporal being. If there is a weakness, it has the potential to affect every other part of the system. When information security is approached systemically, the end result is not only better and more robust security, but also a better understood system that is amenable to management controls.

The most fundamental approach to information security engineering is to examine the risk environment of the system and then to accommodate the acceptable risk within a structured approach of reducing vulnerabilities and employing countermeasures. This effort must be performed at both systemic and elemental levels in order to be effective: vulnerabilities may come to exist at a system level through some combination of features that individually are not problematic. Therefore, vulnerabilities must be addressed both in the specific engineering processes and at the integrated system level. This is made incredibly difficult, if not truly impossible, if the security aspects are not fully incorporated into the entire systems engineering endeavor.

This paper examines each of the thirty elements of systems engineering in order to point out what role or aspect of information security is appropriate for each element. This discussion is not meant to be an exhaustive proof or instruction manual; it is, however, meant to point out the importance of including information security aspects in every element of systems engineering.

1. Needs, Goals, Objectives

"The statement of needs, goals, objectives and requirements come from the customer and acquirer of the system to be developed." Needs are the bases for a project: a project exists to fulfill identified needs. "Goals and objectives are usually short declarative sentences, with goals being rather broad and objectives under each goals being rather broad and objectives under each goal as somewhat more specific." In this first step, "all that should be done under this element is to confirm that the statements of needs, goals and objectives are correct. Because these are provided by the system user or acquisition agent, the system developer should go back to these sources for the purpose of assuring that the needs, goals and objectives are still current and appropriately stated."

The critical issue here is the amount of information technology that has permeated every aspect of all systems. Many customers, particularly those who are in traditionally non-IT intensive industries, are not always aware of the extent to which the ultimate success of their endeavors are dependent on reliable and accurate information technology. There may be inherent or implied information security needs that are not explicitly acknowledged or specified. And yet, these information security needs can add both significant up front costs and specific engineering requirements. Without an explicit accounting of information security requirements, future problems are practically guaranteed. These problems can include having to retrofit information security features into the system at some future time when the requirements are recognized due to some mishap. The worst of all situations could be realized at some point in the future when a lawsuit alleging poor or substandard engineering is lodged due to the nonexistence of security features.

The question becomes, of course, whether incorporating information technology into any system without an assessment of ancillary effects is in fact good or competent engineering. Assessing by products of any technology is a fundamental part of engineering. New materials are not adopted without assessing impacts to not only structures but also cost, maintainability, reliability, training and other aspects of the system as a whole. Competent incorporation of information technology must thus be assumed to include security issue assessments in support of the risk management of the entire system.

These considerations must be broached with the author(s) of the needs, goals and objectives for the system. Confidentiality, while the most commonly considered information security need, is only one part of the security concerns. Integrity and availability issues must also be considered. When these three elements of security are considered, statements describing the system needs in terms of these elements can be prepared and used for more detailed engineering considerations.

2. Mission Engineering

"Mission engineering Ö involves the detailed articulation and analysis of the intended mission of the system that is being engineered. The main purposes of mission engineering are to verify that the system has legitimate missions to be executed that are not being carried out by other systems, and to provide a technical basis for the full definition of requirements for the system. Mission engineering also serves another critical function by providing a technical framework for defining the requirements for the system."

Building off the needs elicited in the first element, it is critical that the security aspects be incorporated into the mission engineering activities. A system's mission, ever more likely to be dependent upon internal and/or external information technologies and communication, must include a detailed articulation of the security requirements. Questions that can help frame this articulation and analysis are as follow:

Within the context of the system and its information environment, what are the issues, sensitivities and problem areas? Why do they exist? Identifying these in context of the overall analysis can be a powerful tool in guiding the development of requirements and technical performance measures.

How are confidentiality, integrity and availability addressed in the analysis? What are the issues associated with these attributes? How are actions associated with protect, detect and correct addressed? What, how much and how long must be part of the description.

What policies contribute to a robust operational environment? How do the different stakeholders feel about the subject area? What are the issues that are important to each of them? Example stakeholders include software writers, law enforcement, international standards bodies, diplomatic bodies, non-governmental organizations, computer systems manufacturers, system administrators, etc. Considering the point of view of each of these stakeholders can highlight potential problem areas.

All of these considerations should be brought together in an analysis of the risk environment. Considering potential threats (the agents of which are also stakeholders), vulnerabilities, possible countermeasures, and the impact of problems provides a robust understanding and contributes directly to specifying architectural alternatives, specific requirements, technical performance measures, and other important aspects of the system engineering process. Performing this analysis up front saves time, effort and resources in later stages of the engineering process.

3. Requirements Analysis/Allocation

"Requirements analysis and allocation is a set of activities that review an existing set of requirements, derive new requirements, and then allocate these requirements to the functional elements of the system."

Building upon the knowledge gained by the mission engineering efforts, specific requirements can be derived associated with information security. A good tool to use is a matrix of security considerations, which would then be filled in with specific requirements. The following matrix shows the types of questions that must be addressed in order to clearly delineate the information security requirements.

Security Needs Definition Matrix:

This matrix assists the system engineer in specifying precisely what security needs exist, and to what magnitude the requirements should be stated. These are straightforward questions, but comprehensive in scope.

4. Functional Analysis/Allocation

Functional analysis and allocation involves the following steps: "definition of the top-level functions of the system; decomposition of the preceding into lower-level functions and subfunctions; allocation of generic information and data flows among and between functions and subfunctions; [and] from the requirements analysis and allocation element, assuring that all requirements are allocated to the functions and subfunctions."

Taking the developed requirements and security understanding, the following matrix can be filled out to allocate the functions across the system. Note that the actions cover the lifespan of the system: they include things that can be built in as well as operational elements that must be part of the operational environment. These latter elements can include such things as positive identification of personnel in the environment or daily audit log analysis procedures.

Security Actions Definition Matrix:

This matrix assists the system engineer in specifying what actions must be taken within the holistic context of the system in order to assure the security requirements. It enables a functional distribution of requirements to elements of the system. By answering these questions, the system engineer is able to identify alternatives as well.

5. Architecture Design/Synthesis

"Developing a basic architecture is the centerpiece of the total systems engineering process. It Ö requires the formulation of alternative system architectures [and] the analysis of the postulated architectures to verify that they satisfy system requirements."

"Architectures can also involved fundamental technology considerations and choices. An example is the basic selection of a time-division-multiplexed system versus a frequency-division-multiplexed system. These are very basic choices that ‘drive’ the remainder of the system design."

Once the knowledge is attained through the activities of the previous steps, the development of architecture designs that incorporate information security needs is greatly facilitated. Without that understanding, it is doubtful that a comprehensive solution can be obtained. At this point, specific solutions can be considered.

These solutions should include a mixture of technical solutions and policy solutions. An example of a technical solution versus a policy solution can be illustrated in the area of cryptography. While cryptography allows data to be hidden from unintended recipients, it is also hidden from intended recipients who don't have the correct key(s) to decrypt the message. Keys have been known to be lost -- people simply forget what the key is. Keys have also been known to have gotten lost, when the sole repository of the key was lost. Say, for example, Fred is working on a highly sensitive piece of work for the company. Just before he leaves work for the day, he encrypts his work, stores it on a disk, locks the disk in a safe, clears his operating buffers and cache space using a special purpose utility program, and then goes home. That night, tragically, over dinner, Fred has a heart attack and dies. The only person who knew the key to decrypt the file is now unable to tell anyone (except a medium).

There are policy solutions that can alleviate the problems with lost keys. Fred could have, for example, stored his key in a sealed envelope in a separate safe. That would have allowed his work to be recoverable in case of accident or misfortune. Policy solutions, however, require active management and education of all personnel in an operational environment in order for them to be effective. If there had been a policy requiring Fred to maintain a recoverable copy of his key, it would have been necessary for Fred to abide by the policy. If he simply ignored it or forgot to follow it in the rush of going home at night, the result would have been the same: a lost key.

The concept of a technological solution for the key recovery problem gets around relying on humans to abide by policy. This technological solution is known as key recovery or key escrow. The purpose of key recovery or key escrow schemes is very straightforward: it is to allow the recovery of encrypted information without the key(s).

Clearly there are systemic advantages and disadvantages associated with both policy and technological solutions for requirements. These should be explored through architectural alternatives in order for a sound decision to be made.

6. Alternatives Analysis/Evaluation

"The essence of this element is to carry out a comprehensive analysis and evaluation of the alternatives that result in a preferred system architecture. Ö At the completion of this element, the systems engineering team has produced a preferred system architecture together with the analysis that supports the selection. In short, it is not enough to simply select a preferred architecture; it is also necessary to explain Ö a clear demonstration of its superiority in relation to other alternatives."

The evaluation and analysis of the architectures in the context of the desired end goal is not different from any other system, since the information security aspects have been thoroughly interjected with the rest of the system requirements. One additional thought the system engineer should keep in mind is the question of the value of information. Valuing information is not straightforward. The value relates not only to its specific uses but also to its loss of value should it be compromised. For example, the formula for a powerful medicine has great value in and of itself. Should this formula be stolen by a competitor, the value decreases somewhat. Thus, part of the alternatives analysis must include that concept of cost as part of the overall cost of the architectural alternative.

7. Technical Performance Measurement (TPM)

TPM "is the underlying basis for evaluation the performance of the architecture alternatives. It also serves as a key ingredient in selecting more detailed design parameters in the form of hardware, software and human components."

Technical performance measures related to information security flow directly from the analysis performed in support of Requirements Analysis/Allocation and Functional Analysis/Allocation. Having performed this analysis up front allows easy and very specific descriptions of technical performance measures that are both meaningful in the context of the mission of the system and measurable over time.

8. Life-Cycle Costing (LCC)

"Costs must be considered on a life-cycle basis. Thus, the three main categories of cost are: research, development, test, and evaluation (RDT&E); acquisition or procurement; [and] operations and maintenance (O&M)."

The costs associated with information security must, as previously stated, take into account not only the positive costs but also the negative costs. Such costs include not only the costs of implementing the security features and enforcing their activity, but also an accounting of costs should they fail. What is the value of information that is not available when needed? What is the value of information that can not be trusted? How much money would it take to recover from a corrupted database? These costs help to put the overall security costs in perspective and make the business case for the security aspects of the system. For example, the cost to a credit card company of not being able to trust their database of accounts and transactions can easily run into the multi-millions of dollars. The cost to a small flower shop of not having telephone communications is the cost of orders not received, which can easily run into the hundreds of dollars. These costs can make or break the success of an enterprise and so should not be overlooked in the system engineering process.

9. Risk Analysis

"In broad terms, risk may be explored in four key areas form the perspective at the CSE: (1) schedule risk, (2) cost risk, (3) cost risk, and (4) societal risk."

These risk areas are very appropriate. Additional descriptors of risk have already been mentioned and are expanded upon here. Within the information security profession, the elements of risk are commonly portrayed as a formula:

Risk = Threat x Vulnerability x Impact
Countermeasures

This formula is not meant to be taken as a mathematical equation for use in making quantitative determinations of risk level, although it can be made mathematically rigorous using probability theory. It is better taken as an algorithm for use in thinking about the factors that enter into risk management and in assessing the qualitative level of danger posed in a given situation.

Threats are posed by organizations or individuals who both intend harm and have the capability to accomplish their intentions. They may take the form of enemy armed forces, spies, criminals, terrorists, and psychotics, computer hackers, drug lords or saboteurs. Their organizations may be formal, as are foreign governments' armies or intelligence services, or informal, like the terrorist group that attacked the World Trade Center or hacker groups like the Legion of Doom or Chaos. Threats to information or to computer processing and communications systems may be from outsiders seeking access to information assets, but more often are insiders. In real-world security situations, threats do not occur one at a time, or even independently. Natural disasters are also threats, representing very real dangers to people, facilities, equipment and other assets, including information and information systems, and have to be considered by managers as part of the larger issue of disaster planning. Reliability and the steps necessary to allow for and deal with reliability failures are also risk management issues for managers.

Vulnerabilities are characteristics of the situations, systems, or facilities that can be exploited by a threat to do harm. A vulnerability for which there is no credible threat does not require a response by the security processes. Examples of vulnerabilities include structural weaknesses of buildings located in earthquake territory, weak and easily discoverable passwords on our computers and networks, easily penetrated facilities, unvetted personnel, or operations carried out in such a way that outsiders can detect their existence and analyze their objectives. Careful attention to the design of or facilities and systems can reduce or eliminate vulnerabilities: locks and barriers can be strengthened, fences raised, alarms and monitors installed, computers systems upgraded to incorporate security features, sprinkler systems installed and a wealth of other features, devices and procedures implemented to reduce vulnerabilities.

System engineers must consider the possible consequences of attacks from a variety of different threats, each of which may act on a specific vulnerability different from those attempted to be exploited by other independent threats and any of which may be unrecognized.

Countermeasures may abate the danger. All else being equal, more countermeasures mean less risk. Guards can be hired, personnel subjected to background investigations or polygraph examinations, badges may be used to identify authorized personnel, procedures implemented in our computer systems and networks to backup data bases and to enforce sound password practices, and so forth. Such countermeasures reduce the likelihood of a successful attack and so lessen risk.

The impact of a successful attack depends upon the value of the target. If the impact of a security failure is small, allocation of scarce resources to security systems and processes can also be small. Obviously, as the value of the target rises, the impact of a successful attack goes up as well, and so risk increases.

Considering risk in this manner provides the system engineer with the perspective with which to make reasoned choices between alternatives in order to provide the most effective solution for the specific environment and mission.

10. Concurrent Engineering

"The essential perspective of concurrent engineering is that all parties that have a role to play in a given system design should be involved with that system throughout its life cycle."

Information security should definitely be concurrently engineered with the rest of the system. As highlighted in each of the previous elements, the impact of information security considerations upon the system as a whole is both specific and wide-ranging. Yet the expertise with which the specific solutions associated with information security requirements are both identified and contrasted is rare. Thus it is important that information security professionals be part and parcel to the system engineering team during all phases of the project.

11. Specification Development

"This is done by developing a set of detailed specifications for the new subsystems, usually considered in three categories: hardware, software, and human."

Information security solutions must take into account all three referenced categories, as well as the interfaces between these categories. As referenced in the above discussion of technical versus policy alternative solutions, information security must be appropriately distributed between capabilities according to needs and requirements. However, it is the portfolio of solutions that are implemented that affords robust protection. Where one fails or is not quite complete, another can overlap. Having lots of different kinds of security measures provides protection in depth -- fall back protection in case one or another fails for one reason or another.

Having robust protection is critical to having detection capabilities. Often, detection capabilities rely on the protection technologies, the failure of which indicates the breaching of protection. For example, the lack of a badge is only noticeable if badges are required. A hole in a fence is only noticeable if there is a fence. A busted lock is only noticeable if there is a lock.

Thus, the interfaces and overlaps between hardware, software and human elements in a system are critical aspects of information security engineering and the specifications must acknowledge this criticality explicitly.

12. Hardware/Software/Human Engineering

"This element refers to the design and construction of subsystems as well as the components that make up these subsystems. As with the architecting process, design choices involve the postulation of alternatives and the selection of the best alternative to satisfy the stated or derived requirements."

It is at this point that information security becomes most technical and arcane. It is highly recommended that the chief system engineer have an advisor who understands the intricacies of information security at this phase as vulnerabilities can be induced by incorrect engineering or poor management processes. For example, the choice of one design alternative in one subsystem may, in conjunction with another design choice in another subsystem, induce a vulnerability into the system as a whole. It is for these reasons that an information security professional is recommended to be part of the chief system engineer's staff overlooking the entire development process.

13. Interface Control

"Experience shows that many of the difficulties in building large systems show themselves in the interfaces between the subsystems and between the system and external systems with which it must operate."

As noted in the previous element, vulnerabilities can be introduced into a system through inattention to interface details and design choices. Again, it is highly recommended that an information security professional be involved in the overall system engineering oversight of the project in order to eliminate this possibility.

14. Computer Tool Evaluation and Utilization

"Under this element of system engineering, the team evaluates and then uses the set of computer aids appropriate to the system being developed."

In addition to other computer tools, a set of information security tools should be considered in the systems engineering process. These tools include automated vulnerability analysis tools, such as SATAN, virus scanners, and access mediators, such as firewalls.

15. Technical Data Management

"A complex systems engineering effort generates a large amount of technical information. [This data must be] organized and managed."

This is particularly true in the context of information security. Knowing specifically the exact state of the system as a whole is a critical element of security implementation and monitoring -- technical data is a vital component of that effort.

16. Integrated Logistics Support (ILS)

"Integrated logistics support (ILS) is defined as ‘a disciplined, unified and iterative approach to the management and technical activities necessary to (a) integrate support considerations into system and equipment design, (b) develop support requirements that are related consistently to readiness objectives, to design, and to each other; (c) acquire the required support; and (d) provide the required support during the operational phase at minimum cost.’"

As noted in many of the above elements, information security solutions and management cover the life cycle of the system. Thus it is an integral part of the logistics plan for the system. Additionally, regular and periodic upgrades to programs such as virus scanners must be part of the logistics plan.

17. Reliability, Maintainability, Availability (RMA)

"The RMA element focuses specifically on matters of the operating life and ease of maintenance of a system. Ö Reliability is the probability that a system successfully operates to time ‘t.’ Availability is the probability that a system is available to operate when called onto do so for a particular mission or application. Maintainability Ö is interpreted as the degree to which a system has been constructed so as to facilitate maintenance at a reasonable cost."

The RMA of a system and the information security concerns addressed in all the above elements are synergistic. An additional consideration that the system engineer should keep in mind is the process of maintenance. Maintenance to any aspect of the system should be carefully considered in terms of how it is performed. If changes are allowed to be made by one person, that becomes a vulnerability. Two or three person control over changes, with separation of duties, can reduce the risk associated with that vulnerability.

18. Integration

"Integration refers to the set of activities that bring together smaller units of a system into larger units."

Along those lines, allowing one person to integrate units into a greater unit can introduce vulnerabilities. This should be considered carefully before being allowed. Again, two or three person control can reduce this risk element.

19. Test and Evaluation

"Test and evaluation (T&E) normally refers to physical confirmation of the performance of an overall system. It is carried out in at least two key contexts: (1) completion of full-scale development of a system, and (2) placing the system in an operational environment."

Independent and highly skilled testers should be employed to examine the security features of a system both at completion of the development and within the operational environment. A powerful tool used by attackers is that of "social engineering." Social engineering is the process of gaining information and/or access through trickery -- by pretending to be someone else, by masquerading as a technician, by getting a job with a janitorial services firm, or through myriad other ways. The testing in the operational environment should include social engineering tests to gauge the effectiveness of the protective and detective measures.

20. Quality Assurance and Management

"Quality assurance and management (QA&M) Ö addresses all matters related to product and service quality."

Quality and security are additionally synergistic. Security measures require high degrees of quality, both in management and in process. The system engineer should be alert to the potential for piggybacking off security processes in quality management efforts.

21. Configuration Management

"Configuration management is largely a bookkeeping and control element that involves the following subelements: identification, control, auditing, status accounting, and traceability. Ö A key concept in system development that relates to [configuration management]] is that of system ‘baselining.’"

Configuration management is crucial to security management. Undocumented changes to a system are highly risky, and the overall security state of a system can not be ascertained with out an understanding of baseline. Periodic audits should be performed in order to ascertain the compliance of the system with its advertised state of being. These audits should be comprehensive and performed by independent teams.

22. Specialty Engineering

"Specialty engineering refers to a set of engineering topics that have to be explore on some, but not all, systems engineering efforts. Ö Examples of specialty engineering areas include electromagnetic compatibility and interference, safety, physical security, computer security, communications security, demand forecasting, object-oriented design, [and] value engineering."

All specialty engineering endeavors related to a system development effort should be coordinated with the information security professionals for conflict and for overlap. For example, the selection of a specific frequency may make a system vulnerable to eavesdropping while the selection of a difference frequency could reduce that vulnerability. Cooperative efforts amongst the disciplines can highlight these problem areas.

23. Preplanned Product Improvement (P3I)

Preplanned product improvement considers the ways and means to enhance the system beyond the scope of the current contractual arrangement. Such improvements generally enhance performance, and more than satisfy the requirements, as currently stated."

Because the state of the threat is constantly evolving, the information security posture must also constantly evolve. This should be recognized in the beginning and planned for continual improvements. Building off of data collected through the other elements can assist in this function.

24. Training

"Training Ö refers to the training of system operators and maintainers."

Training is critical to information security. When push comes to shove, it is the people who operate and maintain the system whom either keep the information security aspects at full functionality or subvert them, either by accident or on purpose. An example of the type of training that is required is that regarding policy issues, such as the wearing of badges, and adequate password creation and periodic replacement. Training is a very cost-effective tool in the information security arsenal and should not be neglected.

25. Documentation

"This element Ö deals with the effective and efficient production of all required system documentation."

Concomitant with the technical data management, configuration management, specifications, and quality assurance elements, it is both critical that adequate documentation of the system security features exist and also that they be protected. The documentation itself may give hostile individuals information on how to get around security features. It should, therefore, be protected as sensitive information.

26. Production

"Production refers to the phase of a project during which one or more installable systems are being produced for the customer."

Production of the system should follow the same processes as maintenance -- one-person changes, builds, or integration introduces risk into the system. Having two person controls or three person controls can ameliorate that risk. A typical methodology is having one person develop software, another check the software item against the requirements, and yet a third compile the software. Having three people separately involved reduces the risk significantly that malicious code can be introduced into the system.

27. Installation

"This is a rather straightforward element, requiring excellent documentation as to how to install the system in its operational environment."

Installing a system in an operational environment can introduce security concerns if not done correctly. A security professional should be on hand for the installation and the operational testing team, who should look specifically for introduced vulnerabilities, should then test the operational installation.

Debriefs and lessons learned from this process should be shared with the entire engineering team so that the knowledge is passed on.

28. Operations and Maintenance

"This part of the systems engineering process refers to the rather long period of time during which the system is operational in the field. From a systems engineering perspective, emphasis should be placed on the continuous measurement of the system’s performance."

The operations and maintenance of a system is where the rubber meets the road for information security. The elements of maintenance, logistics, P3I, and training all contribute to the correct functioning of the system throughout this period. Measurements regarding the effectiveness of the security features should be kept in order to improve the posture and to identify required changes.

29. Operations Evaluation/Reengineering

"If the preceding element is carried out correctly, a data base is built as to how well the system is performing over a long period of time. This places into evidence ways and means of evaluating system performance and points toward specific improvement areas for reengineering of the system."

As with every other element of system engineering, information security aspects should be included in this process.

30. Systems Engineering Management (Planning, Organizing, Directing and Monitoring)

"This last element covers all the management activities that must be considered by the CSE and lead systems engineering managers. As such, it includes the four basic functions of the project manager, namely, planning, organizing, directing, and monitoring."

Again, information security considerations should be included in each of these functions in order to achieve the security needs of the mission.

Conclusion

Modern corporations recognize that productivity, and hence competitiveness, depends directly upon their efficient and effective use of computers and information networks. Increasing use of Electronic Data Interchange (EDI), Just-In-Time inventory management, computer-controlled manufacturing processes, and automated management information systems in addition to the pervasive use of personal computers and workstations for e-mail, accounting and financial management, and word processing means that corporations are overwhelmingly dependent on computers and networks. These technological transformations have resulted in improved network services, performance, reliability, and availability as well as significantly reduced operating costs due to the more efficient utilization of network resources. They have also created an enormous security problem.

For the system engineer, this presents a real challenge since information technology is evolving at a faster rate than information security technology. In fact, information technology is so fast paced that system designers can barely complete system design calculations before the manufacturer wants to update certain specifications. Databases, operating environments, and even operating systems are being distributed. Computer and network security, on the other hand, does not currently have the enormous market forces incentivizing ever more clever products and solutions. On the contrary, existing security theory and technologies are advancing with the equivalent speed of a glacier.

In addition to the market-driven evolution of basic information technology, we are also undergoing a revolution in data processing that is creating unprecedented information systems security challenges. For example, the development and operation of massively parallel processing and neural networks, artificial intelligence systems, and multimedia environments present problems beyond any that formed our current information systems security experience base. Paradigm shifts such as distributed decision making, groupware, and collaborative environments conceptually leapfrog both security controls and security configuration management. Policies and standards applying to data formats and data labeling must be reviewed and adjusted as necessary to incorporate the necessary information systems security information. Labeling standards for security labeling of voice notes and files and video notes and files is needed. Doctrine for manipulating and combining formats has yet to be developed. And interoperability of dissimilar computers in multivendor environments is paving the way for transparent information sharing capabilities and a global integrated information infrastructure.

Private enterprise fully recognizes that greater connectivity, while unavoidable, makes information assets and systems increasingly vulnerable to the corruption, destruction or exploitation. Electronic access to vast amounts of data and critical infrastructure control is now possible from almost anywhere in the world. The sheer volume of data in our information systems makes these systems lucrative targets for disgruntled employees, hackers, competing commercial interests, and perhaps terrorists. We are only in the early stages of applying and understanding the new information technologies across our society, and many questions remain unanswered. Neither the ethics for an internetted society that define acceptable behavior on-line nor the legal structures that would punish misbehavior have been fully developed. This is particularly troublesome in the global marketplace, since neither national boundaries nor legal jurisdictions are apparent in cyberspace.

It is, therefore, very important to the system engineer to consider the impact of information technology in the system as a whole and to make appropriate decisions regarding the security concerns that come with such technology.