Any correspondence concerning this service should be sent
to the repository administrator: [email protected]
This is an author’s version published in:
http://oatao.univ-toulouse.fr/24828
To cite this version: Hamid, Brahim and Weber, Donatus
Engineering secure systems: Models, patterns and empirical
validation. (2018) Computers & Security, 77. 315-348. ISSN
0167-4048
Official URL
DOI : https://doi.org/10.1016/j.cose.2018.03.016
Open Archive Toulouse Archive Ouverte
OATAO is an open access repository that collects the work of Toulouse
researchers and makes it freely available over the web where possible
Engineering
secure
systems:
Models,
patterns
and
empirical
validation
Brahim
Hamid
a, ∗,
Donatus
Weber
baIRIT,UniversityofToulouse,118RoutedeNarbonne,ToulouseCedex931062France
bChairforEmbeddedSystems,UniversityofSiegen,Hoelderlinstrasse3,D-57076Siegen,Germany
Keywords: Security
Systemengineering Pattern
Meta-modeling
Modeldrivenengineering
a
b
s
t
r
a
c
t
Severaldevelopmentapproacheshavebeenproposedtohandlethegrowingcomplexityof softwaresystemdesign.Themostpopularmethodsusemodelsasthemainartifactsto con-structandmaintain.Thedesiredroleofsuchmodelsistofacilitate,systematizeand stan-dardizetheconstructionofsoftware-basedsystems.Inourwork,weproposeamodel-driven engineering(MDE)methodologicalapproachassociatedwithapattern-basedapproachto supportthedevelopmentofsecuresoftwaresystems.Weaddresstheideaofusingpatterns todescribesolutionsforsecurityasrecurringsecurityproblemsinspecificdesigncontexts andpresentawell-provengenericschemefortheirsolutions.Theproposedapproachis basedonmetamodelingandmodeltransformationtechniquestodefinepatternsat dif-ferentlevelsofabstractionandgeneratedifferentrepresentationsaccordingtothetarget domainconcerns,respectively.Moreover,wedescribeanoperationalarchitecturefor de-velopmenttoolstosupporttheapproach.Finally,anempiricalevaluationoftheproposed approachispresentedthroughapracticalapplicationtoausecaseinthemetrologydomain withstrongsecurityrequirements,whichisfollowedbyadescriptionofasurveyperformed amongdomainexpertstobetterunderstandtheirperceptionsregardingourapproach.
1.
Introduction
System andsoftware securityengineering(Anderson,2008; Barnabeetal.,2011;Devanbuetal.,2000)hasbecomea cru-cialbusinessaspectbecauseorganizationsarecompletely de-pendentoncomputer-basedsystemsandinvestsubstantial resourcesinmaintainingthem.Standardsareavailablefor se-curingITsystems,suchasNIST800-60,andControlSystems (ICS),suchasNIST800–82.Althoughtheygivelittleguidance tosoftwareengineersonhowtoimplementthem,theyshould beappliedfromtheearlystagesoftheconceptionofasystem. Mostworkmustbedonemanuallybecauseonlyafewtools areavailabletoaidintheimplementation.Thiscauses exten-siveworkandincurssubstantialextracosts.Thus,thereisa
∗Correspondingauthor.
E-mailaddress:[email protected](B.Hamid).
needtosupporttheengineeringofsecuresystemprocesses withasmuchautomationaspossible.Therefore,developers ofthesesystemsneedto“designforsecurity”.Thisincludes definingthecurrentstructureofthesystem,i.e.,thesystem architecture,findingabstractrisksandconcrete vulnerabili-ties,andimplementingtheappropriatecountermeasuresto mitigaterisksandvulnerabilitiestomeetthesecurity require-mentsofthesesystems.Ourcontributiontothischallengeis tomakethesystemsecurityengineeringprocessmanageable andunderstandablethroughnovelmethodsandtoolsthat en-surethatsystemsecuritysolutionsarebuiltbydesign.
Securityexperts,practitioners andresearchersfrom dif-ferentinternationalorganizations,associationsandacademia have agreed that for security, “it’s not just the code” (Fernandez, 2013; M. Howard, 2007; Neumann, 2004). The mostpopularandwell-knownsoftwaresecurity vulnerabili-tiesaredesignissues,particularlyarchitecturedesignissues. Fromthesystemdeveloperperspective,securityissuesneed
tobeidentified earlyinthe firstdevelopmentstepsand at thehighestlevels,primarilyinthearchitecturedesignstage, wheretheirsemanticsareclear.Whensecurityrequirements are determined,architecture and designactivities are con-ductedusingmodelingtechniquesandtoolsforhigher qual-ity and seamless development.The integration ofsecurity featuresusingthisapproachrequireshighexpertisefor de-veloping thearchitectureanddesignandthe availabilityof bothapplication-domain-specificknowledgeandsecurity ex-pertise.Becausefewexpertswiththisdiversesetof experi-encesexist,capturingandprovidingthisexpertisebymeans ofsecuritypatterns(Anwaretal.,2006;Hafizetal.,2007; Schu-macher,2003;YoderandBarcalow,1998)canenhancesystem developmentbyintegratingthemintodifferentstagesof sys-temsengineering.Therefore,securitysolutionsaredescribed assecuritypatterns,andtheapplication-domainspecificuse ofthesepatternsisprovidedintermsofsecuritytechnological productsthatarealreadyestablishedinthatdomain.
Inthispaper,wepresentamodel-basedapproachfor en-gineeringsecuresystemsthatusespatternstorepresent secu-ritysolutionsandknowledge,whichfostersreuse.Thiswork is conductedwithin the contextofa model-basedsecurity anddependabilityresearchproject,andourcollaborationwith security-critical systemsuppliers suggestedaneedforthis work.Thesecuritysolutionsusedbysecurity-criticalsystem developersarebasedontheapplicationdomainand occasion-allyonthesoftwaredevelopmentenvironment,includingthe designandcodingstages.Thereisaneedtolinkthese con-ceptstosecurity.Thelackofappropriatelinksbetween ap-plicationdomainconceptsandsecurityconceptsposesthree mainchallenges.First,thesecurityengineermustre-engineer existingsolutions.Second,theapplicationdesignermaynot understand domain-specific securitysolutions. Finally,it is difficultforasystemdevelopertoguaranteetheavailability ofsecuritysolutionstocoverthesecurityrequirementsofthe targetedapplicationusingapplicationdomainconcepts.
Toprovideaconcreteexample,weusesmartmeter sys-tems.Inthese systems,thereare a numberofsubsystems working together tocommunicate andexchange the up to datesensingandmeasurementofenergyconsumedwiththe smartgrid.Withintheselargesystems,wefocus onlyon a smartmetergatewayasthecommunicationunitofmodern smartmeters.Agatewayiscapableofconnectingtoseveral metersfordifferentcommodities,suchaselectricity,gas, wa-terorheat,andcommunicatingwithhouseholdsandother remoteentities,suchasregulations.Smartmetersandtheir gatewaysgeneratesecurityandsafetyrelevant,aswellas pri-vacysensitivedataandtransmitthemoverpossiblyinsecure networks.Therefore,aspecialkindofprotectionisrequired forthisdata.
Toaddresstheaboveproblem,wepromoteanew method-ology for system engineering using a pattern as its first-classcitizen:Pattern-basedSystemandSoftwareEngineering (PBSE).WeuseMDE(AtkinsonandKühne,2003)abstraction mechanismstodefineandhandlesecuritypatternsthrougha metamodelthatunifiesthoseconcepts.Moreover,weuseMDE transformationmechanisms(FranceandRumpe,2007;Selic, 2003)thatcanadaptandgeneratedifferentrepresentations, wherepatterns are clearlyrelated todomainmodels. Such an MDE-based approach utilizes domain-specific modeling
languages(DSMLs) (Grayetal.,2007)builtonanintegrated repository of modeling artifacts that function as a group, whereapatternisattheheartofdevelopment-itsroleshould bespecifiedinall lifecycle stagesofdevelopment.In addi-tion,weaimtoprovideformalsecuritysemanticsfor pattern-basedsystem models.Asa result,patternscan beusedas brickstobuildapplicationsthroughamodel-driven engineer-ingapproach.Inthiswork,EclipseModelingFramework Tech-nology (EMFT) 1 isused to buildthe supporttools forour approach.Allmetamodels arespecifiedusing theEMF.The repositoryisimplemented usingtheapproachdescribed in (Hamid,2017),whichisbasedontheEclipseCDO2 framework. Inourwork,thetargetdomaindevelopmentenvironmentis IBMRationalRhapsody3 ,andthedescriptionsofthemodel transformationsarebasedontheQVToperationallanguage (OMG,2011).However,ourvisionisnotlimitedtotheEMF plat-form.Othermodelingtoolsconformingtotherequirementsof
Section5 canalsobeused.
Themaingoalofthis workistodefine amodeling and developmentframeworktosupportthespecifications, defini-tionsandadaptationofasetofmodelingartifactstoassistthe developersofsecureapplications.Thepatternsthatareatthe heartofoursystemengineeringprocessreflectdesign solu-tionsatthedomain-independentanddomain-specificlevels. Theenvisionedmodelingframeworkoffersanintegrated con-ceptualdesignforthespecificationanddevelopmentof secu-ritypatternsandaconcreteandcoherentmethodologyforthe developmentofsoftwaresystemsbasedonsecuritypatterns. Weprovideevidenceofitsbenefitsandapplicabilitythrough theexampleofarepresentativeindustrialcase,i.e.,thesmart metergatewayapplication.
WehavepreviouslystudiedvariousfacetsofPBSEto engi-neersecureanddependablesystems.Ourpriorworkincludes modelinglanguagesforthespecificationofsecurityand de-pendabilitypatterns(Hamid etal.,2011),designand imple-mentationofareusemodelrepository(Hamid,2014).Further, thebasicformulationoftheneedtohaveastrongapproach forsupportingthe engineeringofsecuresystemshasbeen previouslypublishedinaresearchpaperintheinternational journalofInnovationsinSystemsandSoftwareEngineering (Hamidetal.,2016).Thisarticlebringstogetherandextends theideasdescribedintheearlierpapersandpresentsa holis-ticapproachtothemodelingofpattern-basedsoftware sys-temswithstrongsecurityrequirements.Specifically,we pro-videamorecomprehensiveandcompletedescriptionofour approach(Section4)andtoolsupport(Section5),alongwith substantialnewvalidationtoshowthefeasibilityand useful-nessofourapproach(Section6).
Theremainder ofthe paperis organizedasfollows.An overviewofthechallengesfacedinengineeringsecure sys-temsinthecontextofindustrystandardsandpracticesis pre-sentedinSection2.Section3providesamotivatingexample thatmodelsasoftwarearchitectureforawebapplication.In
Section4,wepresentourapproachforsupportingthe pattern-basedsystemandsoftwaresecurityengineering.Section5 de-scribes the architecture of the tool suite and presents an
1 https://eclipse.org/modeling/emft/. 2 http://www.eclipse.org/cdo/.
exampleimplementation.InSection6,wepresentan empiri-calevaluationofourapproachthroughtheTERESAmetrology casestudyandasurvey.Section7 presentsexperimental re-sultsinthecontextrelevanttosecuritygoalsandthreat analy-sis.Then,Section8discussesourcontribution.Section9 com-paresourworkwithrelatedwork.Finally,Section10concludes andsketchesfutureworkdirections.
2.
Generalities
and
background
The engineering of secure systems with security require-ments typically requires the certification of suchproducts according to genericstandards (e.g.,Common Criteria(CC) 15408-1(ISO/IEC,2007),ISO31000(DaliandLajtha,2012;ISO, 2009))ordomain-specificstandards(e.g.,NIST800-60(Stineet al.,2008),ISO/IEC27001(ISO,2013),ProtectionProfile(PP)(BSI, 2014)).Theysupportsystemengineersinthedevelopmentof securesystemsrecommendingasetoftechniquesand mea-surestoachievethedesiredlevelofsecurityofanapplication. Forinstance,theCCstandardprovidessupportwhen build-ingasecuresystembyofferingclassesoffunctionalsecurity componentstoaddresswell-knownsecurityprinciples(e.g., authenticity,encryption,and audit) and aset ofguidelines tosupportsecurityexperts.ThroughtheaforementionedPP standarditispossibletoadddomainspecifictothegeneral approachinextendingandrefiningrequirementsand knowl-edgetothetargeteddomain(e.g.,encryptionstandards,hash functions,SSL,andTPM).
Theengineeringofinformationsystemswithsecurityhas been well established via standards and generalmethods. However,theyprovidelittle guidancetosoftwareengineers onhowtoimplementthem.Mostworkmustbedone manu-ally,asonlyafewtoolsareavailabletoaidinthe implemen-tation.Mostofthesetechniquesandmeasuresareprovided intheformofdesigndecisionstargetingonestageofthe de-velopmentlifecyclewithouteffectiverealization.Theyshould beappliedfromtheverybeginningstageoftheconceptionof thesystem.Inaddition,theformatinwhichthetechniques andmeasuresarepresentedmustbeimprovedtoensurethat theprovidedsolutionsarestorable,reusableandappropriate fortheautomationofsoftwaredevelopmentandanalysis. Fur-thermore,thecost-effectivedevelopmentandcertificationof the targetedproductsisachallenge, and thereusability of provensolutionsenablescostandtime-to-marketreductions. Ourworkaimstoprovidenewmethodologicaltoolsupport thatenablesthesesolutions(techniquesandmeasures)tobe reusedfordevelopmentwithinthesameapplicationdomain orinacross-domainscenario.Asdescribedbelow,asubsetof techniquesandmeasuresproposedinthestandardscanbe usedtodefineseveralsecuritypatterns.
2.1. Model-basedsoftwaresystemssecurityengineering
Ageneralmethodologyfordevelopingsecurity-critical soft-wareusingmodelshasbeenproposedin(Jürjens,2001; Jür-jens,2006).ItusesaUMLextension(profile)calledUMLSecto includesecurity-relevantinformationinthe existingmodel and diagrams.Theapproachissupportedbyextensive au-tomated tool supportforperforming a securityanalysis of
theUMLSec modelsagainstsecurityrequirements and has beenusedinavarietyofindustrialprojects(J.JürjensandR. Rumm,2008).Wecanalsocitetwoothersystemdesign model-drivensoftwaresecurityengineeringprocessesbasedonUML profiles:SecureUML(Lodderstedtetal.,2002)andSecureMDD (Moebiusetal.,2009).SecureUMLprovidesaUMLprofilebased onrole-basedaccesscontrols(RBAC),enablingspecificationof accesscontrolintheoverallsystemdesign.Thisinformation canbeusedtogenerateaccesscontrolinfrastructures,helping thedeveloperstoimproveproductivityandthequalityofthe systemunderconstruction.SecureMDDproposesa method-ologythatenablesthegenerationofplatform-specific mod-els(e.g.,JavaCard)fromahigh-levelstereotypedUMLmodel. Inadditiontoguidelinesformodeling securityaspects,the frameworkoffersverificationbasedonaformalapproachfor theproducedmodels(Grandyetal.,2006).Inadditiontothe aboveapproaches,Leeet al.(Leeet al.,2002;2000)propose anintegrationmodelforintegratingsecurityengineering ap-proachesintosoftwarelifecyclestandards,mappingthe con-ceptsofthesoftwarelifecycle(IEEE12207)tosecurity engi-neeringconcepts (a set ofconcepts collected from various securityengineering approaches (Lee et al.,2000)).The ap-proachattemptstoprovideanunderstanding to stakehold-ersofwhereandwhensecurityactivitiesinterveneand inter-actwithstandardprocesslifecycleactivities.Inthe develop-mentofsecuresystems,Basinetal.(Basinetal.,2009)usea metamodelcalledSecureUML+ComponentUML,which com-bines SecureUML(Lodderstedtet al.,2002)and Componen-tUML (asystem designmodeling language for component-basedsystems).Thismetamodelisusedtomodelsecurity de-signmodelsandsecurityscenariosstartingfromaninformal securitypolicy.Apattern-orientedapproachformodeling se-curecomponent-basedsoftwaresystemscombiningpatterns andUMLsec(Jürjens,2006)waspresentedin(Schmidtand Jür-jens,2011).
2.2. Pattern-basedsoftwaresystemssecurityengineering
Patternsareencapsulatedsolutionstorecurrentsystem prob-lemsanddefineavocabularythatconciselyexpresses require-mentsandsolutionsaswellasprovideacommunication vo-cabularyfordesigners(Gammaetal.,1995;Henningeretal., 2007).Patternsaretriplesthatdescribesolutionsforcommonly occurringproblemsinspecificcontexts.Pattern-based develop-menthasrecentlygained moreattention insoftware engi-neeringbyaddressingnewchallengesthathadnotbeen tar-getedinthepast(Henningeretal.,2007).Theideaofdesign patternswasintroducedbyanarchitect(Urbanist), Christo-pherAlexander(Alexanderetal.,1977).Thefirstobjectivewas toenhance architectural quality,beauty, elegance and har-monytoavoiddehumanizationofthelivingenvironment.In GoF(Gammaetal.,1995),adesignpatternextractsthekey ar-tifactsofacommondesignstructurethatrendersitusefulfor creatingareusableobject-orienteddesign.Wenowrecallthe definitionoftheterm“securitypattern” thatwefoundinthe literature(Schumacher,2003).
Definition1(securitypattern).Asecuritypatterndescribesa particularrecurringsecurityproblem thatarises inspecific
contexts andpresentsawell-provengenericschemeforits solution.
AdaptingthedefinitionsofSchumacher(2003),wepropose thefollowing:
Definition2(Systemofsecuritypatterns). Asystemof secu-ritypatternsisacollectionofsecuritypatternsforminga vo-cabulary.Suchacollectionmaybeskillfullywoventogether intoacohesivewholethatrevealstheinherentstructuresand relationshipsofitsconstituentpartstowardfulfillingashared securityobjective.
Security patterns enablethe development ofsecure ap-plicationsandliberatethedeveloperfromhavingtoaddress security-relatedtechnicaldetails.MDE(AtkinsonandKühne, 2003; Selic, 2003) also provides a very useful contribution tothedesignofsecurity-criticalsystems(Basinetal.,2009; 2006;Jürjens,2006;Lucioetal.,2014)becauseitreducesthe time/cost requiredforunderstandingandanalyzingsystem artifact descriptions due tothe abstractionmechanisms. It alsoreducesthedevelopmentprocesscostduetothe genera-tionmechanisms.Hence,securitypatternintegrationmustbe consideredduringtheMDEprocess.
2.3. Securityanalysisandevaluation
A typical evaluation approach in software system secu-rity engineering is to compare an implementation with a comprehensive list ofcategories agreedupon byan expert community.AnexampleistheOWASP(OpenWeb Applica-tionSecurityProject)list(OWASP,2017b).Ontheonehand,the analysisdiscoverspotentialrisksandareasforimprovement; ontheotherhand,itcanraiseconfidenceinthechosen archi-tecturalapproaches.
Thecurrentpracticetoformulatesecuritystatements is giventhroughexpressingattackercapabilitiestoe.g.gain ac-cesstoaprotecteddatafromamessageobservation(i.e., neg-ative statements).Microsoft forexample usesa threat tax-onomy from the attacker’s perspective calledSTRIDE 4 . To define the securityarchitecture ofthesystem, weneed an analysis ofthe possiblethreats; securitypatterns canthen beintroducedtostopormitigatethem(Fernandez,2013;S.T. Halkidisetal.,2008).Asopposedtothis,theproperty-based approaches(Fuchsetal.,2010;J.Jürjensand R.Rumm,2008) expresssecuritystatementsintermsofasetofdesirable se-curityproperties(i.e.,positivestatements)usingcommon tax-onomiessuchasCIA5 .Patternsthenareintroducedaccording toexpectedsecurityproperties.
Duringthesecurityapplicationdesigntime,formal mod-elingofpatternscanprovesomeofthepropertiesofa pat-ternsolution(securitymechanisms),whichmayrequirea spe-cializedandcostlyverificationprocess(e.g.,basedonformal methods(Hamidet al.,2016;Paulson,1996)).Atsystem de-signtime,wecanevaluatethesecurityriskofsystemsthat usedspecificsecuritypatternsbyseeinghowwellthey han-dledasetofthreatsbyasimplematchingofthreatsto
pat-4STRIDEstandsforSpoofing,Tampering,Repudiation,
Informa-tiondisclosure,Denialofservice,andElevationofprivilege.
5CIAstandsforConfidentiality,IntegrityandAuthenticity.
terns(Fernandez,2013).Often,anattackonasystemresults inthenot-fulfillmentofspecificsecurityproperties.Therefore, threatscanbestoppedbythefulfillmentofsecurity proper-ties.Ifwehaveapatternforeachsecurityproperty,wecan considerthesystemsecureatthemodellevel.Sincethen,itis stillremainsvulnerabilitiesatcodelevel.However,attacksat codelevelarereducedbyanappropriatearchitecturaldesign. Further,forsystemsrequiringstandardizationand certifi-cation,wecanrelyonexistingsecurityriskanalysismethods suchasEBIOS(McDonaldetal.,2013),CORAS(Braberetal., 2007)andsecurity-HAZOP(Srivatanakuletal.,2004).Inthese methods,athreatandriskanalysisisexecutedusingmethods suchasthethreatmodelingwithattacktrees,asdescribedin (Schneier,1999).Theoutputofthesemethodsisasetof rec-ommendationsandguidelinestodetectpossiblerisks, evalu-atethemandthenmitigatethem.Patternsenabletheimplicit applicationofpoliciesandinthesametimepatternisa sys-tematicapproachtodescribebestpractices.Further,pattern candescribestandardsandregulationsinaprecisewayand makethemmoreunderstandableandusable.
3.
A
motivating
example
TheexampleisbasedonanOWASPexampleofacollege li-brarywebsite(OWASP,2017a).Fig.1showstheoverall architec-turedescriptionofthewebapplication.Itconsistsofaclient, awebserverandadatabaseserversoftwarecomponents.The websiteprovidesonlineservicesforsearchingforandfor re-questingbooks.Theusersarestudents,collegestaffand li-brarians.Staffandstudentswillbeabletologinandsearchfor books,andstaffmemberscanrequestbooks.Librarianswillbe abletologin,addbooks,addusers,andsearchforbooks.We useUMLclassdiagramtodescribethehighlevelarchitecture modelofthewebapplication,wheresoftwarecomponentsare representedbyclasses,andrelationshipsbetweenthese com-ponentsarerepresentedbyassociations.
Fig. 1 depicts the corresponding software architecture. There areimplicit security designdecisions,because inter-nalandexternalconnectionsusepublicorprivatenetworks. There is alsoan ad-hoc subcomponentfor “authorization” thatgroupsthreeentities(Webserver,Databaseand Administra-tor)thatcollaborateinordertoensurethattheapplicationhas clearlydefinedtheusertypesandtherightsofsaidusers. Nev-ertheless,severalcontrolsrelatedtosecurityareoutlinedin
Table1.Thesecontrolsmaybefoundineachrespective stan-dardofeachdomain(BSI,2014;ISO,2013;Stineet al.,2008; OWASP,2017a).
Fig.2 showstheclassdiagramthataddssecuritycontrols ofTable1.Eachonerepresentsaspecification (blueboxes). However,effectiverealizationsofthesecontrolsarenot mod-eledinthe UMLclassdiagram;theymaybesubjectto cer-tainchangesand/oradaptations(newsecuritysolutions, dele-tions,modificationsofrealization,forinstance),verifications (formalandempirical,forinstance)andreuse(inthesame do-mainoracrossdomains,forinstance)whilethestructureof themainsoftwarearchitecturecanbemaintained.
Fig.3showstheclassdiagramthataddsnewcomponents torealize the security controlsof Table1. Eachone repre-sentsapattern(redboxes),whichsecuresoftwaredevelopers,
Fig.1– Amotivatingexample.
Fig.2– Motivatingexamplewithsecuritycontrols.
Fig.3– Motivatingexamplewithsecuritypatterns.
mainlyarchitectswouldlikesoftwaremodelingandanalysis languagesmayeasilyexpress.
At this point, several questions were raised: If existing modelinglanguages(Basinetal.,2009;J.JürjensandR.Rumm, 2008;Moebiusetal.,2009)providesupportforengineering se-curesystems,howcanwedefinethesepatternsintermsof theirconstructs?Mustwemodifyandoverloadtheexisting software engineeringprocess todefine thesepatterns? Are
therealternatives tospecifythesepatternswhile maintain-ingtheoverallstructureofthesoftwareengineeringprocess? Dotheexistingsoftwaremodelinglanguageshaveenough ex-pressivenesstoseriouslyaddress theseissues?What ideas areresearchersproposingtoincorporatesecurityin model-basedsoftwaresystemengineering?Whatadvantagesand disadvantageshavetheirproposals?Further,weattemptto addmoreformalitytoimprovepartsofthesystemdesign.In
Table1– Listofsecuritycontrols(OWASP,2017a).
Security property
# Securitycontrols
Authenticity sc1 Ensureallinternalandexternal connectionsgothroughanappropriate andadequateformofauthentication. sc2 Ensureallpagesenforcetherequirement
forauthentication.
Confidentiality sc3 Ensurenosensitivedataistransmittedin theclear,internallyorexternally. sc4 Ensurethatauthenticationcredentialsdo
nottraversethewireincleartextform. Authorization sc5 Ensurethatthereareauthorization
mechanismsinplace.
sc6 Ensurethattheapplicationhasclearly definedtheusertypesandtherightsof saidusers.
ourcontext,wehaveidentifiedtwodimensions:aglobal sys-temviewpoint(e.g.,doesthesystemprovideasufficient se-curitylevel?)andanindividualfunctionalviewpoint(e.g.,isa specificsecurityfunctioneffective?).
Therefore,therearetwomainprerequisitestodefiningthe pattern-basedsoftwaresystemsecurityengineering method-ology.Thefirstisthatitmustbecompatiblewithcurrent de-velopmentprocesses.Theobjectiveisnottochangethehabits ofengineers;instead,easingtheacceptanceoftheapproach inindustryisthegoal.Thesecondprerequisiteisthatitmust beflexibleenoughtoadapttootherspecificprocessesinother domains.Weseekasolutionbasedonthereuseofsoftware subsystems, i.e.,so-calledsecuritypatterns that havebeen pre-engineeredtoadapttoaspecificdomain.Theapproach describedinSection4 usesMDEtechniquestohandlethe is-suesdescribedabove.
4.
Approach
Theproposedapproach(Fig.4)iscomposedofsixmainsteps (thenumbersinparenthesescorrespondtothenumbers in
Fig.4).Step1isresponsibleforcreatingtheconceptualmodel ofsecuritypatterns.Theresultingconceptualmodelisused tobuildaDSMLtospecifysecuritypatterns(step2).The se-curityexpert,withthesystemandasoftwareengineering ex-pert,usesthisDSMLtodefinesecuritypatterns(step3).Then, adomainprocessexpertcreatesandadaptsthesecurity pat-ternsintoaversionthatissuitableinitssystemdevelopment process(step4).Anexampleisadaptationforcompliancewith anappropriatestandard.Moreover,inthecontextofourwork, certainpatternshaveameaningfulrepresentationonlyfora certaindomain.Wethendevelopandapplyappropriate trans-formationsofapatternrepresentationinasuitableformatfor thedevelopmentenvironment(step5).Patterninstantiation astheinitialactivitytoapplyapatternisperformedduring step4andstep5.Finally,thedomainengineerreusesthe re-sultingadaptedandtransformedpatterns forthegiven en-gineeringenvironment(developmentplatform)todevelopa domainapplication(step6).Patternintegrationinthedesign activityisappliedduringthisstep.Inaddition,weattemptto
useformaldescription(e.g,formalmodeling)ofsecurityand architectureforthepurposeofthedevelopmentofan accu-rateanalysis,forevaluationand/orcertification.
Thefirsttwosteps(1and2)areperformedonceforasetof domains.Theinputsofthesestepsareexpertise,standards and best practices from the security expert. Step3 is per-formedonceforasetofdomains.Step4isperformedonceper applicationdomain.PerformingStep3requiresknowledgeof securityengineering,whereas Step4requiresknowledgeof bothsecurityengineeringandthesystemdevelopment pro-cessforaspecific applicationdomain.Step5isperformed onceforeachdevelopmentenvironment.Step6isperformed onceforeverysystemintheapplicationdomain.Thisstep re-quirestheavailabilityofknowledgeonthespecifictargeted systemanddedicatedtoolsthatarecustomizedforagiven developmentplatform.Intherestofthissection,wepresent detaileddescriptionsofthesixstepsinourapproach.
4.1. Step1:Conceptualmodelofsecuritypatterns
Atthebeginningofthispaper,weindicatedtheneedforan explicitinterpretationofsecurityinarchitecturedesignand motivatedwhypatternsareausefultoolfordesigningsecure systemsarchitectures.Weachievethistaskinthefirststepof ourapproachviathecreationofaconceptualmodelof secu-ritypatterns.Aconceptualmodelofsecuritypatternsprovides acommonunderstandingofallconceptsemployedinthis pa-pertoensureaprecisedescriptionoftheaddressedproblems andsolutionapproaches.
Aconceptualmodelofasecuritypattern shouldcapture the mainconcepts and relationships to describethe secu-ritypatternmodelsinthecontextofdifferentstandardsand domain-specificpractices.Tomaintainthecurrentaudience andawareness,weretainpartoftheterminologydefining sec-tionsinthetemplatetodocumentpatterns(Alviand Zulker-nine,2011;Buschmannetal.,2007).WeemployUMLclass di-agramstodescribetheconceptualmodel,whereconceptsare representedbyclasses,conceptattributesarerepresentedby classattributes,andrelationshipsbetweenconceptsare rep-resentedbyassociations.Whenanattribute’svaluebelongs toapredefinedsetofpossiblevalues,weuseenumerations. Packagenotationisusedtocreategroupingsofconcepts.
Agraphicalrepresentation ofthe conceptsand relation-shipsfromtheexcerptisgiveninFig.5.Toimprove under-standingandreadability,theattributesofthedifferent con-ceptsandthelinksbetweentheconceptsarenotdescribed. WenotethatthemodelinFig.5 isapartialrepresentationof theconceptsandrelationshipsrelevanttothepattern defini-tionandusage.
The
context
package
containsallconceptsfor describ-ingthe environmentinwhichthe patternwillbebuiltand employed,including securitypolicystatements,the system developmentlifecycle,andthetypeofsystemassetsto pro-tect(e.g.,applications,distributions,anddata).Theproblem
package
containsallconceptsthatareemployedfor describ-ingthesecurityproblem,includingthethreatcatalog,threat scenario, vulnerabilities, types of attacks, security objec-tives,functionalsecurityrequirementsandotherforces.Thesolution
package
regroupssecuritytechnologyconcepts, suchasbestpractices,controls,safeguards,countermeasures,Fig.4– MethodologyforthecreationofthePBSEmodelingframework.
Fig.5– Securitypatternconceptsandtheirrelationships.
designsolutions,securitymechanismsandCOTS (Commer-cialoftheShelf)components.The
usage
package
regroups all activitiesfor integration-application in the designs and classificationinformationtosupportsearchmechanismsthat surpasskeyword-basedsearchandretrieval,including guide-linesforpatternapplication,knownusesandexamples.Thesystem
of
patterns
package
containsall concepts for describingthecollectionofpatternsand patterns’ relation-shipswithotherpatterns,includingcomposition, dependen-cies and conflicts. Theverification
package
regroups conceptstochecksecurityproperties,whichensuresthe qual-ity of the solution including properties, assumptions and constraints. Theevaluation
package
regroups concepts for evaluating patterns,including concepts to describe theimpactonotherarchitecturequalityattributes,including per-formance,cost,usabilityandfeedback.
These concepts and their related observations are em-ployedasabasisforourconceptualpattern modeling lan-guage(refertoSection4.2).
4.2. Step2:CreationofaDSMLfromaconceptualmodel ofsecuritypatterns
In this section, we emphasize software patterns as a way todesign asecure software architecture (Fernandez, 2013), which builds on a semi-component patterns representa-tion. In software engineering, the separation of concerns promotes the separation of general-purpose services from
implementations.Inourcontext,wetargettheseparationof thegeneralpurposeofapatternfromthemechanisms em-ployedtoimplementthepattern.Thisisanimportantissue forunderstandingtheuseofpatternsinthescope of secu-rityengineering.Thelayerinwhichpatternsandtheirrelated mechanismsareintegratedisdependentontheassuranceof aclientintheservicesofotherconcernedlayers.Security pat-terns are definedfrom a platform-independentperspective (i.e.,theyareindependentoftheirdedicatedimplementation mechanisms);theyareconsistentlyexpressedwith domain-specificmodels.Consequently,theyare mucheasierto un-derstand andvalidatebyapplicationdesignersinaspecific area.Tocapturethisvision,weintroducetheconceptofthe domainperspective,whereasecuritypattern atthe domain-independentlevelexhibitsanabstractsolutionwithout spe-cific knowledge of how the solution is implemented with regard tothe applicationdomain.Theobjective istoreuse thedomain-independentmodelsecuritypatternsforseveral application domains and enable them to customize these domain-independent patterns with their domain knowl-edgeand/orrequirements toproducetheirdomain-specific artifacts.
Tomodelsecuritypatterns,amodelinglanguagewas de-velopedbasedontheconceptualmodelcreatedinStep1.The SystemandsoftwareEngineeringPatternMetamodel(SEPM) is constructedbased on anadditional analysisofdifferent standards from different domains that focus on software-based systems.Theset ofconceptsthat were employedto developthe modelinglanguage tocapturethesetwolevels ofdetailstorepresentsecuritypatternswere identified: ab-stract pattern concepts to define apattern atthe domain-independent level(DIPM)and concrete pattern concepts to defineapatternatthedomain-specificlevel(DSPM).For in-stance,abstractpatternconceptsincludepoliciesandbest prac-tices,whereasconcretepatternconceptsincludedomainbest practicesandmechanisms.
Forourpurpose,weproposeusingawell-knownapproach inMDE:aDSML.Thisapproachisusefulbecauseweare stor-ingalibraryofdesignpatternsinacommonrepositoryand providing one or more adaptationsof each pattern to tar-getseveralapplicationdomains,e.g.,themetrologyindustry, anddifferentdevelopmentenvironmentdomains,e.g.,UML. However,ourvisionisnotlimitedtoDSML.Forexample,in (Radermacheretal.,2013),wedefinedaUMLprofileunderthe UMLpapyrustool6 tospecifypatterns.
4.2.1. Informaldescriptionofthemotivatingpatternexample
Theproblemaddressedinourexampleishowtoensurethat thedatatransmittedoveranypublicnetworkissecurein tran-sit,particularlyhowtoguaranteedataauthenticity.Weshow thefeasibilityofourapproachthroughtheexampleofSecure Communication Pattern (SCP).On thedomain-independent level,thispatternusesabstractsendandreceiveactionsand abstractcommunicationchannelsthatare assumedto pro-videauthenticity.However,onthedomain-specificlevel,SCPs areslightlydifferentintheapplicationdomain.Asystem do-mainmay haveitsown mechanisms,meansand protocols
6http://eclipse.org/papyrus/.
thatcanbeemployedtoimplementthispatternincludeSSL, TLS,Kerberos,IPSec,SSH,andWS-Security.Insummary,they aresimilaringoalbutdifferentinimplementationissues.This isthemotivationtohandlethemodelingofsecuritypatterns bythefollowingabstraction.Asanexample,onthe domain-specificlevelweusetheTLSmechanism(DierksandRescorla, 2008)asaconcreteimplementationoftheSCP.
TheTLSmechanismiscomposedoftwophases:theTLS Handshake that establishes a secure channel, and the TLS Recordinwhichthischannelcanbeusedtoexchangedata se-curely.TheclientinitiatestheTLShandshakebyprovidingthe serverwitharandomnumberandinformationregardingthe cryptographicalgorithmsitcanhandle.Theserverrepliesby choosingtheactualalgorithmtouse,optionallyrequiringthe clienttoauthenticateitself,andbysendingarandom num-berofitsownanditscertificateissuedbysomeCertification Authoritytrustedbyboththeserverandtheclient.
Toauthenticateitself,inthefinalhandshakemessage,the client includesits own certificate, a signature on all three handshakemessagesgeneratedwiththeclient’sprivatekey, and a third random number that is encrypted using the server’spublickeycontainedintheserver’scertificate.After verifyingthecertificatesandsignature,bothclientandserver usetheexchangedrandomnumberstogeneratesessionkeys forgenerating and verifyingmessage authenticationcodes (MACs)andforencryptingand decryptingmessagesduring theTLSrecordphase.
SincethekeyusedbytheclienttogenerateaMAC/encrypt amessageisusedbythe serveronlyforMACverification / decryptionandviceversa,andsincethesekeysarebasedon onerandomnumberthatisconfidentialtotheclientandthe server,thekeysestablishachannelthatprovidesauthenticity andconfidentialityforbothclientandserver.
4.2.2. Abstractsyntax
Weproposeanabstractsyntax(ametamodel)bymeansofan OMG-stylemetamodeltoconstructtheSEPMmodeling lan-guage.Theabstractsyntaxisbasedonpreviousrequirements and describesvariousconcerns,suchasengineering,reuse and integrationaspects.Inourvision,webuildon a semi-componentpatternrepresentation.Therefore,asecurity pat-ternisa subsystemthatexposespattern functionalitiesby interfacesandtargetsecuritypropertiestoenforcethe secu-ritysystemrequirements.Interfacesareemployedtoexhibit apattern’sfunctionalityandmanageitsapplication.In addi-tion,interfacessupportinteractionsbetweensecurity primi-tivesandprotocolswithinaspecificapplicationdomain.The principalclassesofthesystemandsoftwareengineering pat-ternmetamodel(SEPM)aredescribedwithEcorenotationsin
Fig.6(notallclassesandattributesareshownonthediagram toavoidcluttering).Theirmeaningsareexplainedinthe fol-lowingparagraphs.
• SepmPattern.Thisblockrepresentsasecuritypatternasa subsystemthatdescribesasolutionforarecurring secu-ritydesignproblemarisinginaspecificdesigncontext.A SepmPatterndefinesitsbehaviorintermsofprovidedand requiredinterfaces.Largerpiecesofasystem’s functional-itymaybeassembledbyreusingpatternsascomponents ofanencompassingpattern oranassemblyofpatterns;
Fig.6– AnoverviewoftheSEPM.
therequiredandprovidedinterfacesarewiredtogether.A SepmPatternmaybemanifestedbyoneormoreartifacts. • SepmDIPattern.ThisisaSepmPatternthatdenotesan
ab-stractrepresentationofasecuritypatternatthe domain-independentlevel.Thisisthekeyentryartifacttomodel patternsatthedomain-independentlevel(DIPM). • SepmInterface.ASepmPatterninteractswithitsenvironment
via SepmInterfaces, whichare composedofoperations.A SepmOperationrepresentsthefunctionalinterfaceofthe pattern. A SepmPattern represents the provided and re-quiredinterfaces.Aprovidedinterfacehighlightsthe ser-vicesexposedtotheenvironment.Arequiredinterface cor-respondstoservices requiredbythepattern tofunction properly.
Weconsidertwointerfacetypes:
– SepmExternalInterface.Thisenablestheimplementation ofinteractionstointegrateapatternintoanapplication modelortocomposepatterns.
– SepmTechnicalinterface. This enables the implementa-tionofinteractionswithsecurityprimitivesand proto-cols,suchasencryption,andspecializationforspecific underlyingsoftwareand/orhardwareplatformsduring thedeploymentactivity.ASepmDIPatterndoesnothave SepmTechnicalInterfaces.
Forourexample,onemayidentifythefollowingexternal interfaces:
– send(P,Q,ch(P,Q),m), – receive(P,Q,ch(P,Q),m),
withPandQdenotingtheapplicationsenderSand appli-cationreceiverR,respectively,ch(P,Q)theircommunication channel,andmamessage.
• SeReference.Thislinkisusedtospecifytherelationship be-tween patternswithregard tothedomainand software lifecyclestageintheformofapattern language.For ex-ample,apatternatacertainsoftwarelifecyclestageuses anotherpatternatthesameordifferentsoftwarelifecycle stage.SeReferenceKindcontainsexamplesoftheselinks. • SeArtifact. We define a modeling artifact as a
formal-ized pieceofknowledgeforunderstanding and commu-nicatingideasproducedand/orconsumedduringcertain activitiesofsystemengineeringprocesses.Themodeling artifactmaybeclassifiedinaccordancewithengineering processlevels.
• SeLifecycleStage.ASeLifecycleStagedefinesthedevelopment lifecyclestageinwhichtheartifactisused.Inourstudy,we focusonsecuritypatternmodels.Inthiscontext,weuse thepatternclassificationofRiehleandZüllighoven(1996),
• SepmProperty.Thisisaparticularcharacteristic ofa pat-ternrelatedtotheconcernthepatternisaddressingand dedicatedtocapturingitsintentinacertainmanner.The conceptisemployedtodescribethesecurityaspectsofthe subsystemtoenforcethe securitysystemrequirements. Anexampleissecurityproperties.Theconceptisusedto describethesecurityaspectsofthesubsystemtoenforce the securitysystemrequirements.ASepmPropertyis de-finedthroughaname,asemantic,anexpressionanda cat-egory.Thesecurityattributesfrom(Avizienisetal.,2004) arecategoriesofsecurityproperties.Eachpropertyofa pat-ternisvalidatedatthetimeofthepatternvalidating pro-cess,andtheassumptionsarecompiled asasetof con-straintsthatmustbesatisfiedbythedomainapplication (Hamidetal.,2016).Forourexample,wedefinethe follow-ingsecurityproperties:
– authenticityofactionaandactionbforanapplicationentity P.Thus,eachtimeactionboccurs,itmustbeauthentic foranapplicationentitythatactionahasoccurredas well.Forexample,eachtimeanapplicationreceiverR receivesdatad,itmustbeauthenticforhimthatthese arethesamedatadasthedatasentbyaspecific ap-plicationsenderS,i.e.,theactionofsendingthesedata, performedbyaspecificapplicationsenderS,mustbe authenticfortheapplicationreceiverR.
– integrityofdata.Whendatadarereceivedbythe appli-cationreceiverR,thosesamedatadaresentoutbythe applicationsenderS.
– confidentialityofdata.Itdenotesthatonlyspecific sys-tementitiesareenabledtoknowthevalueofdatad. Forexample,theprivatekeyisconfidentialtoitsowner andtheapplicationsenderStruststheconfidentiality ofthecertificateauthorities’(CA)privatekey.
• SepmConstraint.Thisisasetofrequisitesofthepattern.If theconstraintsarenotmet,thepatternisnotableto de-liveritsproperties.Aconstraintisaconditionthatholdsor mustholdduringtheapplicationofapattern.Itisbasedon thenotionofpreandpostconditionspecificationas com-monlyusedinmanyformalmethods.Inourcontext,the assumptionsderivedduringtheformalizationand verifi-cationprocessesofthepatternwillbecompiledasaset ofconstraints,forinstance,resourceconstraintsthatwill havetobesatisfiedbythedomainapplicationbeforethe patternapplicationcanbeperformedandafterthepattern isapplied.Forourexample,wespecifyconstraintsonthe cryptographicalgorithms,onthesizeofthecryptographic key,ontheuseofasecuritylibraryandontheresources consumedbyasecuritylibrary.
• SepmInternalStructure.Thisconstitutestheimplementation ofthesolutionproposedbythepattern:howthe partici-pantscollaboratetocarryouttheirresponsibilitiesforthe realizationofthesolution.Thus,theInternalStructurecan beconsideredasawhiteboxthatexposesthedetailsof theSepmDIPatternandtheSepmDSPattern.Onepatterncan haveseveralpossibleimplementations,providingsupport forpatternvariability.
• SepmParticipant.Alistingofthe componentsusedinthe patternandtheirresponsibilitiesinthedesign.Inour con-text,aparticipant isacomponenttypewitha security-specificpurpose.It’sroleistoaddnewfunctionalitytothe
systemthatisspecifictoasecurityrequirementthe sys-temshoulduphold.
• SepmDSPattern. Thisisa refinementof SepmDIPattern.It is used to build a pattern at the domain-specific level (DSPM).Becausemostknowntechniquesthataddress se-curityabilityarecryptography-basedmodels,weintroduce theSepmDSPatternwithamechanismattributetocapture suchnotionsintheSepmDIPatternmodel.Intheexample introducedinSection4.2.1,TLSisonetechniquetoachieve securecommunication,andtherearealternativewaysto achievethesamegoal.Furthermore,aSepmDSPatternhas TechnicalInterfacestointeractwiththeplatform.Thisisthe keyentryartifacttomodelthepatternattheDSPM.
4.2.3. Concretesyntax
Tocreatemodelinstancesoftheproposedmetamodels,we must provide concrete syntaxes. In our context,we use a mixedsyntaxthatcombinesstructured-treesyntax,textual syntax and a UML-based diagrammatic syntax to describe theSEPM’sconcretesyntax.Thebasicideaisthattheformer definesproblemsandobjectives,thetextualdefines proper-tiesandconstraints,andthediagrammaticpartdefinesroles andsolutions(SepmInternalStructure).Theobjectivebehindthis separation isthata solutiondefined inthe pattern canbe integrated(withoutlosinginformation) intothe application architectureonlyifbotharespecifiedinthesamemodeling language,e.g.,UML.Conversely,theproblemstatementand objectivesareindependentofthechosenmodelinglanguage. Thisseparationenablessolutionsdefinedindifferent model-inglanguagestosharethesameproblemdefinition,whichis usefulbecausewearestoringdesignpatternsinacommon repository,whereas model specificationsin the structured-tree syntax are separately managed and stored.A pattern might eventuallyhave multiplesolutions definedin differ-entmodeling languages.Thepattern discoveryapproaches, i.e.,themechanismstobrowseorsearchpatternswithinthe repository,are basedonthenon-diagrammaticpart. There-fore,fromaDSMLconstructionperspective,designpatterns arecomposedoftwoparts:
• Structured-tree component. Pattern definition that defines patternpropertiesandattributes, suchassafety proper-ties,resourceconstraints,developmentphases,and rela-tionships.Thesedataareusedtoeasepatternsearchand analysis.
• UML-baseddiagrammaticcomponent.Patterninternal struc-turedesignfilesgeneratedviaadditionaltools,e.g., Rhap-sodyor Papyrus (UMLeditors),which are storedasXMI filesand canbe attachedto thepattern description file (SepmDocument).
4.2.4. Patternverificationprocess
Formalmodelingofpatterns,combinedwithmodelchecking, canprovesomeofthepropertiesofapattern’ssolution.We havemadesomeexperimentations(Hamidetal.,2016;2011) toapplythe techniquesforformallyprovingsecurity prop-ertiesofsecuritypatternsprovidedbythesecuritymodeling framework(SeMF)developedbyFraunhoferSIT(Gürgensetal., 2005),followingthetwoabstractionlevelsofthepattern rep-resentations.Incontrasttootherformalsecurityengineering
methods(Devanbuetal.,2000;Landwehr,1981;Paulson,1996), the usedformal securityframework,referredtoasSeMF,is notfollowingthe attack northe riskbased approaches.Its basisareasetofdesiredsecuritypropertiesandassociated assumptions.WithSeMF itispossibletovalidateif proper-tiesliketrust,authenticityorconfidentialityholdundergiven assumptions.The sidebenefitis casea stated assumption doesnotholdisthatpossibleconsequencesinregardto secu-ritypropertiescanbeestimated.Theproofitselfisconducted mostlywithpencilandpaperandtheresultedproofartifacts willbeutilizedbythedesignerasinputtothepattern-based developmentprocess.Formoreinformationregardingthe for-malframeworkandthedefinitionsofsecuritypropertieswe referthereadertoFuchsetal.(2010)andHamidetal.(2016).
Here,wereporton anexperimenttoapply SeMF tothe DIPMandDSPMforthesecurecommunicationpattern target-ingthesecuritypropertyeachtimetheserversideofthe commu-nicationchannelreceivesamessageonthechannel,fortheserverit authenticallyoriginatesfromtheclientsideofthechannel.
4.3. Step3:Definitionofsecuritypatterns
OncewehavedevelopedtheDSML’sconcretesyntaxinStep 2,wecancreatethesetofsecuritypatternstosharethe secu-rityexpertisewithinthedomainofinterest.Duringthisstep, thepatterns areconstructedsuchthattheyconformtothe metamodeldescriptionadoptedinStep2.Tofoster technol-ogyreuseacrossdomains,thepatternsarestoredina reposi-tory,suchasthatdescribedinHamid(2017),thusreducingthe amountofeffortandtimeneededtodesignacomplexsystem. Thetargetrepresentationisthedomain-independentlevel (DIPM),whilestillconformingtotheSEPMmetamodel.Atthe DIPMlevel,thisdescriptionrevealsthefollowingelements: in-terfacesoftypeSepmExternalInterface,securitypropertiesoftype SepmPropertyandsolutionsoftypeSepmInternalStructure. More-over,forclassificationandrelationshipdefinition purposes, additional information may be defined, e.g., lifecycle stages oftype SeLifecycleStageand relationships oftypeSeReference, respectively.
Thefirsttaskistocreateabasicpatternsubsystemasan instanceoftheSepmPattern.Theinstanceisgivenaname and aset ofattributesthat correspondtothe pattern.The description,withvaryinglevelsofabstraction,ismanagedby inheritance.Oncethebasicpatternsubsystemisspecified, in-terfacesareaddedtoexposesomeofthepattern’s functional-ities.Foreachinterface,aninstanceofSepmExternaInterfaceis addedtothepattern’sinterfacecollection.Thenextstepafter creatinginterfacesisthecreationofpropertyinstances.An in-stanceiscreatedinthepattern’spropertycollectiontospecify everyidentifiedsecurityproperty.Apropertyisgivenaname andanexpressionbasedonexternalinterfacesinaproperty language.
Wecontinueourillustrationusingtheexampleofthe se-curecommunicationpattern.Forthesakeofsimplicity,we spec-ifyonlythoseelementsrelatedtobothStep2andStep3that arerequiredtoexplainourapproach.Thesecure communi-cationpatternenablesasecuredataexchangebetween com-ponentsoveranon-securecommunicationchannel(e.g., Eth-ernet),thusensuringtheintegrityandconfidentialityofthe dataandtheauthenticityofthesender.Messagessentamong
distributedsystemfunctions(components)shallarrivefrom authorized sender(s) without data modification.If any at-tackersendsamessageormodifiesanexistingone,this mes-sageshouldbediscardedbythereceiversecurity communi-cationlayer,andthedestinationfunctionmightbeinformed ofthisaction.
Thedomain-independentpatternusesanabstract chan-nelandprovidesmessageauthenticityunderspecific assump-tions,particularlywithregardtothetrustoftheserverwith theprecedenceofitsownreceiveactionviaasendaction per-formedbytherespectiveclient.Thechannelauthentication layerusesaproprietarykeytoauthenticateitselfinthe com-munication.Onthereceivingside,thechannelauthentication performsnecessarycheckstoensurethatthereceived mes-sageisauthenticandthatthedatareceivingfunctiontrusts thechannelauthentication.Inourexample,weidentifiedtwo externalinterfaces,onefortheclientandonefortheserver, providingthefollowingfunctions:
• establCh(P,chk (P,Q)):Pestablishesachannelchk withQ, • send(P,chk (P,Q),m):Psendsmessagemonthechannelchk
sharedwithQ,
• recv(P,Q,chk (P,Q),m):Preceivesandacceptsmessagemon thechannelchk sharedwithQ,
• closeCh(P,chk (P,Q)):Pclosesthechannelchk sharedwithQ. withP∈{C1,...,cn }andQ=Sorviceversa,chk (C,S)=chk (S,C) andk∈N.
Thenextconcern oftheprocess isthe definitionofthe patternsecurityproperties.Thesupportingactivitiesrequire theavailabilityofasetofpropertylibraries.Fortheexample ofthe securecommunicationpatternattheDIPMlevel,we specifythesecurityproperty:“authenticityofreceivingforthe server”.Forthiswenotethattheserverseesitsownactions, thustheactionofreceivingamessageisparticularly authen-ticfortheserveritself.Further,theserverwillneveraccepta messageonachannelithasalreadyclosed:Everyreceive ac-tionforaparticularmessagemoccurswithinanactive chan-nel.Thismeansthatreceiptandacceptanceofamessageby theserveroccurauthenticallyfortheserverwithinthephase thatcorrespondstotheactivechannelchk (P,Q)being estab-lishedandclosed,respectively.Totypethe categoryofthis propertyweuseacategoryfromtheonesdefinedinthe secu-ritycategorylibrary“Authenticity”.Fortheothertypesof prop-erties,wehavetoconsideraconcretesolution.Thereexist var-iousdifferentpossibilitiesforsuchpatternsthatrefinethe ab-stractcommunicationchannelandthustheabstractpattern. Onepossibilityis,e.g.,toexecuteaDiffieHellmanbasedkey exchangealgorithm.Anotherpossibilitythatwewillfocuson inthenextsectionistheestablishmentofaTLSchannel.
Furthermore,each patternisstudiedtoidentifyits rela-tionshipswithother patternsbelongingtothe same appli-cationdomainbasedonthe engineeringprocess activityin whichit isutilized.Thepurposeofthis activityisto orga-nizepatternsintoasetofpatternsystems.Moreover,thisstep shouldincludeallactivitiesthat supportpattern producers inmanagingtherelationshipsamongthesepatterns,which canbedefinedinpatternrelationshipmodellibraries.Ateach stage(phase)nofthesystemengineeringdevelopment pro-cess,thepatternsidentifiedinthepreviousstage(phase)n− 1
Fig.7– Tree-shapedpatternrefinementandspecialization.
canassistintheselectionprocessduringthecurrentphase. Similarly,wespecifymodellibrariesforpatternsclassification. Ateach stageofthe systemengineering development pro-cess,theappropriatepatternsareidentifiedviaaclassification process.
Afteraninitialanalysisofthevariousartifactsources, in-cludingstandardsandexistingapplications,thedesigner de-terminesthestageoftheengineeringprocesslifecycle (sys-temconcept,systemarchitecture,softwarearchitecture,and detailed module design) in whicheach pattern can be de-fined;moreover,whetherthepatternisdomain-independent ordomain-specificcanbedetermined.Forthispurpose,we se-lectthepatternclassificationofRiehleandZüllighoven(1996),
Buschmannetal.(2007,1996),whodefinedsystempatterns, ar-chitecturalpatterns,designpatternsandimplementationpatterns tocreatetheSeLifecycleStagemodellibrary.Inaddition,a pat-ternmaybelinkedwithotherpatternsandassociatedwith propertymodelsusingapredefinedsetofreferencetypes,at averyhigh-level(Noble,1998)orincludingdetailsregarding whatpartofapatternisused,refined,orcombined(Hauge, 2014).Here,wecreatetheSeReferenceKindmodellibraryto sup-portthespecificationofrelationshipsacrossartifacts(e.g., re-fines,specializesanduses)asanextensionoftherelationship classificationproposedin(Noble,1998).
Inthecontextofourwork,certainpatternshavea mean-ingfulrepresentationatthesystemlevel,atwhichgeneral sys-tem blocksare definedand domainconceptsareexpressed (e.g.,systemskeleton).However,theirrepresentationsmight notbedirectlyrefinedinlaterphasesbecausetheyrepresent conceptsthataremeaningfulatonlythearchitecturallevel.In contrast,otherpatternsmightbemeaningfulonlyinlater de-signphasesasindirectspecializationsofanarchitectural con-cept,e.g.,asecureremotereadout(SRR)softwarepatternisa specializationofanarchitecturalskeletonpattern.Inaddition, thesamepatternmayhavemultipleinstantiationsand spe-cializationsineachphase(e.g.,aWakeupServiceislinkedto ahardwarecomponent).Therefore,asshowninFig.7,agiven designpattern(securecommunicationpattern)inthe reposi-torymightfollowatree-shapedrefinementandspecialization flow,representingdifferentlifecyclephases,different refine-mentsandspecializations,andnewpatternrepresentations inlaterphases.Forinstance,TLSprovidesthemechanismsfor confidentialinformationexchangethroughECC (NIST-P256) to supportsecure channel definition and content data en-cryptionandtheauthenticationofcommunicationpartners throughdigitalsignaturesusingECDSA(NIST-P256).
4.4. Step4:Definitionofsecuritypatternsforaspecific domain
Atthedomain-specificlevel(DSPM),thesecuritypatternand someofitsrelatedelementsarealsocreatedbyinheritance. OnceaSepmDSPatterniscreated,everypatternexternal inter-faceisidentifiedandmodeledasarefinementoftheDIPM’s SepmExternalInterfaceinthepattern’sinterfacescollection. Then,followingthepattern’sdescriptionoftheparticular so-lutionthatisrepresented,eachofthepattern’stechnical inter-facesisidentifiedandmodeledbyaninstanceof SepmTechni-calInterfaceinthepattern’sinterfacescollection.
Inthecontextofourexperiment,themetrology domain-specificpatternmustbecompliantnotonlywiththegeneric securitystandardsbutalsowithmetrology-specificsecurity standards.Somepatterns,forexample WakeupServiceare defined exclusively for the metrology domain and others are adapted from generic security standards. For instance, intheCommonCriteriaProtectionProfileofthesmart me-tergateway(BSI,2014),theuseoftheTLSprotocol(referto
Section4.2.1)providingasecurecommunicationchannel be-tweentwocommunicationpartnersismarkedasmandatory forall connections betweena gateway and wide area net-work.Therefore,thedomainspecificsecurecommunication pat-ternasarefinementofthedomainindependentoneisbased onTLS.Itimplementstheabstract channelbyestablishing aTLSchannelbasedonsharedsecrets.TheTLSchannelin turnprovidestheserver’strustintoprecedenceofmessage receiptviasendingofmessagesperformedbytherespective client,againundercertainassumptions.TheTLSpatternuses theserver’spublicandprivatekeysforRSAencryptionand decryption(whichispart ofthepattern itselfanddoesnot useafurtherRSApattern)andanadditionalpatternsuchas DRBGforrandomnumbergenerationthatmustsatisfy spe-cificproperties.Aclientandaserverestablisha communica-tionchannelbyexchangingthreerandomnumbers(two gen-eratedbytheclientandonegeneratedbytheserver)and gen-eratingasetofdifferentsessionkeysbasedontheserandom numbers.Becausetheclient’ssecondrandomnumberissent totheserverencryptedwiththeserver’spublicRSAkey,this randomnumber,ifgeneratedconfidentially,stays confiden-tial,andhence allsession keysareconfidential,thus estab-lishinganauthenticandconfidentialchannelforclientand server.
Forinstance,whenusingTLSasamechanismrelatedto theapplicationdomaintorefinethesecurecommunication
patternatDSPM,wemanagethefollowingartifacts.The ex-ternalinterfacesaredefinedasarefinementoftheDIPM ex-ternalinterfaces.Inadditiontotherefinementoftheconcepts usedatDIPM,theprocessinvolvesthedefinitionoftechnical interfaces.Thesetwoactivitiesarecomplementaryandcan bemutuallyreinforcingwhenundertakensimultaneously.For instance,theestablishmentofachannelusingtheTLS mech-anismisarefinementoftheDIPMactionestablCh(P,ch(P,Q)): We add the random numbers generated byPand Qusing the corresponding technicalinterfaces (genRnd(P, Q)),which resultsintoestablCh(P,ch(P,rndP ,preMSP ,Q,rndQ )).Asubsetof thefunctionsprovidedbytheexternalinterfacesis:
• establCh(P,ch(P,rndP ,preMSP ,Q,rndQ )):Pestablishesa chan-nelch(...)withQ,
• send(P,ch(P,rndP ,preMSP ,Q,rndQ ),m,mac(preMSP ,...,m)):P sendsmandthecorrespondingMACtoQonthechannel ch(...),
• recv(P,ch(P,rndP ,preMSP ,Q,rndQ ),m,mac(preMSP ,...,m)): P
receivesmandthecorrespondingMACfromQonthe chan-nelch(...),
• closeCh(P,ch(P,rndP ,preMSP ,Q,rndQ )):Pclosesthechannel ch(...)sharedwithQ.
withP,Qasdefinedabove,rndP andpreMSP denotingarandom numberandthepremastersecret,respectively,generatedby P,mdenotingamessageandmac(preMSP ,...,m)themessage
authenticationcodegeneratedusingthepremastersecret. Thetechnicalinterfacesaredefinedasasetoffunctions relatedtotheuseofTLStorefinethesecurecommunication pattern.Asubsetofthefunctionsprovidedbytheinternal in-terfacesis
• genRnd(P,rndP ):PgeneratesarandomnumberrndP , • getCert(P,cert):Phasaccesstoitscertificate, • getKey(P,PuKCA ):PhasaccesstotheCAspublickey, • verifyCert(P,PuKCA ,cert):Pverifiesthecertificatecert, • genMac(P,ch(P,rndP ,preMSP ,Q,rndQ ),m,mac(preMSP ,...,m)):
Pgenerates the message authenticationcode (MAC) for a message using its own TLS shared secret for MAC generation
AttheDSPMlevel,wedefineseveralconcretesecurity prop-erties,including“authenticityofsendingandreceivingforthe server.” OtherpropertiesrelatedtotheusageofTLSmayalso bedefined,suchas“confidentialityofthesessionkey.”
4.5. Step5:Adaptationforaspecificdomaindevelopment environment
Thefinalsteps(5and6)areperformedtosupportthe devel-opmentofaspecificsystem.Step5identifiesappropriate pat-ternsandcreatestailoredversionsthatrepresentmodel con-ceptsinthedomainofinterestandthatcanbeadaptedtoboth thesystemdevelopmentprocessandthedevelopment envi-ronment.Theselectionofapatternisprimarilythechoiceof thedeveloper.Therearevariousconsiderationsthatmay nar-rowandsimplifythischoice.Thefirstisthepurposeofthe patternapplication.Althoughthispurposecannotbe gener-ally formalized,certain patterns addressrequirements that
aredefinedbydomainstandards(e.g.,security).If these re-quirementsarestoredinamodellibraryandreferencedin thedefinitionsofthepatterns,thentheselectionofpatterns couldbedrivenbytheselectionof(domain)requirements.The secondconsiderationisthatpatternscanbeclassifiedwith re-specttoseveralproperties,oneofwhichisthestageofthe en-gineeringprocesslifecyclediscussedinSection4.3-apattern mayberelevanttothesystem,itsarchitecture,ortoaspects ofitsdesignorimplementation.Thus,itmustbepossibleto filteravailablemodelingartifactsbasedonthisclassification. In the context ofour work,the target domain develop-mentenvironmentisIBMRationalRhapsody,andthe descrip-tionsofthemodeltransformationsarebasedontheQVT op-erationallanguage.Therefore,thedesignofagivenpattern canberegarded asasinglepackagethatcontains one sub-packageperlifecyclephaseoftheengineeringprocess;each ofthesephasescancontaindesignmodulesandadditional sub-packagesassociatedwithparticularspecializationsand refinements.Thus,importedpatternsarestoredinsidea ded-icatedpackagethatfacilitatessearchingwithinthepackage treeofeachdesign.Moreover,tofosterreuse,thepattern ar-tifactsrelatedtothatphaseareinstantiatedfromthe reposi-torytothevehicularmodelingtoolasareferencepackage.The rightpartofFig.9 showsapatterndesigndeployedin pack-agesusingtheIBMRationalRhapsodytool.Eachpattern de-signpackagegenerallycontainsthefollowingitems:
• Anyinformationthatisrequiredbytheend-userpattern integrator,e.g.,aUMLclassorSysMLblock,withinterfaces thatenabletheinterconnectionofpatternswithagiven systemdesign.
• Additionaldetailedinformationofinterest,e.g.,a “struc-ture” packagethat contains thestatic internalstructure (e.g.,classdiagram) and thedynamicstructure (e.g., se-quencediagram).
4.6. Step6:Reuseforaspecificsystemdevelopment
Thissectionfocusesontheuseofpatternsinasoftware de-velopmentprocess.Theintegrationofapatterninvolvesthe applicationofasolutionprovidedbythatpatterninan exist-ingapplicationarchitecturetotakeadvantageofitsbenefits. Wecannotsimplycopysuchasolutionintothearchitecture underdevelopment.Instead,wemustaccountforthe inter-playbetweenelementsthatpreviouslyexistintheapplication andtheelementsofthepattern.
Toaddressthisissue,aspecificactivitycalledIntegration, whichwaspreviouslystudiedinHamidetal.(2012),isused herein.Inthecontextofourexample,byexecutinga tailor-ingactivity,the patternisexported inanXMI file.Then,it mustbeimportedfromRhapsody.Asshownintherightpart ofFig.9,oncethepatternisimportedinRhapsodyasa pack-age,aprojecttreeisgeneratedanditsartifactsareavailablein theproject.Therefore,ineachphase,thesystemdeveloper ex-ecutesthesearch/selecttaskontherepositorytotailor appro-priatepatternsforthemodelingenvironmentusingthe iden-tificationandthetailoringprocessesdescribedinSection4.5. The developer then integrates them into the application models following an incremental process. In the software
architecturephase,ourprocess flowcanbesummarizedby thefollowingsteps:
1. Thesoftwarearchitectsearchesfordifferent specializa-tions (at the softwarearchitecture-definitionlevel) of thepatternstocomplementthedesign.
2. The software architectselects the appropriate set of identifiedpatterns.
3. Thesoftwarearchitectimportsthe software architec-turedesignperspectiveofeachpatternintothe vehic-ularmodeling environment(Rhapsody)asareference package.Theapplication developer isresponsible for linkingthepattern interfacestointegrate thepattern atthatspecificlevel.
4. Thesoftwarearchitectintegratesthepattern intothe existingsoftwarearchitecturedesigndiagrams. Moreover,inourworkweconsiderthedefinitionof guide-linestocorrectlyusesecuritypatterns.Atsecurityapplication design-time,formalmodelingofpatternscanprovesomeof thepropertiesofapatternsolution.Itmustbeensuredthat theassumptionsusedtoprovethecorrectnessofthepattern areindeedsatisfiedbytheparticularenvironmentofthe ap-plication,followingtheunifiedmodelingand formaldesign framework forpatterndefinition and verificationprocesses proposed inHamidetal.(2016).Storedinarepository, vali-datedsecuritypatternsarethenmadeavailablefor integra-tioninto anMDEprocesstodevelopsecureapplicationsfor variousdomains.Beyondthis,westoreintherepository asso-ciatedverificationartifacts,i.e.,propertiesandassumptions.
Whenusingthepattern,anapplicationdeveloperwillbe concernedwiththesecurityrequirementsexpressedinterms oftheexternalinterface,i.e.,interms ofthe functioncalls usedbytheapplication.Thus,anyformalproofneedstorefer tothesefunctioncalls.Alternately,thesolutiondescribedina respectiveDSPMpatternmustbemodeledintermsofrefined functioncalls.Intuitively,weproposehandlingthe assump-tions thattheproofisbasedonasasetofconstraintsthat needtobesatisfiedinorderforthepatternandthesolutionit specifiestoprovidetheprovenpatternpropertiesintermsof itsinterfaces.Inotherwords,weexecutethedifferentsteps oftheproofandtherelatedassumptionsasrequirementson theexternalandtechnicalinterfaces.Thisisthebasisofthe correctintegrationofpatterns
Forexample,whenprovingtheauthenticitypropertythe TLSHandshake(Hamidetal.,2016),weusedthefollowing as-sumptions:
• Ass1.Theclientdoesnotencryptthepremastersecretwith twodifferentpublickeys(itmightencryptittwiceusing thesamekey).
• Ass2.Thereceiver applicationentity mustnot accepta messageafterhavingclosedtherespectivechannel. • Ass3.Thesharedsecretsmustbedeployedinsuchaway
thattheyare onlyknowntothesenderandthereceiver applicationentities.
• Ass4.Thereceiver willnotuse theshared secretofthe sendertocomputeHMACs.
• Ass5. The random number generator produces unpre-dictablerandomnumbers.
Wenowintroducesomeconstraintsderivedfromtheses assumptionsthattheapplicationdeveloperneedstoverifyto ensurethatthepatternusedindeedprovidestherequired au-thenticityproperty:
• Implementation of sender and receiver (i.e. client and server)applicationentities.Thesenderapplicationentity mustbeimplementedadheringtoassumptionAss.1.The receiverapplicationentitymustbeimplementedin com-pliancewithassumptionAss.2.
• KeyHandling.TheHMACalgorithmworkswithshared se-cretsdeployedaccordingtoAss.3.Further,itmustbe en-suredthatthereceiversatisfiesAss.4.Thisalsomeansthat thesamesharedsecretmustnotbeusedforbi-directional transmissions.
• Randomnumbergeneration.Thesenderapplicationentity mustensurethatitusesarandomnumberasbasisforthe premastersecretandthattherandomnumbergenerator adheretoAss.5.
5.
Tool
support
Inthissection,weproposeanMDEtoolchaintosupportthe proposedapproachandtoassistthedevelopersofmodel-and pattern-basedsecuresoftwaresystems.Asdiscussedbelow, theproposedtoolchainisdesignedtosupporttheproposed metamodels;hence,thetoolchainandtheremainderofthe activitiesinvolvedintheapproachmaybedevelopedin par-allel.Theappropriatetoolsforsupportingourapproachmust fulfillthefollowingkeyrequirements:
• EnablethecreationoftheUMLclassdiagramsusedto de-scribethepatternmetamodelinourapproach.
• Enablethecreationofaconcretesyntax.
• Supporttheimplementationofarepositorytostore pat-ternmodelsandtherelatedmodellibrariesfor classifica-tionandrelationships.
• Enable the creation of pattern models and the related modellibrariesandthepublicationoftheresultsintothe repository.
• Supporttheadministrationandtheinternalmanagement oftherepository.
• Enablethe creationofvisualizationsoftherepositoryto facilitateitsaccess.
• Enablethecreationofapplicationmodels.
• Enabletransformationsofthemodelsfromtherepository formatintothatofthetargetmodelingenvironment. • Enabletheintegrationofapplicationmodelsandimported
patterns.
• Supportapplication-specificcodegeneration.
To satisfythe above requirements,we develop an MDE toolchainontopofthecurrentversionofSemcomdt7 (SEMCO model development tools) to support all the steps in our approach.
Fig.8– Designingapattern.
The repository is implemented using the Eclipse CDO8 framework. Weuse the same process flows for the design andimplementationofareusemodelrepositorysuchasthe onedescribedinHamid(2017).Weapplymetamodeling tech-niquesthatenablethespecificationoftherepositorystructure andinterfacestocontentintheformofmodelingartifactsand modeltransformationtechniquesforthepurposeof genera-tion.Topopulatetherepository,weconstructapatterndesign tool(Arabion)tobeusedbyapattern designer.Arabion in-teractswiththerepositoryforpublicationpurposes.The pat-terndesignenvironmentispresentedinFig.8.Adesignpalette isshownontheright,atreeviewoftheprojectisshownon theleft,andthemaindesignenvironmentispresentedinthe middle.Furthermore,Arabionincludesmechanismsfor veri-fyingtheconformityofthepatternwiththeSEPMmetamodel andforpublishingtheresultstotherepository.
Rhapsodyisusedasthedomain-specificdesignsoftware tooltodesign(andimplement)thesystemusingUML/SysML modelinglanguages.Forexample,itcanbeusedtodesign sys-temsbasedonpackages,whereonepackagemightcontain designdiagramsand/oradditionalpackages.Basedonthis ap-proach,thedesignofagivenpatterncanbeconsidereda sin-glepackagethatcontains onesub-package persafety engi-neeringprocesslifecyclephase;eachofthesephasesmight containdesignmodulesandadditionalsub-packages associ-atedwithspecializationsandrefinements.Thus,theaccess toolprovidestheoptiontoexportpatternsinaformatthatcan beimportedbytheRhapsodytools.Therefore,acustomized accesstool,suchastheoneshowninFig.9,isdevelopedto constructconnectionsbetweenthemetrologydevelopment
8http://www.eclipse.org/cdo/.
environmentandtherepositoryofpatterns.Theaccesstool providesasetoffunctionstoassistinthesearch,selection andsortingofpatterns:
Rhapsodyisusedasthedomain-specificdesignsoftware tooltodesign(andimplement)thesystemusingUML/SysML modelinglanguages.Forexample,Rhapsodycanbeusedto designsystemsbasedonpackages,whereonepackagemight containdesigndiagramsand/oradditionalpackages.Basedon thisapproach,thedesignofagivenpatterncanbeconsidered asasinglepackagethatcontainsonesubpackage per secu-rityengineeringprocesslifecyclephase;eachofthesephases mightcontaindesignmodulesandadditionalsubpackages as-sociatedwithspecializationsandrefinements.Thus,the ac-cesstoolprovidestheoptiontoexportpatternsinaformat thatcanbeimportedbytheRhapsodytools.Therefore,a cus-tomizedaccesstool,suchastheoneshowninFig.9,is de-velopedtoconstructconnectionsbetweenthemetrology de-velopmentenvironmentandtherepositoryofpatterns.The accesstoolprovidesasetoffunctionstoassistinthesearch, selectionandsortingofpatterns:
1. Keywordbasedsearchforpatterns:Feedbackfrom en-gineers ofcompanies witha line ofbusiness in the metrology domain revealed a clear preference for a keyword-basedsearchwhenqueryingtherepositoryfor patterns.
2. Contextbasedsearchforpatterns:Insomecases, en-gineersneedtofindspecializationsorlinkedpatterns for the solution provided by an already instantiated pattern.
3. Pattern browser for manual pattern search: The ac-cesstoolprovidesadedicatedpatternbrowsertabfor
Fig.9– Metrologyaccesstool.
manuallybrowsingthepatternrepositoryfornew pat-ternsorforobtaininganoverviewofthesolutions avail-able.
4. Historyofalready exportedandinstantiated patterns (projectrelated):Toensureconsistency,itisimportant toknowwhichpatternshavealreadybeeninstantiated andintegratedduringthedifferentphasesofthe devel-opmentprocess.
For example,asshownintheleft partofFig.9,thetool assists in selecting appropriate patterns through key word searches and lifecycle stage searches. Theresults are dis-playedinthe searchresulttreeassystem,architecture, de-signandimplementationpatterns.Whenapatternisselected, theaccesstoolinstantiatesthepatterninthedomain-specific tool,asshownintherightpartofFig.9.Becausethistaskis performedduringproductdevelopment,theselectedpattern mustbecompliantwiththecurrentphaseofthedomain pro-cessandwiththeusertools.Byaccessingtherepository,we introducefeaturesbasedonmodeltransformationtechniques toadaptthepatternmodeltothetargetdevelopment environ-ment.Inourwork,thetargetformatisasubsetofUMLthat canbeimportedusingRhapsodyandthemodel transforma-tions,whichwasdevelopedusingtheEclipseimplementation ofQVTO.
AsshowninFig.9,thesystemarchitecttypesinaquery andsearchesthereadouttofindthemostsuitabledesign pat-terninstantiationforthecorrespondingphase.Thesystem ar-chitectanalyzesallpossibleoptions,selects“SRR_Metrology” andclicksExport.ByclickingtheExportbutton,thepatternis exportedasaRhapsody-referencedpackagetotheselected di-rectory.OncethepatternisimportedintoRhapsodyasa
pack-age,aprojecttreeisgenerated,anditsartifactsareavailable foruseintheproject.
6.
Evaluation
Inthissection,wefirst reportanindustrialcasestudy per-formedin the metrologydomain (Section 6.1),followed by a description ofa survey performedamong metrology do-mainexpertsto betterunderstandtheirperceptionsofour approach(Section 6.2).Thecasestudy enablesusto deter-minewhetherthepattern-basedapproachleadstoareduced numberortoasimplificationoftheengineeringprocesssteps, whereasthesurveyassistsinassessingwhetherdomain ex-perts agree regarding the benefit of adopting the pattern-basedapproachinarealindustrialcontext.
6.1. Casestudy
Weusesmartmetergatewaysystemstoexemplifythe pro-posedapproach.Asmartmetergateway(BSI,2014),isa sys-temcapableofconnectingtoseveralmetersfordifferent com-modities,such as electricity, gas,water or heat, and com-municatingwithhouseholdsandotherremoteentities,such asregulations.Itenablesadditionalservices,suchas accu-rate monthly bills and consumption informationregarding theactualtimeofuse.Smartmetersutilizeembedded sys-temsprovidingnetworkconnectivitytothebackend.Inthis scenario,communicatingdifferentinformation(e.g.,readouts, consumptiondata,parameters)withseveralentitiesraises ad-ditionalsecurityconcerns.Itisimportanttohaveauthentic informationabouttheenergyconsumedatdifferent measure-mentpoints.Hence,securityformeteringhasbecomean
