Master Thesis

Software Engineering
Thesis no: MSE-2012-95
May 2012

A Framework for Security Requirements

Elicitation

Gibrail Islam and Murtaza Ali Qureshi

School of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona
Sweden

This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in

partial fulfillment of the requirements for the degree of Master of Science in Software
Engineering. The thesis is equivalent to 26 weeks of full time studies.

Contact Information:
Authors:
Gibrail Islam
E-mail: gibrailislam@gmail.com
Murtaza Ali Qureshi
E-mail: ma911262@gmail.com

University advisor:
DR. JRGEN BRSTLER
Department of Software Engineering and Computer Science

School of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona
Sweden

Internet
Phone
Fax

: www.bth.se/com
: +46 455 38 50 00
: +46 455 38 50 57
ii

ABSTRACT

Context.Securityconsiderationsaretypicallyincorporatedinthelaterstagesofdevelopmentasan
afterthought.Securityinsoftwaresystemisputunderthecategoryofnonfunctionalrequirements
bytheresearchers.Understandingthesecurityneedsofasystemrequiresconsiderableknowledge
of assets, data security, integrity, confidentiality and availability of services. Counter measures
againstsoftwareattacksarealsoasecurityneedofasoftwaresystem.Toincorporatesecurityinthe
earlieststages,i.e.requirementgathering,helpsbuildingsecuresoftwaresystemsfromthestart.For
that purpose researchers have proposed different requirements elicitation techniques. These
techniquesarecategorizedintoformalandinformaltechniquesonthebasisoffinitenessandclarity
inactivitiesofthetechniques.
Objectives.Limitationsofformalmethodsandlackofsystematicapproachesininformalelicitation
techniques make it difficult to rely on a single technique for security requirements elicitation.
Therefore we decided to utilize the strengths of formal and informal technique to mitigate their
weaknesses by combining widely used formal and informal security requirements elicitation
techniques. The basic idea of our research was to integrate an informal technique with a formal
techniqueandproposeaflexibleframeworkwithsomelevelofformalityinthesteps.
Methods.Weconductedasystematicliteraturereviewtoseewhicharethewidelyusedsecurity
requirementelicitationtechniques?asaprestudyforourthesis?Wesearchedonlinedatabasesi.e.
ISI, IEEE Xplore, ACM, Springer, Inspec and compendeX. We also conducted a literature review for
differentframeworksthatareusedinindustry,forsecurityrequirementelicitation.Weconducted
an experiment after proposing a security requirements elicitation Framework and compared the
resultfromtheFrameworkwiththatofCLASPandMisusecases.
Results.Twotypesofanalysiswereconductedonresultsfromtheexperiment:Vulnerabilityanalysis
andRequirementsanalysiswithrespecttoasecuritybaseline.Vulnerabilityanalysisshowsthatthe
proposed framework mitigates more vulnerabilities than CLASP and Misuse Cases. Requirements
analysiswithrespecttothesecuritybaselineshowsthattheproposedframework,unlikeCLASPand
Misusecases,coversallthesecuritybaselinefeatures.
Conclusions. The framework we have proposed by combining CLASP, Misuse cases and Secure
TROPOS contains the strengths of three security requirements elicitation techniques. To make the
proposedframeworkevenmoreeffective,wealsoincludedthesecurityrequirementscategorization
by Bogale and Ahmed [11]. The framework is flexible and contains fifteen steps to elicit security
requirements.Inadditionitalsoallowsiterationstoimprovesecurityinasystem.

Keywords:
Security
Framework, Security
SoftwareSecurity

Requirement
Elicitation
Requirement Engineering,

ACKNOWLEDGEMENTS

WearethankfultoAlmightyGodforgivinguscourageandstrengthtocompleteourthesis
withinsixmonthsoftime.
WewouldalsoliketothankourParents,FamilyandFriendsfortheirconstantsupportand
prayers. We would like to thank Dr. JRGENBRSTLER for helping us throughout the thesis.
We are grateful to him for his guidance and never ending willingness to transfer the
knowledgehehas.
In the end we would also like to thank each other for working as a team and solving
conflictsduringthestudywithpatience.

ii

CONTENTS
ABSTRACT......................................................................................................................................I
ACKNOWLEDGEMENTS..................................................................................................................II
CONTENTS....................................................................................................................................III
1

LISTOFFIGURES...................................................................................................................VI

LISTOFTABLES....................................................................................................................VII

CHAPTER1INTRODUCTION................................................................................................1
1.1
BACKGROUND...........................................................................................................................1
1.1.1 Securityinsoftware .......................................................................................................... 1
1.1.2 Howissecurityneglected?................................................................................................ 2
1.1.3 Howissecurityaddressed? ............................................................................................... 2
1.1.4 SecureSoftwareEngineering ............................................................................................ 2
1.2
OURIDEA.................................................................................................................................3
1.3
PRESTUDYFORTHESIS...............................................................................................................4
1.3.1 SelectionCriteriafortechniques ....................................................................................... 4
1.3.2 SystematicLiteratureReviewforSecurityRequirementElicitationTechniques(Prework
forThesis)....................................................................................................................................... 4
1.3.2.1
SearchStrategy ...................................................................................................................... 4
1.3.2.2
ResearchQuestionsforSLR.................................................................................................... 5
1.3.2.3
SearchTerms .......................................................................................................................... 5
1.3.2.4
Databasesanddatacollectionsource .................................................................................... 6
1.3.2.5
Inclusion/ExclusionCriteria ................................................................................................... 7
1.3.2.5.1 ExclusionCriteria ............................................................................................................... 7
1.3.2.6
KappaCoefficient ................................................................................................................... 7
Toincreasethelevelofagreementamongtheauthors,wetriedtoresolveourconflictsthroughmutual
understandinganddiscussionsbetweenus. ............................................................................................. 8
1.3.2.7
StudyQualityAssessment ...................................................................................................... 8
1.3.2.8
DataExtractionCriteria .......................................................................................................... 9
1.3.2.9
SynthesisofArticles ............................................................................................................. 12
1.3.2.10 Conclusion ............................................................................................................................ 13
1.3.2.11 Limitations............................................................................................................................ 13

1.3.3 QuickcomparisonofSecurityRequirementElicitationtechniques ................................. 13

1.3.4 Whydidwechoosetwoformaltechniques? .................................................................. 15
1.3.5 WhyMisusecases? ......................................................................................................... 15
1.4
AIMSANDOBJECTIVES...............................................................................................................16
1.5
RESEARCHQUESTIONSFOROURTHESIS........................................................................................16
1.6
EXPECTEDOUTCOMES...............................................................................................................17
2 CHAPTER2ANALYSISOFAVAILABLEFRAMEWORKSDOWEREALLYNEEDANEW
FRAMEWORK?.............................................................................................................................18
2.1
CONCEPTBEHINDSECURITYREQUIREMENTELICITATIONTECHNIQUES................................................18
2.2
SECURITYREQUIREMENTFRAMEWORKSININDUSTRY......................................................................19
2.3
LITERATUREREVIEWFOREXISTINGFRAMEWORKSFORSECURITYREQUIREMENTELICITATION.................20
2.3.1 SearchStrategy ............................................................................................................... 20
2.3.2 ResearchQuestionsforLiterature .................................................................................. 20
2.3.3 SearchTerms................................................................................................................... 20
2.3.4 Databasesanddatacollectionsource ............................................................................ 21
2.3.5 Inclusion/ExclusionCriteria ............................................................................................ 21
2.3.6 SearchResults ................................................................................................................. 21
2.4
RESULTSANDCONCLUSIONS......................................................................................................22

iii

UNDERSTANDINGSECURETROPOS,MISUSECASESANDCLASP...........................................23
3.1
SECURETROPOS....................................................................................................................23
3.2
MISUSECASE..........................................................................................................................27
3.2.1 MisuseCasesTemplate ................................................................................................... 28
3.3
CLASP...................................................................................................................................29
3.4
SUMMARY..............................................................................................................................34

PROPOSEDFRAMEWORK....................................................................................................35
4.1
OVERLAPPINGACTIVITIESOFCLASPANDSECURETROPOS............................................................35
4.2
BESTPRACTICESELECTION.........................................................................................................35
4.3
ACTIVITYSELECTION.................................................................................................................36
4.4
ADDITIONALFIELDSINMISUSECASESTEMPLATE............................................................................37
4.5
SEQUENCINGTHESTEPS............................................................................................................37
4.6
ANALYSISOFSELECTEDSTEPS:ACTIVITYREVISIT.............................................................................37
4.7
USINGSECURITYREQUIREMENTCATEGORIZATION.........................................................................38
4.8
PROPOSEDFRAMEWORK...........................................................................................................38
4.8.1 HowtoconducteachstepofFramework ....................................................................... 38
4.8.1.1
4.8.1.2
4.8.1.3
4.8.1.4
4.8.1.5
4.8.1.6
4.8.1.7
4.8.1.8
4.8.1.9
4.8.1.10
4.8.1.11
4.8.1.12

SpecifyOperationalenvironment ........................................................................................ 39
Identifyglobalsecuritypolicy............................................................................................... 39
Identifyresourcesandtrustboundaries .............................................................................. 40
Identifyuserrolesandresourcecapabilities........................................................................ 40
Identifyindepthuserroles,securecapabilitiesandsecurityconstraintsforeachactor .... 41
Identifyattacksurface.......................................................................................................... 41
Researchandassesssecurityposture .................................................................................. 42
Detailmisusecase ................................................................................................................ 42
Documentsecurityrelevantrequirements .......................................................................... 43
Performsecurityanalysisofsystemrequirementsanddesign. ........................................... 44
Updatesecurityrequirementsdocument ............................................................................ 45
Identifyresources,entrypoints,functionalities,assets,servicesandactorsforthesystem
45
4.8.1.13 Supposeallthethreatsmentionedinthecategorizationaretrueforallresources,entry
points,functionalities,assets,servicesandactorsforthesystem .......................................................... 45
4.8.1.14 Validatethreatsforeachresource,entrypoint,functionality,asset,serviceandactorsfor
thesystem 45
4.8.1.15 Updatethedocument .......................................................................................................... 46

EXPERIMENT.......................................................................................................................47
5.1
EXPERIMENTDEFINITION...........................................................................................................47
5.1.1 Objective ......................................................................................................................... 47
5.1.2 Context ............................................................................................................................ 47
5.1.3 SampleSpace .................................................................................................................. 48
5.2
EXPERIMENTPLANNING.............................................................................................................48
5.2.1 Purpose ........................................................................................................................... 48
5.2.2 Qualityfocus ................................................................................................................... 48
5.2.3 Perspective ...................................................................................................................... 48
5.2.4 Contextselection............................................................................................................. 48
5.2.5 Hypothesisformulation................................................................................................... 48
5.2.6 Variableselection............................................................................................................ 48
5.2.7 Subjectselection ............................................................................................................. 49
5.3
EXPERIMENTDESIGN.................................................................................................................49
5.3.1 Designprinciple............................................................................................................... 49
5.3.2 Designtype ..................................................................................................................... 49
5.3.3 Instrumentation .............................................................................................................. 50
5.3.4 Validityevaluation .......................................................................................................... 50
5.4
EXPERIMENTOPERATION...........................................................................................................51
5.4.1 SoftwareSystemforExperiment..................................................................................... 51
5.4.1.1
MonolithicMainframe ......................................................................................................... 51
5.4.1.1.1 Glossary ........................................................................................................................... 51
5.4.1.1.2 SystemDescription .......................................................................................................... 52

iv

5.4.2

Experimentexecution ..................................................................................................... 52

5.4.2.1
OutputduringeachactivityofFramework .......................................................................... 53
5.4.2.1.1 SpecifyOperationalEnvironment(Implementationscenario) ........................................ 54
5.4.2.1.2 IdentifyGlobalSecurityPolicy ......................................................................................... 54
5.4.2.1.3 Identifyresourcesandtrustboundaries ......................................................................... 54
5.4.2.1.4 Identifyuserrolesandresourcecapabilities ................................................................... 56
5.4.2.1.5 Identifyindepthuserroles,securecapabilitiesandsecurityconstraintsforeachactor 57
5.4.2.1.6 Identifyattacksurface ..................................................................................................... 57
5.4.2.1.7 Researchandassesssecurityposture ............................................................................. 57
5.4.2.1.8 DetailMisuseCase .......................................................................................................... 58
5.4.2.1.9 Documentsecurityrelevantrequirements ..................................................................... 59
5.4.2.1.10 Performsecurityanalysisofsystemrequirementsanddesign...................................... 59
5.4.2.1.11 UpdateSecurityRequirementsDocument: ................................................................... 61
5.4.2.1.12 IdentifyResources,EntryPoints,Functionalities,Assets,Capabilities,Resources,
ServicesAndActors. ........................................................................................................................... 61
5.4.2.1.13 SupposeAllTheThreatsMentionedInTheCategorizationAreTrueForAllResources,
EntryPoints,Functionalities,Assets,ServicesAndActorsForTheSystem. ....................................... 62
5.4.2.1.14 Validatethreatsforeachresource,entrypoint,functionality,asset,serviceandactors
forthesystem ..................................................................................................................................... 62
5.4.2.1.15 UpdateSecurityRequirementsDocument: ................................................................... 62

ANALYSISANDINTERPRETATION:........................................................................................63
6.1
DATASETREDUCTION...............................................................................................................63
6.2
DESCRIPTIVESTATISTICS.............................................................................................................63
6.2.1 VulnerabilityComparison................................................................................................ 63
6.2.2 RequirementTypeswithRespecttoSystemssecuritybaseline ..................................... 65
6.3
RESULTSANDDISCUSSIONS........................................................................................................68
6.4
RETURNOFINVESTMENTFOREACHTECHNIQUE..............................................................................69
6.5
VALIDITYTHREATS....................................................................................................................69
6.5.1 Limitations ...................................................................................................................... 70
6.6
ANSWERSTORESEARCHQUESTIONS............................................................................................71
6.7
CONCLUSIONANDLESSONLEARNED............................................................................................72
6.8
FUTUREWORK........................................................................................................................73

REFERENCES........................................................................................................................74

APPENDIX...........................................................................................................................81
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13

APPENDIXA.........................................................................................................................81
APPENDIXB.........................................................................................................................81
APPENDIXC(THREATSCATEGORIZATION)..................................................................................81
APPENDIXD(CLASPANDFRAMEWORKSECURITYRELEVANTREQUIREMENTS).................................85
APPENDIXE(CLASPANDFRAMEWORKSECURITYANALYSISREQUIREMENTS)..................................88
APPENDIXF(FRAMEWORKSFINALUPDATEREQUIREMENTS).........................................................89
APPENDIXG(MISUSECASEREQUIREMENTS).............................................................................90
APPENDIXH(QUESTIONNAIRE)................................................................................................92
APPENDIXI(FEEDBACKFORM)................................................................................................93
APPENDIXJMISUSECASETEMPLATE........................................................................................95
APPENDIXKSEQUENCEDIAGRAMSHOWINGACTIVITYFLOW........................................................96
APPENDIXLUSECASEDIAGRAMFORMONOLITHICSYSTEM..........................................................97
APPENDIXMSEARCHSTRINGS.....................................................ERROR!BOOKMARKNOTDEFINED.

LISTOFFIGURES

Figure1:OverallResearchOverview____________________________________________1
Figure2:SearchStrategy _____________________________________________________5
Figure3:StudySelectionCriteria_______________________________________________9
Figure4:SearchStrategy ____________________________________________________20
Figure5:SecureTROPOSexample_____________________________________________27
Figure6:MisuseCasesexample_______________________________________________27
Figure7:ComponentArchitectureDiagram _____________________________________55
Figure8:ThreatTree________________________________________________________61
Figure9:Percentagecomparisonwithknownvulnerabilities________________________64
Figure10:Authorizationrequirements _________________________________________66
Figure11:AuthenticationRequirements________________________________________66
Figure12:ConfidentialityRequirements________________________________________66
Figure13:DataintegrityRequirements_________________________________________67
Figure14:AvailabilityRequirements___________________________________________67
Figure15:NonRepudiationRequirement_______________________________________68
Figure16:AccountabilityRequirements ________________________________________68
Figure17:RequirementAnalysisw.r.tSecurityBaseline____________________________69

vi

LISTOFTABLES

Table1:TwoPhaseInclusionCriteria____________________________________________7
Table2:KappaCoefficient ____________________________________________________8
Table3:RelevanceofPaperswithResearchQuestions _____________________________9
Table4:Categorizationbyresearchmethods____________________________________11
Table5:DataExtractionCriteria_______________________________________________11
Table6:SynthesisofArticles _________________________________________________12
Table7:StarRatingsofDifferentSecurityRequirementElicitationTechniques(reproduced
fromRomeroMarionaetal.[69])._________________________________________13
Table8:DescriptionforStarRating(reproducedfromRomeroMarionaetal.[69])._____14
Table9:TwoPhaseInclusionCriteria___________________________________________21
Table10:SearchResult______________________________________________________21
Table11:FourPhasesofSecureTROPOS________________________________________23
Table12:ImplementationStepsofSecureTROPOS _______________________________25
Table13:MisuseCasesImplementationSteps ___________________________________28
Table14:MisuseCaseTemplate ______________________________________________28
Table15:CLASPViews ______________________________________________________29
Table16:CLASPActivities____________________________________________________29
Table17:CLASPBestPractices________________________________________________33
Table18:OverlappingActivitiesofCLASPandSecureTROPOS ______________________35
Table19:SelectedBestPracticesforCLASP______________________________________36
Table20:SelectedActivitiesfromCLASP________________________________________36
Table21:SelectedActivitiesfromSecureTROPOS ________________________________37
Table22:AdditionalfieldsinMisuseCaseTemplate_______________________________37
Table23:SequenceofCLASPActivities_________________________________________37
Table24:Mergedactivitiesfromtechniques_____________________________________37
Table25:FrameworkSteps __________________________________________________38
Table26:Experimentdesigntype _____________________________________________49
Table27:Activityflow_______________________________________________________52
Table28:PlanforDay1ofExperiment__________________________________________52
Table29:PlanforDay2ofExperiment__________________________________________53
Table30:SecurityBaseline___________________________________________________54
Table31:ComponentArchitecture ____________________________________________55
Table32:Systemresourcesandcapabilities_____________________________________56
Table33:User'scapabilities__________________________________________________56
Table34:Application'scapabilities ____________________________________________56
Table35:Accessmethodcapabilities___________________________________________57
Table36:Technologiesandproblems __________________________________________58
Table37:MisuseCase_______________________________________________________58
Table38:MisuseCase_______________________________________________________58
Table39:CorrelationMatrix__________________________________________________59
Table40:ThreatsonAssets __________________________________________________60
Table41:ThreatsonCapabilities______________________________________________60
Table42:System'sresources/assets ___________________________________________62
Table43:ValidThreats______________________________________________________62
Table44:VulnerabilityandSecurityrequirementcomparison_______________________64
Table45:RequirementanalysiswithrespecttoSecuritybaseline____________________65

vii

CHAPTER1INTRODUCTION
Thepurposeofthischapteristogiveanintroductionaboutsecurityinsoftware,
the way security is addressed in software and to present an overall idea of our
research. We have explained our research plan and the basic idea behind our
researchinthischapter.
Figure1:OverallResearchOverview

1.1

Background

1.1.1

Securityinsoftware

As assets got connected to software, security concerns for software grew more
and more. Over the years, the level of threats to software systems has varied
dependingupontheenvironmentsinwhichsoftwaresystemsareusedandthedata
thesesoftwaresystemsprocess[54,81].Internetandconnectivitywasconsideredas
asocialandcommercialbreakthroughbutithasincreasedtheopportunitiesforthose
whowanttoelectronicallyexploitothers[81].Softwareattacksandhackingincidents
actuated the software world to concentrate on security of the software produced.

Constantandsuccessfulattackstoriesmakeitclearthatyetsoftwaresaredeveloped
withvulnerabilitiesinside[30,90].

1.1.2

Howissecurityneglected?

Traditionally, software development is focused on functional requirements of

software system from the start of software development [3,15,64]. Security is
incorporatedinthelaterstagesofdevelopmentasanafterthought[41].Securityin
software system is put under the category of nonfunctional requirements by the
researchers [3,16,27] and hence taken as a complimentary feature by software
developers[7,15,74].AccordingtosyllabusprovidedbyREQB1[82]indepthsecurity
requirements are not focused due to time pressure, exclusive fixation of cost and
orientation towards fast results. In addition, functional security features are often
confused with actual security needs throughout the system [3]. Understanding
security needs of a system requires considerable knowledge of asset, data security,
integrity, confidentiality and availability of service [64]. Counter measures against
softwareattacksisalsoasecurityneedofasoftwaresystem.

1.1.3

Howissecurityaddressed?

A number of approaches have evolved to address software security. Following

threemajorapproachesareusedtoaddresssecurityinsoftware[30].
1. PenetrateandPatch
2. SecureOperationalEnvironment
3. SecureSoftwareEngineering
In penetrate and patch approach, software product is released in public after
completion. Any vulnerability found is fixed by applying patches. Although it is the
most common approach but to apply patch after finding vulnerability is hundred
times[10,30,41]moreexpensivethanifitwasfixedduringdevelopment.Mostofthe
time,morevulnerabilitiesareintroducedwhileapplyingpatches[30,41,86].
Securing operational environment [30,37] relies on the devices external to the
software systems such as firewalls and protection mechanisms. It can provide
external security to the software but helps very little against design and
implementationattacks.Moreover,operationalenvironmentsecurityisonlypossible
afterlaunchingtheoperationalproduct[30].
Idea behind secure software engineering is to implement well structured
processes and mechanisms from early phases of software development i.e.
requirement elicitation [30]. Secure software engineering starts from requirements
phaseandreflectedinallthephasesofsoftwaredevelopmentlifecycle[29,69,70,78].

1.1.4

SecureSoftwareEngineering

Focus of security requirement engineering is on early stages of software

development lifecycle which proves to be cost effective and brings about robust
design[42,54].Inordertogathersecurityrequirementofasoftwaresystem,number
ofsecurityrequirementelicitationtechniquesareused[69].
Security requirement elicitation techniques are divided into two categories i.e.
formal and informal. Formal security requirement elicitation techniques follow a
systematic procedure and definite number of steps [35,69]. Besides following the
standard steps, there exists a definite order to follow these steps. Lack of flexibility
and limitation in defining scope of (formal) security requirement elicitation
techniqueslimitstheuseandefficiencyoftechnique.Duetolimitationsinscalability
1

REQB = Requirement Engineering Qualifications Board (REQB), Poland

of the method, formal techniques are hard to use for big projects [69]. There are
predefined roles and repetition of process in formal techniques to conduct the
requirementspecification.
Ontheotherhand,informaltechniquesaremoreflexibleanditbecomeseasyto
definethestepsaccordingtothenatureofthesystemunderconsideration.Despite
theflexibilityofinformaltechniques,theylackasystematicapproach.Repetitionof
theprocessininformaltechniquesisnoteasyascomparedtoformalmethods.Since
there are no predefined steps in informal security requirement elicitation
techniques, most of the software professionals avoid [41] using them. Informal
security requirements elicitation techniques lack a proper structure and normally
leave few security problems unaddressed. In addition, particular roles are not
defined for the stakeholders in order to conduct the specification [69]. These are
some of the main reasons that informal techniques are normally avoided by the
securityrequirementengineers.
Mainideabehindsecurityrequirementelicitationwastouseelicitationmethods,
which are used to gather functional requirements, for nonfunctional requirement
(e.g.security)[3].Sinceelicitationtechniquesarefocusedonfunctionalrequirements
[2,3,14,23,63], it is difficult to use the same technique for capturing nonfunctional
requirements. For this purpose, many of the elicitation techniques were extended
and were used in an extended form [2,14,23,63] to capture nonfunctional
requirement (e.g. security). Some researchers have proposed new frameworks and
techniques especially for security requirement elicitation [4,48,49,51,92]. Whereas
some of the techniques were combined with other elicitation techniques [2,84] to
produce better results. All this, ongoing and past, work [3,8,45,46,65,69] is aimed
upondevelopingattackresistantandsecuresoftwaresystems.

1.2

OurIdea
Different researchers have rated security requirement elicitation techniques
differently [3,69,85]. This makes it very difficult to compare the results and various
ratingsofsecurityrequirementelicitationtechniques.Limitationsofformalmethods
andlackofsystematicapproachesininformalelicitationtechniquesmakesitdifficult
torelyonasingletechniqueforsecurityrequirementelicitation.
As it is mentioned above, that formal techniques lack flexibility and informal
techniques lack systematic approach, we decided to combine the strengths of both
formal and informal techniques to mitigate the problems in both techniques, when
used separately. The basic idea of our research was to integrate an informal
techniquewithformaltechniqueandproposeaflexibleframeworkwithsomelevelof
formality in the steps. Following were some questions which we needed to answer
beforewestartourresearch
1. Whichinformaltechniquearewegoingtochooseforintegration?
2. Whichformaltechniquesareintegrateablewithaninformaltechnique?
3. What is going to be our selection criteria for selecting security requirement
elicitationtechniques?
4. Aretheframeworksproposedbyotherresearchersnotgoodenough?
5. Doweneedanotherframework?

Toanswerpointnumber3abovei.e.SelectionCriteria,weconductedaliterature
review. After deciding a selection criteria (see next section), we conducted a
SystematicliteraturereviewasaPrestudyforourresearch.Followingweretheaims
ofoursystematicliteraturereview.

1. Identify the best informal security requirement elicitation techniques

accordingtotheselectioncriteria.
2. Identifythebestformalsecurityrequirementelicitationtechniquesaccording
totheselectioncriteria.
We also conducted a literature review to identify problems and challenges in
availablesecurityrequirementelicitationframeworks(seeChapter2).

1.3

PreStudyforThesis

1.3.1

SelectionCriteriafortechniques

Assaidearlier,manyresearchershavecomparedsecurityrequirementelicitation
techniques according to their self selected criteria. Each one of them
[3,17,18,22,40,41,49,50,69,7072,75,85] have rated the techniques differently.
Varietyofcriteriaanddifferentratingshinderstheselectionofsecurityrequirement
elicitation techniques. So we conducted a literature review and selected quality
criteriaforevaluatingsecurityrequirementelicitationtechniques.Ourqualitycriteria
werebaseduponthosequalitycriteriathatwerecommoninmostofthepaperswe
selectedforunderstandingevaluation[17,41,49,50,69,7072,75]oftechniques.i.e.
Easy toImplement:Stepsandactivitiesinvolvedin the method arenottoo
complexandcanbeexecutedeasily[49].
Flexibility:Techniqueismodifiableforuse[49,75].
Adaptability:Themethodcanbeusedinmultipleenvironments[49].
Learnability: Technique is learnable in definite and acceptable time period
[17,49,72].
Understandability:Clarityofstepsandactivitiesofthetechniquealongwith
thecapabilityoftechniquetounderstandrequirementspecification[70,71].
Scalability:Techniqueservesforprojectsofdifferentsizes[49,69,71].
Visualoutput:Techniqueproducesunderstandablegraphicaloutput[49].

We shall evaluate security requirement elicitation techniques using above

mentionedcriteria.

1.3.2

SystematicLiteratureReviewforSecurityRequirement
ElicitationTechniques(PreworkforThesis)

1.3.2.1

SearchStrategy
This section is an explanation of search strategy implementation using
KitchenhamGuidelines[43].
1. We identified keywords and important search terms from research
questions.
2. We also used synonyms of important search terms to improve our
search.
3. We formed search strings by using AND and OR Boolean operators (see
section1.2.2.3).
Oursearchstrategyispartiallyiterative.ItmeansthatwhilesearchingDatabases,
we changed and refined keywords and search terms to improve our search. We
gatheredalargesetofinitialstudiesafterexhaustingallthesearchtermsandsearch
strings(mentionedinsection1.2.2.3).Itisshownbelowinfigure1.

Figure2:SearchStrategy

1.3.2.2

ResearchQuestionsforSLR
1. Whatarethesoftwaresecurityrequirementselicitationtechniquesthatare
widelyused?
2. Whatarethetwowidelyusedtechniquesforsecurityrequirementelicitation
i.e. which satisfies these evaluation criteria (mentioned and explained in
section1.3.1);
EasytoImplement
Flexibility
Adaptability
Learnability
Understandability
Scalability
Visualoutput
3. Whichinformaltechniqueforsecurityrequirementelicitationhasthehighest
ratingforfollowingevaluationcriteria;
EasytoImplement
Flexibility
Adaptability
Learnability
Understandability
Scalability
Visualoutput
These research questions help us in evaluating security requirement elicitation
techniquesaccordingtoabovementionedcriteria.
InordertohavebetterunderstandingofRQ2i.e.whydidweselecttwoformal
techniques,refertosection1.3.4.

1.3.2.3

SearchTerms
To find papers in databases we used two Boolean operators i.e. AND & OR.
Firstly, we search papers with keywords and then we combined the keywords with
theBooleanoperatorstogetthedesiredoutput.
1.
2.
3.
4.
5.

SoftwareRequirements
RequirementsElicitation
RequirementsElicitationProcess
TechniquesusedtoelicitSecurityRequirements
RequirementsElicitationTechnique
5

6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

