Patterns Transform Architectures

Munawar HafizUniversity of Illinois

Email: mhafiz@illinois.edu

Paul AdamczykEmail: paul.adamczyk@gmail.com

Ralph JohnsonUniversity of Illinois

Email: johnson@illinois.edu

Abstract—Software patterns have been used to guide de-velopers and to disseminate expert knowledge. This paperdescribes our approach of expressing patterns as programtransformations. We derived from our catalog of security pat-terns, a catalog of security-oriented program transformations.We describe how these program transformations can be appliedto remove security vulnerabilities. Our paper is a first exampleof applying patterns to actively transform architectures.

Keywords-Pattern; Architecture; Transformation; Security

I. INTRODUCTION

Software design remains elusively hard. While designtechniques improve and mature, the expectations grow evenfaster. Stakeholders expect software with more capabilitiesand more flexibility. Implicitly, they also expect better qual-ity attributes, such as availability, performance, and security.The inadequacy of current design techniques is especiallyvisible in the domain of security.

Patterns [1] [2] document best practices in software designand architecture. They describe both the approach and thereasoning behind it. Patterns can be used to design a system,to drive design changes, or to document design [3]. Smallerpatterns (e.g., OBSERVER [2]) are now included in mostlanguage libraries; many sites store pattern source codethat can be copied. But, applying larger patterns is moreinvolved than copying examples. They are better explainedas sequences of refactorings [4], as in “Refactoring toPatterns” [5], which explains the steps required to introducedesign 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 canbe applied to remove existing vulnerabilities or to addprotection against new attacks. Similar to design patterns, itis easier to apply security patterns if there are specificationsand tools for applying them to software. We have developedsuch specifications and tools, as security-oriented programtransformations [10]. Similarly to design patterns, sometransformations can be applied automatically by a tool,while others define concrete steps but require programmerintervention. However, improving security of a (new orexisting) system is different than refactoring, because theirgoal is to improve the design, not to preserve the behavior.

We have two contributions. First, we describe how to im-prove the security of a system by applying security-oriented

program transformations. These program transformations arenot silver bullets; using them requires skill and knowledge ofthe program being transformed. They are instead power toolsthat 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 astep-by-step refinement process, in which the steps can beautomated. But the most important contribution of this paperis the promotion of patterns from a passive guideline fordevelopers to an active program transformation mechanismthat developers can use. Thus, patterns are valuable as amechanism to transform architecture.

We first describe how we captured the guidance fromsecurity patterns in the program transformations. We showexample architectural transformations and discuss prelimi-nary results in applying them. Finally, we discuss severalissues of using patterns and program transformations.

II. SECURITY PATTERNS

A security pattern describes a solution that experts use tosolve a security problem in a context. We have been main-taining a comprehensive catalog of all published securitypatterns [6]. The security pattern catalog currently contains96 patterns. The catalog is a union of all security patternsthat appear in many books, catalogs and papers.

A. Security Pattern Sources

There are 3 books on security patterns. Schumacher leda working group on security patterns to write a securitypattern book [7]. This book had 46 security patterns fromthe domain of enterprise security and risk management,identification and authentication, access control, accounting,firewall architecture, and secure internet applications. Thisbook aggregates many previous works on security patterns,including the first catalog of security patterns [11], Schu-macher [12] and Fernandez’s [13] [14] work on securitypatterns, etc. Steel et al. [8] described 23 security patterns forJ2EE based applications, Web services and identity manage-ment in their book. Microsoft’s Patterns and Practices grouppublished 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 theOpen Group forum. It contained 13 patterns: 5 patterns forimproving reliability, and 8 for security. Kienzle et al. [17]

listed 26 patterns and 3 mini patterns in their securitypatterns catalog. Romanosky [18] [19] compiled two patterncatalogs containing 12 patterns in total.

We have created two pattern catalogs. The first stemsfrom our study of the evolution of mail transfer agentarchitecture [20]. This contains 11 security patterns, and 4reliability patterns. These patterns are not specific to mailtransfer agents; they can be used by the designers of othersecure systems. Our second catalog compiles a collection of12 privacy design patterns [21].

The pattern sources describe 174 security patterns, butwith many overlaps. We developed our catalog of 96 patternsby removing the overlaps. For example, patterns for authenti-cation have been listed in a number of pattern catalogs underdifferent names, e.g., AUTHENTICATOR [14] [7], SECURITYPROVIDER [18], AUTHENTICATED SESSION [17], AU-THENTICATION ENFORCER [8], and DIRECT AUTHENTI-CATION [15]. We have one AUTHENTICATION ENFORCERpattern for authentication, removing language-specific andcatalog-specific descriptions of this pattern [6].

B. Organizing the Pattern Catalog

