FISA-XP: an agile-based integration of security activities with extreme programming S.

Klock

FISA-XP: an agile-based integration of

security activities with extreme
programming
Sander Klock
University of Utrecht
j.a.klock@students.uu.nl
3816958
Student Assistent: Floor Aarnoutse

Notice of Originality

I declare that this paper is my own work and that information derived from pub-
lished or unpublished work of others has been acknowledged in the text and has been
explicitly referred to in the list of references. All citations are in the text between quotation
marks ( ). I am fully aware that violation of these rules can have severe consequences for
my study at Utrecht University.

Signed: Sander Klock Name: Sander Klock

Date: 20-04-2015 Place: Utrecht, the Netherlands

I. Introduction
This paper discusses the FISA-XP method that is proposed by Sonia, Singhal, and Banati (2014).
FISA-XP aims to integrate security activities with the core activities of Extreme Programming
(XP). This integration is proposed because security activities during the development phase are
becoming increasingly important due to the vast increase of security treats nowadays.
Currently agile software development methods like SCRUM and Extreme Programming (XP)
are very popular. These agile methods provide software developers with the ability to quickly
react to unpredictable changes. This method of software development however conflicts with
security activities. Most security activities require planning in advance and are not very agile.
The method is defined in two phases. Both phases consist of three steps, which will be
described in the next section. The entire method is iterative. After completion of the integration of
an agile activity with a security activity, the integration process will start again from phase II with
the next agile activity.

I.I. Phase one

The first step of this method is called Security and Agile Activities selection. In this phase
the security activities and agile activities are selected. These security activities can be selected
from several secure software development processes. The paper uses the activities of CLASP
(Comprehensive, Lightweight Application Security Process) by the Open Web Application Security
Project (OWASP) because it is more lightweight compared to other alternatives (Foundation, 2006;

1
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

de Win, Scandariato, Buyens, Grgoire, & Joosen, 2009). There are several methods available for
the agile activities. The agile activities of XP are used by this method.
The second step is to identify which of the agility features affect the agility of an activity. The
authors propose a group of agility features based on their literature research and their previous
work (Sonia & Singhal, 2012).
The third step orders these features according to their relative importance using a technique
they call WRIAF (Weights describing Relative Importance of Agility Features). This phase results
in a table with the desired agility features and sub-features with their assigned weights.

I.II. Phase two

The first step of this phase creates a binary integration matrix of the security and agile activities.
This integration matrix shows the compatibility of the agile activities with the security activities
(Keramati & Mirian-Hosseinabadi, 2008). The integration matrix built by Sonia et al. is based on
the results of Al-Ahmad (2011).
The second step calculates the agility degree of the security activities that are compatible
according to the integration matrix created in the previous step.
The third step calculates the agility degree of the agile activities. The agility degree of the
security and agile activities are combined into the combined agility degree. Furthermore an
acceptable amount of agility loss is defined (AARF). This factor is defined by the developers and
the customer. AARF is influenced by several factors like the level of security that is required,
project budget and the type of threats that are expected. Based on this AARF value, the allowed
reduction of the combined agility degree is determined. If the combined agility degree decreases
more than the allowed decrease by implementing a security activity, the integration of the security
activity with the agile activity is rejected.

I.III. About the authors

Sonia, Singhal, and Banati have written multiple papers in this field of research, as discussed in
section VI. All three authors are associated with the computer science department of the University
of Delhi. Archana Singhal is an associated professor at Indraprastha College For Women, Delhi
University. Sonia is a PhD student of Archana Singhal at this moment. Finally Hema Banati is an
Associate professor at Dyal Singh college, Delhi University.

2
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

II. Example
This section will give an example of applying FISA-XP in the case of a startup that wants to create
a web shop (webshop.com). Webshop.com wants to develop this web shop iteratively using the XP
developing method since their developers are familiar with it. At first they want to create the basic
features and than gradually extend the web shop application. Since the web shop stores payment
details of users and other privacy related details, security of the stored data is important. However
the budget of the startup is limited, which requires them to quickly release their base product.
As stated in the introduction, the startup will use the XP activities as agile activities. Web-
shop.com will use the OWASP CLASP security checklist because it is recommended by the authors
of the method and it saves them time because they can reuse results from the authors.

Detail misuse cases

Specify operational

Identify user roles

and requirements

Planning Activity
Perform security
Identify global
security policy

requirements
environment

