COMPUTING APPLICATIONS. Michael P. Zeleznik. A dissertation submitted to the faculty of. The University of Utah. Doctor of Philosophy

Transcription

1 SECURITY DESIGN IN DISTRIBUTED COMPUTING APPLICATIONS by Michael P. Zeleznik A dissertation submitted to the faculty of The University of Utah in partial fulllment of the requirements for the degree of Doctor of Philosophy Department of Computer Science The University of Utah December 1993

2 Copyright c Michael P. Zeleznik 1993 All Rights Reserved

3 THE UNIVERSITY OF UTAH GRADUATE SCHOOL SUPERVISORY COMMITTEE APPROVAL of a dissertation submitted by Michael P. Zeleznik This dissertation has been read by each member of the following supervisory committee and by majority vote has been found to be satisfactory. Chair: Lee Hollaar Robert Kessler David Hanscom

4 THE UNIVERSITY OF UTAH GRADUATE SCHOOL FINAL READING APPROVAL To the Graduate Council of the University of Utah: I have read the dissertation of Michael P. Zeleznik in its nal form and have found that (1) its format, citations, and bibliographic style are consistent and acceptable (2) its illustrative materials including gures, tables, and charts are in place and (3) the nal manuscript is satisfactory to the Supervisory Committee and is ready for submission to The Graduate School. Date Lee Hollaar Chair, Supervisory Committee Approved for the Major Department Thomas C. Henderson Chair/Dean Approved for the Graduate Council Ann W. Hart Dean of The Graduate School

5 ABSTRACT The software developer designing a security architecture for a distributed application is often faced with practical constraints that further complicate an already dicult task. These include limited resources and conicting requirements. The goal will often be to simply provide as much eective security as possible, targeted at the end-user security needs. To achieve this goal, the developer must be able to systematically determine where security problems exist, understand the impact of security mechanisms as they are designed, determine which problems have and have not been addressed, explore alternative designs, and build on the architecture in the future. Current approaches to secure system design do not meet these requirements. Although much is understood about many aspects of computer security, little attention has been given to the the issue of how tointegrate this knowledge into a design process of how to generate and maintain a security architecture in a systematic, predictable manner. In this dissertation, this issue is examined in the context of a distributed information retrieval system. The security design problem is analyzed, dening and characterizing its underlying causes and the tools desirable to address it. This is followed by a classication and analysis of current security design approaches in relation to this problem, including a detailed case history of our eorts to employ risk management paradigms, demonstrating their strengths and limitations. A new security design methodology is then presented, whichprovides the desired tools. All aspects of the application, supporting software, hardware, physical environments, and attack scenarios are modeled in a unied, object-oriented manner. An information ow analysis is applied to automatically discover security violations. Safeguards can then be modeled and added to the ow analysis to readily assess their eects and interrelationships. Although the developer must create the application-specic models, the remaining models such as those for the operating system, hardware, environments, and attack scenarios are application-independent, and can evolve over time to represent generic security knowledge bases. These can be utilized by any developer employing this design methodology, regardless of their security background.

6 To Terri, for putting up with me...

7 CONTENTS ABSTRACT ::::::::::::::::::::::::::::::::::::::::::::::::: LIST OF FIGURES ::::::::::::::::::::::::::::::::::::::::::: GLOSSARY ::::::::::::::::::::::::::::::::::::::::::::::::: v xiii xv CHAPTERS 1. INTRODUCTION :::::::::::::::::::::::::::::::::::::::: Overview of this Research ::::::::::::::::::::::::::::::::: Signicance of this Research ::::::::::::::::::::::::::::::: Need for Security in Distributed Systems ::::::::::::::::::::: The Security Design Problem :::::::::::::::::::::::::::::: Fundamental Diculties in Security Design ::::::::::::::: Concerns of the Application Developer ::::::::::::::::::: Security Needs of the Application Developer ::::::::::::::: Current LackofDesignTools :::::::::::::::::::::::::::::: A Proposed Solution ::::::::::::::::::::::::::::::::::::: Road Map to this Dissertation :::::::::::::::::::::::::::::: 7 2. BACKGROUND ISSUES :::::::::::::::::::::::::::::::::: Information Retrieval Systems :::::::::::::::::::::::::::::: What They Are ::::::::::::::::::::::::::::::::::::: The URSA System :::::::::::::::::::::::::::::::::: Security Needs in Information Retrieval :::::::::::::::::: Overview of Related Work ::::::::::::::::::::::::::::::::: Brief Historical Perspective on Computer Security :::::::::: The Bigger Picture :::::::::::::::::::::::::::::::::: THE SECURITY DESIGN PROBLEM ::::::::::::::::::::: Fundamental Diculties in Security Design ::::::::::::::::::: Examples of the Diculties :::::::::::::::::::::::::::: The Lack of a Design Methodology :::::::::::::::::::::: Concerns of the Application Developer ::::::::::::::::::::::: Practical Considerations :::::::::::::::::::::::::::::: End-User Physical Environment :::::::::::::::::::::::: End-User Security Needs :::::::::::::::::::::::::::::: Some Security Design Scenarios ::::::::::::::::::::::::: Design Tools for the Application Developer :::::::::::::::::::: 22

