Patterns Transform Architectures

Patterns Transform Architectures Munawar Hafiz University of Illinois Email: [email protected]

Paul Adamczyk Email: [email protected]

Abstract—Software patterns have been used to guide developers and to disseminate expert knowledge. This paper describes our approach of expressing patterns as program transformations. We derived from our catalog of security patterns, a catalog of security-oriented program transformations. We describe how these program transformations can be applied to remove security vulnerabilities. Our paper is a first example of applying patterns to actively transform architectures. Keywords-Pattern; Architecture; Transformation; Security

I. I NTRODUCTION Software design remains elusively hard. While design techniques improve and mature, the expectations grow even faster. Stakeholders expect software with more capabilities and more flexibility. Implicitly, they also expect better quality attributes, such as availability, performance, and security. The inadequacy of current design techniques is especially visible in the domain of security. Patterns [1] [2] document best practices in software design and architecture. They describe both the approach and the reasoning behind it. Patterns can be used to design a system, to drive design changes, or to document design [3]. Smaller patterns (e.g., O BSERVER [2]) are now included in most language libraries; many sites store pattern source code that can be copied. But, applying larger patterns is more involved than copying examples. They are better explained as sequences of refactorings [4], as in “Refactoring to Patterns” [5], which explains the steps required to introduce design patterns [1] to a system. The domain of security has its own patterns [6] [7] [8]. Some are simple, but most patterns affect entire systems, meaning they are architectural [9]. Security patterns can be applied to remove existing vulnerabilities or to add protection against new attacks. Similar to design patterns, it is easier to apply security patterns if there are specifications and tools for applying them to software. We have developed such specifications and tools, as security-oriented program transformations [10]. Similarly to design patterns, some transformations can be applied automatically by a tool, while others define concrete steps but require programmer intervention. However, improving security of a (new or existing) system is different than refactoring, because their goal is to improve the design, not to preserve the behavior. We have two contributions. First, we describe how to improve the security of a system by applying security-oriented

Ralph Johnson University of Illinois Email: [email protected]

program transformations. These program transformations are not silver bullets; using them requires skill and knowledge of the program being transformed. They are instead power tools that make it easier to systematically change the architecture. We describe examples of applying program transformations, using a one-step transformation tool as well as following a step-by-step refinement process, in which the steps can be automated. But the most important contribution of this paper is the promotion of patterns from a passive guideline for developers to an active program transformation mechanism that developers can use. Thus, patterns are valuable as a mechanism to transform architecture. We first describe how we captured the guidance from security patterns in the program transformations. We show example architectural transformations and discuss preliminary results in applying them. Finally, we discuss several issues of using patterns and program transformations. II. S ECURITY PATTERNS A security pattern describes a solution that experts use to solve a security problem in a context. We have been maintaining a comprehensive catalog of all published security patterns [6]. The security pattern catalog currently contains 96 patterns. The catalog is a union of all security patterns that appear in many books, catalogs and papers. A. Security Pattern Sources There are 3 books on security patterns. Schumacher led a working group on security patterns to write a security pattern book [7]. This book had 46 security patterns from the domain of enterprise security and risk management, identification and authentication, access control, accounting, firewall architecture, and secure internet applications. This book aggregates many previous works on security patterns, including the first catalog of security patterns [11], Schumacher [12] and Fernandez’s [13] [14] work on security patterns, etc. Steel et al. [8] described 23 security patterns for J2EE based applications, Web services and identity management in their book. Microsoft’s Patterns and Practices group published the third book [15] that included 18 patterns. There are several pattern catalogs. Blakley and Heath [16] compiled a security pattern catalog with the members of the Open Group forum. It contained 13 patterns: 5 patterns for improving reliability, and 8 for security. Kienzle et al. [17]

listed 26 patterns and 3 mini patterns in their security patterns catalog. Romanosky [18] [19] compiled two pattern catalogs containing 12 patterns in total. We have created two pattern catalogs. The first stems from our study of the evolution of mail transfer agent architecture [20]. This contains 11 security patterns, and 4 reliability patterns. These patterns are not specific to mail transfer agents; they can be used by the designers of other secure systems. Our second catalog compiles a collection of 12 privacy design patterns [21]. The pattern sources describe 174 security patterns, but with many overlaps. We developed our catalog of 96 patterns by removing the overlaps. For example, patterns for authentication have been listed in a number of pattern catalogs under different names, e.g., AUTHENTICATOR [14] [7], S ECURITY P ROVIDER [18], AUTHENTICATED S ESSION [17], AU THENTICATION E NFORCER [8], and D IRECT AUTHENTI CATION [15]. We have one AUTHENTICATION E NFORCER pattern for authentication, removing language-specific and catalog-specific descriptions of this pattern [6]. B. Organizing the Pattern Catalog A catalog of 96 patterns is overwhelming. It is hard for developers to find a pattern they need, let alone know when to use it. We attempted to organize the security patterns [6] by grouping them into small, correlated sets. We describe here one classification scheme that eventually hepled us identify the patterns that can be described as securityoriented program transformations. Several security pattern authors [7] [22] [23] have attempted to classify their respective pattern catalogs using the Zachman framework. Zachman framework [24] was introduced in 1987 as a table. Its 5 rows describe the levels of information model from the perspective of various stakeholders, e.g., the customer or the owner, the designer, the builder, etc. The 6 columns describe ways of describing an artifact: data (what?), function (how?), network (where?), people (who?), time (when?) and motivation (why?). We applied a tabular classification scheme [6] which uses ‘Enterprise Architectural Space Organizing Table’ [25]. Out of the 7 columns of the table, 6 are from the Zachman framework. The seventh column (Scorecard) includes patterns for testing. The rows describe stakeholders similar to the Zachman framework, but they have been specified in roles of finer granularity. Table I shows how the security patterns are classified using this tabular scheme as well as some sample patterns. It shows only relevant rows of the larger table. As an example of classification, consider the S AFE DATA S TRUCTURE [20] pattern. This pattern is applied to remove the array bounds checking vulnerability in a programming language with no garbage collection. A system written in C is vulnerable to buffer overflow attacks because of unsafe array operations, e.g., unsafe string handling. S AFE DATA S TRUCTURE

