Nicholas Rosasco and David Larochelle.  In the second annual Workshop on Economics and Information Security, College Park, Maryland, May 29-30, 2003.Towards a Model of the Costs of Security
Secure shell (SSH) can safely be called one of the rare successes in which a more secure technology has largely replaced a less secure but entrenched tool: telnet. We perform a market analysis to determine how and why SSH succeeded despite the existence of an entrenched legacy tool while similar technologies such as secure file transfer protocols have been far less successful. We show that network externalities, usually a first order effect, were not a significant factor impeding the adoption of SSH, and that SSH offered equivalent functionality and greater ease of use. We argue that these factors were the primary consideration in the willingness to change. Additionally, we argue that the openness of the standard, which facilitated the creation of numerous compatible implementations, was a key element in the economic decision made by system administrators.
David Larochelle and Nicholas Rosasco, Technical Report CS-2003-13, June 2003.Join Point Encapsulation
We present a simple information security model to determine why, historically, the level of security has not increased despite numerous technical advances. In our model, the software design process involves trade-offs between security and functionality. Developers choose points in the design space corresponding to certain levels of security and functionality. If development resources, such as number of developers, time for completion, etc., are fixed, there is an implicit trade-off between security and functionality. We refer to the set of points that represent the maximum possible security given a certain level of functionality as the protection possibilities frontier (PPF). Technical advances push back the PPF expanding the set of accessible points in the design space potentially allowing both increased security and increased functionality. But historically this has not been sufficient to result in increased security. Instead almost all of the technical advancement is used to increase functionality. We examine how technical advances affect the marginal cost of security in terms of sacrificed functionality and classify technical advances into 3 categories: security neutral, security hostile, and security enhancing. In order for the level of security to increase, security enhancing technical advances must offset security hostile technical advances. We also observe that producing security enhancing technologies is surprisingly difficult. Even advances in information security technologies often result in the ability to take additional risks rather than increased security. Additionally we briefly examine user preferences, which to a large extant drive the actions of developers. We suggest that the lack of security cannot be explained purely by consumer apathy and that limited product availability and network externalities also contribute.
David Larochelle, Karl Scheidt, Kevin Sullivan, Yuan Wei, Joel Winstead, and Anthony Wood.  In AOSD 2003 Workshop on Software-engineering Properties of Languages for Aspect Technologies, Boston, Massachusetts, March, 2003.
At the heart of aspect-oriented programming is the exposure of certain phenomena in the execution of one set of program elements to behavioral modifications specified by other elements. The phenomena are join points. The modifying elements are aspects. The problem that we address is that current aspect-oriented languages do not provide adequate means to control the exposure of join points for behavioral modification by aspects. Rather, these languages define certain classes of join points (e.g., method calls) and expose all instances thereof. In a nutshell, then, current languages lack join point encapsulation mechanisms. We map a solution space and describe one proof-of-concept design that we have implemented for AspectJ. A key feature of our design is that it is, itself, aspect-oriented: We use AspectJ's pointcut language to identity cross-cutting sets of join points to be encapsulated. The potential benefits of such a modularity-supporting mechanism include improved ease of reasoning about program behavior and the ability to assure the absence of side-effects through enforced non-interference by aspect code, and improved ease of design evolution.
David Larochelle and David Evans. In Sixth World Multiconference on Systemics, Cybernetics and Informatics, Orlando, Florida, July 14-18, 2002. (PS, 5 pages)
Security researchers have long understood buffer overflows and other security problems. However, this knowledge has not been codified in a way that helps typical programmers avoid these mistakes. To benefit programmers, this knowledge must be encoded into tools that can be incorporated into the development process. No matter how powerful a tool is, it can be effective only if real world programmers are willing to use it. We briefly summarize techniques for detecting security vulnerabilities that we have integrated into Splint, an annotation assisted static checking tool. We propose extensions to Splint to automate the annotation process. We describe a variety of tools that use techniques related to what we propose and argue that these techniques could be applied to security checking.
Improving Security Using Extensible Lightweight Static Analysis
David Evans and David Larochelle. In IEEE Software, Jan/Feb 2002. (PDF, 12 pages)
Most security attacks exploit instances of well-known classes of implementations flaws. This article describes how Splint can be used to detect common security vulnerabilities (including buffer overflows and format string vulnerabilities).
David Larochelle and David Evans. In 2001 USENIX Security Symposium, Washington, D. C., August 13-17, 2001. (PDF, HTML, 13 pages) ( Talk slides [PPT] [PDF])Last updated 6/12/2003
This paper and the accompanying slides are now available under a Creative Commons (CC BY-NC-ND 3.0) license.
Buffer overflow attacks may be today's single most important security threat. This paper presents a new approach to mitigating buffer overflow vulnerabilities by detecting likely vulnerabilities through an analysis of the program source code. Our approach exploits information provided in semantic comments and uses lightweight and efficient static analyses. This paper describes an implementation of our approach that extends the LCLint annotation-assisted static checking tool. Our tool is as fast as a compiler and nearly as easy to use. We present experience using our approach to detect buffer overflow vulnerabilities in two security-sensitive programs.