2016-02-03 research seminar

63
Tallinn University February 3, 2016 1 Towards Secure Agile Agent-Oriented System Design Hassan Adelyar, PhD Student, Tallinn University Supervisor: Alexander Norta PhD., Senior Researcher of Tallinn University of Technology February 3, 2016

Upload: ifi8106tlu

Post on 12-Jan-2017

156 views

Category:

Education


1 download

TRANSCRIPT

Page 1: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20161

Towards Secure Agile Agent-Oriented System Design

Hassan Adelyar, PhD Student, Tallinn University

Supervisor: Alexander Norta PhD., Senior Researcher of Tallinn University of Technology

February 3, 2016

Page 2: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20162 Agenda

Introduction Current Status of The Research Research Methodology Future Research Activities Bibliography

Page 3: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20163

Introduction

Page 4: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20164 Research Objectives

The main objective of our PhD research is: To Enhance agile software development

approaches for secure digital services using agent-oriented modeling techniques.

The enhancement we study through the adaptation of agile practices for the development of secure digital services.

Page 5: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20165 Agile Software Development Methodology

A common software development methodology. Incremental development method, each increment

contain new functionality. The focus of agile is on developers and customers1 The objective of agile is to produce working

software quickly and accept changes throughout its lifecycle1

1 http://www.agilemanifesto.org/

Page 6: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20166 Software Security [1]• Un-exposure of software execution to unauthorized.• Un-exposure of code to unauthorized.Confidentiality

• Adversaries should not be able to tamper with a program and cause sub-sequent execution to produce incorrect output.

• Software work accordance to its designer desire

Integrity

Availability

• The availability and integrity of the identity of the person who performed an operation.Accountability

• Be available when needed• Execute in a predictable way• Deliver results in a predictable time

frame

Page 7: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20167 Research Questions How to enhance agile practices for holistically

integrating security into digital services using agent-oriented modeling? How to identify security challenges during the

changes to software? How to isolate / avoid security challenges from

XP practices? How to incorporate security benefits into XP

practices?

Page 8: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20168 Current Status Courses related to our PhD Study (50 Credits) Analysis of the Previous Researches Research methodology (Case study) First Publication:

Towards Secure Agile Agent-Oriented System Design, symposium paper in IEEE digital library (March 2015).

Second Publication: Towards Secure Agile Software Development Process

(Almost completed).

Page 9: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20169 Second Publication Towards Secure Agile Software Development

Process How to identify security challenges during

changes to software? What are security challenges of response to

changes based on security principles? What are most serious security challenges in

agile software development? Which agile practices have more security

challenges?

Page 10: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201610 Aim Our aim is to analyze agile practices in order to

identify security challenges based on the security principles / design principles defined in [10].

Experience of practitioners show that design principles can guide the design and implementation of software without flaws [10].

The process of agile software development can be evaluated by comparing the activities of customer and developers with the design principles.

Page 11: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201611 Agile Practices The cornerstone of agile methodologies is the

practices that help to produce software quickly. The twelve practices of agile are as follows: Planning On-site customer Metaphor Small-releases Simple-design Pair-programming

Page 12: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201612

Collective-ownership Coding standards 40-hour-week Continuous-integration Refactoring Testing

Figure 1 shows agile practices.

Page 13: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201613

Page 14: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201614 Security Principles / Design Principles The following is the list of security principles:

Separation of Privileges Least Privileges Fail-safe Defaults Economy of Mechanism Psychological Acceptability Open Design Least Common Mechanism Complete Mediation

Page 15: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201615 Related Work Literature detects deficiencies in agile

methodologies due to the unavailability of security [2], [12], [20], [19].

Research results exits in the domain, but these research works lack a suitable approach to identify security challenges during changes-to-software.

Page 16: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201616 Research Methodology : CASE STUDY We choose a case-study based research method A case study consists of these main phases [9]:

Case-study design, Data collection procedure, Data analysis procedure, Reporting

Page 17: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201617 Case Study Design Case for study

Agile Software development process (Customer & developer activities through agile practices)

Four software development teams in Kabul city Subject for study

Security challenges in agile practices Deductive case study / Explanatory case study

Starts with existing theories, Sets out hypotheses for the research Evidence collection Analysis

Page 18: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201618 Inductive & Deductive Case Study [9]

Page 19: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201619 Hypotheses

(i) Continuous changes-to-software make the process of separation of privilege difficult to implement.

(ii) Continuous changes-to-software increase the privileges for customer and developers.