8 4. APPROACHES TO SECURE SYSTEM DESIGN :::::::::::: ALack of Existing Design Tools :::::::::::::::::::::::::::: A Categorization of Current Design Eorts :::::::::::::::::::: Find and Fix Approach ::::::::::::::::::::::::::::::::::: Preventive Design Approach ::::::::::::::::::::::::::::::: Formal Methods ::::::::::::::::::::::::::::::::::::::::: Specication and Verication :::::::::::::::::::::::::: Formal Policy Models :::::::::::::::::::::::::::::::: Guideline Adherence ::::::::::::::::::::::::::::::::::::: Comprehensive References ::::::::::::::::::::::::::::: Guidelines and Standards ::::::::::::::::::::::::::::: Risk Management ::::::::::::::::::::::::::::::::::::::: Safe and Reliable Systems Design ::::::::::::::::::::::::::: Conventional Software Development ::::::::::::::::::::::::: Experience ::::::::::::::::::::::::::::::::::::::::::::: Recent Work Supporting Our Position ::::::::::::::::::::::: Summary :::::::::::::::::::::::::::::::::::::::::::::: RISK MANAGEMENT TECHNIQUES ::::::::::::::::::::: Denition of Terms :::::::::::::::::::::::::::::::::::::: Risk Management ::::::::::::::::::::::::::::::::::: Determine Assets :::::::::::::::::::::::::::::::::::: Determine Possible Threats Against Assets :::::::::::::::: Determine Possible Vulnerabilities ::::::::::::::::::::::: Rank Vulnerabilities in Terms of Risk :::::::::::::::::::: Design Safeguards to Address Vulnerabilities :::::::::::::: A Note on Practical Approaches :::::::::::::::::::::::::::: The Issue of Risk Analysis ::::::::::::::::::::::::::::::::: ATTEMPTS TO EMPLOY RISK MANAGEMENT :::::::::: Starting to List Assets :::::::::::::::::::::::::::::::::::: Initial Approach :::::::::::::::::::::::::::::::::::: Diculties with Listing Assets ::::::::::::::::::::::::: A Relational Assets Structure :::::::::::::::::::::::::: Employing Checklists to Add Structure ::::::::::::::::::: Fundamental Problem with Assets Lists :::::::::::::::::: Threats and Vulnerability Lists ::::::::::::::::::::::::::::: Ill-dened, Less Tangible than Assets :::::::::::::::::::: Threats Lists ::::::::::::::::::::::::::::::::::::::: Vulnerability Lists ::::::::::::::::::::::::::::::::::: The Information Explosion :::::::::::::::::::::::::::::::: Safeguard Design :::::::::::::::::::::::::::::::::::::::: Trojan Horse Example :::::::::::::::::::::::::::::::: The Problem ::::::::::::::::::::::::::::::::::::::: Simplifying Assets and Threats Lists ::::::::::::::::::::::::: Assessing the Problems at This Point :::::::::::::::::::::::: 62 viii

9 6.6.1 Overview :::::::::::::::::::::::::::::::::::::::::: Synopsis of the Issues :::::::::::::::::::::::::::::::: Need for Dynamic Information ::::::::::::::::::::::::::::: The Control Point Approach ::::::::::::::::::::::::::: Data Flow Analysis :::::::::::::::::::::::::::::::::: Dependency Graphs :::::::::::::::::::::::::::::::::: Problems with Dependency Graphs :::::::::::::::::::::: Need for Detailed Dynamic Analysis ::::::::::::::::::::::::: Some Security Holes Provide Insight ::::::::::::::::::::::::: Document List Access Control Filter ::::::::::::::::::::: The Index Spell Command :::::::::::::::::::::::::::: Auto Search and Retrieval Functions :::::::::::::::::::: A Note on Security Policy ::::::::::::::::::::::::::::::::: Assessing the Problems at This Point :::::::::::::::::::::::: Overview :::::::::::::::::::::::::::::::::::::::::: Synopsis of the Issues :::::::::::::::::::::::::::::::: Summary :::::::::::::::::::::::::::::::::::::::::::::: A SECURITY DESIGN METHODOLOGY :::::::::::::::::: Background :::::::::::::::::::::::::::::::::::::::::::: The Focus of These Chapters :::::::::::::::::::::::::: Why a Risk Management Foundation? ::::::::::::::::::: Security Policy :::::::::::::::::::::::::::::::::::::: Determining Assets :::::::::::::::::::::::::::::::::::::: Information Flow Analysis (IFA) :::::::::::::::::::::::::::: The Meaning of Information Flow ::::::::::::::::::::::: Local IFA :::::::::::::::::::::::::::::::::::::::::: How to Produce the LIFA ::::::::::::::::::::::::::::: ALIFA Example :::::::::::::::::::::::::::::::::::: Global IFA ::::::::::::::::::::::::::::::::::::::::: A GIFA Example :::::::::::::::::::::::::::::::::::: Notes on the Flow Analysis Process ::::::::::::::::::::::::: The LIFA Development ::::::::::::::::::::::::::::::: The Flow Analysis ::::::::::::::::::::::::::::::::::: Synopsis ::::::::::::::::::::::::::::::::::::::::::: The Rest of the Story :::::::::::::::::::::::::::::::::::: Application versus the Environment ::::::::::::::::::::: Environment Planned versus Unplanned Operations ::::::::: Application Planned versus Unplanned Operations :::::::::: The Complete Hierarchical Breakdown ::::::::::::::::::: Signicance of this Breakdown ::::::::::::::::::::::::: The Remaining Sections :::::::::::::::::::::::::::::: Viewing the World as Flows ::::::::::::::::::::::::::::::: Environmental Planned Operations :::::::::::::::::::::::::: The Key Modeling Concepts ::::::::::::::::::::::::::: ALayered, Object-based Approach ::::::::::::::::::::::107 ix

