Tiltak for SSDLC (Secure Software Development Life Cycle)

measures ssdlc

Lær om forskjellige sikkerhetstiltak for å implementere en sikker SDLC eller SSDLC:

Siden teknologien vokser raskt, har også sikkerhetsrelaterte trusler om hacking og stjeling av sikrede data økt tilsvarende. Så ingen tvil om at teknologivekst gir programvareprodusenter utfordringer for å sikre at programvaren deres er sterk og robust mot sikkerhetstrusler og sårbarheter.

Et programvareprodukt kan ikke slippes, selv om det fungerer perfekt for den tiltenkte funksjonaliteten, med mindre det viser seg å være svært sikret og oppfyller de spesifiserte og regulerte sikkerhets- og personvernstandardene, spesielt i sektorer som forsvar, økonomi og helsevesen som involverer personlige og økonomiske data .

Man har ikke råd til å ha en sikkerhetsfeil på produktet når det distribueres, det være seg høy eller middels alvorlighetsgrad. Derfor er det veldig viktig å beskytte programvaren og dataene mot enhver form for angrep, ondsinnede trusler, sårbarheter og sikre programvarens pålitelighet for sluttbrukeren.

I motsetning til vår tradisjonelle programvareutvikling er det ikke mer effektivt å teste i den siste fasen etter at hele programvaren er utviklet. Med implementeringen av Agile-, DevOps- og ShiftLeft-konseptet, er det viktig å utføre tester så tidlig som i hver fase av applikasjonens livssyklus.

Når det er sagt, kan ikke sikkerheten til programvaren bygges eller testes i siste fase, og den må derfor bygges i hver fase for å sikre programvarens totale sikkerhet.

Hva du vil lære:

• Sikkerhetstiltak for SSDLC
  • # 1) Kravfase
  • # 2) Planleggingsfase
  • # 3) Arkitektur og designfase
  • # 4) Utviklingsfase
  • # 5) Implementeringsfase
  • # 6) Testing - Pre Deployment Phase
• Tabelloversikt for SSDLC
• Konklusjon
  • Anbefalt lesing

Sikkerhetstiltak for SSDLC

Nedenfor er de forskjellige måtene for sikkerhetsrelaterte tiltak som kan implementeres på tvers av programvarens utviklingslivssyklus for å sikre Secure SDLC eller SSDLC, og så mye som mulig, får ikke manglene videre til neste fase.

De forskjellige sikkerhetsanalysene og vurderingene der sikkerhet må bygges i SDLC-faser er.

1. Kravfase
2. Planleggingsfase
3. Arkitektur og designfase: Sikkerhetsrisikovurdering basert på design.
4. Utviklingsfase: Secure Code Analysis, en statisk analyse av koden for sikkerhet.
5. Implementeringsfase: Dynamic Code Analysis, en applikasjonssikkerhetstesting.
6. Testing - Pre Deployment Phase: Penetrasjonstesting og sårbarhetsanalyse.

# 1) Kravfase

• For å sikre at nødvendige sikkerhetstiltak er innebygd i programvaren, Sikkerhetsrelaterte spesifikke krav må fanges tydelig i løpet av kravfasen med nok detaljer og forventede resultater.
• Mens du identifiserer de typiske brukssakene og forretningsscenariene, er det et klart sett med Sikkerhetsrelaterte brukssaker og scenarier for verifiseringsformål må det identifiseres for å fange sikkerhetsfunksjonene og utforme sikkerhetstestingsscenarier.

Nedenfor er noen eksempler på eksempler som illustrerer de eksplisitte sikkerhetsrelaterte kravene som kan fanges.

Sec-Req-01: Det kreves at systemet har autentiseringstiltak på alle gatewayer og inngangspunkter.

Sec-Req-02: Systemet kreves for å implementere autentisering via en sikker påloggingsskjerm.

Sec-Req-03: PERSONLIGE DATA skal krypteres i hvile.

# 2) Planleggingsfase

