Developing Secure Software - in an Agile Process

211 Pages·2012·4.68 MB·English

SD
o
e
fv
aBStract te
wl
Background: Software developers are facing in- a real industry setting. As secondary methods for
o
creased pressure to lower development time, re- data collection a variety of approaches have been a Developing Secure Software
p
r
lease new software versions more frequent to used, such as semi-structured interviews, work- i
en - in an agile proceSS
customers and to adapt to a faster market. This shops, study of literature, and use of historical data -g
new environment forces developers and companies from the industry. i
nS
to move from a plan based waterfall development
e
a
process to a flexible agile process. By minimizing Results: The security engineering best practices c
n
the pre development planning and instead increa- were investigated though a series of case studies. u
sing the communication between customers and The base agile and security engineering compati- ar
ge
developers, the agile process tries to create a new, bility was assessed in literature, by developers and

i
more flexible way of working. This new way of in practical studies. The security engineering best l
e
working allows developers to focus their efforts on practices were group based on their purpose and

p
the features that customers want. With increased their compatibility with the agile process. One well
r Dejan Baca
connectability and the faster feature release, the known and popular best practice, automated static
o
security of the software product is stressed. To de- code analysis, was toughly investigated for its use-
c
velop secure software, many companies use secu- fulness, deployment and risks of using as part of e
rity engineering processes that are plan heavy and the process. For the risk analysis practices, a novel S
S
inflexible. These two approaches are each others approach was introduced and improved. As such, a
opposites and they directly contradict each other. way of adapting existing practices to agile is pro-
Objective: The objective of the thesis is to evaluate posed.
how to develop secure software in an agile process.
In particular, what existing best practices can be Conclusion: With regard of agile and security eng-
incorporated into an agile project and still provide ineering we did not find that any of the investigated
the same benefit if the project was using a water- processes was agile compatible. Agile is reaction
fall process. How the best practices can be incor- driven that adapts to change, while the security
porated and adapted to fit the process while still engineering processes are proactive and try to pre-
measuring the improvement. Some security engi- vent threats before they happen. To develop secure
neering concepts are useful but the best practice is software in an agile process the developers should
not agile compatible and would require extensive adopt and adapt key concepts from security engi-
adaptation to integrate with an agile project. neering. These changes will affect the flexibility of
the agile process but it is a necessity if developers
Method: The primary research method used th- want the same software security state as security
roughout the thesis is case studies conducted in engineering processes can provide.

D
e
ja
n

B
a
c
a
Blekinge Institute of Technology
Doctoral Dissertation Series No. 2012:05
2
0 School of Computing
ISSN 1653-2090 1
2
2012:05 ISBN 978-91-7295-229-4 :05
Developing Secure Software
- in an Agile Process
Dejan Baca