10 7.7.3 Explicit vs. Implicit Service Providers :::::::::::::::::::: Objects Providing Explicit Services to the Application ::::::: The Remaining Issues :::::::::::::::::::::::::::::::: The Parasite Concept :::::::::::::::::::::::::::::::: External versus Internal Security Characteristics ::::::::::: Now for the Distributed Aspects :::::::::::::::::::::::: The Physical Environment :::::::::::::::::::::::::::: Explicit Providers to Nonapplication Objects :::::::::::::: Complexity and Reusability :::::::::::::::::::::::::::: Environmental Unplanned Operations :::::::::::::::::::::::: Perspective :::::::::::::::::::::::::::::::::::::::: The Attack Modules (AMODs) ::::::::::::::::::::::::: Details of the AMOD Development :::::::::::::::::::::: Reusable Modules from an Evolutionary Process ::::::::::: Application Unplanned Operations :::::::::::::::::::::::::: What They Are ::::::::::::::::::::::::::::::::::::: Adding Pseudo-Operations :::::::::::::::::::::::::::: The Power of this Modeling Approach :::::::::::::::::::::::: Synopsis of the Design Method at This Point :::::::::::::::::: CALCULATING THE FLOW ANALYSIS ::::::::::::::::::: Introduction :::::::::::::::::::::::::::::::::::::::::::: Roots of the Complexity :::::::::::::::::::::::::::::::::: Approaches to the Flow Analysis Problem :::::::::::::::::::: Security Information Flow Analysis :::::::::::::::::::::: Data Flow Analysis in General ::::::::::::::::::::::::: Petri Net Modeling :::::::::::::::::::::::::::::::::: Algebraic Approaches :::::::::::::::::::::::::::::::: A Simulation-Based Approach :::::::::::::::::::::::::::::: Partitioning the Simulation :::::::::::::::::::::::::::: Security Relevance Information ::::::::::::::::::::::::: The Following Sections ::::::::::::::::::::::::::::::: Simulating the Application Group ::::::::::::::::::::::::::: Application Planned Operations :::::::::::::::::::::::: Application Unplanned Operations :::::::::::::::::::::: Explicit Application Service Operations :::::::::::::::::: How to Drive the Application Simulation ::::::::::::::::::::: Flow Calculations and Policy Checks ::::::::::::::::::::::::: Statically Assigned Variables ::::::::::::::::::::::::::: Nonassigned Variables :::::::::::::::::::::::::::::::: The Key to Policy Violation Calculations ::::::::::::::::: Transport Variables :::::::::::::::::::::::::::::::::: State Variables ::::::::::::::::::::::::::::::::::::: Simulating the Environment Group :::::::::::::::::::::::::: The Environment as Separate from the Application ::::::::: Problems Simulating the Environment Group ::::::::::::::170 x

11 8.9 Searching for Ways to Simplify ::::::::::::::::::::::::::::: The Planned Environment ::::::::::::::::::::::::::::: The Unplanned Environment :::::::::::::::::::::::::: Rate of Change of Application and Environment ::::::::::: Method of Simulation and Flow Analysis ::::::::::::::::::::: Simplifying Application/Environment Interaction ::::::::::: Analysis of This Simplication ::::::::::::::::::::::::: Top-Level FSM (TLFSM) for Synchronization ::::::::::::: Handling ASRVs Across TLFSM States :::::::::::::::::: Complete View of the Flow Analysis ::::::::::::::::::::::::: Brief Review of Types of SRV :::::::::::::::::::::::::: Calculating the Flows :::::::::::::::::::::::::::::::: Initialization Issues :::::::::::::::::::::::::::::::::: Ghost Objects :::::::::::::::::::::::::::::::::::::: Object Relocation ::::::::::::::::::::::::::::::::::: Policy Validation :::::::::::::::::::::::::::::::::::: Notes on Specifying SRV Information :::::::::::::::::::: SAFEGUARD DESIGN ::::::::::::::::::::::::::::::::::: What is a Safeguard? ::::::::::::::::::::::::::::::::::::: Fundamental Safeguard Types :::::::::::::::::::::::::::::: Safeguard Design Techniques ::::::::::::::::::::::::::::::: Issues in Safeguard Design ::::::::::::::::::::::::::::::::: Reconciling the Black-and-White View ::::::::::::::::::::::: Net-eect versus the Design of Safeguards ::::::::::::::::::::: The Problem ::::::::::::::::::::::::::::::::::::::: Trying to Manually Specify Net Eect ::::::::::::::::::: Automatically Assessing the Net Eect ::::::::::::::::::: Specifying Safeguard Design at Three Levels ::::::::::::::::::: The Issue :::::::::::::::::::::::::::::::::::::::::: A Three Level Approach :::::::::::::::::::::::::::::: Safeguard Behavioral Description (SAFE-BD) ::::::::::::: Safeguard Design Descriptions (SAFE-DD) :::::::::::::::: Safeguard Conceptual Description (SAFE-CD) ::::::::::::: Mapping Safeguards into our Model ::::::::::::::::::::::::: Prevention Safeguards :::::::::::::::::::::::::::::::: Detection Safeguards ::::::::::::::::::::::::::::::::: Acceptance Safeguards ::::::::::::::::::::::::::::::: General Audit and Deterrent Safeguards :::::::::::::::::: Untargeted Safeguards :::::::::::::::::::::::::::::::: SUMMARY OF THE DESIGN METHODOLOGY ::::::::::: Information Flow Analysis ::::::::::::::::::::::::::::::::: The Rest of the Story :::::::::::::::::::::::::::::::::::: Viewing the World as Flows ::::::::::::::::::::::::::::::: Environmental Planned Operations ::::::::::::::::::::::::::219 xi

