第 1 章 动力和目标
CHAPTER 1 Motivation and Objectives
We will bankrupt ourselves in the vain search for absolute security.
Dwight D Eisenhower
1.1 Why Do We Need Security Patterns?
Most modern applications are distributed and connected by some type of network – often the Internet, but also LANs and other specialized network types. Their platforms may support web interfaces, web services and even agents. The complexity of such systems makes them hard to understand, design and maintain. This complexity also brings vulnerabilities which, when coupled with the fact that these applications may handle valuable information, attract security attacks. The increasing use of mobile devices with improved capabilities and the growing use of sensors make this problem even more acute. Every day the press reports attacks on web sites or databases around the world, which result in millions of dollars of direct or indirect losses. Systems are constantly attacked and often breached. There is also the fear that a hostile adversary may try to disrupt the infrastructure systems of an entire country.
Why do we fail to secure such systems? One important reason is their complexity, which makes errors common and vulnerabilities hard to find. Another important reason is that security is built piecemeal: parts of a system are secured using specific products, but there is rarely a global analysis of the complete system. If done, different models may be used in different parts, for example one for the databases and another for wireless devices. Regrettably, security requires a comprehensive approach if it is to block all possible means of attack. Very secure components cannot make the whole system secure if they do not protect all parts of the system and do not work in a coordinated way. Threat analysis is done locally, but many threats only emerge when different units are interconnected. Further, methodologies for building secure systems focus mostly on new systems, but the majority of the systems in use are legacy systems, often in a state of constant maintenance. Even systems that have been built carefully can suffer from architecture erosion, in which changes made, once in production, can invalidate or weaken security defenses.
We need a way to handle the complexity of new systems and make them secure in a systematic and holistic way. We need a way to reengineer legacy systems to make them more secure, by tracing back code changes so that their impact on security mechanisms can be detected and corrected. Software developers know a particular language and its environment well; however, they may not know much about security, and their systems exhibit many vulnerabilities which can be easily exploited by attackers. They are also under pressure to produce results quickly.
Secure systems need to be built in a systematic way in which security is an integral part of the software lifecycle [Fer04b][how06][McG06]: the same applies to reliability and other quality factors. If when we build applications we also consider the effect of middleware, operating systems and networks as a whole, we can build systems that can withstand a whole spectrum of attacks from external or internal users. We believe that to build secure applications, it is not effective to build a secure platform and then run some application made secure in isolation on it, but rather that the application and its platform should be designed together and the platform match the type of application. In addition, all security and reliability constraints should be defined at the application level, where their semantics are understood and propagated to lower architectural levels [Fer99b][fer06b] [Sum97].
Lower levels provide the assurance that the constraints are being followed; that is, they enforce an absence of ways to bypass these constraints. The only way to provide this unification in the presence of myriad implementation details of the component units is to use abstraction. In particular, we can apply abstraction through the use of patterns. Patterns are encapsulated solutions to recurrent system problems and define a way to express requirements and solutions concisely, as well as providing a communication vocabulary for designers [Bus96][gam94]. The description of architectures using patterns makes them easier to understand, provides guidelines for design and analysis, and can define a way of making their structure more secure. Security patterns allow application developers to use security measures without being experts on security. We can also use patterns to evaluate existing systems by examining them to see if they contain the required patterns. Further, we can reengineer legacy systems by using patterns to add missing security features. (I compare the use of patterns to other approaches to producing secure systems below.)
We need to unify the total architecture of the network along horizontal and vertical partitions to apply a holistic approach – specifically, along the system development lifecycle and along its architectural levels [Fer11a]. This book presents a complete pattern-based methodology for building secure systems, covering pure information systems as well as embedded systems. I proposed its main ideas in [Fer06b] and am still refining and extending it. A far-reaching objective is to establish the fact that patterns offer a robust way to build security and reliability into systems. Neumann calls for the need to have ‘principled’ systems, based on solid conceptual approaches [Neu04]: patterns allow the implicit application of principles. I have done a substantial amount of work in this direction, but further work is still needed to consolidate and extend this. The use of security patterns and other approaches to building secure systems is surveyed in [Uzu 12c].
To design a secure system, we first need to understand the possible threats to the system. We have proposed an approach for identifying threats by considering the activities in each use case [Bra08a][fer06c]. Such an approach finds threats – as goals of an attacker – that are realized through the lower levels of a system. We need to understand how the specific components of the architecture are compromised, or used by an attacker, to fulfill their objectives. We use the concept of misuse (attack) patterns to model how a misuse is performed [Fer07a].
There is a need for ways to define and enforce standards and regulations; our proposed pattern-based approach can be valuable for that purpose. In fact, some standards – for example HIPAA, FEMA and Sarbanes-Oxley – and regulations are very complex, or even ambiguous; patterns can describe them in a precise way and make them more understandable and usable. Web services and cloud computing have brought about a need for certification of services; patterns could be a good way to achieve this [Dam09].
When we talk about modeling, we do not mean yet another authorization model, but rather a model of the integration of security controls for a variety of devices and units in a computer system, fundamental when dealing with complex systems. We can get a measure of completeness by adding patterns to cover all the threats identified in each layer and approach the holistic ideal required to secure systems. We think this is also a good approach to defend against a possible cyber war. Patterns do not provide provable security, but they are a good practical approach to apply to increasingly complex systems.
1.2 Some Basic Definitions
Before we start, we need to define a few basic terms. Security is the protection against:
- Unauthorized data disclosure (confidentiality or secrecy).
- Unauthorized data modification (integrity). Unauthorized modification of data may result in inconsistencies or erroneous data. Data destruction may bring all kinds of losses.
- Denial of service: users or other systems may prevent the legitimate users from using their system. Denial of service is an attack on the availability of the system.
- Lack of accountability: Users should be responsible for their actions and should not be able to deny what they have done (non-repudiation).
The definition of security above describes security as defense against some types of attacks. The generic types of defenses (also known as countermeasures) that we can use include:
- Identification and authentication (I&A). Identification implies a user or system providing an identity to access a system. Authentication implies providing some proof that a user or system is who or what they claim to be. The result of authentication may be a set of credentials, which later can be used to prove identity and may describe some attributes of the authenticated entity. Patterns for identity management and patterns for authentication are described in Chapter 4 and Chapter 5 respectively.
- Authorization and access control (A & A). Authorization defines permitted access to resources depending on the accessor (user, executing process), the resource being accessed and the intended use of the resource. Access control is the use of some mechanism to enforce authorization. Chapter 6 describes patterns for access control.
- Logging and auditing. These functions imply keeping a record (log) of actions that may be relevant for security and analyzing it later. They can be used to collect evidence for prosecution (forensics) and to improve the system by analyzing why an attack succeeded. Logging and auditing is also described in Chapter 6.
- Hiding of information. Information hiding is usually performed by the use of cryptography, but steganography is another option (see Chapter 12). The idea is to hide information to protect it.
- Intrusion detection. Intrusion Detection Systems (IDS) alert the system in real time when an intruder is trying to attack it. Chapter 10 discusses patterns for networks.
My objective in this book is the construction of complex applications. These include medical systems, financial applications, legal applications, operating systems and others. Such applications are typically implemented with systems that are subject to non-functional requirements such as reliability or fault tolerance. Often they are composed of a variety of software and/or hardware units, some built ad hoc and some bought or outsourced. In such systems the security of the application software itself cannot be separated from the security of the rest of the system.
Another common aspect of such systems is that they frequently must comply with regulatory standards. Systems may include several databases, and usually have Internet access as well as distributed and wireless access. Data is typically accessed using a web application server (WAS) that integrates web and database applications and uses a global enterprise model, usually implemented using components such as J2EE or .NET, applications that are of fundamental value to enterprises and institutions of any type. A systematic approach is required towards building these applications such that they can reach the appropriate level of security. We focus on these applications because they define worst-case scenarios for the application of our patterns methodology.
Security was first studied from a systems viewpoint [Sum97], and standards appeared for evaluating security [cc][dod83]. The emphasis then moved to software; numerous papers indicated its importance and gave the impression that software security was the only objective we need to fulfill to produce secure systems [How03]; there is now a considerable effort to improve the security of code [De W09]. However, things are not so simple: the whole system must be secure, including its hardware and the way the whole system is configured. We need a global and holistic view if we want to produce secure systems. Typical textbooks, for example [Gol06][sta 12], are very good for discussions of specific topics, but they don’t provide a global view. Most research papers study specific mechanisms but rarely look at the complete system. Much work as also been done on stochastic system views of security [Nic04], but while this is an interesting direction for evaluating global aspects of systems, it does not provide constructive solutions for systems security.
In this book we take a systems view of security, for which software architecture is an important basis [Bus07][tay10]. Software architecture provides a global view of systems, but until now most studies have not considered the early lifecycle stages or said much about security [Fer12a]; however, the software architecture viewpoint is very important. To apply any methodology, we need a good catalog of patterns: providing that is one of the main objectives of this book.
A related aspect is that of how to apply these patterns through some systematic methodology. We have applied the patterns described here throughout a secure system development methodology based on a hierarchical architecture whose layers define the scope of each security mechanism [Fer04b][fer06b]. We discuss this approach in Chapter 3.
1.3 The History of Security Patterns
Yoder and Barcalow wrote the first paper on security patterns [Yod97]. They included a variety of patterns useful in different aspects of security. Before them, at least three papers [Fer93a][fer94a] [Ess97] had shown object-oriented models of secure systems without calling them ‘patterns’, or using one of the standard pattern templates. In 1998, two more patterns appeared: a pattern for cryptography [Bra00] and a pattern for access control [Das98]. After that, several others appeared, and we have now three books on the subject [Bla04][sch06b] [Ste05], one of which [Sch06b] was the first to try to categorize and unify a variety of security patterns. Many papers have also appeared, some of which are surveyed here.
Security patterns are now accepted by many companies, Microsoft [msd], Sun [jav] and IBM [IBMb] have papers and web pages on this subject. A general web page for security patterns also exists [sec]. Pattern catalogs include [Ste05][kie02][Bla04][dou09], [Sch06b][ysk06][Haf11]1. Some surveys of security patterns include [Fer06a][yos08] [Uzu 12a]. This book extends the ideas of [Sch06b] and adds many new patterns, as well as a methodology for building secure systems.
1.4 Industrial Use of Security Patterns
Most developers don’t use models, they just code. However, this situation is slowly changing and design patterns have been successfully applied in many industrial projects, for example [Bec96][sch95]. Several major companies now maintain patterns web pages and have published books about them.
Until now, security patterns have not been used as much as design patterns, but some interesting applications exist, such as qmail [Haf08] and BBVA [Mor12]. [ElK09] reports the use of security patterns to enforce security for remote healthcare in smart homes. [Ela11] describes a survey of 237 institutions in China to discover their use of security requirements for software construction. One of their most common sources of security knowledge were standards and security patterns.
One of the reasons for the lack of use of security patterns is the lack of a good catalog; we hope to help with this. Another reason could be lack of a methodology, and we expect that our methodology can be of value here.
1.5 Other Approaches to Building Secure Systems
There are several other approaches to building secure systems, of which the most prominent are those based on secure coding:
- Microsoft’s Security Development Lifecycle (SDL) [How06]. [Lip05] defines activities for all the stages of a lifecycle based on coding with almost no modeling. The analysis stage is almost ignored, and threats are defined with respect to the deployment units of the software.
- OWASP’s CLASP is a lightweight process to define requirements for secure software [OWAa]. It also starts from deployment units and analyzes their threats. Similarly to SDL it ignores the semantic aspects of the application.
- Building Security in Maturity Model (BSIMM) is a software security framework, which includes twelve practices organized into the four domains of Governance, Intelligence, SSDL Touchpoints and Deployment [BSI].
DeWin [De W09] made a detailed comparison of SDL, CLASP and Touchpoints [McG06], looking for similarities and differences, as well as suggesting improvements. Code-based security, while valuable, cannot produce secure systems by itself, but it can be a good complement to model-based methods.
1Strictly, Haf11 and Ysk06 are not catalogs, they are pattern inventories where they organize existing patterns according to some classification, but do not provide pattern descriptions.