Table I C LASSIFICATION OF S ECURITY PATTERNS USING THE E NTERPRISE A RCHITECTURAL S PACE O RGANIZING TABLE

advocates the inclusion of length and allocated memory information with a data structure. This pattern is considered in the development phase of an application when the safe string processing libraries are written or re-used. Hence this pattern fits into the cell defined by the Developer row of Application Architecture perspective and the Data column. The tabular scheme can not classify 16 patterns because they fall into multiple cells in the table; Table I shows some examples. The scheme fails to distinguish low level patterns from high level patterns. We improved it using a classification scheme [6] that uses domain knowledge (threat model) and embraces hierarchy. But this tabular classification helped us identify the patterns that can be described as program transformations. We describe the process in the next section. III. F ROM PATTERNS TO P ROGRAM T RANSFORMATIONS We derived a security-oriented program transformation catalog by surveying the problem domain and solution domain of security. We identified the most important security problems by surveying various vulnerability-trend reports. Then we identified the solutions that solve these problems by surveying the security patterns catalog. Currently, the security-oriented program transformations catalog contains 37 transformations. The pattern catalog contributes to most of the program transformations. 96 patterns contribute to 30 program transformations. The remaining 7 transformations originate from well-known security solutions. The entire activity can be summarized in four steps: (A) Analyzing the problem domain and identifying relevant security problems. (B) Analyzing security pattern catalog for candidates that can be described as program transformations. (C) Identifying other well-known security solutions that can be described as program transformations. (D) Describing the mechanism of security-oriented program transformations. The following sections describe these steps.

Table II F INDING CANDIDATE SECURITY PATTERNS

A. Analyzing the Problem Domain We studied vulnerability trend reports [26] [27] [28] [29] [30] to find the important security problems. We identified 5 important vulnerability classes: input validation vulnerabilities, authentication vulnerabilities, access control vulnerabilities, error handling vulnerabilities, and denial of service vulnerabilities. Our vulnerability classes have been derived primarily from the OWASP [26] list, and have been supported by other vulnerability trend reports. Next, we identified the relevant solutions. B. Analyzing the Security Pattern Catalog Our pattern catalog accumulates the experience of the entire security pattern community and is a fair representation of the solution domain of security. We analyzed the catalog and found 30 security solutions that can be described as program transformations. This was done in two steps. (1) We used the tabular classification scheme for security patterns to identify patterns that describe solutions applicable to software. This step resulted in 70 patterns. (2) Next, we analyzed the implementation mechanism of each remaining pattern. Some patterns describe high-

level policies, some describe solutions that are too difficult to implement; also there are patterns that describe the same technique applied in different contexts. After removing these, we had 29 patterns that contributed to 30 security-oriented program transformations. We will describe these two steps in detail. 1) Using Pattern Classification Scheme to Find Relevant Patterns: Not all security patterns are about code and software design. The tabular classification scheme for organizing security patterns identifies the patterns relevant to software. Table I shows the scheme. In the table, the suitable candidates for program transformations are patterns from the rows grouped by application architecture perspective, and in the function and data columns. This constitutes 70 patterns. Among the 26 patterns we discarded, 10 patterns are about non-software artifacts. Some of these patterns are related to hardware. PACKET F ILTER F IREWALL [7] and S TATEFUL F IREWALL [7] guide practitioners how to select the most appropriate firewall, while D EMILITARIZED Z ONE [7] guides how to deploy multiple firewalls. The remaining 16 patterns could not be classified in Table I, because they straddled multiple cells in the classification