12 A Layered, Object-Based Approach :::::::::::::::::::::: Explicit versus Implicit Service Providers ::::::::::::::::: Modeling Explicit Services to the Application :::::::::::::: Handling the Remaining Issues ::::::::::::::::::::::::: The Parasite Concept :::::::::::::::::::::::::::::::: The Physical Environment :::::::::::::::::::::::::::: Environmental Unplanned Operations :::::::::::::::::::::::: Application Unplanned Operations :::::::::::::::::::::::::: Power of this Modeling Approach ::::::::::::::::::::::::::: Calculating the Flow Analysis :::::::::::::::::::::::::::::: Simulating the Application Group ::::::::::::::::::::::: Driving the Application Simulation :::::::::::::::::::::: Simulating the Environment Group :::::::::::::::::::::: A Way to Simplify This ::::::::::::::::::::::::::::::: Flow Calculations and Policy Checks :::::::::::::::::::: Safeguard Design :::::::::::::::::::::::::::::::::::::::: Reconciling the Black-and-White View ::::::::::::::::::: Net-eect versus the Design of Safeguards ::::::::::::::::: Specifying Safeguard Design at Three Levels ::::::::::::::: Mapping Safeguards into our Model ::::::::::::::::::::::::: Prevention SAFEs ::::::::::::::::::::::::::::::::::: Detection Safeguards ::::::::::::::::::::::::::::::::: Acceptance Safeguards ::::::::::::::::::::::::::::::: General Audit and Deterrent Safeguards :::::::::::::::::: Untargeted Safeguards :::::::::::::::::::::::::::::::: CONCLUSIONS AND FUTURE WORK :::::::::::::::::::: Conclusions :::::::::::::::::::::::::::::::::::::::::::: Future Work :::::::::::::::::::::::::::::::::::::::::::237 APPENDICES A. THE URSA SYSTEM :::::::::::::::::::::::::::::::::::::238 B. SECURITY POLICY MODELS ::::::::::::::::::::::::::::240 C. A RELATIONAL ASSETS LIST ::::::::::::::::::::::::::::247 D. THREAT SOURCES ::::::::::::::::::::::::::::::::::::::256 E. THREAT TECHNIQUES ::::::::::::::::::::::::::::::::::258 F. SECURITY DESIGN PRINCIPLES ::::::::::::::::::::::::261 REFERENCES :::::::::::::::::::::::::::::::::::::::::::::::265 xii

13 LIST OF FIGURES 6.1 Example of Assets Explosion and Hierarchy :::::::::::::::::::: Model for Simplifying Assets and Threats Analysis ::::::::::::::: Control Points ::::::::::::::::::::::::::::::::::::::::::: High-level Flow Diagram for Entire Application ::::::::::::::::: Flow Diagram for Database Loading Operation :::::::::::::::::: Flow Diagram for Generalized System Operation :::::::::::::::: Operation Extended to Distributed Environment :::::::::::::::: Simple Dependency List Example :::::::::::::::::::::::::::: Dependency Diagram with Threats and Vulnerabilities :::::::::::: Full Dependency Diagram with Vulnerabilities :::::::::::::::::: Policy Flow Examples ::::::::::::::::::::::::::::::::::::: Control Flow During Find Operation :::::::::::::::::::::::::: LIFA PseudoCode:::::::::::::::::::::::::::::::::::::::: LIFA Finite State Machine :::::::::::::::::::::::::::::::::: LIFA State Machine with Flows :::::::::::::::::::::::::::::: User Interface LIFA ::::::::::::::::::::::::::::::::::::::: User LIFA :::::::::::::::::::::::::::::::::::::::::::::: World View of Application and its Environment ::::::::::::::::: Environment with Planned and Unplanned Operations :::::::::::: Application and Environment Planned/Unplanned Distinction :::::: Global Binding Table :::::::::::::::::::::::::::::::::::::: Model of Communication System ::::::::::::::::::::::::::::: Model of Nondistributed Filesystem ::::::::::::::::::::::::::: Model of Distributed Filesystem ::::::::::::::::::::::::::::: Simple Parasite MonOS :::::::::::::::::::::::::::::::::::: Example of Utility of MonOS :::::::::::::::::::::::::::::::: Parasite Extensions to Global Binding Table ::::::::::::::::::::120