A catalog of 96 patterns is overwhelming. It is hard fordevelopers to find a pattern they need, let alone know whento use it. We attempted to organize the security patterns [6]by grouping them into small, correlated sets. We describehere one classification scheme that eventually hepled usidentify the patterns that can be described as security-oriented program transformations.

Several security pattern authors [7] [22] [23] have at-tempted to classify their respective pattern catalogs usingthe Zachman framework. Zachman framework [24] wasintroduced in 1987 as a table. Its 5 rows describe thelevels of information model from the perspective of variousstakeholders, e.g., the customer or the owner, the designer,the builder, etc. The 6 columns describe ways of describingan 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]. Outof the 7 columns of the table, 6 are from the Zachmanframework. The seventh column (Scorecard) includes pat-terns for testing. The rows describe stakeholders similar tothe Zachman framework, but they have been specified inroles of finer granularity.

Table I shows how the security patterns are classifiedusing this tabular scheme as well as some sample patterns. Itshows only relevant rows of the larger table. As an exampleof classification, consider the SAFE DATA STRUCTURE [20]pattern. This pattern is applied to remove the array boundschecking vulnerability in a programming language with nogarbage collection. A system written in C is vulnerableto buffer overflow attacks because of unsafe array opera-tions, e.g., unsafe string handling. SAFE DATA STRUCTURE

Table ICLASSIFICATION OF SECURITY PATTERNS USING THE ENTERPRISE

ARCHITECTURAL SPACE ORGANIZING TABLE

advocates the inclusion of length and allocated memoryinformation with a data structure. This pattern is consideredin the development phase of an application when the safestring processing libraries are written or re-used. Hence thispattern fits into the cell defined by the Developer row ofApplication Architecture perspective and the Data column.

The tabular scheme can not classify 16 patterns becausethey fall into multiple cells in the table; Table I shows someexamples. The scheme fails to distinguish low level patternsfrom high level patterns. We improved it using a classifica-tion scheme [6] that uses domain knowledge (threat model)and embraces hierarchy. But this tabular classification helpedus identify the patterns that can be described as programtransformations. We describe the process in the next section.

III. FROM PATTERNS TO PROGRAM TRANSFORMATIONS

We derived a security-oriented program transformationcatalog by surveying the problem domain and solutiondomain of security. We identified the most important securityproblems by surveying various vulnerability-trend reports.Then we identified the solutions that solve these problemsby surveying the security patterns catalog. Currently, thesecurity-oriented program transformations catalog contains37 transformations. The pattern catalog contributes to mostof the program transformations. 96 patterns contribute to 30program transformations. The remaining 7 transformationsoriginate from well-known security solutions.

The entire activity can be summarized in four steps:

(A) Analyzing the problem domain and identifying relevantsecurity problems.

(B) Analyzing security pattern catalog for candidates thatcan be described as program transformations.

(C) Identifying other well-known security solutions that canbe described as program transformations.

(D) Describing the mechanism of security-oriented programtransformations.

The following sections describe these steps.

Table IIFINDING CANDIDATE SECURITY PATTERNS

A. Analyzing the Problem Domain

We studied vulnerability trend reports [26] [27] [28][29] [30] to find the important security problems. Weidentified 5 important vulnerability classes: input validationvulnerabilities, authentication vulnerabilities, access controlvulnerabilities, error handling vulnerabilities, and denial ofservice vulnerabilities. Our vulnerability classes have beenderived primarily from the OWASP [26] list, and have beensupported by other vulnerability trend reports.

Next, we identified the relevant solutions.

B. Analyzing the Security Pattern Catalog

Our pattern catalog accumulates the experience of theentire security pattern community and is a fair representationof the solution domain of security. We analyzed the catalogand found 30 security solutions that can be described asprogram transformations. This was done in two steps.(1) We used the tabular classification scheme for security

patterns to identify patterns that describe solutionsapplicable to software. This step resulted in 70 patterns.

(2) Next, we analyzed the implementation mechanism ofeach remaining pattern. Some patterns describe high-

level policies, some describe solutions that are too dif-ficult to implement; also there are patterns that describethe same technique applied in different contexts. Afterremoving these, we had 29 patterns that contributed to30 security-oriented program transformations.

We will describe these two steps in detail.1) Using Pattern Classification Scheme to Find Rele-

vant Patterns: Not all security patterns are about codeand software design. The tabular classification scheme fororganizing security patterns identifies the patterns relevant tosoftware. Table I shows the scheme. In the table, the suitablecandidates for program transformations are patterns from therows grouped by application architecture perspective, and inthe function and data columns. This constitutes 70 patterns.

Among the 26 patterns we discarded, 10 patterns are aboutnon-software artifacts. Some of these patterns are related tohardware. PACKET FILTER FIREWALL [7] and STATEFULFIREWALL [7] guide practitioners how to select the most ap-propriate firewall, while DEMILITARIZED ZONE [7] guideshow to deploy multiple firewalls.