table. We counted the patterns that fell in either of the data or function columns and the rows grouped by application architecture perspective. There were 9 patterns. The remaining 7 are about software processes. There are security patterns for asset evaluation, risk assessment, and threat modeling [7] that describe a process, and could not be described as a program transformations of software. In total, we selected 79 patterns from the catalog. We analyzed these patterns and identified the ones that can be described as program transformations in the next step. 2) Finding Patterns that could be Described as Program Transformations: Out of the remaining 79 patterns, 14 describe very high level solutions, 26 describe solutions that are hard to implement, and 10 describe solutions common to other patterns. Removing these leaves 29 security patterns, that contribute to 30 program transformations. Table II shows how the 79 patterns are partitioned. 14 patterns prescribe high level solutions. An example of such a pattern is D EFENSE IN D EPTH [31]; it is a security principle that is fundamental in any security design, but it is too general to form a program transformation. Another example is the A NONYMITY S ET [21] pattern. It is a core pattern for privacy preserving applications. It suggests that the fundamental principle of keeping information private is to mix it with other information and make private information indistinguishable. But implementing the high level solution depends on the context of an application; it cannot be expressed as a general purpose program transformation. 26 security patterns provide solutions that are too complex. For example, L IMITED ACCESS [7] and F ULL ACCESS WITH E RRORS [7] describe how secure user interfaces can be designed. For an application with many users and different privilege levels, one option is to give each user a limited view of the user interface, i.e., only the options that his/her privilege allows. The other option is to show all functions to all users, but only allow access to functions that are permitted. Graphical user interface is difficult to code and almost impossible to code automatically. Therefore, automatically adapting an existing user interface to follow either options is not possible. Another example is the ROLE BASED ACCESS C ONTROL [7] pattern. This complex pattern introduces many context sensitive changes in the code. It is hard to describe its general solution as a transformation. In 10 cases, the solution mechanism of multiple security patterns is the same; thus multiple security patterns correspond to one program transformation. For example, input filtering is an important protection mechanism that motivates C ONTENT D EPENDENT P ROCESSING [20] pattern. The filtering mechanism in an application follows the P IPES AND F ILTERS [2] architectural pattern: an input variable passes through a series of filters. The same mechanism applies to other cases when data has to be modified, e.g., encoding or decoding data, encrypting or decrypting, using parity for error detection and correction, or padding data

packets so that all packets are of the same length. Each of these cases is defined by its own security pattern, but the underlying security-oriented program transformation is the same. Similarly, Partitioning program transformation in our catalog is a combination of C OMPARTMENTALIZATION [31] and D ISTRIBUTED R ESPONSIBILITY [32] patterns. 29 security patterns contribute to 30 security-oriented program transformations. S AFE DATA S TRUCTURE [20] pattern contributes to 2 program transformations: Safe Library Replacement and Safe Type Replacement. Table III lists the patterns and corresponding program transformations. C. Program Transformations from Other Sources Table III lists 7 program transformations in our catalog that do not derive from security patterns. Instead they describe how to transform a program to implement wellknown security solutions. Among these are program transformations that introduce cryptographic operations. Program transformations to create a message digest, or a message signature describe how classes of Java or .NET security API can be composed to perform the tasks. Similarly, Encryption/Decryption transformation composes Java or .NET security API. There are security patterns that use cryptographic solutions (C LIENT DATA S TORAGE [17] and E NCRYPTED S TORAGE [17] patterns in table II), but there are no specific patterns describing these cryptographic operations. Explicit Type Enforcement transformation adds missing type information to prevent integer overflow errors that originate from the use of integer datatype in an unsafe context. Guarded Object transforms a program to encapsulate each resource and the corresponding set of permissions in one object. Least Privilege transformation automatically analyzes a program to identify the lowest privilege level required. Fuzzing transformation adds user-directed white box fuzzing components. D. Describing Mechanism of Program Transformations The final step is defining the mechanics of transformations. The mapping from a security pattern to a program transformation is not trivial. A security pattern provides a high-level description of a security solution and the justification for it. It does not describe all the implementation details, nor the steps to transform a program to introduce the solution. For each candidate security pattern, we had to identify the implementation method and then describe the transformation steps. For example, S AFE DATA B UFFER [20] describes a solution to prevent buffer overflow attacks. Buffer overflow occurs because an unsafe language such as C does not check buffer bounds before performing a buffer operation. S AFE DATA B UFFER says that one should check for length information before performing any operation on the data. The lessons from this pattern have been implemented by a number of safe string libraries (e.g., strlcat and strlcpy [33], libmib library [34], ISO/IEC 24731 [35], libsafe library [36], etc) and safe data types [37] [20]. We

Table III L IST OF SECURITY- ORIENTED PROGRAM TRANSFORMATIONS

have described the solution as a Safe Library Replacement transformation as well as a Safe Type Replacement transformation. Safe Library Replacement finds all instances of an unsafe library in a program and replaces each instance with a corresponding safe library. The Safe Type Replacement transformation replaces char * pointers with a safe data type that keeps length information of the buffer. In some cases, the pattern describes a high level solution, yet the program transformation implements a concrete solution. For example, Randomization program transformation randomizes a data variable in a program or instruction set of a system to make it distinct. This, as well as some variants of Safe Library Replacement, has been motivated from the M INEFIELD [17] pattern. The pattern suggests that systems should be varied so that each instance is different; therefore, some instances will be resistant to an attack vector that compromises other instancesstructural c of the same system. There is no general way to implement the pattern. The program transformations introduce concrete solutions for varying a system to make it secure. Not all parts of program transformations can be automated. But if a program transformation can be automated, tools will make it easier for developers to apply them. Some program transformations can be completely automated, but most are interactive and require some manual intervention. IV. W HAT IS A S ECURITY- ORIENTED P ROGRAM T RANSFORMATION ? A program transformation is a function that maps programs to programs. A security-oriented program transformation maps programs to security-augmented programs, i.e., it introduces a protection mechanism to make programs secure.

