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 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, craftsmen, 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. They 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) sponsored this workshop to examine engineering fundamentals, that is, the principles and practice of designing and building secure systems. The workshop was supposed to 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. In advance of the workshop, we identified a set of questions and issues to discuss:

• 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 techniques should we believe (which are vaporware, which are scareware, which are synonyms, and 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, and clean room development techniques)
• Security architectural principles (including Defense in Depth, least privilege, isolation, modularity and layering, diversity, centralized security management, and decentralized security enforcement)

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

• Trusted Computer Systems 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 Secretary of Defense and Director of Central Intelligence)
• Open source
• Cryptography as an alternative to other security mechanisms

The goal of the workshop was to begin a process of serious thinking about these important issues. The output of the workshop is this collection of working session reports, essays, and technical papers on the issues discussed in the workshop. ACSA’s intent is that the output of the workshop becomes an available resource for students of theory, principles, and practice of security engineering. I hope you find this material useful.

The intellectual price of admission was a nominal 5-10 page position paper relevant to the workshop. The purpose of the position paper was to get participants thinking about the problems. In preparing these proceedings, we gave the authors the options of making their position papers available. Twelve papers are presented in these proceedings, nine in original form, and three were updated after the workshop.

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