(iii) Continuous changes-to-software effect negatively on the developer attention.

(iv) Continuous changes-to-software increase the complexity of software.

(v) Continuous changes-to-software make it difficult to control the overall view of the software.

Page 20: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201620 Table I: Themes and Themes descriptionTheme Theme Description

Privileges & Responsibilities

Provide different conditions in order to differentiate privileges

Limitation of Privileges

Only necessary privileges, minimize interaction, & small components

Attention & Caution Lack of access as default, deny access during mistake, & attention and caution

Software Simplicity Make the design of software simple, small and easy

System-wide View & Control

Minimize common mechanism, check every access and deny access during mistake

Page 21: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201621

Hypotheses, derived from the security principles, to guide the interview questions

The result of analysis, either confirm or reject the hypotheses, which leads to either confirmed or rejected theories about agile security based on the security principle.

Page 22: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201622 Data Sources Interview as a data collection method Interviews with 13 software developers in four

different teams All four teams use agile methodology and each

member of the team has at least experience of three software development.

Page 23: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201623

The same questions are asked about the three main phases of agile practices, planning-game, pair-programming and continuous integration.

The interview questions has unstructured format. Interview session lasts roughly 45 minutes to one

hour. Audio recorded into WMA files.

Interview Questions

Page 24: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201624

Page 25: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201625 Analysis procedure Transcribing Coding – Nvivo1 as a software tool Themes to group the codes Hypotheses & Themes Evaluation of codes Code Attributes

Phases Type

1 http://www.qsrinternational.com/

Page 26: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201626

We use a simple formula to evaluate what codes have more value for analysis.

Sources: The number of interviewees mention the code

Phases: The availability of code in the three main phases

Type: Shows if a code is absolutely or conditionally mentioned by the interviewees

Code-value = (Sources * Phases) * Type

Page 27: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201627

Possible values for phase: 1, 1.5, 2, 2.5 and 3 Possible value for type: Abs (1) or Cond (0.5) Codes are sorted based on their value Review every theme separately and draw

conclusions Codes attributes abbreviation:

C: Planning-game P: Pair-programming i: Continuous-integration

All themes and codes are presented in table II.

Page 28: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201628Theme / Code Phases Type Value

1.Privileges & ResponsibilitiesCustomer put responsibility on developers c+p+i Abs 32.5

Privilege & responsibilities of developers are not clearly documented

p+c+i Abs 30

Different pairs & frequent changes to software i+p Abs 20

Different pairs cause unexpected errors p+i Abs 14

Customer give unclear & unstable requirements c Abs 12

If tasks are not clearly specified i+c+p Cond 7.5Customer is not well familiar with technology c Abs 7

If software is large with frequent changes i Cond 5.5

If developers don’t make comments and not work honestly

p+i Cond 5.25

If developers have different ideas & knowledge level

p Cond 5

If standards are not followed i+p Cond 2.5Developer work based on customer interest i Abs 1

Page 29: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 2016292. Limitation of PrivilegesDifferent pairs & frequent changes make difficult to limit the privileges

i+p Abs 20

Different pairs cause unexpected errors p+i Abs 14

Developers work on customer interest & customer change idea frequently

c Abs 12

If tasks / responsibility are not specified p+i Cond 9

Frequent changes of pairs & lack of documentation

p+c Abs 7.5

If proper documentation is not provided c+p Cond 4

No problem i Abs 3Frequent changes & repetition of work c Abs 3

If pairs don’t have good relationship between them

p Cond 2

If standards are not followed p Cond 1

Page 30: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 2016303. Developer AttentionInconsistent feedback, idea & priority by customer cause repetition of work

c+i Abs 22

Different pairs & frequent changes to software i+p Abs 20

Different pairs & frequent changes to software p+i Abs 14

Customer want software quickly c+p Abs 13.5Customer change requirements & our focus is on changes

c Abs 9

Repetition of work & pressure on developers i+c Abs 8

If we have less time p+c Cond 7Customer can’t explain data protection requirements c Abs 5

If I am not sure for my idea and depend on other ideas p Cond 4.5

If I express my idea and other write code p Cond 3

If working in large software for long time with frequent changes

i Cond 3

If software has error that need to be fixed i Cond 2

Page 31: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 2016314. Software SimplicityCustomer give unclear & unstable requirements c Abs 12

Different pairs & frequent changes to software i Abs 10

No problem p+c Abs 8If frequent & inconsistence changes c Cond 6