Figure 1 shows a schematic diagram of such a function. Figure 1 also raises several concerns. What are the inputs of a security-oriented program transformation? What is the specification for a transformation? What type of change is made by a security-oriented program transformation? Finally, what do we mean by improved security in the output programs? What are the tradeoffs?

Figure 1.

Diagram of a Security-oriented Program Transformation

Inputs of a Security-oriented Program Transformation: Security-oriented program transformations rephrase an input program, i.e., the input programs and the target programs are of the same language. However, they include both source to source and binary to binary transformations. Specification for a Security-oriented Program Transformation: Program transformations require user specification. A user applying a refactoring transformation needs to specify where to make the change, e.g., which variable to rename, which method to extract, etc. Even an automated transformation such as compilation requires user specification in the form of makefiles and build configurations. Securityoriented program transformations can be interactive similar to refactorings, or more automated similar to compilers. Nevertheless, they need some form of user specification. To use a security-oriented program transformation, a developer has to follow three steps–1) identify the program

points where to apply a transformation, 2) determine which transformation to apply, and 3) use a tool to automatically transform the program. The first two tasks are manual: a developer typically supplies these parameters to a program transformation with a manual specification. Consider a Single Access Point transformation that minimizes the number of entry points of a program. With minimal access points, the necessary checks on inputs can be performed at fewer entry points. But how does one minimize the number of entry points? Once all the entry points of a system are identified, it is possible through a series of code edits and refactorings to merge entry points. However, it is hard to automate the part of identifying all entry points. It is better if a developer manually specifies the entry points. A developer’s specification is the policy. The tools implement the mechanism; they automatically execute structural changes. Structural Change made by a Security-oriented Program Transformation: A security-oriented program transformation makes structural changes (similar to refactorings), such as replacing method calls, composing classes, refactoring to patterns, distributing artifacts, etc. Structural change also means that the corresponding tool does not need to have a deep understanding of the program behavior; a user provides the specification and a transformation tool performs the mechanical change. A transformation makes the same changes that a developer has to make to secure a program, only it makes the changes systematically. Security-oriented program transformations are larger than typical refactorings. They can be compared to large refactorings comprising of many steps. Some of these steps can be supported by tools while other steps can be manual. The change, made by a transformation, can be categorized by two issues: the scope of change and the impact of change. The same program transformation may make different type of changes in different contexts. For example, a PARTITION ING transformation for a C program splits a process so that each partitioned process runs in its own address space. On the other hand, a PARTITIONING transformation for a Java program distributes objects so that they can live in separate virtual machines. The mechanism of a partitioning tool for a C program is different from that for a Java program. However, it should be general-purpose in the sense that a developer should be able to apply the transformation on any C program. Compare this to a patch program that uses diff outputs to transform a program. It is designed to work with a single version of a program. But security-oriented program transformations are more general. The impact of change made by a security-oriented program transformation distinguishes them from refactorings. Security-oriented program transformations are not behaviorpreserving the way refactorings are. A security-oriented program transformation preserves the correct behavior and fixes the incorrect behavior caused by a security vulnerability. Our program transformations are behavior-preserving when the

system is used correctly; they preserve good path behavior. Improving Security using Program Transformations and its Tradeoffs: Adopting a single protection mechanism is not enough; one must have defense in depth [31]. Securityoriented program transformations should be composable. Security is closely related with other quality attributes, e.g., performance, simplicity and maintainability. Many of the program transformations in our catalog add a new component, e.g., a component for authentication, or a component for filtering inputs. When applied indiscriminately, a transformation can negatively affect the performance of a program. On the other hand, if the insertion points of new components are decoupled from the other parts of the program, the addition not only has minimal impact on performace, but also has the additional benefit of making code more maintainable and understandable. We are assuming that the decoupling is done as a preparatory step, probably by applying a transformation to partition the program. The benefit, then, stems from the fact that the decoupling improves the simplicity and understandability of architecture. Proper partitioning requires deep understanding of the architecture; programmers have to make these architectural decisions. No tools or transformations can take these decisions efficiently (yet). Some transformations come with many tradeoffs, others, especially the code-level ones, with few. Every security-oriented program transformation documents these tradeoffs explicitly. Once the programmer makes a decision, the transformation guides the programmer to make sure all steps are performed correctly. V. E XAMPLE OF A PPLYING P ROGRAM T RANSFORMATIONS We will describe our experience in applying 2 program transformations and how they removed real vulnerabilities. A. Manually Applying a Program Transformation A Single Access Point transformation secures system perimeter by minimizing the number of access points. We applied the transformation to extract the access points in jftpd version 0.3, an FTP server written in Java. It has 11 Java files with 2138 lines of code. We extracted the functions that interact with external users, and created a gatekeeper component. The gatekeeper component runs in a separate virtual machine and communicates with the internal component using RMI. We manually performed the steps inside Eclipse IDE; one can easily visualize that an automated tool can be built to perform these tasks. The program has 3 main classes: Server, ServerPI and ServerDTP. Server class binds to a socket, and listens to client requests. When a request comes, it creates a ServerPI thread. ServerPI method clientloop parses incoming requests and processes them. It contains several handler methods, e.g., handle_user. The handler methods call methods in ServerDTP.

