Literature Reviews

Agile_Software_Architecture_Aligning_Agile_Process..._----_Part_3_Agile_Architecting_in_Specific_Domains1.pdf

Home >Business & Finance homework help >Operations Management homework help >Literature Reviews

PART

Agile Architecting in Specific Domains

Babar, M. A., Brown, A. W., & Mistrik, I. (Eds.). (2013). Agile software architecture : Aligning agile processes and software architectures. ProQuest Ebook Central <a onclick=window.open('http://ebookcentral.proquest.com','_blank') href='http://ebookcentral.proquest.com' target='_blank' style='cursor: pointer;'>http://ebookcentral.proquest.com</a> Created from harrisburg-ebooks on 2020-11-24 14:01:36.

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

This page intentionally left blank

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

CHAPTER

Architecture-Centric Testing for Security: An Agile Perspective

10 Sarah Al-Azzani, Ahmad Al-Natour, and Rami Bahsoon

University of Birmingham, Birmingham, UK

CHAPTER CONTENTS

10.1 Introduction ................................................................................................ 245

10.2 Research Motivation .................................................................................... 246

10.3 Overview of Limitations in Current Post-Implementation Methods ................... 248

10.3.1 Functional Testing of Security Apparatuses ................................ 248

10.3.2 Penetration Testing .................................................................. 248

10.3.3 Threat Modeling ...................................................................... 249

10.3.4 Discussion .............................................................................. 250

10.4 Introducing Implied Scenarios ...................................................................... 251

10.4.1 Detecting Implied Scenarios ..................................................... 251

10.5 Approach .................................................................................................... 253

10.5.1 Stage 1: Implied Scenario Detection ......................................... 253

10.5.2 Stage 2: Review of Detected Implied Scenarios .......................... 253

10.5.3 Stage 3: Performing Live Security Testing .................................. 254

10.6 The Agility of the Approach .......................................................................... 254

10.7 Identity Management Case Study .................................................................. 255

10.7.1 Case Study Background ............................................................ 256

10.7.2 Approach and Results .............................................................. 256

10.8 Further Discussion ....................................................................................... 260

10.9 Agile Development, Architecture, and Security Testing .................................. 263

10.10 Related Work .............................................................................................. 264

10.11 Conclusion .................................................................................................. 265

10.1 INTRODUCTION The use of software system architecture in security testing can play a vital role in

developing secure systems [1]. Its abstraction unnecessarily hides details about

the implementation, allowing testers to focus their attention on design choices to

reveal design vulnerabilities. As for compositional security, executable architectures

allows developers to exercise the integration of system components before they are

245

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

built to iteratively refine ambiguous requirements, search for hidden behavior caused

by composing functional requirements, and generate test cases at early stages. Unfor-

tunately, the importance of architecture-level testing for security to defend against

design vulnerabilities that are believed to be the hardest type to find and correct

and are the most critical to address has been recognized only recently [2]. On the same

level, there is an increasing interest in recognizing the role of architecture in agile

development [3,4] and the possibilities of merging both approaches to achieve adap-

tation and anticipation of requirements without losing the speed of delivery.

In this chapter, we discuss the importance of architecture in agile development sys-

tems and present the application of incremental architecture-level testing for securing

systems developed using agile principles [5]. This approach uses the concept of

implied scenarios [6] that arise from the composition of requirement scenarios to

search for hidden vulnerabilities in the system. We show how the architecture can

be test-driven, incremental, and adaptive to new and incomplete requirements. We

stand by the argument that the architecture can be used to allow for co-processing

of design and testing and that it does not require detailed design but merely relies

on the functionality. Drawing on a nontrivial case study of identity management sys-

tems, we demonstrate how the integration of architecture and agile processes enables

software developers to focus on security as a nonfunctional requirement while strongly

calling for the participation of stakeholders to verify the correctness of requirements.

In the following sections, we discuss the motivation of the work by briefly

reviewing existing security testing methods, their drawbacks, and the need for

design-specific testing methods. We introduce the concept of the implied scenario

and its role in our approach. We then discuss the agility of the approach and its appli-

cation in a case study. Finally, we summarize the chapter by recalling the coexistence

of architecture and agile development.

10.2 RESEARCH MOTIVATION Security testing is fundamentally different from traditional testing because it empha-

sizes what an application should not do rather than what it should do. Therefore we

distinguish between positive requirements, such as disabling user accounts after

three unsuccessful login attempts, and negative requirements, such as the system pre-

vents unauthorized users from accessing system resources [7]. Unlike functional

testing, security testing focuses more on negative behavior (i.e., any undesirable

behavior that affects the security of the system, such as breaching confidentiality

of data). To apply the standard testing approach to negative requirements, one would

need to create every possible set of negative conditions that tests the requirement,

which is infeasible because one cannot reliably enumerate all the possible ways in

which a negative requirement can be tested. It is also challenging because it is

not always possible to map a requirement to a specific software artifact when the

requirement is not implemented in a specific place. Since negative requirement

testing creates a challenge for traditional testing, one needs to explore new testing

246 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

methodologies that highlight the presence of negative behavior and how it manifests

in the system to guard against its occurrence.

The challenge in achieving compositional security is that security is a global

property, yet many big systems are built using smaller components; thus, most vul-

nerabilities arise from unexpected interactions between different system components

[8]. When components are put together, predicting the consequences of their com-

position is difficult [9]. These compositional consequences are referred to as implied

scenarios [10]; they occur when different functionalities are composed together.

Implied scenarios can model positive consequences or a design vulnerability that

combines several legitimate behaviors to produce emergent abusive behavior.

In general, a vulnerability is a weakness in the security system that might be exploited

to cause loss or harm [11]. Often, vulnerabilities are characterized by the result of

their exploitation with respect to security properties [12], such as breach of confiden-

tiality, loss of availability, and data tempering. Design vulnerabilities are a subtype

of vulnerabilities that are associated with design defects causing security violations;

avoiding design-level vulnerabilities is among the most important challenges faced today by software developers [13]. Their fundamental importance lies in the fact that

even the most secure implementation cannot defend against defective design. In a

recent case study, a design vulnerability allowed ciphered text to be accessible to

the user to provide a sense of data security. This was identified as a major design

vulnerability because it allowed the user to cryptanalyze the ciphered text to identify

the cryptographic key used during encryption. These design vulnerabilities cannot be

easily identified using implementation-level testing methods; they require a design-

specific testing methodology to be detected. Thus, the role of architecture manifests

itself such that as requirements are elicited, one can execute their composition to pre-

dict the consequences of the composition and search for incompatibilities between

requirements. We define architecture as “the selection of the structural elements and

their interfaces by which the system is composed together with their behavior as

specified in the collaboration among those elements, and the composition of these

elements into progressively larger subsystems” [14]. And since agile systems a are

built incrementally, applying iterative testing based on these requirements can speed

up deliveries by addressing compositional faults before the system is built. These

requirements can be documented in the agile development lifecycle to enhance

communication between team members and to verify the requirements with stake-

holders [3].

In this chapter, we try to answer the following questions:

• Why can’t current testing methodologies fulfill the role of security testing?

• Can we combine architecture with agile development such that both support each

other to reduce conflicts?

• How can implied scenarios be aligned with agile practices to architect secure

software systems?

a We refer to systems that are built using an agile methodology as “agile systems.”

24710.2 Research Motivation

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

10.3 OVERVIEW OF LIMITATIONS IN CURRENT POST-IMPLEMENTATION METHODS The overall goal of security testing is to reduce vulnerabilities within a software

system [15]. A vulnerability allows an attacker to violate the integrity of the system.

When an attack is successful, the security of a system is said to be compromised.

In past years, there was much focus on implementation vulnerabilities, such as

buffer-overflows, invalid inputs, and general code-level testing, while very little

attention was paid to design vulnerabilities [9]. We summarize the current state of

security testing to motivate the need for further research to address its limitations.

Current security testing approaches can be summarized under three main headings.

10.3.1 Functional testing of security apparatuses The most basic premise behind traditional functional testing is that it is meant to

validate that the software fulfills its requirements and it functions as intended. Func-

tional security testing tests the security mechanisms implemented in the system (such

as authorization check-points) to verify that it behaves as expected. This is largely

based on security software requirements. For example, testing for a requirement that

states “a login page must only verify correct passwords” may be tested with an incor-

rect password to increase confidence that the authorization mechanism behaves as

expected; however, this testing does not guarantee that an attacker cannot brute force

the system and succeed at logging in. Verifying the correct behavior of the system

does not guarantee the absence of undocumented behaviors; it only verifies that the

system behaves according to the specification.

Requirements-based testing is an example of functional testing [16], where test

cases are associated with requirements to ensure that all requirements are covered.

In security testing, the requirements are associated with the security properties of the

system, such as confidentiality and integrity of data. Functional testing is also done

via specification-based testing [17,18] where test cases are derived automatically

from specifications, such as interfaces. There is also code-based testing [19] that

aims to uncover code-based vulnerabilities, such as buffer-overflows.

A general problem associated with functional testing is that it addresses what the

program should do; in other words, it does not aim to investigate what the application

may still do beyond the requirements or specifications. In security testing, it is impor-

tant to test for situations that are not covered in the specifications. We believe that

testing functionality is significantly different from testing for security. This is

because security, unlike functionality, is not an externally observable property,

and hence, one cannot easily predict its results or consequences.

10.3.2 Penetration testing Penetration testing takes the form of black-box testing of the system using a prede-

fined set of test cases that represent known exploits. It is performed using either

248 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

existing tools [20,21] or by hiring security experts that try to attack the system and

exploit any potential weaknesses in the system. Although this approach is attractive,

its main problem with respect to agile development is that it is not design-specific

testing; testers run the same set of test cases on different systems and rely on the fact

that developers often make similar mistakes and repeat them. In addition, penetration

testing—whether done by hiring a red-team or by using vulnerability-scanning

tools—addresses known attacks, but determined attackers often look for novel ways

of attacking a system. The system’s response to such attacks is observed and any

inappropriate behavior is noted. This process requires knowledge of both the desired

behavior and certain implementation details that are the source of vulnerabilities

[22]. Although redesigning a feature in agile development might not be expensive

to perform, patching a system is cheaper and is likely to be considered before rede-

sign. This step attempts to hide the symptoms of the problem as opposed to fixing it,

which may bring many issues into the system such as writing a vulnerable patch or

discovering new symptoms of the problem.

Security tools used in penetration testing, such ISS Scanner [23] and Cybercop

[24], are generally limited in scope. They mainly address network security attacks,

and are not flexible enough to allow testers to write custom attacks. Another problem

with existing tools is that they can only be used after the system is built. In addition,

most tools address IP networks; thus, a company wishing to test a different type of

networks is required to purchase different tools as required. Although these “bad-

ness-ometers” [25] are useful in displaying the negative state of the system, espe-

cially when the system configuration is well understood, they are not useful in

nonstandard applications, and hence should not be the only way of testing an appli-

cation. Other forms of security tools are static analysis tools that address code

vulnerabilities, such as buffer-overflow. Both are very limited in scope since

dynamic testing is also important, and both have high false-positive error rates.

10.3.3 Threat modeling Threat modeling [26–29] is a methodical review of a system design or architecture to

discover and correct design-level security problems. The review process determines

an adversary’s most likely courses of action in order to develop appropriate

responses. It requires a clear understanding of the assets to be protected, the threat’s

objectives, and any factors in the environment that could influence the threat’s capa-

bility or decisions. Such information might not be present during the initial design of