No problem c+p Abs 4If pair don’t follow the standards p+i Cond 3.75If developers have different idea p Cond 3If the scope of software is larger i Cond 3If frequent & inconsistence changes i Cond 2.5

Developers work on customer interest c Abs 2

If each pair work on separate part p Cond 2Lack of proper documentation i+p Abs 1.5If not revise the structure i+p Cond 0.75If order of integration is not logical i Cond 0.5

Page 32: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 2016325. System-wide View and ControlDifferent pairs & unstable status of software i+p Abs 18

Frequent changes & separate integration i+c Abs 16

Customer give unclear & unstable requirements c Abs 12

Customer determine the scope & priority c+i Abs 12

If pairs don’t know the work of others p+i Cond 7

Setting priority by customer make difficult to control the sequential logic of software

i+c Abs 6

Frequent changes also change the structure c+i Abs 4

We loss the overall view for small components & details p Abs 3

If the scope of software is larger i Cond 3If standards are not followed p Cond 2.5If too much changes in short time p Cond 1.5Customer has low technical knowledge c Abs 1

If pairs don’t take responsibility for system-wide view p Cond 1

Page 33: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201633 RESULTS (STILL WORKING ON IT) Comparing the activities of customer and

developers with the security principles. Design Principles & Hypotheses Hypothesis & Themes Themes & Coding

Page 34: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201634

Software security needs a variety of security mechanisms from requirement, implementation, testing and the using environment.

We are focusing on one aspects, which is the development process specifically the customers and developer activities.

Following is the result for answering our research questions.

Page 35: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201635 Theme: Privileges and Responsibility Separation of Privileges

The secure software development process need to verify the identity of customer and developers based on their privileges and responsibilities.

Codes: The first high ranked code indicates the unclear

privileges and responsibilities between customers and developers. This can compromise the “accountability attribute” of security.

Page 36: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201636

The privileges & responsibilities between developers are not clearly documented.

This problem is mentioned in the three main phases and the highest rate of the problem is in the planning-game practice of agile.

The second highest ranked problem is the frequent changes to software by different pairs that make difficult to verify the identity of the developer.

For security purposes, controlling who make changes to software is very essential.

Page 37: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201637

This problem relates to the pair-programming and continuous-integration phases of agile.

The high rate for this problem belongs to the pair-programming phase.

Page 38: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201638 Theme: Limitation of Privileges Least Privileges

The objective for developing secure software is to only provide the necessary privileges for customer and developers.

If this principle is properly applied during the development process of software then, if a question arises related to misuse of a privilege the number of entity that need to be audited is minimized [10].

Violation of this principle makes access control difficult and can compromise all the related attributes of software security.

Page 39: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201639

Codes: The first high ranked code different pairs with

different knowledge level in agile team while making frequent changes to the software is a main challenge for the limitation of their privileges.

This challenge relates to the pair-programming and continuous-integration phases and the highest rate of the problem is in the continuous-integration phase.

Page 40: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201640

The second high ranked challenge is the dependency of developers on the unstable ideas of customers that extend the privileges of customers.

This problem belongs to the planning-game phase of agile.

Frequent changes of pairs and members of the pairs also make problem for the limitation of the developer’s privileges in the pair-programming and continuous-integration phases.

Page 41: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201641 Theme: Developers Attention Fail-safe Defaults:

The Theme emphasizes on the developers attention and caution during the whole software development process.

Certifying that the software is actually implemented as intended, especially for security consideration, needs precise attention.

Agile “40-hour practice” is intended for this but based on our collected data in Table II there are other activities in the process that negatively effect on the developer attention.

Page 42: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201642

Codes: The most mentioned code is the inconsistence

feedbacks, ideas and tasks priority by customer which causes repetition of work for the developers.

This repetition of work negatively affect the developers attention because the unstable ideas of customers requires more changes and repetition of work which cause pressure on developers and that the developers focus on changes.

Page 43: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201643

This problem belongs is related to the planning-game and continuous-integration phases of agile.

The second high rate code is different pairs and frequent changes to software under time pressure which also indicate the problem for developers attention.

This problem recounts to the pair-programming and continuous-integration phases of agile and the high rate of the problem belongs to the continuous-integration phase of agile.

Page 44: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201644

Participants also mentioned that when they depend on other developer ideas in the pair or they are not writing code during pair-programming practice then their attention is lower.

For some developers long time working in large software with frequent changes is another problem for their attention.

These problems relate to the pair-programming practice of agile.

Page 45: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201645 Theme: Software Simplicity Economy of Mechanism + Open Design +

Psychological Acceptability For applying the protection mechanism