The remaining 16 patterns could not be classified in TableI, because they straddled multiple cells in the classification

table. We counted the patterns that fell in either of the dataor function columns and the rows grouped by applicationarchitecture perspective. There were 9 patterns.

The remaining 7 are about software processes. There aresecurity patterns for asset evaluation, risk assessment, andthreat modeling [7] that describe a process, and could notbe described as a program transformations of software.

In total, we selected 79 patterns from the catalog. Weanalyzed these patterns and identified the ones that can bedescribed as program transformations in the next step.

2) Finding Patterns that could be Described as ProgramTransformations: Out of the remaining 79 patterns, 14describe very high level solutions, 26 describe solutions thatare hard to implement, and 10 describe solutions common toother patterns. Removing these leaves 29 security patterns,that contribute to 30 program transformations. Table IIshows how the 79 patterns are partitioned.

14 patterns prescribe high level solutions. An example ofsuch a pattern is DEFENSE IN DEPTH [31]; it is a securityprinciple that is fundamental in any security design, but itis too general to form a program transformation. Anotherexample is the ANONYMITY SET [21] pattern. It is a corepattern for privacy preserving applications. It suggests thatthe fundamental principle of keeping information private isto mix it with other information and make private infor-mation indistinguishable. But implementing the high levelsolution depends on the context of an application; it cannotbe expressed as a general purpose program transformation.

26 security patterns provide solutions that are too com-plex. For example, LIMITED ACCESS [7] and FULL ACCESSWITH ERRORS [7] describe how secure user interfacescan be designed. For an application with many users anddifferent privilege levels, one option is to give each usera limited view of the user interface, i.e., only the optionsthat his/her privilege allows. The other option is to show allfunctions to all users, but only allow access to functions thatare permitted. Graphical user interface is difficult to codeand almost impossible to code automatically. Therefore,automatically adapting an existing user interface to followeither options is not possible. Another example is the ROLEBASED ACCESS CONTROL [7] pattern. This complex patternintroduces many context sensitive changes in the code. It ishard to describe its general solution as a transformation.

In 10 cases, the solution mechanism of multiple secu-rity patterns is the same; thus multiple security patternscorrespond to one program transformation. For example,input filtering is an important protection mechanism that mo-tivates CONTENT DEPENDENT PROCESSING [20] pattern.The filtering mechanism in an application follows the PIPESAND FILTERS [2] architectural pattern: an input variablepasses through a series of filters. The same mechanismapplies to other cases when data has to be modified, e.g.,encoding or decoding data, encrypting or decrypting, usingparity for error detection and correction, or padding data

packets so that all packets are of the same length. Each ofthese cases is defined by its own security pattern, but theunderlying security-oriented program transformation is thesame. Similarly, Partitioning program transformation in ourcatalog is a combination of COMPARTMENTALIZATION [31]and DISTRIBUTED RESPONSIBILITY [32] patterns.

29 security patterns contribute to 30 security-orientedprogram transformations. SAFE DATA STRUCTURE [20] pat-tern contributes to 2 program transformations: Safe LibraryReplacement and Safe Type Replacement. Table III lists thepatterns and corresponding program transformations.

C. Program Transformations from Other Sources

Table III lists 7 program transformations in our catalogthat do not derive from security patterns. Instead theydescribe how to transform a program to implement well-known security solutions. Among these are program trans-formations that introduce cryptographic operations. Programtransformations to create a message digest, or a messagesignature describe how classes of Java or .NET security APIcan be composed to perform the tasks. Similarly, Encryp-tion/Decryption transformation composes Java or .NET se-curity API. There are security patterns that use cryptographicsolutions (CLIENT DATA STORAGE [17] and ENCRYPTEDSTORAGE [17] patterns in table II), but there are no specificpatterns describing these cryptographic operations. ExplicitType Enforcement transformation adds missing type infor-mation to prevent integer overflow errors that originate fromthe use of integer datatype in an unsafe context. GuardedObject transforms a program to encapsulate each resourceand the corresponding set of permissions in one object. LeastPrivilege transformation automatically analyzes a program toidentify the lowest privilege level required. Fuzzing transfor-mation adds user-directed white box fuzzing components.

D. Describing Mechanism of Program Transformations

The final step is defining the mechanics of transforma-tions. The mapping from a security pattern to a programtransformation is not trivial. A security pattern provides ahigh-level description of a security solution and the justi-fication for it. It does not describe all the implementationdetails, nor the steps to transform a program to introducethe solution. For each candidate security pattern, we had toidentify the implementation method and then describe thetransformation steps. For example, SAFE DATA BUFFER [20]describes a solution to prevent buffer overflow attacks.Buffer overflow occurs because an unsafe language such asC does not check buffer bounds before performing a bufferoperation. SAFE DATA BUFFER says that one should checkfor length information before performing any operation onthe data. The lessons from this pattern have been imple-mented by a number of safe string libraries (e.g., strlcatand strlcpy [33], libmib library [34], ISO/IEC 24731 [35],libsafe library [36], etc) and safe data types [37] [20]. We

