2016-02-03 research seminar

TallinnUniversity 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

2
Agenda
 Introduction
 Current Status of The Research
 Research Methodology
 Future Research Activities
 Bibliography

3
Introduction

4
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.

5
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/

6
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

7
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?

8
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).

9
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?

10
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.

11
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

12
 Collective-ownership
 Coding standards
 40-hour-week
 Continuous-integration
 Refactoring
 Testing
 Figure 1 shows agile practices.

13

14
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

15
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.

16
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

17
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

18
Inductive & Deductive Case Study [9]

19
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.

20
Table I: Themes and Themes description
Theme 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

21
 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.

22
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.

23
 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

24

25
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/

26
 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

27
 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.

28
Theme / Code Phases Type Value
1.Privileges & Responsibilities
Customer 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.5
Customer 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.5
Developer work based on customer interest i Abs 1

292. Limitation of Privileges
Different 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 3
Frequent 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

303. Developer Attention
Inconsistent 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.5
Customer 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 7
Customer 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

314. Software Simplicity
Different pairs & frequent changes to software i Abs 10
No problem p+c Abs 8
If frequent & inconsistence changes c Cond 6
No problem c+p Abs 4
If pair don’t follow the standards p+i Cond 3.75
If developers have different idea p Cond 3
If the scope of software is larger i Cond 3
If frequent & inconsistence changes i Cond 2.5
Developers work on customer interest c Abs 2
If each pair work on separate part p Cond 2
Lack of proper documentation i+p Abs 1.5
If not revise the structure i+p Cond 0.75
If order of integration is not logical i Cond 0.5

325. System-wide View and Control
Different pairs & unstable status of software i+p Abs 18
Frequent changes & separate integration i+c Abs 16
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 3
If standards are not followed p Cond 2.5
If too much changes in short time p Cond 1.5
Customer has low technical knowledge c Abs 1
If pairs don’t take responsibility for system-wide view p Cond 1

33
RESULTS (STILL WORKING ON IT)
 Comparing the activities of customer and
developers with the security principles.
 Design Principles & Hypotheses
 Hypothesis & Themes
 Themes & Coding

34
 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.

35
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.

36
 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.

37
 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.

38
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.

39
 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.

40
 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.

41
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.

42
 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.

43
 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.

44
 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.

45
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.

46
 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.

47
 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.

48
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

49
 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.

50
 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.


51
CONCLUSION AND FUTURE WORK

52
Limitations and Future Work

53
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.

54
 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
 We address this gap by posing the following
research question:

55
 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?

56
 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.

57

58 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 Done
Research Question Done
Conducting the literature 1 March, 2016
Case Study Design 20 March, 2016
Data Collection 30 April, 2016
Data Analysis 25 May, 2016
Finalizing the paper 20 June, 2016
Journal Paper (Title will be specified after
completing the conference paper)
Gap Detection 10 July, 2016
Research Question 20 July, 2016
Conducting the related literature
review
31 August, 2016
Case Study Design 20 September, 2016
Data Collection 10 November, 2016
Data Analysis 15 December, 2016
Finalizing the paper 10 January, 2017
Writing the Thesis Introduction and Concepts 10 February, 2017
Related Works 20 March, 2017
Methodology 30 April, 2017
Analysis 31 May, 2017
Conclusion 10 June, 2017
Reviewing the thesis 10 July, 2017
Finalizing the thesis 1 August, 2017
Defense of the Thesis 1 October, 2017

59
REFERENCES
1. 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.

60
8. 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.

61
16. 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.

62
24. 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.

2016-02-03 research seminar

More Related Content

What's hot

Viewers also liked

Similar to 2016-02-03 research seminar

More from ifi8106tlu

Recently uploaded

2016-02-03 research seminar