ServerDTP processes the tasks, e.g., sendFile method processes RETR command submitted by handle_retr, receiveFile method processes STOR command submitted by handle_stor, etc. Figure 2 shows the classes.

This transformation does not remove any particular vulnerability, but it improves the overall security because we can apply Least Privilege transformation to run the gatekeeper component with a different privilege level, or we can apply transformations to add policy enforcement point, authentication component, authorization component, input validation component. The next example describes a transformation that removes well-known security vulnerabilities. B. Applying Program Transformation with a Tool

Figure 2.

Main classes and methods of jftpd

The extraction of the gatekeeper component is an instance of Partitioning transformation. The most efficient partitioning has to minimize inter-component communications. For jftpd, Server and ServerDTP fall into separate partitions: suppose we call them gatekeeper partition and processor partition correspondingly. ServerPI is split between the partitions. The parsing part is in the gatekeeper partition, while the handler methods are in the processor partition. Thus, the only inter-component communication is the ServerPI parser (clientloop) remotely calling (RMI) the appropriate ServerPI handler method. Figure 3 shows the resulting partition.

Figure 3.

Class diagram showing the partitions

We manually made the changes in two steps. In the first step, we created the partitions by creating a separate package namespace called gatekeeper and moved all the parts that would eventually be in the gatekeeper partition in this package. Moving class to a package is a refactoring, as well as splitting a class (Extract Class [4] refactoring). Eclipse provides tool support for these. Then we replaced the local calls in ServerPI in the gatekeeper partition with RMI calls in three steps. (1) We created an RMI interface describing the handler methods in ServerPI in the processor partition. (2) We converted ServerPI class in the gatekeeper partition so that its local calls are replaced with RMI calls described by the interface. (3) We converted ServerPI class in the processor partition so that it implements the RMI interface. This can involve adding a stub. The first step is an instance of Extract Interface [4] refactoring. The second and third steps are not direct instances of refactoring, but they can be automated easily. In fact, Java RMI framework automates tasks such as stub generation.

A Safe Library Replacement transformation replaces unsafe library functions with safe alternatives. We have developed a tool in the Eclipse IDE to apply this transformation on C programs. It replaces strcpy and strcat functions with g_strlcpy and g_strlcat functions from the glib 2.0 library. The safe functions require an additional length parameter, which the tool supplies. We have applied our tool on two open source C programs [10]: a pdf/ps viewer (gv) and a zip library (zziplib). These programs have recent buffer overflow exploits [38] [39], and the exploit codes are available. Our tool replaced 88 out of 107 instances of strcpy and strcat functions in gv, and all 5 instances in zziplib. It modified 4 instances in the configuration files of gv, and 15 instances in the Makefiles of zziplib; these changes included the new library information so that the programs compiled. We manually replaced the remaining instances of unsafe functions in gv, but our tool can be improved to handle these cases. In both cases, the resultant programs did not have buffer overflow vulnerability. They compiled correctly, and showed the same behavior. They passed all the test cases when we ran the make test command. We also applied our program transformation on large code bases, e.g. kerberos 5 kadmind 1.5.1. It contains 1045 C programs with 369,442 lines of C code, 129 Makefiles containing 102,018 lines of code, and 11 configuration file containing 9718 lines of code. Our transformation modified 470 strcat and strcpy instances, 110 instances in Makefiles and 5 instances in the configuration files. 35 instances of strcpy and 3 instances of strcat were not modified. These instances have complex patterns for the parameters. VI. PATTERNS T RANSFORM A RCHITECTURE We have started from a security pattern catalog and identified patterns that can be described as a program transformation. Our approach sheds a new light on the usefulness of a security pattern, by promoting a pattern from a guideline for improving security to a concrete mechanism of transforming architecture. There are several threats to validity of our approach. Are the program transformations really useful? Do they cover important security problems? Are there too many transformations to be useful? How hard is it to automate program