FormalRequirementsElicitationMethods
RequirementsGathering
FormalRequirementsElicitationTechnique
Softwarerequirementelicitation
Softwarerequirementelicitationtechnique
Softwarerequirementelicitationmethods
FormalElicitationTechnique
InformalElicitationTechnique
Softwaresecurity
SecurityRequirementElicitationTechnique
Softwaresecurityrequirements
Softwaresecurityrequirementselicitation
Softwaresecurityrequirementsformalelicitationtechnique
Softwaresecurityrequirementsformalelicitationmethods
1OR2OR3
6OR7OR8
FormalElicitationANDElicitationprocessANDElicitationmethods
Formal Elicitation Technique AND Software requirement elicitation AND
Softwarerequirementelicitationtechnique
ElicitationMethodsAND5AND6
ElicitationMethodsAND14
SoftwareSecurityAND11AND12
SoftwareSecurityAND11AND13
SoftwaresecurityAND15AND16
16AND17AND18
ElicitationTechniqueAND7AND8
ElicitationTechniqueAND19
(Software Requirements OR Requirements Elicitation OR Requirements
Elicitation Process OR Formal Requirements Elicitation Methods OR
RequirementsGatheringORFormalRequirementsElicitationTechniques)AND
(Formal Elicitation OR Elicitation Process OR Elicitation Methods OR Formal
Elicitation Technique OR Software Requirements Elicitation OR Software
Requirement Elicitation Technique) AND (Software Security OR Formal
Elicitation Technique OR Informal Elicitation Technique OR Security
RequirementsElicitationTechnique)

1.3.2.4

Databasesanddatacollectionsource
We used BTH Library to search the relevant material. We also searched the
databasesusingthekeywordswhichwereusedintheinitialsearchtomakesurethat
there isnoFormalorInformalSecurityRequirementElicitation Techniqueswhichis
left untouched. We searched online databases i.e. ISI, IEEE Xplore, ACM, Springer,
InspecandcompendeX.

1.3.2.5

Inclusion/ExclusionCriteria
In abstract level we selected papers based on their title, abstract, keywords,
languageetctocheckwhetherpapersarerelevanttoourfield.Indetailedlevelwe
furtheranalyzedpaperswhetherthedetaillevelinformation(mentionedinTable1)
existintheselectedpapers.

Table1:TwoPhaseInclusionCriteria

AbstractLevel

DetailedLevel

PapersandjournalsinEnglishlanguage.
Articlesthatlookedrelevantbykeywords.
Searchforrecentpapersfromlast89years.
AvailabilityofpaperthroughBTHlibrary.
Papersthatarepublishedinjournalsandconferencesareincluded.
Articleswereincludedwithrelevancetometadata.
ArticleswereincludedwithrelevancetometadataandFulltext.
Articleswereincludedrelevancetotitleandabstract.
Articleswereselectedrelatedtothesoftwaresecurityandformalelicitationtechniques.
ArticleswereselectedrelatedtosoftwaresecurityandInformalelicitationtechniques.
RelationshipwithRQ(ResearchQuestions):ThepaperselectionwasfocusedonourRQs.
Articleswereselectedthatcomparesoftwarerequirementelicitationtechniques.
Articleswereselectedthatevaluatesoftwarerequirementelicitationtechniques.
ArticleswereselectedbasedonEvaluationCriteriamentionedinRQ2andRQ3.

1.3.2.5.1

ExclusionCriteria
Therewerenumberofarticlesandpaperswhichwererepeatedinnumberof
databases. We removed duplicates automatically with the help of software
calledEndNote.Literaturewithsamereferencetypeistakenasaduplicateby
EndNote.Forexampleifjournalarticle,author,year,titlefieldsareidenticalfor
twoormorepapers,Endnotewillconsidersucharticlesasduplicatesandkeep
onlyonereferenceforsucharticles.Otheridenticalarticleswithdifferencein
referencetype,canberemovedmanually.
Paperswerediscardedwhichdidnotfulfillthecriteriaofinclusion.
Studies were excluded if its main focus was not on security requirement
elicitationtechniquesi.e.somepapersfocusedonlyonrequirementelicitation
techniquese.g.brainstorming,interviewsetcwereexcluded.
Articleswereexcludedwhichwerenothavinginformationaboutinformaland
formalsecurityrequirementelicitationtechniques.

1.3.2.6

KappaCoefficient
Werandomlyselected25studieswhileapplyinginclusioncriteriatochecklevel
ofagreementanddisagreementbetweentwoauthors.Tochecklevelofagreement
betweentwoauthorsweusedkappacoefficient.Thevalueofkappacoefficient[43]
intableis0.40whichisafairagreementbetweenauthors.
K=P(o)P(E)
1P(E)
P(o)=ProbabilityofObservedagreementbetweenauthors.
P(E)=ProbabilityofExpectedagreementbetweenauthors.
N=Numberofstudiesrandomlyselected
K=[1,1]
K=1:Perfectagreement
K=0:Agreementisequaltochance

K=1:Perfectdisagreement.
P(o)=(NoofstudiesbothresearchersaysYes+Noofstudiesboth
Researchersaysno)/N
(Inordertocalculateobservedagreementwecalculatednumberof
studies in which both researchers agreed that they must be
included and added with the number of studies on which both
researchers disagreed. Result of this was divided with number of
studiesrandomlyselectedi.e.25here)

P(o)=11+6/25

P(E) = [No of Studies Researcher 1 says yes/ N * No of studies

Researcher2sayyes/N]+[NoofstudiesResearcher1say
No/N*NoofStudiesResearcher2sayNo/N]

(In order to calculate expected agreement we first calculated

number of studies separately in which researcher 1 and 2 agree.
Then we divided separately research 1 studies and research 2
studies with the number of studies randomly selected. Then we
calculated separate studies in which researcher 1 and 2 disagree.
WedividedseparatelyResearcher1andresearcher2studieswith
thenumberofstudiesrandomlyselected.)

P(E)=[16/25*14/25]+[9/25*11/25]

Table2:KappaCoefficient
Studies
InclusionExclusion
Criteria

PapersSelected
Randomly
25

P(A)

P(E)

0.70

0.50

0.40

Toincreasethelevelofagreementamongtheauthors,wetriedtoresolveour
conflictsthroughmutualunderstandinganddiscussionsbetweenus.
1.3.2.7

StudyQualityAssessment
Inordertosearchdifferentrelevantarticlesinthedatabases,weproposedsome
checklist points. A list of papers was selected after applying an inclusion/ exclusion
criteria. Information extracted from studies was analyzed on the basis of approach,
techniques, methods and results. The main objective was to find answer to our
research questions. So the relevancy of problems addressed in the papers was of
significantimportance.
The search was basically focused on different available security requirement
elicitation techniques and their effectiveness of use in different scenarios. Inclusion
andExclusioncriteriawerealsotakenintoaccounttosearchmaterial.Inordertofind
authentic articles, we used checklist points for quality assessment. We applied
checklistpointsbymanuallybyreadingthearticles.Followingarethequalitycriteria
whichweretakenintoconsideration:

Theresearchmethodologyisunderstoodbythereader.
Limitationsofthestudyarereported.

Primarystudieswereselectedbasedonempiricalevidencei.e.datamustbe
availableinqualitativeorinquantitativeform.

Figure3:StudySelectionCriteria

1.3.2.8

DataExtractionCriteria
After the inclusion and exclusion criteria we choose 24 articles
[1,5,6,9,17,19,20,31,32,36,41,49,50,5255,57,7072,76,78,83]whicharemorerelated
to our research area with respect to process, techniques, approaches, gap, future
work,advantagesanddisadvantagesofsecurityrequirementselicitationtechniques.
Found articles are related to the various important techniques for security
requirementsengineering.Papersincludebothformalandinformaltechniques.

Table3:RelevanceofPaperswithResearchQuestions
Papers

Titleofthepaper

Security Requirements Engineering for

[52]
softwaresystems:Casestudiesinsupport
ofsoftwareengineering

Paper related
to Research
question

RQ:2

 Successful requirement elicitation by

[55]
combining requirement engineering
techniques
Security Requirements Elicitation Using
[76]
MethodWeavingandCommonCriteria

RQ:1

Injecting security as aspectable NFR into

[9]
SoftwareArchitecture

RQ:2

Security Requirements Engineering: A

[32]
Framework for Representation and
Analysis
MOQARE:
misuseoriented
quality
[36]
requirementsengineering

RQ:2

An Ontological Interface for Software

[20]
DeveloperstoSelectSecurityPatterns

RQ:2

A systematic review of
[54]
requirementsengineering

RQ:1,RQ:2

security

RQ:1,RQ:2

RQ:2

Security Requirements Variability for

[53]
SoftwareProductLines

RQ:1

ElicitingSecurityRequirementsbyMisuse
[78]
Cases

Analysis for Understanding Software

[19]
SecurityRequirementMethodologies

RQ:2

Security Requirements Elicitation Using

[1]
ViewPointsforOnlineSystem

RQ:1

Security requirements engineering; state

[31]
oftheartandresearchchallenges

RQ:1,RQ:2

Extending tropos methodology

[57]
accommodatesecurity

to

RQ:2

Securityaware Software Development

[83]
LifeCycle(SDLC)

RQ:2

[17]

A comparative Evaluation of three

approaches to specifying security
Requirements
A Survey on requirements and design
methods
for
secure
software
development.
Experiences
in
Eliciting
Security
Requirements

RQ:3

[72]

Formality of the security specification

process:BenefitsBeyondRequirements

RQ2

[49]

How to compare the security quality

requirements
engineering(SQUARE)
MethodwithotherMethods
Security Requirements EngineeringA
survey

RQ3

[41]

[50]

[71]

RQ:1

RQ:2,RQ:3

RQ3

RQ2,RQ3

[70]

SRRS: A Recommendation System for

securityRequirements

RQ2,RQ3

[6]

Initial Industrial Experience of Misuse

CasesinTradeOffAnalysis

RQ3

[5]

MisuseCasesHelptoelicitnonfunctional
requirements.

RQ3

RelevantPaperswereextractedbasedontheresearchquestionsasshowninthe
above table. Based on the selected papers above we categorized the papers
according to the research methodology used in each paper. One article was found

10

which adopted experiment as a research methodology whereas other articles used

casestudy,survey,Interviewsandliteraturereviews.

Table4:Categorizationbyresearchmethods
Articles

Methodology

[50]
[17][9][36][50][52][54][53][49][5][31][76]
[9][19][55][57][41][72][71][70][78][6]
[19][1]
[54]
[55]
[32],[20][31],[83]

Experiment
CaseStudy
Survey
LiteratureReview
SLR
Interviews
Others

Followinginformationwasrecordedforeachpaper.

Table5:DataExtractionCriteria
ArticleTitle
Journal/Conference/ConferenceProceedings
DateofPublication
StudyContext(Academia/Industrial)
ResearchMethod(Experiment/CaseStudy/Survey/LiteratureReviewetc.)
External/InternalValidity
RetrievalSearchQuery
Evaluation/Metrics(RQ2,RQ3)
Abstract

ArticleTitle:Relevanttitleswereselectedbasedonourstudy.

Journal/conference/Conferenceproceedings:WeincludedpapersfromJournals,
conferencesandconferenceproceedings.

Date of publication: Date of publication was taken into consideration when

selectingthepaper.Weselectedrecentpapersfrompast89years.

StudyContext(Academia/Industrial):Inourstudyweconsideredbothacademia
andindustrialstudy.

ResearchMethod(Experiment/casestudy/survey/LiteratureReviewetc):Based
on the selected papers above we categorize the papers according to their research
methodology.

External/Internal validity: We recorded the validity measures of the results of

eachpaper.

Evaluation/Metrics (RQ2, RQ3): Evaluation criteria are mentioned in research

question2and3.Evaluationcriteria(seeSection1.2.1)forthepapersevaluatingthe
techniques was recorded and looked into with respect to evaluation criteria
mentionedinourresearchquestions.

Abstract:Inabstractsummaryofthepaperispresented.Basedontheabstractof
thepaperwecanhaveageneralideawhetherthepaperisrelevanttoourstudyor
not.

11

1.3.2.9

SynthesisofArticles
In synthesis of articles, we synthesize the articles on the basis of research
methods, and the way the articles are related to our research area of software
securityrequirements.Articlesaresummarizedbelowtoshowthatwhatexactlywe
havefoundandwhatistheresultofourstudyregardingourchosenresearchareafor
systematicreview.
Table6:SynthesisofArticles

Articles
[54][78][17][50][71][52]
[55][76][9][53][19][1][31]

Summary
These papers explain the benefits of applying
securityinearlyrequirementphasewiththehelpof
security requirement elicitation techniques. It
resultsindetectingsecurityvulnerabilities,decrease
cost of software maintenance and helps in finding
complex components in software architecture.
Furthermore we get to know different techniques
and the benefits of combined requirement
elicitation techniques in different applications from
thesepapers.

[41][54][78][70][49][50][72]
[71][5][6][1][83][57][31]

In these papers, detail analysis is presented of

formal and informal approaches. Some of the
papersexplainthreatmodelingbasedonformaland
informal elicitation technique. Furthermore it
discusses the challenges and benefits of different
security elicitation techniques based on evaluation
criteriamentionedinRQ2andRQ3:

EasytoImplement

Flexibility

Adaptability

Learnability

Understandability

Scalability

Visualoutput
Thesepapersproposeaframeworkforrequirement
elicitation and analysis. These frameworks were
proposedto elicitqualityrequirement.Applicability
offrameworkswascheckedinindustry.

[32],[36],[20],[53]

Results
By analyzing these articles we
understood different security
requirement
elicitation
techniques and their benefits.
Secondly we analyze the
application
of
combined
requirements
engineering
techniques for efficient and
successful
requirements
engineering process for real life
complex project. We cannot say
thatonetechniqueisbetterthan
the others. There are number of
security requirement elicitation
techniques which facilitates in
detecting different security
vulnerabilities.
Different research methods are
used in found articles to elicit
security requirements. These
papers
evaluate
different
techniques based upon some
criteria. We evaluated the
techniques on the basis of our
own criteria. We came to know
that CLASP and Secure TROPOS
are widely used techniques in
formal techniques. Whereas in
informal techniques, Misuse case
is mostly understandable and
used.
Models are proposed by using
some standards to gather
requirements in the early stages
of the product. It is used as a
reference models in decision
making. Reason behind analyzing
differenttechniquesistoseethat
which
techniques
and
frameworks are suitable in
practicalworld.

Wehavenarrowdownourresearchareatothreeresearchquestions,andthese
posedresearchquestionsareansweredinfollowingways.
Wesearchedoutinavailabledatabasesusingdifferentsearchstringsandsearch
criteriatofindthetechniquestoelicitsoftwaresecurityrequirementswhichgivethe
answerofthefirstresearchquestion.Afterreviewingthefoundresearcharticleswe
analyzed all techniques to find out widely used formal and informal security
requirements elicitation technique on the basis of evaluation criteria mentioned in
research questions. We analyzed the widely used technique based on its
implementationandapplication.Aftertheinclusion/exclusioncriteriawechoosethe
24articles[1,5,6,9,17,19,20,31,32,36,41,49,50,5255,57,7072,76,78,83].

12

1.3.2.10 Conclusion
There are a number of security requirement elicitation techniques. The security
requirementelicitationtechniquesfallundertwocategoriesi.e.formalandinformal
security requirement elicitation techniques. Formal techniques follow certain
methods which are understandable and explainable. After reviewing and analyzing
theformalandinformalsecurityrequirementselicitationtechniquesweselectedtwo
widely used formal techniques (CLASP and Secure TROPOS) and one informal
technique(Misuse cases) based on the evaluation criteria. The reason to choose
formal security requirements elicitation techniques is that they follow a formal
processthatincludesstandardstepstodevelopsecurityrequirementsspecifications
andalsothereisadefinedorderinwhichsuchstandardstepsaretobefollowed,and
rolesaredefinedforsystemsstakeholders[72].Afterreviewingdifferentarticleswe
came to know that CLASP and Secure TROPOS are the most widely used security
requirementselicitationtechniquesinindustryandacademiaonthebasisofarticles
[31,41,57,71,72]. Though the informal technique does not follow any predefined
steps, reason to choose the informal technique (Misuse cases) is that it is used to
analyzeasituationfromdifferentaspectsandcapturesecurityrequirementsinorder
to remove threats in early phases of requirements engineering. Misuse cases as a
solution for security requirement elicitation is accepted by different researchers
becauseofitssimplicityandeffectivenessofuse.Basedontheevaluationcriteriawe
selectedinformaltechnique[5,6,31,41,49,50,70,71].Unfortunately,wedidnothave
accesstoindustryandwehadtodrawconclusionsfrompublishedmaterialalone.If
we had access to industry, we would be able to gather more evidence for the
conclusionsdrawnfromtheSLRhere.
Afterreviewingandanalyzingthecomparisonoftheformaltechniqueswiththe
help of literature review, we concluded that CLASP and Secure TROPOS are easy to
understandandimplement,morescalableandhavemoreusagehistoryforsecurity
criticalsystems.
1.3.2.11 Limitations
After reviewing and analyzing all the found articles from available and possible
databases for the systematic review, we found some limitations in our systematic
literaturereview.Somesearchtermsorstringswerenotworkingproperlytofindthe
articlesfromdatabasesrelatedtosecurityrequirementselicitation.Wetriedourbest
tofindthearticleswhichareavailableinlast89yearssothatwecanfindthelatest
researchgapsinthisareabutyetwe mayhavemissedsomearticlesthatwerenot
availabletous.

1.3.3

QuickcomparisonofSecurityRequirementElicitation
techniques

We used researches by different researchers to understand the comparison

between different security requirement elicitation techniques in our systematic
literaturereview.Followingtableisabetterandsimpleexampleinthisregardwhich
gives a quick and brief overview of famous security requirement elicitation
techniques.

Table7:StarRatingsofDifferentSecurityRequirementElicitationTechniques(reproduced
fromRomeroMarionaetal.[69]).

Resulting
System
Security

Scalability

Integrationof
security
Requirements

Constraint
Consideration

Benefitsof
testing

Other
Requirements
Integration

13

Misusecases
(Informal)
AbuserStories
(Informal)
Secure
TROPOS
(Formal)
Security
Problem
Frames
(Informal)
AntiModels
(Formal)
I*
(Formal)
Common
Criteria
(Formal)
SQUARE
(Informal)
OCTAVE
(Formal)
AttackTrees
(Informal)
USerMethod
(Formal)

**

None

None

***

None

I**

None

**

****

**

A**
D**

**

***

**

***

None

A****

None

None

**

****

None

None

****

**

None
D**
I***

****

****

D**
I*

***

****

None

A*

None

**

****

None

**

None

None

***

None

**

**

None

****

****

**

D**
D**
I**
A*
D**
I*
M*

****

CLASP
(Formal)

RomeroMariona et al. [69] compare 5 informal and 7 formal security

requirementelicitationtechniquesaccordingto6differentqualitycriteria(seeTable
3). Their survey explored constraints at later stages of development. These
constraints are the factors that can benefit other stages of development. These
constraintsincludeArchitectural(A),Design(D),Implementation(I)andMaintenance
(M).Thecriteriaforstarratingisasfollows

Table8:DescriptionforStarRating(reproducedfromRomeroMarionaetal.[69]).
Notation
None

TranslatedAs
Notspecified

Low

**

Moderate

***

ModerateHigh

****

High

Description
Thereisnoinformationregardinganyaspects/conceptsaboutthequestionathandin
anyofthesourcesdescribingtheapproach.
Aspects/conceptsrelatedtothequestionathandaresuggested(butnotindetail)OR
there is enough information to suggest that any support would be possible by the
approach.
Aspects/conceptsrelatedtothequestionathandareexplicitlymentionedinsomeof
the sources describing the approach, but it is not a critical component. Support is
described,butnospecificmeasurestooperationalizethatsupportaregiven.
Aspects/conceptsrelatedtothequestionathandareexplicitlymentionedinamajority
of the sources describing the approach; they are important aspects to the approach.
Supportisdescribedandsomemeasurestooperationalizethatsupportaredescribed.
Aspects/conceptsrelatedtothequestionathandarecriticaltotheapproach.Support
for the specific question is described across the majority of sources describing the
approach. There is evident and extensive support for the question at hand, and
measuresforachievingthissupportaredescribed.

We can see that RomeroMariona et al. [69] rated CLASP and Secure TROPOS
higher than other security requirement elicitation techniques. There is another
research conducted by Khan and Zulkernine [41] which also draws the same
conclusion as RomeroMariona et al.[69]. They [41] have compared Secure TROPOS
and CLASP with all other formal/Informal techniques and the results were almost
similar to that of RomeroMariona et al.[69]. Khan and Zulkernine [41] compared
different security specification languages according to properties like Security

14

constraints, Easy to implement, Usability (Usage scenarios), low level security

requirementsandsoftwarespecificationlanguageetc.Accordingtothem[41],Secure
TROPOS covers all these properties as compared to other specification languages.
They[41]havealsocomparedCLASPwithSQUARE,Haley,SREPandconcludedthat
CLASP covered most of the properties related to Flexibility, resources, potential
attackers, Easy to implement, attackers capabilities and high level security
requirements. In another study Romero et.al [70], in their research, conducted
comparison of different security requirement elicitation techniques based on the
different criteria which also includes Scalability and Understandability. They [70]
conductedSurveytoconcludetheirresultsandusedlikertscaletoratethetechnique
according to criteria. In their rating matrix, Secure TROPOS and CLASP have highest
ratinginScalabilitywhereasforunderstandability,theyhaveratedCLASPandSecure
TROPOS as good [70]. Similar conclusions were drawn by some other [29,85,87]
researchers.Betterandconcisewayofpresentingthecomparisonwithoutalengthy
preface, motivated us to refer to a piece of research from RomeroMariona et al.
[69].

1.3.4

Whydidwechoosetwoformaltechniques?

Thereasonforchoosingtwoformaltechniquesi.e.CLASPandSecureTROPOSout
ofseveralformaltechniqueswasthattheycoverthesecurityaspectsofthesystem
notintherequirementphaseonlybutalsointhedesignandtheimplementationpart
[41].Sobyusingthesetechniquestogether,wecangetusefulresult,whichismore
likely to elicit the security requirements, keeping in view, all software development
phases. These techniques also consider low and basic level security requirements
whichincludeintegrity,availabilityandconfidentialityofthesystem[41].Weignored
others formal techniques because constraints and approaches defined in formal
techniques follow strict systematic procedures [41] which are difficult to integrate
withothertechniques.Integratingtwowidelyusedtechniquesandgeneralizingtheir
stepsiseasyascomparetocombinemorethantwotechniqueswhichwillresultina
messandthusrequiremoreknowledgeinunderstandingthenotationswhichmight
beunfitforourframeworkanalysis[25].Integratingtwowidelyusedtechniquescan
have the benefit of using the different style and meaning of both the methods.
Moreover, considering two techniques will provide us with more options and
freedominordertoproposeaframework.

1.3.5

WhyMisusecases?

In addition to our systematic literature review and its results, we would like to
mentionsomemainreasonbehindselecting Misusecasesasaninformaltechnique
for our framework. Misuse cases are used to analyze a situation from different
aspectsandcapturesecurityrequirementsinordertoremovethreatsinearlyphases
of requirements engineering [68]. Alexander [5] indicated that Misuse cases can be
used for capturing nonfunctional requirements other than security like reliability,
availabilityandmaintainability.Thisinformal(MisuseCases)methodisveryusefulin
analyzing security threats and requirements [78]. Misuse cases as a solution for
security requirement elicitation is accepted by different researchers because of its
simplicity and effectiveness of use. It has a graphical and a textual form of
representation [6,4446,65,79,84,89]. In graphical representations, we can use
differentnotationstoshowthesecuritythreats.Textualtemplatesareusedtogather
detailed use cases descriptions which will benefit the requirement engineers to
analyzethesystem.

15

1.4

Aimsandobjectives
Themainaimofthisthesisistoproposeaconcrete,implementableframework
forsecurityrequirementelicitation.
To understand common software requirement elicitation mistakes that
causesecurityproblemsinasystem,atlaterstages.
Study formal and informal techniques for security requirement
elicitation.
Develop an implementable systematic procedure for security
requirementelicitationbyintegratingMisusecaseswithtwowidelyused
formaltechniquesforsecurityrequirementelicitation.
Toevaluateourproposedframework.
Understanding the validity of attack scenarios i.e. there are possibilities
of getting results some of which may not be applicable in case of the
systemunderconsideration.Inthatcaseweshallhavetovalidateevery
attackscenario.

1.5

ResearchQuestionsforOurthesis

We formulated three research questions for our research. The first research
questionwillbeansweredbyliteraturereviewandanalysisofavailableandongoing
research. We shall also conduct an experiment to conclude RQ1. The second and
third research questions will be validated through experiments or case studies. For
this, we have created two hypothesis null (H0) and alternative (H1) hypothesis in
RQ3.Wegavespecialattentiontotheanswerabilityofeachresearchquestion.Every
research question has an elaboration under the research question which discusses
motivation of the research question and in what way the research question is
answerable.
It should be noted that we used CLASP and Misuse Cases to elicit security
requirements (as mentioned in elaboration of RQ1). We did not elicit security
requirements from Secure TROPOS because later analysis (see Chapter 3) showed
that Secure TROPOS uses strict diagrammatical notations (see Figure 4) which are
difficulttointegratewithtextualform.MoreovermostofthestepsofSecureTROPOS
overlap with some of the activities of CLASP. Therefore, we decided to use CLASP
fromtheformaltechniquesforcomparison.

RQ1.
Doformalapproachesproducebetterresultswhenintegratedwithinformal
approachi.e.Misusecase?
Elaboration: Generalizing the steps of the two widely used formal security requirement
elicitationtechniquesCLASPandSecureTROPOSandintegratingthemwith
MisusecaseswillbethefirststeptoanswerRQ1.Inasecondstepweshall
conductanexperimentanduseCLASPandMisusecasesseparatelytoelicit
security requirements. Then we will use our framework to elicit security
requirements and compare results of our framework with the result from
CLASP and Misuse case respectively. During the comparison, we shall see
thatwhichonefromCLASP,MisuseandFramework,producesmorenumber
ofsecurityrequirements.
H0: Formal approaches do not produce better results when integrated
withinformalapproachi.e.Misusecase.
H1: Formal approaches produce better results when integrated with
informalapproachi.e.Misusecase.

16

RQ2.

What is the practicality of the proposed framework, i.e. up to what extent

andforwhichtypesofsoftwaresystemstheframeworkissuitable?
Elaboration: We focus on delivering an implementable system which is useful for
software industry. After proposing the framework we need to validate our
frameworkintermsofitsimplementation.Usabilityoftheoutcomewillbe
tested with the help of an experiment or case study defined in Research
Methodologysection.

RQ3.
On what basis and for which type of software systems, is the proposed
frameworkbetterthanotherwidelyknownsecurityrequirementelicitation
techniques?
Elaboration: We need to compare our framework with several wellknown security
requirement elicitation techniques. It will help us in determining if the
proposed framework captures more security requirements in number than
other security requirement elicitation techniques. By answering this
researchquestionwewillfindoutlimitationsandrankingofourframework
ascomparedtotheothersecurityrequirementelicitationtechniques.
H0: The proposed framework is not better than other security
requirementelicitationtechniques.
H1: Proposed framework is significantly better than the other
requirementelicitationtechniques.

1.6

ExpectedOutcomes

A workable model and framework by integrating Secure TROPOS and

CLASP with Misuse cases that can be used for security requirement
elicitationofanysoftwaresystem.
Knowledgeaboutthesystems,forwhichourmodelissuitable.

17

CHAPTER2ANALYSISOFAVAILABLEFRAMEWORKSDO
WEREALLYNEEDANEWFRAMEWORK?
Purpose of this chapter is to discuss the overall concept behind security
requirement elicitation techniques and available frameworks for security
requirementelicitationinindustry.
This chapter is divided into three main parts, Concept behind Security
Requirement Elicitation Techniques, Security Requirement Frameworks in industry
andliteraturereviewforexistingframeworksforsecurityrequirement.
Different requirement elicitation techniques and frameworks address security
fromdifferentanglesandperspectivesinordertoprovidemaximumbenefittouser
of the technique or framework. To understand the concept behind the creation of
thesetechniques,weneedtolookintovariousdefinitionsofsecuritybyresearchers
and try to establish their relationship with requirement elicitation techniques and
frameworks.

2.1