effectively, the design must be simple and small. Because, techniques such as line-by-line

inspection for finding security flaws in the code of software are necessary.

For such techniques to be successful, a small and simple design is essential.

Page 46: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201646

Codes: The interviewees confirm that the unstable

requirements from customer need frequent and inconsistence changes to software which increases the complexity of software.

This challenge belongs to the planning-game practice of agile.

The second highest ranked code, which shows the increase of complexity to software in this Theme, is working of different pairs on the software and frequent changes by these pairs.

Page 47: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201647

This problem relate to the continuous integration practice of agile.

This code is also backed by another code in this Theme which states that developers work on the customer interest and frequent changes in customer ideas cause illogical sequence of integration to the software which increases the complexity of software.

This code belongs to the planning-game phase of agile.

Page 48: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201648 Theme: System-wide View & Control Complete Mediation + Least Common Mechanism:

The protection and authorization mechanisms for developing secure software required to prevent all unauthorized activities during software development.

In other words, the effect of every change, need to be checked on the whole software.

This kind of requirements has negative form which make hard to prove that this negative requirements have been achieved.

It require from the developers to demonstrate that every possible threat has been anticipated during the development process.

Page 49: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201649

Thus an expansive view of the problem is most appropriate to ensure that no gaps appear in the whole software during the development process.

Codes: The highest codes in the corresponding Theme shows

that different pairs and frequent changes and separate integration make the status of software unstable which make difficult for developers to keep the system-wide view of software.

This challenge relates to the planning-game, pair-programming and continuous-integration phases of agile.

Page 50: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201650

The second highest ranked code in this Theme is that customer gives unclear and unstable requirements.

This is also backed by the third highest ranked code that interviewees indicate that in agile the scope of software and priority of tasks are determine by customers, which make difficult for developers to control the sequential logic of software.

This challenge belongs to the planning-game and continuous-integration phases of agile.

Page 51: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201651 CONCLUSION AND FUTURE WORK

Page 52: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201652 Limitations and Future Work

Page 53: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201653 Future Research Activities Raising Security Awareness of Agile Software

Developers Using AAOM Method One of the main important reasons for lack of

security of agile methodology is security awareness among software developers.

Software developers as human use agile practices in order to produce software and it make a kind of socio-technical system.

Page 54: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201654

Thus secure Agile Agent-Oriented Modeling (AAOM) can be used to smoothly raise security awareness of developers.

Evaluation of AAOM method for raising security awareness of developers in an agile software development process.

We address this gap by posing the following research question:

Page 55: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201655

How suitable is AAOM for raising security awareness of developers in agile software development? What are implications of raising security

awareness among developers using AAOM method? What is the level of acceptance among developers

for using AAOM method to raise security awareness of agile developers?

Which agile practices can be enhanced by AAOM method to raise developer’s security awareness?

Page 56: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201656

This study aims to evaluate the suitability of using AAOM method for raising security awareness of developers by using agile software methodologies.

The results of this study will enable developers to smoothly identify and improve security of agile software development.

Page 57: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201657

Page 58: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201658 Main Activities Sub Activities Completion Date