the agile system. This process results in a threat model that describes the potential

attacks on the system to be used to understand how attacks can manifest themselves,

and to evaluate critical decisions that will affect the security posture of the system

[28]. Its difficulty lies in the fact that a change made to the design requires reanalysis

of the system’s security status. Thus, in development cycles where requirements

might not be fully stated initially, constant changes might leave the models redun-

dant. Threat modeling addresses designing a secure system—not quite for the testing

phase, although the list of potential vulnerabilities may still be used as test cases.

24910.3 Overview of Limitations in Current Post-Implementation Methods

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

10.3.4 Discussion To summarize the common problems with respect to agile development is agile

development advocates testing first with a focus on implementation. Such tests

are likely to only reveal implementation vulnerabilities, and overlook design vulner-

abilities. Thus, one needs a testing methodology that tests the architecture design

while adapting to changes in the requirements iteratively. In addition, testing for

security cannot be fully automated; such attempts have failed, except in a few cases

[30]. One cannot replace human expertise, because hacking is a creative process, and

creativity cannot be easily automated. Moreover, each application has its own

design, and each design has its own weaknesses and needs to be tested individually,

while current methods use predetermined vulnerability databases to discover known

vulnerabilities in the system. However, security testing is motivated by addressing

undocumented assumptions and areas of particular complexity to determine how

software can be compromised [31]. Existing techniques fail to address implicit

assumptions, mainly because testers rely on the system specifications and code

[15]. Developers build a certain mental view of the software, which is limited

because the software is too complex for a human to carry a complete, detailed mental

picture of it. It is then the tester’s responsibility to violate these assumptions, and

thereby try to uncover vulnerabilities. Security testers must consider actions that are

outside the range of normal activity and might not even be regarded as legitimate tests

under other circumstances. Furthermore, all existing approaches rely on the tester’s

expertise to craft security test cases. This is often problematic because testers are

required to think like attackers, and because security test cases don’t often cause direct

security exploits, which presents an observability problem. Important test cases might

be missed because the application appeared to behave as it should, with disregard to the

additional behaviors that appears from the composition of the correct behavior.

Achieving security requires a tester to test like a detective, following clues to

insecure behavior and then exploring potential vulnerabilities [32]. This is because

attackers intentionally probe unspecified behaviors in the system. They attempt to

make the application behave in an unanticipated manner, and then determine the

attacks associated with that behavior. It is important to observe that detecting inse-

cure behavior will speed up the process of detecting vulnerabilities in a systematic

fashion. The remaining question to be addressed is, “How do we determine insecure

behavior in the system, while still maintaining observability of the problems asso-

ciated with the behavior, and also target implicit assumptions related to the design

of the system?” In this chapter, we try to move toward this goal using architecture-

level testing. We define vulnerability testing in our context as testing the system for

harmful additional behavior not directly specified in the system model.

The inherent characteristics of agile software development serve testing for secu-

rity well in that agility promotes flexibility through its support of decomposition and

incremental requirements. This is believed to assist testing for security in two ways:

1. It allows security testers to focus on emergent compositional behavior; it is crit- ical to gather understanding of all possible behaviors that can be triggered by

attackers.

250 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

2. Testing partial design supports focusing on more problematic areas in the code, such as the meeting points of areas with high and low security status. Areas of

high security often require higher privileges, where an authorization point or

other security feature might be installed; a vulnerability might occur if confiden-

tial information flows into nonsecured areas. Thus, the process eases the detec-

tion of vulnerabilities through continuous inspection of partially-related code to

reveal potential threats in critical areas.

10.4 INTRODUCING IMPLIED SCENARIOS Since security testers are required to consider actions that are outside the range of

normal activity and specification, we discuss our vision of how testers can use

existing methods to look beyond the specifications. In this section, we introduce

the concept of implied scenarios and their role in detecting compositional security

flaws.

Scenarios define an ordered sequence of events; in software architecture, scenar-

ios have been employed in modeling architectural properties [33,34] and in identi-

fying component interactions [35]. Each scenario models a partial behavior between

components, and thus, the composition of all scenarios is likely to exhibit more

behaviors than described by the specified scenarios. These undocumented behaviors,

known as “implied scenarios,” may arise as a result of components having only local

views of the execution [10]. An implied scenario may be an acceptable scenario that

has been overlooked, indicating incomplete specifications. Alternatively, implied

scenarios may represent an unacceptable behavior that may present attackers with

the opportunity for a potential exploit. The notion of implied scenarios was first

introduced in [10] for a restricted scenario language. The work is limited to a set

of message sequence charts (MSCs) that specify a finite set of system behaviors. This

work has been extended in Ref. [36] to provide a more expressive scenario language

that allows for an infinite number of system behaviors. But then, how are implied

scenarios detected?

10.4.1 Detecting implied scenarios The extension provided in Ref. [36] introduced an algorithm that analyzes scenarios

modeled on MSC specifications. These scenarios consist of message events sent and

received between components, which are linked together according to a directed

graph (high-level MSC (hMSC)) that defines possible continuations/loops between

scenarios. With these two inputs, the algorithm performs the following steps:

1. Breaks down the continuation/loops of scenarios into several individual label transition systems (LTSs); one component model is synthesized at a time, repre-

senting its behavior across all scenarios. This is accomplished by (a) collecting

the component behavior in all MSCs, and (b) linking all its behavior according to

the hMSC.

25110.4 Introducing Implied Scenarios

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

2. Uses the collection of component LTS models, to compose an architecture LTS model in parallel by (a) mapping nodes to behavior and to their adjacent nodes,

and (b) then connecting nodes according to the hMSC. This architecture model

takes into account the behavior described by the MSC scenarios (thus preserving

the components structures and interfaces) and the global behavior described by

the hMSC. The joint behavior is the result of all LTSs executing asynchronously

while synchronizing on all shared messages. Thus, any of the LTSs can perform a

transition independently of the other LTSs, as long as the transition label is not

shared with the other LTSs [36]. Because non-shared transitions can be performed

independently across different LTSs, the notion of the architecture is weak

such that it allows for additional unspecified behaviors to emerge that are valid

paths in the hMSC along with exhibiting all traces specified by the MSCs.

3. Builds a new trace model that captures exactly the set of traces defined by the MSC semantics to compare how close the architecture model is to the global

behavior required. Then, any trace that is not specified in the trace model would

correspond to an implied scenario. This trace model is built using a coordinator

component that is responsible for allowing/disallowing components to move

from one MSC to another. This way, components can be guaranteed not to follow

different sequences of MSCs.

4. Compares whether the architecture model exhibits more traces than the trace model, given the traces of both models. This is done by (a) defining the trace

model as a safe property that accepts traces that behave correctly according to

the MSCs and hMSC specifications, and (b) checking whether the architecture

violates the property. Violations are then reported as implied scenario MSCs.

Impliedscenariosarisebecausethescenario-basedmodelingofthesystemdescribes

the desired global behavior, whereas in reality each component in concurrent state

models acts locally based on local information. These counter-example traces may cor-

respond directly to attack scenarios, where a security property is violated and which can

be discovered using automated verification techniques to identify scenarios where

security-related properties are violated. In contrast to previous approaches that mainly

address well-known vulnerabilities, our approach benefits from existing model-based

techniques to automatically seek out and identify vulnerabilities in the design itself.

For formal definition of implied scenarios, please see Ref. [36].

We introduced the application of implied scenario detection to determine

unspecified behavior in the architecture because implied scenarios can address the

following issues:

1. Relying on the architecture of the system allows us to address implicit assumptions made by designers regarding the behavior of system components. In the real

world, a designer might explicitly specify that an application performs scenarios

X, Y, and Z. As these scenarios are composed together, a fourth scenario,

W, might arise. Such unspecified scenarios, namely W, might result in a security

failure if exploited by an attacker. Thus, it is important to discover all possible

behaviors of the system and decide whether the behavior is legitimate or not.

252 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

2. Existing tools for detecting implied scenarios allow us to observe the side effects of the implied scenario on the system, and determine how these scenarios can be trig-

gered by attackers (vulnerabilities), and more importantly how the execution of

these scenarios can affect the security of the system before building the system.

3. The detected implied scenarios can then be used as test cases to aid security testers in determining important test cases. Since implied scenarios allow us to explore

unspecified behaviors based on the assumptions made in the system architecture,

we believe such application in security testing will improve the process of detecting

threats and violations of security assumptions within the architecture.

10.5 APPROACH It is essential to acquire full knowledge of possible behaviors of a system to ensure

that the system behaves as securely as required, and that any additional behaviors do

not violate the desired global security behavior. Briefly, our notion of architecture

consists of the following:

• The component structure: which consists of a list of all components that appear in the modeled scenarios and their composed behavior

• The component interface: where, given a component c of some scenario, the interface of c is determined by the set of messages that are sent and received

by this component

Our proposal for using implied scenarios consists of three main stages.

10.5.1 Stage 1: implied scenario detection A prerequisite for detecting implied scenarios is modeling the high-level design of the

system in MSC specification language. These scenarios reflect the high-level desired

functionality/requirements. Once the requirement scenarios are determined, they are

fed into the Labelled Transition System Analyser - Message Sequence Chart

(LTSA-MSC) tool with a roadmap for continuation (hMSC). When the scenarios

are composed together to create the architecture model, we start collecting all detected

implied scenarios without regard to which of these scenarios are security threats. By

using this information, which is generated based on the system design, we provide

assurance on the security status of the system itself and the design choices, rather than

the security mechanisms implemented. At this stage, new requirements can be added

and removed, and only the hMSC needs to be changed; thus, adding and removing

requirements is a straight-forward task. The system then builds incrementally as

new requirements are added. In addition, models of new requirements and detected

implied scenarios can be used to verify behavior with the stakeholders.

10.5.2 Stage 2: review of detected implied scenarios The focus is on investigating the security breaches of the detected implied scenarios

against all categories of attacks. This is because an implied scenario may fall into

25310.5 Approach

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

several categories of attacks, and hence, may be exploited in different ways. We do

not impose restrictions on which classification scheme is used; however, we base our

classification scheme on Howard and Longstaff’s published scheme [37]. The aim of

their taxonomy is to define a common language for computer security incidents. This

taxonomy is also beneficial because it classifies a range of types of people who may

launch an attack or invoke a particular malicious behavior. It should be noted that

the purpose of categorizing vulnerabilities is to provide a checklist-based approach

whereby the tester can have reasonable confidence that all potential attack methods/

results have been considered. This in turn provides confidence in the completeness of

the vulnerability analysis process. It also helps us identify the types of attacks detect-

able using implied scenarios, and which architectures are more prone to certain

attacks. Ultimately, the result of the review is to ensure that all detected behaviors

are studied for any potential malicious use. At this stage, detected vulnerabilities

can be communicated across testers and developers in a readable scenario form as

generated by the tool in step 1.

Human involvement is needed primarily to evaluate the security of the detected

implied behaviors and to create test cases to exercise the system. Although it may be

possible to define security properties to fully automate the approach, we believe that

such a step is likely to neglect important implied scenarios that do not violate the

defined security properties.

10.5.3 Stage 3: performing live security testing Any malicious behaviors found in the review process are then used as test cases to

exercise the system’s resistance to these attacks. Because implied scenarios are in the

form of scenarios, performing a security test is relatively straight forward, and is no

different practically from common functional testing. Some calibration might be

needed to perform some of the tests. For example, in order to test whether a race

condition can take place on the system, we might need to perform an extra wait oper-