ConceptbehindSecurityRequirementElicitation
Techniques
Rushby [73] describes the concept of security as something which must not
happen. This description of security is quite vague but it is used by Sindre and
Opdahl to create an informal security requirement elicitation technique [78]. If we
take inverse of this description i.e. what must happen, we touch use cases. Use
casestechniqueisapictorialandtextualrepresentationoffunctionalrequirementsof
a software system. In other words a representation of what must happen in a
softwaresystem.MisusecasesissaidtobeinverseofUsecases[78].Inotherwords,
we can say Misuse cases represent what must not happen in a software system.
ThisdescriptionofMisusecasestechniqueisvagueandambiguouswhichissameas
theconceptofsecuritydescribedinRushbys[73]paper.Misusecasesisaninformal
security requirement elicitation technique which is an extension of Use case
requirementelicitationtechnique[61].InputforMisusecasesisatleastoneUsecase
[46,78,84]. There can be one or many misuse cases for a single use case. Misuse
creation depends upon the creativity of the person creating misuse cases
[45,65,6,79].Itmeansthatthereisnomeasurementofhowmanymaximummisuse
cases can be created for a particular use case. This vague concept of misuse case
creationestablishesitsrelationshipwithRushbys[73]description.Itmaybesaidthat
Misusecasesisarealizationofwhatmustnothappenduringasoftwareoperation.
AccordingtoMouratidis[58],asystemssecurityrequirementsaredefinedbya
systemssecurityconstraints.Sameconceptofsecurityispresentedbyothers[56,59]
whodefinesecuritytoasasystemsconstraint.Thisconceptofsecurityisseenini*
whichisaninformalrequirementelicitationtechnique.I*usestheconceptofgoals,
actors and dependencies to gather systems requirements. The concept of
dependenciesusedinI*canbedefinedasobligations[58]ontheactors.I*isused
forcapturingfunctionalrequirementsofasystembutusingtheconceptofsystems
constraint, I* is also used for capturing security requirements [16,23,57]. Tropos, a
formal technique for requirement elicitation is based upon I* modeling. Although
Troposwasnotdevelopedwithsecurityonmind[58],setofsecurityconstraintswas
proposed in order to enable Tropos to consider security aspects [23,58,59]. Secure
TROPOS, an extension of Tropos methodology, emerge as a formal technique for
securityrequirementelicitation[2,41,59].SecureTROPOSlacksincleardefinitionof

18

systemassets.Moreover,theideabehindSecureTROPOSmethodologydoesnottalk
about what system services are being constrained and its effect on systems
functionality[33].
IfwelookatCLASP,itconsistsoffiveviewswhichcontaintwentyfouractivities,
in total [66]. Each of the twenty four activities of CLASP is further divided [66] into
discreteprocesscomponentandlinkedtooneormorespecificprojectroles. Detail
workingofCLASPwillbeexplainedinanupcomingsection(seeChapter3).CLASPisa
formal technique it focuses on removing vulnerabilities in software environment.
CLASP emphasizes more on white box testing [29]. Therefore, despite the detail in
differentviewsandactivitiesofCLASP,itlacksindeterminingthetypesofbugstobe
fixed.CLASPactivitiesusuallyfocusonthearchitecturalandthetechnicalweaknesses
[29].Theseactivitiesignorethebusinesslevelthreats[29].CLASPdoesnothaveany
clear methodology how to realize or understand its activities [29,49,67,87].
Moreover,CLASPlackstoolsupport[29].
We see that not one description of software security encompasses the whole
problemareai.e.securityissuesinsoftware.Itisbecauseofthevarietyofresources
involved in software. Different natures of software systems, type of resources
involved,differentarchitecturalstylesandlifecyclemodelsaresomeofthereasons
ofvaryingefficiencyofsecurityrequirementelicitationtechniquesandframeworks.
Someresearchersconfinesecuritytoauthorization,integrity,confidentialityand
availabilityofservices[30,78,81],whereassome[4,65,92]focusonassets,activities,
goals and restrictions. Security requirement elicitation techniques and frameworks
are constructed on the concept of security. The way security is presented by
predecessors,inresearch,isreflectedlaterintherealizationoftheconceptsbythe
successors in the form of methods and techniques. Every requirement elicitation
technique and framework is a realization of a concept and the way security is
presentedbyoneormoreresearchers[4,32,33].Ithasbecomeclear,afterindepth
study of security concepts, that a flaw or shortcoming in a concept of security is
reflectedintherealizationoftheconceptlater.Itmeansthatifasecurityconcepthas
flaws, almost same flaws are reflected in realization of the concept whether the
conceptisrealizedbythesameordifferentresearcher(s).

2.2

SecurityRequirementFrameworksinIndustry
While studying existing techniques and frameworks, we saw that frameworks
proposedinacademiaareseldomusedinindustryatlarge.Mostorganizationshave
their own set of steps or framework to address security needs of a system. To
understandtheactualuseofsecurityrequirementelicitationframeworksinindustry,
we searched for security requirement frameworks used in software industry. We
selected literature available from two organizations i.e. IBM and CISCO. We were
surprised to know that these organizations have their own frameworks and set of
defined rules to address security in their systems. For example CISCO [39] uses
standardslikeISO17799andNISTSP800.CISCOisusingintegratedapproachinwhich
theyhaveintegratedstandardslikeISO17799andNISTSP800withdifferentstepsand
procedurestobeabletoimplementsecurityinallphasesofsoftwaredevelopment.
IBM [13] created a framework using the holistic approach to business security.
Security framework consists of 5 steps that enable the organization to secure the
solutions and the services. Framework used by IBM characterized security
requirements with respect to business policies which is again a customized
framework.
Frameworks proposed by researchers [4,12,21,24,32,33,38,52,58,77] are based
on different research methods. Researchers conducted detail studies in order to

19

addresssecurityrequirementsandtomakesoftwareworkbetter.Thereisnotmuch
literatureavailablewhichshowsthatdifferentframeworksproposedbyresearchers
areactuallyusedintheindustryonwidescale.
Beforeproposinganewframework,itwasimportanttolookintothepublished
materialregardingdifferentframeworksproposedbyresearchers.Inordertohavea
clear understanding of the existing frameworks and to know whether we need
anotherframeworkornot,weconductedaliteraturereview.

2.3

LiteratureReviewforExistingFrameworksforSecurity
RequirementElicitation

2.3.1

SearchStrategy

Inthissectionweexplainthesearchstrategyforourliteraturereview.
1. We identified keywords and important search terms from research
questions.
2. We also used synonyms of important search terms to improve our
search.
3. We formed search strings by using AND and OR Boolean operators (see
section2.3.3).
Oursearchstrategyispartiallyiterative.ItmeansthatwhilesearchingDatabases,
we changed and refined keywords and search terms to improve our search. We
gatheredalargesetofinitialstudiesafterexhaustingallthesearchtermsandsearch
strings(mentionedinsection2.3.3).Itisshownbelowinfigure3.
Figure4:SearchStrategy

2.3.2

ResearchQuestionsforLiterature

RQ1. Which are the available frameworks for security requirement

elicitation that came into being by integrating formal and Informal
securityrequirementelicitationtechniques?

RQ2. WhataretheproblemsintheResultingframeworksfrom(RQ1)?

2.3.3

SearchTerms

FormalTechniqueSecurityRequirementElicitationFramework
InformalTechniqueSecurityRequirementElicitationFramework
CLASPSecurityRequirementElicitationFramework
MisuseCaseSecurityRequirementElicitationFramework
SecureTROPOSSecurityRequirementElicitationFramework
Securityrequirementelicitationframework
1AND2

20

1OR2
FrameworkforSecurityRequirementElicitation
Formalinformaltechniquesframeworks
Generalframeworkforformalinformaltechniques
SecureTROPOSFramework
Misusecaseframeworks
Modelingsecurityrequirementswithmisusecases
Semiformalframeworkelicitationtechniques

2.3.4

Databasesanddatacollectionsource

We used BTH Library to search the relevant material. We also searched the
databasesusingthekeywordswhichwereusedintheinitialsearchtomakesurethat
thereisnoSecurityRequirementElicitationFrameworkwhichisleftuntouched.We
searched online databases like ISI, IEEE Xplore, ACM, Springer, Inspec and
compendeX.

2.3.5

Inclusion/ExclusionCriteria
Table9:TwoPhaseInclusionCriteria

Abstract
Level

Detailed
Level

PapersandjournalsinEnglishlanguage.
Articlesthatlookedrelevantbykeywords.
AvailabilityofpaperthroughBTHlibrary.
Papersthatarepublishedinjournalsandconferencesareincluded.
Articleswereincludedwithrelevancetometadata.
ArticleswereincludedwithrelevancetometadataandFulltext.
Articleswereincludedrelevancetotitleandabstract.
Articleswereselectedrelatedtothesoftwaresecurityframeworks.
RelationshipwithRQ(ResearchQuestions):ThepaperselectionwasfocusedonourRQs.
PapersrelatedtoIntegrationofformalandinformalsecurityrequirementelicitationtechniques
wereincluded
Articleswereselectedthatevaluateanddiscussproblemsinsecurityrequirementelicitation
frameworks.

We excluded papers which propose a security elicitation framework without

integratingformalandinformaltechniques.
There were number of articles and papers which were repeated in number of
databases. We removed duplicates automatically with the help of software called
EndNote.

2.3.6

SearchResults
Table10:SearchResult
DBs

Title,Abstract,fulltext,Metadata,Topic

TotalSearchResult

Googlescholar

FullText

144983

IEEE

Fulltextandmetadata

22,714

ISI

Topic

194

ACM

Title,abstract,review

9323

Eng.Village

Allfields

2904

Total

All

180,118

Abovearethesearchresultsfromdifferentdatabases.

21

2.4

ResultsandConclusions
Wewouldliketomentionherethatwewerenotabletofindanypaperinwhich
theauthor(s)haveproposedaframeworkbycombiningFormalandInformalsecurity
requirement elicitation techniques. We found few papers in which author(s) have
combined two informal techniques [47,84] but we did not find any paper which
combinesformalandinformalsecurityrequirementelicitationtechnique.Aswehave
mentioned earlier, many frameworks are available [24,33,47,77] for security
requirement elicitation. We only looked for the papers in which researchers have
combined formal and informal technique i.e. the context and basic idea of our
research. After our literature review for frameworks, in which we did not find any
helpfulmaterial,aquestionwasraisedi.e.Maybeitisnotagoodideatocombine
formalandinformaltechniqueforsecurityrequirementelicitation!
We have to answer the above question in our research (See RQ1). The idea
behind our research is to propose a framework by combining formal and informal
security requirement elicitation techniques. In this way we can use strengths in
formalandinformaltechniquestomitigatetheproblemsintheusageofbothformal
andinformaltechniques.

22

UNDERSTANDINGSECURETROPOS,MISUSECASESAND
CLASP
Inthischapter,wehavedoneimplementationanalysisofSecureTROPOS,Misuse
caseandCLASP.Wehavelistdownimplementationstepsoftechniques.Therewere
some steps in these techniques, which needed to be further broken down to
understand actual implementation e.g. (see Table 12). Following aspects were
consideredduringimplementationanalysisoftechniques
ID: An identification number is assigned to identify and differentiate a
particularactivity.
Description:Descriptionandtitleoftheactivity.
Input:Inputandprerequirementsfortheactivity.
Participants:Peopleinvolvedincarryingouttheactivity.
Output:Resultoftheactivity
Purpose:Reasontocarryouttheactivity.
RiskinOmission:Threatsiftheactivityisnotcarriedout.
Analysisand stepsextractionwascarriedoutafter carefulliteraturereview. We
combinedpointsmentionedinseveralpapersintabularformforeasyunderstanding.

3.1

SecureTROPOS
Secure TROPOS was initiated as a PhD project in 2000 [61]. Secure TROPOS is
extension of Tropos methodology to model security features throughout the
developmentprocess.Purposeofthisextensionistoproposesecurityconstraintsina
well defined manner. Secure TROPOS methodology was proposed to fulfill the
limitations of Tropos [26,62]. Secure TROPOS Process includes early requirement
analysis ,late requirement analysis, architectural design and detail design stage.
Early Requirement phase starts from actor modeling. Early requirements and late
requirements have the same activities like actor modeling, dependency modeling,
trust modeling, delegation, security constraint modeling and goal modeling.
Differenceisthatearlyrequirementsmodeltheenvironmentofthesystemwhereas
late requirements model the system to be [26]. Architectural phase defines the
relationships of actors with external actors. Last phase is the detail design phase
where the components identified, in the previous phases, are modeled using the
agentunifiedmodelinglanguage[26].
BelowisthephasewiseexplanationofSecureTROPOS(seeTable11).Inorderto
haveanindepthunderstandingofSecureTROPOSactivities,pleaserefertoTable12.

Table11:FourPhasesofSecureTROPOS

Phase

PhaseDescription

Input

Participants

Output

Purpose

RiskinOmission

23

1. Early
Requirement
analysisstage.

2. Late
Requirement
AnalysisStage

3. Architectural
designStage
Definitionofthe
overall
organization.
Identificationof
thecapabilities.
Identificationof
agentTypes.

Inthisstagedevelopers
understandthe
problembystudying
theorganization
environmentandtheir
settings.Stakeholders
areidentifiedand
developersmodelthe
stakeholdersasactors
toidentifythegoals,
dependenciesbetween
theactors.Actorsgoals
aredecomposeinto
moreprecisegoal
throughgoaloriented
analysisinorderto
achievethegoals
[59][60].
Firststagewasto
analyzetheactors.In
thisstagesystemis
analyzedinoperational
environmentalongwith
thefunctionsandthe
qualities.Inthelate
requirementstageone
ormoreactorsarealso
introducedbecause
sometimestheexisting
actorsdefinedinthe
firststagecannotthe
satisfythegoalsand
thedependencies
betweenthem[59][60].

Organization
Environment
andtheir
settings.

Stakeholders
(Actors),
Developers

Outputwillbe
organizational
modelwhich
includethe
actors,
Security
entitiesand
the
dependencies
betweenthem
[59][60].

Thepurposeisto
identifytheactors,
securityentitiesand
tounderstandthe
problemofthe
organization
[59][60].

Securityconstraintsare
identifiedforthe
stakeholderswhoare
furtheranalyzedinthe
latersteps.Foreach
actorcorresponding
securegoalsare
introducedinorderto
satisfythem.By
omittingthisstep
securityconstraintswill
beignoredforeach
actorandwecannot
furtheranalyzethe
securitygoalsforthe
correspondingactors
[59][60].

Operational
environment
,System,
Early
Requirement
analysis
stage.

Actors,
Developers,
analyst

System
functionaland
nonfunctional
requirement
aredefined.
Furthermore
entitiesare
assignedto
theactorsin
orderto
satisfythe
securitygoals
[59][60].

Thepurposeisto
describethemodel
ofthesystemasan
actorwhichare
definedinthe
previousstage.

Inthisstage
architectureofthe
systemisdefinedin
termsof:
Subsystems.
Thesesubsystems
areinterconnected
throughdataand
dependencies.
Furthermorethisstage
isdividedintothree
stepsaslistedinsteps
section.Architectureof
theorganizationis
definedbyidentifying
thenewactorsand
correspondinggoalsare
assignedtothem.
Secondstepexplains
theresourcesor
capabilityneededby
theactortoachieve
theirgoals.Thirdstep
identifytheagenttypes
[59][60].

Actors,
Goals,Early
Requirement
analysis
stage.

Architect,
Designer,
Developer

Setof
software
agentsare
identified
corresponding
totheactors
[59][60].

Thepurposeofthis
step[59][60]:
Involvenew
actorsthattheycan
interactwiththe
externalactors.
Decompositionof
theactorsothat
everyactordefined
mustbeanalyzedin
detailwithrespectto
theirgoals.
Setofagenttypes
aredefinedandtheir
corresponding
capabilities.

Mostoftheactors
definedinthefirststep
couldnotsatisfytheir
corresponding
intentionsgoalsortheir
relationshipsbetween
them.Byomittingthis
stepwecouldnotadd
moreactorsinthe
systemwhichcanlead
tofailureinsatisfying
thegoalsofthesystem.
Secondlywewillbe
unabletodefinethe
functionalandnon
functionalrequirements
ofthesystem[59][60].
Bydefiningnewactors
inthisstagewedefine
securityconstraintsand
whenwefurther
decomposeactorswe
identifysecuritysub
constraintsandtheir
entities.Byomitting
thisstepsomesecurity
constrainsandsub
constraintswillbe
neglectedwhichcan
leadthesystem
insecure.Furthermore
wecannotmovetothe
nextstepwhichisdetail
designstage[59][60].

24

4. DetailDesign
Stage.

Inthisstage
architectural
componentdefinedin
thepreviousstageare
discussedindetailsin
termsof[59][60]:
Inputs
Outputs
Security
Control

Architectural
DesignStage,
Early
requirement
analysis,late
requirement
analysis
[59][60].

Architect,
Designer,
Developer

Capabilitiesof
thesoftware
agentsare
identifiedand
their
interaction
throughthe
systemis
modeled.
Agentsare
derivedfrom
theactors
definedinthe
previousstage
[59][60].

Purposeistoidentify
thesoftwareagent
capabilitiesby
introducingthe
securityrulesandto
furtheranalyzethe
architectural
component[59][60].

Inthisstagesecurity
aspectsaretakeninto
accountfromthe
previoussteps.By
omittingthisstepwe
cannottracebackto
earlyrequirement
phase[59][60].

Secure TROPOS is implemented in a number of sequential steps. Input of each

stepisdependentuponoutputoftheprecedingstep.Detailimplementationstepsof
Secure TROPOS are mentioned below in Table 12. Purpose of each step along with
theriskifthatparticularstepisomitted,ismentioned.ThisTable(12)canbeusedfor
analysisinthelatersectioninwhichwearegoingtoproposeaframework.Wehave
used ST with a digit, in ID field, in order to be able to uniquely identify activities of
SecureTROPOSfromactivitiesofothertechniques.

Table12:ImplementationStepsofSecureTROPOS
ID
ST1

ST2

ST3

ST4

Step
Description
Construction of
Security
reference
diagram

Modeling
Stakeholders
alongwiththeir
goals,
dependencies,
and
security
constraints.
Analyze
In
depth
each
actors goals
and
security
constraints
imposed
to
them.
Introduce
Secureentities

Input

Participants

Output

Purpose

RiskinOmission

SecurityFeatures

Stakeholders
(Actors),
Developers

Security
Reference
Model/diagram

We lose track of the

security features we
havetotakecareof.

Stakeholders,
dependencies,
security
constraints,
SecurityReference
Model

Stakeholders
(Actors),
Developers,
Requirement
analyst

(Partial)
Stakeholder/Act
ordiagram

The security reference

modeling involves the
identification of security
needs of the systemto
be, problems related to
the security of the
system, such as threats
and vulnerabilities, and
also possible solutions
(usually these solutions
areidentifiedintermsof
asecuritypolicythatthe
organizationmighthave)
tothesecurityproblems.
It allows developers to
perform an analysis by
introducing relationships
between stakeholders
and security constraints
anditscontext.

(Partial)
Stakeholder/Actor
diagram

Stakeholders
(Actors),
Developers,
Requirement
analyst

Detail
actor
diagramfor each
actor

Identification
of
relationships
and
constraints related to
eachactor

Detail
actor
diagram for each
actor

Stakeholders
(Actors),
Developers,
Requirement
analyst

Detail
actor
diagramfor each
actor. (Steps 3
and
4
are
performed
simultaneously)

To help towards the

satisfaction of imposed
securityconstraints.

We have no idea of the

stakeholders and their
relationship with each
other.
We
cannot
describe the relation
between stakeholders
andsecurityconstraints.
Indepth vulnerabilities
areneglected

We cannot check if the

security goal has been
achievedornot

25

ST5

Analysis
of
system under
development
within
its
operational
environment
along
with
relevant
functions and
qualities

Complete actor
analysis from step
3and4

Actors,
Developers,
Requirement
analyst

System (partial)
analysis
(diagram)

ST6

Additionofnew
actors

System (partial)
analysis(diagram)

System (partial)
analysis
(diagram)

ST7

Actor
Decomposition

Output from step

6

System (partial)
analysis
(diagram)

Eachactorisdescribedin
detail with respect to
theirgoalsandtasks

ST8

Identify secure
capabilities for
eachactor

Output from step

7

System (partial)
analysis
(diagram)

Capabilities needed by
the actors to fulfill their
goalsareidentified

Lose track of resources

neededbyactors.

ST9

Agent
Assignment

Output from step

8

Architect,
Designer,
Developer,
Requirement
Analyst,Actors
Architect,
Designer,
Developer,
Requirement
Analyst,Actors
Architect,
Designer,
Developer,
Requirement
Analyst,Actors
Architect,
Designer,
Developer

Thesystemisintroduced
as one more actors, to
which existing actors
delegate responsibilities
for some of the goals
and the dependencies
that they cannot satisfy.
The
delegated
dependencies define all
the functional and non
functional requirements
ofthesystem.
To make the system
interact with external
actors

Architectural
design

Inability to define trust

betweenactors

ST10

Specify agent
capabilities and
interactions
taking
into
account
the
securityaspects
derived from
previous steps
ofanalysis.
Validation

Architecture
design

Architect,
Designer,
Developer

DetailDesign

Set of agent types is

defined and each agent
is assigned one or more
capabilities.
Consists of identifying a
design that satisfies the
security requirements of
thesystem,aswellasits
functionalrequirements.

DetailDesign

Stakeholders,
Architect,
Designer,
Developer

Final
model

ST11

security

Validate the relationship

between threats and
securityfeatures.
To check consistency
between
different
securitymodels.

Relationship
between
security constraints and
operational environment
cannotbeunderstood

Development of Secure
communication methods
between internal and
external
actors
is
neglected
Goal associated with the
actors
might
be
misunderstood

Cannot trace leftover

problems

Lackofconsensusamong
stakeholders.
System might not work
with some components
orothersystems.

26

Figure5:SecureTROPOSexample

Figure 4 is an example of Secure TROPOS which shows the security of eSAP

System.eSAPiselectronicsingleassessmentprocesssystemwhichisanagentbased
health and social care for older people. This diagram illustrates modeling
stakeholders along with their goals, dependencies and security constraints. As you
canseefromdiagrameachnodeisanactorandthelinksbetweeneachnodeshows
thattheyaredependentoneachothertoaccomplishgoal.Forexampleolderperson
dependsuponbenefitagency(Actor)sothatolderpersoncanhavefinancialsupport.
In order to keep their financial information private, older person impose security
constraints to the benefit agency. Likewise R&D Agency is dependent upon
professionalsothattheycanobtainclinicalinformationtoconductresearch.Asyou
can see from figure professional imposed a constraint to keep patient anonymity
fromdepartmentofhealth[59].

3.2

MisuseCase
Misusecasesareactionsthatareperformedbyactor(Person)inordertoharm
system. Purpose of misuse cases elements is to threat use case to hinder them in
achievingthegoal[6].
Figure6:MisuseCasesexample

Abovediagram(Figure5)isanexamplewhichshowsuseandmisusecaseofcar
securityrequirements.Asitisshowninfiguredriverthecar,lockthecarandlockthe
transmission are use case elements. Where as in the right side of picture steal the

27

car,shorttheignitionaremisusecaseelements.Inordertomitigatethreat(Stealthe
car) driver must lock the car. To mitigate short the ignition driver must lock the
transmission[6].
As discussed earlier, Misuse cases is an informal technique proposed by Sindre
and Opdahl. Normally, informal techniques lack definition of discrete and clear
number of steps [41]. If we look at the Implementation steps of Misuse cases, we
clearly see that there is no predefined end state and creation of Misuse case
dependsuponthecreativityofthepersonusingMisusecasestechnique[6,45,65,79].
We have used MC with a digit in ID field, in order to be able to uniquely identify
activitiesofMisusecasesfromactivitiesofothertechniques.

Table13:MisuseCasesImplementationSteps
Step
Number

Step
Description
Concentrate on
normal actors
andusecases

Input

Participants

Output

Purpose

RiskinOmission

Use
Cases

Stakeholders,
Analyst

Use case with

preliminary
Identification of
weakpoints

To understand the
services user wants.
Simplemotivationfor
thisstepis:ifthereis
nothing to use, there
isnothingtomisuse.

Introduce major
MisuseCases

Output
from
step2

Analyst

To express the
intentions of mis
actors who intend to
harmthesystem.

Investigate
Potential
Relation
between Misuse
cases and Use
cases

Misuse
case

Analyst

Major Misuse
case
identification,
Misuse
case
diagram
Detail
Misuse
case

Misuse case is
created on the
basis of Use Case.
Omitting this step
will stop further
progress
with
misuse
case
technique[80].
By omitting this
step,
misusers
intentions towards
the system are
skipped[80].
Wehavenoclueof
the nature of
attacks[80].

MC1

MC2

MC3

To identify the
nature of threat.
Many threats to a
system
can
be
achieved
through
normal functionality
e.g.DenialofService

3.2.1

MisuseCasesTemplate

Since Misuse cases is an extension of Use case [80], there are common fields
betweenUsecaseandMisusecasestemplatessuchasName,Date,andAuthoretc.
There are some additional fields that are specific for Misuse cases Template.
FollowingarethefieldsincludedinMisusecasestemplate[80].

Table14:MisuseCaseTemplate
Field
Name
Summary
Date
Author
BasicPath
AlternativePath
CapturePoint
ExtensionPoint
Triggers
Preconditions
Assumptions
Postconditions
WorstCaseThreat
Preventionguarantee

Description
MisuseCaseName/Title
ExplanationofMisusecase
DateofcreationofMisusecase
CreatorofMisusecase
Stepswhichamisuserisgoingtotakebeforereachingthegoal
Otherpathsthroughwhichthesamegoalcanbereached
Optionsforhowmisusecanbedetectedandprevented[61].
Optionalpathstakenbymisuse
Conditionthatcaninitiatemisusecase
Thisconditiondescribesthosestatesofthesystemwhichmakemisuse
possible
This condition describes those states of the systems environment
whichmakemisusepossible
Stateofthesystemaftersuccessfulmisuse case
Maximum damage possible in case of a successful misuse case.
Optionalpathsarealsoincluded.
Prevention Guarantee describes the result that would be obtained by
following the Basic or Alternate path if the threat were detected
andminimumthreatmitigationoccurs.[34]

28

Detectionguarantee
RelatedBusinessRule
PotentialMisuserProfile
Stakeholders
Scope
AbstractionLevel
Technology and Data
Variations

TheDetectionGuaranteedescribestheresultthatwouldbeobtained
ifthemisuseweredetected,butnotmitigated.[34]
RelatedBusinessRulesareusecasebusinessrulesthatarebrokenby
themisusecase[34]
Levelofskillsandintentionsofthemisusemustbeassessedinorderto
beawareoftheseverityofthreat
The people who have concern about what should not happen in the
system
The scope of modeling, e.g., the entire business or just the planned
computerizedinformationsystem[80]
Whatisthelevelofabstractionforthemisusecasee.g.summary,sub
functionetc.
Which various ways and technologies can be used to achieve the
misuse

3.3

CLASP
CLASP is an application security process which focuses on security throughout
software development life cycle. CLASP has five views (see Table 15), twenty four
activities(seeTable16)whicharegroupedinsevenbestpractices(seeTable17).
Table15:CLASPViews
View
ConceptsView

RoleBasedView

Activityassessmentview

ActivityImplementationView

VulnerabilityView

Description
Purpose of this view is to gain an overview of all the CLASP
processes and activities. Special attention is given to all the
concepts,activitiesandprocessesofCLASP[28,88,66].
This Section Gives an idea to the project manager how he and
his project members will deal or interact with the security
problems. Role based also introduces the basic responsibilities
fortheteammembers.Rolebasedisusedasinitialpointforthe
team members in order to address the security of software
[88,28,66].
CLASP Includes24activities.Itisnotnecessarytoincludeallof
them.Inassessmentview,thoseactivitiesareconsideredwhich
are appropriate for the software and which benefit the cost.
Focusofthisviewisontwothingsi.e.risksandimplementation
cost. Those activities which have low risk and high
implementationcostmaybedeletedinthisview[28,88,66].
CLASP activities are translated into software development
processes.Subsetoftheseactivitiesareassessedandaccepted
inthisphase[28,88,66].
Inthisviewallthesecurityproblemsarecategorized[88,66].

Following twenty four activities [66,88] are performed in CLASP. Some of these
activities can be performed independently whereas to carry out some activities, we
needoutputsofotheractivities.WehaveusedCLwithadigit,inIDfield,inorderto
be able to uniquely identify activities of CLASP from activities of other techniques.
Relative impact of CLASP on several key traditional software engineering activities
such as requirements specification is mentioned in Description field. Steps within
such activities are not materially changed by CLASP [66,88]. Instead, CLASP
recommendsextensionstocommonartifactsandprovidesimplementationguidance
for securityspecific content [66]. Owner in Participant field is the person(s) who
initiateandperformtheactivity.Keycontributorsprovidesignificantsupporttothe
activity.

Table16:CLASPActivities
Step
Number

StepDescription

Input

Participants

Output

Purpose

RiskinOmission

29

CL1

Institutesecurity
awareness
program
(RelativeImpact:
High)

Trainings,
Concepts

Project
manager,
Team
Members

Security
awareness

MonitorSecurity
Metrics
(RelativeImpact:
High)

Organization,
Application

Project
manager

Critical
Vulnerabilitiesare
assessedtoknow
thelevelof
improvementin
security.

Specify
Operational
environment
(RelativeImpact:
Medium)

Operating
Environment

Owner:
Requirement
Specifier,
Key
Contributor:
Architect,

Operational
environment
specification

Identifyglobal
securitypolicy
(RelativeImpact:
Medium)

Organization

Requirement
specifier

Securitybusiness
requirements,
Comparisonof
productsin
organizationsin
ordertocapture
securityposture.

Identify
Resourcesand
trustboundaries.
(RelativeImpact:
Low)

System

