Three Design Patterns for Secure Distributed Systems

Abstract The computers we use are not secure, and they are even less so when connected to the Internet. A lot of blame has been put on lazy sysadmins for not applying patches promptly, but the fault is not entirely theirs. We believe that distributed systems should be designed to make attacks harder and to limit the damage done when attacks succeed. We propose three components of the system architecture that address these goals and make distributed systems easier to monitor and manage, while simplifying the task of writing secure applications. Following these guidelines won't make the system secure, but doing so will make it easier to build systems that are. Introduction Much of our thinking on the subject of computer security originated in the 1960s and 1970s [1, 2], a time when computers were rarely networked, those that were connected largely trusted each other, and those connections rarely changed. That is not the situation today. Virtually all computers and an increasing number of other devices are connected to the Internet. Many of the machines out there are running software that attempts to harm others, either because their owners are malicious or because their owners are careless and have allowed malicious people take control of their machines. To make matters worse, the environment is constantly changing, with machines joining and leaving the system and even changing owners. In this paper we’ll examine three ways to structure distributed systems to make them less susceptible to attack. The patterns we describe address certain aspects of anonymity, auditing, and access control. They can limit the damage done by some denial of service attacks and can make some attacks against applications more difficult. There are many aspects of security that we don’t address in this paper. We exclude from the discussion physical security, including tamper-proof devices, methods for authentication, specification of authorization policy, most aspects of privacy, and protocols for non-repudiation. Nothing we propose can mitigate attacks against the underlying operating system, including the network stack. Also, problems of misplaced trust, social engineering, and careless users are beyond the scope of this work.