Table IIILIST OF SECURITY-ORIENTED PROGRAM TRANSFORMATIONS

have described the solution as a Safe Library Replacementtransformation as well as a Safe Type Replacement transfor-mation. Safe Library Replacement finds all instances of anunsafe library in a program and replaces each instance witha corresponding safe library. The Safe Type Replacementtransformation replaces char * pointers with a safe datatype that keeps length information of the buffer.

In some cases, the pattern describes a high level solution,yet the program transformation implements a concrete so-lution. For example, Randomization program transformationrandomizes a data variable in a program or instruction setof a system to make it distinct. This, as well as somevariants of Safe Library Replacement, has been motivatedfrom the MINEFIELD [17] pattern. The pattern suggests thatsystems should be varied so that each instance is different;therefore, some instances will be resistant to an attack vectorthat compromises other instancesstructural c of the samesystem. There is no general way to implement the pattern.The program transformations introduce concrete solutionsfor varying a system to make it secure.

Not all parts of program transformations can be auto-mated. But if a program transformation can be automated,tools will make it easier for developers to apply them. Someprogram transformations can be completely automated, butmost are interactive and require some manual intervention.

IV. WHAT IS A SECURITY-ORIENTED PROGRAMTRANSFORMATION?

A program transformation is a function that maps pro-grams to programs. A security-oriented program transforma-tion maps programs to security-augmented programs, i.e., itintroduces 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 inputsof a security-oriented program transformation? What is thespecification for a transformation? What type of changeis made by a security-oriented program transformation?Finally, what do we mean by improved security in the outputprograms? 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 inputprogram, i.e., the input programs and the target programs areof the same language. However, they include both source tosource and binary to binary transformations.

Specification for a Security-oriented Program Transfor-mation: Program transformations require user specification.A user applying a refactoring transformation needs to specifywhere to make the change, e.g., which variable to rename,which method to extract, etc. Even an automated transfor-mation such as compilation requires user specification inthe form of makefiles and build configurations. Security-oriented program transformations can be interactive similarto refactorings, or more automated similar to compilers.Nevertheless, they need some form of user specification.

To use a security-oriented program transformation, adeveloper has to follow three steps–1) identify the program

points where to apply a transformation, 2) determine whichtransformation to apply, and 3) use a tool to automaticallytransform the program. The first two tasks are manual: adeveloper typically supplies these parameters to a programtransformation with a manual specification. Consider a Sin-gle Access Point transformation that minimizes the numberof entry points of a program. With minimal access points, thenecessary checks on inputs can be performed at fewer entrypoints. But how does one minimize the number of entrypoints? Once all the entry points of a system are identified,it is possible through a series of code edits and refactoringsto merge entry points. However, it is hard to automate thepart of identifying all entry points. It is better if a developermanually specifies the entry points. A developer’s specifica-tion is the policy. The tools implement the mechanism; theyautomatically execute structural changes.

Structural Change made by a Security-oriented Pro-gram Transformation: A security-oriented program trans-formation makes structural changes (similar to refactorings),such as replacing method calls, composing classes, refactor-ing to patterns, distributing artifacts, etc. Structural changealso means that the corresponding tool does not need tohave a deep understanding of the program behavior; a userprovides the specification and a transformation tool performsthe mechanical change. A transformation makes the samechanges that a developer has to make to secure a program,only it makes the changes systematically.

Security-oriented program transformations are larger thantypical refactorings. They can be compared to large refac-torings comprising of many steps. Some of these steps canbe supported by tools while other steps can be manual.

The change, made by a transformation, can be categorizedby two issues: the scope of change and the impact of change.The same program transformation may make different typeof changes in different contexts. For example, a PARTITION-ING transformation for a C program splits a process so thateach partitioned process runs in its own address space. Onthe other hand, a PARTITIONING transformation for a Javaprogram distributes objects so that they can live in separatevirtual machines. The mechanism of a partitioning tool fora C program is different from that for a Java program.However, it should be general-purpose in the sense that adeveloper should be able to apply the transformation on anyC program. Compare this to a patch program that usesdiff outputs to transform a program. It is designed to workwith a single version of a program. But security-orientedprogram transformations are more general.

The impact of change made by a security-oriented pro-gram transformation distinguishes them from refactorings.Security-oriented program transformations are not behavior-preserving the way refactorings are. A security-oriented pro-gram transformation preserves the correct behavior and fixesthe incorrect behavior caused by a security vulnerability. Ourprogram 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 isnot enough; one must have defense in depth [31]. Security-oriented program transformations should be composable.

