Advance Program (Panel)

One of the most persistent problems that universities struggle with is the battle of managing curricula breadth vs. depth in meeting both traditional and emerging demands of individuals and employers. The goal of providing a broad, well-rounded education conflicts with the goal of providing increasing depth of specialization in a particular field of study. Dynamically optimizing these two goals to meet the needs of the education consumers requires a process of curriculum management with sufficient responsiveness to address rapidly emerging, cross-disciplinary needs while maintaining sufficient stability to support continued accreditation. Maintaining currency within curricula as specialization continues to spawn new fields of study is a challenge. Information assurance, though it has evolved over the last nearly forty years, is such an emerging field of study. It addresses a pervasive problem of managing risks to information-based systems that have become increasingly ubiquitous in this Information Age. Thus, it requires specialized education to support its further development, and it requires extensive cross-disciplinary education to support its application. University curricula managers must come to realize that it is perhaps one of the most important areas of study if we are to enable new ways of doing business via networked information systems, and that aspects of it apply to almost every area of study within a university. Today's curricula management process remains relatively static and generally non-responsive to emergent and cross-disciplinary needs. The most common response from curricula committees is there is no more space in the core curricula to add another topic. Something must come out if we are to put something else in. Another response is that there are so many core requirements in the curricula that the student has little opportunity for optional courses. Still another response is that a particular area of interest is not sufficiently mature to warrant its own field of study. Such responses have been particularly true in trying to incorporate information assurance into university curricula. There are no panaceas in this battle, but there may be innovative approaches to achieving an appropriate blend of information assurance breadth vs. depth in individual universities. Structural changes in course content to change the focus or emphasis of a course (e.g., safe or defensive programming, system engineering experimentation) can provide an initial starting point. Other innovative approaches that may help universities be more responsive to educational consumers include: Self-paced instruction, distance learning, modular curricula, professionals as adjunct professors, visiting lecturer chairs, special topics courses, university outreach, corresponding university agreements, engineering research extension programs, industrial partnerships, adult continuing education, and the willingness of a university to further tailor curricula to meet individual student needs. These approaches should each be examined as part of revalidating and reinventing the university for the 21st Century. A simple example of such innovation is the development and application of modular curricula. In 1987, I was part of a group , sponsored by National Computer Security Center (NCSC), chartered to introduce computer security into the computer science curricula via the Joint ACM-IEEE Computer Science Curricula Committee. The approach we took was to write six optional undergraduate curricula modules that could be used as desired by computer science professors as adjuncts to their core curricula courses. For example, we had an operating systems security module to accompany the core operating systems course and a similar one for network security. Professors could use these modules to tailor their courses so that information security could be included to a level appropriate to other requirements of the course. While we were unsuccessful getting them into the Joint Curricula due to administrative release problems, they have been used rather extensively through the early 1990 s. The NCSC has distributed several thousand copies of these modules, though the modules now need to be updated to be truly useful. The general feedback was that the modules provided a good start to incorporating computer security into core, undergraduate computer science courses. Today s question before this panel is whether to establish in-depth curricula in security engineering or to integrate security engineering into software engineering curricula. I assert that the question should not be either-or, but rather a larger one of how to establish an appropriate multi-disciplinary blend of information assurance education in the future curricula of universities. The educational objective I have in mind is to not just to develop the largely missing engineering science related to information assurance, but also to broadly apply appropriate aspects of information assurance knowledge to all disciplines taught in a university setting. We must generate the awareness for the need to apply information assurance and an understanding of when, where, and how it may be applied. Such applications include electronic commerce, protection of intellectual property, engineering, communications, government, law, and basic sciences. Any discipline that uses computers will need to be taught some aspects of information assurance. Similarly, those disciplines must inform the information assurance discipline of their needs, failures, and successes. Most importantly, we must teach systems engineers in a manner that they are thoroughly grounded in information assurance principles and techniques. We do not approach the engineering of computer-based systems in the same manner that we approach the engineering of physical entities. We do not have the equivalent data for our engineering tasks that the civil or mechanical engineers have. We need extensive computer science and engineering experimentation to build the data necessary for software and systems engineers to do their jobs. The commercial industry is desperate for such systems-level engineering information so that they can clearly understand how best to incorporate their products into larger-scale systems. This demand argues strongly in two directions: One for the full incorporation of information assurance topics throughout the computer science and computer engineering curricula with cross-disciplinary interfaces with business, medicine, manufacturing, electronic commerce, and other enterprise domains. Another, for more in-depth intra-disciplinary education. Information assurance is fundamental to system interoperability and large-scale distributed enterprise operations. It ties in applications, process engineering, communications and distributed computing, policy enforcement, and many other issues. New initiatives within the federal government are being taken to focus on protecting our critical national infrastructures and on high confidence systems. The infrastructure vulnerability problems underlying these initiatives convey that there is need for both breadth and depth in high assurance software and systems engineering educational activity. I believe it is the blend of this breadth and depth that is needed. Information assurance should no longer be thought of as something relegated to the Security Gurus. It must be thought of from a disciplined systems-engineering point of view for every information system that is designed, built, fielded, and maintained. Computer systems are becoming increasingly ubiquitous in our lives. Many of these systems support safety-critical, security-critical, and life-critical needs and require high assurance that these needs will be met. Information assurance is required in the design and construction of software that provides control of physical systems such as integrated avionics. It is critical in software that provides significant process control such as banking, electronic commerce, telemedicine, nuclear power plant control, and manufacturing. All of these systems require the designers, builders, users, and regulators of these systems to have high confidence that they will operate correctly, safely, securely, and reliably. High confidence is derived a priori to operational fielding through assurance argumentation. Assurance argumentation for any system is generally accepted to be composed from four different components with which future software and system engineers must be thoroughly familiar: Assurance Mechanisms the behavioral control components that are embedded within a system. Assurance Processes the means by which the system was developed. Assurance Evaluations the means by which the system is examined for expected behavioral properties. Environmental Expectations the assumptions made regarding how the system will interact with its environment. Assurance Mechanisms. First, software and systems engineers should be taught about integrity, availability, and confidentiality mechanisms and techniques that will be required in various types of systems that they will design and build. They should be taught about the locations, strengths, and interdependencies of the various forms of these mechanisms. Beyond the mechanisms is the idea of techniques. Here, software engineers should be taught how to perform and apply defensive programming. The issue extends to cultural enforcement. In today s culture, many programmers may have been taught aspects of defensive programming, but we continue to experience buffer overflows and exceptions that are not handled in some of our most critical software. We must do better in inculcating software development best practices. Finally, engineers should be taught about the available architectural and engineering tradeoffs to be considered in achieving the assurance and performance properties required of the system. It should be noted here that one of the missing essential ingredients is the engineering experimentation data to support this tradeoff analysis. If we are to do systems engineering, we need to have engineering measurement data. University research could help tremendously in this area. Assurance Processes. The second component that software and systems engineers should be educated in is assurance processes. Today, most systems are developed using ad hoc trial-and-error methods, or what may be termed discover and patch. The system development process we should be striving for is one of correct by construction. This requires a much more disciplined and rigorous approach to software and system development. It requires extensive failure analysis. Engineers should be taught how to express system design in formal terms using mathematics and formal logic. Engineers should be taught component and behavioral composition. Engineers should be supported with tools and techniques that integrate well into the system s development process. Such tools and techniques should enforce software engineering best practices. Like other engineering disciplines, the failure modes and mitigation approaches should be captured and codified. Assurance Evaluation. The third system and software engineering educational component is assurance evaluation. Evaluation is a process to examine evidence that the system has been designed and built correctly, and that it can be expected to operate correctly in its intended environment. Such evidence comes from unambiguous system requirements and design documentation. It comes from software construction and testing documentation that well articulates the structure and behavior of the assurance mechanisms incorporated into a system. It also comes from operational testing and analysis of the system in its expected environment either in a live mode or in a simulated mode. Finally, it comes from the examination of process variance documentation over the course of the development. Each individual and each team of individuals should keep logs that document the process and product variance of their efforts over time. They should discover where the most frequent failures occur as well as the pace in which these failures are mitigated over time. Environmental Expectations. The fourth educational component is perhaps the most difficult. Assumptions of the operational environment often do not take into account more than a nominal environment. Future systems engineers must take into account adverse environments and abnormal conditions as a matter of course. They must expect failure within the environment and develop both system reliability and system survivability capabilities. Rigorous failure analysis should be part of assessing the environmental assumptions. Rather than expectations of fault containment, one should approach the problem from expanded fault propagation until one has examined each component of the system for failure of assumptions to hold. Having done this analysis, appropriate and affordable margins to accommodate failure and manage risks must be engineered into the system. What does this blending of information assurance into university curricula do to change our software engineering and systems engineering education? First, it more thoroughly embeds systems, safety, reliability, and security engineering into software engineering. Second, it embeds more mathematics, logic, and behavioral analyses into software engineering to achieve greater rigor in the process. Third, it adds process control mechanisms to the engineering process. Fourth, it provides a greater breadth of information assurance awareness, enabling more informed application users and designers. Finally, it adds more environmental analysis to the systems engineering process. This change is the integration aspect of blending in information assurance into our systems and software university education curricula. The depth aspect of this blend is dedicated pursuit of education in systems, safety, reliability, and security engineering. This is a critical element of future university engineering education, especially if they are to meet current and future demands of industry and government. These disciplines have specialty requirements unto themselves. We have too few courses in existence and a demand for expertise much greater than universities can support today. More exploration is needed to develop new mechanisms and techniques in these disciplines. More research is needed to address security, safety, and reliability issues in emerging technologies. And, based on the demand, more federal research funds can be expected to address these needs. Thus, I argue that universities need to blend the dedicated pursuit of these disciplines with their more general application to software and system engineering. To achieve this blend, universities should focus on education and research in system engineering fundamentals to include safety, security, and reliability, and appropriately apply these fundamentals to software engineering. Universities should focus on assurance mechanisms and techniques in system engineering practices, to include experimental measurement of the behavioral and performance properties, and apply these to software engineering. Universities should ensure that all disciplines have some level of information assurance awareness education. Universities should also pursue systems engineering process improvements to include software engineering. Finally, universities should focus on tools and techniques development that can be applied to enhance the effectiveness and efficiency of software and system engineering processes. What s in it for the universities to change? Why do the universities need to change if the industry is not yet using assurance techniques in its processes and cannot yet see the value of their use? There is both a growing need and expanding opportunities to achieve information assurance in software and systems engineering. With computers becoming more ubiquitous in every aspect of our lives, universities must stand up to the need to develop software and systems engineering expertise that is capable of developing high assurance systems. Industry, in my visits to them, has continued to point out their need for more qualified systems-level engineers with high assurance experience. We do not have that engineering capability today. The older generations of systems developers can be convinced to change when both the expertise and university-developed tools and techniques reach industry and demonstrate significant improvements in the assurance of software and systems, especially if such improvements can also be linked to improvements in the affordability of high assurance systems. We are beginning to see a greater awareness of the need for high assurance in many different user domains. We are also beginning to see some uses of high assurance expertise and technologies in hardware design. Partnering with industry may help improve both the development of new expertise and the development and deployment of new software and systems engineering technology. Gaining government support to make this change could also enhance the manner in which universities achieve requisite capabilities to produce future expertise, tools, and techniques for high assurance. The key is not to focus on just integrating security into software engineering or on establishing a new security engineering curricula, rather it must be on blending the two in a wider multi-disciplinary manner to advance the goals of better overall software and system engineering. Members included: Dr. Dorothy E. Denning (Chair), currently at Georgetown University; Ms. Janet M. Cook, Illinois State University; Mr. J. David Fox, University of Maryland at Baltimore; Dr. Virgil D. Gligor, University of Maryland; Dr. David K. Hsaio, Naval Postgraduate School, Monterey; Dr. Lance J. Hoffman, George Washington University; Dr. Richard Kemmerer, University of California, Santa Barbara; Dr. Michael Mulder, University of Portland; Dr. Charles P. Pfleeger, University of Tennessee; Dr. A. Joe Turner, Clemson University; Ms. Carolyn Deverin, National Computer Security Center; Dr. R. Alan Whitehurst, National Computer Security Center; and Terry Mayfield, Institute For Defense Analyses. Modules included: Introduction to Information Protection, Operating Systems Security, Network Security, Database Security, Formal Specification and Verification, and Risk Analysis.