Owner:
Architect,
Key
contributors:
Requirement
Specifier

Security
requirements

CL2

CL3

CL4

CL5

Trainingsare
conductedinorderto
ensurethatproject
managersandthe
wholedevelopment
teamknowsabout
theimportanceofthe
securityinthe
software
To identify part of
software
that
requires
more
attention.
By
identifying
those
areas,securitycanbe
improved.
To
identify
the
frequency of the
defects.
Operation
environmentis
identifiedinorderto
assessthesecurity
impact.Assumptions
canbemadeinorder
toidentifythe
operational
environmentor
throughthe
requirementsofthe
systems
By identifying the
global security policy
a comparison can be
made of the security
procedure of the
products related to
the
different
organizations. By this
wecanhaveadefault
base line for security
business
requirements
Thesystemis
introducedasone
moreactors,towhich
existingactors
delegate
responsibilitiesfor
someofthegoalsand
thedependencies
thattheycannot
satisfy.Thedelegated
dependenciesdefine
allthefunctionaland
nonfunctional
requirementsofthe
system.

Teammemberswill
notunderstandthe
conceptand
importanceof
security.

Byomittingthisstep
therewillbeno
concretebaseto
measuresecurity
effort.

Bynotproperly
identifyingthe
operational
environmentwewill
notbeableto
communicateto
userstheimpactof
securityindesign
decisions.

It might create an
hindrance
in
comparing different
security procedure
with
different
organizations

Relationship
betweensecurity
constraintsand
operational
environmentcannot
beunderstood

30

Identifyuserroles
andresource
capabilities
(RelativeImpact:
Medium)

System

Owner:
Architect,Key
contributor:
Requirement
specifier

Systemroles,
resources

Systemrolesandthe
resourcestheseroles
canaccessare
identified.

Document
SecurityRelevant
Requirements
(RelativeImpact:
High)
DetailMisuse
cases
(RelativeImpact:
Low)

Application,
Security

Owner:
Requirement
Specifier,Key
contributor

Functional and
Business
requirementsfor
security

Functional
Requirementsfor
securityare
documented

System,
organization

Owner:
Requirements
specifier,Key
contributors:
Stakeholders.
Owner:
Designer

Risksare
identifiedwhich
canbe
communicatedto
stakeholders
Potentialentry
pointsforattack.

To
communicate
potential risks to the
stakeholder.

CL6

CL7

CL8

IdentifyAttack
Surface
(RelativeImpact:
High)

Application
Design

Applysecurity
principleto
design
(RelativeImpact:
High)

Application

Owner:
Designer

Implementation
strategies,Design
principles

Research
and
assess security
posture
of
technology
solutions
(Relative Impact:
High)
Annotateclass
designswith
security
properties
(RelativeImpact:
Low)
SpecifyDatabase
security
configuration
(RelativeImpact:
MediumtoHigh)

Thirdparty
components,
Technology

Owner:
Designer,
Key
Contributor:
Component
Vendor

SecurityRisksin
technologies.

Datafields,
Classdesign

Owner:
Designer

Detailexplanation
ofsecurity
policies.

Database
resources

Owner:
Database
Designer.

Default
configurationin
ordertosecure
database
resources.

CL9

CL10

CL11

CL12

CL13

By identifying the
attack surface one
can identify the
maximum
entry
pointsforanattackto
the system. This can
be measured by
identifying
the
number of inputs to
theprogram.
Determine
implementation
strategyforsecurity.

Itwillassessrisksin
thirdparty
components.
Determinehow
effectivelya
technologyreduces
risks.
Security policies are
defined for data
fields.

Default
security
configurations
are
identified for the
databases that are
associated
with
implementation.
Identify
recommended
security configuration
for
database
resources
for
databases that are
deployed by a third
party.

Bynotidentifyingthe
roles according to
the
resources
available
might
create hindrance in
the
protection
mechanism
on
resources. Secondly
by not specifying
roles according to
resources available
will create confusion
regarding the access
controlmechanisms.
System services for
security can be
ignoredeasily.

Customer will not

understand
the
threats and the risks
related
to
the
system.
Failure to consider
entry
important
points.
There can be a
chanceofduplication
of work in other
activities.

Notapplyingsecurity
principles earlier in
design phase will
result in revisit the
design phase in case
some
security
problem arise in the
implementationpart.

Security problems in
third
party
components
can
potentially
compromise
systemssecurity.
Error
in
implementing access
controlpolicy.

By omitting this
activity will have
security Errors in
database
configuration.

31

PerformSecurity
analysisofsystem
requirementsand
design
(RelativeImpact:
High)

System

Owner:
Security
Auditor,Key
contributor:
Architectand
designer

Systemthreats,
Systemrisks,
Securityimpact

Integratesecurity
analysisinto
source
management
process
(RelativeImpact:
Medium)

Management
process

Owner:
Integrator.

Regularmetrics
data,
implementation
review.

Implement
Interface
contracts
(RelativeImpact:
High)

Program
Interface.

Owner:
Implementer.

ReliabilityErrors
areidentified.

It is used for
validation of inputs.
Reliability Errors are
identified.

Implementand
elaborate
resourcepolicies
andsecurity
technologies
(RelativeImpact:
VeryHigh)
Addressreported
securityIssues
(RelativeImpact:
High)

Specification

Owner:
Implementer.

Security
functionalities

Security
Functionalities
related
to
the
specification will be
implemented by the
implementer.

Software

Owner:
Designer,
Key
contributor:
FaultReporter

SecurityRisk
i.e.tocheck
whetherthe
securityrisks
identifiedare
addressedornot.

PerformSource
Levelsecurity
review
Relative
Impact:(Very
High)
Identify,
implementand
performsecurity
Tests
Relative
Impact:(Medium)

Software,
System

Owner:
Security
Auditor,Key
contributors:
Implementer,
Designer.
Owner:Test
analysts.

Measurementof
healthofsecure
software
development
effort.

It is used to check
whether the risks
identified in the
design phase are
addressed properly in
implementation
phase
Vulnerabilitiesrelated
tosecurityare
identifiedin
implementation.

CL14

CL15

CL16

CL17

CL18

CL19

CL20

CL21

CL22

VerifySecurity
attributesof
Resources
(RelativeImpact:
Medium).
PerformCode
Signing
(RelativeImpact:
Low).

Design
review,
Operational
environment

Security
Problems,
SecurityRisks.

Software
operational
environment.

Owner:Tester

Confirmationof
previously
definedsecurity
policies.

Software

Owner:
Integrator.

Malwareare
omitted

System risks are

analyzed by analyzing
therequirements and
the design of the
system. It identifies
the high level system
threats which are not
properly documented
in
requirements
section.
Security
impact
of
non
security requirements
are assessed in this
phase.
Automatic
Metric
collection
and
implementation
securitylevelanalysis.

SecurityProblemsare
found which are not
identified in the
implementation part.
Failures
can
be
identified in design,
specification
and
implementation.
Confirm previously
defined
security
policies.

Providethe
stakeholderwitha
meansofvalidating
theoriginand
integrityofsoftware

System threats and

riskswillbeignored.

Omitting this activity

will lead to manual
laborwhichcanhave
negative impact on
projectscheduling.
Implementation
reviewscanbeeasily
skipped.
Criticaldatarelated
tosecuritywillbe
notidentified.Input
validationwillnotbe
complete.

Willincreaserisks

Risksnotaddressed
inimplementation
willleadtomore
threatsinthe
software.

Thoseriskswhichare
ignoredorskippedin
thedesignphasecan
bereflectedinthe
implementation
phase.
Securityriskswillbe
reflectedin
deployment.

Attackers have a
direct access to the
resources of the
software.

Customer
may
receive illegitimate
software
with
malwares.

32

CL23

CL24

BuildOperational
Guide
(RelativeImpact:
Medium).

Security
functionality,
Software.

Managesecurity
issuedisclosure
process
(RelativeImpact:
Low)

Security
Researchers

Owner:
Integrator,Key
Contributors:
Designer,
Architect,
Implementer
Owner:Project
Manager,Key
Contributor:
Designer

Operational
securitymeasures
document.

Documentationis
providedto
stakeholderrelatedto
operationalsecurity
measures.

User may install the

software
without
recommended
security
configurations

Effective
communication.

Communication with
customers
and
security researchers
from outside when
issues are found in
releasedsoftware.

Damage
business
reputation

Allthe24activitiesdefinedabovearegroupedinsevenbestpracticesinCLASP.
RelatedactivitiesofCLASParegroupedintosevenbestpractices,
1. Institute awareness program: Purpose of this activity is to educate everyone
involvedaboutsecurityconceptsandtechniquesusedinorganizationsthrough
trainingsandaccountability.
2. Perform application assessment: The purpose of this practice is to assess the
application by identifying security problems and security risks introduced in
operationalenvironment.
3. Capture Security Requirements: In order to capture security requirements
followingsfactorsmustbeconsidered:
Understand the application in context of usage and attack
scenarios.
Assetsareidentifiedinordertofindthelevelofaccesstheyprovide.
Overallarchitectureoftheapplication.
4. Implementsecuredevelopmentpractices:Goalofthispracticeistoachieve
securedevelopmentpracticesinorganization.Itguidesprojectteamwhen
applyingsecurityprinciplestodesignandelaboratingresourcepolicies.
5. Build vulnerability remediation procedures: Role of this activity is to reduce
risks by defining roles, responsibilities, prioritize steps and remediate
vulnerabilities.
6. Define and monitor metrics: This practice is critical in analyzing the security
posture of an organization, security effort and monitors the overall
performance.
7. Publish operational security guidelines: Documentation is provided to
stakeholderrelatedtooperationalsecuritymeasures.Tasksdefinedabovemust
becommunicatedtodifferentresearchers.
Following Table is inspired from [28] for better understanding of CLASP best
practices.
Table17:CLASPBestPractices
CLASPBestPractices
1. Institutesecurity
awarenessprogram
2. PerformApplication
Assessment

ID
CL1

CLASPActivities
Institutesecurityawarenessprogram

RelatedProjectRoles
ProjectManager

CL14

PerformSecurityanalysisof system
requirementsanddesign
PerformSourceLevelsecurityreview

SecurityAuditor

CL19

CL20
CL21
CL11

3. CaptureSecurity

CL4

Identify,implementandperform
securityTests
VerifySecurityattributesofResources
Researchandassesssecuritypostureof
technologysolutions
Identifyglobalsecuritypolicy

Owner:SecurityAuditor
KeyContributor:Implementer,
designer
Testanalyst
Tester
Owner:Designer
KeyContributor:Component
Vendor
RequirementSpecifier

33

Requirements

CL5

IdentifyResourcesandtrustboundaries

CL6

Identifyuserrolesandresource
capabilities

CL3

SpecifyOperationalenvironment

CL8

CL22
CL24

DetailMisusecases
(RelativeImpact:Low)
IdentifyAttackSurface
DocumentSecurityRelevant
Requirements
Applysecurityprincipletodesign
Annotateclassdesignswithsecurity
properties
Implementandelaborateresource
policiesandsecuritytechnologies
ImplementInterfacecontracts
Integratesecurityanalysisintosource
managementprocess
PerformCodeSigning
Managesecurityissuedisclosureprocess

CL18

AddressreportedsecurityIssues

CL2

MonitorSecurityMetrics

Integrator
Owner:Projectmanager
KeyContributor:Designer
Owner:Designer,
FaultReporter
ProjectManager

CL13

SpecifyDatabasesecurityconfiguration

DatabaseDesigner

CL23

BuildOperationalGuide

Owner:Integrator
KeyContributor:Designer,
Architect,Implementer

CL9
CL7
4. ImplementSecure
developmentpractices

CL10
CL12
CL17
CL16
CL15

5. Buildvulnerability
remediationprocedures

6. Defineandmonitor
metrics
7. PublishOperational
Securityguidelines

3.4

Owner:Architect
KeyContributor:Requirement
Specifier
Owner:Architect
KeyContributor:Requirement
Specifier
Owner:RequirementSpecifier
KeyContributor:Architect
Owner:RequirementSpecifier
KeyContributor:Stakeholder
Designer
Owner:RequirementSpecifier
KeyContributor:Architect
Designer
Designer
Implementer
Implementer
Integrator

Summary
AsfarasSecureTROPOSisconcerned,itusesstrictnotationsanddiagramswhich
arereallydifficulttointegratewithtextualformofactivitydescription(seeFigure4).
The notations like depender, node, constraints, dependee, dependum etc used in
Secure TROPOSareextensionofTroposmethodology.Withoutthesenotationsone
cannot carry out activities of Secure TROPOS. Focus of Secure TROPOS is to secure
thesystem.
Misuse cases have both textual and pictorial form of representation (see Figure
5). Misuse cases represent attacks on a system. Unlike CLASP and Secure TROPOS,
Misusecasesfocusonthreatstoasystem.
Allthe24activitiesofCLASPhavetextualexplanation.Itmeansthatactivitiesof
CLASP are explained in simple and plain language. CLASPs activities and best
practicesfocusonsecuringthesystemthroughoutsoftwaredevelopmentlifecycle.

34

PROPOSEDFRAMEWORK
Wewent throughanumberofactivitiesforproposingaframeworkforsecurity
requirement elicitation using CLASP, Secure TROPOS and Misuse cases. All of these
activitiesarementionedclearlyinthischapter.Itshouldbekeptinmindthatthere
weremanyplaceswhereweremovedsomeconstraintsintheactivitieswhichwere
specific for the technique. These constraints were removed to make the activity
integrateable with other activities. For example: Activities in Secure TROPOS are
sequential and Secure TROPOS uses special notations and diagrams for security
constraints and requirements which makes integration of Secure TROPOS with any
other technique very difficult. We used the basic idea behind such activities and
proposed new activities in our framework. We proposed this framework by
integratingactivitiesfromCLASP,SecureTROPOSandMisuseCases.

4.1

OverlappingActivitiesofCLASPandSecureTROPOS
We compared activities of CLASP and Secure TROPOS and found similarities in
some of the activities on the basis of concept behind the activities. To check
similaritieswelookedintoactualstepsofthetechniques.Asdiscussedearlier,Secure
TROPOS uses graphical notations which are difficult to integrate with techniques
having textual form of representation. Therefore we used the basic concept behind
SecureTROPOSactivities.
Some of activities of CLASP use similar concept as some activities in Secure
TROPOS. For example Activity CL3 says that one must specify operational
environmentinordertoassesssecurityimpact.UsingthesameconceptST5inSecure
TROPOSsaysthattoanalyzesystemoneshouldspecifyoperationalenvironmentin
whichsystemworks.SameisthecasewithCL10andST6,ST7,ST8whicharerelated
to architectural design. We have listed down the overlapping activities to eliminate
repetition of activities (see Table 18). Activities of Secure TROPOS are based upon
languagenotationsanddiagrams.Wehavetakenthebasicideabehindeachactivity
ofSecureTROPOSandignorednotationsanddiagrammaticalrepresentations.

Table18:OverlappingActivitiesofCLASPandSecureTROPOS
CLASP
ActivityID
CL2
CL3

MonitorSecurityMetrics
Specify
Operational
environment

CL10

Applysecurityprincipleto
design

CL5
CL14
CL21

4.2

Description

Secure
TROPOS
ActivityID
ST1

Identify Resources and trust

boundaries
Perform Security analysis of
system requirements and
design
Verify Security attributes of
Resources

ST5
ST6,
ST7,
ST8,
ST9
ST10
ST11

Description
ConstructionofSecurityreferencediagram
Analysis of system under development within its
operational environment along with relevant
functionsandqualities
These activities are performed to produce an
architecturaldesign
AgentAssignment
Specify agent capabilities and interactions taking
into account the security aspects derived from
previousstepsofanalysis
Validation

BestPracticeSelection
Theme of our thesis is to propose a framework, through which you are able to
elicit security requirements. After analyzing CLASP practices we realized that these
practices are related to different phases of Software Development Lifecycle such as

35

implementation and testing whereas focus of our research was on requirement

elicitation. So we selected two best practices of CLASP that contain the activities
relatedtorequirementgatheringphase(seeTable19).

Table19:SelectedBestPracticesforCLASP
CLASPBestPractices
PerformApplication
Assessment

ID
CL14
CL19

CL20
CL21
CL11

CaptureSecurity
Requirements

Identify,implementandperformsecurity
Tests
VerifySecurityattributesofResources
Researchandassesssecuritypostureof
technologysolutions

CL4
CL5

Identifyglobalsecuritypolicy
IdentifyResourcesandtrustboundaries

CL6

Identifyuserrolesandresourcecapabilities

CL3

SpecifyOperationalenvironment

CL8

DetailMisusecases
(RelativeImpact:Low)
IdentifyAttackSurface
DocumentSecurityRelevantRequirements

CL9
CL7

4.3

CLASPActivities
PerformSecurityanalysisofsystem
requirementsanddesign
PerformSourceLevelsecurityreview

RelatedProjectRoles
SecurityAuditor
Owner:SecurityAuditor
KeyContributor:Implementer,
designer
Testanalyst
Tester
Owner:Designer
KeyContributor:Component
Vendor
RequirementSpecifier
Owner:Architect
KeyContributor:Requirement
Specifier
Owner:Architect
KeyContributor:Requirement
Specifier
Owner:RequirementSpecifier
KeyContributor:Architect
Owner:RequirementSpecifier
KeyContributor:Stakeholder
Designer
Owner:RequirementSpecifier
KeyContributor:Architect

ActivitySelection
We further analyzed activities of the two selected best practices and found out
that there are some activities which focus on other than requirement phase of
SoftwareDevelopmentLifecycle.Wedeletedactivitieswhichwereoutofcontextfor
us and kept only those which focus on security requirement capturing phase. We
then revisited the table in which we listed over lapping activities(see Table 18) and
listed down the overlapping activities of CLASP and Secure TROPOS for our finally
selected activities. Our final activities are listed below (see Table 20). It should be
keptinmindthatthoseactivitiesofCLASPandSecureTROPOSwhicharerelatedto
phasesotherthanrequirementelicitationareequallyimportantinordertosecurea
systembutweonlyfocusedontheactivitiesthataddressrequirementelicitationto
stayinthescopeofthethesis.
Activity number CL19, CL20 and CL21 were deleted because they are related to
implementationandTestingphasesoftheSoftwaredevelopmentLifecycle.
Table20:SelectedActivitiesfromCLASP
CLASPBest
Practices
PerformApplication
Assessment

ID

CLASPActivities

CL14

PerformSecurityanalysisofsystemrequirements
anddesign
Researchandassesssecuritypostureoftechnology
solutions
Identifyglobalsecuritypolicy
IdentifyResourcesandtrustboundaries
Identifyuserrolesandresourcecapabilities
SpecifyOperationalenvironment
DetailMisusecases
(RelativeImpact:Low)
IdentifyAttackSurface
DocumentSecurityRelevantRequirements

CL11
CaptureSecurity
Requirements

CL4
CL5
CL6
CL3
CL8
CL9
CL7

Overlappingactivities
fromSecureTROPOS
ST10

ST9

ST5

36

Table21:SelectedActivitiesfromSecureTROPOS
SecureTROPOSActivityID
ST2
ST3
ST4
ST8

4.4

Description
ModelingStakeholdersalongwiththeirgoals,dependencies,andsecurityconstraints.
AnalyzeIndeptheachactorsgoalsandsecurityconstraintsimposedtothem.
IntroduceSecureentities.
Identifysecurecapabilitiesforeachactor.

AdditionalfieldsinMisuseCasesTemplate
In this step we considered those activities of Secure TROPOS that have no
overlappingwithanyoftheactivityofCLASPi.e.ST2,ST3,ST4andST8.
WeintendtomakeaseparateactivityusingST3,ST4andST8becausetheyare
related. Purpose of ST2 is to record Stakeholder information along with their goals,
dependencies,andsecurityconstraints.ItseemsfeasibletoaddthesefieldsinMisuse
CasesTemplate(seeTable14)andrecordthisinformationintheaddedfields.Sowe
addedthreemorefieldsinMisusecasestemplatei.e.(seeTable21)
Table22:AdditionalfieldsinMisuseCaseTemplate
Field
Goal
Dependencies(Relationship):
SecurityConstraints

4.5

Description
Whichgoalofthestakeholderishindered
RelationshipofStakeholderwithotherStakeholder(s)
InformationaboutSecurityconstraintsonStakeholder(s)

SequencingtheSteps
After finalizing the activities that are to be included in the framework, we
sequencedtheactivities onthebasis ofwhatshallbe donefirst(seeTable 22).For
example:CL14isdependentupontheoutputofotheractivities[66]soitshouldbe
keptatlast.

Table23:SequenceofCLASPActivities
ID
CL3
CL4
CL5
CL6
CL9
CL11
CL8
CL7
CL14

ActivityDescription
SpecifyOperationalenvironment
Identifyglobalsecuritypolicy
Identifyresourcesandtrustboundaries
Identifyuserrolesandresourcecapabilities
Identifyattacksurface
Researchandassesssecurityposture
Detailmisusecase
Documentsecurityrelevant requirements
Performsecurityanalysisofsystemrequirementsanddesign.

4.6

AnalysisofSelectedSteps:Activityrevisit
SequencedCLASPactivitieswerethenmergedwiththeactivitiesofMisusecase
andSecureTROPOS(seeTable23).

Table24:Mergedactivitiesfromtechniques
ID
CL3
CL4
CL5
CL6
ST3,ST4,ST8
CL9
CL11
MC1
MC2
MC3
CL7

ActivityDescription
SpecifyOperationalenvironment
Identifyglobalsecuritypolicy
Identifyresourcesandtrustboundaries
Identifyuserrolesandresourcecapabilities
Identifyindepthuserroles,secure capabilities andsecurityconstraints foreachactor
Identifyattacksurface
Researchandassesssecurityposture
Concentrateonnormalactorsandusecases
IntroducemajorMisuseCases
InvestigatePotentialRelationbetweenMisusecasesandUsecases
Documentsecurityrelevant requirements

37

CL14

4.7

Performsecurityanalysisofsystemrequirementsanddesign.

UsingSecurityRequirementCategorization
WhenwelookedatMisuseCaseactivities,westillfacetheproblemthatMisuse
creation depends upon the creativity of the person creating Misuse case. So we
decided to use Security Requirement Categorization by Bogale and Ahmed [11] in
whichtheyhavecategorizedalltheknownsecurityrequirementsandvalidatedtheir
categorizationfromSwedishArmedForces(seeAppendixC).
In order to make sure that maximum security requirements are captured, we
initially assume that all security requirements mentioned in Security Requirement
Categorization [11] are true for all identified entry points, functionalities, assets,
servicesandactors.Therearegoingtobemanyrequirementswhicharenotvalidfor
anentrypoint,functionality,asset,serviceoractor.Wedeleteinvalidrequirements
one by one for each entry point, functionality, asset, service or actor. The left over
security requirements will be valid security requirements for each entry point,
functionality,asset,serviceoractor.

4.8

ProposedFramework
Following steps are proposed after analysis of activities mentioned in earlier
sectionsinthischapter.ItshouldbenotedthatDetailMisuseCaseactivityi.e.Step8
and11arecomprisedofthreesubactivitiesmentionedinTable13andTable23.

Table25:FrameworkSteps
Step
Number
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Description
SpecifyOperationalenvironment
Identifyglobalsecuritypolicy
Identifyresourcesandtrustboundaries
Identifyuserrolesandresourcecapabilities
Identifyindepthuserroles,securecapabilitiesandsecurity constraints
foreachactor
Identifyattacksurface
Researchandassesssecurityposture
Detailmisusecase
Documentsecurityrelevantrequirements
Performsecurityanalysisofsystemrequirementsanddesign.
Updatesecurityrequirementsdocument
Identifyresources,entrypoints,functionalities,assets,servicesand
actorsforthesystem
Supposeallthethreatsmentionedinthecategorizationaretrueforall
resources,entrypoints,functionalities,assets,servicesandactorsfor
thesystem
Validatethreatsforeachresource,entrypoint,functionality,asset,
serviceandactorsforthesystem
Updatethedocument.

ActivityIDfromCLASP,
SecureTROPOSorMisuses
Cases
CL3
CL4
CL5
CL6
ST3,ST4,ST8
CL9
CL11
MC1,MC2,MC3
CL7
CL14

FurtheranalysisoftheframeworkshowedthattherecanbeiterationfromStep8
to Step15. Step 11 and onwards do not belong to any technique. These steps are
includedtofacilitatetheuseofSecurityCategorization(seesection4.7)

4.8.1

HowtoconducteachstepofFramework

Mostpartofthesection4.8.1containstextfrom[66]and[88].Mostofthetext
written in before mentioned section also belongs to [66] because there were many
thingswhichwerebetterexplainedinoriginaltextfrom[66].
It should be noted that first nine activities are decomposition of the system for
Performsecurityanalysisactivityofthesystem.Webreakdowntheapplicationto

38

understanduserroles,entrypoints,exitpointsanddataflowinfirstnineactivitiesof
theframework.Theseactivitiesactasaninputforsecurityanalysisofsystem.
4.8.1.1

SpecifyOperationalenvironment
Thisactivityhelpstheteammembersinunderstandingtheoperationalcontextof
thesystem.Considerationofoperationalcontextfacilitatestheteaminestablishing
securityguidelinesandprinciples[66].
An operational worksheet is provided in Appendix A for this activity. Following
important aspects of this activity should also be looked into while performing this
activity.
Identifyrequirementsandassumptionsrelatedtoindividualhosts
Userrightsandauthorizationrelatedtosoftwaresystemisthefocusofthissub
activity [66]. Security policies defined by the organization regarding the use of
particularsoftwarearelistedhere.Moreoverrisksrelatedtotheplatformonwhich
thesoftwareisinstalledmustalsobehighlighted.Forexample:theremaybesome
componentsofOSthatposerisktotheusagepolicyofasoftware.
Inaddition,alloptionalfunctionalitiesandtheirimpactonsecuritymustalsobe
consideredinthissubactivity[66].
Identifyrequirementsandassumptionsrelatedtonetworkarchitecture
Networkresources,networktopologies,existence andconfigurationoffirewalls
are identified in this subactivity. Those things and factors which have any impact
(negativeorpositive),onsecurity,mustbetakenintoaccount[66].

4.8.1.2

Identifyglobalsecuritypolicy
Baseline security requirements act as a reference for security requirement
specifiers. Organizations security policies and basic security services are defined in
ordertohaveclearunderstandingofinternalsecurityprocedures[66].Samplelistof
globalsecurityrequirementsispresentedinAppendixB.
Every global security requirement should be checked for its applicability in the
system. If a requirement is not relevant to the project, it should be explicitly
documented. Baseline for global security policy is created for protecting data
resources.Theseresourcesarefurtherdividedintocategoriesortechnologieswhich
provide guidance about when to apply these technologies and how to apply them
whentheyareusedinaproject.Globalsecuritypolicyisvaluablesinceitprovidesthe
concrete documentation of internal or external procedures that the documentation
teamshouldfollow.Inlargeorganizationsitisusefultohaveasetofbaselinesecurity
requirements for different projects which ease the job for requirement specifier in
long term and provides a path to compare the security posture of different
applicationinorganization.
Foreachsecuritypolicyfollowingthreechecksmustbeperformed[66].
Is the global requirement already addressed by one or more other system
requirements?
Iftheglobalrequirementcontradictsanyexplicitorimplicitrequirementfor
project.
The global requirement does not contradict any requirement but has not
beenaddressedyet.

39

4.8.1.3

Identifyresourcesandtrustboundaries
This activity provides a structured foundation for understanding the security
requirements of a system [66]. This activity includes following important sub
activities.
Identifynetworkleveldesign
Describe network architecture of the system and identify any components that
are located on different logical platform such as client software, middleware and
databases.Amiddlewareandadatabase,whichbothcanpossiblyliveonaseparate
machine,shouldbeidentifiedaslogicallyseparate.
After describing network components and architecture, trust boundaries are
identified e.g. firewall and Individual hosts. For example, Client machines on the
outside are less trustworthy whereas many multiuser systems can have multiple
trustboundariesinternally."Trustboundariesshouldbemappedtosystemrolesthat
canbegrantedleveloftrust[66].Inthisactivityprotectionmechanismisidentified
for resources and data links in the architecture diagram. Moreover, the diagram
shouldbeannotatedwiththesemechanisms.
IdentifyDataresources
Dataresourcesthatmaybeusedbyaprogramareidentified.Inthenextactivity,
individual capabilities related to each resource are identified e.g. identifying
individual database tables, instead of simply the database as a whole. Outcome of
this activity should be documented separately to facilitate security analysis. The
informationmaybeincludedintobusinessrequirements.
Sampleresourcesinclude[66]:
9 Databasesanddatabasetables
9 Configurationfiles
9 Cryptographickeystores
9 ACLs(AccesscontrolLists)
9 Registrykeys
9 Webpages(staticanddynamic)
9 Auditlogs
9 Networksockets/networkmedia
9 IPC (Inter Process Communication), Services, and RPC (Remote procedure
call)resources
9 Anyotherfilesanddirectories
9 Anyothermemoryresource
"Networkmediaisaresourceofitsown[66].Weneedtospecifyhowtoprotect
that datawhenittraversesthemedia.All thecomponents connected tothemedia
arealsoconsideredsuchasdisksandmemories.