transformations that make large, architectural changes? This section discusses these issues. A. Do Transformations Secure Applications? Section V gives examples of some program transformations being applied to remove real vulnerabilities from real systems. We have applied many other program transformations in our catalog, either manually or using proofof-concept tools, and removed real vulnerabilities from real programs. Some program transformations, e.g., Single Access Point, do not remove a vulnerability; they make other vulnerabilities harder to exploit. We have described these transformations and described how to create a tool to automate the steps. B. Do Transformations Cover Important Security Problems? We have derived our program transformation catalog by analyzing the problem domain and solution domain of security. However, instead of finding all possible security problems, we have restricted ourselves to the most important security vulnerabilities, identified by the vulnerability trend reports. On the other hand, we have searched for security solutions in our security pattern catalog, that represents the collective experience of the security patterns community. The pattern catalog is a summation of solutions described by many researchers; it covers the solution space better than any arbitrary approach. Our approach lies in the middle ground between two extreme approaches of deriving a catalog. One extreme is building a catalog by arbitrarily listing a number of security solutions. While it is easy to adopt, the resulting catalog does not provide any confidence in terms of coverage: it may miss many important transformation opportunities. The closest analog of our program transformation catalog, the refactoring catalog [4], was built this way; the catalog was later extended by other practitioners with new refactorings. On the other hand, the most rigorous way to build a catalog of program transformations is to enumerate every possible security problem and their solutions, build tools to implement candidate solutions as program transformations, allow developers to use the tools and identify which transformations are more useful, and finally include them in the catalog. It is impossible for a researcher to follow this rigorous path; building tools and user testing each transformation in a catalog would take hundreds of person years. We analyzed the problem domain of security as our first step (in section III-A). We identified the five most important security problems. Our security-oriented program transformation catalog includes transformations for all classes of security problems: 10 for unvalidated input vulnerabilities, 6 for broken authentication vulnerabilities, 7 for broken access control vulnerabilities, 5 for improper error handling vulnerabilities, and 4 for Denial of Service vulnerabilities. The remaining 5 program transformations in our catalog are

‘fundamental program transformations’. These transformations do not target any specific vulnerabilities, but they make other vulnerabilities harder to exploit. C. Why So Many Transformations? 37 program transformations may be too many for people to use. This large number is a result of our vulnerabilityspecific approach to finding transformations. Perhaps if we considered them differently, we could describe our lessons in fewer transformations. One alternative approach for deriving a program transformation catalog could be a look at the general strategies of transforming programs. For example, many of our program transformations are examples of connector transformations [40], which define types of architectural changes that can be applied to connectors. Our transformations are examples of data translation (e.g., Decorated Filter) or add redirect where new components are added (e.g. Message Intercepting Gateway). However, other transformations do not fit this classification. Fuzzing and Randomization require making changes to many existing components. Partitioning means breaking up components, while chroot jail transforms primarily the execution environment of a process so that it can run inside a constrained environment. This classification does not help us, because applying security solutions means crossing and breaking architectural boundaries of components and connectors. Considering transformations from the point of view of components and connectors would yield even more types of program transformations. Nevertheless, top-down categorization is prevalent in software architecture research. Fahmy and Holt [41] describe 6 types of software architecture transformations: Lifting, Hide Interior/Exterior, Diagnostic, Sifting, Forward Repair and Reverse Repair. Ryoo et al. [42] discuss the classification of security tactics, where each tactic addresses a single architectural force; in their preliminary classification scheme only 10 tactics are listed. We feel this is because the authors focus on defining distinct categories rather than on completeness. More types of transformations and tactics are likely to be identified later. Alternatively we could identify the smaller building blocks that comprise our transformations. Several program transformations in our catalog add a new component, e.g., an authentication enforcer component, an authorization enforcer component, a perimeter filter component, etc. Each transformation is distinct, because it creates a component by composing classes of a specific security framework, or it creates a component according to a specific template. Cataloging them together, for instance as a ‘compose framework class transformation, does not make them general-purpose the way connector transformations are, because each of these transformations applies to specific security problems. Some program transformations share common steps, but their end goals are vastly different. A Partitioning transfor-

Table IV F EASIBILITY OF B UILDING P ROGRAM T RANSFORMATION T OOLS

mation distributes functionality among various components and modifies inter-component communication mechanism. Many of the same steps are applied in a Single Access Point transformation, that distributes components to extract access points of an application. The apparent similarity in their mechanisms is complicated by the goals of these two distributions, which means the analysis and the implementation mechanism will be different. Furthermore, other steps of these transformations are different. Identifying the building blocks of all the transformations would result in an even larger catalog. We have limited ourselves to only the most important security vulnerabilities and explored corresponding security patterns. We eliminated similar or overlapping solutions while developing our pattern catalog. There has been a conscious effort throughout the process to minimize the number of program transformations and remove overlaps. 37 program transformations is not too much. By comparison, Fowler’s catalog [4] contains 72 refactorings. Besides, describing program transformations in terms of vulnerabilities makes it easy for application developers to apply the transformations. Tool builders might prefer that the catalog contains building blocks that are composed into security solutions. Here, we have taken an application developers perspective. Our aim is to understand the feasibility of introducing security solutions as program transformations; a domain specific approach that explores security vulnerabilities is more appropriate for this study. The tool builders’ perspective is a logical next step of implementing the program transformations. D. Can Security Patterns Become Automated Program Transformations? We have derived the program transformation catalog by including only those security patterns that can be automated. Yet, it is easy to build tools for some program transformations; for a few others, only parts of the transformation can be automated. It is natural that the first tools are the ones that are the easiest to build. However, the importance of these tools cannot be minimized, because they target