analysis of
Desired Agile
Related Attributes
Characteristics
Change in project plans 2 2 2 2 2 4
Changes in team members 2 2 2 2 3 4
Flexibility
Changes to new technology 1 3 2 2 2 4
Changes at any later stage
0 0 1 1 1 4
even in work product
Simplicity 1 0 1 2 2 2
Leanness (L) Quality Improvement 3 2 2 2 2 3
Economical 1 0 1 1 1 2
Documentation
- 0 1 0 1 1 1
Level (DL)
Iterative behaviour 0 0 2 2 2 4
Development Incremental towards
1 1 1 2 2 3
Style (DS) continuous improvement
Rapid execution 1 1 2 2 1 3
Informal 0 0 1 1 1 3
Cross functional ability
1 1 2 3 2 3
Team Structure (Self Organized disciplined teams)
and Behaviour (TS) Competency 1 1 2 2 1 2
Trust level and cooperation 1 1 1 1 1 2
Automation Level (AL) - 1 1 1 2 2 2
Learning & knowledge Continuous training and
2 2 2 1 1 3
development (LK) development of business people
Reusability (R) - 1 1 1 2 2 3
Role of customer i.e. Customer satisfaction 1 1 1 2 3 4
Customer involvement (CI) Customer Interaction
0 0 1 2 1 4
and enrichement
.
Table 1: Modified Preferred Agile Values of CLASP Security Activities and XP Planning activity used for measuring their agility degrees.
Based on the table of Sonia et al. (2014)

3
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

Based on the reuse of the previous components they can also reuse the integration matrix that
was provided by Sonia et al. (2014). Webshop.com however does not agree with the assigned
agility degree of the security activities. The matrix with the assigned agility degrees of the security
activities is modified as can be seen in Table 1. The cells with red text indicate a changed assigned
agility degree. A specification of the operational environment is not considered agile with regards
to changes in the technology used. Since web development is a rapidly evolving area, they consider
it likely that they will use different technologies in the future. Furthermore Webshop.com believe
that implementing a global security policy for their web shop can be reused when switched to
another technology. Because of their limited budget, they find the creation of the detailed misuse
cases too expensive. Furthermore the management of the startup requires a security analysis of
most new requirements, so this is considered important and hence assigned a higher agile value.

Next they define an acceptable amount of agility loss (AARF). Webshop.com decides to define
this threshold quite low for the beginning because of the financial needs to release a product. They
define a 5% agility loss as acceptable. Based on their defined threshold and the calculations that
resulted from the defined agility degrees, they select the security activities that have an agility loss
less than 5%. These activities are then selected and performed during the development process.

III. Process-deliverable Diagram

This section describes the method and technique presented by Sonia et al. (2014) using two
Process-deliverable diagrams (PDD). The PDDs are created using a meta-modeling technique
presented by van de Weerd and Brinkkemper (2008). The model follows the conventions presented
in that paper. The PDD of the entire method is depicted in Figure 1. The technique used in the
Determine importance of Agility Feature activity of this method is elaborated in a seperate PDD,
as shown in Figure 2. These PDDs are supported by an Activity table (Table 2) and a Concept
table (Table 3). These tables contain the activities and concepts respectively of both the method
and technique.

The paper of Sonia et al. (2014) does not provide explicit roles for the method or activities.
Since the activities require knowledge of both the business and technical aspects, the role of
Project manager is assigned to the diagrams. Depending on the size and complexity of the
project, other people might be involved. A team of security experts might be involved to select
the required security activities for an development project that has high security requirements for
example.

4
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

III.I. Method Process-deliverable Diagram

Figure 1: Method Process-deliverable Diagram of the described method

FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

III.II. Technique Process-deliverable Diagram

Figure 2: Technique Process-deliverable Diagram of the described method

6
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

IV. Activity Table

Table 2: Activity Table

Activity Sub activity Description