4.8.1.4

Identifyuserrolesandresourcecapabilities
Purpose of this activity is to identify system roles and capabilities/resources a
particularrolecanaccess.Thewordcapabilityheremeansthethingsuser(s)maybe
abletodo.Followingmainsubactivitiesareinvolvedinthisactivity.
Identifydistinctcapabilities
Capabilitiesareinterestingoperationsonresourcesthatshouldbemediatedvia
an authorization/access control mechanism. Capabilities are set of operations that
are applied on resources. Capabilities are defined so that system users can have
proper understanding of the system and can perform these operations. To perform

40

these operations different roles are identified on the basis of authorization/Control

mechanism. All the access control mechanisms for operations, user rights and
authoritiesaredefinedinthissubactivity.
Mapsystemrolestocapabilities
System roles and set of capabilities are mapped in this subactivity. This step
helpsinunderstandingwhichsetofcapabilitiesareassignedtowhichusers.Mostof
the time system itself is a set of roles which includes capabilities and can access
them.Exampleofthisisclientserverapplication.
IdentifyAttackerprofile(attackerrolesandresources)
One must have a clear picture of the origin of threat. By knowing the origin of
threat, one can predict the resources attacker may use. Attacker profile must be
documented.
Examplesofdifferenttypesofattackersareasfollows
Insiders People from inside the organization or have access to the
infrastructure.
Script Kiddies People who uses software or existing scripts to exploit
weaknesses.
CompetitorWhomayhaveareasonablebudget.
GovernmentsMayhaveanextraordinarybudgetandresources.
OrganizedCrimeUnitsChoosefewtargetsforfinancialgainnormally.
Activists who target organizations which are not liked (by community or a
groupofpeople).

4.8.1.5

Identifyindepthuserroles,securecapabilitiesandsecurityconstraintsforeach
actor
Eachusersabilitiestointeractwiththesystemandresourcesausercanaccess
are identified. Secure capabilities are separated from insecure capabilities and
explicitly mentioned. Security constraints on each actor with their impact are
identified.Securityconstraintsarealsocheckedfortheirsuccessfulimplementation.

4.8.1.6

Identifyattacksurface
Identify all the entry points to facilitate the analysis. Define all the components
attacker can interact with. Define mechanism through which any one can interact
withthesystemregardlessofhis/herroleinthesystem.Documentallthefollowing
[66]
networkportsopened,
placeswherethefilesystemistouched
anylocalUserInterfaceelements,
anyinterproceduralcommunicationpoints
Any public methods that can be called externally while the program is
running
After identifying entry points, map roles to entry points. Next step is to map
resourcestotheentrypoints.Inmappingrolesallrolesthatcanpossiblyaccessentry
pointsareidentified.Afterthatdocumenttheresourcesthatareaccessiblefromthat
entrypoint.

41

4.8.1.7

Researchandassesssecurityposture
Generally, it is very hard to get technology assessment from vendors because
theyarerarelycooperativeinthisregard.Still,youneedtoknowtheriskassociated
with the software components you are using in your system. Selfassessment sheet
basedoninteractionwiththevendor,whichcanbefilledinbyyouorthevendoris
includedinAppendixA.Worksheetisfilledbyconductingstructuredinterviewswith
vendors.
Worksheetshouldbeabletoanswerfollowingpointsinthisactivity[66].
At a high level, what are the trust boundaries, resources, and roles in the
system?
Hasanindependentassessmentbeenperformedbyarespectedthirdparty?
Andifso,whatbusinessrisksdiditidentify,andwhathaschangedsincethe
assessment?
Whatarethesecurityqualificationsofthedevelopmentteam?
Whatarethemajorareasofriskintheproduct?
What were the security requirements that were used for development
(implicitandexplicit)?
Inadditiontoabovementionedpoints,youmustcollectdatafromcustomersand
user reviews. If possible perform security testing on the component. Above
mentionedstepswillhelpyouindecidingwhethertoproceedwiththetechnologyor
not.

4.8.1.8

Detailmisusecase
MisusecasestechniqueissimilartousecaseexcepttheaimwhereMisusecaseis
meanttodetailcommonattemptedabusesofthesystem[66].DeterminingMisuse
caseisabrainstormingactivityandtherearethreegoodpointsforstructuredbrain
storming[66]i.e.
Thepersonperformingtheactivityshoulddescribehowtheattackerwilltake
advantage of a problem using preexisting knowledge of common security
problems.
The person, performing the activity shall construct misuse cases for each
systemresourcebybrainstormingforeachofthebasicsecurityservicese.g.
authentication,confidentiality,accesscontrol,integrity,andavailability.
Theperson,performingtheactivityshallcreatemisusecasesonthebasisofa
set of existing use cases to ensure that the first two steps did not overlook
anyobviousthreats.
Misuse cases should be described visually and should be documented. Defense
mechanism is identified for every Misuse case. Results are then reviewed with the
stakeholders.
AMisusecaseiscreatedusingfollowingsteps
ConcentrateonnormalactorsandusecasesbypreliminaryIdentificationof
weakpointsinUsecases
Introduce major Misuse Cases to express the intentions of misactors who
intendtoharmthesystem
InvestigatePotentialRelationbetweenMisusecasesandUsecasestoidentify
the nature of threat. Many threats to a system can be achieved through
exploitingnormalfunctionalitye.g.DenialofService
42

TohaveaquickunderstandingofMisuseCasesactivities,pleaserefertoTable13.
MisuseCasestemplatewhichisnecessaryforthisactivityisincludedinAppendixJ
4.8.1.9

Documentsecurityrelevantrequirements
All the business level and functionality related security requirements are
documented in this activity. All the requirements must have following basic
properties
Specific: There must be are no ambiguities in the requirement. Consistent
terminologiesshouldbeusedbetweenrequirements.
Measurable:Itshouldbepossibletodeterminewhethertherequirementhas
beenmet,throughtesting.
Reasonable: One should conduct some validation to determine whether
meeting the requirement is physically possible keeping in mind the project
constraints.
Traceable: Requirements should also be isolated to make them easy to
track/validatethroughoutthedevelopmentlifecycle.
Documentexplicitbusinessrequirements
Issues must be communicated to customers earlier in order to avoid problems
after deployment as customers are not always aware of the security problems.
[66,88]:
Recommendedauthenticationsolutions
PersonaldatamustbekeptPrivate(PrivacyConcerns).
RecommendedConfidentialitysolutionsfornetworktraffic.
Confidentialitysolutionsforlongtermstorageofkeydata.

Developfunctionalsecurityrequirements
Specifyprotectionrequirementsrelatedtothebasicsecurityserviceslike
Authorization(accesscontrol):Whatprivilegesondatashouldbegrantedto
thevariousrolesatvarioustimesandwhatmeasureshallbetakentoenforce
thepolicy[66,88].
Consider operating environment resources which need to be protected
suchasadministrativeprivilegesonahostmachine[66,88].
Authenticationandintegrity:HowIdentitydeterminedtogainofaccesstoa
resource? Is, the resource strongly bound to an identity? For example do
individual messages need to have their origin identified, or can data be
anonymousoncommunicationchannels[66]?
Confidentiality (including privacy): Confidentiality mechanisms such as
encryptionareusedtoenforceauthorization.Whenaresourceisexposedtoa
user,whatexactlyisexposed:theactualresourceorsometransformation?
[66]
Availability:Requirementsshouldtakeintoaccounthowavailablearesource
shouldbeforauthorizedusers[66,88].
Accountability(Includingnonrepudiation):Logfilesneedtobespecifiedand
protected.[66,88].

Explicitlylabelrequirementsthatdenotedependencies

43

All external dependencies should be discovered in requirements to

reasonabledegree[66,88].
All thirdparty components and required functionality in the operational
environmentspecificationshouldbespecified[66,88].
Any requirements denoting external dependencies should be explicitly
labeledtofacilitatesubsequentanalysis[66,88].

Determineriskmitigations(compensatingcontrols)foreachresource
Businesslevelresourcesareidentifiedthatneedtobeprotectedi.e.,whatare
theriskstoindividualresourcesandhowtherisksneedtobeaddressed[66,88].

Resolvedeficienciesandconflictsbetweenrequirementsets
Inordertodetermineomissionsandconflicts,setofrequirementsaremappedto
othersetsofrequirements[66,88].
4.8.1.10 Performsecurityanalysisofsystemrequirementsanddesign.
Inordertoperformsecurityanalysisofasystem,followingoutputsfromprevious
activitiesareneededasaninputforthisactivity
Aspecificationoftheoperationalenvironment;
Ahighlevelarchitecturaldiagramindicatingtrustboundaries;
Aspecificationofresourcesandcapabilitiesonthoseresources;thismay
beincorporatedintotherequirements;
A specification of system users and a mapping of users to resource
capabilities;thisalsomaybeincorporatedintotherequirements;
Anattacksurfacespecification,towhateverdegreeelaborated;
Dataflowdiagrams,ifavailable;
Anattackerprofile(again,thismaybepartoftherequirements);and
Misusecases,ifany.[66]
Securityanalysisconsistsofsetofsubactivitiesi.e.
Developanunderstandingofthesystem
Todevelopanunderstandingofthesystembeforesecurityanalysisisimportant.
Documentationshallbereviewedforexistinghighlevelsystem.Itisgenerallybestto
haveaprojectoverviewfromacustomercentricperspectiveontheproject.
DetermineandValidatesecurityrelevantassumptions
Any assumptions that are made about the attacker and environment in which
system is deployed should be validated and then incorporated into project
documentation[66,88].
ReviewNonsecuritysecurityrequirements
Findoutanysecurityimplicationsthatarenotproperlyaddressedinthesecurity
requirements. Also look into requirements that are not explicitly aimed at security.
Throughdataflowdiagramwecanassesstheimpactoneachsecurityservicewhile
tracingresourcesthatarerelevanttoarequirement[66,88].
AssesscompletenessofSecurityrequirements
For each resource and capability, security services must be addressed with
securityrequirements.Thisisdonethroughacorrelationmatrix,whererequirements
areononeaxisandsecurityservicesoncapabilities(orresources)areonanotheraxis
[66].Appropriateboxesforeachsecurityrequirement,whererequirementshavean
impact, are marked in the matrix. This matrix assesses the completeness of
requirements,i.e.ifthesecurityserviceisadequatelyaddressed.

44

IdentifyThreatsonAssets/Capabilities
All potential security threats should be identified and documented for each
securityserviceoneachcapabilitybyiteratingthroughassetsandcapabilities[66,88].
Determinelevelofrisks
Decisionmakingprocessofanattackercanbemodeledusingthreattrees.Look
particularly for ways that multiple conditions can be used together to create
additionalthreats[66].
Determineriskmitigationsforeachresource
Mitigation steps for each threat indentified in the previous activity should be
explicitly mentioned along with any possibility of reproducibility of the particular
threat.
Evaluatefindings
Security auditor should report any security risks that may not have been
adequately addressed in the requirements. Auditor should recommend a preferred
strategy for implementing risk mitigation and should discuss any alternatives that
could be considered. If any conflicts or omissions are brought to light during
requirement review, security auditor should make recommendations that are
consistentwithprojectrequirements.
4.8.1.11 Updatesecurityrequirementsdocument
Based on the evaluation of findings of Security analysis phase, security
requirementdocumentisupdated.Allrequirementsmustbementionedwithallthe
traceabilityinformation.
4.8.1.12 Identifyresources,entrypoints,functionalities,assets,servicesandactorsforthe
system
All
resources,
entrypoints,
functionalities,
assets,
capabilities,
resources,
servicesand
actors
shallbeexplicitlydocumented
4.8.1.13 Supposeallthethreatsmentionedinthecategorizationaretrueforallresources,
entrypoints,functionalities,assets,servicesandactorsforthesystem
Allthreatsmentionedinsecurityrequirementscategorization(seeAppendixC)
shouldbesupposedtrueforeverypointinthelistmentionedinlastactivity.
4.8.1.14 Validatethreatsforeachresource,entrypoint,functionality,asset,serviceand
actorsforthesystem
For each resource, entry point etc. threats which were supposed true are now
validated. For example, threat that is not applicable to a particular resource is
omittedforthatparticularresource.EachthreatshallbeconsideredasaMisusecase
anddocumentedbyfillingMisusecasetemplateforeachthreatseparately.
Above mentioned step is performed in iteration until all the threats are
adequately validated. Threats that are not omitted in the process will be the valid
threatstothesystem.
45

4.8.1.15 Updatethedocument
Securityrequirementsformitigationofeverythreat/Misusecaseinprevious
activitymustbedocumentedwithtraceabilityinformation.

46

EXPERIMENT
WehavefollowedWohlinet.al[91]guidelineforexperiment.InthisSection,we
haveexplainedthedetaildescriptionofexperimentperformedforthisresearch.We
haveexplainedExperimentdefinition,plan,Designandexecutionofourexperiment.
Thisexperimentisperformedtomeasuretheapplicabilityofourframeworks.We
intend to suggest improvements in the framework on the basis of feedback and
resultsfromtheexperiment.

5.1

Experimentdefinition

5.1.1

Objective

Objective of this experiment is to check whether by combining formal and

informal security requirement elicitation techniques we yield better results than
usingformalorinformalsecurityrequirementelicitationtechniquealone.

5.1.2

Context

Thisexperimentwascompletedintwodaysandinvolvedsixstudentswhowere
divided in three groups i.e. two members per group. All six students were software
engineeringstudentswhohavestudiedrequirementengineeringcourseandhaveat
leasttwoyearsofindustrialexperience.Allsixstudentsweresupposedtoconducta
setofactivitiesinaspecificamountoftime.Theseactivitieswereselectedfromthe
activitiesofourframework,CLASPandMisusecasetechnique.Aftertheexperiment,
allthesixstudentswereaskedtofillafeedbackform(seeAppendixI).
WeconductedtheexperimentwithCLASP(aformaltechnique),MisuseCases(an
informal technique) and Framework. We did not Include Secure TROPOS in the
experimentduetothreemainreasons.
1. Purpose of the experiment was to compare the proposed Framework with a
formalandanInformaltechnique.CLASPbeingaformaltechniqueandMisuse
Casesbeinganinformaltechnique,fulfillthepurposeoftheexperiment.
2. Secure TROPOS, as mentioned earlier, has sequential activities which are
strictlyconnectedtoeachother.
3. In addition, many activities of Secure TROPOS focus on phases other than
requirement gathering of software development life cycle whereas our focus
wasonlyonrequirementelicitation.
ThereforewedidnotincludeSecureTROPOSintheExperiment.
Limitedavailabilityofstudents(subjects)compelledustoselectasmallsystem.
Wesenttwodocumentsi.e.SystemsdetaildescriptionandActivitiesdescriptionto
subjectsviaemailtwodaysbeforeconductingtheexperiment.Purposetosendthe
document was to give brief overview of activities and software system before
experiment. Later we had discussions with our subjects via video conferencing in
ordertoclarifythedoubtsandquestionsregardingsystemandactivities.
Keeping in mind the lack of practice of students (subjects) to perform the
activities, we conducted one hour pilot exercise before conducting the experiment.
Eachactivitywasassignedaspecificamountoftime.
On first day of experiment i.e. 2012March29, the students were randomly
divided in groups of two to perform the activities. It took total 6 hours to perform
firstpartoftheexperiment.

47

5.1.3

SampleSpace

OursamplespaceconsistsofsoftwareengineeringstudentsinBTH.

5.2

Experimentplanning

5.2.1

Purpose

Purpose of study is to observe effectiveness of our security requirement

elicitation framework with respect to widely used formal and informal security
requirementelicitationtechniquesi.e.CLASPandMisuseCases.

5.2.2

Qualityfocus

Our study is focused on improving the quality of software by highlighting

importanceofsecurityinearlyphaseofsoftwaredevelopmentlifecycle.

5.2.3

Perspective

Thisstudyisbeneficialforsmallandmediumsizesoftwareorganizations.
Softwarecompaniescanbenefitfromtheresultofthisstudy.Attackersperspective
towardssoftwareprovidesdetailunderstandingofvulnerabilitiesinsoftware.
Developingsecuresoftwarecanimprovebusinessreputationandpublicconfidence
insoftware.

5.2.4

Contextselection

Experiment was conducted in controlled environment with the help of six

studentswhoweredividedinthreegroupsi.e.twomemberspergroup.Toperform
the experiment we provided detail of a software system and activities of our
framework.Softwaresystemanditsdescriptionwereselectedfrompaper[66].We
alsoprovidedthemMisusecasetemplate.

5.2.5

Hypothesisformulation

NULLHYPOTHESIS(H0):Formalapproachesdonotproducebetterresultswhen
integratedwithinformalapproachi.e.Misusecases.
ALTERNATIVEHYPOTHESIS(H1):Formalapproachesproducebetterresultswhen
integratedwithinformalapproachi.e.Misusecases.

NULL HYPOTHESIS (H0): The proposed framework is not better than other
securityrequirementelicitationtechniques.
ALTERNATIVE HYPOTHSIS (H1): Proposed framework is significantly better than
theotherrequirementelicitationtechniques.

5.2.6

Variableselection

Independentvariablesinthisexperimentareasfollowing:
FrameworkActivities
FrameworkActivitiesGuidelines.
SoftwareSystem
Misusecasetemplate
Misusecaseguidelines.
ClaspActivities
ClaspGuidelines
DependentVariablesinthisexperimentareasfollowing:
Resources
Trustboundaries

48

 UserrolesandResourcecapabilities
SecurityConstraintofeachactor
AttackSurface
Detailmisusecase
SecurityRequirements
SecurityAnalysis
As shown above; independent variables are the inputs to experiment where as
dependentvariablesaretheoutputofexperiment.Asexperimentisconductedin
a controlled environment, dependent variables vary according to inputs of
experiment(Independentvariables).

5.2.7

Subjectselection

We selected academic Subjects for our experiment as a population. We have

conductedprobabilitysamplingforourexperiment.Populationwasthestudentswho
have studied requirement engineering course at BTH and have some industrial
experience. Subjects were selected randomly from population. Six students were
dividedinthreegroupsi.e.twomemberspergroup.OneGroupperformedactivities
of CLASP and the other two groups performed activities of Framework and Misuse
cases,respectively.

5.3

Experimentdesign

5.3.1

Designprinciple

We have used three basic design principles Randomization, Balancing and

Blockinginourexperiment.
It was not possible to recruit professionals for this experiment due to time
constraints and the availability of professionals. Therefore we decided to include
software engineering students that have formal trainings in security requirements
engineering and have some industry experience.Randomization is achieved by
random selection of software engineering students who have studied requirement
engineeringCourseatBTH.Samenumberofpersonsineachgroupandsameamount
of total time for each technique justifies balancing i.e. two members per group
workingforapproximately10hours.Tocovertheblockingdesignprinciplewemade
surethatoutofthreegroups,nogroupshouldconsistofonlyinexperiencedpeople
i.e. one out of two students in each group must have 23 years of industrial
experience.

5.3.2

Designtype

Designtypeofourexperimentisonefactorwiththreetreatments.
Table26:Experimentdesigntype
SUBJECT
2
2
2

TREATMENT1
X

TREATMENT2

TREATMENT3

X
X

AccordingtoourExperiment,Treatment1isFrameworkactivities,Treatment2is
CLASPactivitiesandTreatment3isMisusecaseactivities.FactorfortheExperiment
isSecurityRequirements.

49

5.3.3

Instrumentation

Inourexperimentwehaveusedobjects,guidelinesasinstrumenttomonitorand
guideinvolvedparticipants.
Objectwere
Documentation of software system on which activities were to be
performed
Misusecasestemplate.
Guidelineswerehowtoperformactivitiesinallocatedtime.
Descriptionofeachactivityofframework,CLASPandMisusecase
Attheendofexperimentaskedthemtofillaquestionnaire.
InstrumentsusedinourExperimentwere:
StudentsfromBTH
Libraryrooms
Documentsofsoftwaresystem
Misusecasetemplate
Guidelinesofeachactivities
Questionnaire
Trainings
Measurement
NumberofSecurityRequirements

5.3.4

Validityevaluation

Beforeperformingtheexperimentweconductedpilotstudywithtwostudentsto
haveabasicideaabouttimetoconducttheexperimentandfeasibilityoftechniques.
During the pilot study, we observed that the participants must have time to
understand the tasks and ask questions. Moreover; minimum time to conduct the
experimentwithasmallsystemis11hours.Wedesignedourexperimentonthebasis
ofobservationsduringpilotstudies.
Beforeexecutingtheexperimentthereweretwothings,wehadtotakecareof
twothingsi.e.
1. Inourexperiment,frameworkactivitiestakemoretimeascomparedtoother
techniques. One could argue that since framework is taking more time, so
onecanelicitmorerequirementsfromframework.
2. Wearedealingwithhumanbeingswhohavevaryinglevelofcompetencies.
Sowhatistheguaranteethatpeopleworkingwithframework,CLASP,Misuse
Casehavethesamelevelofcompetencytoworkwithrequirements?There
maybeapossibilitythatpeopleworkingwithCLASPhavelessunderstanding
than people working with framework. Therefore we are going to get more
outputfromactivitiesofframework.

In order to ensure transparency and justice with all the three methods i.e. Our
Framework,CLASPandMisusecase,wetooktwostepsi.e.
1. Assignsameamountoftimetothetechniquesi.e.Weassignedthesame
amountoftotaltimetoallthethreemethods.Itisbecausebylooking15
activities of framework, one can easily tell that it requires more time
whereasCLASPwith10andMisusecasewiththreeactivitieswouldtake
far less time. Since we are concerned with the number of security
requirements and not time so we assign equal amount of time to
Framework, CLASP and Misuse case. Each group using one of these
methods has equal amount of time to elicit security requirements (See
Table30andTable31).

50

2. Combine input from Team1 and Team2 and provide it to Team2 for
securityanalysisusingCLASPtechnique(explainedinnextsection).

5.4

Experimentoperation
Total subjects on first day of our experiment are six people which are assigned
Treatments.
On the first day, experiment was conducted in university (BTH) group rooms
H2016, H206C and H206D on 2012 March 29th. Two person i.e. each group was
assignedaseparategrouproom.Weprovidedthemdescriptionofasoftwaresystem
and activities. One group performed activities of framework and the other groups
performed activities related to CLASP and Misuse case. All the groups were given a
totaltimeof5hoursand15minutestoperformtheactivities.
Group performing framework activities were supposed to perform 6 activities.
For first 2 hours they performed 4 activities. Duration of first four activities was 30
minutes each. After the lunch break they were suppose to perform remaining two
activities.Durationoftheremainingtwoactivitieswas1hour.
GroupperformingCLASPactivities,hadtoperformfiveactivitiesandtheduration
wassameasforgroupperformingframeworkactivities.GroupwithMisusecasewas
giventhesameamountoftimealso(SeeTable30andTable31).Weprovidedthem
Misuse case template and the description of activities. There were total three
activities of Misuse case. Team1s first task was to understand the case and the
activities.BasedontheirunderstandingtheyfilledMisusecasetemplate.
On the second day of experiment, we conducted the second part of the
experimentwiththesamesixpeopleagain.TheonlydifferencewasthatTeam2and
Team3 i.e. group working with activities with CLASP and Misuse case were free to
iterate and repeat the procedure of the activities they have performed. Whereas
Team1i.e.thegroupworkingwithframeworkperformedtheremainingactivitiesof
theframework.Ontheseconddayi.e.2012March30thexperimentwasconductedin
university(BTH)grouproomsH2016,H206CandH206D.Team1,Team2andTeam3
were sat in different rooms. In order to neutralize the threat of different level of
competencyofstudents,wedecidedtogivemaximumbenefittoCLASP.
WehavealreadydiscussedthatoutputsoftheactivitiesperformedduringDay1
ofexperimentareinputforsecurityanalysisinCLASPandinframework.Sowegave
maximumadvantagetoCLASPbyprovidingoutputofactivitiesperformedbyTeam1
andTeam2,duringfirstdayoftheexperiment,forsecurityanalysisinCLASP.
The group working with framework continued with what they got after
performingtheactivitiesonDay1.

5.4.1

SoftwareSystemforExperiment

Duetolimitationsinaccesstoindustrialresources,wehadtoselectasoftware
system by using which we can conduct an experiment in a short time. For that
purpose,weconsideredmanysoftwaresystemsandchoicewasdifficult.Wedecided
toselectasystemonwhichasecuritystudyisalreadyconductedwhichwillalsohelp
us in comparing our results with the results from the study. We considered an
examplefrom[66]i.e.
5.4.1.1
5.4.1.1.1

MonolithicMainframe
Glossary

51

CICS:CustomerInformationControlSystemAtransactionserverwhichrunson
IBMmainframeunderz/OS.
z/OS:64bitoperatingsystemformainframeproducedbyIBM.
RAFC:ResourceAccessControlfacility:AnIBMsoftwareproductforsystems
securitythatprovidesauditingfunctionalityandaccesscontrol.
VSAM:VirtualStorageAccessMethod:AnIBMfilesdiskstoragemethod.
3270terminals:IBMdisplaydevicesusedtocommunicatewiththemainframe.
5.4.1.1.2

SystemDescription
A leading insurance company has applications which process claims by its
customers. Application users are customer service representatives who either
createorupdateclaimsinformationbasedontelephoneconversationswiththeir
customers.AllincomingclaimsareprocessedbytheapplicationsonasingleIBM
mainframemachine.

Table27:Activityflow
Step:

Description:

TheuserperformsaninitiallogonandispromptedforuserIDandpassword.

IftheuserIDandpasswordaresuccessfullyentered,aCICSsessionwiththeIBMmainframeisinitiated

TheapplicationuserinvokesthedesiredCICStransaction.

Toobtainauthorizationtorunthetransaction,theCICSdeterminespermissionfortheinvokinguser

Theapplicationuser(i.e.,customerservicerepresentative)requestsaccountinformationforanexisting
customer

Theapplicationreadsaccountrecord(s)forthespecifiedcustomer.Intheprocessofreadingthedata,the
operatingsystemdetermineswhethertheuserispermittedtoreadtherelevantVSAMfile.

IfRACFauthorizationsallowit,therecordisreturnedtotheapplicationfromVSAM.

Thecustomerdataisreturnedtotheapplicationuserandisdisplayedonthe3270terminal

Theapplicationuserentersrequiredinformation eithercreatinganewclaimoraddingfurther
information(asinstructedbythecustomer,specificallyrelatingtotheinsuranceclaim).

10

Theapplicationupdatesaccountrecord(s)forthespecifiedcustomer.Intheprocessofupdatingthedata,
theoperatingsystemdetermineswhethertheuserispermittedtoupdatetherelevantVSAMfile.

11

IfRACFauthorizationsallowit,therecordisupdatedintheVSAMfile.

12

Theapplicationsatisfiestherequestforupdatingthecustomerclaimdataanddisplaysconfirmationofthe
updateonthe3270terminal.

AlsoseeAppendixKandAppendixLtoseeSequencediagramandUseCase
diagramofthesystem.

5.4.2

Experimentexecution

FollowingactivitieswiththesequencedescribedinTable30andTable31,were
performedbythegroupsnamedasTeam1(performingFrameworkactivities),Team2
(CLASPactivities)andTeam3(Misusecaseactivities).
DetailschedulefortwodaysofexperimentisprovidedinTable30andTable31.
Durationofexperimentduringfirstdaywas5hoursand15minutes.Activitiesduring
seconddaytook4hoursand50minutesoftime.

Table28:PlanforDay1ofExperiment

PilotExercise
QuestionandAnswers
Team1 Task
&
SpecifyOperationalEnvironment
Team2 IdentifyGlobalSecurityPolicy

Duration
50Minutes
10Minutes
20Minutes
15Minutes

PilotExercise
QuestionandAnswers
Team3 Task
MisuseCaseActivity1
MisuseCaseActivity2

Duration
50Minutes
10Minutes

20Minutes
55Minutes

52

IdentifyResourcesandTrustBoundaries
Total
LunchBreak
Identifyuserrolesandresourcecapabilities

60Minutes
155Minutes

Identifyindepthuserroles,secure
capabilitiesandsecurityconstraintsforeach
actor(OnlyperformedbyTeam1)
Identifyattacksurface
Researchandassesssecurityposture
Detailmisusecase
Documentsecurityrelevantrequirements
Total

20Minutes

MisuseCaseActivity3
20Minutes
Total
155Minutes
LunchBreak
FillMisusecase
150Minutes
Template
Total
150Minutes

20minutes

20Minutes
30Minutes
60Minutes
60minutes
150Minutes

Table29:PlanforDay2ofExperiment
Team1

Task
Perform
security
analysis
of
system
requirements
anddesign.
Update
security
requirements
document.
Total

Duration
120
Minutes

30
Minutes

150
Minutes
LunchBreak

Suppose all the

threats
mentioned in
the
categorization
are true for all
resources,
entry points,
functionalities,
assets, services
and actors for
thesystem.
Validate
threats
for
each resources,
entry points,
functionalities,
assets, services
and actors for
thesystem.
Update
the
document.
Fill
Questionnaire
Total

30min

Team2

Task
Perform
security
analysis
of
system
requirements
anddesign.
Update
security
requirements
document.
Total

Duration
120
Minutes