Blekinge Institute of Technology doctoral dissertation series
No 2012:05
Developing Secure Software
- in an Agile Process
Dejan Baca
Doctoral Dissertation in
Computer Science
School of Computing
Blekinge Institute of Technology
SWEDEN
2012 Dejan Baca
School of Computing
Publisher: Blekinge Institute of Technology,
SE-371 79 Karlskrona, Sweden
Printed by Printfabriken, Karlskrona, Sweden 2012
ISBN: 978-91-7295-229-4
ISSN 1653-2090
urn:nbn:se:bth-00525
”Donotworry,itisnon-destructivesecuritytesting. Yourweeklong
stresstestwillnotbeeffectedbyit.”
Mylastwordsbeforegettingbannedfromthetestlab.
–DejanBaca
v
vi
Abstract
Background:Softwaredevelopersarefacingincreasedpressuretolowerdevelopment
time,releasenewsoftwareversionsmorefrequenttocustomersandtoadapttoafaster
market. Thisnewenvironmentforcesdevelopersandcompaniestomovefromaplan
basedwaterfalldevelopmentprocesstoaflexibleagileprocess. Byminimizingthepre
development planning and instead increasing the communication between customers
and developers, the agile process tries to create a new, more flexible way of work-
ing. Thisnewwayofworkingallowsdeveloperstofocustheireffortsonthefeatures
thatcustomerswant. Withincreasedconnectabilityandthefasterfeaturerelease, the
securityofthesoftwareproductisstressed. Todevelopsecuresoftware,manycompa-
niesusesecurityengineeringprocessesthatareplanheavyandinflexible. Thesetwo
approachesareeachothersoppositesandtheydirectlycontradicteachother.
Objective:Theobjectiveofthethesisistoevaluatehowtodevelopsecuresoftware
inanagileprocess. Inparticular,whatexistingbestpracticescanbeincorporatedinto
an agile project and still provide the same benefit if the project was using a waterfall
process. How the best practices can be incorporated and adapted to fit the process
whilestillmeasuringtheimprovement. Somesecurityengineeringconceptsareuseful
butthebestpracticeisnotagilecompatibleandwouldrequireextensiveadaptationto
integratewithanagileproject.
Method: Theprimaryresearchmethodusedthroughoutthethesisiscasestudies
conductedinarealindustrysetting.Assecondarymethodsfordatacollectionavariety
ofapproacheshavebeenused,suchassemi-structuredinterviews,workshops,studyof
literature,anduseofhistoricaldatafromtheindustry.
Results: Thesecurityengineeringbestpracticeswereinvestigatedthoughaseries
ofcasestudies. Thebaseagileandsecurityengineeringcompatibilitywasassessedin
literature, by developers and in practical studies. The security engineering best prac-
ticesweregroupbasedontheirpurposeandtheircompatibilitywiththeagileprocess.
Onewellknownandpopularbestpractice,automatedstaticcodeanalysis,wastoughly
investigatedforitsusefulness,deploymentandrisksofusingaspartoftheprocess.For
theriskanalysispractices,anovelapproachwasintroducedandimproved. Assuch,a
wayofadaptingexistingpracticestoagileisproposed.
Conclusion: With regard of agile and security engineering we did not find that
any of the investigated processes was agile compatible. Agile is reaction driven that
adapts to change, while the security engineering processes are proactive and try to
prevent threats before they happen. To develop secure software in an agile process
thedevelopersshouldadoptandadaptkeyconceptsfromsecurityengineering. These
changeswillaffecttheflexibilityoftheagileprocessbutitisanecessityifdevelopers
wantthesamesoftwaresecuritystateassecurityengineeringprocessescanprovide.
vii
viii
Acknowledgements
First and foremost, I would like to thank my supervisors PhD Lars-Ola Damm, Pro-
fessor Bengt Carlsson and Professor Lars Lundberg for their support, especially for
valuablefeedbackonpapersandotherresearchrelatedadvice.EspeciallyBengtCarls-
son for giving me a swift kick when I needed to write papers instead of starting new
experiments.
EricssonABgavemethechanceofconductingresearchandatthesametimestay-
ingintouchwiththeindustry. TheindustrialPh.Dstudentpositiongavemeaunique
opportunity to identify problems and evaluate them in a practical real world environ-
mentinsteadofatestlab. Aspecialthankstomyunitmanagers,whosebudgetIwas
constancy breaking; Maria Larsson, PerOlof Bengtsson, Sven Johansson and Daniel
Borg.
Blekinge Institute of Technology provided me with colleagues and friends from
all over the world that create a diverse environment of ideas and culture. I would
especiallyliketothankKaiPetersenwhomIwrotemanyofmypaperswith. Martin
Hylerstedtwhoalwaysagreedtoreadmypapersandhelpmewithproofreading.Anton
Borg,PetarJersick,MartinBoldt,SamirehJalaliandSvetlanaZivanovicforbeingmy
friendsandcolloguesatBTHduringmytimethere.
Finally,Iwouldliketothankmyfamilyandfriendsforputtingupwithmedespite
neglectingthemwhenhavingahighworkload.
ThisworkwasfundedjointlybyEricssonABandtheKnowledgeFoundationinSwe-
denunderaresearchgrantfortheresearchschoolSAVE-ITfromMa¨lardalensuniver-
sity.
ix