Agility feature selection and assigning Relative weights
Select Agile Select the AGILE ACTIVITIES from an agile method. All these
Activities AGILE ACTIVITIES make the AGILE AGILITIES LIST.
Select Secu- Select the SECURITY ACTIVITIES from a secure software de-
rity Activi- velopment process. All these SECURITY ACTIVITIES make the
ties SECURITY ACTIVITIES LIST.
Identify Ag- This step identifies AGILE FEATURES that are used to compute
ile Features the agility degree of an activity. The AGILE FEATURES are com-
bined into the AGILE FEATURES LIST. These AGILE FEATURES
are attributes like Flexibility, Leanness and Documentation level.
They are used for both the agility degree calculation of the AG-
ILE ACTIVITIES and SECURITY ACTIVITIES. The method does
not provide a technique to do this, but the authors provide nine
AGILE FEATURES they have identified based on their literature
review and previous work (Sonia et al., 2014).
Identify This sub activity identifies the importance of AGILE FEATURES.
Determine
agile This importance is expressed as a number. Hereby the AGILE
importance
(sub)features FEATURES and sub-features are assessed to identify their contri-
of Agile
butions to the agility of a SECURITY ACTIVITY.
Feature
Create agile A hierarchy is created where a goal is placed at the highest level.
feature hier- Below this level the AGILITY FEATURES are placed. This level is
archy followed by the third level in which the sub-AGILITY FEATURES
are located.
Perform Pair-wise comparisons of AGILE FEATURES are created in this
pairwise phase. These pair-wise comparisons indicate how more impor-
comparisons tant the first AGILE FEATURE is than the second AGILE FEA-
of features TURE. This is done using a scale from one to nine. Since of the
subjectivity of this judgements, it is recommended to perform
this activity with a group of experts and aggregate the results
into a single representative judgement. The COMPARISON MA-
TRIX contains the results of all pair-wise comparisons between
the AGILE FEATURES.
Create Nor- A priority vector is computed to determine the weights of at-
malized Ma- tributes. This vector is used to create the NORMALIZED COM-
trix PARISON MATRIX, showing the relative importance of each
agility feature.
Calculate The CONSISTENCY RATIO determines if the data collected
data consis- during the pair-wise comparisons is consistent. A higher ratio
tency implies higher inconsistency. A CONSISTENCY RATIO higher
than 0.10 for a comparison is reason to study the problem further
and re-evaluate those pair-wise comparisons.

7
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

Activity Sub activity Description

Determine Calculate This phase calculates the global weight of an AGILE FEATURE.
importance global The global weights are computed by multiplying the relative
of Agile weights weight of AGILITY FEATURES with the relative weights of their
Feature sub-features. These global weights are noted in the AGILE FEA-
(cont.) TURE GLOBAL WEIGHT TABLE.
Filter Agility This step produces the end result of this technique, the FILTERED
features WEIGHTED AGILE FEATURE LIST. This WEIGHTED AGILE
FEATURE LIST is a filtered version of the AGILE FEATURE
GLOBAL WEIGHT TABLE. This list consists of the selected AG-
ILE FEATURES from the AGILE FEATURE GLOBAL WEIGHT
TABLE. The selection fully depends on the project and company
context and constraints. A project with limited time or tight
budget might want to limit the amount of AGILE FEATURES
to limit the complexity. The selection can be based on a lower
threshold. All AGILE FEATURES with global weights below this
threshold will be discarded.
Build in- The INTEGRATION MATRIX displays if a SECURITY ACTIVITY
tegration can be integrated with an AGILE ACTIVITY. An integratable
matrix pair of activities is marked with a 1 in the cell, a 0 or blank
otherwise.
Integration of security activities with agile activities
Determine This activity selects all SECURITY ACTIVITIES that can be in-
integration tegrated with the specified AGILE ACTIVITY according to the
possibilities INTEGRATION MATRIX. This results in INTEGRATABLE SE-
CURITY & AGILE ACTIVITY PAIRS.
Calculate The Agility degree of each SECURITY ACTIVITY that occurs in
Agility the INTEGRATABLE SECURITY & AGILE ACTIVITY PAIRS is
degree of calculated.
Security
Activity
Calculate The agility degree of the AGILE ACTIVITY is calculated in this
Agility de- step, resulting in the AGILITY DEGREE OF AGILE ACTIVITY.
gree of Agile
Activity
Calculate This step calculates the COMBINED AGILITY DEGREE of the
combined AGILE ACTIVITY with each SECURITY ACTIVITY that occurs in
Agility the INTEGRATABLE SECURITY & AGILE ACTIVITY PAIRS. The
degree results of these calculations are aggregated in the COMBINED
ACTIVITY AGILITY DEGREE LIST.
Determine The AARF is based on several factors like the level of security
Acceptable required, cost and time approved for the project and the type of
Agility security necessary for the project. The AARF should be decided
Reduc- by mutual consent of the development team and the customer.
tion Factor The AARF is expressed as a percentage of acceptable agility
(AARF) reduction.

8
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

Activity Sub activity Description

Filter activ- Every COMBINED AGILITY DEGREE OF AGILE ACTIVITY
ities using AND SECURITY ACTIVITY CAd is compared to the AARF. If
AARF the reduction in CAd is less than AARF then this activity is added
to FILTERED COMBINED ACTIVITY AGILITY DEGREE LIST.

