measures ssdlc
Lær om forskellige sikkerhedsforanstaltninger, der skal implementeres for en sikker SDLC eller SSDLC:
Da teknologien vokser hurtigt, er de sikkerhedsrelaterede trusler om hacking og stjæling af sikrede data også steget tilsvarende. Så ingen tvivl om, at teknologivækst skaber udfordringer for softwareproducenterne for at sikre, at deres software er stærk og robust mod sikkerhedstrusler og sårbarheder.
Et softwareprodukt kan ikke frigives, selvom det fungerer perfekt til den tilsigtede funktionalitet, medmindre det viser sig at være meget sikkert og opfylder de specificerede og regulerede sikkerheds- og privatlivsstandarder, især i sektorer som forsvar, økonomi og sundhedspleje, der involverer personlige og økonomiske data .
Man har ikke råd til at have en sikkerhedsdefekt i produktet, når det implementeres, det være sig høj eller middel sværhedsgrad. Derfor er det meget vigtigt at beskytte softwaren og dataene mod enhver form for angreb, ondsindede trusler, sårbarheder og sikre softwarets troværdighed over for slutbrugeren.
I modsætning til vores traditionelle softwareudvikling er testning i sidste fase, efter at hele softwaren er udviklet, ikke mere effektiv. Med implementeringen af Agile-, DevOps- og ShiftLeft-konceptet er det vigtigt at udføre test så tidligt som i hver fase af applikationens livscyklus.
Når det er sagt, kan sikkerhedens sikkerhed ikke bygges eller endda testes i sidste fase, og det skal derfor bygges i hver fase for at sikre den samlede sikkerhed for softwaren.
Hvad du vil lære:
Sikkerhedsforanstaltninger til SSDLC
Nedenfor er de forskellige måder til sikkerhedsrelaterede foranstaltninger, der kan implementeres på tværs af softwareudviklings livscyklus for at sikre Secure SDLC eller SSDLC, og så meget som muligt får manglerne ikke videre til næste fase.
De forskellige sikkerhedsanalyser og vurderinger, hvor sikkerhed skal bygges i SDLC-faser er.
- Kravsfase
- Planlægningsfase
- Arkitektur og designfase: Sikkerhedsrisikovurdering baseret på designet.
- Udviklingsfase: Secure Code Analysis, en statisk analyse af koden for sikkerhed.
- Implementeringsfase: Dynamisk kodeanalyse, en applikationssikkerhedstest.
- Testning - Fase før implementering: Penetrationstest og sårbarhedsanalyse.
# 1) Kravsfase
- For primært for at sikre, at nødvendige sikkerhedsforanstaltninger er indbygget i softwaren, Sikkerhedsrelaterede specifikke krav skal fanges tydeligt i kravfasen med tilstrækkelige detaljer og forventede resultater.
- Mens man identificerer de typiske brugssager og forretningsscenarier, er der et klart sæt af Sikkerhedsrelaterede brugssager og scenarier til verifikationsformål skal der identificeres for at indfange sikkerhedsfunktionerne og designe sikkerhedstestscenarier.
Nedenfor er et par eksempler på eksempler, der illustrerer de eksplicitte sikkerhedsrelaterede krav, der kan fanges.
Sec-Req-01: Systemet skal have godkendelsesforanstaltninger på alle gateways og indgangspunkter.
Sec-Req-02: Systemet kræves for at implementere godkendelse via en sikker login-skærm.
Sec-Req-03: PERSONLIGE DATA skal krypteres i hvile.
# 2) Planlægningsfase
På et højt niveau, men ikke kun begrænset til disse, skal følgende punkter tages hånd om i planlægningsfasen.
virtual reality gaming briller xbox 360
- En stærk, Dedikeret sikkerhedsteam , der fungerer uden for programteamets PMO (projektledelseskontor), bestående af Sikkerhedsofficer, sikkerhedsarkitekter, sikkerhedstestere der skal dannes for at udføre og styre alle programmets sikkerhedsrelaterede aktiviteter på en upartisk måde. For hver af disse roller defineres en klar RnR (roller og ansvarsområder) og RACI.
- Nogen eskaleringer, uklarheder relateret til sikkerhedsspørgsmål skal håndteres af PSO (Product Security Officer), så sikkerhedsteamet fungerer problemfrit og hjælper med at træffe de rigtige beslutninger.
- En robust Strategi for sikkerhedstest at specificere, hvordan de sikkerhedsrelaterede krav skal implementeres, hvordan, hvornår og hvad der skal testes, hvilke værktøjer der skal bruges på hvert trin, skal identificeres.
- Det er obligatorisk at involvere Kontaktpunkt for sikkerhed til alle tekniske / gennemgangsdiskussioner relateret til programmet, så sikkerhedsteamet er opmærksom på eventuelle ændringer, der sker i programmet.
# 3) Arkitektur og designfase
At være mere opmærksom på sikkerhedsaspekterne tidligt i designfasen skal hjælpe med at forhindre sikkerhedsrisici og reducere en betydelig indsats i designændringer senere i SDLC.
Mens det er muligt at designe softwaren og den infrastruktur, som softwaren hostes på, er alt muligt Implementeringer af sikkerhedsdesign skal være godt designet med inddragelse af sikkerhedsarkitekterne.
Enhver tvetydighed og konflikter mellem de funktionelle og ikke-funktionelle design- og arkitekturaspekter skal sorteres gennem brainstormingssessioner, der involverer de rigtige interessenter.
I løbet af denne fase, en detaljeret produktsikkerhedsvurdering, som også undertiden kaldes 'Statisk vurdering' skal udføres af sikkerhedsteamet af eksperter.
Vurdering af sikkerhedsrisici inkluderer en gennemgang af programmerne fra et sikkerhedsmæssigt synspunkt på det foreløbige design / arkitekturtrin for at identificere de sikkerhedsrelaterede fejl fra designperspektivet og dermed hæve produktet Sikkerhedsrisici til projektteamet for at adressere dem og undgå at komme ind i den næste fase.
Disse vurderinger udføres på baggrund af de organisatoriske / industrielle sikkerhedsretningslinjer, standarder og kontroller, der er beskrevet i disse dokumenter. For eksempel. UXW 00320, UXW 030017
Under produktsikkerhedsvurdering:
- Krav, funktioner, brugerhistorier og deres designdokumenter gennemgås på baggrund af detaljer, artefakter, der deles af projektteamet, For eksempel. Designdokumenter (HLDD og LLDD). Vurderingerne indebærer også drøftelser med de relevante projektmedlemmer i tilfælde af manglende dokumenter eller for at afklare, hvis der er tvivl.
- Huller identificeres, når programmets sikkerhedskrav kortlægges mod de fastsatte standarder og andre bedste praksis. Nogle gange udvikles også trusselmodeller baseret på de identificerede huller.
- Disse huller identificeres som potentielle sikkerhedsrisici, der også inkluderer antydning af mulige afbødninger til implementering, hæves og styres.
- Når disse afhjælpninger er implementeret af projektteamet, verificeres de til lukning via passende testcases designet af System Test-teamet.
- Risikostyringsmatrix, der giver sporbarhed, er parat til at spore disse risici. Godkendelse og afmelding med den resterende risiko vil blive taget af sikkerhedsarkitekten og PSO.
Typiske trusselmønstre, der identificeres i designfasen, er relateret til Input Validation, Audit / Log Management, Configurations og encryptions. Risikoidentifikationen inkluderer angreb af sårbarheder som svage adgangskoder, Simple Brute Force Attacks osv.,
Typiske anmeldelser inkluderer risici i forbindelse med adgang til personlige data, adgang til revisionsspor, sortliste-hvidlisteenheder, datarensning og sletningsaktivitet.
Eksempel på testscenarier inkluderer:
- Sårbarhed i bufferoverløb: For at sikre, at manuel fuzzing af parametre, bør det ikke være muligt at bremse serveren og tvinge serveren til ikke at svare (Denial of Service).
- Datasanitisering: For at sikre, at korrekt datasanitering sker for hver input og output, så angriberen ikke kan injicere og gemme det ondsindede indhold i systemet.
# 4) Udviklingsfase
Sikker kodeanalyse er en Vurdering af statisk kode - metode, der bruges til at vurdere Sikker kode af de forskellige funktioner i software ved hjælp af et automatiseret scanningsværktøj. Eksempel: Forstærke.
Denne analyse udføres på hver kode-check-in / build for at scanne den genererede kode for sikkerhedstrusler. Denne vurdering udføres generelt på et User Story-niveau.
- Fortify-scanninger via plugins skal installeres på udviklerens maskiner.
- Fortify skal integreres med build-skabelonen.
- Automatisk scanning udføres dagligt på alle builds.
- Scanningsresultatet analyseres af sikkerhedsteamet for falske positive.
- Mangler identificeret ved denne vurdering hæves og styres til lukning, så udsivning minimeres / nulstilles til det næste niveau.
Eksempel på testscenarier inkluderer:
- For at sikre, at følsomme data ikke sendes i almindelig tekst under datatransmission.
- For at sikre sikker datatransmission skal API'er, der vender udad, installeres på en HTTPS-kanal.
# 5) Implementeringsfase
Dynamisk kodeanalyse er intet andet end Application Security Testing, som også kaldes OWASP (Open Web Application Security Project) test. Sårbarhedsanalyse og penetrationstest (VAPT) skal udføres i implementerings- / testfasen.
Denne analyse vurderer binærfiler og nogle miljøkonfigurationer og styrker koden yderligere til sikkerhedskravene.
Som en del af denne analyse er Dynamisk adfærd eller funktionalitet af forskellige funktioner i programmerne analyseres for sikkerhedsrelaterede sårbarheder. Fastsatte brugssager og forretningsscenarier bruges også til at udføre dynamisk kodeanalyse.
Denne aktivitet udføres på Testopbygninger ved hjælp af forskellige sikkerhedsværktøjer med en automatisk og manuel tilgang.
- HP WebInspect, Burp Suite, ZAP og SOAP UI-værktøjer bruges generelt til at kontrollere sårbarheder mod standard sårbarhedsdatabaser ( Eksempel: OWASP Top 10 )
- Denne aktivitet er dog hovedsageligt automatiseret på grund af visse værktøjsbegrænsninger, og det kan være nødvendigt med noget manuelt arbejde for at triage falske positive.
- Dette gøres ideelt i et separat miljø (System Testing Environment), hvor softwaren klar til test implementeres.
- Sårbarheder skal hæves og lukkes med de foreslåede afbødninger.
Typiske trusselmønstre identificeret under denne analyse er relateret til Input validering, Broken Authentication & Session Management, Sensitive data exposure, XSS and Password Management.
Eksempel på testscenarier inkluderer,
hvad skal du bruge til fejlfinding af et live netværkskabel
- Adgangskodeadministration: For at sikre, at adgangskoderne ikke er gemt i almindelig tekst i konfigurationsfilerne eller hvor som helst i systemet.
- Systeminformationslækage: For at sikre, at systeminformationen ikke lækkes på noget tidspunkt, kan de oplysninger, der er afsløret af printStackTrace, hjælpe modstanderen fra en angrebsplan.
# 6) Testning - Forudinstallationsfase
Penetrationstest , Kort test af pen og Infra VAPT (sårbarhedsanalyse og penetrationstest) , er den fuldstændige holistiske test med fuld løsning og konfigurationer (inklusive netværk), der ideelt udføres i et præ-prod eller produktionslignende miljø.
Dette udføres hovedsageligt for at identificere DB-sårbarheder og server-sårbarheder sammen med andre sårbarheder. Dette er den sidste fase af sikkerhedstest, der ville blive gennemført. Derfor inkluderer dette også verifikation af tidligere rapporterede mangler og risici.
- Værktøjer som Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP, der er tilgængelige på markedet, bruges til at udføre pen-test.
- Scanning af webapplikationer ved hjælp af automatiserede værktøjer og udnyttelse til yderligere verifikation udføres under denne test. Test udføres for at simulere den virkelige angribers adfærd, og det kan derfor også omfatte et par negative tests.
- Sårbarhed i infrastruktur vurdering inkluderer scanning, analyse og sikkerhedskonfiguration gennemgang af infrastruktur (netværk, systemer og servere) for at identificere sårbarhederne og kontrollere modstandsdygtigheden over for de målrettede angreb.
- Dette udføres på et præproduktions- eller produktionslignende miljø, hvor den software, der er klar til implementering, testes og dermed simulerer realtidsmiljøet.
- Sårbarheder identificeres ved hjælp af både scannere og manuelle teknikker for at eliminere falske positive. Der vil også blive udført forretningsscenarier i realtid under manuel test.
- En endelig rapport om hele sikkerhedsanalysen, der udføres for hele programmet, vil blive produceret, der fremhæver status for eventuelle højrisikoposter.
Eksempel på testscenarier inkluderer,
- For at sikre, at sårbare HTTP-metoder ikke er aktiveret.
- For at sikre, at følsomme oplysninger fra de andre brugere ikke er synlige i klar tekst over netværket.
- For at sikre, at validering af filupload er implementeret for at undgå upload af en ondsindet fil.
Oversigt over tabeller til SSDLC
Nedenstående tabel opsummerer de forskellige aspekter af sikkerhedsanalyse, der er forklaret ovenfor.
SDLC-fase | Nøgleanalyse udført | Hvad der præcist gøres i disse vurderinger | Indgang | Brugte værktøjer | Produktion |
---|---|---|---|---|---|
Krav | For at sikre, at sikkerhedskrav fanges effektivt. | Krav analyseres. | Kravsdokumenter / brugerhistorier / funktioner | Håndbog | Sikkerhedskrav er indbygget i kravspecifikationerne. |
Planlægning | Sikkerhedsteam, der skal oprettes Strategi til sikkerhedstest udarbejdet. | Team identificeret og oprettet. Strategi udarbejdet, gennemgået og godkendt med interessenter. | Nul | Håndbog | Opsætning af sikkerhedsteam med RnR og RACI defineret. Signeret af sikkerhedstestdokument. |
Design | Vurdering af sikkerhedsrisici | Gennemgang af programrelaterede dokumenter for at identificere sikkerhedsfejl. Diskussion med holdet. Risici identificeres, og afbødning foreslås. | Projektrelaterede dokumenter: HLDD, LLDD. | Manuel gennemgang | Identificerede designrisici. Risikostyringsmatrix med foreslåede afbødninger. |
Udvikling | Sikker kodeanalyse (statisk vurdering) | Sikkerhedsscannere er tilsluttet udviklerens maskiner. Sikkerhedsværktøj integreret med build-skabelon. | Udviklet kode | Automatiser scannere (Fortify). Manuel triage af falske positive. | Sikker kodefejl. Risikostyringsmatrix med afbødninger. |
Implementering | Dynamisk kodeanalyse (dynamisk vurdering) | Test af applikationssikkerhed udført. | Enhedstestet konstruktion Dedikeret testmiljø | Sikkerhedstestværktøjer (HP WebInspect, Burp-suite, ZAP Manuel triage af falske positive. | Dynamiske kodeanalysefejl. Risikostyringsmatrix med afbødninger. |
Test / præinstallation | Pen test, Infra VAPT | Penetrationstest og Infra VAPT ved hjælp af realtidsscenarier. Verifikation af tidligere rapporterede risici / mangler. | Klar til implementering af build. Forprodukt eller produktion som miljø. | Sikkerhedstestværktøjer (Nessus, NMAP, HP WebInspect) Manuel triage af falske positive. | Risikostyringsmatrix med afbødninger. Endelig sikkerhedstestrapport med risikostatus. |
Konklusion
Med implementeringen af alle disse sikkerhedsrelaterede aspekter integreret på tværs af de forskellige faser af SDLC hjælper organisationen organisationen med at identificere sikkerhedsdefekter tidligt i cyklussen og gør det muligt for organisationen at implementere passende afbødninger og derved undgå Højrisikosikkerhedsfejl i Live System.
Undersøgelsen viser også, at et flertal af sikkerhedsdefekterne induceres i softwaren under udviklingsfasen, dvs. under Kodningsfase , hvor kodningen ikke har taget tilstrækkeligt sig af alle sikkerhedsaspekterne af uanset årsag.
Ideelt set ville ingen udviklere ønske at skrive en dårlig kode, der kompromitterer sikkerheden. For at guide udviklerne om, hvordan man skriver en sikker software, dækker den kommende tutorial således Bedste fremgangsmåder og retningslinjerne for kodning for udviklere for at sikre bedre sikkerhed for softwaren.
Vi håber, at denne tutorial om Secure SDLC eller SSDLC var nyttig !!
Anbefalet læsning
- SDLC (softwareudvikling livscyklus) faser, metoder, proces og modeller
- De 10 bedste mobile APP-sikkerhedstestværktøjer i 2021
- 19 Kraftige penetrationstestværktøjer, der blev brugt af professionelle i 2021
- Retningslinjer for test af mobilappsikkerhed
- Netværkssikkerhedstest og de bedste netværkssikkerhedsværktøjer
- Sikkerhedstest (En komplet guide)
- Top 4 Open Source sikkerhedstestværktøjer til test af webapplikation
- Vejledning til test af webapplikationssikkerhed