NISTIR 5472 iii A HEAD START ON ASSURANCE Proceedings of an Invitational Workshop on Information Technology (IT) Assurance and Trustworthiness March 21-23, 1994 George Washington Inn Williamsburg, Virginia Edited by Marshall D. Abrams The MITRE Corporation and Patricia R. Toth National Institute of Standards and Technology Sponsored by Aerospace Computer Security Associates Co-sponsored by National Computer Systems Laboratory, National Institute of Standards and Technology ABSTRACT The purpose of the Invitational Workshop on Information Technology (IT) Assurance and Trustworthiness was to identify crucial issues on assurance in IT systems and to provide input into the development of policy guidance on determining the type and level of assurance appropriate in a given environment. The readers of these proceedings include those who handle sensitive information involving national security, privacy, commercial value, integrity, and availability. Existing IT security policy guidance is based on computer and communications architectures of the early 1980s. Technological changes since that time mandate a review and revision of policy guidance on assurance and trustworthiness, especially since the changes encompass such technologies as distributed systems, local area networks, the worldwide Internet, policy- enforcing applications, and public key cryptography. FOREWORD The Aerospace Computer Security Associates (ACSA) had its genesis in the first Aerospace Computer Security Applications Conference in 1985. That conference was a success and evolved into the Annual Computer Security Applications Conference (ACSAC), which is now in its tenth year. Several years ago, "Aerospace" was dropped from the name to promote a wider range of government and commercial applications. ACSA was incorporated in 1987 as a small, non-profit association of computer security professionals who have a common goal of improving the understanding, theory, and practice of computer security. ACSA continues to be the primary sponsor of the annual conference. In 1989, ACSA began the Distinguished Lecture Series at the annual conference. Each year an outstanding computer security professional is invited to present a lecture of current topical interest to the security community. Past Distinguished Lecture speakers have included Dorothy Denning and Willis Ware. In 1991, ACSA began issuing a Best-Paper-by-a-Student Award at the annual conference. This award is intended to encourage active student participation in the annual conference. The Distinguished Lecturer and the award winning student author receive an honorarium and all expenses paid for attending the conference. ACSA continues to be committed to serving the security community by finding additional approaches for encouraging and facilitating dialogue and technical interchange. ACSA is always interested in suggestions from interested professionals and computer security professional organizations on achievement of these goals. In early 1994, ACSA, responding to a perceived growing need in the community, organized and sponsored the Invitational Workshop on Information Technology Assurance and Trustworthiness (IWITAT). The IWITAT is the first in what ACSA hopes will be a successful series of workshops on assurance, trustworthiness, and other topics of critical interest to security professionals. These proceedings document the activities of that workshop. The Computer Systems Laboratory (CSL) at the National Institute of Standards and Technology (NIST) works with governments, industry, academia, and consortia to improve the efficiency and delivery of government services. CSL develops standards, guidelines, and test methods; validates products for conformance to standards; conducts research; and provides techical advice and assistance. Many interactions are accomplished working directly with industry through workshops, research and development agreements, and other cooperative arrangements. The Computer Security Division of the CSL provides guidance and technical assistance to government and industry in the protection of unclassified automated information systems. The Computer Security Division develops, prototypes, tests and implements computer security standards and procedures to prtoect sensitive information from unauthorized access or modicification. Areas of cooperation with industry include risk management; open systems; LAN security; security architectures; systems integration; and public and private key cryptographic techniques as applied to electronic data interchange (EDI), electronic funds transfer, and electronic mail. PREFACE ABOUT THIS INTERNAL REPORT This Internal Report contains many more questions than answers, accurately reflecting the current state of knowledge and practice. It is, however, a significant step toward developing an agenda for future work in IT assurance and trustworthiness. The plenary and working sessions are each documented in a separate section of this Internal Report. The reader is assumed to be knowledgeable about information security and familiar with the Trusted Computer System Evaluation Criteria (TCSEC) (DOD, 1985) as well as more contemporary efforts, such as the Canadian Criteria (Canadian System Security Center, 1993), the European Information Technology Security Evaluation Criteria (ITSEC) (Commission of the European Communities, 1991), and the United States Federal Criteria (FC) for Information Technology Security (National Institute of Standards and Technology and National Security Agency, 1992). For background reading, we suggest Computers at Risk [National Research Council, 1991]. Also, publication of Redefining Security (Joint Security Commission, 1994) shortly before the workshop provided an authoritative source for many commonly held opinions. Specifically the following chapters cite directly relevant background to this Internal Report: Chapter 1, "Approaching the Next Century"; Chapter 8, "Information System Security"; and Chapter 11, "A Security Architecture for the Future." ACKNOWLEDGMENTS We wish to acknowledge the assistance of Heidi Bass of the George Washington Inn for her support during the post-workshop editing session. C. Dawn Gibson and Carol R. Oakes of The MITRE Corporation helped transform independent contributions into a coherent proceedings. TABLE OF CONTENTS EXECUTIVE OVERVIEW XVII INTRODUCTION XVII WORKING SESSIONS XVIII TRADEOFFS XVIII PEDIGREE XVIII SECURITY ARCHITECTURE AND APPLICATIONS XIX PROCESS XIX METRICS AND TESTING XX RISK MANAGEMENT XX CLOSING XXI INTRODUCTION 1 1.1 PURPOSE OF THIS WORKSHOP 1 1.2 PRELIMINARY LIST OF ISSUES 2 1.3 WORKSHOP ORGANIZATION 3 1.4 TERMINOLOGY 4 1.5 DOCUMENT ORGANIZATION 5 THE OPENING PLENARY 7 SECURITY ASSURANCE TRADEOFFS 9 3.1 INTRODUCTION 9 3.2 MAIN CONCEPTS DISCUSSED 10 3.3 WHAT IS WRONG WITH THE TCSEC EMPHASIS ON TCB ASSURANCE?11 3.4 WHY IS SECURITY OF THE OPERATING SYSTEM TCB DIFFERENT FROM SECURITY OF AN APPLICATION? 12 3.5 IS IT POSSIBLE TO QUANTIFY ASSURANCE VERSUS VULNERABILITY TRADEOFFS? 13 3.6 WHO SHOULD MAKE TRADEOFF DECISIONS? 15 3.7 CONCLUSIONS 15 PEDIGREE 17 4.1 INTRODUCTION 17 4.2 ISSUES ASSOCIATED WITH PEDIGREE 18 4.2.1 WHAT IS A PEDIGREE? 18 4.2.2 APPLICABILITY 19 4.2.3 INDIVIDUAL PEDIGREE 20 4.2.4 ORGANIZATIONAL PEDIGREE 20 4.2.5 MEASUREMENTS 20 4.2.6 ENFORCEMENT 21 4.2.7 USEFULNESS 21 4.2.8 AGGREGATION 22 4.3 CONCLUSIONS 22 4.3.1 TERMINOLOGY 22 4.3.2 CATEGORIZING 23 4.3.3 FORMAL VERSUS INFORMAL IMPLEMENTATIONS 23 SECURITY ARCHITECTURE AND APPLICATIONS 25 5.1 INTRODUCTION 25 5.2 NEW TECHNOLOGIES IN DISTRIBUTED COMPUTING 27 5.3 IS UNDERSTANDING AND IMPLEMENTING SECURITY IN LARGER DISTRIBUTED SYSTEMS LESS ACHIEVABLE? 28 5.3.1 POLICY ISSUES 28 5.3.2 ACCESS ISSUES 30 5.3.3 SCALABILITY ISSUES 30 5.4 ARE WE FOCUSED TOO MUCH ON OPERATING SYSTEM SECURITY? DO WE NEED TRUSTED APPLICATIONS? 31 5.4.1 FOCUS ON THE OPERATING SYSTEM 31 5.4.2 TRUST IN APPLICATIONS 32 5.5 HOW CAN SECURITY ARCHITECTURES EASE ASSURANCE ARGUMENTS? 33 5.6 CAN SOME SECURITY ARCHITECTURES ALLOW INTEGRATION OF NEW TECHNOLOGIES, SUPPORT MORE SECURE USE OF LEGACY SYSTEMS, AND PROMOTE ASSURANCE? 33 5.6.1 NEW TECHNOLOGIES AND LEGACY SYSTEMS 33 5.6.2 ADMINISTRATION OF DISTRIBUTED SECURITY 34 5.7 CAN DIFFERENT SECURITY ARCHITECTURES ALLOW USERS MORE EFFECTIVE ACCESS TO THEIR DATA? 35 5.8 CONCLUSIONS 36 PROCESS 39 6.1 INTRODUCTION 39 6.2 MAIN CONCEPTS DISCUSSED 40 6.2.1 WHY FOCUS ON PROCESS 40 6.2.2 RELIANCE ON PROCESS 40 6.2.3 MEASUREMENT AND ASSURANCE OF PROCESS 41 6.2.4 UNDERSTANDING ASSURANCE AND ITS INGREDIENTS 42 6.2.5 RELATING PROCESS TO ASSURANCE 44 6.2.6 PROCESS ASSURANCE AS A BASIS OF SYSTEM/PRODUCT ASSURANCE 44 6.2.7 PROCESS IMPROVEMENT 45 6.3 CONCLUSIONS AND FUTURE DIRECTIONS 46 METRICS AND TESTING 49 7.1 INTRODUCTION 49 7.2 BACKGROUND 49 7.3 RATIONALE FOR ASSURANCE 50 7.4 DEFINITION AND PURPOSE OF ASSURANCE 51 7.5 KINDS OF ASSURANCE 52 7.6 ASSURANCE TECHNIQUES 53 7.6.1 POLICY ASSURANCE 53 7.6.2 EFFECTIVENESS AND CORRECTNESS ASSURANCE 53 7.6.3 EVALUATION ASSURANCE 54 7.6.4 ENSURING BALANCE 54 7.7 WHERE TESTING FITS IN 55 7.7.1 WHERE AUTOMATED TESTING FITS IN 55 7.8 CONCLUSIONS 56 RISK MANAGEMENT 59 8.1 INTRODUCTION 59 8.1.1 EXTRACTS FROM REDEFINING SECURITY 59 8.1.2 TOOLS NEEDED FOR RISK MANAGEMENT 60 8.2 FUNDAMENTAL AND VERY TOUGH QUESTIONS 61 8.3 TERMINOLOGY 61 8.4 MULTIDIMENSIONAL COMPLEXITY 61 8.5 TRADEOFF AND BALANCE 62 8.6 SCOPE OF IT SECURITY 62 8.7 DECISION MAKING TECHNIQUES 63 8.8 DECISION-MAKERS 64 8.9 BASIS FOR DECISIONS 64 8.10 SYSTEM CHARACTERISTICS 65 8.11 CONTINGENCY PLANS 65 8.12 DISSEMINATING INFORMATION 65 CLOSING 67 9.1 IT SECURITY ASSURANCE WORKSHOP UTILITY 67 9.2 FUTURE ASSURANCE WORKSHOPS 67 9.3 FREQUENCY OF WORKSHOPS 68 9.4 OBSERVATIONS ON PROGRESS 68 LIST OF REFERENCES 69 GLOSSARY 75 LIST OF FIGURES FIGURE PAGE 1 Risk Management Process 52 EXECUTIVE OVERVIEW INTRODUCTION The twofold purpose of the Invitational Workshop on Information Technology (IT) Assurance and Trustworthiness was to identify crucial issues on assurance in IT systems and to provide input into the development of policy guidance for determining the type and level of assurance appropriate in a given environment and talk about also guiding future directions in this area. The workshop participants defined assurance, as applied to IT products and systems, as the degree of confidence that security needs are satisfied. Existing IT security policy guidance is based on computer and communications architectures of the early 1980s. Technological changes since that time mandate a review and revision of policy guidance on assurance and trustworthiness. These changes encompass such technologies as distributed systems, local area networks, the worldwide Internet, policy-enforcing applications, and public key cryptography. There is a growing consensus that no one technique can provide comprehensive adequate assurance. Established approaches need to be re-examined and compared to newer ideas. Major issues and concerns include the following: y How architecture contributes to assurance - The balance of assurance between operating systems and applications - The management of information security for subscribers in a worldwide information infrastructure - The use of larger, more heterogeneous computing environments y The growing requirement to enforce policies other than confidentiality, such as the following: - Integrity and availability (primarily) - Non-repudiation or anonymity (occasionally) y The relationship between process and assurance Since no metrics exist for determining the effectiveness of assurance techniques, it is very difficult to compare the various techniques. Nevertheless, (GAO, 1994) and (JSC, 1994) recommend approaches for improved cost-effectiveness. WORKING SESSIONS The workshop was structured into six working sessions, each of which is summarized below. Tradeoffs Assurance effort for any system should be balanced based on perceived risk and cost. Application assurance, which has generally been underemphasized in the past, should be addressed along with product assurance. There is no single uniform approach to assurance that will satisfy all kinds of system applications. To support a balanced approach, assurance arguments should be assembled from a set of system building blocks. Concepts of system composition and integration should allow the assurance analysis to be tailored to specific user requirements. Assurance evidence should be carefully packaged to best support enterprise decision-makers during the security tradeoff process. Pedigree The Pedigree session focused on the acceptability of assurance evidence based on the identity of the creators of that evidence. That is, participants discussed assurance evidence based on the "who" rather than the "what" or "how." The term "credentials" would also have been a good name for this session. The issues can be logically grouped into one of the following eight categories: y Applicability y What is "pedigree"? y Assurance based on an individual y Assurance based on an organization y Measurements/metrics y Enforcement and liability y Usefulness y Aggregation concerns Drawing on the similarities and differences among IT security professionals and other professionals such as engineers, certified public accountants, and lawyers, much of the general discussion addressed the value/drawbacks of formalizing an informal aspect of assurance. Security Architecture and Applications This session aspired to identify opportunities for managing information security for subscribers in a worldwide information infrastructure, to learn how architecture contributes to system assurance, and to understand how application-specific requirements can be addressed in this context. We observed a growing requirement to enforce policies other than confidentiality (e.g., integrity, availability, non-repudiation, or anonymity). Achieving security solutions that are applicable in a larger, more heterogeneous computing environment requires a shift from the current paradigm of developing security for each individual system toward recognition that security is a global property that must be addressed throughout the computing environment. Moreover, each component or system within the environment has a role to play in the protection of information. Conventional security approaches can ensure that these systems or components comply with their defined role. Some of these approaches were discussed in detail, including the development of trusted applications and products that support the enforcement of different policies. Process Two fundamental issues for this session were (1) whether improved and uniform processes for development and evaluation will lead to higher quality and more predictable evidence and, hence, better, faster, less expensive assurance and (2) to what degree can assurance about process contribute to assurance about products and systems. The following major topics emerged: assurance about a process; the relationship of process to system/product assurance; and process improvement. Fundamental issues regarding process and assurance and their interrelationships include reliance on process, particularly the development process, as a major component of system and product assurance; measurement of process quality and adherence as a basis for assurance; and understanding assurance in terms of concepts such as correctness, effectiveness, and workmanship. Many interrelated processes exist today; these processes may be formally stated or conducted in default. While a single integrated process sounds attractive, it most likely would be too complex, too high-level, and ineffective. Metrics and Testing The session identified five different types of assurance and, for each type, relevant assurance techniques. This session discussed what assurance is, how it can be measured, both qualitatively and quantitatively, and how testing, including automated testing, fits in to assurance. Having identified five different types of assurance, the group identified relevant assurance techniques for each type. The five identified types were: policy assurance, design-effectiveness assurance, system-correctness assurance, evaluation assurance, and ensuring balance among the first four types. This session's main conclusion regarding assurance measurement was that we have not been collecting the types of data needed for reliable measurements. Risk Management We cannot pretend that by implementing certain security measures we can mitigate all security risk. This paradigm shift from risk avoidance to risk management (i.e., risk tolerance) brings to light the necessity of dealing with the unimaginable. It is also necessary to consider incomparables such as system security, human safety, and personal career. Viewing risk assessment from the standpoint of assets and threats is necessary but not sufficient. There are several kinds of risks to which systems are subjected, including technical, schedule, cost, security, and safety. Security risks need to be considered in the context of overall risks. Satisfaction of all objectives and avoidance of all risks are generally impossible to achieve because the objectives or techniques used to achieve these objectives are often in conflict. The members of this session felt that much of current risk management methodology is an attempt to use the scientific method for a problem that has not been reduced to science. Fundamental and very hard questions need to be answered to make any progress on risk management: What are the security requirements, including assurance? In what ways do we risk not meeting those requirements? How much are we willing to spend to mitigate those risks and to what degree? What should be the government's role in helping to protect information held by private citizens and institutions? How can government technology be provided to the private sector for the protection of sensitive unclassified information? Will the private sector accept that technology? CLOSING The general consensus was that a forum to discuss the issues of IT security assurance was of great use to the community. In particular, this workshop determined that assurance is still a somewhat nebulous subject. There are many questions that need to be explored. It is still difficult to define precisely what is meant by assurance, and the definition varies from person to person and enterprise to enterprise. The questions of how to gain assurance, how to convey assurance results, and how to use assurance all need further study. It was generally felt that just the identification of these questions for further study made the workshop a useful exercise. There was some sentiment that these subjects need to be pushed back out into the community for actual resolution. The security community appears to have made little progress in truly understanding the issues at hand, and there is little hope for the immediate future. While there appeared to be much agreement on what had been done incorrectly in the past, there appeared to be little consensus on how to proceed. One thing appears clear; in order to improve the security of our information and resources we must: y Respond in a timely manner to rapidly changing technology and threat environment y Becomes more proactive and more in touch with the real user needs and expectations y Does a better job of developing security awareness in the user community (to ensure security is built in and maintained during operation of the system). SECTION 1 INTRODUCTION Before entrusting valuable information assets to an IT system and placing an organization in a position of depending on the confidentiality, integrity, and availability of these assets, responsible management must be convinced that the IT system is sufficiently trustworthy to meet the needs of its operational environment. Work is under way to produce new national and international criteria for IT security. These emerging criteria ascribe to the paradigm of analyzing a given environment to identify risk, threat, and vulnerability; determining applicable legislation, policy, and custom; and selecting administrative, physical, and technical countermeasures that reduce the residual risk to an acceptable level. These criteria describe IT security functionality and approaches for assurance, but they do not include guidance on how to determine the appropriate and necessary assurances for a particular environment. By way of contrast, the TCSEC assumed the presence of a human adversary who attempts to cause the IT system to behave in a way contrary to that for which it was intended. While this assumption has had a dominating influence on assurance for IT products designed for the military, it is clearly not accurate for all operational environments. 1.1 PURPOSE OF THIS WORKSHOP The purpose of this workshop was to document the perceived state of practice and stimulate new ideas concerning assurance in security-relevant IT systems. Input from people in the field who must make decisions about using IT was especially sought. Publishing this information is designed to provide input into the development of security policy guidance on determining the type and level of assurance appropriate in a given environment. Practically all existing security policy guidance is based on the Yellow Books, published in 1985 (National Computer Security Center, 1985). This guidance was based on computer and communications architectures of the 1980s. This workshop addressed questions of how policy guidance on assurance and trustworthiness needs to be revised in order to stay consistent with technological changes, especially those brought about by distributed systems and related technologies such as local area networks, the worldwide Internet, policy-enforcing applications, and public key cryptography. Security policy guidance combines aspects of technology assessment, risk analysis, and cost-effectiveness. Trade-offs between academic and cost-effectiveness considerations must be made. Answers must be given in the face of inadequate information and technical uncertainty. The mission of the workshop was to identify the crucial issues and to make recommendations for future direction in this area. Readers of these proceedings include those who handle sensitive information involving national security, privacy, commercial value, integrity, and availability. Participants submitted position papers expressing technical or policy views, and these position papers were used to identify working session topics. All accepted position papers were distributed as anonymous to all participants by e-mail in advance of the workshop. It was felt that anonymity would better serve the objective that position papers should stimulate discussion and not necessarily represent final positions. For the same reason, the position papers are not included in this publication. 1.2 PRELIMINARY LIST OF ISSUES A preliminary list of issues, presented below, was offered to focus and stimulate the position papers. Not all of these issues were discussed. In fact, the entire workshop identified many more problems than it solved. These issues were used to develop the working session topics listed in Section 1.3. y Assurance is not a one-dimensional quantity, but a vector with many components, one for each perceived threat in the user environment. y Threats need to be more cost-effectively aligned with appropriate countermeasures, especially in environments where the threat changes dynamically. y Precedent may not be the best indicator of what assurances are acceptable. y Practical considerations of cost-effectiveness strongly suggest that pre-deployment product assurance should be balanced with operational assurances in the area of ongoing system operations and maintenance. y There is a danger in becoming too comfortable with the alleged intractability of perfect security. We are accepting the current crop of half-measures as the best attainable. y Kinds of guidance that are possible and appropriate need to be identified. y That guidance can take various forms: - Simple formula like Yellow Book risk index - One hundred possible scenarios for best match y The benefits of high-assurance techniques such as formal methods need to be examined - For cost-effectiveness - Comparison to original expectations. y Sufficient assurance in some environments can be provided by several methods: - Conforming with process standard such as International Organization for Standardization (ISO) (ISO, 1987) 9000. - Employing good software engineering practice - Providing limited warranties for repair of security flaws - Using capability maturity models developed by the Software Engineering Institute at Carnegie-Mellon University. y Direct characterization of product strength is needed, in terms of the difficulty of exploiting the flaws in the product. One would say that the product is suitable for a particular use if its security controls are harder to defeat than some pre-determined threshold. 1.3 WORKSHOP ORGANIZATION There was an opening plenary session, followed by six working sessions divided into two parallel tracks. Each working session had a moderator and recorder, listed below, who produced these proceedings. All of the attendees were given an opportunity to copy edit these proceedings. The moderator for each working session started the activities by summarizing the issues and suggestions. The moderator's remarks were based, in part, on the position papers submitted. Although the position papers were not presented at the workshop, the authors had the opportunity to remain anonymous, to keep to the position they wrote, or to change their minds. Some, but not all, of the authors identified themselves. The working sessions, moderators, and recorders were as follows: Security Assurance Tradeoffs Moderator: Bret Hartman Recorder: Lynne Ambuel Pedigree Moderator: Deb Campbell Recorder: Pat Toth Security Architecture and Applications Moderator: Judy Froscher Recorder: Jay Kahn Process Moderator: Joel Sachs Recorder: Caralyn Wichers Metrics and Testing Moderator: Jim Williams Recorder: Caralyn Wichers Risk Management Moderator: Marshall Abrams Recorder: Lynne Ambuel 1.4 TERMINOLOGY Participants agreed that the pronoun we is often overused or ambiguous. Usually it refers to the set of people working on information security issues, sometimes called the information security community. Sometimes it referred to the technical subset of the information security community, excluding the managers. Sometimes it is the regal we. Occasionally, it referred to us_the workshop participants. We hope that no one is unnecessarily confused by this usage. Any confusion in this publication probably reflects how well we understand each other. 1.5 DOCUMENT ORGANIZATION As stated previously, the remaining sections of this document correspond with the plenary and working sessions of the workshop: Section 2, "Opening Plenary"; Section 3, "Security Assurance Tradeoffs"; Section 4, "Pedigree"; Section 5, "Security Architecture and Applications"; Section 6, "Process"; Section 7, "Metrics and Testing"; Section 8, "Risk Management." The document concludes with closing statements cited in Section 9 and an appendix describing security services applied to the THETA system. SECTION 2 THE OPENING PLENARY The opening plenary session began by defining the objectives of the workshop: provide input to policy guidance in the face of inadequate information and technical uncertainty; identify the type and level of assurance appropriate in a given environment; combine and trade-off aspects of technology assessment, risk analysis, and cost-effectiveness, recognizing that we may not be able to afford academic completeness; and identify crucial issues and make recommendations. Participants were asked to focus on assurance and resist the temptation to solve all information security problems. Several sets of extracts from Redefining Security (Joint Security Commission [JSC], 1994) set the stage for discussion. While the report address the situation in the United States (U.S.), it is probably applicable to other countries as well. The motivational observations included: y Protecting the confidentiality, integrity, and availability of the nation's information systems and information assets_both public and private_must be among our highest national priorities. y IT is evolving at a faster rate than information systems security technology. y A systems approach is necessary in making decisions about the application of security countermeasures. y Countermeasures are frequently out of balance with the threat, often based on worst-case scenarios rather than realistic assessments of threats and vulnerabilities. y Security is a service that should be based on an integrated assessment of threat, vulnerability, and customer needs. y Security is a balance between opposing equities. The JSC observations about threats to information and information security included: y Networks are recognized as a battlefield of the future. y An attack on unprotected civilian infrastructures could be disastrous. y Foreign intelligence services, including those of some of our "allies," are known to target U.S. information systems . y Computer viruses, other malicious software, and hackers are increasingly common and dangerous. y Hiding information about security flaws from ourselves doesn't help. y Eighty-five percent of computer crime is committed by insiders with validated access. Observations about failed strategies served to remind the participants that business as usual is unacceptable: y Encouraging the private sector to design, develop, and manufacture products at their own expense against government promise to require their use: the government did not follow through and buy the products. y Research has focused on classified information to the detriment of protecting unclassified information and infrastructure. The JSC-recommended strategies directed the focus to constructive criticism: y Promoting understanding in the private sector that it is less expensive to protect information assets with affordable technology than with insurance should result in availability of moderate-assurance security products. y Government funding is necessary to promote development of high-assurance products. y It would be reasonable to allocate five to ten percent of total development and operational cost to ensure availability, confidentiality, and integrity. y Research and development (R&D) should be coordinated and focused on products for protection of classified and unclassified networks and systems. y Infrastructure security management should be given more attention. SECTION 3 SECURITY ASSURANCE TRADEOFFS Bret Hartman, Moderator Lynne Ambuel, Recorder 3.1 INTRODUCTION This session addressed security assurance tradeoffs. Security assurance tradeoff decisions occur in many contexts, such as assurance benefit versus cost, the relationship of assurance to system functionality, and the requirements on assurance imposed by the value of information stored in the system. The group discussed a variety of tradeoff issues as well as the current views of the security community. Tradeoffs issues were a fundamental theme of the workshop_the group discussions cut across many of the other sessions. The position papers discussed during this session were representative of the growing opinion that the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) (Department of Defense [DOD], 1985) does not necessarily have the appropriate emphasis on assurance. The TCSEC focuses all efforts on the trusted computing base (TCB), which in the traditional view is the collection of hardware and software that enforces the underlying system security policy. By enforcing the security policy, the TCB thus ensures that untrusted non-TCB software may safely access sensitive information without danger of compromise. Experience has shown, however, that there are several problems with this approach. Traditional high-assurance systems (e.g., B3 or A1) are difficult to use because of limited functionality and the potential impact on performance. It remains to be determined whether it is practical to produce high assurance and high functionality products. In addition, the assurance evidence required is difficult and time- consuming to produce and evaluate. Furthermore, a traditional TCB may not adequately address the security requirements in applications. Applications include general-purpose systems such as Database Management Systems (DBMS) and financial management systems, highly focused systems such as process control, and in-between systems that focus on a broad market segment such as a military message system. Applications frequently have different security tradeoffs than the underlying TCB. The narrow security policy of the TCB may not be sufficient to protect against many application-specific security requirements in areas such as accountability, availability, integrity, and the prevention of information leakage through known covert channels in the TCB. The group discussed possible solutions to the limitations of the TCSEC approach to TCB assurance. One potential direction is to extend the system security perimeter to include both the TCB and the Controlled Application Set (CAS). The CAS is the set of applications that have access to sensitive information and thus are subject to additional constraints beyond those enforced by the TCB. Identifying the CAS is consistent with security measures in practice today, where certain critical applications are carefully controlled and analyzed. Another direction is to recognize that certain security functions beyond those typically implemented within the TCB can help augment application security. For example, containment mechanisms can limit damage caused by rogue applications. Application-specific security checks within the application may also contribute significantly to overall system assurance. Finally, the notion of balanced assurance was a common discussion theme during the session. Balanced assurance promotes the use of assurance techniques appropriate to the level of risk in system components. Based on the level of risk for specific components, different assurance techniques would be used as appropriate. For example, if discretionary access enforcement were considered a lower risk than mandatory access control for some system application, then mandatory access control mechanisms would be subject to much greater scrutiny. In order to make any security assurance approach feasible, we must recognize that it is not possible to eliminate the risk of a security compromise. Security assurance must always be a balance between cost and perceived risk. The primary assurance tradeoff involves one central issue: the balance of assurance cost versus the resulting security benefit. 3.2 MAIN CONCEPTS DISCUSSED In order to focus the discussion of assurance tradeoffs, the group discussed four concepts, presented below as questions: y What is wrong with the TCSEC emphasis on TCB assurance? y Why is security of a TCB different from security of an application? y Is it possible to quantify assurance versus vulnerability tradeoffs? y Who (e.g., policy makers, vendors, application developers, accreditors) should make tradeoff decisions? Each of these questions is addressed below. 3.3 WHAT IS WRONG WITH THE TCSEC EMPHASIS ON TCB ASSURANCE? The TCSEC emphasis on the TCB is inflexible_the TCSEC assumes a pre-defined set of threats (e.g., Trojan horse attacks) that are not necessarily relevant in all systems. Based on these threats, the TCSEC asserts that the TCB is the totality of required security mechanisms. In most systems, the TCB is the subset of the operating system that enforces access control, especially Bell-LaPadula (Bell-LaPadula, 1975) properties. Although the TCB has a significant role in enforcing system security, practice has shown that applications also have a large role. For this reason, it is important to examine how assurance applies to applications. In the non-DOD commercial world, assurance has a different emphasis. TCSEC assurance is usually too demanding for commercial applications. Assurance appears to have a bad connotation for many customers, indicating a product that is expensive and does not necessarily provide good performance. Despite the apprehension about high-assurance systems, customers still want the same result: they want to be sure that a product works as it is intended. The provision of product warranties appears to be a growing trend for assurance in the commercial world. Although the most common approach to commercial software development is perceived to have been to release unreliable code first and then fix bugs as they are discovered, this approach is becoming less common. X/Open, for example, is developing a branding process that entails the endorsement of software backed by a clearly defined vendor commitment to a defined standard of quality. When a vendor makes a public pronouncement that its UNIX system conforms to X/Open's branding scheme, it is committing to maintain this standard. If it is shown that a product does not actually meet X/Open requirements and the vendor does not correct the problem in a timely fashion, then that vendor may lose the right to use the X/Open Logo. When and if this becomes public knowledge the vendor may suffer embarrassment and lose market credibility and market share. The concept of a system containing "no obvious flaws" would be desirable as a basic security assurance requirement. If a standard list of known flaws were published and frequently updated, products could be tested against the list. This notion is similar to the current approach taken by virus- detection software. Although it is well known that assurance based solely on existing penetration attacks is inherently limited, this simple assurance approach would be a significant improvement over the current state of practice in most commercial systems. 3.4 WHY IS SECURITY OF THE OPERATING SYSTEM TCB DIFFERENT FROM SECURITY OF AN APPLICATION? In is generally accepted that the operating system cannot address all aspects of application-specific security because it is not possible to provide all security in an application- independent manner. There is some debate whether the security- relevant part of an application should be considered part of the TCB. Although an operating system TCB provides the underlying basis (e.g., identification and authentication) for building application security properties, it has traditionally emphasized enforcement of confidentiality. Applications tend to support other security properties, such as integrity and availability, that are specific to the problem domain. Tradeoffs of security properties (e.g., integrity versus confidentiality) must be based on operational requirements rather than a priori constraints defined in the TCSEC. The group agreed that the focus of system security must shift. Too much emphasis has been placed on assurance of products, and too little has been placed on assurance of systems. We need to spend more time and effort building and analyzing operational systems; product evaluation is only the first step of this process. Furthermore, we need to emphasize upgrading and maintaining the level of assurance once a system becomes operational. Assurance maintenance continues to be a neglected area for both products and systems. Basic building blocks that define subsystem abstractions are a critical aspect for developing assurance. Rather than a monolithic assurance approach, wherein the developer must follow a predefined formula, assurance in the form of building blocks allows developers and users to tailor assurance to their particular system. For example, military systems that primarily require confidentiality have traditionally concentrated on assurance of the underlying operating system, while commercial systems requiring integrity may address application software much more heavily. As discussed in Section 5, application security is becoming increasingly important for confidentiality policies as well. It may be appropriate to concentrate assurance on the areas with the most perceived risk. The TCSEC approach of relying on the operating system to provide integrity to all security-relevant functions needs to be re-examined. Its validity limits need to be probed and alternative bases, if any, need to be explored. In order to define system building blocks, we need assurance guidance for interconnecting subsystems, applications, and products. Further research is still required in this area_the concept of system composability, although defined for limited domains, needs to be developed further. Support for distributed systems, which are gaining widespread use, is particularly important. We also need to refine the concept of product integration. The fundamental issue is one of systems engineering: how to integrate subsystems into a larger system while preserving assurance. 3.5 IS IT POSSIBLE TO QUANTIFY ASSURANCE VERSUS VULNERABILITY TRADEOFFS? Many issues must be considered when performing assurance tradeoff analyses. This difficult task becomes even more complicated because many of the decisions are highly subjective. If quantitative measures to aid in tradeoff analyses could be developed, complexity of the tradeoff decision might be reduced. The group generally agreed that it was easier to quantify assurance tradeoffs by focusing on security vulnerabilities rather than security risks. Doing this may create a gap between quantification efforts and the risk containment and reduction goals identified in Sections 1, 3.4, 5, and 7.4, however. Current risk-analysis techniques are largely subjective, and are based on the judgment of expected threats to system security in a given environment rather than on actual experience. Objective risk-analysis techniques are discussed briefly in Sections 8.1 and 8.7. Security vulnerabilities can be largely assessed using purely technical criteria_while a particular vulnerability either exists or does not exist in a system, ease of exploitation may vary considerably. Because vulnerabilities can be identified objectively, they provide an attractive means for trading off against assurance. Assurance considerations in assurance/vulnerability tradeoffs are correctness of the mechanism/product/system, and the effectiveness of the mechanism in protecting against the perceived threat, often quantified as the level of effort required to subvert the assets being protected. Additional relevant kinds of assurance are identified in Section 7.5. It was generally accepted that the assurance paradigm presented in the TCSEC has been insufficient to address tradeoff decisions between types of assurance and vulnerability. The TCSEC prescribes specific assurance measures for avoiding vulnerabilities. However, the TCSEC does not consider many of the tradeoff decisions now being made in practice, such as tradeoffs between assurance measures and requirements on usability and performance. This limitation has often resulted in avoiding awkward trusted configurations during peacetime operations, hoping that the security features will work properly during a crisis. Making tradeoff decisions among mechanisms that perform a specific security function is a relatively straightforward task. Unfortunately, this aspect is only a small portion of the tradeoffs to be made. Cost, functionality, mechanisms, and assurances are all part of the decision. It is often difficult to make tradeoffs among these concerns because they are incomparable. However, these inter-disciplinary tradeoffs are often the ones that have the most impact on the product/system. The complexity of the tradeoff decision changes depending on the subsystem being addressed_the larger the scope, the more complicated the decision. Tradeoffs made at the component (product) design level can be very straightforward. System- level tradeoffs can be more complicated because all of the composing products/systems must be considered. There are also tradeoff decisions made at the enterprise level that take into account the non-technical factors (e.g., social, legal, way of doing business). These tradeoff activities are not independent and are highly influenced by each other. An enterprise tradeoff decision is likely to influence the tradeoff decision made in the system and therefore in the design of the components of the system. The group discussed possible metrics for a decision-maker to use when deciding on how much assurance should be included in a given product/system. The classic decision factor has been provided to the decision-maker by the assurance levels enumerated in the TCSEC and the companion Yellow Book. These prescribed levels have proven to be inadequate for many decision-makers because they do not take cost into consideration. A member of the group suggested that assurance cost as a percentage of development cost may be a good tradeoff metric. The group decided that this could be one useful tradeoff, but did not consider several important factors. It is difficult to measure development cost because life-cycle costs are often open ended. Also, the group felt that the value of the information protected needed to be taken into consideration_a small, relatively inexpensive component that performs a crucial function may need considerably more assurance, as a percentage of development cost, than a large multipurpose system. The problem with adding information value into the tradeoff discussion is that the value of information is difficult to ascertain. An enterprise would need to determine the value of its information for both the enterprise and for its adversaries. In some circumstances, a value cannot be placed on information (e.g., loss of life, enterprise survival). This complicates the quantification further. In the end, it was decided that the determination of information value will always have a subjective component. Although it is a factor in considering tradeoffs against assurance cost, it cannot be relied upon as the sole factor. 3.6 WHO (E.G., POLICY MAKERS, VENDORS, APPLICATION DEVELOPERS, ACCREDITORS) SHOULD MAKE TRADEOFF DECISIONS? The group agreed that the trend for the assurance tradeoff decision-makers is moving away from policy makers and toward developers and system enterprises. While the TCSEC promotes a fixed set of tradeoff options embodied in the criteria assurance levels, most systems require further assurance decisions based on the specific needs of their application. To evaluate assurance tradeoffs, it is necessary to recognize the role of an organization's "risk-taker". This authority is the member of the enterprise who has the responsibility for deciding the level of acceptable security risk that is appropriate for system installations. The risk-taker makes primarily political and operational management decisions based on the enterprise goals and the perceived threat environment. Security assurance documentation is the principal technical information supplied to the risk-taker. Those people providing the security assurance analysis have the responsibility to supply to the risk-taker with the most complete and accurate assessment possible. However, this information, which will be highly technical, may not be in a form easily understood by the risk-taker. Assurance documentation must be packaged to define overall assurance in the best form possible to help risk-takers do their job. High-level managerial decisions that are based on complex technical rationale can be difficult to formulate. The documentation must discuss alternatives in a form so that the risk-taker can clearly see possible tradeoffs. One approach to support tradeoff decisions is to provide a set of security questions for the risk-taker to consider. If the risk-taker is satisfied that the answers to the questions sufficiently address the enterprise security goals, then the risk-taker has a basis for making a decision. In this manner, security is driven primarily by the system procurement authority and program manager rather than by product developers. 3.7 CONCLUSIONS Participants in this session discussed a wide variety of topics related to security assurance tradeoffs. In general, the group appeared to reach consensus on the current state of security assurance tradeoffs as well as directions for future investigation. The group felt that application assurance has received too little emphasis in the past, and it should receive more. The assurance effort must be balanced for any system based on the perceived system risk. There is no single uniform approach to providing assurance that will satisfy all kinds of system applications. To support a balanced approach, assurance arguments should be assembled from a set of system building blocks. Concepts of system composition and integration should allow the assurance analysis to be tailored to specific user requirements. Models of product, system, and enterprise tradeoffs should be used to help identify the levels of tradeoff decision-making. Finally, the group recognized the role of the "risk-taker" as the decision-maker of enterprise security tradeoffs, and advocated that assurance evidence should be packaged to provide the best support to the tradeoff process. SECTION 4 PEDIGREE Deb Campbell, Moderator Pat Toth, Recorder 4.1 INTRODUCTION As presented in one of the submitted papers, pedigree suggests a method to determine the acceptability of evidence based on the identity of the creators of that evidence. Pedigree may be based on an individual's identity or on the organization that produced the evidence. The goal of this session was to articulate the pertinent questions and identify the issues pertaining to pedigree. The sessions began by highlighting some of the main points of the submitted papers as a means of stimulating ideas and discussion. The main points as presented were the following: y Where evidence of assurance is not suitable for being reused or being validated, the pedigree of the evidence can be used as a surrogate. y The acceptance of a checklist instead of the evidence itself is essentially the reuse of evidence by the acceptance of its pedigree. y An accreditor might accept the pedigree of the certifier and use the associated report as the primary basis for the accreditation decision. (Additionally, the challenge was posed that if the accreditor bases the decision on pedigree of certifier, was the report even necessary?) y The practice of accepting evidence based on pedigrees will lead to islands of trust. y Evidence with a weak pedigree could/would/should be subjected to more scrutiny. y A pedigree may derive from the tools used. y Most users make the mistake of narrowly basing their judgments on personal experiences. For example: - If they know and trust product developers, the process the developer follows is less important. - If they know and do not trust the developers, no process will convince them that the developer's product is of high quality. - Logically, it follows that they might trust developers they do not know as long as the developers have name recognition. 4.2 ISSUES ASSOCIATED WITH PEDIGREE The introductory period was followed by a brainstorming exercise among the eleven session participants. Each idea was recorded and later organized into groups of issues based on the natural relationships between each issue1. The groups of issues provided below are the initial result of the session. Due to time constraints, only minimal sanity checks were made to determine if all issues were correctly grouped or if other relevant issues were missing. 4.2.1 What Is A Pedigree? y Confidence can be based on tools, people, and organizations. How can they be balanced? Does one weigh off more than another? y How do you apply pedigree to an unknown entity? y How is a pedigree established? Can a new company gain a pedigree by hiring a consultant with an established pedigree? y Maybe the pedigree concept is misnamed and should be called credentials. Credentials has an updating connotation to it, rather than a birthright which pedigree implies. y Should pedigree provide assurance based on what you have done in the past, as opposed to what you are currently doing? Once a pedigree is established, how long is it valid without being updated? y Should pedigrees be multidimensional and not oversimplified? That is, a simple one word label for a pedigree may not convey enough information to be useful. y A pedigree can be thought of as an integrity label. However, to be useful, must pedigrees be considered in a broader context? 4.2.2 Applicability y For which qualities of a system or product is pedigree a useful measure (e.g., correctness, effectiveness, reliability, workmanship)? y Is it agreed that pedigree makes a difference based on roles (e.g., accreditor, developer, security engineer, integrator, certifier, criteria writer, evaluator, profiler, user)? y Can pedigree be extended to a tool or is it limited to individuals and/or organizations? y What does pedigree buy me? What evidence can I waive if I have pedigree? Do I need to provide more or less evidence based on a positive, nonexistent, or negative pedigree? y How does pedigree feed into assurance? y What is the relationship among effectiveness, correctness, and pedigree? y Can pedigree and criteria be viewed as opposites? Criteria in some cases may be viewed as overriding pedigree and in other cases there may not be a conflict. Perhaps criteria are not necessary. y Does a pedigree have coattails? Is pedigree extendable? Is pedigree applicable across all products made by developer? 4.2.3 Individual Pedigree y Should we be skeptical of individual pedigrees? Loyalty to your company may be an overriding factor. Individuals may be stifled due to loyalty to the company or organization. y Should we decide to read something or not depending on who the author is? y What is the importance of your personal knowledge/trust of people by name? y What is the importance of people to the organization's pedigree? If a person leaves a company, does the trust level go down unless an "equally known and respected" person replaces him/her? y What are the elements of an individual pedigree, such as knowledge, training, and precedent? 4.2.4 Organizational Pedigree y Why are we skeptical of organizational pedigrees? If pedigree is associated with too large an organization, it may lose meaning. If worldwide conglomerate XXX has a pedigree, does every division carry that same pedigree or should the pedigree be limited to divisions? y What is the importance of people to the organization's pedigree? If a person leaves a company, does the trust level go down unless an "equally known and respected" person replaces him/her? y What is the level of granularity of pedigree associated with organization. y How do small companies develop a pedigree? y What is the difference/similarity between individual versus organizational pedigrees? 4.2.5 Measurements y How can we collect security cost data? y Can regression analysis be used to establish risk? y Who decides what the standards are for pedigree? Who selects the judges? y Should there be a licensing requirement for pedigrees as in other professions, such as certified public accountants, doctors, or lawyers? This topic also raises the issue of liability. y How should we institutionalize the process for evaluating pedigrees? Should the process be institutionalized? 4.2.6 Enforcement y Are individuals/organizations true to their pedigree? How do you know if the process is followed correctly once the pedigree has been established? y Can you regain a lost pedigree? y What is the liability of a pedigree? y Pedigree is not a one-time stamp, so what elements do you re-evaluate? y How do I protect my interest against a company with a pedigree? 4.2.7 Usefulness y How do we capture what an individual or an organization has learned during the process? y Should we give the "edge" to new products? What should be the balance to pedigree and innovation? Magazine reviews always tend to favor the newer, slicker products. y What are the ramifications of "buying" based on pedigree? y Are pedigrees useful for high-assurance systems? Or should they be limited to low-assurance systems? y Is pedigree applicable for all products? y Is there anything you can rely on except pedigree for legacy systems? y Regarding networks of trust, if a trusts b and b trusts c, should a trust c? 4.2.8 Aggregation y If we have a large system and a large number of people working on it with individual pedigrees at various levels, what is the pedigree associated with the system? y Does a pedigree associated with a system change during the life cycle of that system? If the developer had a high pedigree but the integrator had a low pedigree, what is the pedigree of the system? y How do we determine pedigrees on components of systems? What are the rules of composition for pedigrees? y If you have a strong pedigree early in the process, do you need a strong pedigree late in the process? Conversely, if you have a weak pedigree early in the process, do you need a strong pedigree late in the process? This is a certification problem. 4.3 CONCLUSIONS The session concluded with a discussion that focused on several key issues, listed below. 4.3.1 Terminology One must be careful when introducing a new term, such as pedigree. The term itself may project a meaning that may or may not accurately reflect the intended concept. It is critical that the corresponding concept be thoroughly explored and the terminology match the intended meaning. This workshop allowed participants to delve into this concept in great detail. As a result, it become evident that pedigree, although used almost exclusively in this session, is not the best term to capture the intended concept. The dictionary definition of pedigree is a line of ancestors; lineage. This infers a birthright that is clearly not intended. An alternate term suggested was credentials. (A dictionary definition of credentials is (1) that which entitles one to confidence, credit, or authority; or (2) evidence or testimonials attesting to one's right to credit, confidence, or authority.) Although the group did not reach a consensus during the session to adopt the term credentials in lieu of pedigree, it was felt that a term such as credentials was probably more appropriate for conveying the intended concept. 4.3.2 Categorizing The concept of grouping pedigree or credentials into three categories based on roles of the individual/organization was introduced. Earlier in the brainstorming exercise, it was suggested that this concept could apply the same or differently depending upon the role of the individual or organization (See Section 4.2.2). It was initially proposed that perhaps three categories (builders, evaluators, and, approvers) would be sufficient. It was also suggested that possibly the latter two could be combined into one category, leaving just two high-level categories for consideration. No conclusion was reached; further efforts in examining this proposed concept would be necessary, especially if a formal credentials process were implemented. 4.3.3 Formal versus Informal Implementations Many of the issues discussed in the later half of the session focused on issues that can be grouped under the major heading of whether the issue of pedigree versus credentials should be formalized within the IT security community. This concept is clearly not new nor is it limited to security. It is something we have in everyday life, both formally (e.g., certified public accountants, doctors, lawyers) and informally (e.g., make of car you chose, the dealer you bought it from), or even somewhere in between (e.g., doctor referral service, consumer reports). Whether formalized or not, this concept is a channel of information that is currently used, albeit on a more informal basis. We listen to those we have come to trust; many do buy products/systems based on who was the developer or integrator, for example. Many correlations can be drawn to other professional occupations. However, differences do exist. One example cited during the discussion was the construction of a bridge. Clearly, the engineers have received formal training and are licensed. However, strict, measurable requirements for the actual construction also exist. In the area of IT security, similar requirements are not so easily identified. Formalizing the process of obtaining credentials of an IT security professional raises numerous corresponding issues. Is it worth the effort for an individual/organization to obtain formal credentials if they are not able to make a tradeoff for something else; (i.e., not having to produce as much evidence as the individual/organization who does not have formal credentials)? Liability concerns are an equally important issue. Much insight could be gained in identifying other significant issues from further comparisons to other occupations that currently have a formal process for obtaining credentials as well as those that do not. SECTION 5 SECURITY ARCHITECTURE AND APPLICATIONS Judy Froscher, Moderator Jay Kahn, Recorder "Our paradigm for managing information security must shift from developing security for each individual application, system, and network to developing security for subscribers within the worldwide utility." Joint Security Commission Report, 1 March 1994 5.1 INTRODUCTION The twofold purpose of this session was to identify the opportunities for managing information security for "subscribers within the worldwide utility" and to discuss how architecture contributes to system assurance. The starting point for this session was the report of the JSC, Redefining Security (JSC, 1994). While not endorsing or even considering every finding in this report, the session participants agreed that the report provided challenging objectives and should be used as a source of provocative ideas. Chapter 8 of the JSC report, "Information Systems Security," clearly identifies networking and distributed systems as essential to tomorrow's architecture. Further, the report notes that as a nation, we can no longer afford to develop unique solutions to what appear to be standard problems. The moderator identified the following three security challenges from the JSC report, which were used as long-term national goals during the workshop discussion: y Encourage distributed architectures. y Discourage stovepipe2 solutions. y Discourage multilevel secure (MLS) stovepipe systems. With this introduction, the following five questions were used as discussion points for this session: y Is understanding and implementing security in distributed systems less achievable or just more difficult? How does distribution increase complexity? y Are we focused too much on operating system (OS) security? Do we need trusted applications? y How can security architectures ease assurance arguments? y Can some security architectures allow integration of new technologies, support more secure use of legacy systems, and promote assurance? y Can different security architectures allow users more effective access to their data? While these goals and questions framed the security architecture and applications discussion, most session participants had not considered how security in the large could be achieved. Hence, much of the discussion centered on understanding requirements and how emerging technologies could support security in a worldwide, distributed computing environment. Most participants were much more at ease in postulating security solutions for dedicated applications or for small confederations of simple, homogeneous systems, to which more conventional MLS approaches are applicable. Security architectures that could promote the management and protection of information in a worldwide information infrastructure proved too much of a paradigm shift for this forum. The group reached a consensus definition of security architecture. A security architecture is the structure of protection mechanisms that allow the enforcement of a security policy. Security architectures are not unique. The same security policy can be enforced using different security architectures. That is we can rely on different compositions of mechanisms to enforce the same policy. Our goal is to define security architectures that promote the enforcement of a security policy and make the assurance argument as straightforward and simple as possible. Security architectures can ease the assurance argument by explicitly identifying the role of different parts of a system in enforcing a security policy, identifying dependencies among different parts of the protection mechanisms, and allowing focused assurance strategies for each security-relevant part of the system. Security architectures allow us to compose systems to enforce a policy that governs the security behavior of the combined systems. 5.2 NEW TECHNOLOGIES IN DISTRIBUTED COMPUTING Two current technologies that could support distributed architectures were highlighted. The first of these technologies involves Object Oriented (OO) development paradigms, as manifested in OO designs, OO data management systems, and OO programming languages. There is a subtle difference between OO design and development methodologies and actual OO systems. The blurring of this distinction is quite confusing. While it is unclear at this time what are the consequences of embedding security attributes within objects, the highly dynamic nature of linking and re-linking of objects is a cause for security concern. This dynamic linking and re- linking of objects is quite different from traditional systems in which security architectures and policies can be regarded as static. What supporting security mechanisms will be required to interface with the object's embedded security parameters is an unresolved question. The entire success of OO technology itself is open to question. Other similarly promising technologies have emerged in the past without having significant long-term effects on automatic data processing (ADP) development. The security implications of OO technology are currently under investigation in several R&D efforts, but the efforts are too immature to predict any results. The second technology addresses client-server systems. Client- server technology has already captured a significant portion of the ADP market. This technology has the commercial advantage of being cost-effective in replacing aging mainframe systems. From a security perspective, client-server technology will introduce difficulty as it will require parts of the security policy to be enforced in different, sometimes heterogeneous, hosts. However, a consistent access control policy can be used to manage data access servers, while complex applications with application-specific and user-specific interfaces can run on powerful client processors. Perhaps if these applications transmit information at only one security level, clients can operate without trust from a confidentiality standpoint. However, accommodating policies of assured delivery, non- repudiation, separation of roles, or availability will increase difficulty. The employment of widely used, commercially available application software can reduce the risk of integrity vulnerabilities. The seemingly unmanageable interactions among clients and servers can be controlled through transaction management, which can guarantee that many of the integrity concerns that have been discussed in this session do not result in chaos and unpredictability. The goal of this workshop session was not to solve all of the security problems inherent in either of these two emerging technologies, but rather to recognize that any evolving security development will have to function in either or both of these technological environments. 5.3 IS UNDERSTANDING AND IMPLEMENTING SECURITY IN LARGER DISTRIBUTED SYSTEMS LESS ACHIEVABLE? 5.3.1 Policy Issues We observed an expanding need to have policies other than confidentiality. These include polices for integrity, availability, and anonymity. We need to have some attributes that characterize both users and data, and that can be used to make decisions about accesses between them. The semantics of these attributes and the attendant accesses depend on specific security policy objectives. As our computing environment evolves toward a distributed one, it appears that it will become more difficult to assume single, uniform policy coverage. Distributed systems will require multiple security policies and enforcement in multiple domains. These policies will have to be enforced within the system's primary domain, and be applicable, or at least not violated, while in other domains. This multidomain, multipolicy environment will lead to the development of metapolicies that tell us how to make policies. The concept of metapolicies introduces complexities that are not scalable from the current environment. This concept also provides initial evidence that security for distributed systems will be a much more difficult problem than found in a traditional single system TCSEC environment. Once metapolicies are introduced, the follow-up question must be "Where are decisions made?" We identified three possible answers: y At the developer's facility y By the system manager when the system is loaded and configured y Dynamically as necessary If decisions are made dynamically, it appears that artificial intelligence engines may be required to provide automated capabilities exceeding the level of sophistication available today. However, if decisions can be pre-determined, security solutions become possible. Again, the complexity inherent in implementing a security policy that can be tailored at the site also increases the difficulty of providing a distributed security implementation. It has been recognized that there are problems remaining with creating rather simple security policies. Policy-makers desire clear, concise rules. If rules can be defined that are appropriate in every contingency, then the policy-maker has succeeded. However, sometimes policy is only a mechanism in disguise. Policies are rarely complete or concise, nor are they always applicable. When we create security policies, we document and circulate them believing that the policy statements reflect a pragmatic approach for doing business. As long as the users are able to perform their jobs without feeling hindered, frustrated, at risk, or foolish, they nearly always adhere to the policy. However, if users feel that policy interferes with the mission, generally it is the policy that is discarded rather than the mission. Examples of user resistance include the work-to-rule industrial action, the unauthorized sharing of restricted data, or the undocumented disregard for policy. The conversation described above highlights the issue that we use an imprecise medium, the English language, to document policy statements. The policy that we write reflects the way we want things to operate, and it may be self-contradictory, incomplete, or ambiguous. Further, the policy description defines expectations of how we think we would like the policy to be. A systemic review, such as one conducted as part of a reengineering review, might lead to a different statement of the security policy. Security policy, like most policies, is often expounded by upper management. These policy statements are interpreted by middle management as rules to be implemented, while conforming to and often preserving the existing middle-management corporate view. This understanding of how policy is made and implemented raises the following question: Is there really a difference between high-level statements about desirable goals and security policy rules? There are concerns in that these differences can be important, that we are striving for nebulous goals instead of crisp, clear policies, and that there is no ideal methodology for separating the two concerns. Ultimately, the issue is one of control: Who, then, is right, the management or the system's designers? To implement high-level policy for an actual system, the system designer must first decide which enforcement mechanisms must be automated and which will be enforced procedurally or by trusting personnel. to behave ethically. These decisions must be consistent with policy enforcement throughout a distributed confederation of autonomous, heterogeneous systems. The challenge is to make design and policy decisions that promote lower risk solutions. 5.3.2 Access Issues While access determinations eventually evolve into binary decisions, to make these determinations when multiple policies are in effect, it may be necessary to use new kinds of mechanisms. A candidate mechanism is fuzzy logic3. It was noted that fuzzy logic is widely used today in real situations, but the fuzzy logic processor is a human being. Implicit in this discussion is the realization that users need complex security access rules involving factors such as day of the week, time of day, the user's physical location, and the user's role. 5.3.3 Scalability Issues The issue of increasing complexity with increased scale is subjective. However, it appears that as we look at scaling up from a centralized system to a distributed system or system of systems, it may be easier to implement some security mechanisms because physical separation can provide some enforcement. However, this enforcement is not sufficient for a complete security policy. Distribution appears to add risk, which increases complexity and is not scalable. In general, increased scale brings increased risk. It was noted that TCB techniques do not seem to scale upward. Meeting applications assurance requirements become too expensive, so we need new assurance techniques that can handle aggregates of distributed data. To find these new mechanisms, we must consider whether access mediation is imposed at the correct level in an architecture. In scaling up for size and complexity, we may need to place protection mechanisms at different levels and apply additional protection mechanisms once a coarse access mediation decision has been taken. Another possible solution is to increase the security perimeter. This topic is discussed as part of the question addressed in Section 5.4. However, we are beginning to recognize that we cannot afford distributed TCSEC solutions, so we must begin to look at other approaches. 5.4 ARE WE FOCUSED TOO MUCH ON OPERATING SYSTEM SECURITY? DO WE NEED TRUSTED APPLICATIONS? 5.4.1 Focus on the Operating System Distributed systems have fundamental problems with some of the features that are required by the TCSEC, for example, trusted path. The communications protocols in use today do not support these kinds of features. On the other hand, no product TCB is free of covert channels, although some products now coming on the market claim this distinction. Covert channels have been found in all products having a TCB, even high-assurance products. Covert channels introduce a vulnerability that can be exploited to violate the security policy. Whether to guard against the exploitation of this vulnerability for a given environment is a risk management decision. However, when we move to a distributed computing environment, covert channel vulnerability offers a much richer opportunity with a lower probability of detection for gaining unauthorized access to sensitive information. Access to real threat information can perhaps provide pragmatic guidance for the real risk that covert channel vulnerability poses for the compromise of sensitive information. Work is being done in maintaining security across multiple domains. European Computer Manufacturers Association (ECMA) Standard ECMA-138 (ECMA, 1989), which addresses the propagation of security policies across domains, was suggested as a useful reference document. With these types of problems in mind, it became obvious that we need to find ways to make security architectures work for and not against us. Distribution adds both difficulty and complexity to the security problem. As noted previously, we must be able to enforce security policies such as integrity, availability, and safety as well as the traditional policies of confidentiality. Using the security infrastructure commercially available today as a consequence of National Security Agency (NSA) support for evaluated security products, it has not yet become practical to construct a modular architecture from the building blocks provided by these evaluated security products. An architectural methodology would permit the development and combination of these logical building blocks to support all of these security policies, as well as the support of distributed functionality. New security paradigms must provide services that support enforcement of these policies. These services are the logical building blocks just mentioned. Examples of these services include data abstraction, layered security services, and refinement support. These services were applied to the THETA system (McEnerney, et al., 1990). Data abstraction is an important software engineering technique for developing quality modular software. It allows assurance claims to be made that trusted software has a limited impact and hence does not violate the system security policy. It can be used to demonstrate domain isolation and show if new covert channels have been introduced. Data abstraction can also be used to enforce fine-grained access control policies with richer access semantics. Making security services available to trusted applications when they are needed can be far more effective than providing the service as part of a centralized TCB. These security services can be designed, implemented, evaluated, and stored in a repository. A trusted application uses only those services needed for the application. Examples of these layered security services include mandatory access control (MAC) checks, audit, trusted path, and scheduling. Refinement support to some extent depends on data abstraction and the availability of layered security services. A trusted application may require a finer grained access control mechanism that can be enforced using data abstraction and a MAC check. The assurance argument is facilitated by demonstrating that the application code satisfies the conventions of the layered security services it uses, and that the code enforces the application-specific security policy. 5.4.2 Trust in Applications We can gain assurance about security policies other than confidentiality if we trust some applications. By extending trust in selected applications, we gain enough assurance to permit the use of lower assurance systems in environments where other guidance, such as the Yellow Books, may establish a requirement for higher assurance systems. We gain this assurance in the following way. Some security enforcement mechanisms can be implemented in trusted applications. If we place a few restraints on those applications, we can have assurance that this trust is warranted. The primary restriction is that the application must be trusted not to behave maliciously. We must have assurance that trusted applications do not exploit covert channels, subvert accountability mechanisms, or corrupt information that is processed by the application. These trusted applications become extensions of the TCB. In turn, the TCB must ensure that these applications are not bypassed, are tamperproof, and must provide a trusted path from the application to the user. There are several proposed methods for gaining assurance that an application is not malicious. One method advocated by John McDermid is a trilateral plan for using professional people, code inspection and analysis, and testing (McDermid, 1991). Others advocate gaining assurance through the pedigree of the investigator, his/her organizational allegiance, or the reputation of the tools used to examine the software. Pedigree was addressed as a separate workshop topic (see Section 4). By gaining assurance in this way, even medium-assurance TCBs with trusted applications can be used in place of high-assurance systems. Although some distributed system examples were presented, most of the discussion focused on trusted applications running on special-purpose OSs and the sometimes contradictory nature of policy objectives from different security domains. Issues of securely sharing information among autonomous systems, the atomicity of user-generated transactions, the secure handling of congestion among trusted systems, the proliferation of covert channels, and secure recovery in a distributed subscriber information infrastructure environment were not discussed at length, but remain important topics for further investigation. 5.5 HOW CAN SECURITY ARCHITECTURES EASE ASSURANCE ARGUMENTS? While this question was not explicitly discussed, it was recognized that part of the response to the question addressed in Section 5.4 included this subject. Additionally, if we can separate the assurance problem into smaller, more manageable components, we can reason about these components with more confidence. Defining rules for composing the assurance for these components into assurance for the larger whole is an area of ongoing research. System- or infrastructure-level refinement techniques for allocating requirements as well as assurance objectives also requires further investigation. Some efforts in DOD address assurance by certification and accreditation of the information infrastructure. The common approach is to define a flexible security architecture that allows individual systems to connect in well-defined ways and constrains the risk and the role that a given system plays within the infrastructure. By defining connection rules, a system's security posture can be protected against perturbations elsewhere in the infrastructure. Only when a system's own security configuration changes does the security posture of the system itself need to be reassessed. This approach makes security management tractable from the system perspective. However, deriving a security architecture in the large, and reasoning about its assurance and protection effectiveness remains a problem for future investigation. 5.6 CAN SOME SECURITY ARCHITECTURES ALLOW INTEGRATION OF NEW TECHNOLOGIES, SUPPORT MORE SECURE USE OF LEGACY SYSTEMS, AND PROMOTE ASSURANCE? 5.6.1 New Technologies and Legacy Systems In light of the current migration away from legacy mainframe systems toward distributed computing environments, legacy systems require some special consideration. This migration will occur slowly because resources are not readily available. The Naval Research Laboratory (NRL) has used physical separation, distribution, and replication with a high- assurance product in a prototype system called the Secure Information Through Replicated Architecture (SINTRA) project. A trusted front end mediates access between users logged in at different security levels to databases at their respective login level. Each database contains information appropriate to the login level as well as copies of all lower level information. Users can retrieve information with high assurance and little security overhead. However, when a user updates a low-level database, the update must be securely and consistently propagated to all higher level backend databases. Most of the research effort for the SINTRA project has been focused on the development of a correct replica-control algorithm for the consistent replication of data, while providing secure, concurrent access to users operating at different levels. Several such algorithms were developed as part of this effort. The algorithm currently implemented is untrusted, and it does not require changes to the commercial database management system running on back end processors. A proof-of-concept prototype has been implemented and demonstrated that high assurance and good performance are not mutually exclusive. This pragmatic approach to security offers strong security protection, high assurance, good performance, full relational database capabilities, and the ability to incorporate new American National Standards Institute (ANSI) Structured Query Language (SQL) compliant technology. If we can define what a transaction does in a legacy system and what an update implies, the replicated architecture approach can support high- assurance distribution of legacy systems. Likewise, this approach can be used to provide an MLS capability for new technologies such as object-oriented databases, extended relational databases, and expert systems. In a similar spirit, other pragmatic security mechanisms can be used. In addition to enforcing a confidentiality policy, some form of cryptographic checksum can be used to ensure that information has not been inadvertently or maliciously changed. Intrusion-tolerant mechanisms can be used to thwart the efforts of an intruder and to increase the work factor needed for gaining access to sensitive information. This is an attractive approach for protecting databases against unauthorized access. 5.6.2 Administration of Distributed Security The discussion addressed the administration of distributed systems. The example was the AEGIS system. In this distributed system, processes can be started on a given hardware platform but can be moved to other platforms to maintain system availability. In this example system, the security policy enforcement mechanisms must also move from platform to platform in a transparent but highly dynamic manner. This physical separation and mobile security enforcement introduce new security problems. It is worth noting that on a different level, the management of security across distributed hardware becomes significantly more complex than for a traditional single-processor system. Besides complex issues of synchronizing user names and passwords, hardware-naming conventions, and coordinating audit on-and-off switches, there are major problems with the collection and analysis of audit information. Today's commercial off-the-shelf (COTS) tools meet very few of these security needs. One aspect of distributed system security that has not received much study is that of multiple identities. Each of us has several identities. These identities might include: y Joe Sixpack, a commercial network customer y Joe, a government employee using the Internet at work y Joe, the office computer-system's database administrator y Joe, the Parent Teachers Association volunteer at the local school tutoring students in computer skills For each of these roles, Joe might have a different user name and password. The capability for Joe to access his own files, regardless of his active Internet identity, is problematic. The most straightforward solution is for Joe's access to be determined based on the role for which he is currently authorized. A metapolicy may require that only one role at a time must be active, although this requirement could be very difficult to enforce. This requirement would prevent the following violation of the least privilege policy: in an extreme case, Joe could attempt to satisfy a two-man rule and being both of the required people by simultaneously using two of his user names. Writing a security policy that covers this situation is extremely difficult. Implementing it could be even more difficult. The challenge is to create such a security policy without embedding a solution into the architecture or building a solution into the criteria. These problems illustrate the complexity and conflicts that can arise in the enforcement of multiple policies. 5.7 CAN DIFFERENT SECURITY ARCHITECTURES ALLOW USERS MORE EFFECTIVE ACCESS TO THEIR DATA? Due to time constraints, this question was not addressed. 5.8 CONCLUSIONS It was agreed that there is a need to go beyond the TCSEC because this document is not based on the right questions for the new computing world of today. Solutions must be based on understanding the damage that could result from compromise, including confidentiality, availability, integrity, and authenticity compromises; the threats that could cause compromise; and the countermeasures that are effective in protecting data against these threats. We previously asked "How do we identify the new rules and criteria? Do we allow customer agencies to set their own requirements?" Protection profiles can be used to describe the needs of a particular industry or industry segment. However, there is a pressing need for at least a few of these industry segments to create protection profiles. The first published profiles will greatly contribute to the understanding of user security needs in a distributed environment and to preliminary determinations of which functions need automation. Recalling our original challenges as stated in the JSC Report, it is essential that the information security (INFOSEC) community must begin to study these problems from the subscriber's point of view. The subscriber will access information from a vast collection of heterogeneous data sources. As our dependence on increasingly greater amounts and varieties of information grows, our ability to manage, manipulate, and protect information becomes more critical. We must be able to ensure that changes made to related information result in consistent information and that consistency is preserved even when some components fail. These observations lead us to conclude that the effects of a subscriber's input request, or transaction, either become permanent within the distributed computing environment or that no effects of the transaction persist. Hence, the transaction becomes the control abstraction for a distributed computing environment. This concept enables us to build upon the INFOSEC infrastructure and discipline that have been developed over the past two decades. Security decisions must be made that ease the transaction management problem for distributed, heterogeneous information sources. If a subscriber's access must be mediated over some collection of MLS stovepipe application systems, we must impose MLS and application-specific constraints on an already difficult transaction management problem. The challenge for the INFOSEC community is to initiate investigations that lead to a better appreciation of distributed computing environment problems and to provide guidance that makes solutions in the large more possible. We must appreciate that the transition to a subscriber- information infrastructure computing environment presents as many opportunities as challenges for INFOSEC solutions. Stovepipe MLS solutions have focused on constraints and restrictions. Application of security measures in the large can provide authorized users with secure, reliable access to all the information they need to do their jobs. SECTION 6 PROCESS Joel Sachs, Moderator Caralyn Wichers, Recorder 6.1 INTRODUCTION Background information is presented to both aid in understanding and to provide some context. This information is based on the moderator's presentation. Process was defined as the set of practices, methods, and transformations that integrate managers and engineers in using technology to attain an end-result. The fundamental challenge to organizations today is to develop quality results, both reliably and predictably. Key leverage points are people, technology, and process. Unfortunately, the role of process has been given minimal attention to date. The session discussed the fact that many interrelated processes exist today; these may be formally stated or conducted in default. Major process areas include: acquisition, integration, development, product evaluation, system certification, and system accreditation. The names for these process areas may differ among the military, civil government, and private sectors, but the basic notions are universally applicable. DOD-oriented terms are used throughout this section. Specialty processes relate to specific disciplines such as systems engineering, software engineering, hardware engineering, test engineering, security engineering and its associated process, operating systems, and accepting risks. Some disciplines cut across the major process and as a result, one can view either a specialty process within a major process or one that branches across them. While a single integrated process sounds attractive, it most likely would be too complex, too high-level, and ineffective. Managing multiple processes in concert is the challenge of concurrent engineering management today. Processes can be thought of as branching across or constrained within life-cycle phases. Regardless of development approach, system/product projects go through concept definition, design, implementation, and testing in some form or another. Today several development approaches are in use or under consideration. These include evolutionary acquisition, incremental build, prototyping, and "classic" waterfall. Equally important is considering whether a system/product is built from scratch, re-engineered, integrated from 100% COTS, or integrated with developed applications. The term process can connote many different things, including: process definition, process description, process (activity) prescription, process practice, process enactment, process improvement, and process measurements. Directly related to the process measurement is capability assessment and capability models to perform such assessments. 6.2 MAIN CONCEPTS DISCUSSED 6.2.1 Why Focus on Process There are a number of reasons to emphasize process today. We observe that systems and products apparently will continue to increase in size and complexity. In addition, they will transition through various versions and releases, most likely more rapidly. Their use, environment, and re-use will evolve. Single entity systems will become more a part of an infrastructure, which will become more a part of a National Information Infrastructure (NII) or Defense Information Infrastructure, which become more a part of a Global Information Infrastructure. Such demands and timeliness will necessitate more reliance on the actual engineering of the products and systems that comprise these and, in particular, a need for reliable security engineering to be conducted constantly. Process improvement and assurance are critical to such a need and perhaps the only feasible solution. Focus on process focus introduces the possibility for scalability, knowledge evolution, and improvement. Such focus will help predict and guarantee predictable outcomes, trends, and characteristics. In addition, it will concentrate investments to enhance and perform quality and effective security engineering. 6.2.2 Reliance on Process One part of the discussion focused on the relationship between the process and the amount of assurance provided by a system/product. An interesting point was realized in asking the question: To which process are we referring? Some said the process for building something, whereas others mentioned the process for assessing something. The process for operating the system/product may also support the ability to determine assurance. These may be fundamentally different assurances or may be different ingredients to a single notion of assurance. Before one can agree on a uniform process for determining an appropriate amount of desired assurance and the ability to measure assurance, a common dictionary for customers to use is really necessary so everyone can communicate effectively and consistently. We need to specify what is desired, not how it is implemented. Another part of the discussion focused the benefits in using a uniform process. Uniformity, both within an organization and across organizations, provides some increased confidence that a particular process is employed properly. Moreover, uniformity in process may lead to improved evidence. The following additional points/questions were made regarding uniform process and reliance on process: y Running a set of conformance tests do not adequately assure a system/product as testing cannot be complete or comprehensive, hence process must address more than just testing. y There is a difference between the individuals or organization qualifications to certify/evaluate versus responsibility for certifying/evaluating. y While a process is being followed uniformly, there will be pressures to deviate from it, for example from the accreditor, PMO, integration PM, etc., findings will need to account for adjustments in the process. y To what extent should a security knowledgeable individual be involved in the process in order to be able to address the security issues? y How can we ensure that the evidence will provide assurance when needed during the process? y How can tools help? 6.2.3 Measurement and Assurance of Process Documenting a process is an insufficient way to conclude that the process is followed. It is not only critical to know that a process is being followed, but also to know how well is it followed and how sophisticated is it. Hence, there is a need to measure and assess the quality and degree of process adherence within an organization. Three major security-related processes and their execution: y The engineering process defines the security requirements, develops a security architecture and design, conducts security testing, and collects and presents evidence about the system/product (usually executed by the engineering organization, typically a system integrator/developer or product (vendor engineering group). y The assessment process examines the evidence on the system/product and the activities of the engineering organization (usually executed by a system certification or product evaluation organization). y The accreditation process accepts and approves the operational risks associated with the use of a system and its inherent weaknesses (usually executed by the accreditor). One process model discussed was the Security Engineering Capability Maturity Model (SE CMM). This model focuses on the development engineering activities which are security specific and their interface to other areas, e.g., evaluation, certification, acquisition, and quality assurance. It views security engineering as an engineering discipline conducted concurrently with other disciplines, e.g., systems engineering, software engineering, hardware engineering, and test engineering. The overall result is confidence in the organization's process and their adherence to it. The following additional points/questions were made regarding measurement and assurance of the process: y What minimal things do you need to do to make sure the process is applied and followed? y With what initial set of things does a security engineering process need to start, e.g., threats, risks, mainstream vulnerabilities, etc.? y Process, technology and people will change. y How does a risk manager/taker rely on process assurance? y How should other key processes be addressed, e.g., product evaluation, system certification, system accreditation, system acquisition? 6.2.4 Understanding Assurance and Its Ingredients An assurance taxonomy was introduced to aid in discussing and understanding assurance. The elements of the taxonomy are: the target, the method, and the benefit of the assurance. The target needs to be considered both in terms of the explicit (immediate) target and the (ultimate) end target. Three aspects are important regarding method, namely the production method, the assessment method, and the results representation. Benefit needs to be thought of relative to direct benefit and indirect benefit. Various aspects of assurance were discussed throughout the session. These included seeing assurance in terms of attributes, degrees, and ingredients. The attributes discussed covered correctness (strength of mechanism and quality of their implementation), effectiveness (how well mechanisms do their job), workmanship (quality of development and overall quality of end result), and usability. The possibility for other attributes was acknowledged. Concerning degree of assurance, it is necessary to recognize that assurance is a continuum. Potential ingredients to establishing degree of assurance could include functionality and engineering, quality control, and assessor process and evidence. Many of the elements of the taxonomy can be seen as independent of each other. However, it was clear from the discussions that the real interrelationships of them is unknown. Moreover, how to establish and express the type and degree of assurance needed is not really available today. Current practices are weak. The degree of structure required to address them was not clear. All of this is further complicated since risk management is interwoven with politics. A suggestion was made to examine the taxonomy in terms of the true added value of the evidence and the assurance. These may imply that multiple types (representative forms) of assurance, ratings, and evidences are needed to satisfy multiple types of consumers. The following additional points/questions were made regarding understanding assurance and its ingredients: y Depending on the type of the assurance requirements needed, the attributes of the assurance for the process may be quite different. y The user of information technology (IT) security should decide what the needed evidence is to make the product considered enough of assurance. y Levels of evidence are different and need to be considered, i.e., incorporated into an accepted model. Examples include reputation, warranty, third-party evaluations, industry or consortium branding, and wide- spread use. y Effectiveness, correctness, and risks are different for systems than products, particularly what they mean and how important they are. y How should subsequent discovered bugs and problems be handled and how should they affect one's view of previously established assurance or assurance ratings? y Assurance can be seen as based on the composition of a variety of evidences. 6.2.5 Relating Process to Assurance Clearly a relationship between process, evidence, and assurance exists. Today assurance is predominantly determined by the product evaluator's process or the system certifier's process for products and systems, respectively. Also today the developer's process (whether a product or integrator/developer engineering group) contributes directly to the creation of evidence to be used in an assurance determination. Therefore, higher quality and improvements to these processes can result in cheaper, faster, better, more predictable assurance. The following additional points/questions were made regarding relating process to assurance: y With a high quality process(es), the amount of system/product specific evidence can be greatly reduced. y Process-produced evidence needs to include effectiveness. y Is the assurance statement related to the work factor, i.e., degree of effort? If the work factor is large then is assurance improved? y There is a need to determine how the process can generate the evidence required by the customer then determine. y Variations must be allowed in the specific practices of a process (i.e., instantiation and implementation). y In reality, there will be cases where a product is developed without following a defined process and these cases cannot be ignored, i.e., will need to be accounted for. 6.2.6 PROCESS ASSURANCE AS A BASIS OF SYSTEM/PRODUCT ASSURANCE The discussion at the session centered around the extent that assurances about process could contribute to assurance about the system/product. As stated above, clearly process contributes to evidence upon which classic assurance is determined. It should be equally clear that assurance about a relevant process, e.g., the developer's security engineering process, can also contribute to the evidence. For example, such assurance would indicate a degree of confidence in the evidence contributions produced by the process. One could argue that today's system and product assurance are based on assurance of the product evaluator's and system certifier's processes, respectively. The assurance on each process is a forgone conclusion offered by its practitioner. Moreover, these process assurances are usually quite accepted by the consumers, accreditors, developers, and users. The most challenging question is whether one could rely on developer's security engineering process assurance as the sole or predominant determinant of system/product assurance. Almost all of the attendees felt that relying on a good process alone to achieve an amount of assurance isn't adequate. For instance, testing would still be needed to ensure that process is followed before, during, and after the system/product is made. Total dependence on the process is not enough, because there may be errors and such dependence appears naive. The SE CMM was viewed as a promising method (and criteria) for establishing security engineering process assurance. The following additional points/questions were made regarding relating process to assurance: y Process assurance may be adequate to be the sole determinant of system/product assurance. y Comparisons and equivalencies of various blends of developer process assurance and system/product evidence to establish system/product evidence are needed. y The Software Engineering Institute (SEI) CMM for Software, while providing assurance on software engineering management, does not address security. y ISO 9000 fundamentally requires the developer to have a documented process; it does not give any details or criteria. 6.2.7 Process Improvement System security engineering organizations currently have differences in the maturity of the processes that they follow. Immature organizations tend to use processes which typically do not provide a great deal of visibility into the progress and quality of the system/product being built. These processes are indicative of unpredictable performance and lead to excessive maintenance costs. The SE CMM identifies key process areas and provides the ability to determine the strengths and weaknesses of the process. Existing relationships between the key process areas are utilized. It provides an approach to improve the process for building a system/product. This is done by identifying incremental improvements and focusing investments in training, tools, and process development. The group basically agreed that if the process to build the system/product can be improved, then the product will be improved, and therefore reducing the amount of required system/product specific evidence. To improve the process of gaining assurance in a system/product we need to identify the processes that mitigate the risk and relate them to the process that develops the system/product. After you define those processes you need to differentiate the kinds of assurances related. The following additional points/questions were made regarding process improvement: y How much evidence will be needed for illustrating that you follow a particular process? y How much additional evidence above and beyond following a particular process is required to indicate a sufficient amount of assurance? y What is the cost of improving the process? y What is the cost associated with evaluating the additional evidence? y What are the relationships between the risk and methods used to counter the risks? y How can we disassemble threat and the relationship of the process? y How can tools help? 6.3 CONCLUSIONS AND FUTURE DIRECTIONS Clearly movement to a process orientation for engineering, systems, and products is a necessity. Integral to such a movement is a commitment to continuous organizational process improvement, where slow incremental organizational process improvement is key. Such notions can apply equally to processes for security engineering (system or product), product evaluation, system certification, system accreditation, acquisition, and system administration. Improved and uniform process(es) may lead to higher quality and more predictable evidence and, hence, better, faster, cheaper assurance. Process assurance will likewise aid in this direction. Hopefully, process assurance will permit a reliance on process as the predominant determinant of system/product assurance, perhaps even the sole determinant. Such reliance will need to be investigated, resolved by analysis, trail, or a combination thereof. The various questions and issues merit investigation: y A better (practical, usable) definition of assurance with more robust taxonomy that addresses assurance attributes, ingredients, and forms that differentiates assurance purpose and degree. y Understanding of the trade-offs and the translation of them to equivalency classes; these must address trade- offs among security functionality development process, assurance process, and evidence dimensions. y Development of the SE CMM and its use in security engineering process improvement, assurance, and standardization. y Addressing other processes in terms of process standardization, improvement, and confidence. y Addressing process related issues, such as individual skills, process descriptions, and process prescriptions. SECTION 7 METRICS AND TESTING Jim Williams, Moderator Caralyn Wichers, Recorder 7.1 INTRODUCTION "What is assurance?" Without a working definition of assurance, it is difficult to describe how to measure assurance. An appropriate definition of assurance depends, in turn, on the rationale for assurance. Participants in this session discussed definitions and purpose assurance, how it can be measured, both qualitatively and quantitatively, and how testing, including automated testing, fits into assurance. 7.2 BACKGROUND The following relevant findings can be found in Redefining Security (JSC, 1994). A balanced mix of information systems security, personnel security, and physical security is needed, but how does one make sure that an appropriate mix is achieved? A complete range of security objectives needs to be addressed, including confidentiality, availability, integrity, and security management, but do assurance techniques designed for confidentiality necessarily carry over to other objectives? The Federal Criteria (National Institute of Standards and Technology (NIST) and NSA, 1992) provides a view of security in terms of a basic problem decomposition into task areas, most of which constitute assurance of some sort (those that do not are italicized): y Product functionality y Environment/usage y Product cycle (design, development, evaluation, maintenance) y Vetting of the above requirements y Product integration y System certification y System accreditation The Federal Criteria itself addressed only the first four items. 7.3 RATIONALE FOR ASSURANCE The primary reasons for providing assurance include the following: y Reduce threats to information assets, safety of physical systems, data sources and recipients, and users. y Reduce losses induced by active threat agents, natural disasters, faulty software, incompatible system components, inadvertent "agents," and expenditures on security protection. There was some discussion as to whether the goal of achieving acceptable security could be understood in terms of the cost of security, including indirect costs such as inconvenience to users and security breaches. Reducing concepts to dollars may encourage cynicism, such as determining what a secret is worth and who cares, rather than foster making a meaningful decision. However, to achieve any assurance, one must spend money. Even in building a system without explicit security requirements, one still wants to test and show that the system works. Depending on the level of assurance needed, one may want to spend more to obtain it. In some cases, one may want to spend a lot for assurance because one may care about saving lives, for example. In others, any additional expense on a particular security objective, such as confidentiality, may be wasted on the product's intended customers. There must be requirements for measuring the cost of security. Without these requirements, there is no empirical basis for measuring the payoffs from using various assurance techniques. Unfortunately, we do not often learn from the past whether or not assurance techniques were successful. Based on unsuccessful efforts to elicit the voluntary production of cost-benefit information, it appears that if there is no requirement to record the information, then the vendor will not record it. We need to capture information, for instance, on how long it really takes to test and how this testing correlates with how much assurance is obtained as a result. We need, for example, to obtain information on security tradeoffs between testing prototypes and testing actual systems. Currently, testers ask how much money is involved and how long testing will take, but not how this testing will correlate with likelihood of meeting user security needs. 7.4 DEFINITION AND PURPOSE OF ASSURANCE The following primary and secondary definitions were developed based on a managed brainstorming session conducted using a Juran tool. y Assurance is confidence that a system meets the security needs of those whom it was intended to serve.4 Thus, the purpose of assurance is to mitigate risk that security needs will not be met. y Confidence, in this case, varies from an informal belief, comfort level, or sense of well being to rigorous, statistically valid measures of probability of truth. It is difficult to see how meaningful quantitative measures of confidence can be obtained without resorting to rigorous statistical notions of confidence. For many people, confidence implies substantiating knowledge of how the belief was obtained, by employing of a precise, rigorous analysis of system behavior, having confidence in the people who perform the analysis, supplying substantiating evidence. Confidence depends on individual perspective; there is usually some loss of confidence as assurance information is transferred from producers of this information to its consumers. y A system is made up of automated information products, users, and other interacting entities. This fact leads to distinctions among automated system assurance, product assurance, and personnel assurance. y Meeting security needs presupposes the full and correct identification of security needs. Thus, assurance necessarily includes validating the correctness and completeness of identified security needs. Moreover, the needed degree of assurance depends directly on the expected cost of failing to meet these needs. Cost is not always measurable in monetary terms. Meeting security needs also involves the proper design and implementation of systems. The overall system design process includes formulation of automated system requirements as well as usage and environmental constraints. Consequently, assurance involves ensuring that the overall design effectively addresses the needs of the users and owners of the system. The overall structure, or design of a system, is something that exists throughout its life cycle. Assurance of effectiveness is needed continuously throughout the entire evolution of the system. y The overall security design must also be correctly implemented. Automated components must perform as specified, which implies not doing things that are prohibited by the design's security requirements. Moreover, constraints on the use of the system must be reasonable and must be explained to its users and administrators who, in turn, must have sufficient incentives to obey these constraints. Assurance of correctness must also be provided continuously throughout a system's life cycle. 7.5 KINDS OF ASSURANCE The above discussion on the purpose and definition of assurance implies directly that security assurance includes the following kinds of assurance: Policy assurance involves the identification, assessment, and validation of security needs, as well as estimation of the (possibly non-monetary) cost of failing to meet these needs. This form of assurance requires empirical data on security incidents. Like other forms of assurance, this form must take place throughout the system's life cycle because relevant empirical data is generated throughout the system's life cycle and because security needs evolve in parallel with those of the system. Effectiveness assurance ensures the effectiveness of the overall system and component designs, including the design of environmental/usage constraints, throughout their entire life cycle. Effectiveness, in the ITSEC at least, is the aptitude of the security functions to properly counter the postulated threats. Effectiveness includes suitability and strength of mechanisms. The FC adds adequacy, completeness, binding, and dependency analysis. Correctness assurance ensures that designs are correctly implemented throughout their entire life cycle. Correct implementation refers to agreement between implementation and specification. Evaluation assurance provides evidence as to whether policy, effectiveness, and correctness assurance is adequate. Successful evaluation involves expert examination of evidence pertaining to policy appropriateness, design effectiveness, and implementation correctness. Pragmatically, the above decomposition of the assurance problem requires an appropriate, balanced allocation of assurance effort among various kinds of assurance, among system components, including human components, and among various assurance techniques, throughout the system's life cycle. Balance presupposes the identification of all readily available sources of assurance and assurance evidence. The need for allocation of assurance throughout product and system life cycles is a strong motivation for emphasizing reusable assurance evidence. Our discussion did not devise a name for this process, but for ease of later reference in this document, we will refer to it as ensuring balance. For all kinds of assurance, including ensuring balance, the amount of assurance actually provided depends heavily on the expertise of the people and organizations involved; it is positively, perhaps strongly, correlated with their reputations. Consequently, reputation may be a useful, convenient form of evidence for evaluating all kinds of assurance. For the same reason, willingness to accept responsibility (including legal responsibility) for error is also positively correlated and is thus useful as evidence. In particular, vendor product warranties may constitute evidence of correctly implemented, effective product designs. All of the various kinds of assurance can fail. Security incidents will happen, and thus assurance will be improved if response to breakage is planned for, especially in regard to the maintenance of policies, systems, and the products from which systems are built. 7.6 ASSURANCE TECHNIQUES The following subsections discuss in more detail the above five kinds of assurance, along with related assurance techniques. This list of techniques produced during the discussion is clearly incomplete. The apparent absence of techniques for some forms and aspects of assurance may be a significant observation or simply a result of the brevity of our investigation. 7.6.1 Policy Assurance Policy assurance, as it applies to information security, appears to be an under-explored area. Other similar disciplines, such as industrial safety and physical security, have a stronger tradition of collecting, analyzing, and profiting from incident data, both real-world and experimental data. 7.6.2 Effectiveness and Correctness Assurance There is a large body of knowledge and assumed wisdom about how to achieve high quality design, implementation, and systems integration. We did not discuss this topic in detail. However, product and automated system development necessarily includes developer evaluation, so that the evaluation techniques mentioned below apply here as well. Moreover, the overall value of a development technique may include not only intrinsic value to the product or system produced but evidentiary value for evaluation. Assurance in the design and implementation of environment and usage constraints was touched on only briefly, and less appears to be known than originally thought. Techniques include screening/training users and product integrators as well as redesigning products and systems to make them as idiot proof as possible. 7.6.3 Evaluation Assurance Available evaluation assurance techniques include, but are not limited to, the following: y Direct, rigorous analysis of product or system behavior y Use of formal methods. such as specifications and correctness proofs y Covert channel analysis (mention of this drew protest on grounds of practicality) y Penetration testing y Functional testing (including beta testing) y Assessment of developer competence and/or methodology y Assessment of developer reputation y Assessment of development tools (e.g., for design analysis, configuration management, automated testing) y Assessment of user experience y Avoidance of using the first version of a system, which usually involves field testing and evaluation 7.6.4 Ensuring Balance Assurance techniques often tend to apply to perceived-threat scenarios, focusing on what might go wrong. The assurance approach for a given system or product family needs to be subjected to threat-mitigation or risk-reduction analyses. Unfortunately, there is a dirth of relevant information here. For example, there is no clear way to authoritatively answer such obvious questions as the following: y For what environments would money spent on covert channel analysis have been better spent on configuration management? y Is having an NSA A1 evaluation better than being a COTS product? 7.7 WHERE TESTING FITS IN Evaluators tend to test what the developers do. If tests performed by the developers were correct and complete, perhaps the evaluators could just check the results. There are a few areas in which exhaustive testing is already being used, one of which is model checking of hardware. For portions of systems that can be specified in terms of propositional logic, it is feasible to set up binary decision trees to check all paths. This is common practice for testing of hardware; these tests are fully automated. Security testing traditionally includes penetration testing, which is difficult to automate because it involves long, unusual scenarios. Penetration testing is based on the assumption that the system will have hostile users whose patterns of input are explicitly designed to exploit system vulnerabilities. Traditional testing theory requires that test cases be distributed in the same way as input in actual system operation. Unfortunately, input patterns by hostile users can change when vulnerabilities are discovered_in ways that cannot be predicted during routine testing. There are tools that help with penetration testing, but full automation seems infeasible. 7.7.1 Where Automated Testing Fits In Fully automated testing involves constructing machine-readable specifications that describe both system behavior and expected user inputs, automated generation of test cases from the specifications, automated execution of test cases by test harnesses, and automated analysis of test results by test servers. Automated test generation involves additional expense because of the need to write machine-readable specifications. However, automated test generation may be very cost-effective when the following statements are true: y Economies of scale are realized - A single design has many different implementations y Assurance requirements call for - Systematic or exhaustive testing - Independent validation of vendor test results - Machine-readable specifications y Automated test execution is required for other reasons y Test-generation tools can develop new test suites quickly for - Design revisions - New test requirements - New implementations To what extent does automated testing support evaluation? Unconstrained searching for vulnerabilities is a good thing to do but it is not clear if this is feasible via automated testing, if hostile users are assumed to exist. However, automated regression testing can be used to ensure that known security flaws do not reappear after having been removed. 7.8 CONCLUSIONS Several useful sources of assurance have been underutilized in the past. More cost-effective approaches depend on understanding how these sources can be best used. In this session, we have posed tentative answers to all but the last of the following questions: y What is the higher goal that security assurance supports? y How does assurance fit in? y What is assurance? y How does (automated) testing fit in? y How can assurance be achieved and measured? These answers and the final question need to be discussed by the larger security community, possibly at NIST's International Invitational Workshop on Developmental Assurance, to be held in June 1994. Finally, we have identified a preliminary taxonomy of assurance elements and techniques. This taxonomy pertains to the difficult questions of how to achieve practical assurance levels and how to measure, either qualitatively or quantitatively, the amount of assurance provided for a product or system. It was the consensus of the discussion group that qualitative measurements of assurance are currently more feasible than quantitative measurements. SECTION 8 RISK MANAGEMENT Marshall Abrams, Moderator Lynne Ambuel, Recorder 8.1 INTRODUCTION The challenges of risk management are divided into equally demanding and sometimes conflicting requirements concerning data integrity, system integrity, availability, software reliability, safety, and confidentially. Accepting a risk management perspective, we cannot pretend that by implementing certain security measures, we can mitigate the security risk to zero. Viewing risk assessment from the standpoint of assets and threats is necessary but not sufficient. Participants in this session discussed relevant extracts from Redefining Security (JSC, 1994), fundamental questions and terminology, multidimensional complexity, trade-off and balance, scope of IT security, decision-making, system characteristics, contingency plans, and dissemination of information. 8.1.1 Extracts from Redefining Security Like many of the other sessions in this workshop, we found relevant extracts in Redefining Security (JSC, 1994): y Security of information systems and networks is the major security challenge of this decade and possibly the next century. y The paradigm for managing information security is subscribers within a worldwide utility connected to and dependent upon an infrastructure they neither own nor control. y In most cases, it is possible to balance risk of loss or damage of disclosure against cost of countermeasures. y We must use a risk management approach that considers actual threats, inherent vulnerabilities, and availability and cost of countermeasures. y Risk management requires evaluating the resource impact of proposed changes in security policies and standards. The members of the working session felt that Figure 1, extracted from Redefining Security (JSC, 1994), which shows the risk management process, is an attempt to use the scientific method for a problem that has not been reduced to science. Figure 1. Risk Management Process 8.1.2 Tools Needed for Risk Management Among the tools needed for risk management are a language to capture requirements and maintain cognizance of requirements throughout a system's life cycle; a risk quantification method that relates to actual requirements, addresses inherent risks, deals with complex implementations, and performs meaningful computations; a methodology to lead designers and evaluators through the full spectrum of risk issues, identifying which concerns are applicable to a particular system and going into more depth where appropriate; and a listing or rating of risk reducers. 8.2 FUNDAMENTAL AND VERY TOUGH QUESTIONS Fundamental and very tough questions need to be answered to make any progress on risk management: What are the security requirements? In what ways are we at risk of not meeting those requirements? How much are we willing to spend to mitigate those risks and to what degree? What should be the government's role in helping to protect information held by private citizens and institutions? How can government technology be provided to the private sector for the protection of sensitive unclassified information? Will the private sector accept it? 8.3 TERMINOLOGY Semantic distinctions and definitions are very much part of the problem faced in capturing and presenting issues in assurance and risk management. Even when terms are defined, it is very difficult to get people to read the definitions and to use the terms as defined. Nevertheless, failure to define terms almost guarantees failure in meaningful interchanges concerning risk management. This session met this problem half-way. We identified four key terms that must be defined: risk, threat, vulnerability, and susceptibility. The participants were able to communicate based on prior knowledge from working in the field. However, we recognized that there are multiple authoritative definitions which differ among themselves in both subtle and more obvious ways. 8.4 MULTIDIMENSIONAL COMPLEXITY While the desirability of quantification is recognized, it may not be possible given the state of understanding. Qualitative descriptors may be sufficient and necessary based on whether an assurance factor is quantifiable. In some instances, simple ordering may be achievable and desirable. One of the consequences of the paradigm switch from risk avoidance to risk management is that it becomes necessary to deal with the unimaginable. Especially in times of decreasing resources, it is necessary to think about what actions should be taken if highly undesirable events occur. As discussed in more detail below, it is also necessary to consider incomparables in risk trade-offs and management. People may make decisions based on system security, human safety, personal career, or any other factor that they may consider to be important to themselves or their organization. In addition, security risks are only one component of risk management. The risks to development/production schedules, inclusion of competitive, state-of-the-art technology, and sales factors often dwarf the security risks in the decision- making process. The imperfections of current risk management techniques were acknowledged, but no alternatives were identified. The group generally agreed that, although the techniques and tools for performing risk analysis could be improved, the management of risk will always be an integral part of product and system development. It will be necessary to refine the concepts and practices of risk management as they are applied to information security. In discussing risk management, it is necessary to distinguish between the general concept of risk management and specific techniques. It is not uncommon for a discussion to be couched in terms of risk management when the speakers have specific techniques in mind. Communication can be especially difficult when different techniques are being discussed but have not been made clear. 8.5 TRADEOFF AND BALANCE There are several kinds of risks to which systems are subjected, including technical, schedule, cost, security, and safety. Satisfaction of all objectives and avoidance of all risks are generally impossible because the objectives or the techniques used to achieve these objectives are often in conflict. Perspective enhances the ability to make the trade-offs, but the job is never easy. It involves balancing conflicting equities. Sometimes, decisions are made suboptimally because the decision-maker is unaware of all the consequences. 8.6 SCOPE OF IT SECURITY Traditionally, IT security has focused on products and systems. However, the scope extends beyond these areas in several dimensions. Security can affect the survival and well being of entities, including the individual, the organization, the nation, and the planet. Integrating products into systems and forming systems of systems are unsolved security problems. It has been recognized for several years that we need standards and procedures for preserving security attributes and properties through the integration process. Little or no progress has been made on developing guidance or codifying good practice in this area. The security impact of integration remains an art form due, in part, to the subjective nature of risk management. IT systems exist in an environment. One of the salient characteristics of systems, as defined in the ITSEC and FC, is that a system is used in a specific real environment. The IT system and the environment are real entities that interact. The circumstances and realities of the environment constitute boundary conditions and requirements on the IT system. Non- technical countermeasures are also part of the environment. The opinion has been voiced, but not conclusively established, that non-technical countermeasures are more cost-effective than technical ones. Proving and using this assertion can be both a demonstration of risk management techniques and a tool in the utopian trade-off tool kit. A significant part of the environment is the information infrastructure. Networks connect resources across agencies, companies, industries, countries, and the world. The laissez faire, cooperative, decentralized federation of the Advanced Research Projects Agency (ARPA) sponsored Internet in the 1980s appears inadequate for the commercialized global Internet evolving in the 1990s. Understanding and responding to changes in this part of the environment are significant problems. 8.7 DECISION MAKING TECHNIQUES Management has been described as decision-making based on insufficient information, and risk management is decision- making in the face of uncertainty. Risk management can be characterized as technically complex, multivariate, and not fully understood. Existing techniques include sensitivity analysis, system effectiveness analysis, and cost-benefit analysis. It is not clear whether such techniques are applicable to managing security risk. Data is lacking on whether these techniques have been employed, whether they have proven to be effective, and how acceptable they are to the risk managers. The models underlying the techniques also need to be reexamined. Are Bayesian, probabilistic, and actuarial statistics applicable? How does the possibility of a human agent attempting to violate system security policy affect the underlying assumptions on which the models are based? Are fuzzy system techniques applicable and acceptable? 8.8 DECISION-MAKERS Who makes which type(s) of decision(s)? The appropriate person, level, criteria, and method for making a decision is not always clear. Technical personnel, line management, and type management all make decisions that impact risk. Technical personnel may not recognize overriding policy or political concerns, for example. Accepting responsibility for decisions is complicated by group decision-making techniques, such as mutual and peer decision making. In addition, many organizations have lack of responsibility built into their decision-making processes. In these organizations, decision-makers are on a fixed, short- term tour of duty in which it is essentially guaranteed that a product/system will not be operationally deployed by the time their tour is over. Because of this, the decision-maker may consider career advancement decisions and avoidance of adverse publicity to be major factors is the decision-making process as they will not be directly accountable for the operational product/system. There needs to be more accountability of these decisions, perhaps by placing people into positions so they stay with a project, having responsibility for all stages in the development and deployment of that system. Qualification of decision-makers is highly variable. Academic training in the referenced techniques is infrequent. Many organizations believe that general managers or general officers can move among disciplines with equal effectiveness. 8.9 BASIS FOR DECISIONS Managers make decisions based on many considerations. The scope of their influence or knowledge base will shape their decisions both in terms of technical/political risks and localized/global perspective. Career impact is a highly motivating decision basis and may result in a decision that reflects personal accountability and not necessarily technically optimum. The decisions are often made without sufficient information and are therefore somewhat error prone, if not highly subjective in nature. In addition, there appears to be a tendency to focus on active threats, perhaps because of their urgency. We must not neglect systemic features that allow error and omissions to escalate. Passive threats can also cause catastrophes. There is a need to put more emphasis on long-term countermeasures because that is where true risk management comes into play. Short-term countermeasures have been easier to define but do not look into potential threats and susceptibilities. There also needs to be more of a look at risks not based solely on threats and assets. Inherent risks, reliability, and development risks are all factors that need to be added to the risk management considerations. 8.10 SYSTEM CHARACTERISTICS There are some significant differences between IT systems and other engineering products that affect security risk management. Many of the techniques applicable to continuous physical systems do not apply to IT systems because of discontinuity in hardware and software (Zelkowitz, 1994). IT systems can be unforgiving and are becoming more unpredictable. Small errors, problems, or breaches can have large effects. It is not clear whether it is possible to over- engineer software systems to build in a margin for error, as it is in other engineering disciples, especially manufacturing. 8.11 CONTINGENCY PLANS Contingency planning in the form of backup data storage and remote alternate operation sites has long been part of security planning for availability, reflecting the preparation for undesirable event occurrences. The safety community practices risk toleration as another form of contingency planning. Contingency planning needs to be extended to other security policy objectives such as confidentiality and integrity. The paradigm shift away from risk prevention implies occasional policy breaches for which provision should be made. 8.12 DISSEMINATING INFORMATION While risk management must function in the absence of sufficient information, there is no virtue in taking on an unnecessary handicap. Accumulated information about risks and countermeasures must be made available. Disseminating such information is, itself, a risk management decision. It is not possible to keep the information from the penetrators, nor is it possible to force all system administrators to act with what we consider necessary prudence. However, decision-makers have always been reluctant to keep and/or provide records of the risk management decisions being made. There are many reasons for this. These decisions are not made with a great deal of quantitative data and are therefore highly subjective in nature. Without objective, quantitative data to back up decisions, many responsible managers do not wish to be second-guessed years after a decision has been made. Therefore, records are seen as a liability and not diligently kept. SECTION 9 CLOSING The attendees of the workshop were asked three questions at the closing session: "Was there utility in this first workshop for IT security?" "Should there be future such workshops?" and "If so (to the first two questions), what should be the frequency of the workshops ?" 9.1 IT SECURITY ASSURANCE WORKSHOP UTILITY The general consensus was that a forum to discuss the issues of IT security assurance was of great use to the community. In particular, this workshop determined that assurance is still a somewhat nebulous subject. There are many questions that need to be explored. It is still difficult to define precisely what is meant by assurance, and the definition varies from person to person and enterprise to enterprise. The questions of how to gain assurance, how to relay assurance gained, and how to use assurance all need further study. It was generally felt that just the identification of these questions for further study made the workshop a useful exercise. There was some sentiment that these subjects need to be pushed back out into the community for actual resolution. Discussions in a short workshop must remain at a high level. Therefore, no problems could be resolved at such meetings. However, the group decided that this group could help provide the questions that could be addressed through research. One method for doing this in the near future is to provide the proceedings to other forums considering the subject of assurance, especially those attending the International Workshop of Developmental Assurance being held in Maryland in June 1994. In addition, a panel discussion on the results of both of the assurance workshops has been scheduled for the National Computer Security Conference in October 1994. It is thought that these forums will further advance the discussions and move the community one step closer to resolution of some of the issues identified. 9.2 FUTURE ASSURANCE WORKSHOPS Based on the utility discussion, the group agreed that future workshops should take place. However, the group also agreed that it should strive to move beyond identifying issues to resolution of some of these issues. It was agreed that this could happen once the problems are well defined. Workshop sessions could then concentrate on issues of much finer detail. 9.3 FREQUENCY OF WORKSHOPS The group did not determine a specific duration between workshops. Instead, it was generally decided that they should be planned as needed. Because of the impending Developmental Workshop and the assurance discussion planned for the NCSC in October, the planning committee has decided to target spring 1995 for the next workshop. 9.4 OBSERVATIONS ON PROGRESS One conclusion/observation is that the security community has made little progress in the past years in truly understanding the issues at hand, and there is little hope for the immediate future. We continue to spend large amounts of resources trying to address simple issues such as definition of terms and high- level processes (again and again), while failing to understand the user community's needs and promote a strong security awareness among the general user population. While there appeared to be much agreement on what had been done wrong in the past, there appeared to be little consensus on how to proceed. One thing appears clear though: with the rapidly changing technology and threat environment, unless the security community becomes more proactive, more in touch with the real user needs and expectations, and does a better job of developing security awareness in the user community (to ensure security is built in and maintained during operation of the system), the security of our information and resources will not improve. LIST OF REFERENCES Bell, D. E., and L. J. LaPadula, 1975, Secure Computer Systems: Generalized Framework for Exposition and Multics Interpretation, ESD-TR-75-306, The MITRE Corporation. (Also available through NIST, Springfield, VA AD-A023588) Canadian System Security Center, January 1993, The Canadian Trusted Computer Product Evaluation Criteria, Version 3.0e. Commission of the European Communities, 28 June 1991, Information Technology Security Evaluation Criteria (ITSEC): Provisional Harmonized Criteria, Luxembourg: Office for Official Publications of the European Communities, Version 1.2. Computer Science Laboratory, March 1992, EHDM Specifications and Verification System - Version 6.1 User's Guide, Technical Report, SRI International. Department of Defense, 1985, Department of Defense Trusted Computer System Evaluation Criteria, DOD 5200.28-STD, Washington, DC. European Computer Manufacturers Association, 14 December 1989, Security in Open Systems, Data Elements and Device Definitions, ECMA-138. ISO 9000, International Standards for Quality Management, 2nd Edition, 1987-1991 Joint Security Committee Report, 28 February 1994, Redefining Security: A Report to the Secretary of Defense and the Director of Central Intelligence, Joint Security Committee, Washington DC. Korelsky, Tanya, and David Rosenthal, August 1992, Integrated Trusted Systems Development Environment Tools Final Report, Technical Report, ORA Corporation. McEnerney, Joseph R., D. G. Weber, Randall Brown, and R. Varadarajah, October 1990, "Automated Extensibility in THETA," Proceedings 13th National Computer Security Conference, Washington, D.C. McDermid, John A., 1991, "Issues in Developing Software for Safety Critical Systems," Reliability Engineering and System Safety, Volume 32, 1991, pages 1-24. National Computer Security Center, 25 June 1985, Computer Security Requirements: Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments (Yellow Books), National Security Agency, Fort George G. Meade, MD. National Institute of Standards and Technology and National Security Agency, December 1992, Federal Criteria for Information Technology Security, Version 1.0. National Research Council, 1991, Computers at Risk Safe Computing In the Information Age. O'Brien, Richard, and Clyde Rogers, October 1991, "Developing Applications on LOCK," 14th National Computer Security Conference. Saltman, Roy G., December 1993, Good Security Practices for Electronic Commerce, Including Electronic Data Interchange. Zelkowitz, M. V., 1994, Models and Algebra (and Reality). APPENDIX ATTENDEES Listed below are the workshop attendees (asterisks indicate members of the organizing committee): Marshall Abrams* Karen Ferraiolo The MITRE Corporation ARCA Systems, Inc. 7525 Colshire Drive 8229 Boone Blvd., #610 McLean, VA 22102 Vienna, VA 22182 (703) 883-6938 (703) 724-5611 abrams@mitre.org ferraiolo@arca.va.com Dee Akers* Sharon Fletcher The MITRE Corporation Sandia National Laboratories 7525 Colshire Drive Dept. 9411 MS Z274 Albuquerque, NM 87185-0778 McLean, VA 22102 (505) 844-2251 (703) 883-5907 skflete@sandia.gov akers@mitre.org Lester Fraim Lynn Ambuel* The MITRE Corporation NSA,I94 7525 Colshire Drive Fort Meade, MD 20755-600 McLean, VA 22102 (410) 859-4463 (703) 883-6339 ambuel@dockmaster.ncsc.mil fraim@mitre.org Blaine Burnham Art Friedman NSA,V12 The MITRE Corporation 9800 Savage Rd 7525 Colshire Drive Fort Meade, MD 20755-6020 McLean, VA 22102 burnham@dockmaster.ncsc.mil (410) 859-6700/01 arf@mitre.org Debbie Campbell NSA/I94 Judith N. Froscher* 9800 Savage Rd Naval Research Laboratory Fort George G. Meade, MD Code 5542 20755 Washington, DC 20375 (401) 859-4464 (202) 767-3012 dscampbell@dockmaster.ncsc.m froscher@itd.nrl.navy.mil il Bret Hartman Julie Connolly Odyssey Research Associates NSA/I91 301 Dates Drive 9800 Savage Rd Ithaca, NY 14850 Fort Meade, MD 20755 (607) 277-2020 (410) 684-7374 bret@oracorp.com jlconnolly@dockmaster.ncsc.m il Chuck Howell The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 Bill Neugent (703) 883-6080 The MITRE Corporation howell@mitre.org 7525 Colshire Drive McLean, VA 22102 Jay Kahn (703) 883-6632 The MITRE Corporation wneugent@smiley.mitre.org 7525 Colshire Drive McLean, VA 22102-3481 Ingrid Olson (703) 883-6622 The MITRE Corporation jkahn@mitre.org 7525 Colshire Drive McLean, VA 22102 Doug Landall (703) 883-7044 ARCA Systems iolson@smiley.mitre.org 10320 Little Patuxent Parkway Bernard Roussely Columbia, MD 21044 SCSSI (410) 715-0500 18, rue du Docteur Zamenhof landoll.arca.md.com G2131 ISSY-LES-MOULINEAUX France Burkhard Lau SSI13@calvacom.fr Delft University of Technology Joel Sachs P.O. Box 365 ARCA Systems NL-2624 AJ Delft One Commerce Center Netherlands 10320 Little Patuxent Pkwy 31-15-787106 Suite 1005 B.Lau@IS.TWI.TUDelft.NL Columbia, MD 21044 (410) 715-0500 John McDermid sachs@area.md.com University of York Heslington, York Ravi Sandhu Y015DD, UK George Mason University 44 904 432726 Issue Department, MS4A4 jam@minster.york.ac.uk Fairfax, VA 22030 (703) 993-1659 Piers McMahon sandhu@gmu.edu ICL Kings Road Dan Sterne 33 Kings Road Trusted Information Systems Reading, RG13PK, UK 3060 Washington Road pvmcmahon@rea0803.mins.icl.c Glenwood, MD 21738 o.uk (301) 854-6889 +44 734 634882 sterne@tis.com Pat Toth* National Institute of Standards and Technology National Computer Systems Laboratory Gaithersburg, MD 20899 (302) 975-5140 toth@csmes.ncsl.nist.gov Caralyn Wichers* BBN 9810 Patuxent Woods Drive Columbia, MD 21046-1562 (410) 290-6188 cwichers@bbn.com Jim Williams The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 (617) 271-2647 jgw@mitre.org GLOSSARY ACSA Annual Computer Security Applications Conference ADP automatic data processing ANSI American National Standards Institute ARPA Advanced Research Projects Agency CAS Controlled Application Set COTS commercial off-the-shelf DOD Department of Defense ECMA European Computer Manufacturers Association INFOSECinformation security ISO International Standards Organization IT information technology IWITAT Invitational Workshop on Information Technology Assurance and Trustworthiness JSC Joint Security Commission MAC mandatory access control MLS multilevel secure NIST National Institute of Standards and Technology NRL Naval Research Laboratory NSA National Security Agency OO object oriented OS operating systems R&D research and development SINTRA Secure Information Through Replicated Architecture SQL Structured Query Language TCB trusted computing base TCSEC Trusted Computer System Evaluation Criteria U.S. United States _______________________________ 1 The groups shown below were developed using one of the Juran Management and Planning Tools known as an Affinity Diagram. Each issue identified during the brainstorming session was written on a post-it note. All post-it notes were then randomly placed on the wall and then moved into groups. During the process, no one spoke, and everyone worked simultaneously. The process continued until everyone was satisfied with the groups. When one issue appeared to be appropriate in two or more groups, duplicate post-it notes were made. 2 A stovepipe system has a low degree of horizontal integration with other systems in an enterprise, and a high degree of vertical integration. That is, it does not share or communicate well or at all with other platforms' resources at the same levels in their respective architectures. By vertical integration, a system may have its own dedicated displays, computer hardware and software, communications lines, phone system, sensors, etc. Stovepipe systems have the connotation of potentially never being used again. The term has a pejorative connotation of a system potentially never being used again. It is often associated with a program-specific one-time solution that fit the exact system or situation at hand, and is not interoperable with other programs. The primary advantage of stovepipe systems is performance. They are dedicated to one use and offer maximum availability. There are also advantages for developers. By having all their own vertical components, they may be faster to build as they are independent of common architecture definitions and therefore avoid politics. The disadvantages are generally related to maintenance and extensibility, and they can be more expensive than general purpose systems. 3 Readers unfamiliar with fuzzy logic are referred to Lotfi A. Zadeh; Fuzzy Logic, Neural Networks, and Soft Computing; Communications of the ACM; March 1, 1994, v 37, n 3, page 77. 4 This definition is significantly stronger than that found in the NSA Glossary of Computer Security Terms which defines assurance relative to an assumed system security policy that, in some cases, may be irrelevant to the security needs of people whose lives may be affected by the system at hand. The Federal Criteria's definition, which is closer to ours, splits assurance into profile assurance and IT product assurance. Profile assurance is equated with technical soundness, which implies appropriateness of the profile's functional and assurance requirements.