Åtgärder för SSDLC (Secure Software Development Life Cycle)

measures ssdlc

Lär dig om olika säkerhetsåtgärder för en säker SDLC eller SSDLC:

Eftersom tekniken växer snabbt har säkerhetsrelaterade hot om hackning och stjäling av säkra data också ökat i enlighet därmed. Så ingen tvekan om att teknikutvecklingen ger programvarutillverkarna utmaningar för att säkerställa att deras programvara är stark och robust mot säkerhetshot och sårbarheter.

En programvaruprodukt kan inte släppas, även om den fungerar perfekt för den avsedda funktionaliteten såvida den inte visar sig vara mycket säker och uppfyller de angivna och reglerade säkerhets- och sekretessstandarderna, särskilt i sektorer som försvar, ekonomi och hälsovård som involverar personliga och ekonomiska data .

Man har inte råd att ha en säkerhetsfel i produkten när den distribueras, vare sig den är hög eller medelhög. Därför är det mycket viktigt att skydda programvaran och data från alla typer av attacker, skadliga hot, sårbarheter och säkerställa programvarans pålitlighet för slutanvändaren.

I motsats till vår traditionella programvaruutveckling är testning i sista fasen efter att hela programvaran har utvecklats inte mer effektiv. Med implementeringen av Agile-, DevOps- och ShiftLeft-konceptet är det viktigt att utföra testning tidigt såväl som i varje fas av applikationens livscykel.

Med detta sagt kan programvarans säkerhet inte byggas eller testas till och med i sista steget och därför måste den byggas i varje fas för att säkerställa den totala säkerheten för programvaran.

Vad du kommer att lära dig:

• Säkerhetsåtgärder för SSDLC
  • # 1) Kravsfas
  • # 2) Planeringsfas
  • # 3) Arkitektur och designfas
  • # 4) Utvecklingsfas
  • # 5) Implementeringsfas
  • # 6) Testning - Fördriftsättningsfas
• Tabellöversikt för SSDLC
• Slutsats
  • Rekommenderad läsning

Säkerhetsåtgärder för SSDLC

Nedan listas de olika sätten för säkerhetsrelaterade åtgärder som kan implementeras under livscykeln för programvaruutveckling för att säkerställa säker SDLC eller SSDLC och så mycket som möjligt får bristerna inte fortsätta till nästa fas.

De olika säkerhetsanalyserna och bedömningarna vid vilka säkerhet måste byggas i SDLC-faser är.

1. Kravsfas
2. Planeringsfas
3. Arkitektur och designfas: Bedömning av säkerhetsrisk baserat på design.
4. Utvecklingsfas: Säker kodanalys, en statisk analys av koden för säkerhet.
5. Implementeringsfas: Dynamisk kodanalys, en applikationssäkerhetstestning.
6. Testning - Fördriftsättningsfas: Penetrationstest och sårbarhetsanalys.

# 1) Kravsfas

• För att säkerställa att nödvändiga säkerhetsåtgärder byggs in i programvaran, Säkerhetsrelaterade specifika krav måste fångas tydligt under kravfasen med tillräckligt med detaljer och förväntade resultat.
• Medan man identifierar typiska användningsfall och affärsscenarier, en tydlig uppsättning Säkerhetsrelaterade användningsfall och scenarier för verifieringsändamål måste identifieras för att fånga säkerhetsfunktioner och designa scenarier för säkerhetstestning.

Nedan följer några exempel på exempel som illustrerar de uttryckliga säkerhetsrelaterade kraven som kan fångas.

Sec-Req-01: Systemet måste ha autentiseringsåtgärder på alla portar och ingångspunkter.

Sec-Req-02: Systemet krävs för att implementera autentisering via en säker inloggningsskärm.

Sec-Req-03: PERSONUPPGIFTER ska krypteras i vila.

# 2) Planeringsfas

På hög nivå, men inte bara begränsad till dessa, måste följande punkter beaktas i planeringsfasen.

osi-modeller använder varje lager

• En stark, Dedikerat säkerhetsteam , fungerar utanför PMO (projektledningskontoret) för programgruppen, bestående av Säkerhetsansvarig, säkerhetsarkitekter, säkerhetstestare att bildas för att utföra och hantera alla säkerhetsrelaterade aktiviteter i programmet på ett opartiskt sätt. För var och en av dessa roller definieras en tydlig RnR (roller och ansvarsområden) och RACI.
• Några eskaleringar, tvetydigheter relaterade till säkerhetsfrågor måste hanteras av PSO (Product Security Officer) så att säkerhetsteamet fungerar smidigt och hjälper till att fatta rätt beslut.
• En robust Säkerhetsteststrategi specificera hur säkerhetsrelaterade krav ska implementeras, hur, när och vad som ska testas, vilka verktyg som ska användas i varje steg, måste identifieras.
• Det är obligatoriskt att involvera Kontaktpunkt för säkerhet för alla tekniska / granskningsdiskussioner relaterade till programmet så att säkerhetsgruppen är medveten om eventuella förändringar som händer i programmet.