ation on one of components to allow an event to take place in a certain order; this

does not affect how the system behaves/resists the attack, but is required because race

conditions happen in extremely short time intervals. Testing can begin as soon as

vulnerable implied scenarios are detected, and as the architecture is refined, more

tested cases can be created.

10.6 THE AGILITY OF THE APPROACH For an approach to be consistent with agile principles, it must meet certain criteria to

be integrated in the agile development system. Contrary to what some believe,

requirements do not need to be gathered all up front in one phase; our approach

responds to changes by:

1. Supporting incremental elaboration of requirements by automatically searching for potential requirements; this supports customer collaboration to verify the

validity of detected behavior, as well as prediction of behavior to avoid costly

correction of integration problems.

254 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

2. Reconstruction of architecture as new information becomes available to address requirement ambiguities, and to allow stakeholders to periodically see the

progress and make adjustments to the requirements as needed.

With respect to testing, our approach supports test-driven development where the

focus is on reusing and testing the integration of components built iteratively and

ensuring that when components are composed, a correct overall behavior can be

maintained. Figure 10.1 illustrates how the iterative process of our approach maps

to Scrum to produce a working increment of the developed software. The process

starts by first collecting related requirements to be implemented, then prioritizing

these requirements, then composing them incrementally while adding or removing

requirements as the system evolves to produce a working increment of the software.

Test cases can be derived from requirements regardless of the programming lan-

guage or technology utilized, which allows it to be used to test existing systems.

In addition, relying on requirement functionality and behavior helps in achieving

tractability between the code and the architecture, as well as ensuring consistent

understanding between team members.

Finally, the type of documentation required is lightweight, and is essential to

enumerate the requirements in scaled projects.

10.7 IDENTITY MANAGEMENT CASE STUDY In this section, we look at the practical application of implied-scenario-detection

algorithms on two identity-management models designed by a project funded by

Vodafone. The evaluation of the models was conducted as part of masters projects

in security, involving two students over a period of 2 months. During the 2 months,

the students were briefed for 1 h about the use of the LTSA-MSC tool used to detect

FIGURE 10.1

Mapping between the implied scenario detection approach and Scrum.

25510.7 Identity Management Case Study

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 10.1

implied scenarios, and how to create MSCs; they were not required to understand what

implied scenarios are, or how they are detected. The students modeled the system in

MSC using the LTSA-MSC tools and all generated implied scenarios were recorded

and evaluated. The use of sequence charts is believed to be one of the most widely used

models in the software industry [38], thus using such models does not introduce an

overhead on the industry to adopt the approach. Another prerequisite for the approach

is basic understanding about security properties, and how they are violated.

10.7.1 Case study background The case study aimed at evaluating two identity management models (device-based

and service-based) [39] implemented in an online bargain shop (OBS) for security

vulnerabilities. Retailers and wholesalers can subscribe to the OBS system in order

to advertise their online products, while buyers can sign up to OBS to browse offer-

ings and search for and buy products. The architecture uses temporary sessions

assigned for every user. The user will access the portal by providing a username

and password, which in turn will provide access to a third party web service (e.g.,

Amazon). Once the user enters the credentials, the portal will forward the request

for authentication to the session generator, which in turn will determine whether

the username and password are valid by comparing them with the values stored in

the user credential database. The desired communication is illustrated in Figure 10.2.

Device-based identity utilizes security credentials on the device to authenticate

with services and uses the identity provider (IdP) to distribute the public key for the

identity and maintains a list of attributes. It introduces a security token, which is sent

to the users’ device for authentication. Security credentials are stored in the device

and are used to identify the service and authenticate the device requesting the service;

thus, “each device maintains its own credentials for the user identity” [39]. The

desired behavior is illustrated in Figure 10.3.

10.7.2 Approach and results Each model contained four legitimate scenarios generated from the code with its

hMSC. We have applied our approach to both models and compared our results with

respect to the following security properties [12]: confidentiality, integrity, authenti-

cation, and availability. As new behaviors were detected using the LTSA-MSC tool,

the developers were involved to decide whether the behavior was positive or not (i.e.,

“Is it a design defect with potential security implications, or is it an undesirable infer-

ence?”). In cases where additional behaviors were positive, they were added to the

model supporting continuous refinement and addition of new requirements. Further

investigation was performed incrementally and iteratively to ensure that additional

behaviors do not cause integration errors.

The device-based model proved to be more vulnerable to security vulnerability

exploitation, since it had a total of three negative implied scenarios and violated the

confidentiality, integrity, and availability requirements. On the other hand, the

256 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

User Portal

reqAuthentication

authenticate

returnSession

authenticationSuccessful

createSession

authenSession

authenSuccessful

redirect

forwardReq

reqSessionlnfo

sendSessionlnfo

verifySessionlnfo

veriSuccessful

reqUserPolicy

sendUserPolicyForVerification

reqUserCredentials

sendUserCredentials

allowAccess

SessionGe... UserCrede... SessionSt... WebService Policyand... PolicyRep...

FIGURE 10.2

Service-based identity management model for an online shopping system.

2 5 7

1 0 .7

Id e n tity

M a n a g e m e n t C a se

S tu d y

B a b

a r, M

. A ., B

ro w

n , A

. W ., &

M istrik, I. (E

d s.). (2

0 1 3 ). A

g ile

so ftw

a re

a rch

ite ctu

re : A

lig n in

g a

g ile

p ro

ce sse

s a n d so

ftw a re

a rch

ite ctu

re s. P

ro Q

u e st E

b o o k C

e n tra

l <

a o

n click=

w in

d o w