Security is closely related with other quality attributes,e.g., performance, simplicity and maintainability. Many ofthe program transformations in our catalog add a newcomponent, e.g., a component for authentication, or a com-ponent for filtering inputs. When applied indiscriminately,a transformation can negatively affect the performance ofa program. On the other hand, if the insertion points ofnew components are decoupled from the other parts ofthe program, the addition not only has minimal impact onperformace, but also has the additional benefit of mak-ing code more maintainable and understandable. We areassuming that the decoupling is done as a preparatorystep, probably by applying a transformation to partition theprogram. The benefit, then, stems from the fact that thedecoupling improves the simplicity and understandability ofarchitecture. Proper partitioning requires deep understand-ing of the architecture; programmers have to make thesearchitectural decisions. No tools or transformations can takethese decisions efficiently (yet). Some transformations comewith many tradeoffs, others, especially the code-level ones,with few. Every security-oriented program transformationdocuments these tradeoffs explicitly. Once the programmermakes a decision, the transformation guides the programmerto make sure all steps are performed correctly.

V. EXAMPLE OF APPLYING PROGRAMTRANSFORMATIONS

We will describe our experience in applying 2 programtransformations and how they removed real vulnerabilities.

A. Manually Applying a Program Transformation

A Single Access Point transformation secures systemperimeter by minimizing the number of access points. Weapplied the transformation to extract the access points injftpd version 0.3, an FTP server written in Java. It has 11Java files with 2138 lines of code. We extracted the functionsthat interact with external users, and created a gatekeepercomponent. The gatekeeper component runs in a separatevirtual machine and communicates with the internal com-ponent using RMI. We manually performed the steps insideEclipse IDE; one can easily visualize that an automated toolcan be built to perform these tasks.

The program has 3 main classes: Server, ServerPIand ServerDTP. Server class binds to a socket, andlistens to client requests. When a request comes, it createsa ServerPI thread. ServerPI method clientloopparses incoming requests and processes them. It con-tains several handler methods, e.g., handle_user.The handler methods call methods in ServerDTP.

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

Figure 2. Main classes and methods of jftpd

The extraction of the gatekeeper component is an instanceof Partitioning transformation. The most efficient parti-tioning has to minimize inter-component communications.For jftpd, Server and ServerDTP fall into separatepartitions: suppose we call them gatekeeper partition andprocessor partition correspondingly. ServerPI is split be-tween the partitions. The parsing part is in the gatekeeperpartition, while the handler methods are in the processorpartition. Thus, the only inter-component communicationis the ServerPI parser (clientloop) remotely calling(RMI) the appropriate ServerPI handler method. Figure3 shows the resulting partition.

Figure 3. Class diagram showing the partitions

We manually made the changes in two steps. In thefirst step, we created the partitions by creating a separatepackage namespace called gatekeeper and moved all theparts that would eventually be in the gatekeeper partitionin 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 thegatekeeper partition with RMI calls in three steps.

(1) We created an RMI interface describing the handlermethods in ServerPI in the processor partition.

(2) We converted ServerPI class in the gatekeeper par-tition so that its local calls are replaced with RMI callsdescribed by the interface.

(3) We converted ServerPI class in the processor parti-tion so that it implements the RMI interface. This caninvolve adding a stub.

The first step is an instance of Extract Interface [4] refac-toring. The second and third steps are not direct instances ofrefactoring, but they can be automated easily. In fact, JavaRMI framework automates tasks such as stub generation.

This transformation does not remove any particular vul-nerability, but it improves the overall security because wecan apply Least Privilege transformation to run the gate-keeper component with a different privilege level, or wecan apply transformations to add policy enforcement point,authentication component, authorization component, inputvalidation component. The next example describes a trans-formation that removes well-known security vulnerabilities.

B. Applying Program Transformation with a Tool

A Safe Library Replacement transformation replaces un-safe library functions with safe alternatives. We have devel-oped a tool in the Eclipse IDE to apply this transformationon C programs. It replaces strcpy and strcat functionswith g_strlcpy and g_strlcat functions from theglib 2.0 library. The safe functions require an additionallength parameter, which the tool supplies.

We have applied our tool on two open source C pro-grams [10]: a pdf/ps viewer (gv) and a zip library (zzi-plib). These programs have recent buffer overflow ex-ploits [38] [39], and the exploit codes are available. Ourtool replaced 88 out of 107 instances of strcpy andstrcat functions in gv, and all 5 instances in zziplib. Itmodified 4 instances in the configuration files of gv, and 15instances in the Makefiles of zziplib; these changes includedthe new library information so that the programs compiled.We manually replaced the remaining instances of unsafefunctions in gv, but our tool can be improved to handlethese cases.

