International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
![]()
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
1Student, Department of Software Engineering, Delhi Technological University, Delhi, India ***
Abstract - Most firms have a well oiled machine in place for developing, delivering, and maintaining functional software. However, when it comes to safeguarding that programme, not so much. Many development teams still see security as an impediment, something that creates roadblocks and compels them to redo work, preventing them from bringing innovative new things to market. However, unsecure software puts firms at risk. Cool new features will not protect you or your consumers if your product contains exploitable flaws that hackers can exploit. Instead, your team must incorporate security across the software development life cycle (SDLC) so that it facilitates, rather than hinders, the delivery of high quality, highly secure products to market. The aim of this paper is to evaluate these three security approaches by discussing their common process, strength, and limitations. Moreover, we discuss why these approaches do not effectively increase software security, and then we set the stage for a future framework to enhance and simplify the application of various security activities within the SDLC. The structure of this paper is as follows. First, briefly describing the Touchpoints, CLASP, and SDL approaches respectively, then the comparison between the three approaches based on a set of criteria. Followed by critical evaluation of the three approaches, I discuss activities that are shared among the approaches, then I illustrate the strength and the weakness for each one, comparing more models at the end.
Key Words: SecureSDLC
agileandCI/CD,whichincreasethespeedandfrequencyofdeployment.
Previously,organisationswouldonlyexecutesecurity relatedtasksaspartoftesting attheendoftheSDLC.Becauseof thislate gamestrategy,theywouldnotdiscoverfaults,weaknesses,andothervulnerabilitiesuntiltheyweresignificantly moreexpensiveandtime consumingtoaddress.Worse,theywouldnotdiscoveranysecurityflawsatall.
According to IBM's Systems Sciences Institute, fixing a fault discovered after implementation costs six times as much as fixing one discovered during design. Furthermore, according to IBM, the cost of resolving flaws discovered during the testingphasemightbe15timesthatoffixingthosediscoveredduringthedesignphase.
Soit's significantly better, not to mentionfaster andless expensive, toincorporate security testingthroughout theSDLC, rather than just at the end, to help uncover and mitigate vulnerabilities early on, effectively building security in. Architectureanalysisduringdesign, codereviewduring codingand build,andpenetrationtesting priorto releaseareall examplesofsecurityassuranceactivities.
ThefollowingaresomeofthemajorbenefitsofasecureSDLCapproach:
Becausesecurityisaconstantconcern,yourprogrammeismoresecure.
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
Securityconcernsareknowntoallstakeholders.
Designdefectsaredetectedearly,beforetheyarecodedintoreality.Yousavemoneybecauseofearlydefectdetectionand resolution.Youreduceyourorganization'soverallunderlyingbusinessrisks.
When software began to play more active roles in numerous businesses in the last century, softwaresecurity challenges arose.However,thesoftwaredevelopmentprocessdid notfollowa matureengineering approachanddidnotincludean explicitsecuritystep
Even though the software development process has embraced a systematic engineering method such as Software DevelopmentLifeCycle(SDLC),thenumberofsecurityvulnerabilitieshasincreasedovertime,particularlywiththebroad adoptionofnewapplicationssuchassocialnetworkplatforms.
Many studies have identified the root cause of the rise in security issues; one of the most prominent reasons is that security isnotconsideredatanyleveloftheSDLC.Researchershaveproposedsolutionstothis problemsincethe1980s and continue to do so now. Integrating security into each phase of the development process is one of the greatest recommendationsthathavegainedthemostattentionfromdiverseparties.Thisconcepthasbeenofferedbyresearchers forthepast30years.
Despite the fact that various security approaches have appeared to tackle security concerns and integrate security with SDLC for a long time,the number ofsecurity challenges continues togrow. Thesourceof risingsecurityconcerns is that software development firms continue to ignore security in their SDLC, owing to problems in implementing one of these methodologies,suchastimeandcost.
The following are the most commonly recommended techniques for integrating security with SDLC: the Open Web Application Security Project (OWASP) organization's Comprehensive Lightweight Application Security Process (CLASP), McGraw'sTouchpoints,andMicrosoft'sSecurityDevelopmentLifecycle(SDL).
McGraw proposed the Touchpoints approach as a collection of security measures to be used during the software development process. They consist of both harmful and positive acts. Destructive activities include attacks, exploits, and breaking software; these are referred to as black hat (offence) activities. Constructive activities include design, defence, evaluation, and functionality, and are referred to as white hat (defence) activities. Both sorts of activities (offensive and defensive)arerequired,andtheyinclude:
Since 2006, the OWASP organisation has promoted the CLASP strategy, describing it as a well organized and systematic approach for incorporating security issues into the early stages of the SDLC. It is a prescriptive strategy that includes paperworkandtoolstohelpinimplementation.Itisanactivitydrivenbyasetofprocessesthatareexplicitlyspecifiedas thebestpractisesforintegratingsecurityintoexistingornewSDLCs.TheCLASPwasbuiltbyOWASPtobeadaptableand
International
e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
simple to integrate into existing development processes. It is made up of three major parts: CLASP Views, CLASP Resources,andVulnerabilityUseCases.
The main characteristic that distinguishes the approach is its activities that are divided intoseparated subprocesses and assigntospecificprojectrole(projectmanager,securityauditor,developer,architect,tester,andothers).Also,itcontains alargevulnerabilitylexiconwhichisstructuredfrommanyperspectivesthathelpthedevelopmentteamineachphase.
SDL was created by Microsoft and is utilised internally inside the Windows Vista project. They defined it as a set of necessary security actions that must be carried out in a specified order. However, Microsoft has demonstrated that security activities carried out as part of a software development process achieve higher security objectives than actions carriedoutpiecemealoradhocbasedonpracticalexperience.
Microsoft SDL includes 16 actions, the majority of which include resources such as reference, training materials (presentations, films, or webcasts), templates or examples that can be downloaded, and tools that can be used to implementtheactivities.
2.Comparing Touchpoints, SDL and CLASP:
Each technique has a varied amount of activities; the Touchpoints approach has the fewest, with only seven. The CLASP includes24activities;thesecurityadvisormayremovesomeofthembasedontheirassessment.TheSDLincludes16core activitiesaswellasoptionalactivitiesthatcanbeusedincriticalapplicationstoboostsecurity.
Because activities are dependent, the selection process and order of execution are left open and flexible. CLASP and Touchpoints activities are distinct. The SDL, on the other hand, is dependent on events that are properly organised and staged.
Because it is heavyweight and rigid, it is assumed that the SDL is appropriate for large organisations. Touchpoints and CLASParesuitableforbothsmallandlargecompaniesduetotheirlightweightandadaptability.
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
There are two types of activities: constructive (defence) and destructive (attack) (offense). The Touchpoints encompass bothconstructiveanddestructiveactions;itincludes PenetrationTesting,whichisdestructive,andCodeReviews,which is constructive. The SDL and CLASP, ontheotherhand, only coverconstructivetasks such as security requirements, risk assessments,andcodereviews
Because there are a very limited number of developers with relevant security knowledge, educating or training a team priortothecommencement ofaprojectis ahighly important job.Thisactivityguarantees thatothersecurity operations arecompletedwithhighquality.TheSDLandCLASPmethodsvaluethisactivityhighly;itprovidesteammemberswitha security awareness programme to help them gain the necessary security knowledge . The SDL only gives the security awareness programme to developers, and it contains a means to assess the developers' security understanding after the programme.TheCLASPprovidesasecurityawarenessprogrammetotheentiredevelopmentteam,whichincludespeople withvariedjobs.ThemostsignificantdownsideoftheTouchpointstechniqueisthelackoftrainingactivity.
Adaptation, or the flexibility of the technique to be used in any software development process, is a critical requirement. BecauseMicrosoftcreateditfortheirinternaldevelopmentprocess,itisheavyweight,andtheiroperationsaredependant, theSDListhemostdifficulttomodifyinanySDLCandmaynotadapt.Touchpointsisthesimplestbecauseitislightweight and contains a few independent tasks. Furthermore, because the CLASP is a series of autonomous activities with rich resourcesthatlinktotheprojectresponsibilities,itissimpletoadaptinanySDLCprocess.
The SDL activities are divided into SDLC phases (education and awareness, project inception, analysis, design, implementation, testing and verication, and deployment and support). The CLASP activities are assigned to SDLC phases based onthe functionthat is inchargeof the activity. Theoperations ofthe Touchpoints areapplied tovarious software objects
The SDL testing type emphasises black box testing, whereas the CLASP emphasises white box testing. The Touchpoints techniqueemphasisesblackboxtestinginpenetrationtestingandwhiteboxtestinginrisk basedsecuritytests
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
Privacyisacriticalnotioninsecurity.TheSDLapproachistheonlyonewithaspecificactivity(SecurityandPrivacyRisk Assessment)linkedtoprivacy,whilsttheCLASPandTouchpointsdonothaveany[12].
Itisavitalactivityforcriticalsoftwarethatcreatessecuritypoliciesforanorganisation,process,andproduct.CLASPisthe only model that offers a separate activity for security policy (Identify global security policy). Because the SDL and Touchpoints do not have isolated activities to create a security policy, the security policy may be set in the security requirements
Nonetheless,Idiscoveredthatthenotionsofthefollowingactionsaresharedbythethreesystems.
SecurityRequirementsactivityispresentinallthreemodels,butindifferentways;itisanimportantactivitythatisused inotherSDLCphases,suchasthedesignphasetoexaminesecurityrisksandthetestingphasetocheckspecifiedsecurity requirements. It could refer to access control, privacy, law enforcement, abuse cases, anti requirements, identifying resourcesandtrustboundaries,andspecifyingtheoperatingenvironment.
RiskAnalysis(ThreatModeling)isadesignphaseactivitythatidentifiesthemostimportantvulnerabilitiesandthemost difficult defects. Unfortunately, because of some difficulties, only a few people do it correctly, i.e. most people do not understandit,donotknowhowtodoit,areunabletodoit,donotknowifatoolcanbeused,donotknowwhichtoolis useful,andtheyfocussolelyonthearchitectdesignandeliminateorignorethebusinessdesign.
Examples of design problems that lead to a high security risk and should be discovered in the Risk Analysis (Threat Modeling)activityarethefollowing:errorhandling,sharingobjects,incorrectormissingaccesscontrolmechanisms,lack ofauditingorlogging,andtimeofchecktotimeofuse(TOCTOU),raceconditions,ordering,andtimingerrorsespeciallyin multithreadedsystems.
In the name and details, Static Source Code Review is a shared activity between the three techniques (explicitly). Most software development firms use it exclusively since it detects the most frequent vulnerabilities without the need for professionalsandintheshortestamountoftimeandmoney.
Theother ways,which are CreateQualityGates/Bug Bars,Fuzz Testing,Incident ResponsePlan,andReleaseArchive,do notincludeimportantsoftware.Ontheotherside,itisintendedforMicrosoft,whichmakesitheavyweightanddifficultto implementinmanySDLCs.Italsodoesnotincludeanyharmfulactionoroperationsintheoperatingphase.
Governance, design, implementation, verification, and operations are the five business functions of SAMM. Each function hasthreesecurityprocedures,eachofwhichhasthreestagesofmaturity.
TheBuilding SecurityInMaturity Model (BSIMM) assists enterprises intheplanning, implementation, and measurement ofsoftwaresecurityprojects.ABSIMMassessmentprovidesanobjective,data drivenreviewonwhichleaderswishingto improvetheirsecurityposturescanbaseresource,time,budget,andprioritydecisions.TheyearlyBSIMMreportprovides analysisbasedonhundredsofassessmentsfrommanyindustryverticalsandactsasasignificantbenchmarkforsecurity professionals, academic curricula, and analysts. BSIMM also has a vibrant community where members discuss best practisesandspecialcontent,aswellascooperatewithsecuritypeers.
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
NIST's SSDF, also known as NIST 800 218, provides a foundational set of secure development principles that can be appliedacrosstheSoftwareDevelopmentLifecycle(SDLC).SSDFdiffersfromBSIMMandSAMMinthatitdoesnotspecify its own unique techniques, but instead draws from current secure software development guidance and sources such as BSIMM,SAMM,OWASPASVS,andexistingNISTguidelines,amongothers.
SSDF, like BSIMM, specifies safe software development techniques but does not specify how to implement them. This enables a dynamic and adaptable framework focused on secure software results rather than precise implementation specifics. SSDF also uses plain English, making it a useful tool for addressing secure development methods across communitiesofbusinessowners/executives,softwaremakers,andusers.
The ASVS, which stands for Application Security Verification Standard, was created to standardise industry terminology for assessing the security of applications/products. Once everyone is on the same page with the terminology, organisations can buy software with confidence that it is compliant with a pre defined security level; and it can be confidentthatitiscompliantwiththislevelbecauseitwasverifiedaccordingtocommon/standardrequirements,andif thisisperformedbyanexternalvendor,becausethisisawell definedstandard.
TheASVSisgenerallyanewinitiativebecausemostorganisationshavenotyetbegunimplementingit,butitcanbeagreat businessdriverforthembecauseitaimstosetahighersecuritylevelpan organizationally,whichwillhelporganisations communicateinauniformmanner(acrossdepartmentsanddivisions)andwithsimilarexternalbodies.
Furthermore, theASVSmandatesSecurityCodeReview,rangingfromtotallyautomated(basiclevel) toacombinationof automated and manual, to assist assure software security an essential issue that Comsec has been addressing with CODEFENDTM.
From our initial study, the SAMM appears to be a good model that may assist firms in integrating security into their development lifecycle,anditisverycomparabletotheComsecin housedesigned model.Thisisespeciallyimportantfor SMEsorbusinessesthatlackthematuritytoimplementalarge scaleandcomprehensivemodelliketheMS SDL.
OnesignificantdistinctionbetweenSAMMandBSIMMisthatSAMMisaprescriptivemodelwhereasBSIMMisdescriptive. As a result, SAMM specifies concrete activities and procedures that businesses can implement to improve software assurance.SAMMisanopen sourceframework,whichmeansitisnotproprietaryandcanbeimprovedbythecommunity.
The OWASP Application Security Verification Standard (ASVS) Project provides a foundation for verifying technical securitycontrolsinonlineapplications,aswellasalistofrequirementsforsecuredevelopment.
TheOWASPApplicationSecurityVerificationStandard(ASVS)Project'smajorgoalistostandardisetherangeofcoverage and level of rigour available in the market when performing Web application security verification using a commercially workableopenstandard.Thestandardestablishesafoundationforevaluatingapplicationtechnicalsecuritymeasures,as well as any other technical security controls in the environment, that are used to protect against vulnerabilities such as Cross Site Scripting (XSS) and SQL injection. This standard can be used to establish trust in the security of Web applications.Therequirementswerecreatedwiththefollowinggoalsinmind:
• Useasametric Provideapplicationdevelopersandapplicationownerswithayardstickwithwhichtoassessthe degreeoftrustthatcanbeplacedintheirWebapplications,
Use as guidance Provide guidance to security control developers as to what to build into security controls in ordertosatisfyapplicationsecurityrequirements,and
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
• Use during procurement Provide a basis for specifying application security verification requirements in contracts.
Both the ASVS and SAMM standards are regarded somewhat less commonly integrated activities in the information securitysectorthathavenowbeendesignatedasOWASPprojects.
A common origin:
The beginnings of BSIMM (Building Security In Maturity Model) and SAMM (Software Assurance Maturity Model) are similar,datingbackto2008 2009.I'mregularlyaskedwhatsimilaritiesanddifferencesexistbetweenthetwomodels,soI created this comparison to assist organisations in determining which of these two models may be a better fit for their purposes.
Type of model:
BSIMM is a descriptive model:
TheBSIMMisessentiallyasoftwaresecuritybenchmark.Theeasiestapproachtoapplyitistocompareandcontrastyour owninitiativewithstatisticsfromotherfirms.TheBSIMMalsoservesasanSSIroadmap.Youcanestablishyourowngoals andobjectives,thenusetheBSIMMtoassesswhetheradditionalactivitiesareappropriateforyou.
TheBSIMM'sgoalistomeasuretheactivitiesofvarioustypesofSSIsacrossmultiplebusinesses.
Because these initiatives employ different approaches and language, the BSIMM requires a framework that allows us to uniformly characterise any effort. Our software security framework (SSF) and activity descriptions provide a common vocabularyforexplainingthekeyelementsofanSSI,allowingustocompareinitiativesthatusedifferentterms,operateat different scales, exist in different parts of the organisational chart, operate in different vertical markets, or produce differentworkproducts.
The BSIMM's only objective as a descriptive model is to observe and report. We like to report that we went to a neighbourhood to investigate what was going on and discovered that "there are robot vacuum cleaners in X of the Y houses we went to." The BSIMM does not state that "all houses must have robot vacuum cleaners," that "robot vacuum cleaners are the only acceptable type of vacuumcleaners," that"vacuum cleaners mustbe used every day," or any other valuejudgments.Weprovidestraightforwardobservations.
SAMM is a prescriptive model:
SAMMisa prescriptivemodel,anopenframeworkthatiseasytoimplement, well defined,andmeasurable.Thesolution details are simple enough for non security persons to understand. It assists firms in analysing their present software security practises, developing a security programme in defined iterations, demonstrating progressive improvements in securepractises,anddefiningandmeasuringsecurity relatedactivities.
SAMM was designed with flexibility in mind, so that it may be customised and adopted by small, medium, and big enterprisesutilisinganydevelopmentmethodology.Itenablesyoutoidentifywhereyourorganisationstandsintermsof softwareassuranceandwhatstepsshouldbetakentoadvancetothenextlevelofmaturity.
SAMM does not require that all organisations achieve the highest level of maturity in every category. Each business can decide the appropriate target maturity level for each Security Practice and adjust the available templates to their own needs.
The significance of OWASP SAMM is in giving a mechanism for your business to understand where it is on its road to software assurance and what is advised to proceed to the next level of maturity. OWASP SAMM does not require all businesses to attain maturity level 3 in all categories. Indeed, you decide the target maturity level for each Security Practicethatisbestsuitedtoyourorganization'srequirements.
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
Maturity levels: "TheBSIMMisnotastandardmaturitymodelinwhich asetoftasksisrepeatedatseveraldepthandbreadthlevels do somethingatlevel1,domoreatlevel2,dobetteratlevel3,andsoon."Instead,theBSIMMismadeupofasetofdistinct activities,withactivitylevelsutilisedsimplytodifferentiatetherelativefrequency withwhichtheactivitiesareobserved inorganisations.Level1denotesoftenobservedactivities,level2denoteslessfrequentlyobservedactivities,andlevel3 denotesinfrequentlyobservedactivities." Each
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056
Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
• EnvironmentManagement
• OperationalManagement
Activities 7 12 observed and related activities per practicearea 2 streams of activities per security practice that complimentandbuildoneachother
Result comparison
BSIMM 11 has 130 contributing organizations that were interviewed and contributedtotheircomparisondataset
working on the SAMM Benchmark project to collect data from implementing and assessing organizationsforcomparison
Frequency of updates annual every2 3years
Assessment BSIMM is proprietary to Synopsys. For an assessment you should reach out to them forcostandlogistics.
References:
SAMM is an open model and can be self assessed or conducted by a number of different consulting organizationsandindividuals.
• [1]F.G.TompkinsandR.S. Rice, “Integratingsecurity activities intothesoftwaredevelopment lifecycleandthe softwarequalityassuranceprocess,”Computers&Security,vol.5,no.3,pp.218 242,1986.
• [2]R. Baskerville, “Information systems security design methods: implications for information systems development,”ACMComputingSurveys,vol.25,no.4,pp.375 414,Jan.1993.
• [3] M.SiponenandR.Baskerville, “ANewParadigmforAddingSecurityintoisDevelopmentMethods,”Advances inInformationSecurityManagement&SmallSystemsSecurity,pp.99 111,2001.
• [4] J.Danahy, “The ‘phasing in ’ofsecurity governance inthe SDLC,”Network Security, vol.2008, no.12,pp.15 17,2008.
• [5] A. U. H. Yasar, D. Preuveneers, Y. Berbers, and G. Bhatti, “Best practices for software security: An overview,” 2008IEEEInternationalMultitopicConference,2008.
• [6] G. Raj, D. Singh, and A. Bansal, “Analysis for security implementation in SDLC,” 2014 5th International Conference ConfluenceTheNextGenerationInformationTechnologySummit(Confluence),2014.
• [7] D.Geer, “AreCompaniesActuallyUsingSecureDevelopmentLifeCycles?,”Computer,vol.43,no.6,pp.12 16, 2010.
• [8] “OWASP CLASP Project,” OWASP. [Online]. Available: https://www.owasp.org/index.php/Category:OWASP_CLASP_Project.[Accessed:24 Oct 2016].
• [9] G.MacGraw,Softwaresecurity:buildingsecurityin.Addison Wesley,2006.
• [10] “Microsoft Security Development Lifecycle,” Microsoft. [Online]. Available: https://www.microsoft.com/en us/sdl.[Accessed:24 Oct 2016].
International Research Journal of Engineering and Technology (IRJET) e ISSN:2395 0056 Volume: 09 Issue: 06 | June 2022 www.irjet.net p ISSN:2395 0072
• [11] J. Gregoire, K. Buyens, B. D. Win, R. Scandariato, and W. Joosen, “On the Secure Software Development Process: CLASPandSDL Compared,” ThirdInternational Workshopon SoftwareEngineering for Secure Systems (SESS'07:ICSEWorkshops2007),2007.
• [12] N. Sankhwar, A. Tewari, and V. Singh, “SDL, CLASP and TOUCHPOINTS: A Comparison and Alignment of CLASP with Waterfall Model”. International Journal of Computer and Communication System Engineering (IJCCSE),vol.2,no.3,pp.365 376,2015.
• [13] I.E.RhaffariandO.Roudies, “BenchmarkingSDLandCLASPlifecycle,”20149thInternationalConferenceon IntelligentSystems:TheoriesandApplications(SITA 14),2014.
• [14] J.Alqatawna,A.Madain,A.M.Al Zoubi,andR.Al Sayyed, “OnlineSocialNetworksSecurity:Threats,Attacks, andFutureDirections,” in Social Media Shaping e Publishingand Academia, N.Taha, R.Al Sayyed, J. Alqatawna, andA.Rodan,Eds.Cham:SpringerInternationalPublishing,2017,pp.121 132.
• [15] J. Alqatawna, “The Challenge of Implementing Information Security Standards in Small and Medium e Business Enterprises“ , Journal of Software Engineering and Applications, vol. 07, no. 10, pp. 883 890, 2014.