|
| |
Motivation
The importance of making our software systems
secure has been steadily increasing as societys dependence on
interconnected computers grows. Recent changes in political climate,
marketplace pressures, and societal needs have dramatically heightened
awareness of the problem of software insecurity and led to demands for
improvement. At the same time, the technical challenge of securing software
systems is far greater today because of simultaneous, explosive increases in
the scale, complexity, and diversity of
 |
the software systems we build (i.e., applications, services,
networks, and cyber-infrastructure); |
|
the software development processes used to build them; and |
|
the customers and users who rely on them. |
As scientists and engineers, we have a
professional, as well as practical, responsibility to ensure that the
software we build is reliable and trustworthy. How can we rise to this
challenge? More specifically, how do you, as a practitionera builder of
browsers, databases, operating systems, or routersstrive to make your
software system secure? How is it that you, as a researcheran inventor of
methods, languages, protocols, or toolshelp developers build secure
software systems? What design principles do you espouse? What automated
techniques do you use? What are your principal unmet challenges?
These questions are difficult to consider,
let alone answer, in isolation. We each work on a piece of a large security
puzzle. Security, broadly construed, is not an absolute property, and in
practice, perfect security is unachievable. Instead of a clear goal, we
face a complex set of interacting and conflicting properties, including
integrity, confidentiality, and availability. We measure security along
many dimensions, and so tradeoffs are inevitable. It is also important to
look beyond code in a software system. Design and architectural decisions
facilitate or hinder making a system secure. The unpredictability of a
software systems interactions with its environmentincluding hardware,
other software systems, and human usersprecludes a complete analysis of a
systems vulnerabilities. Each of us sees and touches only part of this
larger problem.
Goals
The goal of this summer institute is to
bridge some of these barriers by bringing together a diverse group of
practitioners and researchers, whose work spans a wide range of areas, for
four days of intense discussion on how to make software secure. More
specifically, our goals are:
|
To share our different and possibly differing perspectives on
building secure software systems.
 |
What specific technical problems are you trying to solve and what
specific approaches are you following? What threats can you guard
against? What security policies do you try to enforce? What guarantees
does your solution provide to others? |
|
What are the limitations of your approach? How do you rely on
others solving their pieces of the puzzle? |
|
|
To identify promising research directions
for the future.
|
What directions lead to solutions that
scale, are feasible to implement and deploy, and anticipate technology
trends? What incremental research appears to offer high benefits? Or,
what sea changes are necessary to make significant improvements? |
|
How will our solutions fit together to give us increased
confidence that our software systems of tomorrow will be more secure
than those in use today? |
|
By the end of the institute, we hope that
participants leave with a richer appreciation of the current capabilities in
and future visions for the theory and practice of building secure software
systems.
Jim Larus (Microsoft), Jeannette Wing (CMU), and John
Zahorjan (UW)
|
Key Information
|
About UW-MSR Summer Institutes
Since 1997, the
University of Washington
Computer Science Department and Microsoft Research have co-sponsored
summer institutes on
diverse topics, including data mining, intelligent systems, and
software tools infrastructure. In 2003, Carnegie Mellon University
joins UW and Microsoft Research in sponsoring a summer institute on software security.
|
|