På høyt nivå, men ikke bare begrenset til disse, må følgende punkter ivaretas i planleggingsfasen.

osi-modellenheter bruker hvert lag

• En sterk, Dedikert sikkerhetsteam , fungerer utenfor PMO (prosjektledelseskontor) til programteamet, bestående av Sikkerhetsoffiser, sikkerhetsarkitekter, sikkerhetstestere som skal dannes for å gjennomføre og administrere alle sikkerhetsrelaterte aktiviteter i programmet på en upartisk måte. For hver av disse rollene defineres en tydelig RnR (roller og ansvar) og RACI.
• Noen opptrappinger, uklarheter relatert til sikkerhetsspørsmål må håndteres av PSO (Product Security Officer) slik at sikkerhetsteamet fungerer greit og hjelper til med å ta de riktige beslutningene.
• En robust Strategi for sikkerhetstesting spesifisere hvordan de sikkerhetsrelaterte kravene skal implementeres, hvordan, når og hva man skal teste, hvilke verktøy som skal brukes på hvert trinn, må identifiseres.
• Det er obligatorisk å involvere Sikkerhetspunkt for kontakt for alle tekniske / gjennomgangsdiskusjoner knyttet til programmet, slik at sikkerhetsteamet er klar over eventuelle endringer som skjer i programmet.

# 3) Arkitektur og designfase

Å være mer oppmerksom på sikkerhetsaspektene tidlig i designfasen, vil bidra til å forhindre sikkerhetsrisikoen og redusere betydelig innsats i designendringer senere i SDLC.

Mens du designer programvaren, og infrastrukturen som programvaren vil være vert for, er alt mulig Implementeringer av sikkerhetsdesign må være godt utformet med involvering av sikkerhetsarkitektene.

Enhver tvetydighet og konflikt mellom de funksjonelle og ikke-funksjonelle design- og arkitekturaspektene må ordnes gjennom idédugnad hvor de rette interessentene involveres.

I løpet av denne fasen, en detaljert produktsikkerhetsvurdering, som også noen ganger kalles ‘Statisk vurdering’ må utføres av sikkerhetsteamet med eksperter.

Vurdering av sikkerhetsrisiko inkluderer en gjennomgang av programmene fra et sikkerhetsmessig synspunkt på det foreløpige design / arkitekturtrinnet for å identifisere sikkerhetsrelaterte feil fra designperspektivet og følgelig heve produktet Sikkerhetsrisiko til prosjektgruppen for å henvende seg til dem og unngå å gå inn i neste fase.

Disse vurderingene blir utført basert på retningslinjene, standardene og kontrollene for organisasjon / industri som er beskrevet i disse dokumentene. F.eks. UXW 00320, UXW 030017

Under produktsikkerhetsvurdering:

• Krav, funksjoner, brukerhistorier og deres designdokumenter blir gjennomgått, basert på detaljer, gjenstander som deles av prosjektgruppen, F.eks. Designdokumenter (HLDD og LLDD). Evalueringene innebærer også diskusjoner med de aktuelle medlemmene av prosjektgruppen i fravær av dokumenter eller for å avklare om det er tvil.
• Mangler identifiseres mens sikkerhetskravene til programmet kartlegges mot de fastsatte standardene og annen god praksis. Noen ganger utvikles også trusselmodeller basert på de identifiserte hullene.
• Disse hullene er identifisert som potensielle sikkerhetsrisikoer inkluderer også antydning om mulige avbøtninger for implementering, økes og administreres.
• Når disse begrensningene er implementert av prosjektgruppen, blir de bekreftet for avslutning via passende testtilfeller designet av System Test-teamet.
• Risikostyringsmatrise, som gir sporbarhet, er forberedt på å spore disse risikoene. Godkjenning og signering med restrisiko vil bli tatt av sikkerhetsarkitekten og PSO.