V. Concept table

Table 3: Concept table

Concept Description
AGILE ACTIVITY Activity that is part of an Agile method. An Agile method is an
(system development) method that is aligned with the concepts
of the Agile Manifesto (Fowler & Highsmith, 2001).
AGILE ACTIVITY LIST Collection of AGILE ACTIVITIES
SECURITY ACTIVITY Activity that is part of an software development process that
helps developers build more secure software.
SECURITY ACTIVITY Collection of SECURITY ACTIVITIES
LIST
AGILE FEATURE Factor desirable for describing agile nature of an activity (Sonia
& Singhal, 2012).
AGILE FEATURE HIER- Hierarchy of AGILE FEATURES where a goal is placed at the
ARCHY highest level. The second level contains AGILITY FEATURES
and the third level contains the AGILITY sub-FEATURES. The
hierarchy is displayed in a table. The first column contains the
goal, the second column the AGILITY FEATURES and the third
column contains the AGILITY sub-FEATURES (if any) (Sonia et
al., 2014).
COMPARISON MATRIX Contains the results of all pair-wise importance comparisons
between the AGILE FEATURES (Sonia et al., 2014).
NORMALIZED COM- Specialized version of the COMPARISON MATRIX. This version
PARISON MATRIX is created by normalizing the COMPARISON matrix using a com-
puted priority vector to determine the weights of the attributes
(Sonia et al., 2014).
CONSISTENCY RATIO This ratio compares the inconsistency of the set of judgements
in a matrix with what it would be if the judgements and the
corresponding reciprocals were taken at random from the scale
(Saaty, 1994).
AGILE FEATURE
Table containing all AGILE FEATURE and corresponding AGILE
GLOBAL WEIGHT TABLE
sub-FEATURES with their corresponding weights (Sonia et al.,
2014).
WEIGHTED AGILE FEA- Collection of AGILE FEATURES with associated weights, describ-
TURES LIST ing the relative importance (Sonia et al., 2014).

9
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