Workshop Paper (Towards Secure Agile Software Development

  Almost Completed

Conference Paper (Raising Security Awareness of Agile Software Developers Using AAOM Method)  

Gap Detection DoneResearch Question DoneConducting the literature 1 March, 2016Case Study Design 20 March, 2016Data Collection 30 April, 2016Data Analysis 25 May, 2016Finalizing the paper 20 June, 2016

Journal Paper (Title will be specified after completing the conference paper)

Gap Detection 10 July, 2016Research Question 20 July, 2016Conducting the related literature review

31 August, 2016

Case Study Design 20 September, 2016Data Collection 10 November, 2016Data Analysis 15 December, 2016Finalizing the paper 10 January, 2017

Writing the Thesis Introduction and Concepts 10 February, 2017Related Works 20 March, 2017Methodology 30 April, 2017Analysis 31 May, 2017Conclusion 10 June, 2017Reviewing the thesis 10 July, 2017Finalizing the thesis 1 August, 2017

Defense of the Thesis   1 October, 2017     

Page 59: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 201659 REFERENCES1. Algirdas A., Jean-Claude Laprie, Brian Randell, and Carl Landwehr, (2004). Basic

Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transaction on Dependable and Secure Computing.

2. Bejan Baca. (2011). Agile Development with Security Engineering Activities. ACM, USA.

3. Beznosov K., (2003). Extreme Security Engineering: On Employing XP Practices to Achieve “Good Enough Security” without defining it, ACM Press.

4. Chandrabose A. and Alagarsamy K., (2011). Security Requirements Engineering – A Strategic Approach. International Journal of Computer Applications, Madurai, India.

5. Charette R., the Decision is in: Agile versus Heavy Methodologies. Agile development and Project Management, Cutter Consortium, Vol. 2 (19), February 2004.

6. Daniel Owens, Integrating Software Security into the Software Development Lifecycle System Securities. San Diego, CA 92123, USA.

7. Emine G. Aydal, and Richard F., (2006). Security Planning and Refactoring in Extreme Programming. Department of Computer Science, University of York, UK.

Page 60: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 2016608. Eystein Mathisen, and Terje Fallmyr, Using business process modelling to reduce

the effects of requirements changes in software projects.9. Gustav Boström, and Beznosov K., Extending XP Practices to Support Security

Requirements Engineering. University of British Columbia, Canada.10. Haley C. B., Laney R., (2008). Security Requirements Engineering: A Framework

for Representation and Analysis. 11. Imran Daud. (2010). Secure Software Development Model: A Guide for Secure

Software Life Cycle. Proceeding of the International MultiConference of Engineers and Computer Scientists, IMECS Hong Kong.

12. Imran Ghani and Adila Firdaus, (2013). Role-based Extreme Programming (XP) for Secure Software Development. University Teknologi Malaysia, Skudai, Malaysia.

13. Imran Ghani and Izzaty Yasin, (2013). Software Security Engineering in Extreme Programming Methodology: A Systematic Literature Review. Universiti Teknologi Malaysia, Skudai, Johor, Malaysia.

14. Johan Peeters, Agile Security Requirements Engineering.15. Ovidiu Vermesan & Peter Friess Internet of Things – From Research and

Innovation to Market Deployment, River Publishers, Chicago, USA, 2014.

Page 61: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20166116. Per Runeson, Martin Host, and Austen Rainer, (2012), Case Study Research in

Software Engineering. John Wiley & Sons, Inc., Hoboken, New Jersey, USA.17. Salini P. and Kanmani S., (2010). A Model Based Security Requirements

Engineering Framework. International Journal of Computer Engineering and Technology (IJCET). Volume 1, Number 1.

18. Saltzer, Jerome H. & Schroeder, (1975). The Protection of Information in Computer Systems. 1278-1308. in Proceedings of the IEEE.

19. Sonia Archana Singhal, Jyoti Balwani, (2014). Analysing Security and Software Requirements using Multi-Layered Iterative Model. Delhi, India.

20. Steffen Bartsch. Practitioners’ Perspectives on Security in Agile Development. TZI, University of Bremen, Bremen, Germany.

21. Stephen Wood, and Chris Thomson, (2014). Successful extreme programming: Fidelity to the methodology or good team working? University of Leicester, Leicester, UK.

22. Tanel Tenso and Kuldar Taveter, Requirements Engineering With Agent-Oriented Models, Department of Informatics, Tallinn University of Technology.

23. Security Development Lifecycle for Agile Development, 2009 Microsoft Corporation.

Page 62: 2016-02-03 research seminar

Talli

nn U

nive

rsity

February 3, 20166224. Christopher Wood & Gregory Knox, (Guidelines for Agile Security Requirements

Engineering.25. George Grispos & William Bradley Glisson, Rethinking Security Incident

Response: The Integration of Agile Principles, AMCIS 2014.26. J. Wäyrynen, M. Bodén, and G. Boström, "Security Engineering and eXtreme

Programming: an Impossible marriage?," in Extreme programming and agile methodsXP/Agile Universe 2004, C. Zannier, H. Erdogmus, and L. Lindstrom, Eds. LNSC3134, Berlin: Springer-Verlag, 2004, pp. 117-128.

27. Adila Firdaus, Imran Ghani, and Nor Izzaty Mohd Yasin, Developing Secure Websites Using Feature Driven Development (FDD): A Case Study. Journal of Clean Energy Technologies, Vol. 1, No. 4, October 2013.

28. Abdullahi Sani, Adila Firdaus, Seung Ryul Jeong, Imran Ghani, A Review on Software Development Security Engineering using Dynamic System Method (DSDM). International Journal of Computer Applications (0975 – 8887) Volume 69– No.25, May 2013.

29. Ian Sommerville, SOFTWARE ENGINEERING Ninth Edition, Addison-Wesley, USA, 2011.

Page 63: 2016-02-03 research seminar

Thank You