Typiske trusselmønstre som er identifisert i designfasen er relatert til Inngangsvalidering, Revisjon / Loggstyring, Konfigurasjoner og kryptering. Risikoidentifikasjonen inkluderer angripende sårbarheter som svake passord, enkle brute force-angrep, etc.,

Typiske gjennomganger inkluderer risiko knyttet til tilgang til personopplysninger, tilgang til revisjonsspor, enheter på svarteliste-hviteliste, datarensing og slettingsaktivitet.

hvordan åpner du xml-filer

Eksempel på testscenarier inkluderer:

• Sårbarhet i bufferoverløp: For å sikre at ved å manuelt parametre parametere, skal det ikke være mulig å bremse serveren og tvinge serveren til ikke å svare (Denial of Service).
• Datasanitisering: For å sikre at riktig datasanitering skjer for hver inngang og utgang, slik at angriperen ikke kan injisere og lagre det ondsinnede innholdet i systemet.

# 4) Utviklingsfase

Sikker kodeanalyse er en Vurdering av statisk kode metode som brukes til å vurdere Sikker kode av de forskjellige funksjonene i programvaren ved hjelp av et automatisert skanneverktøy. Eksempel: Forsterke.

Denne analysen utføres på hver kode som sjekkes inn / bygges for å skanne koden som genereres for sikkerhetstruslene. Denne vurderingen gjøres vanligvis på et User Story-nivå.

• Fortify-skanninger via plugins må installeres på utviklerens maskiner.
• Fortify må integreres med byggemalen.
• Automatisert skanning vil utføres på alle bygg hver dag.
• Skanneresultatet vil bli analysert av sikkerhetsteamet for falske positive.
• Mangler identifisert ved denne vurderingen løftes og håndteres til avslutning, slik at sive minimeres / nullstilles til neste nivå.

Eksempel på testscenarier inkluderer:

• For å sikre at sensitive data ikke sendes i ren tekst under dataoverføring.
• For å sikre sikker dataoverføring må API-er som vender utover, distribueres på en HTTPS-kanal.

# 5) Implementeringsfase

Dynamisk kodeanalyse er ingenting annet enn Application Security Testing, som også kalles OWASP (Open Web Application Security Project) testing. Sårbarhetsanalyse og penetrasjonstesting (VAPT) må gjennomføres i implementerings- / testfasen.

Denne analysen vurderer binærfiler og noen miljøkonfigurasjoner og styrker koden for sikkerhetskravene ytterligere.

Som en del av denne analysen, har Dynamisk atferd eller funksjonaliteten til forskjellige funksjoner i programmene blir analysert for sikkerhetsrelaterte sårbarheter. Bestemte brukssaker og forretningsscenarier brukes også til å utføre dynamisk kodeanalyse.

Denne aktiviteten utføres på Test Builds bruker forskjellige sikkerhetsverktøy med en automatisert og manuell tilnærming.

• HP WebInspect, Burp Suite, ZAP og SOAP UI verktøy brukes vanligvis til å sjekke sårbarheter mot standard sårbarhetsdatabaser ( Eksempel: OWASP Topp 10 )
• Denne aktiviteten er imidlertid hovedsakelig automatisert på grunn av visse verktøybegrensninger, noe manuelt arbeid kan være nødvendig for å triage falske positive.
• Dette gjøres ideelt i et eget miljø (System Testing Environment), der programvaren klar for testing blir distribuert.
• Sårbarheter må heves og tas til slutt med de foreslåtte avbøtningene.

Typiske trusselmønstre identifisert under denne analysen er relatert til Input validering, Broken Authentication & Session Management, Sensitive data exposure, XSS and Password Management.

Eksempel på testscenarier inkluderer,

• Passordadministrasjon: For å sikre at passordene ikke lagres i ren tekst i konfigurasjonsfilene eller hvor som helst i systemet.
• Systeminformasjon Lekkasje: For å sikre at systeminformasjonen ikke lekker ut på noe tidspunkt, kan informasjonen avslørt av printStackTrace hjelpe motstanderen fra en angrepsplan.

# 6) Testing - Pre Deployment Phase