14 7.18 Global Binding TablewithParasite Bindings ::::::::::::::::::: Operating System with Memory Protection and Authentication ::::: Modeling Four Operating Systems with Simple Variables :::::::::: Distributed Operating System ::::::::::::::::::::::::::::::: Distributed OS with Memory Protection and Authentication ::::::: Physical Room Environments :::::::::::::::::::::::::::::::: Open vs. Secure Node ::::::::::::::::::::::::::::::::::::: Arbitrary Room :::::::::::::::::::::::::::::::::::::::::: An Open Node in a Secure Room :::::::::::::::::::::::::::: Secure Room After Hours ::::::::::::::::::::::::::::::::::: Arbitrary Person ::::::::::::::::::::::::::::::::::::::::: Two Instances of an Arbitrary Person ::::::::::::::::::::::::: Fault Tree Approach :::::::::::::::::::::::::::::::::::::: AMOD of Node and Disk Attack ::::::::::::::::::::::::::::: Node AMOD with Variables from Node and Person PMODs ::::::: Examples of Safeguard Interaction with AMODs/PMODs ::::::::: Printer with Line to Computer :::::::::::::::::::::::::::::: Printer Line with State Variable Modeling EMP ::::::::::::::::: Operating System AMOD :::::::::::::::::::::::::::::::::: FragmentofLIFA for User Interface :::::::::::::::::::::::::: Pseudo-Operation Added to LIFA :::::::::::::::::::::::::::: Auto-Search Feature ::::::::::::::::::::::::::::::::::::::: UserIF and Index Flows :::::::::::::::::::::::::::::::::::: Simple Example of Net Eect versus Design ::::::::::::::::::::216 B.1 Security Policy Denes Responsibility :::::::::::::::::::::::::246 xiv

15 GLOSSARY AMOD - Attack modules. Models of the unplanned operation of the environment, consisting of attacks against environmental objects, utilizing the parasite approach. ASRV - Accumulated SRV. The ASRV attribute of a variable accumulates the set of SRVs that haveowed into that variable, generally for the lifetime of a given static environment. See also TSRV. BLP - The Bell and LaPadula security policy model. CFSM - Communicating nite state machine. DOM - Dominates relation. A class X dominates a class Y I X.level Y.level and X.category-set Y.category-set. EMP - Electromagnetic Pickup. FSM - Finite state machine. IC -Integrity Class. A value identifying the level of integrity of an object(e.g., high or low). See also SC. IFA - Information Flow Analysis. GIFA - Global information ow analysis. The ow analysis of a set of communicating FSMs (each represented with a LIFA model). LIFA - Local information ow analysis. The FSM ow model for an application or environmental module. OS - Operating system. MLS - Multi-level secure system. A system in which data and users at dierent security levels can simultaneously exist, but which controls access based on a security policy. PCheck -Policy check. The algorithm to determine if a given ow upholds or violates the security policy. PMOD - Models of the planned operation of the environment, including software and the physical environment, often utilizing the parasite approach.

16 SAFE - Safeguard. Any mechanism that attempts to reduce loss due to an undesirable event (e.g., a security policy violation). SC - Secrecy Class. A value identifying the level of secrecy of an object (e.g., top secret or unclassied). See also IC. SECREL - Refers to the general security relevant aspects of an object or situation (e.g., Is SECREL information present? What are the SECREL aspects of this object?). See also SRV. SRV - The collective security relevance value of an object. For our simple policy, this is the value of its secrecy class (object.sc) and integrity class (object.ic). See also SECREL. SSRV - Static SRV. The SSRV attribute of a variable is an SRV thatismanually assigned to fundamental assets. All other variables have NULL SSRVs. TCSEC - (Orange Book) Trusted Computer Security Evaluation Criteria. TEMPEST - Secured against information leakage by emission of electromagnetic radiation. TLFSM -Top level FSM that drives both the application and the environment, allowing the environment to change over time. TSRV -Transport SRV. The TSRV attribute of a variable accumulates the set of SRVs that have owed into that variable, independent of the lifetime of the current static environment. See also ASRV. xvi

17 CHAPTER 1 INTRODUCTION 1.1 Overview of this Research The number of distributed computer applications is increasing, along with the need for security in such applications. Our research began as an eort to design a security architecture for a distributed information retrieval system. This system was based on the Utah Retrieval System Architecture (URSA), a message-based, loosely coupled design, with processes expected to be distributed in a heterogeneous computing environment, ranging from small LANs to global information networks. We faced practical constraints common to most software developers such as limited resources, a previously existing application design, conicts between functionality and security, lack of control of the target environments, and variable end-user security needs. Thus, rather than trying to provide some xed level of security such as targeting one of the government specied evaluation levels, the goal was simply to provide as much eective security as possible, targeted at the end user security needs essentially to see how much could be provided for how little. This would be a common goal for many small system developers facing the same practical constraints. The desire was to drive the security architecture design directly from the security requirements, and to understand precisely what it did, and did not address. However, there is a fundamental diculty in moving from a set of security requirements to a design which enforces them, and in understanding what a particular design achieves. The diculty isthateach single security requirement actually embodies both a positive and negative requirement. The positive requirementis the simple functional need, while the negative one is the implicit requirement that nothing be able to subvert the positive requirement. This greatly complicates the normal design process. To achieve our goals, tools were needed that allow one to start with their security requirements, to systematically determine where security problems exist, to understand the net eects of security mechanisms as they are designed, and to readily explore alternative designs. One also must be able to build on the security architecture in the future, as the application or security needschange, andasdevelopment personnel change. This implies the need for clear records of these issues, especially what has and has not been addressed and why. Essentially this is no more than one would like in designing any software system. We discovered that current approaches to the design of secure systems simply do not meet these needs, especially for the small developer. Furthermore, very little