the most important security vulnerabilities. Input validation vulnerabilities are the most prominent, especially buffer overflow vulnerability, SQL injection vulnerability and cross site scripting vulnerability. Our catalog lists 10 program transformations to prevent input validation vulnerabilities, e.g., Safe Library Replacement, Safe Type Replacement etc. These program transformations make small changes at each program point, but the changes occur at many points. Tools that make small, structural changes are easy to build, and the frequency of the changes suggests that it can be tedious for a human to make them consistently without tool support. Table IV lists our program transformations based on two criteria: how feasible is it to build tools for program transformations, and how much effort is needed to apply the solution manually? The top-left quadrant lists the largest number of program transformations, including the program transformations that prevent injection attacks. Most of these program transformations make small, but numerous changes. Some apparently difficult program transformations such as Single Access Point and Partitioning are also listed. We described how parts of these transformations can be automated by reusing refactoring tools and other remoting tools. A Partitioning transformation first distributes program components and may create new components; developers can apply refactoring tools that extract classes, split classes and move methods to introduce these changes step by step. Developers have to determine a partitioning strategy beforehand; this step can be aided by architecture visualization tools. Once the partitioning is done, some local method calls are replaced by remote method calls. There are existing tools that automate these steps to improve performance [43] [44]. The top-right quadrant lists program transformations that are difficult to perform manually, and are difficult to automate. These program transformations introduce a lot of change. Making these changes requires a lot of behavioral information. These program transformations are more interactive than the ones in the top-left quadrant; developers perform some steps manually and use automated tools to perform some of the steps. Consider the Add Authentication Enforcer transformation that composes an authentication component using an existing framework. The default authentication component must be customized by developers to fit their application; this involves specifying authentication type (username/password), source of user inputs, authentication knowledge base (username/password store), and the outcome of a successful authentication (which principals and credentials are added to the subject), etc. Many of these steps can be automated, but others remain must be done manually. The bottom-left quadrant lists two program transformations that perform small changes in a few places. These program transformations are easy to automate, but the tools may not be useful enough, since the same change can be easy to introduce manually. The bottom-right quadrant contains one program trans-