.o p e n ('h

ttp ://e

b o o kce

n tra

l.p ro

q u e st.co

m ','_

b la

n k') h

re f=

'h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m ' ta

rg e t=

'_ b la

n k' style

= 'cu

rso r: p

o in

te r;'>

h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m <

/a >

C re

a te

d fro

m h

a rrisb

u rg

-e b o o ks o

n 2

0 2 0 -1

1 -2

4 1

4 :0

1 :3

6 .

Figure 10.2

User Device OBS Idp DataRepos... TrustRoot

use

access

reqAuthentication

accessWithToken

respond

provideToken

storelDofDevice

verifyRequest

verificationSuccessful

reqldentity

FIGURE 10.3

Device-based identity management model for a shopping system.

2 5 8

C H A P T E R 1 0

A g ile

A rc h ite c tu re

fo r S e c u rity

T e stin

B a b

a r, M

. A ., B

ro w

n , A

. W ., &

M istrik, I. (E

d s.). (2

0 1 3 ). A

g ile

so ftw

a re

a rch

ite ctu

re : A

lig n in

g a

g ile

p ro

ce sse

s a n d so

ftw a re

a rch

ite ctu

re s. P

ro Q

u e st E

b o o k C

e n tra

l <

a o

n click=

w in

d o w

.o p e n ('h

ttp ://e

b o o kce

n tra

l.p ro

q u e st.co

m ','_

b la

n k') h

re f=

'h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m ' ta

rg e t=

'_ b la

n k' style

= 'cu

rso r: p

o in

te r;'>

h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m <

/a >

C re

a te

d fro

m h

a rrisb

u rg

-e b o o ks o

n 2

0 2 0 -1

1 -2

4 1

4 :0

1 :3

6 .

Figure 10.3

service-based model shows only one negative implied scenario which violated the

authentication requirement as presented in Table 10.1.

The implied scenarios found are as follows:

• Implied scenarios 1 and 2: Ambiguous behavior is exhibited when multiple login attempts are carried out instantly. This happens in both models. It indicates pos-

sibilities of brute force attack on the server until a successful login attempt is

made. The architecture does not guard against flooded requests of login attempts.

This could disrupt the availability of the service leading to a denial of service

attack, since no firewall is implemented to block such behavior. This can also

raise an alarm for how the system disposes credentials when the server fails to

respond. A common improper handling of exceptions can leave the credentials

floating in the memory.

• Implied scenario 3: Another possibility is masquerading attack, in which a user attempts to login, and once a successful confirmation is returned, the confirma-

tion is intercepted by an attacker that attempts to replay the confirmation to gain

access to the user’s account. This is modeled in Figure 10.3, where the first part of

the diagram models the legitimate behavior and the second part models the

attempt to access the server using replayed confirmation. Since the models do

not present encryption mechanisms, modification of the credentials may occur,

thus violating the integrity requirement of the model.

• Implied scenario 4: An application with an improper threading mechanism in concurrent applications may face problematic interleavings that return wrong

sessions to the wrong person, granting the user more privileges than they own.

• Implied scenarios 5 and 6: These model positive behaviors; one models a valid request of service after authentication is successful, and one models a login

attempt after authentication is successful (allowing for concurrent access from

different features, and re-verification of authorization).

The amount of effort required to accomplish the study involved learning to use

the tool and modeling the system, which the students reported no difficulty in learn-

ing; by the end of the 1 hour introduction to the tool, the students were able to use it

on their own. The process of modeling the actual identity management models was

Table 10.1 Comparison of Implied Scenario Detection in Service- and Device-Based Models

Total Implied Scenarios

Negative Implied Scenarios

Confidentiality Violation

Integrity Violation

Availability Violation

Authen- tication Violation

Device- based

4 3 Yes Yes Yes No

Service- based

2 1 No No No Yes

25910.7 Identity Management Case Study

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

also straightforward because the developer of the models was present to confirm that

the students’ models were correct before the evaluation took place. Finally, the num-

ber of acceptable implied scenarios were minimal (�2), so the effort required to eval- uate their potential security implication paid off in comparison with the negative

implied scenarios detected (�4) and acknowledged by the developer. It is also worth mentioning that implied scenarios are difficult to detect manually, and thus the time

required to detect them is significantly reduced using automated tools.

Now that we have an overview of potential design vulnerabilities, one can either

refine the code to reflect the architecture to make it more secure and to prevent prob-

lems from occurring (where possible), or one can create concrete test cases that test

the possible consequences of the execution, or increase/decrease the number of

requirements and reevaluate the outcome. This can take place concurrently with

the implementation process. We have looked into refining the service-based model,

for which we have proposed a hybrid model with two-factor authentication. In addi-

tion to securing the model, it aims to decentralize the task of identity management in

general and to distribute the burden of identity management by using both the trust

root (for device identity authentication), and the IdP (for user identity authentica-

tion). Moreover, the use of one-time password (OTP) will provide additional authen-

tication, and its use as an authentication configuration enables our model to support

single sign-on, which in itself reduces phishing attacks and password fatigue. As

Figure 10.5 shows, the IdP will verify the identity of the user and send an acknowl-

edgment back to the session generator. Once the OBS receives the redirect from the

portal, it will forward the request to access the service to the policy and access control

module, which will request the identity of the device from the IdP. The IdP then

sends the identity to the trust root for verification, which in turn will request an

OTP from the server. The server will compute the OTP (using either time-

synchronized functions or mathematical hash functions) and will send it to the device

so the user can log in using the OTP. When the user logs in to the service, the OTP

will be verified by the server and access will be granted.

10.8 FURTHER DISCUSSION We now report on the following criteria:

• Agility of the approach: The approach proved to be flexible in responding to changes involved in the requirements. Its benefits include (1) its support for con-

tinuous evolvement, (2) its ability to improve productivity, since it reduces staff effort and time required to perform integration checks as new requirements are

added, (3) its ability to produce better quality of product, since it targets inspect- ing hidden, potentially dangerous behaviors, and (4) its support for systematic

review of the system. However, once the scenarios are detected, human judgment

is required to determine how the insecure behavior might affect the security of the

system. This guided testing helps identify vulnerable areas for testers to examine.

260 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

User

use

reqidentity

verifyRequest

verificationSuccessful

verifyRequest

verificationSuccessful

reqAuthentication

access

use

access

Device OBS Idp DataRepos... TrustRoot

FIGURE 10.4

Potential masquerading attack on the service-based identity management model.

2 6 1

1 0 .8

F u rth

e r D isc

u ssio

B a b

a r, M

. A ., B

ro w

n , A

. W ., &

M istrik, I. (E

d s.). (2

0 1 3 ). A

g ile

so ftw

a re

a rch

ite ctu

re : A

lig n in

g a

g ile

p ro

ce sse

s a n d so

ftw a re

a rch

ite ctu

re s. P

ro Q

u e st E

b o o k C

e n tra

l <

a o

n click=

w in

d o w

.o p e n ('h

ttp ://e

b o o kce

n tra

l.p ro

q u e st.co

m ','_

b la

n k') h

re f=

'h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m ' ta

rg e t=

'_ b la

n k' style

= 'cu

rso r: p

o in

te r;'>

h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m <

/a >

C re

a te

d fro

m h

a rrisb

u rg

-e b o o ks o

n 2

0 2 0 -1

1 -2

4 1

4 :0

1 :3

6 .

Figure 10.4

User

use

authenReq

authenticate

authenReply

redirect

loginUsingOTP

sendOTP

forwardReq

reqidentity

verifyDeviceIdentity

verifyOTP

reqOTP

allowAccess

returnSession

Device Portal SessionGe.. Idp OBS TrustRoot ServerPolicy & Ac...

FIGURE 10.5

A hybrid model with two-factor authentication proposed to secure the service-based model.

2 6 2

C H A P T E R 1 0

A g ile

A rc h ite c tu re

fo r S e c u rity

T e stin

B a b

a r, M

. A ., B

ro w

n , A

. W ., &

M istrik, I. (E

d s.). (2

0 1 3 ). A

g ile

so ftw

a re

a rch

ite ctu

re : A

lig n in

g a

g ile

p ro

ce sse

s a n d so

ftw a re

a rch

ite ctu

re s. P

ro Q

u e st E

b o o k C

e n tra

l <

a o

n click=

w in

d o w

.o p e n ('h

ttp ://e

b o o kce

n tra

l.p ro

q u e st.co

m ','_

b la

n k') h

re f=

'h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m ' ta

rg e t=

'_ b la

n k' style

= 'cu

rso r: p

o in

te r;'>

h ttp

://e b o o kce

n tra

l.p ro

q u e st.co

m <

/a >

C re

a te

d fro

m h

a rrisb

u rg

-e b o o ks o

n 2

0 2 0 -1

1 -2

4 1

4 :0

1 :3

6 .

Figure 10.5

We sped up this process by determining categories of attack results that might

occur if insecure behaviors are executed.

• Phases of application: Because we are working at the architectural level to address security testing, our approach can be integrated into the analysis, design,

implementation, or testing phase of the development cycle, as long as the global

and individual behaviors of components are identified. Because agile develop-

ment is test-driven, testing can begin as early as some of the requirements are

available. Our approach to security testing supports a highly iterative process;

for example, in cases of adaptation to new requirements, these requirements

can be added to the LTSA-MSC in the form of new behavioral scenarios. As these

new scenarios are added, the approach can be automatically reiterated to detect

new implied scenarios. The testers will only need to review new sets of detected

implied scenarios, which reduces the necessary time because reviews are not

repeated for implied scenarios that have already been detected.

• Generality and applicability of approach: We have specifically chosen to work on the architecture of the system because it offers an adequate level of generality.

Almost every system can be modeled in terms of components and interactions, and

every system has an architecture, whether it is modeled or not. We have also chosen

scenario-based specification because it is popular for modeling behaviors. Unified

Modelling Language (UML) 2.0 and MSC are among the most commonly used

scenario-based specifications, and many software engineers are familiar with these

modeling languages. Thus, we are not requiring additional training for testers. Fur-

thermore, the detection of implied scenarios has been applied to different types of

applications, including component-based systems [40], Java systems [41], and in

this example we have applied it successfully to an identity management system.

• Scalability: This approach supports breaking down the system into groups of requirements, either to perform detailed dynamic analysis for certain groups of

requirements (e.g., problematic areas) or for evolving the requirements for spe-

cific functionality or subsystems. Once a group of functionalities is determined,

our approach supports composing these functionalities incrementally to reach a

larger subsystem.

10.9 AGILE DEVELOPMENT, ARCHITECTURE, AND SECURITY TESTING Moving from implementation testing to architecture-level testing offers several

advantages, which we summarize as follows:

1. Identifying developer’s assumptions based on the code can be a difficult task for testers, since the assumptions are not abstracted from the code. Identifying

assumptions as discussed in Section 10.3.2 is critical for security testing.

2. Supports high-level view the system to address scalability and complexity of systems. For example, the use of code to test an object-oriented system, is

26310.9 Agile Development, Architecture, and Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

complex and tedious task [42] especially for large applications. On an average

sized system, architecture can help scale its size especially on situations where

there is a large, distributed team.

3. Abstraction allows us to omit parts that are not necessarily important for security testing. This helps focus attention on components that are more vulnerable than

others. Abstraction is also useful for capturing attack patterns in the system, with-

out the need for an in-depth description of the attack.

4. Traditional software testing techniques consider only a static view of code, which is not sufficient for testing dynamic behavior of the system [43]. Testing the

live system is very expensive. Thus, using an executable architecture is a

cost-effective approach that allows us to experiment with the behavior of the

system.

5. Applications often contain third-party components. Since it may not be viable to modify the source of such components (either because the code was shipped in

binary form or because the license agreement is prohibitive), it is not obvious

how security vulnerabilities could be detected at coding level. Our approach

relies on the interfaces of components, and the safety of their integration.

6. Applications may be written in a variety of languages. In cases of code testing, there is no easy way to abstract security-related code behind a clean Application

programming interface (API) [44]. As a consequence, security-related code will

be scattered throughout the application, increasing the difficulty of detecting

vulnerabilities.

7. Architecture-level testing facilitates better communication between testers, developers, and stakeholders, since abstracted models are easier to read and

understand than large amounts of code.

8. The test process and test case generation can be planned at an early stage of the software development life cycle, allowing coding and testing to be carried out in

parallel, which fulfills the requirement of test-driven development.

These points highlight a promising use of the architecture for agile development.

Its use does not conflict with the principles of agile development as demonstrated by

our case study; iteration can be achieved, adapting to changing requirements, con-

tinuous integration, and test-driven.

10.10 RELATED WORK The closest work to ours is that produced by Ramakrishnan and Sekar [8]. In their

work, they create a model for each system component and then compose them to

show different interactions between these components. Then they verify this com-

posite model by searching for a scenario where a formally defined security property

is violated. The major difference in our approach is that we do not model each com-

ponent independently; instead, we model all interaction scenarios between these

components. We also do not formally define security properties, and instead study

all unspecified behaviors for potentially dangerous behaviors. Defining a security

264 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

property for automation might restrict the results of the approach because automation

may lead to false positives and negatives, and thus overlook scenarios.

Another related work is that of Salas et al. [45]. In their work, they build three

models: (1) a specification model that reflects the desired behavior, (2) an implemen-

tation model that reflects low-level details of the system, with a particular focus on

security concerns, and (3) an attacker model that represents the intentions of an

attacker. The purpose of the first two models is to show nonconformance between

the specification and its implementation, and then the attacker’s model is compared

to the implementation model. The major difference between our work and theirs is

that we only use a single model that reflects the implementation model. We also do

not aim to verify the presence of previously identified threats (through other means

of threat-detection), but instead, we aim to provide the detect mechanism itself to

identify potential threats.

10.11 CONCLUSION We aim in this research to continue to push against the limitations of the state of the art

in securing our systems. We have presented the application of test-driven, architecture-

level security testing for agile development. The application is motivated to comple-

ment limitations in existing security testing techniques. We hypothesized that the

application of implied scenario detection [46] at the architecture level does not conflict

with the principles of agile development. We have demonstrated that the architecture

can be adaptive, iterative, and test-driven. We have also demonstrated that testing indi-

vidual functionalities does not help to identify compositional security violations, and

that the use of implied scenarios reveals inconsistencies in the composition of func-

tional scenarios. Using a case study, our results validated our hypothesis, and the

use of implied scenarios detected several threats that are likely to have been missed

using implementation-testing methods. We conclude that the use of architecture for

agile development is highly effective for guiding testers to evaluate security vulnera-

bilities. We have discussed the usefulness of incorporating the system architecture

along with the code. We have presented a real-world example in which our approach

detected four threats. In our future work, we intend to generate test cases and perform

live testing on a distributed system.

References [1] Shreyas D, Software Engineering and Security: Towards Architecting Secure

Software. Term paper for ICS 221-Seminar in Software Engineering, Irvine:

University of California; 2001. http://www.dsc.ufcg.edu.br/�jacques/cursos/map/ recursos/SoftwareEngineeringandSecurity.pdf

[2] McGraw G, Potter B. Software security testing. IEEE Secur Priv 2004;2(5):81–5.

[3] Falessi D, Cantone G, Sarcia’ SA, Calavaro G, Subiaco P, D’Amore C. Peaceful

coexistence: agile developer perspectives on software architecture. IEEE Softw

2010;27(2):23–5.

265References

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://www.dsc.ufcg.edu.br/&sim;jacques/cursos/map/recursos/SoftwareEngineeringandSecurity.pdf

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0010

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0015

[4] Abrahamsson P, Ali Babar M, Kruchten P. Agility and architecture: can they coexist?

IEEE Softw 2010;27(2):16–22.

[5] Ambler S. Agile modeling: effective practices for extreme programming and the unified

process. New York: Wiley; 2002.

[6] Uchitel S, Chatley R, Kramer J, Magee J. LTSA-MSC: tool support for behaviour model

elaboration using implied scenarios. In: Joint European conference on theory and prac-

tice of software (ETAPS 2003), Warsaw, Poland; 2003.

[7] Fink G, Bishop M. Property-based testing: a new approach to testing for assurance. ACM

SIGSOFT Softw Eng Notes 1997;22(4):74–80.

[8] Ramakrishnan C, Sekar R. Model-based vulnerability analysis of computer systems. In:

Second international workshop on verification, model checking, and abstract interpreta-

tion (VMCAI), Pisa, Italy; 1998.

[9] Wing J. A call to action look beyond the horizon. IEEE Secur Priv 2003;1(6):62–7.

[10] Alur R, Etessami K, Yannakakis M. Inference of message sequence charts. In: ICSE ’00:

proceedings of the 22nd international conference on software engineering. New York,

NY: ACM; 2000. p. 304–13.

[11] Pfleeger CP. Security in computing. Upper Saddle River, NJ: Prentice-Hall; 1997.

[12] Avizienis A, Randell B, Landwehr C. Basic concepts and taxonomy of dependable and

secure computing. IEEE Trans Dependable Secure Comput 2004;1(1):11–33.

[13] Rehman S, Mustafa K. Research on software design level security vulnerabilities. ACM

SIGSOFT Softw Eng Notes 2009;34(6):1–5.

[14] IBM. Rational unified process. URL: http://www-306.ibm.com/software/awdtools/rup/?

S_TACT¼105AGY59&S_CMP¼WIKI&ca¼dtl-08rupsite; 2007. [15] Michael CC, Radosevich W. Risk-based and functional security testing. Technical

report, Build security; 2005.

[16] Mogyorodi G. Requirements-based testing: an overview. In: TOOLS ’01: Proceedings of

the 39th international conference and exhibition on technology of object-oriented lan-

guages and systems (TOOLS39). Washington, DC: IEEE Computer Society; 2001.

[17] Stocks P, Carrington D. A framework for specification-based testing. IEEE Trans Softw

Eng 1996;22(11):777–93.

[18] Wimmel G,Jürjens J.Specification-basedtestgeneration for security-critical systems using

mutations. In: International conference on formal engineering methods (ICFEM); 2002.

[19] Antoniol G. Keynote paper: search based software testing for software security: breaking

code to make it safer. In: ICSTW ’09: proceedings of the IEEE international conference

on software testing, verification, and validation workshops. Washington, DC: IEEE

Computer Society; 2009.

[20] Lodderstedt T, Basin DA, Doser J. SecureUML: a UML-based modeling language for

model-driven security. In: UML ’02: proceedings of the 5th international conference

on the unified modeling language. London: Springer; 2002.

[21] Ahn G-J, Shin ME. Role-based authorization constraints specification using object con-

straint language. In: WETICE ’01: proceedings of the 10th IEEE international workshops

on enabling technologies. Washington, DC: IEEE Computer Society; 2001.

[22] Jacobson I, Booch G, Rumbaugh J. The unified software development process. Boston,

MA: Addison-Wesley Longman Publishing Co., Inc.; 1999.

[23] Internet security systems, internet scanner (ISS). Web. URL: http://www.iss.net/; 2003.

[24] Network associates, cybercop scanner. Web. URL: http://www.nss.co.uk/grouptests/va/

edition2/nai_cybercop_scanner/nai_cybercop_scanner.htm.

[25] McGraw G. Software security: building security. Boston, MA: Addison-Wesley Profes-

sional; 2006.

266 CHAPTER 10 Agile Architecture for Security Testing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0020

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0025

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0030

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0035

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0040

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0045

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0050

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0055

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0060

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0065

http://www-306.ibm.com/software/awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rupsite

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0070

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0075

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0080

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0085

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0090

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0095

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0100

http://www.iss.net/

http://www.nss.co.uk/grouptests/va/edition2/nai_cybercop_scanner/nai_cybercop_scanner.htm

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0105

[26] Whittle J, Wijesekera D, Hartong M. Executable misuse cases for modeling security con-

cerns. In: ICSE ’08: proceedings of the 30th international conference on software engi-

neering. New York, NY: ACM; 2008.

[27] Hernan S, Lambert S, Ostwald T, Shostack A. Threat modeling: uncover security design

flaws using the stride approach, MSDN Magazine 2006. http://msdn.microsoft.com/en-

us/magazine/cc163519.aspx.

[28] Swiderski F, Snyder W. Threat modeling. Redmond, WA: Microsoft Press; 2004.

[29] Schneier B. Attack Trees. Dr. Dobb’s Journal Dec 1999;24(12):21–9.

[30] Turpe S. Security testing: Turning practice into theory. In: IEEE international conference

on software testing verification and validation workshop, ICSTW ’08; 2008. p. 1–10.

[31] Howard M, LeBlanc DC. Writing secure code. Redmond, WA: Microsoft Press; 2002.

[32] Thompson HH. Why security testing is hard. IEEE Secur Priv 2003;1(4):83–6.

[33] Kazman R, Abowd G, Bass L, Clements P. Scenario-based analysis of software archi-

tecture. IEEE Softw 1996;13(6):47–55.

[34] Babar MA, Gorton I. Comparison of scenario-based software architecture evaluation

methods. In: Asia-Pacific software engineering conference; 2004. p. 600–7.

[35] OMG Unified Modeling Language™ (OMG UML), Infrastructure. Version 2.4.1, for- mal/2011-08-05, August 2011. Object Management Group. http://www.omg.org/spec/

UML/2.4.1/Infrastructure.

[36] Uchitel S, Kramer J, Magee J. Detecting implied scenarios in message sequence chart

specifications. ACM SIGSOFT Softw Eng Notes 2001;26(5):74–82.

[37] Howard JD, Longstaff TA. A Common Language for Computer Security Incidents.

Sandia National Laboratories; October 1998 [Sandia Report: SAND98-8667]. http://

infoserve.sandia.gov/sand_doc/1998/988667.pdf.

[38] Samuel P, Joseph AT. Test sequence generation from UML sequence diagrams. In: Soft-

ware engineering, artificial intelligence, networking, and parallel/distributed computing.

SNPD ’08. Ninth ACIS international conference; 2008.

[39] Staite C. Device based identity management. URL: http://www.cs.bham.ac.uk/cxs548/

papers/device-based.pdf; 2010.

[40] Rodrigues GN, Rosenblum DS, Uchitel S. Using scenarios to predict the reliability of

concurrent component-based software systems. In: FASE; 2005.

[41] de Sousa FC, Mendon N, Uchitel S, Kramer J. Detecting implied scenarios from execu-

tion traces. In: Reverse engineering, working conference; 2007.

[42] Kundu D, Samanta D. A novel approach to generate test cases from UML activity

diagrams. JOT 2009;8(3):65–83.

[43] Binder RV. Testing object-oriented systems: models, patterns, and tools. Boston, MA:

Addison-Wesley Longman Publishing Co., Inc.; 1999.

[44] Scott D, Sharp R. Abstracting application-level web security. In: WWW ’02: proceed-

ings of the 11th international conference on world wide web. New York, NY: ACM;

2002. p. 396–407.

[45] Salas PAP, Krishnan P, Ross KJ. Model-based security vulnerability testing. In:

ASWEC ’07: proceedings of the 2007 Australian software engineering conference.

Washington, DC: IEEE Computer Society; 2007. p. 284–96.

[46] Al-Azzani S, Bahsoon R. Semi-automated detection of architectural threats for security

testing. In: ESEC/FSE doctoral symposium ’09: proceedings of the doctoral symposium

for ESEC/FSE on doctoral symposium. New York, NY: ACM; 2009. p. 25–6.

267References

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0110

http://msdn.microsoft.com/en-us/magazine/cc163519.aspx

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0120

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0125

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0130

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0135

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0140

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0145

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0150

http://www.omg.org/spec/UML/2.4.1/Infrastructure

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0155

http://infoserve.sandia.gov/sand_doc/1998/988667.pdf

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0160

http://www.cs.bham.ac.uk/cxs548/papers/device-based.pdf

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0165

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0170

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0175

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0180

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0185

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0190

http://refhub.elsevier.com/B978-0-12-407772-0.00009-5/rf0195

This page intentionally left blank

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

CHAPTER

Supporting Agile Software Development and Deployment in the Cloud: A Multitenant, Multitarget Architecture

Antonio Rico*, Manuel Noguera*, José Luis Garrido*, Kawtar Benghazi*, Lawrence Chung

{

*Universidad de Granada, Granada, Spain {University of Texas at Dallas, Richardson, TX, USA

CHAPTER CONTENTS

11.1 Introduction .................................................................................................. 269

11.2 Cloud Computing ........................................................................................... 271

11.3 Multitenancy Architectures ............................................................................ 272

11.4 Agility and Multitenancy Architectures ........................................................... 274

11.5 Multitenancy Monotarget: Agility Challenges .................................................. 275

11.6 Supporting Agility: Multitenancy Multitarget ................................................... 276

11.6.1 Functional Portfolio Management ................................................278

11.6.2 Multitarget Metadata (MT2 Metadata) ..........................................278

11.6.3 Business Process Reutilization ....................................................279

11.6.4 Multitarget Security ...................................................................281

11.7 Globalgest: A Real MT2 System ...................................................................... 281

11.8 Related Work ................................................................................................ 284

11.9 Conclusions and Future Work ......................................................................... 285

11.1 INTRODUCTION Cloud computing is enabling everyone to have access to high computational capa-

bilities. Computation is served as a commodity by cloud providers [1], whereas cloud

clients (Information Technology (IT) companies) are able to access these IT

269

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

resources on demand. This new paradigm, also known as Software as a Service

(SaaS), has changed the way in which software is distributed. In SaaS, applications

are no longer purchased (unlike its predecessor, software on premises) but con-

sumed; small- and medium-sized companies afford top-end applications, paying

software vendors (SaaS providers) for the use.

In this context, another paradigm—multitenancy (MT)—has become a key tech-

nology for the success of SaaS [2–4]. In MT, clients reduce the cost of software use

by sharing expenditures, whereas software vendors maximize sales profits by reach-

ing larger markets. MT architectures (MTAs) allow multiple customers (i.e., tenants)

to be aggregated into the same application. Tenants share not only the application,

but also capital and operational expenses [5].

Agility has been widely advocated in the past few years as a development phi-

losophy that improves efficiency in software construction [6]. Most agility methods

and techniques focus on the organization of the members in software teams and the

extensive adoption of demonstrated software engineering best practices, such as code

refactoring. Agilists consider software architecture something “evil” from the past, a bad habit that only carries tons of documentation, big up-front design, and you ain’t

gonna need it (YAGNI) [7].

However, in the cloud multitenant situation, where easy scalability is key, archi-

tectures supporting agility and rapid provisioning become critical. In SaaS, MT appli-

cations demand has to be supported by architectural styles that allow rapid subscription

configuration. MTAs need to provide an “administrative framework that improves

management efficiency for administering the system” [5]. Cloud SaaS architectures

should not be considered evil but as helpful tools and assets for agile teams.

According to Liu [8], “the adoption of SaaS is growing and evolving in the enter-

prise application markets.” SaaS includes all kinds of software applications: cus-

tomer relationship management (CRM), enterprise resource planning (ERP),

content management systems (CMSs), and document management systems (DMSs),

among others. In traditional SaaS MT systems, each MT application usually deploys

a single functionality and is shared among tenants with similar functional needs. In

this regard, we could call actual MT applications monotarget because they target a single area in the spectrum of potential clients.

We previously introduced a proposal for improving MTAs, called multitenancy

multitarget (MT 2 ) [9]. This novel architecture adds new components to an underlying

MT foundation to support multiple functionalities. In this chapter, we illustrate how

MT 2 fosters deployment (since just one system is needed to support multiple

services) and aim to support agility in development by avoiding unnecessary repli-

cations; customers in turn reduce learning effort because one application is needed to

cover all services. The applicability and benefits of the proposal are illustrated

through a real MT 2 system called Globalgest [10,11], which is currently in service.

This chapter is organized as follows. First, a definition of cloud computing and

its services is provided. Second, we go deeper into MT and explain the general model

of this architectural pattern. Third, we discuss agility in SaaS MT applications

and the recent discussion to combine traditional agile software development with

270 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

architecture. Fourth, the proposal is introduced and is followed by the presentation of

a real MT 2 implementation (Globalgest). Finally, conclusions and future work are

summarized.

11.2 CLOUD COMPUTING The National Institute of Standards and Technology defines cloud computing as “a

model for enabling ubiquitous, convenient, on-demand network access to a shared

pool of configurable computing resources (e.g., networks, servers, storage, applica-

tions, and services) that can be rapidly provisioned and released with minimal

management effort or service provider interaction” [12].

In other words, cloud computing means the use of computer resources at different

levels over a cloud. A cloud is a datacenter providing computing infrastructure (hard- ware and software) and accessed over the Internet. This way, companies are able to

migrate their IT infrastructure, reducing capital and operational expenses. Depend-

ing on the organizations operating on the infrastructure, clouds can be classified into

private, community, public, or hybrid [12]. Services consumed by customers over a

cloud are called cloud services, and can be organized in three levels [4,12,13]:

– Software as a Service (SaaS): Consumption of software applications deployed in the cloud. Platform and infrastructure are transparent to users.

– Platform as a Service (PaaS): Capacity to deploy applications into the cloud. Cus- tomers do not control lower-level computing resources, such as operating systems

or network.

– Infrastructure as a Service (IaaS): Provision of storage, computing, network, and other primary computing resources.

Though this classification of cloud services seems to be agreed in literature, there is

still no common understanding on the definition of cloud computing. In Berkeley’s

definition [1,14], cloud computing is considered the sum of utility computing and SaaS, anddoesnot include private clouds. Utilitycomputing [15] refersto the use ofcomputer

resources on demand. This way, Berkeley considers IaaS a utility computing service,

whereas PaaS is halfway between cloud computing and utility computing.

In SaaS, companies are no longer owners of the applications, but subscribers to

them. According to Ref. [16], “The basic long-term vision of SaaS is centered around

separating software possession and ownership from its use.” Unlike its predecessor,

Software on Premises, applications are now installed in a cloud and accessed over the Internet; users are not owners of the software any more, but consumers of web

applications.

Previous attempts to migrate application provisioning to the cloud have failed. In

ASP (application service provider), applications were also deployed over a network

instead of being executed on local servers. However, in this model, clients would not

benefit from cost reduction since servers where private and used only by their owner

companies. SaaS, on the other hand, is focused on exploiting economies of scale by

27111.2 Cloud Computing

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

consolidating several customers onto the same operational system. Companies afford

top-quality enterprise applications, while providers maximize sales profits targeting

the market of small- and medium-sized companies. Among other reasons, ASP failed

because it did not even contemplate the possibility of serving different companies using

the same software instance [17] or the ability to provide customized applications [18].

11.3 MULTITENANCY ARCHITECTURES MT is an architectural pattern for SaaS applications that permits several customers

(tenants) to share the same instance of the software [19]. A tenant is an organizational

unit that pays for the use of the SaaS application on a regular basis (according to the

subscription contract). One tenant might consist of many end-users, therefore MT

applications might also be multi-users; we will call tenancy the set of users of one tenant that run the same customized version of the application instance. The number

of instances runningin a multitenant environment might be more than one, resulting in

a MT farm. This situation could occur not only because of performance issues (some

tenants might get greedy on computer resources), but also because of country

legislations stating the obligation to store data within country borders [20].

The multitenant model is considered an essential characteristic for cloud comput-

ing and its software delivery model [4,12]. Salesforce.com, one of the most popular

cloud providers, states [3]: “hosting models that do not offer the leverage of MT do

not belong in the same discussion as the value proposition implied by the term SaaS.”

Chong, in his article Architecture Strategies for Catching the Long Tail [2], believes three attributes are to be considered in a good SaaS application architecture: scalabil-

ity, configurability, and multitenant efficiency.

The use of metadata in multitenant applications lets tenants customize the system

within the tenancy in three different levels: database model, user interface, and busi-

ness logic. This way, MT seems to be transparent for customers giving the impres-

sion that they are running a dedicated instance of the application. Customization and

security rely on the model chosen to store data. Several authors have proposed

different approaches [5,21–23]. Though using different terminology, they all agree

that the distinction is given by the level of isolation on tenant’s data.

Basically, MTA models have two tiers: administrative and instance. The admin-

istrative tier [5] provides the functionalities responsible for rapid account manage-

ment, while the instance tier hosts the applications that tenants execute according to

subscription contracts defined at the administrative level. In Figure 11.1, the multi-

tenant master panel (MTMP) represents the administrative level to control a farm

with four application instances.

In a MT farm, the MTMP must ensure system performance is balanced and have

the capability to move or scale out tenants to (new) servers of the farm. This

component stores data in the administrative database.

Figure 11.2 details the instance level of the architecture. The lower level tiers

perform changes dictated by the business layer in both the multitenant database

272 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Application instance 2

Application instance 1

Administrative tier

Instance tier

Application instance 3

Multitenant master panel (MTMP)

Application instance 4

T3T42T41T33T32T31T23T22T21T13T12T11

Multitenant database(s)

Administrative database

FIGURE 11.1

Administrative and instance tiers in an MT environment.

L o

w e

r le v e

l tie rs

FIGURE 11.2

Multitenant architecture detailed: instance tier.

27311.3 Multitenancy Architectures

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.1

Figure 11.2

and file system. Intermediate layers, such as presentation or Service-Oriented Archi-

tecture (SOA) services, communicate with browsers and smart devices respectively

to produce end-users’ output. Metadata are responsible for system customization so

that tenants can get a specific user experience. This customization includes data

model extension, adaptation of the presentation layer to corporative image, and busi-

ness workflow personalization. Security services must be present in all multiuser sys-

tems. In multitenant environments, the complexity of this component increases;

systems must maintain privacy not only among end users, but also among different

tenants.

11.4 AGILITY AND MULTITENANT ARCHITECTURES The term agile has been long used in software development to refer to a set of methods following the guidelines established in The Agile Manifesto [24]. This man- ifesto states four basic values:

– Individuals and interactions over processes and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan

Agile software development is a philosophy that separates radically from tradi-

tional methods of development, like the waterfall model. Focused more on team

organizations, agile methodologies like Scrum [25] or Xtreme Programming [26]

have a reputation of paying little attention to software architecture [27]. Support

of teams through certain validated software assets, from development frameworks

to architectural designs that foster reuse and make development easier, seems to have

been disregarded so far.

The concept of architecture, involving big up-front design and YAGNI, has terror-

ized agile teams that fear to end up sunken under a massive pile of documentation.

Proponents of agility think that that architecture should emerge gradually in every

sprint; they embrace the change and prefer adaptive systems instead of the use of pre- defined architectures that limit the system evolution. However, as well as these claims,

agile methods strive to deliver working and valuable software early and often to clients.

If so, it would be worthy to start from a proven and supportive architecture rather than

starting from scratch. In cloud MT systems, other issues, such as rapid deployment, may

be complementary to agile philosophy; there should be a fast change to the system so as

to accommodate potential tenants in as short a period of time as possible. In this regard,

architecture should not be doomed as a forbidden non-agile malpractice.

Recently, prominent authors from the system and software engineering commu-

nities have claimed and advocated in favor of coexistence between agile and archi-

tecture [28–30]. According to Ref. [7], “certain classes of system, ignoring

architectural issues too long, ‘hit a wall’ and collapse by lack of an architectural

focus.” In Ref. [30], Madison talks about agile architecture as a combination of these

274 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

two streams; this work gives the architect an essential role and indicates that this new

architectural direction should include a wide range of options instead of a closed

solution.

SaaS MTAs seek to leverage economies of scale due to software instance sharing

among tenants, whatever the kind of application deployed. Literature has not yet

covered how this architecture may support or even be Agile-compatible.

MTAs and other technologies, like software product line engineering (SPLE)

[31], may support agility with complementary issues (e.g., rapid deployment,

quality, and time-to-market). As seen in Figure 11.1, the MTMP component is

responsible for accounts creation; clients can be registered in the system and ready

to access the application within minutes. These two sides are not incompatible; they

just are different, and can be combined together.

According to Ref. [32], “Agility is the ability to rapidly and cost-effectively adapt

to market and environmental aspects.” This affirmation, originally applied to SPLE,

can be perfectly extended to SaaS MT applications. In SPLE, new modifications are

made to artifacts to cope with new requirements of the market; these artifacts are

used in the platform so that new versions of the products satisfy them. In MT, with

just one application instance (except in cases of a MT farm), propagation of change is

almost instantaneous. Moreover, changes are carried out over existing working

development projects rather than from scratch.

To sum up, MT not only tries to provide cost reduction for clients and maximi-

zation of provider profits, but also aims to support agility claims in different ways by:

• Deployment because clients are rapidly registered into the system.

• Maintenance and scalability when new requirements are needed.

• Development since changes are not made from scratch.

Architectures that aim to support agility are key in this new SaaS paradigm; with-

out the rapid and effective management or ease of upgrade that MTAs provide, SaaS

would be doomed to failure like ASP.

11.5 MULTITENANCY MONOTARGET: AGILITY CHALLENGES The market that SaaS applications serve on demand is vast. Companies willing to

change their traditional on-premises software will find their corresponding applica-

tion in the cloud. CRMs, ERPs, CMSs, DMSs or even vertical specialized [33] sys- tems, like a real estate CRM [34], are served on demand by SaaS providers and can be

subscribed to within minutes.

Traditionally, current multitenant applications deploy a single functionality or

are aimed to serve a specific line-of-business (LOB). A company needing a CRM will compare among those providers in the market serving CRM applications and

subscribe to the one that best fits its needs. If this same company would need a

CMS or ERP, it would probably end up subscribing to another SaaS vendor offering

those services on demand (see Figure 11.3a).

27511.5 Multitenancy Monotarget: Agility Challenges

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

With this model, where the market has different applications for different func-

tionalities, companies have to subscribe to as many applications as the services they

need. In traditional MT, tenants share not only application instances, but also the

functionality deployed. We could say that actual multitenancy is monotarget; ven- dors will have to develop new software applications if they want to target potential

clients from other LOBs or with different functional needs.

Many of these multitenant applications could share common lower development

components in their architecture. Database connectors, user authentication, or gen-

eral user interface components (graphics, style sheets, etc.) among others, might be

the same in any SaaS application whether it is for a CRM, CMS, or ERP. However, as

shown in Figure 11.3b, all these common components are to be replicated over all

these different implementations.

In terms of agility, replication means losing valuable time. During the develop-

ment process, programmers will have to duplicate and adapt/reconnect components

over implementations; vendors serving different applications will have to manage

different MTMPs with duplicated records of the same multisubscribed customers;

moreover, customers in turn will have bigger learning effort required as different

applications need to be learned and used.

11.6 SUPPORTING AGILITY: MULTITENANCY MULTITARGET MT

2 is a proposal to extend MTAs that allows multiple functionalities to be offered

in the same operational system. The main idea behind MT 2 is reusability of common

MT components. Several MT applications are grouped into a single MT 2 system

and used as assets to meta-generate customized service applications for clients. In

MT 2 , just one application instance is needed to manage different functionalities.

a b

FIGURE 11.3

(a) Subscriptions depend on functional needs. (b) Replication of common development

components.

276 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.3

Subscription determines the service(s) and therefore the functionalities to be

deployed during execution time.

MT 2 achieves reusability (and thus supports agility) by removing useless repli-

cation of common features. In multitenancy monotarget, functionalities are deployed

in different applications; hence components are replicated. In multitarget, shared

components are reutilized among all functionalities; cloud agile teams could boost

deployment, since just one application is needed to host many functionalities.

This way, applications are distributed among tenants with different functional

needs and vendors can host tenants from heterogeneous market sectors. This multi-

functional situation seeks several benefits as follows:

– Companies are able to subscribe to only one SaaS MT 2 application, speeding

up the learning process (Figure 11.4a, Tenant 2).

– Vendors have a multitarget market (Figure 11.4a, Vendor 1), broadening the spec-

trum of potential customers and making subscriber’s management faster thanks to

the multitarget master panel (MTMP). – Developers in turn avoid unnecessary replications, and therefore reduce time-to-

market (see Figure 11.4b).

To this end, new components are added to the traditional MTA (Figure 11.2).

Figure 11.5 represents the model of MT 2 A with those new components with a thicker

edge. These components enhance traditional MTAs, giving the ability to execute dif-

ferent functionalities depending on a tenant’s contract. Applications therefore could

be completely different among tenants; this meta-application profile of MT 2 involves

changes in both administrative and instance tiers.

In addition to traditional MT duties, this multiservice profile implies new com-

mitments. These novel features try to support agility and are described in the next

subsections.

a b

MT2 system MT2 system

FIGURE 11.4

(a) MT2 systems allow tenants to subscribe to multiple functionalities while providers manage

one MT2MP. (b) Reusability of common resources in MT2.

27711.6 Supporting Agility: Multitenancy Multitarget

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.4

11.6.1 Functional portfolio management The set of functionalities deployed in an MT

2 system is called the functional port-

folio. The number of functionalities in the portfolio may differ depending on vendor. MT

2 systems seek scalability not only at the tenant level, but also at the functional

level. New MT 2 systems may deploy just a few features, but can increase the

portfolio over time. Previous MT 2 systems are supposed to have larger functional

portfolios, since new functionalities are added on customers’ demands and remain

on the portfolio, unless outdated. The MT 2 MP must support the creation, addition,

or deletion of functionalities in the portfolio.

11.6.2 Multitarget metadata (MT2 metadata) Multitarget metadata links tenants’ accounts not to only functionalities subscribed to

by tenants, but also to contractual features of this relationship. For instance, if a ten-

ant wants to subscribe to SMS functionality, we should at least set the number of text

Administrative tier

Instance tier

Smart device

Individual business processing (IBP)

Common business processing (CBP)

Query processor

File system Multitenant database

L o

w e r le

v e l tie

MT2 master panel

FIGURE 11.5

MT2 architecture model.

278 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.5

messages contracted; setting this parameter in other functionalities, such as client management, does not make sense. Every subscription to functionalities has its own conditions, and these are reflected in the multitarget metadata of each tenant.

Subscriptions to functionalities are defined by multitarget metadata. Figure 11.6

shows an example of an MT 2 system with four functionalities in the portfolio and two

tenants. In this case, Tenant 1 is subscribed to CMS and SMS, whereas Tenant 2 has

contracted CRM and SMS; as we see, relationship to SMS is present in both tenan-

cies using MT 2 metadata, but the number of text messages to be sent differs.

With this extension, vendors can have all their SaaS applications unified. To this

end, they need to configure an MT 2 system with a functional portfolio including all

previously deployed functionalities. Clients from different applications are to be

registered in the MT 2 MP, setting up a subscription linking the functionality from

the previous monotarget SaaS application. This centralization improves agility in

deployment; just one multitarget master panel is needed to control all clients and

applications (now as functionalities in the MT 2 system). MT

2 systems can be scaled

with tenants with changing functional needs; resource optimization is easier to

achieve with the consequent reduction of costs. Vendors and customers can leverage

this unification not only for an even more attractive price, but also because the new set

of functionalities offered could be deployed within minutes by means of the MT 2 MP.

11.6.3 Business process reutilization Reusability of common features along all functionalities is the main cause of this

MT 2 extension. In a multitarget environment, business layers are divided into:

– Common Business Processing (CBP): It includes those elements that are business- independent and reusable across all functionalities.

MT2 functional portfolio

Multitarget metadata

FIGURE 11.6

Multitarget metadata contains subscription details and contractual features for each tenant.

27911.6 Supporting Agility: Multitenancy Multitarget

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.6

– Individual Business Processing (IBP): It includes those elements that are business-dependent and which are specifically designed to support one

functionality.

During the execution timeline of their application instances, all tenants will

import CBP elements statically; however, IBP elements will be imported dynami-

cally depending on tenants’ subscriptions. In Figure 11.7, a tenant has a subscription

to functionalities F2 and F4. In this case, all CBP components are imported statically.

However, in the dynamic IBP selection for importation, just F2 and F4 components

will be included. Security services will check subscription and will confirm that only

these two functionalities are to be deployed during execution.

As mentioned above, CBP represents all those components reused in different

functionalities; agility in development is reached due to reusability. Features such

as privacy or system authentication are no longer to be developed in future function-

alities; they are already in the CBP layer. Furthermore, development effort is reduced

not only because of reutilization of CBP elements, but also for their extension. For

instance (see Figure 11.8), if a programmer needs to develop a specific feature and

MT2

instance execution

CBP import

CBP item Metadata security

Multitarget metadata

IBP import

FIGURE 11.7

Static and dynamic import in MT2.

FIGURE 11.8

Agility in development for extension of CBP classes.

280 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.7

Figure 11.8

encapsulate it within a class; that class does not need to be developed from the begin-

ning; it can be coded by extending one existing class from the CBP layer.

11.6.4 Multitarget security MT

2 environments deploy different functionalities depending on tenants’ subscrip-

tions; tenants share applications, but functional deployment may differ. In this situ-

ation, security components become more complex in architecture, since end users are

allowed to execute those functionalities present in the subscription and not others.

Multitarget involves new guarantees for the security layer at two levels:

– Tenant level: Tenants should not deploy functionalities that are not included in subscription. Security must ensure that forbidden functionalities are not deployed.

– End-user level: MT applications are multiuser environments at instance level. Tenants end-users have different roles that determine their capabilities in the sys-

tem. In MT 2 , tenants may have a subscription to a certain functionality, but not all

the tenancy should have access to it. Admin users of the tenancy must have the

capability to decide for each user what functionalities to deploy from the tenant

portfolio. For instance, a company could have a subscription to accounting and

agenda functionalities; however, leaking of important financial data is not desir-

able, so accounting functionality could be hidden from certain users of the tenancy

for security reasons.

11.7 GLOBALGEST: A REAL MT2 SYSTEM Globalgest [10,11] is an example of a business-oriented application based on MT

architecture. It has been implemented by 21 companies and deploys more than

100 functionalities. Combinations of this portfolio allow Globalgest to serve busi-

nesses from different industries, such as a medical clinic or an IT company, by choos-

ing different functional subscriptions for them [35].

Globalgest is a single application that serves companies from different industries

without duplicating development efforts. MT 2 architecture allows Globalgest to deploy

andhostseveralfunctionalitiesconfiguringaclient’sfunctionalsubscriptionondemand.

Rapid provisioning is key in Globalgest; customers require a fast response that is

reached thanks to the administrative level of the architecture—the MT 2 master panel.

Setting up a new client account in Globalgest is easy and entails only a few steps.

Once logged into the system as an MT 2 administrator, a user will be able to access the

administrative level. As seen in Figures 11.9 and 11.10, this process is quite simple:

1. Open the MT2MP 2. Click on Insert new account 3. Fill in tenant details: Contact, billing, shipping

28111.7 Globalgest: A Real MT2 System

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

4. Set subscription details: 4.1 Expiration and method of payment 4.2 Create admin user for the tenancy 4.3 Set functionalities desired by the customer by just clicking on the

check fields

The agility with which this operation can be performed is very noticeable; tenants

can be registered within minutes. Steps 1-4.3 might be common to other monotarget

applications, but the main difference and benefit that MT 2 provides to Globalgest is

in Step 4.3. In this phase, clients are registered with a personalized service by choos-

ing the functionalities desired (Figure 11.10). In traditional MT, this possibility is not

FIGURE 11.9

MT2MP: inserting new account.

FIGURE 11.10

Functional selection in the MT2MP.

282 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.9

Figure 11.10

present, because it is monofunctional; therefore, customers with different functional

requirements might be registered in as many MT applications as functional needs.

The major advantage of Globalgest against their MT competitors is multiservice,

and therefore the agility, in providing different services with just one software

instance. Subscribing to an ERP or a CRM can be a difficult decision. However, that

might not be the case for other, less important functionalities (CMS, for instance).

Clients can be registered with a set of these simpler functionalities and once they

get used to the interface and have passed the learning curve, they will more likely

step forward and upgrade their subscription to more complex functionalities. In con-

trast, for the Globalgest vendor this upgrade operation is just a click away thanks to

the MT 2 MP.

Furthermore, Globalgest has a functional portfolio that can increase its number of

functionalities with time. As these new features are incorporated into the system, ten-

ants can upgrade their subscription—either because these new functionalities com-

plement others already contracted, or because they are newly interested. In any case,

the Globalgest vendor is one step ahead of its competitors again.

As explained before, in Globalgest, functionalities do not need to be developed

from scratch. The MT 2 architecture allows developers to achieve agility in develop-

ment because common components over functionalities are reused and not repli-

cated. Programmed with PHP as its server language and MySQL as its database

engine, the CBP layer includes these main classes:

– SQLConnector.php: Database processing and query management – HTMLCreator.php: Creation of HTML data (tables, inputs, forms, dialogs, etc.) – Controller.php: Security and the tenant’s privacy – FileConnector.php: File system access – WSConnector.php: Responsible for SOA

During execution time in all functionalities, these classes are instantiated and

developers can make use of them instead of reprogramming. If new specific pro-

gramming is needed for the functionality, new IBP classes can be encoded; unlike

MT applications, these new classes can be encoded extending existing CBP classes.

Figure 11.11 shows a real example of how a CPB class (HTMLCreator) is extended for specific purposes in SMS functionality. In this example, a new popup

FIGURE 11.11

CBP class extension.

28311.7 Globalgest: A Real MT2 System

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.11

(Figure 11.12) will appear to the user when trying to text a person with no numbers on

its record.

Agility becomes especially critical when the company that owns the software

lacks human resources. For very small IT companies, MT’s support for agility is

not enough. MT 2 provides not only rapid deployment, but also agility for develop-

ment and eases the general management of the system. Multitarget applications like

Globalgest can serve dozens of tenants with just one system administrator.

11.8 RELATED WORK Some similarities can be seen to SPLE [31,36] due to reusability of common com-

ponents. However, SPLE involves obtaining personalized software products from

the platform, whereas MT 2 just uses the same components running in the same soft-

ware instance. In MT 2 ,reusability takes place during execution time, whereas SPLE

reuses the artifacts during development. Moreover, with MT 2 , services deployed for

a customer could change by just modifying the functional contract; in SPLE, a prod-

uct cannot be changed once it has been released from the platform.

Salesforce.com [37] is another SaaS platform offering different functionalities

that can be subscribed to piecewise. However, to the best of our knowledge, no

underlying architectural models of this multifunctional architecture or evidence of

their existence have been provided (i.e., it is not clear if Salesforce.com has a core

FIGURE 11.12

Popup generated when trying to use SMS functionality in Globalgest.

284 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

Figure 11.12

architecture and, if so, how it evolves). The novelty of this approach is the extension

from traditional MTA to MT 2 A where the CBP elements are key for software reuse.

Fink and Markovich [33] explain three different verticalization strategies for IT

development companies. Horizontal strategies are general solutions suitable for

many sectors that potentially appeal to most or all market users. Vertical strategies

are tailored products designed specifically for one sector. Small and medium busi-

ness (SMB) companies choose this strategy due to its capacity limitations, whereas

large, specialized companies may develop many vertical solutions to different mar-

kets, adopting a multivertical strategy. MT 2 breaks this limitation to SMB compa-

nies, since with just one application instance they are able to manage not only

multiple customers, but also multiple targets. Contribution is for a cloud multitenant

environment, where sharing is key. A vertical solution could be better for just one

client and one project, but not for the SaaS model. MT 2 tries to go a step further

and use the same application for clients with different needs.

Zaidman [20] proposes an architecture model for MT SaaS applications to avoid

maintenance problems. It defines the key characteristics in MT and explains

opportunities in SaaS MT applications, like zero-downtime or security, but does

not consider coexistence of different business logics for the same system, which

MT 2 does.

Kr et al. [38] presented a backend customization approach for MT SaaS applica-

tions. Extensibility and customization of database models is well understood, and

there are many approaches. In contrast, personalization of user interfaces and espe-

cially business logic models is still a challenge. This approach is related to custom-

ization of the business logic, but within the same functionality for all tenants. It does

not consider multifunctionality.

Banks et al. [39] introduced a conceptual prototype, called Fractal, which is an

application for collaboration among tenants within an MT environment. It explores

the key requirements for creating a collaborating platform. In subsequent versions of

MT 2 , we will try to study possible controlled collaborations among tenants.

In Ref. [40], a framework for reengineering applications to support MT is

explained. It does not consider multiservice provisioning.

11.9 CONCLUSIONS AND FUTURE WORK Cloud computing and its new software delivery model (SaaS) are increasingly being

adopted for current software vendors. SaaS has become a common software distri-

bution formula for users [41]; according to Ref. [42], SaaS revenue is expected to

reach nearly 5 billion dollars. The adoption of SaaS is just a matter of time, if it

has not been already done.

MT is a key feature and an essential characteristic in cloud computing. MT archi-

tectures allow SaaS applications to aggregate users into the system on demand, ven-

dors leverage scalability to reduce the general cost of applications, and users afford

top-quality implementations: everybody wins.

28511.9 Conclusions and Future Work

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

There is a recent debate on the coexistence between agility and architecture, claim-

ing that these two cultures should not be considered opposite. In cloud environments,

architectures supporting claims such as the quick delivery of working software to cli-

ents should not be left separate from the agile movement.

Traditionally, applications aim to serve one single purpose, and therefore differ-

ent purposes involve different applications. MT applications are thereby monotarget,

because they target one line of business.

In this chapter, we have presented multitarget as an extension to MTAs. Thanks to

the reuse of common features, MT 2 allows traditional monotarget applications to

support multiple functionalities and deploy them selectively depending on subscrip-

tion contract. MT 2 A is an example of the fruitful combination of agility and archi-

tecture, in the sense that it makes possible a rapid delivery of working,

multifunctional software to clients by taking advantage of a consolidated and proven

(working) software architecture. MT 2 aims to support agility not only for deployment

due to unification, but also for development.

Although MT 2 is already implemented in Globalgest, the novelty of this approach

opens a big field for further study of this architecture. New challenges are to be over-

come and new benefits are to be found. The complexity of the architectural model

needs further study and detail—especially in the administrative tier. There are many

aspects to be considered when providing a multifunctional service; functionalities,

for instance, may be dependent on each other (appointments and agenda may be dependent to the entities involved, like clients or human resources). This dependency control should be reflected in the MT

2 architecture.

Benefits in terms of agility should be demonstrated with some empirical/

estimated data about development and deployment times and costs and more detailed

examples of code and specific pictures are also needed. Besides the benefits, the short-

comings of MT 2 , such as application centralization, need to be explained and solved.

The MT 2 MP can be considered in the range of meta-applications; new tenants can

be set up by means of this master panel giving out service-customized applications

on demand. We will further study the relationship between MT 2 and the world of

meta-applications.

The next step in MT 2 will be called MT

2.0 . The multitarget profile of MT

involves providing service to clients from different sectors and lines of business.

If these companies from different industries already cooperate daily in the real world,

why not do it via networking using multitarget systems? We will deepen the study of

networking among tenants; a collaboration that will be reflected by controlled data

sharing and interaction among users from different tenancies.

References [1] Ambrust M, Fox A, Griffith R, Joseph AD, Katz RH, Konwinski A, et al. Above the

clouds: A Berkeley view of cloud computing. Berkeley: Dept. Electrical Eng. and

Comput. Sciences, University of California; 2009, Rep. UCB/EECS. 28; 2009.

286 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf9000

[2] Chong F, Carraro G. Architecture strategies for catching the long tail: what is software as

a service? Most. 479069; 2006. p. 1–22.

[3] Coffee P. Busting Myths of On-Demand: Why Multi-Tenancy Matters; 2007. Salesforce.

com White Paper, http://wiki.apexdevnet.com/images/0/04/MythbustMultiT.PDF.

[4] Qaisar EJ. Introduction to cloud computing for developers: key concepts, the players and

their offerings. In: 2012 IEEE TCF information technology professional conference;

2012. p. 1–6.

[5] Jacobs D, Aulbach S. Ruminations on multi-tenant databases. Fachtagung fur

Datenbanksysteme in Business, Technologie und Web (BTW), Aachen, Germany, March

5–9, 2007.

[6] Block M. Evolving to agile: a story of agile adoption at a small SaaS company. In:

AGILE conference; 2011. p. 234–9.

[7] Kruchten P. Software architecture and agile software development: a clash of two cul-

tures? In: 2010 ACM/IEEE 32nd international conference on software engineering, Cape

Town, South Africa; 2010. p. 497–8.

[8] Liu S, Zhang Y, Meng X. Towards High Maturity in SaaS Applications Based on Vir-

tualization. Int. J. Inform. Syst. Service Sector 2011;3:39–53.

[9] Rico A, Noguera M, Garrido JL, Benghazi K, Chung L. Multi-Tenancy Multi-Target

(MT2): A SaaS Architecture for the Cloud. In: Advanced Information Systems Engineer-

ing Workshops; 2012. p. 214–27.

[10] RicoA.DesarrolloTIC.SEO,web,andsoftwaredevelopment,http://www.desarrollotic.com/.

[11] Rico, A. Software de Gestión ERP y CRM en la Nube - Globalgest ERP. (n.d.). Retrieved

July 14, 2013, from http://globalgest-saas.com/.

[12] Mell P, Grance T. The NIST definition of cloud computing (draft). NIST special publi-

cation 2011;800(145):7.

[13] Vaquero L, Rodero-Merino L. A break in the clouds: towards a cloud definition. ACM

SIGCOMM 2008;39(1):50–5.

[14] Armbrust M, Stoica I, Zaharia M, Fox A, Griffith R, Joseph AD, et al. A view of cloud

computing. Communications of the ACM 2010;53(4):50. http://dx.doi.org/10.1145/

1721654.1721672.

[15] Parkhill DF. Challenge of the computer utility. Reading, MA: Addison-Wesley Educa-

tional Publishers; 1966.

[16] Turner M, et al. Turning software into a service. Computer 2003;36(10):38–44.

[17] Liu G, et al. Software design on a SaaS platform. In: 2010 2nd International conference

on computer engineering and technology; 2010. p. V4-355–8.

[18] Papazoglou M. Service-oriented computing: concepts, characteristics and directions. In

Proceedings of the 7th International Conference on Properties and Applications of

Dielectric Materials (Cat. No.03CH37417). IEEE Comput. Soc; p. 3–12. http://dx.doi.

org/10.1109/WISE.2003.1254461

[19] Bezemer C, Zaidman A. Challenges of reengineering into multi-tenant SaaS applications:

challenges; 2010.

[20] Zaidman A. Multi-tenant SaaS applications: maintenance dream or nightmare? Position

paper.

[21] Aulbach S, et al. A comparison of flexible schemas for software as a service. ACME

2009;881–8.

[22] Aulbach S, Grust T, Jacobs D, Kemper A, Rittinger J. Multi-tenant databases for software

as a service: In: Proceedings of the 2008 ACM SIGMOD international conference on

Management of data - SIGMOD ‘08. New York, USA: ACM Press; 2008. p. 1195.

287References

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://wiki.apexdevnet.com/images/0/04/MythbustMultiT.PDF

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0010

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0015

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0020

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0025

http://www.desarrollotic.com/

http://globalgest-saas.com/

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0030

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0035

http://dx.doi.org/10.1145/1721654.1721672

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0040

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0045

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0050

[23] Chong F, et al. Multi-tenant data architecture three approaches to managing multi-tenant

data architecture. 479086; June 2006. p. 1–18.

[24] Beck K, et al. Manifesto for agile software development, http://agilemanifesto.org/.

[25] Schwaber K, Beedle M. Agile software development with scrum. Englewood Cliffs, NJ:

Prentice Hall; 2001.

[26] Beck K. Embracing change with extreme programming. Computer 1999;32(10):70–7.

http://dx.doi.org/10.1109/2.796139.

[27] Hanssen GK, Fægri TE. Process fusion: an industrial case study on agile software product

line engineering. J Syst Softw 2008;81(6):843–54.

[28] Abrahamsson P, et al. Agility and architecture: can they coexist? IEEE Softw 2010;27

(2):16–22.

[29] Booch G. An architectural oxymoron. IEEE Softw 2010;27(5):96.

[30] Madison J. Agile architecture interactions. IEEE Softw 2010;27(2):41–8.

[31] Pohl K, et al. Software product line engineering: foundations, principles, and techniques.

Secaucus, NJ: Springer-Verlag New York Inc; 2005.

[32] Clements P, McGregor J. Better, faster, cheaper: pick any three. Bus Horiz 2012;55

(2):201–8.

[33] Fink L, Markovich S. Generic verticalization strategies in enterprise system markets: an

exploratory framework. J Inform Tech 2008;23(4):281–96.

[34] TIC D. NetPropertyAgent—SaaS real estate CRM, http://www.netpropertyagent.com/.

[35] Ortega AR, et al. Multi-tenancy multi-target (MT2): a SaaS architecture for the cloud. In:

CAiSE workshops; 2012. p. 214–27.

[36] Clements P, Northrop L. Software product lines. Boston: Addison-Wesley; 2002.

[37] SalesForce.com, http://www.salesforce.com/.

[38] Kr J, et al. Customizing enterprise software as a service applications: back-end extension

in a multi-tenancy environment. Work 2009;24(I):66–77.

[39] Banks D, Erickson J, Rhodes M. Multi-tenancy in cloud-based collaboration services.

Hewlett-Packard Development Company, LP; 2009. Retrieved from http://www.hpl.

hp.com/techreports/2009/HPL-2009-17.pdf.

[40] Almorsy M, Grundy J, Ibrahim AS. SMURF: Supporting Multi-tenancy Using Re-

aspects Framework. In: 2012 17th International Conference on Engineering of Complex

Computer Systems (ICECCS); 2012. p. 361–70.

[41] Benefield R. Agile deployment: lean service management and deployment strategies for

the SaaS enterprise; 2009. p. 1–5.

[42] A worlwide review of SaaS growth, http://www.vi.net/blog/2012/01/a-worlwide-review-

of-software-as-a-service-saas-growth/.

288 CHAPTER 11 MT2: A Multitenant Multitarget Architecture

C o p yr

ig h t ©

2 0 1 3 . E

ls e vi

e r

S ci

e n ce

& T

e ch

n o lo

g y.

A ll

ri g h ts

r e

se rv

e d .

http://agilemanifesto.org/

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0060

http://dx.doi.org/10.1109/2.796139

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0070

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0075

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0080

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0085

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0090

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0095

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0100

http://www.netpropertyagent.com/

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0105

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0110

http://www.salesforce.com/

http://refhub.elsevier.com/B978-0-12-407772-0.00010-1/rf0115

http://www.hpl.hp.com/techreports/2009/HPL-2009-17.pdf

http://www.vi.net/blog/2012/01/a-worlwide-review-of-software-as-a-service-saas-growth/