18 attention has been given to providing for these needs, or even to acknowledging their existence. We undertook a thorough investigation of how secure systems were being developed, and classied the approaches into a number of broad categories which were then analyzed in terms of our needs. Although many dierent approaches achieved many dierent goals, the only one that addressed the security design process in a well-structured manner aligned with our goals was that of risk management. However, this proved nearly impossible to apply to the software design process of distributed, dynamic systems of the URSA class. It became clear that new design tools were needed if there was to be any hope of the small system developer approaching the security design problem in awell-structured manner, and of producing a design with a solid understanding of what has and has not been addressed. As a result of extensive attempts to apply risk management and other approaches to the design problem and analyzing the diculties and underlying causes, we have developed a proposal for a new design methodology which addresses many of these needs. The framework of the methodology provides the same structured approach as risk management. However, the proposed methods and tools to achievethisgoalare very dierent. The methodology consists of modeling all elements of the application and its operating environment in an object-based manner. The environmental elements require some novel abstractions, simple fault tree analysis, and heuristics. A high-level information ow analysis is then applied to this model through a simulation-based approach. This dynamically denes the assets and indicates where vulnerabilities exist. From this information, safeguards can be designed to address the vulnerabilities. These are also modeled as objects, but at three distinct levels of abstraction, allowing us to readily separate the securityarchitecture from the application, to assess the eects and interrelationship of safeguards, and to readily explore alternative designs. Although the application modeling is specic to the target application, much of the support environment modeling can be done generically, tailorable to specic target environments by simply setting characteristic variables. Thus, small application developers can make use of environmental models that can evolve over long periods of time, representing the collective security expertise of many individuals, essentially becoming a securityknowledge base that the developer can plug directly into his design process. The following section discusses the signicance of this research. The remaining sections are an overview of the dissertation, followed by a road map to the remaining chapters. 1.2 Signicance of this Research This research did not proceed by addressing an already well-understood problem. Both the problem and corresponding lack of adequate tools were discovered as a result of the original intended research, resulting in the need to propose a new design methodology. As such, the signicance of this work encompasses three aspects. 1. The precise denition, explication, and characterization of the fundamental security design problem, its underlying causes, and tools to address it. 2

19 A necessary rst step in solving a problem is to clearly understand it. The security design process is analyzed, identifying the fundamental diculties, and exploring these in the context of the small developer with limited resources and other pragmatic constraints. This leads to a characterization of the needs, as well as the tools that would be desirable for a well structured, well documented security design process. 2. Classication and analysis of current security design approaches and their relationship to the above needs, including a detailed case study of our experience employing a risk management paradigm. Although much is understood about many specic aspects of security, little discussion has been devoted to the actual design process in the literature, with no eort to attempt any such classication. From our classication and analysis, it is evident thatvery few structured approaches have been documented, and of these, the risk management paradigm appeared most directly applicable to the problem. A case history of our attempts to employ this and other related techniques is presented. Critical analysis of this experience provides a better understanding of the necessary tools and how they might be realized, and provides a foundation for the design methodology. 3. The description and analysis of our proposed security design methodology, which addresses many of our goals and provides a solid foundation for future research in this important, but neglected area. A new design methodology is proposed, which addresses many of needs discovered above, providing tools for a systematic approach to the design and maintenance of a security architecture for a distributed software application. Through analysis of numerous examples, its strengths, limitations, and directions for necessary future research are discussed. The methodology addresses the full range of issues involved in the security design process. This includes high-level security requirements, determining where security problems exist, understanding the impact of security mechanisms as they are designed, determining which problems have and have not been addressed, allowing one to readily explore alternative designs, providing the ability tobuild on the security architecture in the future, and incorporating security issues related to software, hardware, the physical environment, and personnel. Due to the extremely large scope of this undertaking, we could not focus in depth on the individual aspects. However, there was no alternative but to address the \big picture," since this is precisely what is lacking in the literature. For decades the security community has been undertaking detailed, focussed research into specic areas of security, while largely ignoring the design process by which this can all be integrated in a structured manner. During the development of this methodology, all concepts were extensively evaluated in the context of the existing URSA system, which is complex enough to well represent this class of distributed systems. This included extensive walkthroughs of all concepts, modeling all of the fundamental URSA modules and functions, detailed exploration of all security issues that came to our attention, proof of concept programming where walkthroughs were not conclusive, and the implementation of numerous security mechanisms for the URSA system. All of this was essential to the creation of a viable methodology. 3