Concept Description
INTEGRATION MATRIX Matrix that depicts the integration possibilities between SECU-
RITY ACTIVITIES and AGILE ACTIVITIES. The AGILE ACTIVI-
TIES form the column headers, the SECURITY ACTIVITIES are
the row headers. The matrix can be build using the following
formula:
(
1, if (i, j) integration is possible
aij =
0, otherwise

Here i represents the SECURITY ACTIVITY and j represents the

AGILE ACTIVITY (Sonia et al., 2014).
INTEGRATABLE SECU- Pair of an AGILE ACTIVITY and a SECURITY ACTIVITY that can
RITY & AGILE ACTIVITY be integrated according to the INTEGRATION MATRIX (Sonia
PAIR et al., 2014).
INTEGRATABLE ACTIV- Collection of INTEGRATABLE SECURITY & AGILE ACTIVITY
ITY LIST PAIRS
AGILITY DEGREE Level of activitys compatibility with agile methodologies. This
is calculated on the basis of AGILITY FEATURES (Keramati
& Mirian-Hosseinabadi, 2008). The degree is expressed as a
number.
AGILITY DEGREE OF SE- AGILITY DEGREE of a SECURITY ACTIVITY. This indicates
CURITY ACTIVITY how agile a particular SECURITY ACTIVITY is and thus how
easy it can be integrated with an Agile Method.
SECURITY ACTIVITY Collection of AGILE DEGREES of SECURITY ACTIVITIES
AGILITY DEGREE LIST
AGILITY DEGREE OF AGILITY DEGREE of an AGILE ACTIVITY
AGILE ACTIVITY
COMBINED AGILITY AGILE DEGREE of an AGILE ACTIVITY combined with AGILE
DEGREE OF AGILE AC- DEGREE of a SECURITY ACTIVITY
TIVITY AND SECURITY
ACTIVITY
COMBINED ACTIVITY Collection of COMBINED AGILITY DEGREES OF AGILE AC-
AGILITY DEGREE LIST TIVITY AND SECURITY ACTIVITY
ACCEPTABLE AGILITY Percentage of reduction in agility that is considered tolerable.
REDUCTION FACTOR This factor is decided by mutual consent of the software develop-
(AARF) ment team and the customer (Sonia et al., 2014).
FILTERED COMBINED Specialized version of COMBINED ACTIVITY AGILITY DE-
ACTIVITY AGILITY DE- GREE LIST only containing COMBINED AGILITY DEGREES
GREE LIST OF AGILE ACTIVITY AND SECURITY ACTIVITY that have an
agility reduction that is less than the ACCEPTABLE AGILITY
REDUCTION FACTOR (Sonia et al., 2014).
AGILE SECURE DEVEL- Agile software development with explicitly integrated SECURITY
OPMENT METHOD ACTIVITIES.

10
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

VI. Related work

A lot of research has been perfomed in this area by several authors.
Sonia have published several papers in this field of research, with different co-authors. They
have created a framework that determines the compatibility between a security activity and an
agile activity (Sonia & Singhal, 2012), which is used in an altered form in the discussed paper.
In another paper the authors present a framework that introduces security activities in agile
development using a hybrid technique for requirements elicitation (Sonia & Singhal, 2011).
Beznosov and Kruchten (2004) identified several security activities that are compatible with
agile development. Requirements that have to be fulfilled to integrate a security technique into
an agile method were defined by Siponen, Baskerville, and Kuivalainen (2005). Several secure
development methods have been compared to identify commonalities and propose changes to
better align these methods with agile development (de Win et al., 2009). Baca and Carlsson
(2011) analysed the impact of several secure development methods like Microsoft SDL and
Cigatel touchpoints. Based on a case study performed at Ericsson AB the parts from the secure
development methods were extracted that were considered as unobtrusive by the developers.
Ayalew, Kidane, and Carlsson (2013) performed a systematic literature research on this topic as
well as a survey. The goal of this study is to identify the most compatible and beneficial security
activities from the current waterfall methods. It concluded that none of the current secure software
development methods are fully compatible with agile development methods.
The discussed paper of Sonia et al. (2014) differs from previous research because it gives an inte-
grated security-engineering process instead of a generalized approach. Previous research suggests
methods to integrate security activities with agile activities on an abstracted and generalized level.
This paper integrates two specific methods: the Extreme Programming agile development method
(Beck, 2000) and the OWASP CLASP method (Foundation, 2006). OWASP CLASP was chosen
because it is more lightweight and flexible according to de Win et al. (2009), thus easier to integrate
with an agile development method. The proposed method was tested using the developed tool at
a software development company and a university. Afterwards thirty-two participants were asked
to fill in a survey. Their feedback indicated that the usage of this framework and the accompanying
tool was considered useful by the developers.

11
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

VII. Template
This section shows a template for the AGILE FEATURE GLOBAL WEIGHT TABLE. As explained
in the Concept table above, this AGILE FEATURE GLOBAL WEIGHT TABLE contains all AGILE
FEATURES and corresponding AGILE sub-FEATURES with their corresponding weights.
The first column contains the names of Agile Features that were identified in the Identify
agile (sub)features step of the technique. The relative weights for each Agile Feature (RA1) can
be found in the Create normalized matrix step of the technique. The third column (Sub-features)
contains the names of all Agile sub-features, grouped by parent Agile Feature. The relative weights
(RA2) column can also again be filled in from the values present in the normalized matrix that has
been created. Finally the global weights are filled in according to the Calculate global weights
step. The global weight of sub-feature #2.1 of feature 2 is calculated using the following formula:
Global Weight = RA12 RA22.1
where RA12 is the relative weight of feature 2 and RA22.1 is the relative weight of sub-feature #2.1

Table 4: AGILE FEATURE GLOBAL WEIGHT TABLE template.

Relative Relative Global Weights

Desired Agility Sub-Features
Weights (RA1) Weights (RA2) (RA1*RA2)
Features
<Agile <Sub-feature #1.1> RA21.1 RA11 RA21.1
RA11
Feature #1> <Sub-feature #1.2> RA21.2 RA11 RA21.2
<Agile Feature RA12 RA22.1 RA12 RA22.1
#2>
<Agile <Sub-feature #n.1> RA2n.1 RA1n RA2n.1
RA1n
Feature #n> <Sub-feature #n.2> RA2n.2 RA1n RA2n.2

12
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

VII.I. Filled in template

This section shows a filled in example of the above template. This example is taken from the paper
by Sonia et al. (2014).

Table 5: Filled in example of AGILE FEATURE GLOBAL WEIGHT TABLE.

Relative Relative Global Weights

Desired Agility Sub-Features
Weights (RA1) Weights (RA2) (RA1*RA2)
Features
Change in project plans 0.505 0.140
Flexibility Changes in team mem- 0.064 0.018
0.277
(F) bers
Changes to new technol- 0.288 0.080
ogy
Changes at any later stage 0.143 0.039
even in work Product
Simplicity 0.258 0.051
Leanness (L) 0.201 Quality Improvement 0.637 0.128
Economical 0.105 0.021
Documentation 0.119 - 1 0.119
Level (DL)
Iterative behaviour 0.390 0.060
Development Incremental towards con- 0.390 0.060
0.155
style (DS) tinuous improvement
Rapid execution 0.152 0.024
Informal 0.068 0.011
Team Cross functional abil- 0.60 0.059
Structure 0.099 ity (Self Organized
and Disciplined teams)
behaviour Competency 0.20 0.020
(TS) Trust level and coopera- 0.20 0.020
tion
Automation 0.032 - 1 0.032
Level (AL)
Learning and 0.022 Continuous training and 1 0.022
knowledge development of business
development people
(LK)
Reusability (R) 0.016 - 1 0.016
Role of Customer satisfaction 0.045 0.004
0.079
customer Customer interaction and 0.055 0.004
(CI) enrichment

References
Al-Ahmad, W. (2011). Building secure software using XP. IJSSE, 2(3), 6376.
Ayalew, T., Kidane, T., & Carlsson, B. (2013). Identification and evaluation of security activities
in agile projects. In H. R. Nielson & D. Gollmann (Eds.), Secure IT systems - 18th nordic

13
FISA-XP: an agile-based integration of security activities with extreme programming S. Klock

conference, nordsec 2013, Ilulissat, Greenland, october 18-21, 2013, proceedings (pp. 139153).
Berlin: Springer.
Baca, D., & Carlsson, B. (2011). Agile development with security engineering activities. In D. Raffo,
D. Pfahl, & L. Zhang (Eds.), International conference on software and systems process, ICSSP 2011,
Honolulu, HI, USA, may 21-22, 2011, proceedings (pp. 149158). New York, NY: ACM.
Beck, K. (2000). Extreme programming explained: embrace change. Boston, MA: Addison-Wesley
Professional.
Beznosov, K., & Kruchten, P. (2004). Towards agile security assurance. In C. Hempelmann &
V. Raskin (Eds.), Proceedings of the new security paradigms workshop 2004, september 20-23, 2004,
Nova Scotia, Canada (pp. 4754). New York, NY: ACM.
de Win, B., Scandariato, R., Buyens, K., Grgoire, J., & Joosen, W. (2009). On the secure
software development process: Clasp, sdl and touchpoints compared. Information and
software technology, 51(7), 11521171.
Foundation, O. (2006). Owasp clasp project. Retrieved 2015-02-11, from https://www.owasp.org/
index.php/Category:OWASP_CLASP_Project
Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 2835.
Keramati, H., & Mirian-Hosseinabadi, S. (2008). Integrating software development security
activities with agile methodologies. In The 6th ACS/IEEE international conference on computer
systems and applications, AICCSA 2008, Doha, Qatar, march 31 - april 4, 2008 (pp. 749754). New
York, NY: IEEE Computer Society.
Saaty, T. L. (1994). How to make a decision: the analytic hierarchy process. Interfaces, 24(6), 1943.
Siponen, M. T., Baskerville, R., & Kuivalainen, T. (2005). Integrating security into agile development
methods. In J. J. Nunamaker & R. Briggs (Eds.), 38th hawaii international conference on system
sciences (HICSS-38 2005), CD-ROM / abstracts proceedings, 3-6 january 2005, Big Island, HI, USA
(pp. 185a185a). Washington, DC: IEEE Computer Society.
Sonia, & Singhal, A. (2011). Development of agile security framework using a hybrid technique
for requirements elicitation. In S. Unnikrishnan, S. Surve, & D. Bhoir (Eds.), Advances in
computing, communication and control (pp. 178188). Berlin: Springer Berlin Heidelberg.
Sonia, & Singhal, A. (2012, February). Integration analysis of security activities from the perspective
of agility. In J. E. Guerrero (Ed.), Agile india (agile india), 2012 (pp. 4047). New York, NY:
IEEE Computer Society.
Sonia, Singhal, A., & Banati, H. (2014). FISA-XP: an agile-based integration of security activities
with extreme programming. ACM SIGSOFT Software Engineering Notes, 39(3), 114.
van de Weerd, I., & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design
methods. In M. Syed & S. Syed (Eds.), Handbook of research on modern systems analysis and
design technologies and applications (pp. 3558). Hershey: Idea Group Publishing.

14