In both cases, the resultant programs did not have bufferoverflow vulnerability. They compiled correctly, and showedthe same behavior. They passed all the test cases when weran the make test command.

We also applied our program transformation on largecode bases, e.g. kerberos 5 kadmind 1.5.1. It contains 1045C programs with 369,442 lines of C code, 129 Makefilescontaining 102,018 lines of code, and 11 configuration filecontaining 9718 lines of code. Our transformation modified470 strcat and strcpy instances, 110 instances in Makefilesand 5 instances in the configuration files. 35 instances ofstrcpy and 3 instances of strcat were not modified. Theseinstances have complex patterns for the parameters.

VI. PATTERNS TRANSFORM ARCHITECTURE

We have started from a security pattern catalog andidentified patterns that can be described as a programtransformation. Our approach sheds a new light on theusefulness of a security pattern, by promoting a pattern froma guideline for improving security to a concrete mechanismof transforming architecture.

There are several threats to validity of our approach. Arethe program transformations really useful? Do they coverimportant security problems? Are there too many transfor-mations to be useful? How hard is it to automate program

transformations that make large, architectural changes? Thissection discusses these issues.

A. Do Transformations Secure Applications?

Section V gives examples of some program transforma-tions being applied to remove real vulnerabilities from realsystems. We have applied many other program transfor-mations in our catalog, either manually or using proof-of-concept tools, and removed real vulnerabilities fromreal programs. Some program transformations, e.g., SingleAccess Point, do not remove a vulnerability; they makeother vulnerabilities harder to exploit. We have describedthese transformations and described how to create a tool toautomate the steps.

B. Do Transformations Cover Important Security Problems?

We have derived our program transformation catalogby analyzing the problem domain and solution domain ofsecurity. However, instead of finding all possible securityproblems, we have restricted ourselves to the most importantsecurity vulnerabilities, identified by the vulnerability trendreports. On the other hand, we have searched for securitysolutions in our security pattern catalog, that represents thecollective experience of the security patterns community.The pattern catalog is a summation of solutions describedby many researchers; it covers the solution space better thanany arbitrary approach.

Our approach lies in the middle ground between twoextreme approaches of deriving a catalog. One extreme isbuilding a catalog by arbitrarily listing a number of securitysolutions. While it is easy to adopt, the resulting catalogdoes not provide any confidence in terms of coverage: itmay miss many important transformation opportunities. Theclosest analog of our program transformation catalog, therefactoring catalog [4], was built this way; the catalog waslater extended by other practitioners with new refactorings.On the other hand, the most rigorous way to build a catalogof program transformations is to enumerate every possiblesecurity problem and their solutions, build tools to imple-ment candidate solutions as program transformations, allowdevelopers to use the tools and identify which transforma-tions are more useful, and finally include them in the catalog.It is impossible for a researcher to follow this rigorouspath; building tools and user testing each transformation ina catalog would take hundreds of person years.

We analyzed the problem domain of security as our firststep (in section III-A). We identified the five most importantsecurity problems. Our security-oriented program transfor-mation catalog includes transformations for all classes ofsecurity problems: 10 for unvalidated input vulnerabilities,6 for broken authentication vulnerabilities, 7 for brokenaccess control vulnerabilities, 5 for improper error handlingvulnerabilities, and 4 for Denial of Service vulnerabilities.The remaining 5 program transformations in our catalog are

‘fundamental program transformations’. These transforma-tions do not target any specific vulnerabilities, but they makeother vulnerabilities harder to exploit.

C. Why So Many Transformations?

37 program transformations may be too many for peopleto use. This large number is a result of our vulnerability-specific approach to finding transformations. Perhaps if weconsidered them differently, we could describe our lessonsin fewer transformations.

One alternative approach for deriving a program trans-formation catalog could be a look at the general strategiesof transforming programs. For example, many of our pro-gram transformations are examples of connector transfor-mations [40], which define types of architectural changesthat can be applied to connectors. Our transformations areexamples of data translation (e.g., Decorated Filter) or addredirect where new components are added (e.g. MessageIntercepting Gateway). However, other transformations donot fit this classification. Fuzzing and Randomization requiremaking changes to many existing components. Partitioningmeans breaking up components, while chroot jail transformsprimarily the execution environment of a process so that itcan run inside a constrained environment. This classificationdoes not help us, because applying security solutions meanscrossing and breaking architectural boundaries of compo-nents and connectors. Considering transformations from thepoint of view of components and connectors would yieldeven more types of program transformations.

Nevertheless, top-down categorization is prevalent in soft-ware architecture research. Fahmy and Holt [41] describe 6types of software architecture transformations: Lifting, HideInterior/Exterior, Diagnostic, Sifting, Forward Repair andReverse Repair. Ryoo et al. [42] discuss the classificationof security tactics, where each tactic addresses a singlearchitectural force; in their preliminary classification schemeonly 10 tactics are listed. We feel this is because theauthors focus on defining distinct categories rather than oncompleteness. More types of transformations and tactics arelikely to be identified later.

