Seventh USENIX Security Symposium Proceedings

268 Pages·107.1 MB·English

by  USENIX Association

USENIX Association
Proceedings of the
Seventh USENIX Security Symposium
January 26-29,1998
San Antonio, Texas
Conference Organizers
Program Chair Readers
Avi Rubin, AT&T Labs - Research Katherine T. Fithen, CERT
Trent Jaeger, IBM Watson Labs
Program Committee
Carlisle Adams, Entrust Technologies Invited Talks Coordinator
Dave Balenson, Trusted Information Systems
Greg Rose, QUALCOMM Australia
Steve Bellovin, AT&T Labs — Research
Dan Boneh, Stanford University The USENIX Association Staff
Diane Coe, Concept Five Technologies
Ed Felten, Princeton University
Li Gong, JavaSoft
Peter Honeyman, CITI, University of Michigan
Hugo Krawczyk, Technion
Jack Lacy, AT&T Labs - Research
Hilarie Orman, DARPA/ITO
Mike Reiter, AT&T Labs - Research
David Wagner, University of California, Berkeley
External Reviewers
Charles J. Antonelli Benny Pinkas
Dirk Balfanz Tal Rabin
Matt Blaze S. Rajagopalan
Daniel Bleichenbacher Jim Rees
Dennis K. Branstad Pankaj Rohatgi
Ran Canetti Greg Rose
Pau-Chen Cheng David Safford
Drew Dean Rich Salz
Shai Halevi Douglas Lee Schales
John loannidis Richard Schroeppel
Dave Kormann Alan T. Sherman
Kevin Lai Michael Stolarchuck
John P. Linderman Martin Strauss
David P. Maher Matthew Undy
Petros Maniatis Dan Wallach
Patrick McDaniel Michael Wiener
John Mitchell Robert Zuccherato
Femando C N Pereira
Table of Contents
Seventh USENIX Security Symposium
January 26-29,1998
San Antonio, Texas
Wednesday, January 28
Opening Remarks
Avi Rubin, AT&T Labs - Research
Keynote Address:
Security Lessons From All Over
Bill Cheswick, Lucent Technologies, Bell Labs
Architecture
Session Chair: Steve Bellovin, AT&T Labs - Research
A Comparison of Methods for Implementing Adaptive Security Policies
Michael Carney and Brian Loe, Secure Computing Corporation
T h e C R I S I S W i d e A r e a S e c u r i t y A r c h i t e c t u r e 1
Eshwar Belani and Amin Vahdat, University of California, Berkeley; Thomas Anderson, University of Washington,
Seattle; Michael Dahlin, University of Texas, Austin
Intrusion Detection
Session Chair: Mike Reiter, AT&T Labs — Research
Bro: A System for Detecting Network Intruders in Real-Time -
Vem Paxson, Lawrence Berkeley National Laboratory
Cryptographic Support for Secure Logs on Untrusted Machines -
Bruce Schneier and John Kelsey, Counterpane Systems
StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks (
Crispan Cowan. Calton Pu. Dave Maier, Jonathan Walpole, Peat Bakke, Steve Seattle, Aaron Grier, Perry Wagle,
and Qian Zhang, Oregon Graduate Institute of Science & Technology; Heather Hinton, Ryerson Polytechnic
University
Data Mining Approaches for Intrusion Detection
Wenke Lee and Salvatore J. Stolfo, Columbia University
Network Security
Session Chair: Dave Balenson, Trusted Information Systems
Securing 'Classical IP Over ATM Networks'
Carsten Benecke and Uwe Ellermann, Universitdt Hamburg
A Java Beans Component Architecture for Cryptographic Protocols 107
Pekka Nikander and Arto Karila, Helsinki University of Technology
S e c u r e V i d e o c o n f e r e n c i n g 1 2 3
Peter Honeyman. Andy Adamson, Kevin Coffman, Janani Janakiraman, Rob Jerdonek. and Jim Rees,
University of Michigan, Ann Arbor
Thursday, January 29
Distributed Systems
Session Chair: Hilarie Orman, DARPA/ITO
Unified Support for Heterogeneous Security Policies in Distributed Systems 131
Naftaly H. Minsky and Victoria Ungureanu, Rutgers University
Operating System Protection for Fine-Grained Programs 143
Trent Jaeger, Jochen Liedtke, and Nayeem Islam, IBM T.J. Watson Research Center
Expanding and Extending the Security Features of Java I59
Nimisha V. Mehta, The Open Group; Karen R. Sollins, MIT laboratory for Computer Science
World Wide Web Security
Session Chair: Diane Coe, Concepts Technologies
To w a r d s We b S e c u r i t y U s i n g P l a s m a 1 - 7 3
Annette Krannig, Fraunhofer-Institute for Computer Graphics IGD
Security of Web Browser Scripting Languages: Vulnerabilities, Attacks, and Remedies 187
VinodAnupam and Alain Mayer, Bell Laboratories, Lucent Technologies
F i n i t e - S t a t e A n a l y s i s o f S S L 3 . 0 2 0 1
John C. Mitchell, Vitaly Shmatikov, and Ulrich Stern, Stanford University
Cryptography
Session Chair: Carlisle Adams, Nortel
Certificate Revocation and Certificate Update 217
Moni Naor and Kobbi Nissim, Weizmann Institute of Science
Attack-resistant trust metrics for public key certification 229
Raph Levien and Alex Aiken, University of California, Berkeley
Software Generation of Practically Strong Random Numbers
.243
Peter Gutmann, University of Auckland
Preface
In the last year, the popular press has become enamored with computer security. Hardly a week goes by without an
article in the New York Times or the Wall Street Journal about how susceptible the Internet is to hacking, or how
someone has broken into some "highly secure" site. All of this press presents exciting opportunities for researchers
in the fields of computer security and cryptography, as funding opportunities abound. More and more companies
are realizing the importance of securing their networks, their data and their computers. The long-awaited electronic
commerce is becoming a reality, and people are actually making money on the Net.
However, for some reason, more and more insecure systems are deployed, giving the press more to feed on. It is a
positive feedback loop. The 7th USENIX Security Symposium is a place where the latest research in practical
system security is presented and discussed. It is our place to try to break the loop.
As I look over the 65 submissions we received this year (an all-time high), I notice several trends. The topic of
greatest interest is the security of mobile code. The advent of Java and other platform-independent languages has
enabled computational models that only existed in theory to be rapidly developed and deployed. The inherent
security risks have jump-started researchers into action.
There is also a renewed interest in intrusion detection, as new systems far superior to their predecesors are
implemented. Several such systems are presented this year. We also have some papers on the security of the World
Wide Web.
As you can see, this is a vibrant, dynamic time for our field. It is my hope that this conference and these
proceedings will enhance the resources in our community.
Aviel D. Rubin
Program Chair
: ^ L
A Comparison of Methods for
Implementing Adaptive Security Policies
Michael Carney Brian Loe
Secure Computing Corporation Secure Computing Corporation
2675 Long Lake Road 2675 Long Lake Road
Roseville, Minnesota 55113 Roseville, Minnesota 55113
e-mail: [email protected] e-mail: [email protected]
Abstract 1 Introduction
Real organizations do not have static security poli
The security policies for computing resources must
match the security policies of the organizations that cies. Rather, they have dynamic policies that
use them; therefore, computer security policies must change, either as a matter of course, or to allow
be adaptive to meet the changing security environ them to react to exceptional circumstances. The
ment of their user-base. This paper presents four computing resources of these organizations must re
methods for implementing adaptive security poli flect the organization's need for security while af
cies for architectures which separate the definition fording users the flexibility required to operate in a
of the policy in a Security Server from the enforce changing environment.
ment which is done by the kernel. The four methods
Any implementation of adaptive security presents
discussed include its own set of advantages and disadvantages. While
this paper compares four methods for implementing
• reloading a new security database for the Secu
adaptive security policies, it is important to keep the
rity Server, needs of the organizations in mind in order to ade
• expanding the state and security database of quately compare implementations of adaptive secu
the Security Server to include more than one rity. Section 2 outlines some of the possible scenar
ios requiring adaptive security policies and provides
mode of operation,
a number of examples of adaptive policies that are
• implementing another Security Server and useful to the later discussion. Section 3 describes
handing off control for security computations, the range of possible implementations for adaptive
and security given the basic security architecture of the
DTOS prototype and provides a brief sketch of the
• implementing multiple, concurrent Security
implementations discussed in Section 5. Section 4
Servers each controlling a subset of processes.
provides more background on DTOS, which was
used to implement each of the four methods de
Each of these methods comes with a set of trade
scribed in this paper. Section 5.1 describes the cri
offs: policy flexibility, functi.>nal flexibility, security,
teria against which implementations of adaptive se
reliability, and performance. This paper evaluates
curity may be measured. The final subsections of
each of the implementations with respect to each
Section 5 describes in greater detail the four spe
of these criteria. Although the methods described
cific implementations researched at Secure Comput
in this paper were implemented for the Distributed
ing Corporation and evaluates each with respect to
Trusted Operating System (DTDS) prototype, this
the criteria from Section 5.1.
paper describes general research, and the conclu
sions drawn from this work need not be limited to
that development platform.^
^ This work was supported by Rome Laboratory contracts
F30602-95-C-0047 and F30602-96-C-0210. Portions of the
DTOS Overview found in Section 4 appeared in (SKTC96].
USENIX Association Seventh USENIX Security Symposium - January 26-29, 1998 1
2 Motivating Examples for Adaptive
Role-based security policies form another class of
Security adaptive security policies. A role is distinguished
from a task in that an individual has an on-going
need to complete a set of tasks. (See [SC96],
The first example of adaptive security consists of
[FCK95], and [Hof97].) In commercial settings,
organizations that need to change their policies at
roles may be used to enforce separation of duties
regular intervals. For example, a bank may have one
[CW87]. For example one role may be granted au
security policy enforced during business hours and
another policy enforced after hours. The business thority to issue purchase orders while another has
hours policy would grant broad sets of permissions authority to pay for those purchases. However, for
small companies it may be necessary for one indi
to various sets of employees in order complete nor
vidual to perform actions in more than one role,
mal banking transactions; however, a more restric
tive policy would be in effect after hours to prevent though not necessarily at one time to provide the
proper controls and oversight. In military opera
system users from altering banking data in unin
tions it may be necessary for an individual to per
tended ways.
form actions in more than one role simultaneously.
Some organizations may need to release sensitive For example, in the Navy the role of the Watch Of
documents at specific times. For commercial orga ficer on a ship may be performed by the Chief En
nizations it may be a press release of new product in
gineer. This person may need to fulfill both roles
formation that must not be available from the web simultaneously. Similarly, the Command Duty Of
server until a specified time. Military organizations ficer may need to perform actions reserved for the
may have similar needs to make information avail Commanding Officer in times of emergency. Priv
able to allies on a timed-release basis. Conversely,
ilege to invoke these dual roles should be reserved
today's commercial partner or military ally may be for extreme situations.
an tomorrow's adversary, in which case they should
Multi-level security (MLS) rules as applied in the
not be allowed to receive various forms of informa
military and intelligence communities form a final
tion.
class of examples of security policies that must be
Other organizations may need to adapt their se
adaptive. Adaptive policies may allow either a re
curity policies based on the tasks performed by laxation or selective hardening of confidentiality re
the users. For example, in the banking example strictions. Under MLS rules all objects are labeled
cited above, some tasks may be critical to perform
according to the sensitivity of the data they con
despite the more restrictive policy enforced after tain (e.g., Top Secret, Secret, Confidential, and Un
5:00 PM. High-priority or urgent tasks may need
classified). By the simple security rule, users and
to be granted special permissions to complete on
subjects are allowed access to observe objects only
going operations despite the general change of pol if their clearance level is equal to or exceeds the
icy. Other task-based policies may make use of an sensitivity of the object (see [BL73]). During an
assured pipeline, like that proposed by Boebert and
emergency it may be necessary to consolidate lev
Kain [BK85]. Assured pipelines address situations els into two levels: one for Secret and Top Secret
in which a series of tasks must be performed in a files, and another for the remainder. Thus, under
particular order and the control flow must be re the relaxed rules, someone formerly cleared for Se
stricted. An adaptive policy might change the set cret could access files formerly labeled as Top Se
of permissions associated with a single process as cret. For example, military officers may only have
it completes a series of operations. As the process clearance to the Secret level, but once their troops
completes one operation, the permission set changes are under fire, they may need to access Top Secret
to allow the process to complete the next operation information such as the location or capabilities of
but to prevent it from revisiting any objects that
enemy forces. Conversely, confidentiality rules and
it needed for earlier operations. A related secu other security measures could be "hardened" based
rity policy would be the Chinese Wall introduced on DEFCON alert status or following detection of
by Brewer and Nash [BN89], which is intended to a possible intrusion. There are a number of ways to
prevent conflicts of interest in commercial settings. "harden" a system. For example, one could increase
Briefly, under a Chinese Wall security policy a sub internal controls, perform full audits rather than se
ject may initially be allowed permission to an entire lective audits, or require additional authentication
class of objects, but as soon as the subject accesses
measures.
one element of the class, permissions to access any
other object of that class are denied.
2 Seventh USENIX Security Symposium - January 26-29, 1998 USENIX Association