Iterateallor
anyactivityof
CLASP

100
Minutes

Update the
document.
Fill
Questionnaire
Total

30min

Team3

Task
Iterateallthe
activitiesof
MisuseCase

Duration
160
Minutes

30Minutes

160
Minutes
LunchBreak

Total

160
Minutes
LunchBreak

Iterateallor
anyactivityof
MisuseCase

100
Minutes

70min

30min
10
Minutes
140
Minutes

10Minutes
140
Minutes

Update
the
document.
Fill
Questionnaire
Total

30min
10
Minutes
140
Minutes

ToseeOutputfromMisusecasestechniquealone,refertoAppendixG.
5.4.2.1

OutputduringeachactivityofFramework
Wehavelistedoutputoftheactivities,indocument,insuchawaythatthis
sectioncoversoutputfromallthetechniques.

53

Sincefirst10activitiesoftheframeworkaretakenfromCLASP(except5.4.2.1.5)
itisuselesstorepeattheoutputof9activitiesofCLASPinthedocument.Thereader
canassumethattheoutput5.4.2.1.1upto5.4.2.1.10issameforCLASPand
Framework.FinaloutputfromCLASPisincludedinAppendixDandAppendixE
whereasoutputofMisuseCasesismentionedinAppendixG.
Outputmentionedinsection5.4.2.1.11to5.4.2.1.15istheoutputonlyfrom
Framework.FinaloutputfromFrameworkaloneismentionedinAppendixF.
5.4.2.1.1

SpecifyOperationalEnvironment(Implementationscenario)
The IT organization of the insurance company develops its own applications in
order to gain an advantage in a highly competitive and quickly changing business
environment.TheapplicationsinquestionaredevelopedinCOBOLtorununderCICS
on a z/OS IBM mainframe machine. These customwritten applications enable the
insurance company to respond rapidly to the timecritical needs of its client. The
usersutilize3270terminalsfromwheretheylogondirectlytoCICS.
Itshouldbekeptinmindthatdataonthediscisnotencrypted.

5.4.2.1.2

IdentifyGlobalSecurityPolicy
Customersdataisvaluabletothecompanysoonlyauthorizedpeopleshouldbe
ableviewandeditcustomersdata.Securitybaselineanditsdescriptionare
mentionedinTable32.

Table30:SecurityBaseline

Authorization

Authorizationalsocalledaccesscontrol.Authorizationsaregiventouserstoaccessthesystemonthe
basisofidentityandaregenerallypolicydriven.Policiesareenforcedbyaccesscontrolmechanismto
performoperationsonresources.Policiesdependupontheindividualactionsperformedonresources.
Forexampleaccesscontroldecisionisgenerallytakenonthebasisofuserspecificpolicy.

Authentication

Authenticationisusedtoestablishidentityofcommunicationpartners,owner,creatoretcofdata.
Authenticationmustbeperformedatlogintimefornetworkconnectionsbutonemustalsoperform
ongoingauthenticationsforlifetimeofconnection.Differentcategoriesofauthenticationareasfollows:

Confidentiality

Thingswhichareknownsuchaspasswordsorpassphrases.
ThingsyouhavesuchascreditcardorRSASecureID(Authenticationtokens).
Thingsyouaresuchasfingerprints,voiceprintandretinalscans.
Purposeofconfidentialityistokeepdatasecrettoallunauthorizedparties.Datamustbekeptsecretor
encryptedinbothwayslikewhendataisbeingtransmittedonanetworkandwhenitisbeingstored,
longtermorshortterm.

Integrity

Dataintegritymeanstokeepthedataasinform asitwasintendedtobe.Forexampleinphysicallink
layerontrustedmediawhereerroroccursbutnotrelatedtosecurityerrors.

Availability

Delayofdatacancausetheavailabilityproblemorifproblemisduetomaliciouslyisknownasdenialof
serviceattack.

Accountability

Systemshouldloginformationabouttheoperationsperformedbythesystemuserinordertoreview
thisinformationwhenrequired.Systemusersmustbeaccountablefortheactionstheyperform.

Nonrepudiation

Whenthereistwopartycommunications,eithersidescanprovetothemselveswhetherdatacomes
fromauthenticsource.Problemoccurswhenthirdpartyinvolves.Forthismessagecanbeestablished
fromoriginalsendertothirdpartieswhichiscallednonrepudiatable.

5.4.2.1.3

Identifyresourcesandtrustboundaries
TrustBoundaries
Useri.e.customerservicerepresentativeconnectstoseverthrough3270
terminalbyenteringvalididandpassword.

54

User can view customers information only if the user has authority to
viewcustomersinformation.RACFperformsauthorizationcheckbefore
lettingtheuserviewtheinformation.
Usercanupdatecustomersinformationonlyiftheuserhasauthorityto
update customers information. RACF performs authorization check
beforelettingtheuserupdatetheinformation.
Authorization is called access control and Authentication is used to
establish identity of communication partners. Both authorization and
authenticationchecksareperformedbyRACF.
Thereisnoremoteaccesstoserver.Allusersaccesstheserverthrough
3270terminalswithinsystemboundary.

Identifynetworkleveldesign
Figure7:ComponentArchitectureDiagram

Business applications, security system and database are located on one

mainframeserver.Mainframeserverisaccessedbycustomerservicerepresentatives
using3270terminals.Thisshowsthatthesystemisimplementedusingstartopology.

Table31:ComponentArchitecture

55

Component
User

DescriptionofComponent
TheapplicationusersarecustomerservicerepresentativesoftheinsurancecompanywhologontoCICS
runningunderz/OSonasingleIBMmainframe.Theusersarelocatedwithinafacilityoftheorganization
i.e.,noremoteaccessisrequired.
Thisisacustomapplicationdevelopedwithintheorganization i.e.,itisnotapackageapplication.
TheapplicationdatainquestionislocatedinVSAMfileclusteronthesingleIBMmainframemachine.
Theelementsofthesecuritysystemare:
RACFsignonsecurity;
RACFauthorizationtoexecuteCICStransactions;
RACFauthorizationtoread/updateVSAMfilesdata.

Application
Data
Security
System

IdentifyDataresources
Systemsresourcesalongwiththecapabilitiesarementionedinthetablebelow
(seeTable34).Capabilitiesaretheresourcesaresourcesoranactorcanaccess

Table32:Systemresourcesandcapabilities
Resource
Name
CICS

Description

Capabilities

CustomerInformationControlSystem Atransaction
serverwhichrunsonIBMmainframeunderz/OS.

Canaccessandperformoperationon
databaseusingVSAM.Communicates
withRACFthroughz/OS.
Controlsinterprocesscommunication
onMainframei.e.betweenCICSand
RACF.
PerformsAuthenticationandAccess
Controlchecks.Keepslogoftheactivities
performed.
Establishesamechanismtoaccessdata
base.
N/A

z/OS

64bitoperatingsystemformainframeproducedbyIBM.

RAFC

ResourceAccessControlfacility:AnIBMsoftwareproduct
forsystemssecuritythatprovidesauditingfunctionality
andaccesscontrol.
VirtualStorageAccessMethod:AnIBMfilesdiskstorage
method.
IBMdisplaydevicesusedtocommunicatewiththe
mainframe.
Customerservicerepresentative.

VSAM
3270
terminal
User

Network
Medium

Customer

LANi.e.Allstations(3270terminal)areconnectedby
cable(orwireless)toacentralpoint,suchashubora
switchwhichisthenconnectedtoaMainframe
computer.
Apersonwhointeractswiththecustomerservice
representativeoverthephone.

AccessesDatabaseandperforms
operationsondatabasethroughCICS,
using3270terminals.
Actsasamediumcommunication
mediumbetween3270terminaland
Mainframesever.
Theycanrequestcreation,searchand
update,butthistaskishandledby
customerservicerepresentative.

5.4.2.1.4

Identifyuserrolesandresourcecapabilities
Itshouldbenotedthatallcommunicationbetween3270terminaland
mainframe,involvesLocalAreaNetwork.
User(Customerservicerepresentative)
Resources:3270terminals
Table33:User'scapabilities
CAPABILITIES
LOGIN
VALIDATEUSER
READCUSTOMERDATA
UPDATECUSTOMERDATA

RESOURCESINVOLVED
AUTHENTICATEDBYRACF
AUTHENTICATEDBYAPPLICATIONANDRACF
RACF+VSAM
RACF+VSAM

Application(Transactionsystem)
Resources:CICS
Table34:Application'scapabilities
CAPABILITIES
ACCESSCUSTOMERDATA
AUTHENTICATEREQUEST
UPDATECUSTOMERDATA

RESOURCESINVOLVED
RACF
RACF
RACF+VSAM

56

RETURNPROCESSEDDATATO3270
TERMINAL

3270TERMINAL

Accesscontrolmethod(VSAM)
Table35:Accessmethodcapabilities
CAPABILITIES
INITIATEDBYCICS

RESOURCESINVOLVED
RACF,Z/OS,CICS

AttackersProfile
Attackerisaninsiderwhohasphysicalaccesstoterminal3270andMainframe.
Thisinsidermaybeacustomerservicerepresentativeorapersonwhohasaphysical
accesstotheinfrastructure.
Mostprobably,theattackerwillusebruteforcetechniquetoenterthesystemor
trytoexploitabadprogrammingpracticesuchasstack/bufferoverflowattack.

5.4.2.1.5

Identifyindepthuserroles,securecapabilitiesandsecurityconstraintsforeach
actor
Mainroleinthesystemisoftheuseri.e.Customerservicerepresentative.Inan
idealcondition,auserischeckedatthreepointsinthesystemi.e.
1. Atthetimeoflogini.e.Authentication/identitycheck
2. Attempttoviewcustomersdatai.e.Authorizationcheck
3. Attempttoupdatecustomersdatai.e.Authorizationcheck
Abovementionedarethesecurityconstraintsontheuser.

Userssecurecapabilitiesare
Login,
Accesscustomersdata,
Updatecustomersdata
Customerservicerepresentativehaveaccessto3270terminal

Usersinsecurecapabilitiesare
Loginwithoutauthentication
BypassCICS,
BypassRACFandaccessVSAM,
BypassRACFandaccessCICS,
PerformoperationonVSAMwithoutauthenticationandauthorization

5.4.2.1.6

Identifyattacksurface
Mainentrypointsforanattackare3270terminalandphysicalports.
AnybodywhohasphysicalaccesstoMainframecancopydatadirectlyfrom
MainframesincedatastoredinMainframeisnotencrypted.
IfRACFissomehowbypassed,itwillbeeasytoperformoperationonthe
datausingVSAM.Entrypointinthiscasewillbe3270terminal.
Insecurepublicmethodswhichcanbemanipulatedfrom3270terminalscan
poseathreattothesystem.
DisablinginterprocesscommunicationbetweenCICSandRACFmayputthe
systemindanger.

5.4.2.1.7

Researchandassesssecurityposture

57

CertaintechnologieslikeRACF,CICS,VSAMetc.areusedinthesystem.Issues
relatedtothesetechnologiesaregatheredfromonlinereviewsofpeoplewhohave
beenworkingwiththesetechnologies.Issueswiththesetechnologiesaredefinedin
ISSUESColumn.

Table36:Technologiesandproblems
COMPONENTS
RACF

Z/OS

VSAMDiskStorage
CICS

ISSUES
ThestandardRACFproductincludesutilitiesandcommandstohandleMostofthesituations
whichsecurityadministrators,auditors,andtechnicalstaffarelikelytoencounter.However,
someofthesefacilitiesaredifficulttouseortaketoolongtoconsiderusingthemonadaily
basis.Asaresultofthissomeinstallationshavebeenforcedtodeveloptheirownprocedures
fordealingwiththesesituationsandothershavebeenunabletoaffordtheresourcestodeal
withthemonaregularbasis.
ConfigurationIssues.
Neitherz/OSnortheMVSfamilyofoperatingsystemsprovidessecurityaspartoftheoperating
system.TheyrelyonExternalSecurityManagers(ESMs)toprovidesecurity.Whenthe
operatingsystemreceivesarequest,thatrequestisdivertedbytheSecurityAuthorization
Facility(SAF)withinz/OStoanESM.SAFdirectscontroltoeitherorboth:
AnESMsuchasRACForACF2.
Anorganizationsuppliedprocessingroutine.
Unmanageddiskstoragecanresultinsystemoutages.
Costofmanagingstorageis4to10timestheinitialcostofstorageacquisition.
CICShasstoppedrunning.TherearethreemainreasonswhyCICSmightunexpectedlystop
running:
TherecouldbeCICSsystemerrors.
CICScouldbeinawaitstate.Inotherwords,itcouldhavestalled.
Aprogramcouldbeinatightloop.
CICSisrunningslowly.Mainreasonsare:
Systemislightlyloaded;apoorlydesignedtransactioncouldbethecause.

5.4.2.1.8

DetailMisuseCase
ToseeOutputfromMisusecasestechniquealone,refertoAppendixG.
Table37:MisuseCase
Field
Name
Summary
Date
Author
BasicPath
AlternativePath
CapturePoint
ExtensionPoint
Triggers
Preconditions
Assumptions
Postconditions
WorstCaseThreat
Preventionguarantee
Detectionguarantee
RelatedBusinessRule
PotentialMisuserProfile
Stakeholders
Scope
AbstractionLevel
Technology and Data
Variations
Goal
Dependencies
SecurityConstraints

Description
Logininwithoutvalidcredentials
Bypassingsecurityprotocols
120329
Farukh&waqas
3270terminaluser.sendrequesttoCICS.
DirectaccesstoCICSwithout3270terminals.
RACF
Directaccess
DeactivatedRACF
DeactivatedRACF
RACFnotworking,notauthenticatingtherequest.
AccesstoVSAM
Dataintegrityimplications
RACF
CICS
Preventunauthorizedaccess
Accessotherthancustomerrepresentation
Analysts
Plannedcomputerizedinfosystem
Subfunction
LAN

Field

Description

Validation
Analyststocustomerrepresentation
AccessGrant.

Table38:MisuseCase

58

Name
Summary
Date
Author
BasicPath
AlternativePath
CapturePoint
ExtensionPoint
Triggers
Preconditions
Assumptions
Postconditions
WorstCaseThreat
Preventionguarantee
Detectionguarantee
RelatedBusinessRule
PotentialMisuserProfile
Stakeholders
Scope
AbstractionLevel
Technology and Data
Variations
Goal
Dependencies
SecurityConstraints

5.4.2.1.9

CSRUpdate
CSRhasnegativeintentionstoupdatecustomerdata.
120329
Pezhman&Hassan
CSRlogsintothesystemandtampersthedata.
Logintothesysteminanunauthorized way.
Datalogs.
N/A
CSRhasnegativeintentionsandhaveaccesstothesystem
CSRisloggedin
N/A
CSRupdatedcustomerrecordwrongly.
Customerdatacorruption.
Gettoknowpeoplewithnegativeintentionsintheorganization
Datastatisticalanalysis
Dataintegrity
Insider.
Customer,Organization
Data
N/A
Bufferoverflow,SQLinjection
KeepCustomerpersonalinformationsafe
CSRandcustomer
Authorizedlogintosystem

Documentsecurityrelevantrequirements
SeeAppendix(D)

5.4.2.1.10 Performsecurityanalysisofsystemrequirementsanddesign

DevelopanUnderstandingOfTheSystem.
Systemwascompletelyunderstoodthroughdocumentationandoutputsof
previousactivities.
DetermineandValidateSecurityRelevantAssumptions:
BusinessEnvironment:
Thereisnoremoteaccess.
Attacker:
Attackersareoftwotypes:
Itcanbecustomerservicerepresentative.
Someonewhohasphysicalaccesstothesystemoritscomponents.
ReviewNonSecurityrequirements:
Systemhasnotaddressed:
Dataintegrity
Availability
Confidentiality
Nonrepudiation
AssessCompletenessOfSecurityRequirements:
Table39:CorrelationMatrix
Security
requirement
ID
1
2
3
4
5

Authorization

Authentication

Confidentiality

Integrity

Availability

X
X

Accountability

Non
repudiation

59

Other

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
TOTAL

X
X

X
X
X

X
X
X

X
4

IdentifyThreatsOnAssets/Capabilities.
Table40:ThreatsonAssets
ASSETS
CICS
Z/OS
RACF
VSAM

3270TERMINAL
NETWORK

THREATS

WithoutauthenticationcancreateCICsession.

Denialofservice(CICSsession)

DonotallowcommunicationbetweenRACFandZ/OS.

Operatingsystemcanbeoutofservice.

OutofService

Allowunauthorizeduserandnotallowauthorizedusers

DiskStoragecanbecorrupted.AsthereisnotbackupDBfiledatacanbelost.

Outofservice.

MisusedbyCSR.

Usedbyunauthorizeduser.
Asthereisnodataencryption,datacanbemodifiedorreadduringdatatransmission.

Table41:ThreatsonCapabilities
CAPABILITES
Login
ValidateUser
Read/Customerdata/Update.
Readprocessdatato3270terminal

THREATS
Attemptsfromunauthorizedperson

Outofservice

Outputofthefunctionalityismodified.

Donotallowtoread/updatecustomerdata.

Writecustomerdatawithoutauthentication
Donotallowtoreturnprocessdatato3270terminal.

DetermineLevelOfRisks

60

Figure8:ThreatTree

DetermineRiskMitigationsForEachResource.
Risksmitigation:
UsercanonlyinitiateCICsessionafterauthenticloginfrom3270terminal.
Protecttransactionserver(Theremustbelimitedaccess).
Limitthemaximumnumberoffilesorprocessesthatauserisallowed.
VSAMfilemustbestoredasEncryptedform.
Alldatacommunicationsthroughnetworkmustbeencrypted.
EvaluateFindings:
Allthefindingsareevaluatedanddocumentedassecurityrequirementsinthenextactivity.
5.4.2.1.11 UpdateSecurityRequirementsDocument:
SeeAppendix(E)
5.4.2.1.12 IdentifyResources,EntryPoints,Functionalities,Assets,Capabilities,Resources,
ServicesAndActors.

61


Table42:System'sresources/assets
RESOURCES
CICS

FUNCTIONALITIES
Authentication

Z/OS
RACF

ExecutionApplication
Authorization

VSAM

Dataupdate/Read

3270TERMINAL
NETWORK

Searchclaims
CreateNewClaim

ASSETS
CustomerData

CAPABILITIES
Login.
ValidateUser.
Read/Customer
data/Update.
Readprocessdatato
3270terminal.

ACTORS
CustomerService
Representative.
Customer.

5.4.2.1.13 SupposeAllTheThreatsMentionedInTheCategorizationAreTrueForAll
Resources,EntryPoints,Functionalities,Assets,ServicesAndActorsForThe
System.
Aswehavediscussedearlierthatweareusingsecuritycategorizationfrom[11]
(SeeAppendixC).Inthisactivityallthethreatsmentioninthreatcategorization(See
AppendixC)weresupposedtobetrueforeveryentryinTable44.
5.4.2.1.14 Validatethreatsforeachresource,entrypoint,functionality,asset,serviceand
actorsforthesystem
Table45containsthenumberofthevalidthreatsfromthreatcategorization(See
AppendixC).
Table43:ValidThreats
Asset/Resource
CICS,3270TERMINAL
Login,Datastorage,CICS,RACF
CustomerDATA,Application
Network,Datastorage
Mainframe,3270terminal,Network
Application
3270Terminal,Update/Read
CustomerData,Read/Update
RACF,LogFile
3270Terminal,CICS,RACF
Mainframe,Network,3270Terminal,Data
storage

ThreatCategorizationNumber
1A,1B
1C
2
3A
3B,3C
3D
4
5A, 5B,5C,5D
6
7A
8

5.4.2.1.15 UpdateSecurityRequirementsDocument:
SeeAppendix(F)

62

ANALYSISANDINTERPRETATION:
Purpose of this chapter is to analyze and interpret the data obtained from
experiment. We extracted information from experiment and deleted redundancies.
We analyzed results using Vulnerability Comparison and system security baseline
[66,88].
We noticed that the participants of the experiment, especially the group using
Framework, werenot happyabouttheshorttime assignedtotheactivities. Infact,
timepressurewasreallyhelpfulbecauseinthiswaywewereabletosimulatethereal
world circumstances. The experiment, overall was a success because we simulated
the actual circumstances under which security is neglected in industry i.e. Lack of
resourcesorinexperiencedpeopleandTightscheduleforcompletingaproduct.

6.1

Datasetreduction
Bycarefullylookingattheactivitiesofthetechniques,weseethatinFramework,
securityrequirementdocumentisupdatedthrice.Whereastherewasnorestriction
for updating the document in Misuse cases and in CLASP. The security requirement
document was at least updated twice using CLASP and once using Misuse Cases.
During information extraction, we noticed that some security requirements were
repeated in CLASP and Framework. For example; a security requirement which was
alreadydocumentedwasrepeatedinsecondorthirdupdatingactivity.
We decided to delete repeated security requirements. We achieved that by
keeping the former and deleting the latter. It means if a security requirement was
written once and it was repeated in next document updating activity, we removed
thesecurityrequirementfromlatterupdatingactivity.

6.2

Descriptivestatistics

6.2.1

VulnerabilityComparison

As described earlier, Software system used during the experiment was taken
from[66].Fewvulnerabilitiesofthesystemwerealsolistedwiththedescriptionof
the system in [66]. We listed these vulnerabilities in Table 46 below. There may be
other vulnerabilities in the system example (Monolithic Framework) but we have
decidedtolistonlythosevulnerabilitieswhichwerelistedinthedocument[66]from
whichthesoftwaresystemexamplewasselected.
After removing repetitions in the security requirements for each technique, we
compared vulnerabilities covered by techniques with the already known
vulnerabilitiesofthesystem(seeTable46)toseewhichoftheknownvulnerabilities
areremovedbyeachtechnique.
It should be noted that our focus was to elicit security requirements. Therefore
we analyzed the data gathered in the context of research. Our focus was not on
findingvulnerabilitiesbutsecurityrequirements.Securityrequirementswereelicited
fortheotherthreatsfoundinTable45andthedocumentwasupdatedaccordinglyby
the group using Framework (See Appendix F). In Table 46 we have analyzed our
security requirements with respect to known vulnerabilities i.e. whether security
requirementselicitedbythethreetechniquesmitigatethevulnerabilitiesornot.

63

Table44:VulnerabilityandSecurityrequirementcomparison
ID
V1

V2

V3

V4

V5

V6

V7

V8

V9

Total

Vulnerabilities
UsingpasswordSystems
Thefailureofapasswordauthenticationmechanism
willalmostresultinattackersbeingauthorizedas
validuser.
Allowingpasswordaging.
Aspasswordage,theprobabilitythattheyare
compromisedgrows.
Note:RACFmustbecorrectlyconfiguredtoobtain
thecorrectpasswordaging
Notallowingpasswordaging.
Aspasswordage,theprobabilitythattheyare
compromisedgrows.
StoringPasswordsinarecoverableformat.
InthatcaseUserspasswordmayberevealedand
maybereusedelsewheretoimpersonatetheusersin
question.
Note:RACFmustbecorrectlyconfiguredtoobtain
thecorrectpasswordaging
Usingsinglefactorauthentication.
Ifthesecretinasinglefactorauthenticationscheme
getscompromised,fullauthenticationispossible.
Failuretoprotectstoreddatafrommodification.
Theobjectcouldbetamperedwith.
BufferOverflow.
Bufferoverflowsgenerallyleadtocrashes.Other
attacksleadingtolackofavailabilityarepossible,
includingputtingtheprogramintoaninfiniteloop.
Bufferoverflowsoftencanbeusedtoexecute
arbitrarycode,whichisusuallyoutsidethescopeofa
programsimplicitsecuritypolicy.
Whentheconsequenceisarbitrarycodeexecution,
thiscanoftenbeusedtosubvertanyothersecurity
service.
Failuretocheckwhetherprivilegesweredropped
successfully.
Ifprivilegesarenotdropped,neitherareaccess
rightsoftheuser.Oftentheserightscanbe
preventedfrombeingdropped.
Ifprivilegesarenotdropped,insomecasesthe
systemmayrecordactionsastheuserwhichisbeing
impersonatedratherthantheimpersonator.
Trustofsystemeventdata.
Ifonetruststhesystemeventinformationand
executescommandsbasedonit,onecould
potentiallytakeactionsbasedonaspoofedidentity.

MisuseCase

CLASP

FRAMEWORK

8
9

8
9

8
9

1
3
Figure9:Percentagecomparisonwithknownvulnerabilities

64

Final output of requirement elicitation techniques i.e. Framework, CLASP and

Misuse case, were number of security requirements. These requirements were
elicited in same amount of time but the number of elicited requirements was
different for each technique. Not only was the number of elicited requirements
different but types of requirement were also different. We analyzed the security
requirements elicited by each technique and compared the requirements with 9
knownvulnerabilitiesofthesystem(seeTable46).Basicallythepurposewastosee
thatwhatpercentageofthevulnerabilitiesismitigatedbyeachtechnique.
Afteranalyzingtherequirementsforvulnerabilitymitigation,weseethat5outof
total nine vulnerabilities (55%) are mitigated by Framework. Whereas 3 of 9
vulnerabilities (33%) were covered by CLASP and 1 out of 9 (11%) was covered by
Misusecase.

6.2.2

RequirementTypeswithRespecttoSystemssecurity
baseline

Wheneverwetalkaboutsecurity,questionwhichcomestoourmindiswhatdo
you want to secure. For that purpose we look into global security policy of the
organizationandestablishasecuritybaseline(seeTable32).
Asecuritybaselinewasestablishedfortheexamplesoftwaresystem,beforethe
experiment(seeTable32).Nowweneedtoseewhattypesecuritybaselinefeatures
are covered by each technique. We have 7 security baseline features and three
techniques i.e. Framework, CLASP and Misuse case. We got number of security
requirementsfromeachsecurityrequirementelicitationtechnique.Weneedtosee
thatwhichofthetechniquecoverswhichoftheestablishedbaselinefeaturesinan
effectivemanner.
Thegraphsbelowaresummarizedinthetablebelow

Table45:RequirementanalysiswithrespecttoSecuritybaseline
NumberofRequirements
CLASP
Framework

Security Baseline
Feature
Authorization

MisuseCase
2

Authentication

Confidentiality

DataIntegrity

Availability

Accountability

Nonrepudiation

In the graph below, Xaxis shows the three Techniques and Yaxis shows the
numberofrequirementselicitedfromtheseTechniques.AsyoucanseefromTable
45, Framework elicited more number of security requirements in terms of
authorization, authentication and confidentiality. Whereas in data integrity,
confidentiality and availability CLASP and Framework elicited same number of
requirements. In non repudiation and in accountability framework elicited one
requirementsascomparedtoothers.TherequirementswhichareelicitedbyMisuse
CasesandCLASParecoveredbyframeworkalso.Frameworkelicitedmorenumberof
requirements as compared to CLASP and Misuse cases which are mentioned in
AppendixF.Wedidnotfindanyuniquerequirementotherthanthesecuritybaseline.

65

Following graph (Figure 10) shows the number authorization Requirement

elicited from Misuse case, CLASP and Framework. As shown in graph, Misuse Case
elicited3,CLASP6andFrameworkelicted7authorizationrequirements.

Figure10:Authorizationrequirements

The graph below, shows the authentication Requirement elicited from Misuse
caseCLASPandFrameworkAsshowningraph(seeFigure11),norequirementwas
elicited using Misuse case. Whereas with CLASP, 5 and with Framework, 6
authenticationrequirementswereelicted.

Figure11:AuthenticationRequirements

Followinggraph(seeFigure12)showsConfidentialityRequirementelicitedusing
threesecuirtyrequirementelicitationtechniques.MisuseCaseelicited2,CLASP3and
Frameworkelicted7Confidentialityrequirements.

Figure12:ConfidentialityRequirements

66

Followinggraph(seeFigure13)shows,DataintegrityRequirementelicited using
the threetechniques.NoneofDataintegrityrequirementwaselicitedusing Misuse
case.4DataintegrityrequirementsareelicitedusingCLASPandFramework.

Figure13:DataintegrityRequirements

Graphbelow(seeFigure14)showsAvailabilityRequirementelicitedusingthree
techniques.Asshowningraph(seeFigure14),MisuseCaseelicited0,CLASP1and
Framework elicted 1 availability requirement. As shown (see Figure 14) CLASP and
FrameworkelicitedsamenumberofAvailabilityrequirements.
Figure14:AvailabilityRequirements

Follwinggraph(seeFigure15)isthecomparisonofNonrepudiationRequirement
elicitedusingthethreetechniques.Asshowningraph(seeFigure15),MisuseCase
elicited0,CLASP0andFrameworkelicted1NonrepudiationRequirement.

67


Figure15:NonRepudiationRequirement

Nextgraph(seeFigure16)showstheAccountabilityRequirementelicitedfrom
usingthreetechniques.Asshowningraph(seeFigure16),MisuseCaseelicited0,
CLASP0andFrameworkelicted1AccountabilityRequirement.

Figure16:AccountabilityRequirements

6.3