Alternatively we could identify the smaller buildingblocks that comprise our transformations. Several programtransformations in our catalog add a new component, e.g.,an authentication enforcer component, an authorization en-forcer component, a perimeter filter component, etc. Eachtransformation is distinct, because it creates a componentby composing classes of a specific security framework, or itcreates a component according to a specific template. Cata-loging them together, for instance as a ‘compose frameworkclass transformation, does not make them general-purposethe way connector transformations are, because each of thesetransformations applies to specific security problems.

Some program transformations share common steps, buttheir end goals are vastly different. A Partitioning transfor-

Table IVFEASIBILITY OF BUILDING PROGRAM TRANSFORMATION TOOLS

mation distributes functionality among various componentsand modifies inter-component communication mechanism.Many of the same steps are applied in a Single AccessPoint transformation, that distributes components to extractaccess points of an application. The apparent similarity intheir mechanisms is complicated by the goals of these twodistributions, which means the analysis and the implementa-tion mechanism will be different. Furthermore, other steps ofthese transformations are different. Identifying the buildingblocks of all the transformations would result in an evenlarger catalog.

We have limited ourselves to only the most importantsecurity vulnerabilities and explored corresponding securitypatterns. We eliminated similar or overlapping solutionswhile developing our pattern catalog. There has been aconscious effort throughout the process to minimize thenumber of program transformations and remove overlaps. 37program transformations is not too much. By comparison,Fowler’s catalog [4] contains 72 refactorings.

Besides, describing program transformations in terms ofvulnerabilities makes it easy for application developers toapply the transformations. Tool builders might prefer thatthe catalog contains building blocks that are composed intosecurity solutions. Here, we have taken an application de-velopers perspective. Our aim is to understand the feasibilityof introducing security solutions as program transforma-tions; a domain specific approach that explores securityvulnerabilities is more appropriate for this study. The toolbuilders’ perspective is a logical next step of implementingthe program transformations.

D. Can Security Patterns Become Automated ProgramTransformations?

We have derived the program transformation catalog byincluding only those security patterns that can be automated.Yet, it is easy to build tools for some program transfor-mations; for a few others, only parts of the transformationcan be automated. It is natural that the first tools are theones that are the easiest to build. However, the importanceof these tools cannot be minimized, because they target

the most important security vulnerabilities. Input validationvulnerabilities are the most prominent, especially bufferoverflow vulnerability, SQL injection vulnerability and crosssite scripting vulnerability. Our catalog lists 10 programtransformations to prevent input validation vulnerabilities,e.g., Safe Library Replacement, Safe Type Replacement etc.These program transformations make small changes at eachprogram point, but the changes occur at many points. Toolsthat make small, structural changes are easy to build, andthe frequency of the changes suggests that it can be tediousfor a human to make them consistently without tool support.

Table IV lists our program transformations based ontwo criteria: how feasible is it to build tools for programtransformations, and how much effort is needed to applythe solution manually? The top-left quadrant lists the largestnumber of program transformations, including the programtransformations that prevent injection attacks. Most of theseprogram transformations make small, but numerous changes.Some apparently difficult program transformations such asSingle Access Point and Partitioning are also listed. Wedescribed how parts of these transformations can be au-tomated by reusing refactoring tools and other remotingtools. A Partitioning transformation first distributes programcomponents and may create new components; developerscan apply refactoring tools that extract classes, split classesand move methods to introduce these changes step by step.Developers have to determine a partitioning strategy before-hand; this step can be aided by architecture visualizationtools. Once the partitioning is done, some local method callsare replaced by remote method calls. There are existing toolsthat automate these steps to improve performance [43] [44].

The top-right quadrant lists program transformations thatare difficult to perform manually, and are difficult to au-tomate. These program transformations introduce a lot ofchange. Making these changes requires a lot of behavioralinformation. These program transformations are more in-teractive than the ones in the top-left quadrant; developersperform some steps manually and use automated tools toperform some of the steps. Consider the Add AuthenticationEnforcer transformation that composes an authenticationcomponent using an existing framework. The default au-thentication component must be customized by developersto fit their application; this involves specifying authenticationtype (username/password), source of user inputs, authenti-cation knowledge base (username/password store), and theoutcome of a successful authentication (which principals andcredentials are added to the subject), etc. Many of these stepscan be automated, but others remain must be done manually.

The bottom-left quadrant lists two program transforma-tions that perform small changes in a few places. Theseprogram transformations are easy to automate, but the toolsmay not be useful enough, since the same change can beeasy to introduce manually.

The bottom-right quadrant contains one program trans-