20 Given the scope of the problem and our limited resources, it was not possible to produce a full implementation of the necessary tools. However, it is believed that the groundwork has been clearly laid for this next step. All of the above contributions should provide a necessary solid foundation for future research inthis important, but neglected area. 1.3 Need for Security in Distributed Systems Many organizations are becoming increasingly aware of the benets of networking with other organizations or systems, and more and more applications are being designed to run in a distributed environment. The need for security in such distributed computer applications is increasing for many reasons. The costs of security breaches can be considerable, both in monetary and human terms. For example, the estimated cost to the National SecurityAgencyofchanging a single compromised code word was a quarter million dollars [15]. Although that is an eccentric example, consider the personal damage and lawsuits that could arise from unauthorized release of medical records, or the legal judgement errors that could occur, or mistrials that could be declared, if legal information was found to have been compromised. Further, without adequate protection mechanisms, organizations are generally unwilling to share even nonprivate information, especially with the government, for fear of also releasing private information. This can result in tremendous duplication of eort and ineciency [201]. Certainly, the growing interconnection of systems and the growing amount of information being committed to these systems can only increase the possibility of damage, especially from purely malicious attacks such as worms or viruses. Such attacks can undermine the entire cooperative foundation on which many eorts are built [191]. 1.4 The Security Design Problem In this section we discuss the fundamental diculties in security design, the additional constraints faced by the application developer, and the resulting needs for security design tools. These issues are discussed in detail in Chapter Fundamental Diculties in Security Design A fundamental diculty in designing a secure system lies in the initial task of moving from a set of security requirements to a design which enforces them. The reason is that each security requirement actually embodies what we have termed both a positive and negative requirement. For example, in the simple requirement that \all users must login," the positive requirement is that some login mechanism is required. The negative requirement is that there be no other way toenter the system, and further, that the login mechanism itself be protected from tampering. Not only must the design satisfy the obvious (positive) functional requirements, but it must also allow nothing else to occur which could negate those functions.

21 This greatly complicates the normal process of system architecture design, since enforcing the negative requirement can involve many other areas of the system far removed from those supporting the positive requirement. For example, whereas the above positive requirement could be met with a simple login program that accepts a name and password, protecting that login mechanism may require that a wide range of issues be addressed, such as encryption of network messages, employing a trusted kernel, enforcing specic access controls on the les involved, and enforcing controls on the life cycle of the software. Furthermore, the negative requirements will often necessitate a more complex, less intuitive design to support the positive requirement as well. For example, the simple name/password scheme may have to be changed to a challenge/response approach involving a remote authentication server. Consequently, not only is it dicult to design for the negative requirements, but it can be very dicult afterwards to understand the reasons behind a given design. What security purpose does each piece serve, and indeed, which pieces are even part of the security architecture? More importantly, it can be extremely dicult to determine the level of security attained. This is exacerbated by the following fact. If something is overlooked or done incorrectly in a general application design, the end users will generally complain. If something is overlooked in the security design, it is doubtful that an attacker will intentionally let us know Concerns of the Application Developer In many applications, the developer is faced with pragmatic concerns that further complicate the task of addressing the security issue. Necessary resources, such as personnel, development time, and expertise, may be very limited. Security may well play a secondary role to other attributes of the application, such as ease of use, performance, and maintenance. It mayhave to be added in an evolutionary manner, as best it can. End-user needs can also vary widely, from security requirements and physical environment, to customized applications. Lastly, the security architecture must be maintained as the application and end-user security requirements continue to evolve and as development personnel also change. These issues all add to the cost of security. Thus, the goal of the designer will probably not be to provide some ultimate level of security, nor even to conform to some government security guideline or standard. It will more likely be to simply provide as much eective security tailored to the end user needs as is possible, given all the other considerations to see how much security hecanprovide for how little cost Security Needs of the Application Developer The combination of the application developer concerns with the general security design diculties creates a major problem for software developers attempting to address the security design issue in a structured, predictable manner. They will need design tools that allow them to: Systematically discover where security problems exist, and why, at any point in the design process.

22 6 Readily determine the eects of security mechanisms as they are designed. Explore the viability of alternative designs or the eects of altered requirements in a systematic manner. Maintain records so the security architecture can be later understood and readily adapted as changes occur in the application, or in the security requirements, especially as development personnel also change. Achieve these goals with limited resources. Essentially, we are suggesting no more than one already expects in conventional software development the ability to clearly see the required functions, to know which have andhave not been addressed, to experiment with optional designs, and to document the work. It is the negative requirement aspect, and the resulting complexity that exists in a security architecture, that complicate these issues. However, for the application security developer, these capabilities are not luxuries. Without them, the design process simply can not be approached in any systematic, predictable manner. 1.5 Current Lack of Design Tools In developing a security architecture for the URSA system, we faced the same problems and needed the same tools as discussed above. Given the wealth of information available on many dierent aspects of computer security, such as research eorts in cryptography, network security, user authentication, and formal methods, as well as government guidelines and commercial products, we hoped to simply integrate this information into our needs. However, we discovered that the process of designing secure systems has not been well investigated at all, and that current methods of designing secure systems simply do not provide for the above goals. Essentially there has been a general lack of attention given to the fundamental issue of how one generates the design of a secure computer system in a systematic, predictable manner. The focus has been more on the individual pieces (e.g., cryptography orauthentication), or after-the-fact analysis (e.g., verication), than on the process by which the system is designed. A similar situation would exist if general software developmentwere described only in terms of the software tools to write programs, or the methods of their formal verication, rather than the design methodologies employed to create the programs in the rst place. This is discussed in Chapter 4. In the end, the only structured approach to the design process is that of classical risk management. This attempts to provide structure through the systematic determination of assets, evaluation of security threats and vulnerabilities, and the design of safeguards to address these. This is discussed in Section 4.7 and Chapter 5. However, this does not apply well to detailed software design, especially in dynamic distributed systems where assets can rapidly change form and location. Even recent attempts to extend the risk management approach for software issues have severe problems. A detailed case study of our attempts to utilize these techniques in the URSA security design, and the resulting diculties, is presented in Chapter 6.