ResultsandDiscussions
Vulnerability analysis (in Section 6.2.1) shows that Framework mitigate more
numberofvulnerabilitiesthanCLASPandMisuseCase.Securityrequirementselicited
by Framework mitigated 55% whereas CLASP and Misuse case mitigated 33% and
11%ofthetotalknownvulnerabilitiesinoursoftwaresystem.
Requirement analysis with respect to security baseline shows that CLASP does
not elicit any requirement for Accountability and Availability security baseline
features.ForConfidentiality,numberofrequirementselicitedusingCLASPisfarless
thanthenumberofsecurityrequirementselicitedbyFramework.ForDataintegrity,
numberofsecurityrequirementsbyCLASPandFrameworkissame.
WecanseefromTable44andFigure17thatMisusecaseshaspoorperformance
both in vulnerability analysis and requirement analysis with respect to security
baseline. Major reason of poor performance from Misuse case is because it merely
dependsuponthecreativityofthepersoncreatingaMisusecase.

68

Figure17:RequirementAnalysisw.r.tSecurityBaseline

There is no absolute measure for creativity. Since Misuse case depends upon
creativity of the person executing the technique, we are not sure about the results
we got from Misuse case alone. We can say that the group had a low level of
creativity skills but in the end we were supposed to extract results from what we
actually got. So the result showed that Misuse case did not perform better than
CLASPandFramework.
CLASPontheotherhandhasdefinitenumberofstepsandpredefinedguidelines
whichgivesabetteropportunitytoexploitanddiscoverissues.Wesawthatusingthe
security requirement categorization [11] raised the security requirement elicitation
graphsignificantlyforFramework.

6.4

Returnofinvestmentforeachtechnique.
Thissectionisbasedupontheobservationsduringtheexperiment.Resultmayor
maynotdifferifcircumstancesarechanged.
Weconductedtheexperimentusingthreetechniquesi.e.MisuseCases(informal
technique),CLASP(formaltechnique)andFramework.Outputoftheexperimentwas
three sets of security requirements i.e. from Misuse Cases, from CLASP and from
Framework. If we initially suppose that time invested in each of the technique is
directlyproportionaltotheoutput,it wouldsimplymeanthatthemoretimespent
on a technique leads to increase in number of security requirements. We have
alreadymentionedinsection5.3.4thatweassignedsameamountoftimetoallthe
threetechniques.ResultsshowthatinsameamountoftimeFrameworkelicitsmore
securityrequirementsthanMisuseCasesandCLASP.ThereforeFrameworkhasmore
ReturnofInvestmentthanMisuseCasesandCLASP.

6.5

ValidityThreats

Conductinganexperimentwithsmallsamplespacei.e.Sixstudentsmaybea
questionmarkonourresults.Wecansupposethatwegetsameresultwith
largesamplespacebutwecannotbesureaboutit.Resultinferredisbased
upontheconditionsunderwhichweconductedtheexperiment.

69

 Results and conclusions mentioned in the document are based on one

softwaresystem.Wecanonlyassumethattheconclusionfromalargescale
experiment will be same as conclusions drawn in this study but we are not
sure about it. Results are based on the experiment and the system we
selected for the experiment. Although the software system for the
experiment was selected randomly, still we do not have large evidence to
supportourresults.
WeproposedtheFrameworkbyintegratingoneinformaltechniquewithtwo
formal techniques. We also combined security requirement categorization
(see Appendix C) with our framework. Security requirement categorization
was devised for Misuse Cases technique by Bogale and Ahmed [11].
Therefore we can say that Misuse Cases have a large contribution in our
Framework. Three more fields were also added to Misuse Cases (See
Appendix J). Using selected activities from CLASP and Secure TROPOS and
combiningthosewithMisuseCasesaddedstrengthtoourFrameworkbutwe
arenotsureaboutwhichtechniqueactuallyattributedtobetterresultsfrom
Framework.Atthemomentwecanonlymakesuppositionsaboutthisthreat
because analyzing each techniques contribution to the Framework requires
indepthanalysiswhichbecomesoutofscopeforourthesis.

6.5.1

Limitations
Lackofresourcestoconducttheexperimenti.e.wewerenotabletofindany
industrial contact to conduct the experiment. Our experiment required
software analysts from industry. Response from industries was not positive
becausesoftwareorganizationshavetheirownongoingprojectsthereforeit
wasnotpossibletoengagesomeonefromindustry.
If we have more time, we should choose more complex method i.e. more
stepsintheframework.Justusingmoretimewithasimplemethodwillnot
improve the number of problems found. We had to select the method
dependingonseveralissuese.g.availabletime.
We have few Data points in our experiment. Few data points may affect
generalization of results. As mentioned earlier, our results and conclusions
areinferredfromonesystemwhichwasrandomlyselected.
Ourframeworkisworkintensiveandwecanseefromtheexperimentthatits
activitiesneedtimetoexecute.Thisunaddressedissuecanbealimitationof
the study. Our motive in the study was to find more number of security
requirements than a formal or informal technique. Reducing activities of
framework would simply be at the cost of security requirements. Making a
less work intensive Framework and testing its applicability becomes out of
scopeforusinthepresentstudy.

70

6.6

AnswerstoResearchQuestions
Ourfirstresearchquestionwas:
RQ1. Do formal approaches produce better results when integrated with
informalapproachi.e.Misusecase?
H0:Formalapproachesdonotproducebetterresultswhenintegrated
withinformalapproachi.e.Misusecase.
H1: Formal approaches produce better results when integrated with
informalapproachi.e.Misusecase.

Our Framework was proposed by combining CLASP, Misuse case and Secure
TROPOS.Ourresultsshowthat,ourFrameworkproducebetterresultthanCLASPand
Misuse case. Since our Framework elicits more number of security requirements
thanaformalandanInformaltechnique,wecansaythatifwecombineformaland
Informal security requirement elicitation technique, we can yield better results. In
other words, we can say that by combining strengths of formal and informal
techniques, we can mitigate their weaknesses. For example, a formal technique is
flexible but has definite number of steps whereas on the other hand informal
techniqueslackproperstructurebuthaveflexibility.Therefore,bycombiningformal
and informal techniques we can produce better results. This proves hypothesis H1
trueforRQ1(undergivencircumstances).

Oursecondresearchquestionwas:
RQ2. What is the practicality of the proposed framework, i.e. up to what
extent and for which types of software systems the framework is
suitable?

At this point, we would like to mention again that our scope was limited to
requirement elicitation. So we are to see the practicality and workability of our
frameworkinthesaidcontext.Ofcoursewedonothavemeasurementscaleforthe
practicality and workability of our framework but the visual analysis we have from
the data we see that it works pretty well than CLASP and Misuse case. CLASP, a
widely used formal technique and Misuse case, a well known informal technique
were tested on a software system along with our framework. We saw that our
framework not only elicits more number of security requirements but cover more
vulnerabilities in the system. Moreover our framework covered all the security
baselinefeaturesofthesoftwaresystem(seeTable47).
We can answer the first part of research question RQ2 here by saying that our
framework is more workable and practical than CLASP (a formal technique) and
Misusecase(aninformaltechnique)intermsofsecurityrequirementelicitationand
invulnerabilitiesmitigation.Moreoverwegatheredfeedbackfromstudentstoknow
the usability of the framework (see Appendix I). Feedback showed that, while
performing the activities of the Framework, participants analyzed the system from
different aspects which are usually are not considered in software development.
Moreover, use of the framework improves the users knowledge about software
securityandsoftwareattackscenarios.
Unfortunately,itwasnotpossibleforustoanswerthesecondpartoftheRQ2i.e.
for which types of software systems the framework is suitable? We did not have
thetimeandresourcestoconductexperimentonmorethanonesoftwaresystemso
it pointless to argue on relationship of the framework with nature of software

71

systems.Wecannotmakecertainclaimsaboutnatureofsoftwaresystemunlessour
frameworkistestedondifferentsystems.

RQ3. On what basis and for which type of software systems, is the proposed
framework better than other widely known security requirement
elicitationtechniques?
H0: The proposed framework is not better than other security
requirementelicitationtechniques.
H1: Proposed framework is significantly better than the other
requirementelicitationtechniques.

Answer to first part of RQ3 i.e. on what basis, the framework is better than
CLASPandMisuseCase,is:
Frameworkshowsbetterperformancethanawidelyusedformalandinformal
techniqueintermsofelicitingmorenumberofsecurityrequirements.
Framework covers the security baseline requirements defined by the
organization.
Framework takes into account, those perspectives of software system which
are not touched in CLASP and Misuse Case e.g. Threats related to
Functionalities and physical integrity of hardware and software. Feedback
from participants of the experiment shows that this framework helps in
analyzingasystemfromdifferentaspectswhichareusuallynotconsideredin
softwaredevelopment(seeAppendixI).
Frameworkprovidesanoptiontoiteratethroughsomeimportantactivitiesby
whichsecurityrequirementscanberecheckedandrefined.
Framework activities breakdown the system into little details and help build
securityintheformofrequirementelicitation.
Asfarassecondpartisconcerned,wehavealreadyansweredthatinRQ2.

6.7

ConclusionandLessonLearned
Securityrequirementelicitationhelpsfocussecurityinsoftwaresystem.Wehave
mentionedbeforethatcostrelatedtofixingsecurityproblemismuchmorethanthe
cost of security requirement elicitation in earliest phase of software development.
The framework we have proposed by combining CLASP, Misuse case and Secure
TROPOS contains the strength of three security requirement elicitation techniques.
To make the framework more effective, we also included security requirement
categorization by Bogale and Ahmed [11]. Including security requirement
categorization was really useful because it helped in eliciting more security
requirements(seeAppendixF).
If we take a quick overview of the Framework, we see that the Framework is
proposed by combining CLASP, Secure TROPOS, Misuse Cases and Security
requirementcategorization.Frameworkconsistsoffifteenactivities.First10activities
are taken from CLASP and Secure TROPOS. Since Secure TROPOS follows complex
graphical notations (as mentioned earlier), we only used the basic idea behind the
activitiesfromSecureTROPOS.MostoftheactivitiesofSecureTROPOSweresimilar
inconcepttotheactivitiesinCLASP(seeTable18andTable20).Foranyoverlapping
activitybetweenCLASPandSecureTROPOS,thatwasselectedfromCLASPorSecure
TROPOS,weusedthetextualdescriptionoftheactivityfromCLASPtodescribethe
activity. CLASP, having textual form of activity description, was easy to integrate as
comparedtoSecureTROPOS.WenotonlyusedalltheactivitiesofMisuseCasesin
the Framework but we also used Security Requirement categorization which was

72

proposed [11] specifically for Misuse Cases. Therefore we can say all the three
techniqueshadequalcontributioninproposingourFramework.
Theframeworkisflexibleandcontainsdefinitenumberofstepstoelicitsecurity
requirements. In addition it also allows iterations to improve security in a system.
This research was an attempt to provide a flexible framework for security
requirement elicitation. We achieved that by mitigating the weaknesses in formal
and informal security requirement elicitation techniques by combing them. In the
questionnaire,whichwasfilledbytheparticipantsoftheexperiment,theparticipants
agreed that using this framework improved their knowledge about importance of
securityinsoftwaresystems.

During this research we learned and discovered that there are many security
requirementelicitationtechniquesproposedbyresearchersbutalmostnoneofthem
areusedinindustryonalargescale.MostofthebigbrandnameslikeIBMandCISCO
have their own, customized, set of steps to ensure security in their product. It is
worth noting that these customized set of steps to ensure security also reflect
organizational structure. Academic research in this field is not used in industry at
large scale. Reason behind not including research outputs in security requirement
engineering field is that small organizations do not have resources for that. Big
organizationshavedevelopedtheirowncustomizedproceduresovertimetohandle
security in their product and it is costly to switch to anything new suddenly.
Thereforeitisunfortunatethatacademicresearchinthisfieldisnotgivenattention
asitdeserves.
It is clear that not every software development organization gives desired
attention to security in software and hacking incidents around the world are the
evidence to our argument. That means, the organizations that produce vulnerable
softwaredonothaveanyformalprocedurestoviewsecurityasamajorconcernina
softwaresystem.Tomakesuchanorganizationrefertotheacademicresearchinthis
regard,wesuggestcreatingademandforsecuresoftwaredevelopment.
Socialawarenessaboutsoftwaresecurityisveryimportantbecauseitwillcreate
ademandforsecuresoftwaresystems.Sincesoftwarehasamajorroletoplayinour
lives today, we suggest that Software vendors, Customers and Researchers must
understand the importance of security in software systems. Demand for systems
whicharesecurefrom customersandvendorsperspectivewill automaticallyforce
bothbigandsmallorganizationstorefertoacademicresearchinsoftwaresecurity,
especially security requirements elicitation. This may also help to bridge the gap
betweenacademiaandindustryinthefieldofsecurityrequirementengineering.

6.8

FutureWork
In our framework we have focused on Requirement phase of Software
Development Lifecycle. We considered only those activities of CLASP and Secure
TROPOSwhichwererelatedtoRequirementelicitation.Infuture,onecanaddmore
activitiestotheframeworkthatarerelatedtoothersoftwaredevelopmentLifecycle
Phases.Thiswillhelptoinvokesecurityinallphasesofdevelopmentlifecycle.
WehavetestedourFrameworkforonesoftwaresystem.Forfutureworkonecan
check the practicality of framework for different systems. In this procedure
improvementsinourframeworkcanbesuggested.

73

7
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

REFERENCES
Agarwal, A. and Gupta, D. Security Requirements Elicitation Using View Points for
Online System, in Emerging Trends in Engineering & Technology, International
Conferenceon,LosAlamitos,CA,USA,2008,vol.0,pp.12381243.
Ahmed, N. and Matuleviius, R. Towards Transformation Guidelines from Secure
TropostoMisuseCases(PositionPaper),2011.
Allen, J., Barnum, S., Ellison, R., McGraw, G., and Mead, N. Software security
engineering:aguideforprojectmanagers.AddisonWesleyProfessional,2008.
Alberts, C.J., Behrens, S.G., Pethia, R.D., and Wilson, W.R. Operationally critical
threat,asset,andvulnerabilityevaluation(OCTAVE)framework,Version1.0,1999.
Alexander,I.Misusecaseshelptoelicitnonfunctionalrequirements.Computing&
ControlEngineeringJournal,2003,vol.14,no.1,pp.4045.
Alexander, I. Initial industrial experience of misuse cases in tradeoff analysis. In
ProceedingIEEEJointInternationalConferenceRequirementsEngineering(2002),pp
6168.
Alhazmi,O.H.,Malaiya,Y.K.,andRay,I.Measuring,analyzingandpredictingsecurity
vulnerabilities in software systems, Computers & Security,2007, vol. 26, no. 3, pp.
219228.
Babar, M.A and Zhang, He. Systematic literature reviews in software engineering:
Preliminaryresultsfrominterviewswithresearchers,in3rdInternationalSymposium
onEmpiricalSoftwareEngineeringandMeasurement.ESEM,2009,pp.346355.
Bagheri,H.InjectingsecurityasaspectableNFRintoSoftwareArchitecture,inAsia
Pacific Software Engineering Conference, Los Alamitos, CA, USA, 2007, vol. 0, pp.
310317.
Boehm, B.W. and Papaccio, P.N. Understanding and controlling software costs,
SoftwareEngineering,IEEETransactionson,1988,vol.14,no.10,pp.14621477.
Bogale, H., Ahmed, Z. A FRAMEWORK FOR SECURITY REQUIREMENTS: SECURITY
REQUIREMENTSCATEGORIZATIONANDMISUSECASES,BTH,Thesisdoc,September,
2011.
Brown, A.W. and Wallnau, K.C. A framework for evaluating software technology,
Software,IEEE,1996,vol.13,no.5,pp.3949.
Buecker, A., Borrett, M., Lorenz, C., Powers, C.Introducing the IBM Security
Frameworks and IBM Security Blueprint to Realize BusinessDriven
Security.Redbooks.2010.

Castro, J., Kolp, M., and Mylopoulos, J. A requirementsdriven development

methodology,inAdvancedInformationSystemsEngineering,2001,pp.108123.

74

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

Chung,L.Dealingwithsecurityrequirementsduringthedevelopmentofinformation
systems,inAdvancedInformationSystemsEngineering,1993,pp.234251.
Chung, L. and do Prado Leite, J. On nonfunctional requirements in software
engineering, Conceptual modeling: Foundations and applications, 2009, pp. 363
379.
Diallo, M.H., RomeroMariona, J., Sim, S.E., and Richardson, D.J. A comparative
evaluationofthreeapproachestospecifyingsecurityrequirements,in12thWorking
Conference on Requirements Engineering: Foundation for Software Quality,
Luxembourg,2006.
Davey, B. and Cope, C. Requirements Elicitation Whats Missing?, Issues in
InformingScience&InformationTechnology,2008,vol.5,pp.543551.
Du, J., Yang, Y., and Wang, Q. An Analysis for Understanding Software Security
Requirement Methodologies, in Secure System Integration and Reliability
Improvement,LosAlamitos,CA,USA,2009,vol.0,pp.141149

El Khoury, P., Mokhtari, A., Coquery, E., Hacid, M.S, An Ontological Interface for
Software Developers to Select Security Patterns, in Database and Expert Systems
Application,2008.DEXA08.19thInternationalWorkshopon,2008,pp.297301.

Elahi, G., Yu, E., and Zannone, N. A vulnerabilitycentric requirements engineering

framework: analyzing security attacks, countermeasures, and requirements based
onvulnerabilities,Requirementsengineering,2010,vol.15,no.1,pp.4162.

Fabian, B., Grses, S., Heisel, M., Santen, T., and Schmidt, H. A comparison of
security requirements engineering methods, Requirements engineering, 2010 , vol.
15,no.1,pp.740.

Fuxman, A., Kazhamiakin, R., Pistore, M., and Roveri, M. Formal Tropos: language
andsemantics,UniversityofTrentoandIRST,2003.
Garcia Alcazar, E. and Monzn, A. A process framework for requirements analysis
and specification, in Requirements Engineering. Proceedings. 4th International
Conferenceon,2000,pp.2735.

Gargantini,A., Riccobene,E , and Scandurra ,P. Integrating formal methods with

modeldriven engineering, in Software Engineering Advances. ICSEA09. Fourth
InternationalConferenceon,2009,pp.8692.

Giorgini,P.,Mouratidis,H.,andZannone,N.Modellingsecurityandtrustwithsecure
tropos,IntegratingSecurityandSoftwareEngineering:AdvancesandFutureVision,
2006,pp.160189.

Glinz,M.Onnonfunctionalrequirements,inRequirementsEngineeringConference.
RE07.15thIEEEInternational,2007,pp.2126.

Graham,D.IntroductiontotheCLASPProcess,BuildSecurityIn,SecureSoftware,Inc.
2006.

75

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]
[40]

[41]

[42]

Gregoire, J., Buyens, K., De Win, B., Scandariato, R.,and Joosen, W.2007.
OntheSecureSoftware Development Process: CLASP and SDL Compared. In SESS
07:Proceedings of the Third International Workshop on Software Engineering for
SecureSystems(Minneapolis,MN,2007),pp.1.
Hadavi, M.A., Sangchi, H., Hamishagi, V., and Shirazi, H. Software security; a
vulnerability activity revisit, in Availability, Reliability and Security. ARES 08. Third
InternationalConferenceon,2008,pp.866872.
Hadavi,M.,Hamishagi,V.,andSangchi,H.SecurityRequirementsEngineering;State
of the Art and Research Challenges, Proceedings of the International
MultiConferenceofEngineersandComputerScientists,2008,vol.1,pp.1921.

Haley,C.,Laney,R.,Moffett,J.,andNuseibeh,B.SecurityRequirementsEngineering:
A Framework for Representation and Analysis, IEEE Transactions on Software
Engineering,2008,vol.34,no.1,pp.133153.
Haley, C.B., Moffett, J.D., Laney, R., and Nuseibeh, B. A framework for security
requirements engineering, in Proceedings of the 2006 international workshop on
Softwareengineeringforsecuresystems,2006,pp.3542.
Hartong, M., Goel, R., and Wijesekera, D. Metamodels for misuse cases, in
Proceedings of the 5th Annual Workshop on Cyber Security and Information
Intelligence Research: Cyber Security and Information Intelligence Challenges and
Strategies,2009,p.33.

Hassan, R., Eltoweissy, M., Bohner, S., and ElKassas, S. Formal analysis and design
for engineering security automated derivation of formal software security
specificationsfromgoalorientedsecurityrequirements,Software,IET,2010,vol.4,
no.2,pp.149160.

Herrmann, A. and Paech, B. MOQARE: misuseoriented quality requirements

engineering,RequirementsEngineering,2007,vol.13,no.1,pp.7386.
Howard,M.andLeBlanc,D.S.T.B.Online,andS.B.O.(Firme),Writingsecurecode,
vol.2.Microsoftpress,2003.
Husnain,M.,Waseem,M.,andGhayyur,S.AnInterrogativeReviewofRequirement
EngineeringFrameworks,InternationalJournalofReviewsinComputing(IJRIC).2009.
IntegratedSecurityArchitecturalFramework.CISCO.WhitePaper.2006.

Irvine,C.E.andNguyen,T.D.UseofEvaluationCriteriainSecurityEducation.NAVAL
POSTGRADUATESCHOOLMONTEREYCA,2008.

Khan,M.U.A.andZulkernine,M.ASurveyonRequirementsandDesignMethodsfor
Secure Software Development, Technical Report No. 2009 562 , School of
Computing,QueensUniversity,Kingston,Ontario,Canada,August2009.
Kim,J.,Kim,M.,andPark,S.Goalandscenariobaseddomainrequirementsanalysis
environment,JournalofSystemsandSoftware,2006,vol.79,no.7,pp.926938.

76

[43]

[44]
[45]
[46]

[47]

[48]

[49]

[50]
[51]
[52]

[53]

[54]

[55]

[56]

[57]

Kitchenham,B.ProceduresforPerfomingSystematicReview,JointTechnicalReport,
Software Engineering Group, Department of Computer Science Keele University,
United Kingdom and Empirical Software Engineering, National ICT Australia
Ltd.:Australia,2004.

Kruchten,P.TheRationalUnifiedProcessanIntroduction,AddisonWesley.2000.

Kulak,D.,andGuiney,E.UseCases:RequirementsinContext,ACMPress.2000

Matulevicius, R., Mayer, N., and Heymans, P. Alignment of misuse cases with
securityriskmanagement,ARES20083rdInternationalConferenceonAvailability,
Security,andReliability,Proceedings,2008,pp.13971404.

McUmber, W.E. and Cheng, B.H.C. A general framework for formalizing UML with
formal languages, in Proceedings of the 23rd international conference on Software
engineering,2001,pp.433442.
Mead, N.R. and Stehney, T. Security quality requirements engineering (SQUARE)
methodology,vol.30.ACM,2005.
Mead, N.R. How to compare the Security Quality Requirements Engineering
(SQUARE)methodwithothermethods,DTICDocument,2007.
Mead,N.R.Experiencesinelicitingsecurityrequirements,DTICDocument,2006.

Mead,N.R.Requirementsengineeringforsurvivablesystems,2003.

Mead, N.R. and Hough, E.D. Security Requirements Engineering for Software
Systems: Case Studies in Support of Software Engineering Education, in Software
EngineeringEducationandTraining,Conferenceon,LosAlamitos,CA,USA,2006,vol.
0,pp.149158.
Mellado, D., Eduardo FernndezMedina, Mario Piattini. Security Requirements
Variability for Software Product Lines, in Availability, Reliability and security. ARES
08.ThirdInternationalConferenceon,2008,pp.14131420.

Mellado,D.,Blanco,C.,Snchez,L.E.,andFernndezMedina,E.Asystematicreview
ofsecurityrequirementsengineering,ComputerStandards&Interfaces,2010,vol.
32,no.4,pp.153165.
Mishra,D.,Mishra,A.,andYazici,A.Successfulrequirementelicitationbycombining
requirementengineeringtechniques,inApplicationsofDigitalInformationandWeb
Technologies.ICADIWT.FirstInternationalConferenceonthe,2008,pp.258263.

Moffett, J.D., Haley, C.B., and Nuseibeh, B. Core security requirements artefacts,
Department of Computing, The Open University, Milton Keynes, UK, Technical
Report,2004,vol.23.

Mouratidis,H.ExtendingTROPOSMethodologytoAccommodateSecurity.Progress
Report,ComputerScienceDepartment,UniversityofSheffield,October2002.

77

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

Mouratidis, H., Giorgini, P., and Manson, G. Integrating security and systems
engineering: Towards the modelling of secure information systems, in Advanced
InformationSystemsEngineering,2003,p.10311031.
Mouratidis, H. and Giorgini, P. Secure tropos: A securityoriented extension of the
troposmethodology,InternationalJournalofSoftwareEngineeringandKnowledge
Engineering,vol.17,no.2,2007,pp.285309.
Mouratidis,H.SecureTropos:Anagentorientedsoftwareengineeringmethodology
for the development of health and social care information systems, International
JournalofComputerScienceandSecurity(IJCSS),2009,vol.154,no.3,p.241.
Mouratidis, H. A Security Oriented Approach in the Development of Multiagent
Systems:AppliedtotheManagementoftheHealthandSocialCareNeedsofOlder
PeopleinEngland,2004,PhDThesis,UniversityofSheffield.
Mouratidis,H.SecureSoftwareSystemsEngineering:TheSecureTroposApproach,
JournalofSoftware,2011,vol.6,no.3,pp.331339.
Mylopoulos,J.,Fuxman,A.,andGiorgini,P.Fromentitiesandrelationshipstosocial
actors and dependencies, in Proceedings of the 19th international conference on
Conceptualmodeling,2000,pp.2736.

Nuseibeh, B. and Easterbrook, S. Requirements engineering: a roadmap, in

ProceedingsoftheConferenceontheFutureofSoftwareEngineering,2000,pp.35
46.

Okubo, T.,Taguchi, K., and Yoshioka, N. Misuse cases + assets + security goals,
Proceedings 12th IEEE International Conference on Computational Science and
Engineering,CSE2009,pp.424429.
OWASP CLASP. CLASP Concepts View, CLASP v1.2, March, 2006.
http://www.lulu.com/items/volume_62/1401000/1401307/3/print/OWASP_CLASP_
v1.2_for_print_LULU.pdf
Pandey, S., Mustafa, K., and Rehman, S. CLASP and SDL Revisited, in Proceedings
SecondInternationalConferenceonInformationProcessing,2008,p.343.
Pauli,J. J. and Xu,D. Misuse casebased design and analysis of secure software
architecture, in Information Technology: Coding and Computing. ITCC 2005.
InternationalConferenceon,vol.2,pp.398403.

RomeroMariona, J., Ziv, H., and Richardson, D.J . Formality of the Security
Specification Process: Benefits Beyond Requirements. Hawaii International
ConferenceonSystemSciences(LosAlamitos,CA,USA,2010),16.
RomeroMariona, J., Ziv, H., and Richardson, D.J. SRRS: a recommendation system
for security requirements, in Proceedings of the 2008 international workshop on
Recommendationsystemsforsoftwareengineering,2008,pp.5052.
RomeroMariona,J.,Ziv,H.,andRichardson,D.SecurityRequirementsEngineering:
ASurvey,TechnicalReportUCIISR082.UniversityofCalifornia,Irvine,2008.
78


