INTRODUCTION

Computer systems and networks are rife with vulnerabilities. Amateur hackers are probing worldwide lists of IP addresses and apparently regularly succeed in penetrating and taking control of many computers. More experienced hackers and, probably, nation states are penetrating our systems without our knowledge. The attacks we do know about are based on well-known vulnerabilities that we know how to fix but have not done so.

When it comes to computers and networks we seem to have failed to apply our past experience to new designs. We repeat the same failures again and again. Indeed, the ubiquitous buffer overflow vulnerability accounts for more than fifty percent of all attacks reported by the Carnegie Mellon CERT. It is as if every bridge we built suffered from the same flaw that caused the collapse of the Tacoma Narrows Bridge. Granted, computer security failures have seldom if ever been responsible for loss of life, but they surely have been responsible for extensive financial loss. Why haven't we been able to get this right?

Are information security engineers really engineers? Or are we artisans, craftsman, or magicians? As engineers we would be far more concerned about doing it right the first time than we seem to be. We would be more serious about proper requirements identification. We would be more serious about desiderata, specification, and simplicity, not to say elegance, of design. We would be concerned about sound assembly and integration; about rigorous, disciplined, systematic, and effective testing and acceptance. We would be concerned about good practice. Engineers worry about the use of standard, intuitive, and obvious interfaces and controls. Engineers are concerned about taking responsibility for one's work, supervising the work of others, and passing on the culture to the tyros.

Engineering is not just about escape mechanisms or recovering from errors (vulnerabilities, bugs, etc.). Security engineering should not be about dealing with the vulnerability of the day; rather it should be about building robust systems in the first place. We must also be aware that we will probably not be effective if we focus only on the technical flaws of implementations rather than the fundamental flaws rampant in law, policy, management and user understanding of the problem.

The Applied Computer Security Associates (ACSA) is sponsoring a workshop to examine engineering fundamentals, the principles and practice of designing and building secure systems. The workshop will look at where we have been in security engineering (formal methods, Orange book, Common Criteria, penetrate and patch, Certification and Accreditation, Defense in Depth) and where we should go. The workshop will consider such questions and issues as:

• How can we do better at engineering secure systems?
• Do we need new paradigms?
• Have we not done a good job in applying the old techniques?
• Is the real problem just bad software engineering, not bad security engineering?
• Is the problem poor maintenance, rather than poor engineering?
• Is "Defense in Depth" a meaningful engineering concept or is it bumper sticker engineering?
• Have we forgotten the past?
• Are we failing to teach new security engineers what we know?

Which of the following should we believe, which are vaporware, which are scareware, which are synonyms, which contribute to security?

• Security through obscurity
• Penetrate and patch (including penetration testing, red teaming, and scanning for known vulnerabilities)
• War games
• High assurance (including formal specification and verification, software development process maturity, clean room development techniques)
• Security architectural principles (including defense in depth, least privilege, isolation, modularity and layering, diversity, centralized security management, decentralized security enforcement)

There are many prophets and aspirant-received wisdom. Which are credible; which have proved useful; which are obsolete; which have never worked?

• Trusted Computer System Evaluation Criteria (Orange Book)
• Common Criteria for Information Technology Security Evaluation
• Unbundling security functionality and security assurance
• Protection Profiles
• Security Targets
• Redefining Security (Report to SECDEF & DCI)
• Open source
• Cryptography as an alternative to other security mechanisms

The goal of the workshop is to begin a process of serious thinking about these important issues. The output of the workshop will be a collection of essays and technical papers on the issues discussed in the workshop. The papers will be available on-line to the community. ACSA's intent is that the output of the workshop becomes the kernel for a growing on-line collection of theory, principles, and practice of security engineering. Over time this site will maintain our history, our lessons learned, and principles for getting it right the first time.

Position Papers

The intellectual price of admission is a nominal 5-10 page position paper (due before September 30, 2002) relevant to the workshop. The purpose of the position paper is to get participants thinking about the problems. Position papers will be grouped together by topic and posted on the ACSAC web site for participants. These position papers are solely for the purpose of exchanging information among the workshop participants and are not intended to be presented at the workshop. We expect the invited attendees to read the position papers prior to the workshop in order to have a common foundation to initiate discussion. To allow the discussion to start early, ACSA will establish an email address group of invited participants to enable an email discussion group for the authors' discussion. Position papers may be used to organize workshop discussion sessions.

WORKSHOP FORMAT

The workshop will begin with a plenary session laying out the objectives to the participants. This is likely to be in the form of 5 or 6 major issues that the committee has selected from the position papers and other sources. Each major issue will have an organizer and editor and a series of working group discussions. Following the workshop, the editor will produce a position paper that summarizes the problem, the current state of security problems and defenses, failed and successful countermeasures and other useful information to present a balanced picture to students, practitioners, and researchers. These papers will be collected, edited under direction of the editor-in-chief, and published by ACSA.

HIGHLIGHTS

PREPARING YOUR SUBMISSIONS:

Interested persons are invited to submit their position paper via email in one of the following formats:

• Rich Text Format (.RTF)
• Acrobat or PostScript format (.pdf or .ps)
• ASCII text (only if absolutely necessary)
• Microsoft Word

Include on your cover sheet:

• Title or Topic Abstract (not to exceed 250 words)
• Author(s), Organizational Affiliation
• Phone numbers (voice and fax)
• Email address
• Point of Contact, if more than one author

Authors are responsible for obtaining necessary releases and approvals as well as appropriately marking their position papers. Classified material or topics should NOT be submitted.

ORGANIZING COMMITTEE

• Workshop Chair: Marshall Abrams, MITRE
• Editor-in-Chief: Cristina Serban, AT&T Labs
• Program Chair: Chuck Flink
• Program Committee:
  • Ed Amoroso, AT&T
  • Blaine Burnham, University of Nebraska
  • William H Murray, TruSecure Corporation
  • Eugene H Spafford, Purdue
• Treasurer: Jay Kahn, MITRE
• Web Masters: Daniel Faigin, Aerospace; Ronda Henning, Harris
• Local Arrangements: Paul J. Brusil, Strategic Management Directions

Home | Chair's Perspective | Editor's Notes | Group Reports
Papers| Contributors |Organizing Committee | Original CFP

This document maintained by faigin -at aero.org and ncarlson -at aero.org.
Material Copyright © 2003 Applied Computer Security Associates