formation that is easy to perform manually, but is hardto automate. Add Account Lockout transformation restrictsauthentication attempts to a few tries to prevent a brute-forceattack against authentication tokens. The transformationmight be as simple as adding a for loop with a conditionalclause. But finding where to insert the code is difficult ifthe authentication component is implemented arbitrarily. Atool for this transformation is unnecessary because of thesmall change the transformation makes in very few pointsin a program.

VII. CONCLUSION

Security-oriented program transformations are a powertool for securing existing software systems. They capturethe expertise of security patterns in a methodical, structuredform that makes them easier to apply to existing software.We have described the process of deriving security-orientedprogram transformations to show that they are based onproven solutions, rather than experimental work. They canbe used to remove the most pressing security vulnerabilitiesfrom the code, while transforming its underlying architectureto better prepare it for future threats.

REFERENCES[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,” inObject-Oriented Programming, Proceedings of the 8th EuropeanConference 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 SystemsEngineering. John Wiley and Sons, December 2005.

[8] C. Steel, R. Nagappan, and R. Lai, Core Security Patterns : BestPractices and Strategies for J2EE(TM), Web Services, and IdentityManagement. 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 ScientificPublishing Company, 1993, pp. 1–39.

[10] M. Hafiz, P. Adamczyk, and R. Johnson, “Systematically eradicatingdata injection attacks using security-oriented program transforma-tions,” in Proceedings of the International Symposium on EngineeringSecure Software and Systems (ESSoS-09), Feb 2009.

[11] J. Yoder and J. Barcalow, “Architectural patterns for enabling appli-cation security.” In Proceedings of the 4th Conference on PatternsLanguage of Programming (PLoP’97)., 1997.

[12] M. Schumacher and U. Roedig, “Security engineering with patterns.”In Proceedings of the 8th Conference on Patterns Language ofProgramming (PLoP’01)., 2001.

[13] F. L. Brown Jr., J. DiVietri, G. D. Villegas, and E. B. Fernandez, “Theauthenticator pattern,” 1999.

[14] E. B. Fernandez and J. C. Sinibaldi, “More patterns for operatingsystems access control,” In Proceedings of the European Conferenceon Patterns Language of Programming (EuroPLoP’03), 2003.

[15] J. Hogg, D. Smith, F. Chong, D. Taylor, L. Wall, and P. Slater, WebService Security: Scenarios, Patterns, and Implementation Guidancefor Web Services Enhancements (WSE) 3.0. Microsoft Press, March2006.

[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, “Secu-rity 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: Theimpact 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 Proceed-ings of the 13th Conference on Patterns Language of Programming(PLoP’06), 2006.

[22] D. Hybertson, J. Heaney, and A. Reedy, “Conceptual aspects ofsecurity patterns,” 2002.

[23] J. Heaney, D. Hybertson, A. Reedy, S.Chapin, T. Bollinger,D. Williams, and M. Kirwan Jr., “Information assurance for enterpriseengineering,” In Proceedings of the 9th Conference on PatternsLanguage 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 SecurityThreat Report. Trends for 2008.”

[31] J. Viega and G. McGraw, Building Secure Software: How to AvoidSecurity 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 TechnicalConference, 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: Spec-ification For Secure C Library Functions, 2004.

[36] A. Baratloo, N. Singh, and T. Tsai, “Transparent run-time defenseagainst stack-smashing attacks,” in 2000 USENIX Annual TechnicalConference: 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 over-flow vulnerability,” http://www.securityfocus.com/bid/23013, 2007.

[40] B. Spitznagel and D. Garlan, “A compositional approach for con-structing connectors,” in WICSA ’01: Proceedings of the WorkingIEEE/IFIP Conference on Software Architecture. Washington, DC,USA: IEEE Computer Society, 2001, p. 148.

[41] H. Fahmy and R. C. Holt, “Software architecture transformations,” inProceedings of the International Conference on Software Maintenance(ICSM’00), ser. ICSM ’00. Washington, DC, USA: IEEE ComputerSociety, 2000, pp. 88–.

[42] J. Ryoo, P. Laplante, and R. Kazman, “A methodology for miningsecurity tactics from security patterns,” Hawaii International Confer-ence on System Sciences, 2010.

[43] M. Tatsubori, T. Sasaki, S. Chiba, and K. Itano, “A bytecode translatorfor distributed execution of “legacy” Java software,” in ECOOP ’01:Proceedings of the 15th European Conference on Object-OrientedProgramming. London, UK: Springer-Verlag, 2001, pp. 236–255.

[44] E. Tilevich and Y. Smaragdakis, “J-orchestra: Automatic Java ap-plication partitioning,” in ECOOP ’02: Proceedings of the 16thEuropean Conference on Object-Oriented Programming. London,UK: Springer-Verlag, 2002, pp. 178–204.