[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

RomeroMariona, J., Ziv, H., and Richardson, D.J., Formality of the Security
Specification Process: Benefits Beyond Requirements, in System Sciences (HICSS),
201043rdHawaiiInternationalConferenceon,2010,pp.16.
Rushby, J. Security requirements specifications: How and what, in Symposium on
RequirementsEngineeringforInformationSecurity(SREIS),2001,vol.441.

Ryan, A.J. An approach to qunantitative nonfunctional requirements in software

development, in Systems engineeringa key to competitive advantage for all
industries:proceedingsofthe2ndEuropeanSystemsEngineeringConference(EUSEC
2000),Munich,September13th15th,2000,p.73.
Sadiq, M. and Shahid, M. Elicitation and Prioritization of Software Requirements,
InternationalJournalofRecentTrendsinEngineering,2009,vol.2,no.3.
Saeki,M.andkoKaiya,H.SecurityRequirementsElicitationUsingMethodWeaving
andCommonCriteria.Japan2010.
Salini, P. and Kanmani, S. A model based security requirements engineering
framework applied for online trading system, in 2011 International Conference on
RecentTrendsinInformationTechnology(ICRTIT2011),Piscataway,NJ,USA,2011,
p.1195202.

Sindre, G., and Opdahl, A.L. Eliciting security requirements with misuse cases,
RequirementsEngineering,Jan,2005,pp.3444.

Sindre,G.,andOpdahl,A.L.CapturingSecurityRequirementsthroughMisuseCases.
13thInternationalWorkingConferenceonRequirementsEngineering:Foundationfor
SoftwareQuality.2007.
Sindre,G.andOpdahl,A.L.Templatesformisusecasedescription,inProc.Seventh
International Workshop on Requirements Engineering: Foundation of Software
Quality(REFSQ2001),2001.

Su,X.,Bolzoni,D.,VanEck,P.,andWieringa,R.Abusinessgoaldrivenapproachfor
understanding and specifying information security requirements, Arxiv preprint
cs/0603129,2006.

Syllabus Version 1.2 .REQBCertified Professional for Requirements

Engineering,FoundationLevel,2008.

Talukder,A.K.,Maurya,V.K.,G,S.B.,Ebenezer,J.,V,M.S.,KP,J.,Samanta,S.,andP,
A.R.SecurityawareSoftwareDevelopmentLifeCycle(SaSDLC)Processesandtools,
inIFIPInternationalConferenceonWirelessandOpticalCommunicationsNetworks,
Cairo,Egypt,2009,pp.15.

Tndel, I., Jensen, J., and Rstad, L. Combining misuse cases with attack trees and
security activity models, in Availability, Reliability, and Security, 2010. ARES10
InternationalConferenceon,2010,pp.438445.

79

[85]

[86]

[87]

[88]

[89]

[90]

[91]

[92]

Tondel,I.A.,Jaatun,M.G.,andMeland,P.H.Securityrequirementsfortherestofus:
Asurvey,IEEESOFTWARE,2008,pp.2027,.

Viega,J.andMcGraw,G.Buildingsecuresoftware:howtoavoidsecurityproblems
therightway.AddisonWesleyProfessional,2001.
Viega,J.. Building security requirements with CLASP, in ACM SIGSOFT Software
EngineeringNotes,2005,vol.30,pp.17.

Viega, J. The CLASP Application Security Process, Secure Software, Inc.,CLASP v1.0
,june,2005.

Whittle, J., Wijesekera, D.,and Hartong, M. Executable misuse cases for modeling
security concerns. In ICSE 08: Proceedings of the 30th international conference on
Softwareengineering,2008,pp.121130.

Wilander, J. and Gustavsson, J. Security requirementsA field study of current

practice, in Symposium on Requirement Engineering for Information Security
(SREIS2005),Paris,France,2005.

Wohlin,C.,Runeson,P.,andHst,M.ExperimentationinSoftwareEngineering:An
Introduction,1sted.Springer,1999.

Yoshioka, N., Washizaki, H., and Maruyama, K. A survey on security patterns,

ProgressinInformatics,2008,vol.5,no.5,pp.3547.

80

APPENDIX

8.1

APPENDIXA

F4:SystemResources
Belowtableshowstheresourcesusedbysysteminternallyorexportsanddifferentmeasuresaretakentopromotesecurity
goals.

Resource
SecurityMeasures

Authentication:
Confidentiality:
Dataintegrity:
AccessControl:
Nonrepudiation:
Accountability:

Authentication:
Confidentiality:
Dataintegrity:
AccessControl:
Nonrepudiation:
Accountability:

8.2

APPENDIXB

CLASPResourcesDdiscussesthecoresecurityservice.Thesearethefundamentalsecuritygoalswhichneedstobeaddressed
effectivelyforresourcesinasystem.
Authorization
Authorizationalsocalledaccesscontrol.Authorizationsaregiventouserstoaccessthesystemonthebasis
ofidentityandaregenerallypolicydriven.Policiesareenforcedbyaccesscontrolmechanismtoperform
operationsonresources.Policiesdependupontheindividualactionsperformedonresources.Forexample
accesscontroldecisionisgenerallytakenonthebasisofuserspecificpolicy.
Authentication Authenticationisusedtoestablishidentityofcommunicationpartners,owner,creatoretcofdata.
Authenticationmustbeperformedatlogintimefornetworkconnectionsbutonemustalsoperform
ongoingauthenticationsforlifetimeofconnection.Differentcategoriesofauthenticationareasfollows:
Thingswhichareknownsuchaspasswordsorpassphrases.
ThingsyouhavesuchascreditcardorRSASecureID(Authenticationtokens).
Thingsyouaresuchasfingerprints,voiceprintandretinalscans.

Confidentiality Purposeofconfidentialityistokeepdatasecrettoallunauthorizedparties.Datamustbekeptsecretor
encryptedinbothwayslikewhendataisbeingtransmittedonanetworkandwhenitisbeingstored,long
termorshortterm.
Integrity
Dataintegritymeanstokeepthedataasinformasitwasintendedtobe.Clasptreatsdataintegrityas
subsetofauthentication.Therearecaseswhereitcanbetakenasseparateserviceasauthentication.For
exampleinphysicallinklayerontrustedmediawhereerroroccursbutnotrelatedtosecurityerrors.
Availability
Delayofdatacancausetheavailabilityproblemorifproblemisduetomaliciouslyisknownasdenialof
serviceattack.
Accountability
Systemshouldloginformationabouttheoperationsperformedbythesystemuserinordertoreviewthis
informationwhenrequired.Systemusersmustbeaccountablefortheactionstheyperform.
Non
Whenthereistwopartycommunications,eithersidescanprovetothemselveswhetherdatacomesfrom
repudiation
authenticsource.Problemoccurswhenthirdpartyinvolves.Forthismessagecanbeestablishedfrom
originalsendertothirdpartieswhichiscallednonrepudiatable.

8.3

APPENDIXC(ThreatsCategorization)

Categories
1.Accesscontrol
a.Identification
Requirements(D.G.
Firesmith,2003)

Description

Identification
requirementsisany
securityrequirementthat
specifiestheextentto
whichabusiness,
application,component
orcentreshallidentify
externalsbefore
interactingwiththem(D.
G.Firesmith,2003)

Examples

PowerStatements

Theapplicationshall
identifyallofitsclient
applicationsbefore
allowingthemtouse
itscapabilities

Anunauthorized
agentattemptsto
intrudeintothe
system/
application/centre
withoutavalid
identity.

PowerMisuseCase
StealInformation

81

b.Authentication
Requirements(D.G.
Firesmith,2003)

Authentication
requirementsisany
securityrequirementthat
specifiestheextentto
whichabusiness,
application,component,
orcentershallverifythe
identityofitsexternals
beforeinteractingwith
them(D.G.Firesmith,
2003)
Anauthorization
requirementisany
securityrequirementthat
specifiestheaccessand
usageprivilegeof
authenticatedusersand
clientapplications(D.G.
Firesmith,2003)

Theapplicationshall
verifytheidentityof
allofitsusersbefore
allowingthemtouse
itscapabilities

Anunauthorized
agentattemptsto
intrudeintothe
system/
application/centre
withoutaverified
identity

Theapplicationshall
alloweachcustomer
toobtainaccesstoall
ofhisorherown
personalaccount
information.

2.Immunity
Requirements(D.G.
Firesmith,2003)

Animmunity
requirementsisany
securityrequirementthat
specifiestheextentto
whichanapplicationor
componentshallprotect
itselffrominfectionby
unauthorizedundesirable
programs(D.G.
Firesmith,2003)

Theapplicationshall
protectitselffrom
infectionbyscanning
allenteredor
downloadeddataand
softwarefor
unknowncomputer
viruses,worms,
Trojanhorsesand
othersimilarharmful
programs(D.G.
Firesmith,2003)

Anunauthorized
agentattemptsto
gainaccesstothe
restricteddata/
services,specific
application,
component
capabilitiesorany
confidential
informationofthe
system/
application/centre
withoutproper
authorization
Anunauthorized
agentattemptsto
infectthedataor
softwareofthe
system/
application/centre

3.Integrity
Requirements
a.DataIntegrity(D.
G.Firesmith,
2003)(DonaldG
Firesmith,2005)

c.Authorization
Requirements(D.G.
Firesmith,2003)

b.Hardware
Integrity(DonaldG
Firesmith,2005)

c.Personal
Integrity
(Communications)
(D.G.Firesmith,
2003)(DonaldG
Firesmith,2005)

Anintegrityrequirement
isthekindofsecurity
requirementthat
specifiestheextentto
whichthehardware,
softwareordata
components,or
communicationsare
securedfromintentional
corruption(e.g.,via
unauthorizedcreation,
modification,deletionor
replay)(DonaldG
Firesmith,2005)

Infectthesystem
(onewaycanbeto
useundesirable
program)

Corruptadata
Theapplicationshall
preventthe
unauthorized
corruptionofdata
collectedfrom
customersandother
externalusers(D.G.
Firesmith,2003)

Theapplicationshall
preventthe
unauthorized
corruptionof
attachedhardware
Theapplicationshall
preventthe
unauthorized
corruptionofemails
thatitsendsto
customersandother
externalusers(D.G.
Firesmith,2003)

Anunauthorized
agentattemptsto
createunauthorized
corruptiontothe
dataor
communicationof
thesystem/
application/centre

82

d.Software
Integrity(DonaldG
Firesmith,2005)

4.Nonrepudiation
andAccountability
Requirements(D.G.
Firesmith,2003)

5Privacy
Requirements

a.Anonymity(D.G.
Firesmith,2003)

Anonrepudiation
requirementisany
securityrequirementthat
specifiestheextentto
whichabusiness,
applicationorcomponent
shallpreventapartyto
oneofitsinteractions
fromdenyinghaving
participatedinallorpart
oftheinteraction(D.G.
Firesmith,2003)

Aprivacyrequirementis
anysecurityrequirement
thatspecifiestheextent
towhichabusiness,
application,component
orcentershallkeepits
sensitivedataand
communicationsprivate
fromunauthorized
individualsandprograms
(D.G.Firesmith,2003)

b.Communications
(D.G.Firesmith,
2003)

c.DataStorage(D.
G.Firesmith,2003)

Confidentiality

Theapplicationshall
preventthe
unauthorized
corruptionofall
communications
passingthrough
networksthatare
externaltoany
protecteddata
centers(D.G.
Firesmith,2003)
Theapplicationshall
preventthe
unauthorized
corruptionofthe
software
Theapplicationshall
makeandstore
tamperproofrecords
ofthefollowing
informationabout
eachorderreceived
fromacustomerand
eachinvoicesenttoa
customer(D.G.
Firesmith,2003)

Theapplicationshall
notstoreany
personalinformation
abouttheusers(D.G.
Firesmith,2003)

Theapplicationshall
notallow
unauthorized
individualsor
programsaccessto
anycommunications
(D.G.Firesmith,
2003)
Theapplicationshall
notallow
unauthorized
individualsor
programsaccessto
anystoreddata(D.G.
Firesmith,2003)
Theapplicationshall
provideaccessto
confidentialdataonly
totheauthorized
userswhohavethe
privilege

Anagent
intentionallytriesto
tampertherecords
ofinteractions
(message,
transactionsetc)of
thesystem/
application/centre

Anunauthorized
agentattemptsto
gainaccesstoany
dataor
communicationof
thesystem/
application/centre

Todenyusage/to
denyaction(thiscan
bedonebydeletethe
datausedasaproof
orCreatesimilar
proof

Get
privilege/disclosure
ofinformation

83

6SecurityAuditing
Requirements(D.G.
Firesmith,2003)

7.Survivabilityand
Availability
Requirements(D.G.
Firesmith,2003)

8.Physical
Protection
Requirements(D.G.
Firesmith,2003)

9.System
Maintenance
Security
Requirements(D.G.
Firesmith,2003)

10.Attack/
HarmDetection
Requirements
(DonaldGFiresmith,
2004)/Intrusion
Detection
requirements(D.G.
Firesmith,2003)

a.Availability
requirements

Asecurityauditing
requirementisany
securityrequirementthat
specifiestheextentto
whichabusiness,
application,component,
orcentershallenable
securitypersonnelto
auditthestatusanduse
ofitssecurity
mechanisms(D.G.
Firesmith,2003)
Asurvivability
requirementisany
securityrequirementthat
specifiestheextentto
whichanapplicationor
centershallsurvivethe
intentionallossor
destructionofa
component(D.G.
Firesmith,2003).Ensuring
timelyandreliableaccess
toanduseof
information.[common
criteria][federal
standards]
Aphysicalprotection
requirementisany
securityrequirementthat
specifiestheextentto
whichanapplicationor
centershallprotectitself
fromphysicalassault(D.
G.Firesmith,2003)
Asystemmaintenance
securityrequirementis
anysecurityrequirement
thatspecifiestheextent
towhichanapplication,
component,orcenter
shallpreventauthorized
modificationsfrom
accidentallydefeatingits
securitymechanisms(D.
G.Firesmith,2003)

AnAttack/harmor
intrusiondetection
requirementisany
securityrequirementthat
specifiestheextentto
whichanapplicationor
componentshalldetect
andrecordattempted
accessormodificationby
unauthorizedindividuals
(D.G.Firesmith,2003)
Anysecurityrequirement
thatisrelatedto
maliciousharm(DonaldG
Firesmith,
2004)(Information&
Systems,1999)

Theapplicationshall
collect,organize,
summarize,and
regularlyreportthe
statusofitssecurity
mechanismsincluding
accesscontrol,
immunity,privacy
andintrusion
detection.

Anagent
maliciouslyattempts
toattackortamper
theauditingprocess
ofthesystems/
applications/
centresstatusand
securitymechanism

Stealtheauditstatus
(tomitigatethisone
weshouldusesome
kindoflawthat
governsthesecurity
personnels)

Theapplicationshall
nothaveasingle
pointoffailure(D.G.
Firesmith,2003).
Theapplicationshall
beaccessibletothe
authorizeduser.

Anunauthorized
agentintentionally
destroysasystems
/applications/
centrescomponent
tocreateitsfailure
ortohamperits
legitimateuserto
accessthe"system.

Denialofservice

Thedatacentershall
protectitshardware
componentsfrom
physicaldamage,
destruction,theftor
surreptitious
replacement(D.G.
Firesmith,2003)
Theapplicationshall
notviolateitssecurity
requirementsasa
resultofthe
upgradingofadata,
hardwareorsoftware
component(D.G.
Firesmith,2003)

Anagenttriesto
intentionallydamage
orharmphysically
thehardwareor
componentsor
personnelofthe
system/
application/centre
Anagent
(authorizedor
accidental)attempts
toviolatethe
security
requirementsduring
theusagephase
(upgrading/
replacement/
removalofdata,
hardwareor
software
component)ofthe
system/
application/centre.

Physicallyassault

Failsecure(the
Upgradingofdata,
software,
hardware)(thesystem
shouldpreserveits
securedstate)

Attemptpossibilities
tointrude

Thesystemshall
detectthepresence
ofatleast99.9%of
denialofservice
attacks

84

b.Confidentiality
Requirements

c.Integrity
Requirements

d.Nonrepudiation
Requirements

Thesystemshall
preventthe
corruptionof
confidentialdataby
atleast99%ofthe
attacksthatlastno
longerthan1hour
andaremadeby
attackerswithprofile
X
Upondetectionof
corrupteddata,the
systemshallnotify
thesecurityengineer
within5secondsat
least99.99%ofthe
time
Thesystemshalluse
virusdefinitionsanda
virusscanenginethat
havebeenupdated
withintheprevious
24hours,ifsuchan
updateexists.

Note:Requirementsareprioritizedaccordingtoscalehighpriority,mediumpriorityandlowpriorityasshownbelow:

8.4

APPENDIXD(CLASPandFrameworkSecurityRelevant
Requirements)

Note:Requirementsareprioritizedaccordingtoscalehighpriority,mediumpriorityandlowpriorityasshownbelow:
PriorityScale(1:High,2:Medium,3:Low)

ID
1
IDENTIFIER
MF_R001
TITLE
NoRemoteaccessed toSystem
REQUIREMENT
Systemshallworkwithinorganization.
RATIONALE
Systemcannotbeaccessremotely.
RESTRICTION
OnlyCSR(Customerservicerepresentative)canaccess
system.
DEPENDENCIES
NA
Type
AuthorizationRequirement.
Actor
3270Terminal
Priority
1

ID
2
IDENTIFIER
MF_R002
TITLE
TimeCritical
REQUIREMENT
Systemshalldisplaycorrectresultwithin5secondsof
makingtherequesttothesystem.
RATIONALE
Customerservicerepresentativemustrespondtocustomer
ineffectivemanner.
RESTRICTION
Inordertoupdate,createorsearchdatacustomerhastocall
CSR.
DEPENDENCIES
4
Type
DataIntegrityRequirement,
Actor
3270Terminal
Priority
1

ID
3
IDENTIFIER
MF_R003
TITLE
Unauthorizedaccess
REQUIREMENT
Thereshallbenoaccesstodatawithoutauthorization.
RATIONALE
Nocustomercanhavedirectaccesstodata.
RESTRICTION
OnlyCSRcanaccessthedata.
DEPENDENCIES
5

85

Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION

AuthorizationRequirement.
3270Terminal
1

4
MF_R004
Availabilityofsystem
Systemshallbeavailableallthetimeanditshouldbefault
tolerant.
Customerservicerepresentativemustrespondtocustomer
whenneeded.
OnlyCSRhaveaccesstosystem.
2
AvailabilityRequirement.
3270Terminal
2

5
MF_R005
Validcredentials
Customersrepresentativeshalluseloginandapasswordto
accessthesystem.
Inordertomaintainsecurity,CSRmustuseusernameand
passwordtoinitiateCICS.
OnlyCSRcanhavedirectlyaccesstosystem.
3,9
AuthenticationRequirement.
3270Terminal
2
6
MF_R006
CICSaccessible
CICSShallonlybeaccessiblethrough3270terminal
CSRcaninitiateCICSthrough3270terminal.
OnlyCSRcaninitiatetheCICSthrough3270terminal.
1
AuthorizationRequirement
3270Terminal
2
7
MF_R007
RACFAuthorization
Returnedtoapplicationanddisplayedonthescreenonlyif
RACFauthorizationallows.
RACFcheckswhethertheuserispermittedtoreadthe
relevantfile.
OnlyRACFsystemcangivedatasetandtransaction
permissions.
AuthorizationRequirement
SecurityRequirement
3270Terminal
2

8
MF_R008
UpdateInformation
Applicationusercancreatenewclaimorcanupdate
information.
Applicationmustupdatedataforspecifiedcustomer.
IFRACFallowsit,recordisupdatedinVSAMfile.

86

DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTION
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

5
Dataintegrity
3270Terminal
3
9
MF_R009
Loginattempts
Systemshallnotsupportmorethan3loginattempts(incase
ofloginfailures).
Becauseofimprovedsecuritywewishtohave3login
attemptsafterthatsystemwouldnotbeavailable.
Systemshouldnotsupportmorethan3loginattempts.
5
AuthenticationRequirement.
3270Terminal
1

10
MF_R010
CommunicationFailure
Rollbackshallbesupportedincaseofcommunicationfailure
duringtransaction.
Torestorethedatatoitsprevious state.
NA
NA
DataintegrityRequirement.
3270Terminal
1
11
MF_R011
64bitoperatingsystem
Mainframeshouldrununder64bitoperatingsystem.
Oursecurityframeworksupport64bitoperatingsystem

Thiscaseonlysupport64bitoperatingsystem.
NA
SystemRequirement
3270Terminal
3
12
MF_R012
Extraportsclosed
Allportsexceptportsconnecting3270terminalshallbe
closed.
Closeentrypointstorestrictanydirectinteractionwithdata.
Systemshallonlybeaccessiblefrom3270terminal
NA
ConfidentialityRequirement.
3270terminal
1
13
MF_R013
VSAMFile
CICScanonlyaccessVSAMfileafterauthenticatingtheuser
fromRACF.
Restrictunauthorizedaccesstodata
Customerdatacanonlybeaccessedbyauthorizedcustomer
servicerepresentatives
7,6
AuthenticationRequirement
CICS
1

87

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

8.5

14
MF_R014
PublicMethods
Publicmethodshallbedeclaredasfewaspossible.
Followsecurecodingstandards.
Unauthorizedaccessi.e.usingpublicmethodstoenterthe
systemisnotallowed.
5
AuthorizationRequirement,Authentication
User
1

APPENDIXE(CLASPandFrameworkSecurityAnalysis
Requirements)

Note:Requirementnumber15isofframeworkonly.
ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor

15
MF_R015
CICSession
UsercanonlyinitiateCICsessionafterauthenticlogin.
Toprotectcustomerdata
OnlyCSRcanloginthesystem
9
Authentication
3270terminal
1
16
MF_R016
Filesandprocesses
Thereshouldbealimittothemaximumnumberoffilesand
processesthatauserisallowed.
CSRisnotallowedkeepthesystemsresourcesunnecessarily
busy.
OnlyCSRcanaccessthesystemfile.
3
Availability
3270terminal
2
17
MF_R017
EncryptedData.
DatamustbestoredinEncryptedform.
Inordertoprotectdata,itmustbestoredinencryptedform.
OnlyCSRcanaccessthesystem
18
ConfidentialityRequirement.
3270terminal.
2

18
MF_R018
Datacommunication
Alldatacommunicationthroughnetworkmustbeencrypted.
Inordertoprotectdata, communicationthroughnetwork
mustbeencrypted.
IBMMainFrame
17
ConfidentialityRequirement
3270Terminal

88

Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

8.6

2
19
MF_R019
Physicalaccesstomainframe.
Thereshouldbenophysicalaccesstomainframe,network
and3270terminalbyanyunauthorizedperson.
Onlyauthorizedpersoncanaccesstosystem.
OnlyCSRcanloginthesystem
3
AuthorizationRequirement
3270terminal.
2

20
MF_R020
Codingguidelines.
Propercodingguidelinesmustbefollowedtopreventattacks
likebufferoverflowandSQLinjection.
Avoidprogrammingvulnerabilities
OnlyCSRcanexecutetheapplication
NA
DataintegrityRequirement.
3270terminal
3

APPENDIXF(FrameworksfinalupdateRequirements)

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

21
MF_R021
Accessapplicationsystemfile.
Usermustnotbeallowedtoaccessapplicationsystemfile.
Attackercannotcorruptormanipulateapplication/system
files.
OnlyCSRcanaccessthesystemfile.
3
Authorizationrequirement
3270terminal
1
22
MF_R022
SoftwareInstallation
AnyTypeofsoftwareinstallationshallbestrictlyrestricted.
Softwareinstallationmustberestrictedtoavoidmalware
installation.
IBMMainFrame
23
ConfidentialityRequirement.
3270Terminal
2
23
MF_R023
Downloaddata
Applicationshouldnotallowdownload,copyanykindof
data.
Companypolicy
OnlycanCSRcanloginthesystem
22
ConfidentialityRequirement.
3270terminal.
2

89

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE

RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT

RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

8.7

24
MF_R024
Accesstoanycommunication
Applicationshallnotallowaccesstoanycommunication
Attackermustnotbeabletomodifyanyfilesormessages
duringcommunication.
OnlyCSRcanexecutetheapplication
NA
NONrepudiation
3270terminal
2
25
MF_R025
RACFLogFiles
NoaccessshallbeallowedtoRACFLOGfiles.
Operationlogshowsdetailofthetransactionssothata
problemcanbetracedback.
CSRmustnothaveany accesstoRACFlogfiles.
3
Accountability.
3270Terminal.
1
26
MF_R026
Intrusiondetectionmechanism
Intrusiondetectionmechanismshallbeimplementedatall
entrypointsandcommunicationpoints.
Intrusiondetectionmechanismshallbeimplementedatall
entrypointsandcommunicationpointstoprotectcustomer
data.
Portsareblocked.
19
ConfidentialityRequirement.
3270Terminal
1
27
MF_R027
Failureofasystemcomponent
Ifanycomponentofthesystemfailsorstopsresponding,
systemmustnotallowoperationsuntilsystemstarts
functioningnormally
Failureofanycomponentcanmakesystemvulnerable
Theremustnotbeanydirectaccesstodata
19
ConfidentialityRequirement.
3270Terminal
1

APPENDIXG(MisuseCaseRequirements)

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID

M1
MC_R001
EncryptedData.
DatamustbestoredinEncryptedform.
Inordertoprotectdata,itmustbestoredinencryptedform.
OnlyCSRcanaccessthesystem
18
Confidentiality.
3270terminal.
2
M2

90

IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type
Actor
Priority

ID
IDENTIFIER
TITLE
REQUIREMENT
RATIONALE
RESTRICTIONANDRISKS
DEPENDENCIES
Type

MC_R002
NoRemoteaccesstoSystem
Systemshallworkwithinorganization.
Systemcannotbeaccessremotely.
OnlyCSR(Customerservicerepresentative)canaccess
system.
NA
AuthorizationRequirement.
3270Terminal
1

M3
MF_R003
Extraportsclosed
Allportsexceptportsconnecting3270terminalshallbe
closed.
Closeentrypointstorestrictanydirectinteractionwithdata.
Systemshallonlybeaccessiblefrom3270terminal
NA
ConfidentialityRequirement.
3270terminal
1

4
MF_R004
NodirectaccesstoVSAM
CICScanonlyaccessVSAMfileafterauthenticatingtheuser
fromRACF.
Restrictunauthorizedaccesstodata
Customerdatacanonlybeaccessedbyauthorizedcustomer
servicerepresentatives
NA
Authorization

91

8.8

APPENDIXH(Questionnaire)

92

8.9

APPENDIXI(FeedbackForm)

Doyouhaveanyexperienceinworking/elicitingsecurityrequirementsforsoftware?
Response

Chart

Frequency

Yes

60%

No

40%

Totalresponses:6

Haveyoueverusedorhaveanyknowledgeaboutanytechniqueforsecurityrequirementelicitation?
Response

Chart

Frequency

Yes

17%

No

83%

Totalresponses:6

Wastheinformationprovidedaboutthesoftwaresystemenoughtounderstandthesystem?
Response

Chart

Yes

Frequency

67%

No

33%

Totalresponses:6

Whatwasthelevelofunderstandingoftheactivitiesfromthematerialprovidedonthescaleof1to5(1isveryeasyand5is
verydifficult)?
Response

Chart

Frequency

0%

33%

17%

17%

93

Response

Chart

Frequency

33%

Totalresponses:6
Editthisitem
Whatwasthelevelofapplicationoftheactivitiesfromthematerialprovidedonthescaleof1to5(1isveryeasyand5isvery
difficult)?
Response

Chart

Frequency

0%

17%

67%

17%

0%

Totalresponses:6

Doyouthinkthatthetimetoperformtheseactivitiesforprovidedsoftwaresystemwasenough?
Response

Chart

Yes

Frequency

67%

No

33%

Totalresponses:6

Doyouthinkthatifyouperformtheseactivitiesagain,youcanproducebetterresults?
Response

Chart

Yes

Frequency

50%

No

50%

Totalresponses:6

Doyouthinkthatduringtheseactivitiesyouanalyzedthesystemfromdifferentaspectswhichareusuallyarenotconsidered
insoftwaredevelopment?
Response

Chart

Frequency

94

Response

Chart

Frequency

Yes

67%

33%

TotalResponse6

No

ThisExperimentimprovedyourknowledgeaboutsoftwaresecurityandsoftwareattackscenarios?
Response

Chart

Yes

Frequency

67%

No

33%

Totalresponses:6

8.10 APPENDIXJMisuseCaseTemplate
Field
Name
Summary
Date
Author
BasicPath
AlternativePath
CapturePoint
ExtensionPoint
Triggers
Preconditions
Assumptions
Postconditions
WorstCaseThreat
Preventionguarantee

Detectionguarantee
RelatedBusinessRule
PotentialMisuserProfile
Stakeholders
Scope
AbstractionLevel
TechnologyandDataVariations
Goal
Dependencies(Relationship)
SecurityConstraints

Description
MisuseCaseName/Title
ExplanationofMisusecase
DateofcreationofMisusecase
CreatorofMisusecase
Stepswhichamisuserisgoingtotakebeforereachingthegoal
Otherpathsthroughwhichthesamegoalcanbereached
Optionsforhowmisusecanbedetectedandprevented[61].
Optionalpathstakenbymisuse
Conditionthatcaninitiatemisusecase
Thisconditiondescribesthosestatesofthesystemwhichmakemisuse
possible
This condition describes those states of the systems environment
whichmakemisusepossible
Stateofthesystemaftersuccessfulmisusecase
Maximum damage possible in case of a successful misuse case.
Optionalpathsarealsoincluded.
Prevention Guarantee describes the result that would be obtained by
following the Basic or Alternate path if the threat were detected
andminimumthreatmitigationoccurs.[34]
TheDetectionGuaranteedescribestheresultthatwouldbeobtained
ifthemisuseweredetected,butnotmitigated.[34]
RelatedBusinessRulesareusecasebusinessrulesthatarebrokenby
themisusecase[34]
Levelofskillsandintentionsofthemisusemustbeassessedinorderto
beawareoftheseverityofthreat
The people who have concern about what should not happen in the
system
The scope of modeling, e.g., the entire business or just the planned
computerizedinformationsystem[80]
Whatisthelevelofabstractionforthemisusecasee.g.summary,sub
functionetc.
Which various ways and technologies can be used to achieve the
misuse
Whichgoalofthestakeholderishindered
RelationshipofStakeholderwithotherStakeholder(s)
InformationaboutSecurityconstraintsonStakeholder(s)

95

8.11 APPENDIXKSequenceDiagramShowingActivityFlow

96

8.12 APPENDIXLUseCaseDiagramforMonolithicSystem

System

Authentication
(RACF)

Log In

Request to Execute
Application

Application

Request for
customer data
Customer Data

3270 Terminal

To update customer
data

Validate User

Whether the user is permitted to

read the relevant file

Check
Authorization(RACF)
Update customer
data

If RACF allow it, record is

returned to application
from VSAM file

View Data from VASM

Determine whether the user is

permitted to update file
Check
Authorization(RACF)
If RACF allows it,record
is updated in VSAM File
Database
Updation(File)

Update Data on the 3270 terminal

97