formation that is easy to perform manually, but is hard to automate. Add Account Lockout transformation restricts authentication attempts to a few tries to prevent a brute-force attack against authentication tokens. The transformation might be as simple as adding a for loop with a conditional clause. But finding where to insert the code is difficult if the authentication component is implemented arbitrarily. A tool for this transformation is unnecessary because of the small change the transformation makes in very few points in a program. VII. C ONCLUSION Security-oriented program transformations are a power tool for securing existing software systems. They capture the expertise of security patterns in a methodical, structured form that makes them easier to apply to existing software. We have described the process of deriving security-oriented program transformations to show that they are based on proven solutions, rather than experimental work. They can be used to remove the most pressing security vulnerabilities from the code, while transforming its underlying architecture to better prepare it for future threats. R EFERENCES [1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns. Addison-Wesley, 1995. [2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture: A System of Patterns, ser. Wiley series in Software design patterns. John Wiley & Sons, 1996. [3] K. Beck and R. E. Johnson, “Patterns generate architectures,” in Object-Oriented Programming, Proceedings of the 8th European Conference ECOOP’94, ser. Lecture Notes in Computer Science, M. Tokoro and R. Pareschi, Eds., vol. 821. Bologna, Italy: Springer, 4—8 Jul. 1994, pp. 139–149. [4] M. Fowler, Refactoring: Improving The Design of Existing Code. Addison-Wesley, Jun 1999. [5] J. Kerievsky, Refactoring to Patterns. Addison Wesley, 2004. [6] M. Hafiz, P. Adamczyk, and R. E. Johnson, “Organizing security patterns,” IEEE Software, vol. 24, no. 4, pp. 52–60, July/August 2007. [7] M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Buschmann, and P. Sommerlad, Security Patterns: Integrating Security and Systems Engineering. John Wiley and Sons, December 2005. [8] C. Steel, R. Nagappan, and R. Lai, Core Security Patterns : Best Practices and Strategies for J2EE(TM), Web Services, and Identity Management. Prentice Hall PTR, Oct 2005. [9] D. Garlan and M. Shaw, “An introduction to software architecture,” in Advances in Software Engineering and Knowledge Engineering, V. Ambriola and G. Tortora, Eds. Singapore: World Scientific Publishing Company, 1993, pp. 1–39. [10] M. Hafiz, P. Adamczyk, and R. Johnson, “Systematically eradicating data injection attacks using security-oriented program transformations,” in Proceedings of the International Symposium on Engineering Secure Software and Systems (ESSoS-09), Feb 2009. [11] J. Yoder and J. Barcalow, “Architectural patterns for enabling application security.” In Proceedings of the 4th Conference on Patterns Language of Programming (PLoP’97)., 1997. [12] M. Schumacher and U. Roedig, “Security engineering with patterns.” In Proceedings of the 8th Conference on Patterns Language of Programming (PLoP’01)., 2001. [13] F. L. Brown Jr., J. DiVietri, G. D. Villegas, and E. B. Fernandez, “The authenticator pattern,” 1999. [14] E. B. Fernandez and J. C. Sinibaldi, “More patterns for operating systems access control,” In Proceedings of the European Conference on Patterns Language of Programming (EuroPLoP’03), 2003. [15] J. Hogg, D. Smith, F. Chong, D. Taylor, L. Wall, and P. Slater, Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0. Microsoft Press, March 2006.

[16] B. Blakley and C. Heath, “Security design patterns technical guide– Version 1,” Open Group(OG), Tech. Rep., 2004. [17] D. Kienzle, M. Elder, D. Tyree, and J. Edwards-Hewitt, “Security patterns repository version 1.0,” http://www.scrypt.net/∼celer/ securitypatterns/repository.pdf, 2002. [18] S. Romanosky, “Security design patterns part 1,” http://citeseer.ist.psu. edu/575199.html, Nov 2001. [19] S. Romanosky, “Enterprise security patterns,” 2002, http://citeseer.ist. psu.edu/romanosky02enterprise.html. [20] M. Hafiz and R. Johnson, “Evolution of the MTA architecture: The impact of security,” Software—Practice and Experience, vol. 38, no. 15, pp. 1569–1599, Dec 2008. [21] M. Hafiz, “A collection of privacy design patterns,” In Proceedings of the 13th Conference on Patterns Language of Programming (PLoP’06), 2006. [22] D. Hybertson, J. Heaney, and A. Reedy, “Conceptual aspects of security patterns,” 2002. [23] J. Heaney, D. Hybertson, A. Reedy, S.Chapin, T. Bollinger, D. Williams, and M. Kirwan Jr., “Information assurance for enterprise engineering,” In Proceedings of the 9th Conference on Patterns Language of Programming (PLoP’02), 2002. [24] J. A. Zachman, “A framework for information systems architecture,” IBM Systems Journal, vol. 26, no. 3, 1987. [25] D. Trowbridge, W. Cunningham, M. Evans, L. Brader, and P. Slater, “Describing the enterprise architectural space,” MSDN, June 2004. [26] Open Web Application Security Project (OWASP), “Attacks,” http: //www.owasp.org/index.php/Category:Attack, 2008. [27] US-CERT, “Vulnerability notes by severity metric,” Apr 2008. [28] SANS Institute, “SANS top-20 2007 security risks (2007 annual update),” November 2007. [29] S. Christey and R. Martin, “Vulnerability type distributions in CVE, version 1.1,” http://cwe.mitre.org/documents/vuln-trends/index.html, May 2007. [30] Symantec Enterprise Security, “Symantec Global Internet Security Threat Report. Trends for 2008.” [31] J. Viega and G. McGraw, Building Secure Software: How to Avoid Security Problems The Right Way. Addison-Wesley, 2002. [32] R. Veryard and A. Ward, “Trusting components and services,” http://cbdiforum.com/report summary.php3?topic id=23&report= 411&order=author&start rec=15, 2001. [33] T. Miller and T. de Raadt, “strlcpy and strlcat — Consistent, safe, string copy and concatenation,” in 1999 Usenix Annual Technical Conference, Monterey, California, USA, 1999. [34] F. Cavalier III, “Libmib allocated string functions,” http://www. mibsoftware.com/libmib/astring/. [35] International Organization for Standardization, ISO/IEC 24731: Specification For Secure C Library Functions, 2004. [36] A. Baratloo, N. Singh, and T. Tsai, “Transparent run-time defense against stack-smashing attacks,” in 2000 USENIX Annual Technical Conference: San Diego, CA, USA, 2000. [37] A. Narayanan, “Design of a safe string library for C,” Software— Practice and Experience, vol. 24, no. 6, pp. 565–578, 1994. [38] Bugtraq ID 20978, “gv stack buffer overflow vulnerability,” http:// www.securityfocus.com/bid/20978, 2006. [39] Bugtraq ID 23013, “zzipLib zzip open shared io stack buffer overflow vulnerability,” http://www.securityfocus.com/bid/23013, 2007. [40] B. Spitznagel and D. Garlan, “A compositional approach for constructing connectors,” in WICSA ’01: Proceedings of the Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA: IEEE Computer Society, 2001, p. 148. [41] H. Fahmy and R. C. Holt, “Software architecture transformations,” in Proceedings of the International Conference on Software Maintenance (ICSM’00), ser. ICSM ’00. Washington, DC, USA: IEEE Computer Society, 2000, pp. 88–. [42] J. Ryoo, P. Laplante, and R. Kazman, “A methodology for mining security tactics from security patterns,” Hawaii International Conference on System Sciences, 2010. [43] M. Tatsubori, T. Sasaki, S. Chiba, and K. Itano, “A bytecode translator for distributed execution of “legacy” Java software,” in ECOOP ’01: Proceedings of the 15th European Conference on Object-Oriented Programming. London, UK: Springer-Verlag, 2001, pp. 236–255. [44] E. Tilevich and Y. Smaragdakis, “J-orchestra: Automatic Java application partitioning,” in ECOOP ’02: Proceedings of the 16th European Conference on Object-Oriented Programming. London, UK: Springer-Verlag, 2002, pp. 178–204.