# 3) Arkitektur och designfas

Att ägna mer uppmärksamhet åt säkerhetsaspekterna tidigt under designfasen ska bidra till att förhindra säkerhetsriskerna och minska betydande ansträngningar för designändringar senare i SDLC.

Medan du utformar programvaran och infrastrukturen som programvaran kommer att vara värd för, är allt möjligt Implementeringar av säkerhetsdesign måste utformas väl med inblandning av säkerhetsarkitekterna.

Varje tvetydighet och konflikter mellan funktionella och icke-funktionella design- och arkitekturaspekter måste sorteras genom brainstormningssessioner med rätt intressenter.

Under denna fas, en detaljerad produktsäkerhetsbedömning, som också ibland kallas 'Statisk bedömning' måste utföras av säkerhetsteamet av experter.

Bedömning av säkerhetsrisker inkluderar en granskning av programmen från en säkerhetssynpunkt i det preliminära design- / arkitekturskedet för att identifiera säkerhetsrelaterade brister ur designperspektivet och därmed höja produkten Säkerhetsrisker till projektgruppen för att ta itu med dem och undvika att gå in i nästa fas.

Dessa bedömningar utförs utifrån de organisatoriska / industriella säkerhetsriktlinjerna, standarderna och kontrollerna som beskrivs i dessa dokument. T.ex. UXW 00320, UXW 030017

Vid produktsäkerhetsbedömning:

• Krav, funktioner, användarberättelser och deras designdokument granskas baserat på detaljer, artefakter som delas av projektgruppen, T.ex. Designdokument (HLDD och LLDD). Bedömningarna innefattar också diskussioner med berörda projektgruppsmedlemmar om det saknas dokument eller för att klargöra om det finns några tvivel.
• Brister identifieras när programmets säkerhetskrav mappas mot de fastställda standarderna och andra bästa praxis. Ibland utvecklas också hotmodeller baserat på de identifierade luckorna.
• Dessa luckor identifieras som potentiella säkerhetsrisker inkluderar också att föreslå möjliga begränsningar för implementering, höjs och hanteras.
• När dessa begränsningar har implementerats av projektgruppen verifieras de för stängning via lämpliga testfall designade av systemtestteamet.
• Riskhanteringsmatris, som ger spårbarhet, är beredd att spåra dessa risker. Godkännande och avloggning med återstående risk tas av säkerhetsarkitekten och PSO.

Typiska hotmönster som identifieras i designfasen är relaterade till Input Validation, Audit / Log Management, Configurations och encryptions. Riskidentifieringen inkluderar attackerande sårbarheter som svaga lösenord, Simple Brute Force Attacks, etc.,

Typiska recensioner inkluderar risker relaterade till åtkomst till personuppgifter, åtkomst till granskningsspår, enheter för svartlistning och vitlistning, datarengöring och borttagningsaktivitet.

Exempel på testscenarier inkluderar:

• Sårbarhet vid buffertöverflöd: För att säkerställa att genom manuell fuzzing av parametrar bör det inte vara möjligt att sakta ner servern och tvinga servern att inte svara (Denial of Service).
• Sanering av data: För att säkerställa att korrekt datain sanering sker för varje in- och utmatning så att angriparen inte kan injicera och lagra det skadliga innehållet i systemet.

# 4) Utvecklingsfas

Säker kodanalys är en Bedömning av statisk kod metod som används för att bedöma Säkerhetskod av de olika funktionerna i programvara med hjälp av ett automatiskt skanningsverktyg. Exempel: Befästa.

Denna analys utförs vid varje kodincheckning / -byggnad för att skanna koden som genereras för säkerhetshot. Denna bedömning görs vanligtvis på en User Story-nivå.

• Fortify-skanningar via plugins måste installeras på utvecklarens maskiner.
• Fortify måste integreras med byggmallen.
• Automatisk skanning kommer att utföras på alla byggnader dagligen.
• Skanningsresultatet kommer att analyseras av säkerhetsteamet för falska positiva resultat.
• Defekter som identifierats av denna bedömning lyfts upp och hanteras till slutet, så att läckage minimeras / nollställs till nästa nivå.

Exempel på testscenarier inkluderar:

• För att säkerställa att känslig data inte skickas i klartext under dataöverföringen.
• För att säkerställa säker dataöverföring måste API: er som vetter mot externa enheter distribueras på en HTTPS-kanal.

# 5) Implementeringsfas

Dynamisk kodanalys är inget annat än Application Security Testing, som också kallas OWASP (Open Web Application Security Project) -testning. Sårbarhetsanalys och penetrationstestning (VAPT) måste genomföras i implementerings- / testfasen.

Denna analys utvärderar binärfilerna och vissa miljökonfigurationer och stärker koden för säkerhetskraven ytterligare.

testledningsintervju frågor och svar pdf

Som en del av denna analys har Dynamiskt beteende eller funktionaliteten hos olika funktioner i programmen analyseras för säkerhetsrelaterade sårbarheter. Bestämda användningsfall och affärsscenarier används också för att utföra dynamisk kodanalys.