23 1.6 A Proposed Solution As a result of our eorts to employ existing design approaches, it became apparent that new design tools were required. The developer essentially needs tools to provide the same basic services that traditional risk management approaches attempt to provide, but which will work in this dierent environment. We propose a new design methodology that addresses many of the above goals, providing tools that allow the securityarchitecture to be developed and maintained in a systematic, predictable manner. The framework of the methodology provides the same structured approach as risk management assets are determined, security vulnerabilities located, and safeguards designed to address them. However, the methods and tools we use to realize this process are very dierent. First, all elements of the application and its operating environment are modeled in a layered, object-based manner. Although mapping the application to these models is relatively mechanical with simple abstractions, the environmental element models require some novel abstractions and simple fault tree analysis in order to integrate with our needs. A high-level information ow analysis is then applied to this model. After considering a number of options, a simulation-based approach was chosen, employing heuristics to maintain tractability. This analysis automatically and dynamically denes the assets and indicates where vulnerabilities exist. This eliminates the need to manually list assets, trace operations, or enumerate vulnerabilities, and automatically adjusts to changes in the application or security architecture. From this information, safeguards can be designed to address the violations. These are also modeled as objects, but at three levels of abstraction, allowing us to readily separate the security architecture from the application, to assess the eects and interrelationship of safeguards, and to readily explore alternative designs. Of course, one must still design the security mechanisms, based on an understanding of general security design techniques, or know to employ previously existing designs, but the tools provide a clear indication of what needs to be addressed, how the mechanisms interrelate, and the eect of changes to the security or application architectures. Note that although the application modeling is specic to the target application, the support environment modeling can be done generically, tailorable to specic target environments by simply setting characteristic variables. Thus, small application developers can make use of environmental models that can evolve over long periods of time, representing the collective security expertise of many individuals, essentially becoming a security knowledge base that developers can plug directly into their design process, regardless of their securitybackground. Details of the methodology are discussed in Chapters 7, 8 and 9, with a complete summary in Chapter Road Map to this Dissertation 1. Introduction 2. Background - Background on information retrieval systems and a brief overview of related work in security and distributed systems. 7

24 3. The Security Design Problem - Address rst goal. The precise denition, explication, and characterization of the fundamental security design problem, its underlying causes, and tools to address it. 4. Current Approaches to Secure System Design - Begin second goal. Classication and analysis of current security design approaches and their relationship to the above needs. Summary at end. 5. Risk Management Techniques -Continue second goal. Describes the foundations of risk management and denes terminology. Necessary background for following chapter. 6. Attempts to Employ Risk Management Techniques - Finish second goal. A detailed case history of our eorts to employ risk management and related techniques in the design process, evaluating the strengths and weaknesses, and gaining insight into what is needed. Summary at end. 7. A Security Design Methodology - Begin third goal. The proposed security design methodology. Introduces the ow analysis approach and policy issues, and describes how all elements of the application and its environment are modeled. 8. Calculating the Information Flow Analysis - Continue third goal. Discusses the problems with realizing the necessary ow analysis in practice, and the details of the chosen simulation-based approach. 9. Designing Safeguards - Finish third goal. Describes the method of designing safeguards, modeling them, and including them in the analysis. 10. Summary of Design Methodology - Summarizes the entire design methodology. This may be read prior to the previous three chapters as an overview, if one accepts that much will be out of context. 11. Conclusions and Future Work 12. Appendices - Covering the URSA system, security policy models, security design principles, and specic issues for Chapter 6. 8

25 CHAPTER 2 BACKGROUND ISSUES In this chapter, distributed information retrieval systems, including the URSA system and associated security needs are discussed, since this research was undertaken in this context. A brief historical perspective on computer security is then presented, followed by a broader look at the wide range of issues related to this dissertation with references to later sections containing more detailed discussions. 2.1 Information Retrieval Systems What They Are Information retrieval systems allow the storage of large amounts of full-text information, such as scientic journal articles, and the subsequent searching for documents that pertain to a desired area (see [175, 108] for an introduction to this topic). Unlike database management systems, the data in information retrieval systems are less well-/-structured. Rather than rigidly-dened elds, the text database consists of loosely-specied contexts, such as title or abstract. Queries generally consist of boolean combinations of words or phrases, with possible context and proximity constraints. For example, one maysearch for documents containing the phrase nuclear power. If the number of returned documents appears too small, one may change the query to search for the words nuclear and power within the same sentence or paragraph. However, to avoid missing relevant material which does not employ that particular choice of words, one may expand nuclear to the logical union of (nuclear OR atomic OR fusion) andpower to the union of (power OR energy OR plant). Searches generally proceed in an interactive manner, observing results and modifying query expressions, to focus in on the relevantdocuments. A practical system may need to store a large amount of information. For example, the collected laws of Utah require approximately 20 megabytes (MB) (or at least 40 MB with court decision annotations). The text of all court decisions would take tens of gigabytes (GB). It is estimated that the retrieval systems operated by Mead Data Central, including legal, news, and patent information, contain over 100 GB [190]. The large database size, coupled with the need for a more complex search through less-structured data, complicates the implementation of an information retrieval system with good response time. Parallel searching of backend databases, and