Penetrasjonstesting , Pen Test i korte og Infra VAPT (Sårbarhetsanalyse og penetrasjonstesting) , er den fullverdige helhetstesten med full løsning og konfigurasjoner (inkludert nettverk) som ideelt sett gjøres i et pre-prod eller produksjonslignende miljø.

Dette utføres hovedsakelig for å identifisere DB-sikkerhetsproblemer og serverproblemer sammen med eventuelle andre sikkerhetsproblemer. Dette er den siste fasen av sikkerhetstesting som vil bli gjennomført. Derfor inkluderer dette også verifisering av tidligere rapporterte mangler og risikoer.

• Verktøy som Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP som er tilgjengelige i markedet, brukes til å utføre pennetesting.
• Skanning av webapplikasjoner ved hjelp av automatiserte verktøy og utnyttelse for videre verifisering gjøres under denne testingen. Testing er gjort for å simulere den virkelige angriperens oppførsel, og det kan derfor også omfatte noen få negative tester.
• Sårbarhet i infrastruktur vurderingen inkluderer skanning, analyse og sikkerhetskonfigurasjonsgjennomgang av infrastruktur (nettverk, systemer og servere) for å identifisere sårbarhetene og kontrollere motstandsdyktigheten mot målrettede angrep.
• Dette utføres i et pre-produksjon eller produksjonslignende miljø, der programvaren som er klar til distribusjon blir testet og dermed simulerer sanntidsmiljøet.
• Sårbarheter identifiseres ved hjelp av både skannere og manuelle teknikker for å eliminere falske positive. I tillegg vil forretningsscenarier i sanntid bli utført under manuell testing.
• En sluttrapport om hele sikkerhetsanalysen som gjennomføres for hele programmet vil bli produsert som fremhever status for høyrisikoelementene, hvis noen.

Eksempel på testscenarier inkluderer,

• For å sikre at sårbare HTTP-metoder ikke er aktivert.
• For å sikre at sensitiv informasjon fra de andre brukerne ikke er synlig i klar tekst over nettverket.
• For å sikre at validering for filopplasting er implementert for å unngå opplasting av en ondsinnet fil.

Tabelloversikt for SSDLC

Tabellen nedenfor oppsummerer de forskjellige aspektene ved sikkerhetsanalyse som er forklart ovenfor.

Konklusjon

Med implementeringen av alle disse sikkerhetsrelaterte aspektene integrert på tvers av de forskjellige fasene i SDLC, hjelper organisasjonen organisasjonen med å identifisere sikkerhetsfeilene tidlig i syklusen og gjør det mulig for organisasjonen å implementere passende begrensninger, og dermed unngå Høyrisikosikkerhetsfeil i Live System.

Studien viser også at et flertall av sikkerhetsfeilene er indusert i programvaren under utviklingsfasen, dvs. under Kodningsfase , hvor kodingen ikke har tilstrekkelig ivaretatt alle sikkerhetsaspekter, uansett årsak.

Ideelt sett vil ingen utviklere skrive en dårlig kode som kompromitterer sikkerheten. For å veilede utviklerne om hvordan man skriver en sikker programvare, dekker den kommende opplæringen Beste praksis og retningslinjene for koding for utviklere, for å sikre bedre sikkerhet for programvaren.

Vi håper denne opplæringen om Secure SDLC eller SSDLC var nyttig !!

Anbefalt lesing

• SDLC (programvareutvikling livssyklus) faser, metoder, prosesser og modeller
• 10 beste verktøy for mobil APP-sikkerhetstesting i 2021
• 19 Kraftige penetrasjonstestverktøy brukt av proffer i 2021
• Retningslinjer for testing av mobilapper
• Testing av nettverkssikkerhet og beste verktøy for nettverkssikkerhet
• Sikkerhetstesting (En komplett guide)
• Topp 4 open source sikkerhetstestverktøy for å teste webapplikasjon
• Veiledning for testing av webapplikasjoner