Denna aktivitet utförs på Testbyggnader med olika säkerhetsverktyg med ett automatiserat och manuellt tillvägagångssätt.

• HP WebInspect-, Burp Suite-, ZAP- och SOAP UI-verktyg används vanligtvis för att kontrollera sårbarheter mot vanliga sårbarhetsdatabaser ( Exempel: OWASP Topp 10 )
• Denna aktivitet är dock huvudsakligen automatiserad, på grund av vissa verktygsbegränsningar, kan manuellt arbeta krävas för att triage falska positiva resultat.
• Detta görs idealiskt i en separat miljö (System Testing Environment), där programvaran som är redo för testning distribueras.
• Sårbarheter måste höjas och avslutas med de föreslagna lindringarna.

Typiska hotmönster som identifierats under denna analys är relaterade till Input validering, Broken Authentication & Session Management, Sensitive data exposure, XSS and Password Management.

Exempel på testscenarier inkluderar,

• Lösenordshantering: För att säkerställa att lösenorden inte lagras i ren text i konfigurationsfilerna eller någonstans i systemet.
• Systeminformationsläckage: För att säkerställa att systeminformationen inte läcks ut vid någon tidpunkt kan den information som avslöjas av printStackTrace hjälpa motståndaren från en attackplan.

# 6) Testning - Fördriftsättningsfas

Penetrationstestning , Pen Test i korthet och Infra VAPT (sårbarhetsanalys och penetrationstestning) , är det fullständiga helhetsprovet med fullständig lösning och konfigurationer (inklusive nätverk) som helst görs i en pre-prod eller produktionsliknande miljö.

Detta utförs huvudsakligen för att identifiera DB-sårbarheter och serversårbarheter tillsammans med andra sårbarheter. Detta är det sista steget i säkerhetstest som skulle genomföras. Detta inkluderar även verifiering av tidigare rapporterade brister och risker.

• Verktyg som Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP som finns tillgängliga på marknaden används för att utföra testning av pennor.
• Skanning av webbapplikationer med automatiserade verktyg och utnyttjande för ytterligare verifiering görs under denna testning. Testning görs för att simulera den verkliga angriparens beteende och därför kan det också innehålla några negativa tester.
• Sårbarhet i infrastruktur bedömningen inkluderar skanning, analys och säkerhetskonfigurationsgranskning av infrastruktur (nätverk, system och servrar) för att identifiera sårbarheterna och kontrollera motståndskraften mot de riktade attackerna.
• Detta utförs i en förproduktion eller produktionsliknande miljö där programvaran som är redo att distribueras testas och därmed simulerar realtidsmiljön.
• Sårbarheter identifieras med både skannrar och manuella tekniker för att eliminera falska positiva effekter. Dessutom kommer affärsscenarier i realtid att genomföras under manuell testning.
• En slutrapport om hela säkerhetsanalysen som genomförs för hela programmet kommer att framställas med status för eventuella högriskposter.

Exempel på testscenarier inkluderar,

• För att säkerställa att sårbara HTTP-metoder inte är aktiverade.
• För att säkerställa att känslig information från andra användare inte syns i klartext över nätverket.
• För att säkerställa att validering för filöverföring implementeras för att undvika uppladdning av en skadlig fil.

Tabellöversikt för SSDLC

Nedanstående tabell sammanfattar de olika aspekterna av säkerhetsanalys som förklaras ovan.

Slutsats

Med implementeringen av alla dessa säkerhetsrelaterade aspekter integrerade över de olika faserna i SDLC hjälper organisationen att identifiera säkerhetsfel tidigt i cykeln och gör det möjligt för organisationen att genomföra lämpliga begränsningar och därigenom undvika Högrisksäkerhetsfel i Live System.

Studien visar också att en majoritet av säkerhetsdefekterna induceras i programvaran under utvecklingsfasen, dvs. under Kodningsfas , varvid kodningen inte har tagit tillräckligt hand om alla säkerhetsaspekter, oavsett orsaker.

Helst skulle ingen utvecklare vilja skriva en dålig kod som äventyrar säkerheten. Således för att vägleda utvecklarna om hur man skriver en säker programvara, täcker den kommande handboken Bästa praxis och kodningsriktlinjerna för utvecklare, för att säkerställa bättre säkerhet för programvaran.

Vi hoppas att den här guiden om Secure SDLC eller SSDLC var till hjälp !!

Rekommenderad läsning

• SDLC (Software Development Life Cycle) -faser, metoder, processer och modeller
• 10 bästa verktyg för mobilappsäkerhetstestning 2021
• 19 Kraftfulla penetrationsprovningsverktyg som användes av proffs 2021
• Riktlinjer för testning av mobilapps säkerhet
• Testning av nätverkssäkerhet och bästa verktyg för nätverkssäkerhet
• Säkerhetstestning (en komplett guide)
• Topp 4 Open Source Security Testing Tools för att testa webbapplikation
• Testguide för webbapplikationssäkerhet