Maatregelen voor SSDLC (Secure Software Development Life Cycle)

measures ssdlc

Lees meer over verschillende beveiligingsmaatregelen die u kunt implementeren voor een veilige SDLC of SSDLC:

Aangezien de technologie snel groeit, zijn ook de beveiligingsgerelateerde bedreigingen van hacken en stelen van beveiligde gegevens dienovereenkomstig toegenomen. Het lijdt dus geen twijfel dat de technologische groei de softwaremakers voor uitdagingen stelt om ervoor te zorgen dat hun software sterk en robuust is tegen de beveiligingsbedreigingen en kwetsbaarheden.

Een softwareproduct kan niet worden vrijgegeven, zelfs niet als het perfect functioneert voor de beoogde functionaliteit, tenzij het sterk beveiligd blijkt te zijn en voldoet aan de gespecificeerde en gereguleerde beveiligings- en privacynormen, vooral in sectoren als Defensie, Financiën en Gezondheidszorg waarbij persoonlijke en financiële gegevens worden gebruikt .

Men kan het zich niet veroorloven om een ​​beveiligingsfout in het product te hebben wanneer het wordt geïmplementeerd, of het nu gaat om een ​​hoge of gemiddelde ernst. Daarom is het zeer essentieel om de software en de gegevens te beschermen tegen elke vorm van aanval, kwaadwillende bedreiging en kwetsbaarheden, en om de betrouwbaarheid van de software voor de eindgebruiker te waarborgen.

In tegenstelling tot onze traditionele softwareontwikkeling, is testen in de laatste fase nadat de volledige software is ontwikkeld niet meer effectief. Bij de implementatie van het Agile-, DevOps- en ShiftLeft-concept is het essentieel om zowel vroeg als in elke fase van de applicatielevenscyclus te testen.

Dat gezegd hebbende, de beveiliging van de software kan in de laatste fase niet worden gebouwd of zelfs getest en daarom moet deze in elke fase worden gebouwd om de totale veiligheid van de software te garanderen.

Wat je leert:

• Beveiligingsmaatregelen voor SSDLC
  • # 1) Vereistenfase
  • # 2) Planningsfase
  • # 3) Architectuur- en ontwerpfase
  • # 4) Ontwikkelingsfase
  • # 5) Implementatiefase
  • # 6) Testen - Pre-implementatiefase
• Tabeloverzicht voor SSDLC
• Gevolgtrekking
  • Aanbevolen literatuur

Beveiligingsmaatregelen voor SSDLC

Hieronder worden de verschillende middelen van beveiligingsgerelateerde maatregelen genoemd die kunnen worden geïmplementeerd gedurende de levenscyclus van softwareontwikkeling om Secure SDLC of SSDLC te garanderen en de defecten mogen zoveel mogelijk niet worden overgedragen naar de volgende fase.

De verschillende beveiligingsanalyses en assessments waarbij beveiliging moet worden gebouwd in SDLC-fasen zijn.

1. Vereistenfase
2. Planningsfase
3. Architectuur- en ontwerpfase: Beveiligingsrisicobeoordeling op basis van het ontwerp.
4. Ontwikkelingsfase: Secure Code Analysis, een statische analyse van de code voor beveiliging.
5. Implementatie fase: Dynamic Code Analysis, een applicatiebeveiligingstest.
6. Testen - Pre-implementatiefase: Penetratietesten en kwetsbaarheidsanalyse.

# 1) Vereistenfase

• In de eerste plaats om ervoor te zorgen dat de nodige beveiligingsmaatregelen in de software worden ingebouwd, Beveiligingsgerelateerde specifieke vereisten moeten duidelijk worden vastgelegd tijdens de requirementsfase met voldoende details en verwachte resultaten.
• Bij het identificeren van de typische gebruiksscenario's en bedrijfsscenario's, een duidelijke set van Beveiligingsgerelateerde gebruiksscenario's en scenario's voor verificatiedoeleinden moeten worden geïdentificeerd om de beveiligingsfuncties vast te leggen en beveiligingsscenario's te ontwerpen.

Hieronder vindt u enkele voorbeeldvoorbeelden die de expliciete beveiligingsgerelateerde vereisten illustreren die kunnen worden vastgelegd.

Sec-Req-01: Het systeem moet authenticatiemaatregelen hebben bij alle gateways en toegangspunten.

Sec-Req-02: Het systeem is vereist om authenticatie te implementeren via een beveiligd inlogscherm.

Sec-Req-03: PERSOONLIJKE GEGEVENS worden in rust versleuteld.

# 2) Planningsfase

Op een hoog niveau, maar niet alleen hiertoe beperkt, moeten de volgende punten in de planningsfase worden aangepakt.

salesforce developer interviewvragen voor ervaren

• Een sterke, Toegewijd beveiligingsteam , functioneren buiten het PMO (projectmanagementbureau) van het programmateam, bestaande uit Beveiligingsfunctionaris, beveiligingsarchitecten, beveiligingstesters worden gevormd om alle veiligheidsgerelateerde activiteiten van het programma op een onbevooroordeelde manier uit te voeren en te beheren. Voor elk van deze rollen is een duidelijke RnR (rollen en verantwoordelijkheden) en RACI gedefinieerd.
• Ieder escalaties, onduidelijkheden met betrekking tot de beveiligingskwesties moeten worden afgehandeld door de PSO (Product Security Officer) zodat het beveiligingsteam soepel functioneert en helpt bij het nemen van de juiste beslissingen.
• Een robuust Strategie voor het testen van beveiliging specificeren hoe de beveiligingsgerelateerde vereisten moeten worden geïmplementeerd, hoe, wanneer en wat er moet worden getest en welke tools in elke fase moeten worden gebruikt, moet worden geïdentificeerd.
• Het is verplicht om het Beveiligingspunt voor alle technische / review-discussies met betrekking tot het programma, zodat het beveiligingsteam op de hoogte is van eventuele wijzigingen in het programma.

# 3) Architectuur- en ontwerpfase

Door in de ontwerpfase al vroeg meer aandacht te besteden aan de beveiligingsaspecten, worden de veiligheidsrisico's voorkomen en worden aanzienlijke inspanningen voor ontwerpwijzigingen later in de SDLC verminderd.

Bij het ontwerpen van de software en de infrastructuur waarop de software wordt gehost, alles mogelijk Implementaties van beveiligingsontwerp moeten goed worden ontworpen met de betrokkenheid van de beveiligingsarchitecten.

Elke dubbelzinnigheid en conflicten tussen de functionele en niet-functionele aspecten van Ontwerp en Architectuur moeten worden opgelost door middel van brainstormsessies met de juiste belanghebbenden.

Tijdens deze fase wordt een gedetailleerde Product Security Risk Assessment uitgevoerd, ook wel genoemd ‘Statische beoordeling’ moet worden uitgevoerd door het beveiligingsteam van experts.

Beoordeling van beveiligingsrisico's omvat een beoordeling van de programma's vanuit een beveiligingsstandpunt in de voorlopige ontwerp- / architectuurfase om de beveiligingsgerelateerde tekortkomingen vanuit het ontwerpperspectief te identificeren en dienovereenkomstig het product te verhogen Beveiligingsrisico's aan het projectteam om ze aan te pakken en te voorkomen dat ze de volgende fase ingaan.

Deze beoordelingen worden uitgevoerd op basis van de organisatorische / industriële beveiligingsrichtlijnen, normen en controles die in die documenten worden beschreven. Bijv. UXW 00320, UXW 030017

Tijdens productbeveiligingsrisicobeoordeling:

• Vereisten, functies, gebruikersverhalen en hun ontwerpdocumenten worden beoordeeld op basis van de details, artefacten gedeeld door het projectteam, Bijv. Ontwerpdocumenten (HLDD en LLDD). De beoordelingen omvatten ook besprekingen met de relevante projectteamleden in geval van het ontbreken van documenten of om eventuele twijfels op te helderen.
• Hiaten worden geïdentificeerd terwijl de beveiligingsvereisten van het programma in kaart worden gebracht tegen de vastgestelde normen en andere best practices. Soms worden ook dreigingsmodellen ontwikkeld op basis van de geïdentificeerde hiaten.
• Deze hiaten worden geïdentificeerd als potentiële beveiligingsrisico's, inclusief het suggereren van mogelijke mitigerende maatregelen voor de implementatie, die worden verhoogd en beheerd.
• Zodra deze mitigaties door het projectteam zijn geïmplementeerd, worden ze geverifieerd voor de afsluiting via geschikte testcases die zijn ontworpen door het systeemtestteam.
• Risk Management Matrix, die traceerbaarheid biedt, is voorbereid om deze risico's te volgen. Goedkeuring en aftekenen met het restrisico geschiedt door de Security Architect en PSO.

Typische bedreigingspatronen die tijdens de ontwerpfase worden geïdentificeerd, hebben betrekking op invoervalidatie, audit / logbeheer, configuraties en coderingen. De risico-identificatie omvat aanvallende kwetsbaarheden zoals zwakke wachtwoorden, eenvoudige brute force-aanvallen, enz.,

Typische beoordelingen omvatten risico's met betrekking tot toegang tot persoonlijke gegevens, toegang tot audittrails, blacklisting-whitelisting-entiteiten, gegevensopschoning en verwijderingsactiviteiten.

Voorbeelden van testscenario's zijn:

• Kwetsbaarheid voor bufferoverloop: Om ervoor te zorgen dat door handmatig parameters te fuzzen, het niet mogelijk moet zijn om de server te vertragen en de server te dwingen niet te reageren (Denial of Service).
• Gegevens opschonen: Om ervoor te zorgen dat de juiste gegevensopschoning plaatsvindt voor elke invoer en uitvoer, zodat de aanvaller de kwaadaardige inhoud niet in het systeem kan injecteren en opslaan.

# 4) Ontwikkelingsfase

Veilige codeanalyse is een Beoordeling van statische codes methode die wordt gebruikt om de Beveiligings code van de verschillende functies van software met behulp van een geautomatiseerde scantool. Voorbeeld: Versterken.

Deze analyse wordt uitgevoerd bij elke code check-in / build om de gegenereerde code te scannen op de beveiligingsbedreigingen. Deze beoordeling wordt doorgaans gedaan op het niveau van User Story.

• Versterkende scans via plug-ins moeten op de machines van de ontwikkelaar worden geïnstalleerd.
• Fortify moet worden geïntegreerd met de build-sjabloon.
• Er wordt dagelijks automatisch gescand op alle builds.
• Het scanresultaat wordt door het beveiligingsteam geanalyseerd op false positives.
• Defecten die door deze beoordeling worden geïdentificeerd, worden gemeld en beheerd tot aan de sluiting, zodat kwel wordt geminimaliseerd / op nul wordt gezet naar het volgende niveau.

Voorbeelden van testscenario's zijn:

• Om ervoor te zorgen dat gevoelige gegevens tijdens de gegevensoverdracht niet in platte tekst worden verzonden.
• Om een ​​veilige gegevensoverdracht te garanderen, moeten naar buiten gerichte API's worden geïmplementeerd op een HTTPS-kanaal.

# 5) Implementatiefase

Dynamische code-analyse is niets anders dan Application Security Testing, ook wel OWASP-testen (Open Web Application Security Project) genoemd. Kwetsbaarheidsanalyse en penetratietesten (VAPT) moeten worden uitgevoerd tijdens de implementatie / testfase.

Deze analyse beoordeelt de binaire bestanden en sommige omgevingsconfiguraties en versterkt de code verder voor de beveiligingsvereisten.

Als onderdeel van deze analyse is het Dynamisch gedrag of functionaliteit van verschillende functies van de programma's worden geanalyseerd op beveiligingsgerelateerde kwetsbaarheden. Bepaalde use cases en bedrijfsscenario's worden ook gebruikt om dynamische code-analyse uit te voeren.

Deze activiteit wordt uitgevoerd op de Test builds met behulp van verschillende beveiligingstools met een geautomatiseerde en handmatige aanpak.

hashtabel c ++ voorbeeld

• HP WebInspect, Burp Suite, ZAP en SOAP UI-tools worden over het algemeen gebruikt om kwetsbaarheden te controleren in standaard kwetsbaarheidsdatabases ( Voorbeeld: OWASP Top 10 ​
• Deze activiteit is echter grotendeels geautomatiseerd, vanwege bepaalde beperkingen van de tools, kan er wat handmatig werk nodig zijn om false positives te traceren.
• Dit gebeurt idealiter op een aparte omgeving (System Testing Environment), waar de testklare software wordt ingezet.
• Kwetsbaarheden moeten aan de orde worden gesteld en met de voorgestelde beperkende maatregelen worden afgesloten.

Typische bedreigingspatronen die tijdens deze analyse worden geïdentificeerd, hebben betrekking op invoervalidatie, defecte authenticatie en sessiebeheer, blootstelling aan gevoelige gegevens, XSS en wachtwoordbeheer.

Voorbeelden van testscenario's zijn:

• Wachtwoordbeheer: Om ervoor te zorgen dat de wachtwoorden niet in platte tekst in de configuratiebestanden of waar dan ook in het systeem worden opgeslagen.
• Systeeminformatie lek: Om ervoor te zorgen dat de systeeminformatie op geen enkel moment wordt gelekt, kan de informatie die door printStackTrace wordt onthuld de tegenstander helpen bij een aanvalsplan.

# 6) Testen - Pre-implementatiefase

Penetratietesten , Pen Test in het kort en Infra VAPT (Kwetsbaarheidsanalyse en penetratietest) , is de complete holistische test met volledige oplossing en configuraties (inclusief netwerk) dat idealiter wordt gedaan op een pre-product- of productieachtige omgeving.

Dit wordt voornamelijk uitgevoerd om de DB-kwetsbaarheden en serverkwetsbaarheden te identificeren, samen met eventuele andere kwetsbaarheden. Dit is de laatste fase van beveiligingstests die zou worden uitgevoerd. Dit omvat dus ook verificatie van eerder gemelde defecten en risico's.

• Tools als Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP die op de markt beschikbaar zijn, worden gebruikt om pentesten uit te voeren.
• Tijdens deze tests worden webapplicaties gescand met behulp van geautomatiseerde tools en geëxploiteerd voor verdere verificatie. Er worden tests uitgevoerd om het gedrag van de echte aanvaller te simuleren en daarom kunnen er ook enkele negatieve tests worden uitgevoerd.
• Kwetsbaarheid van infrastructuur beoordeling omvat scannen, analyse en beoordeling van de beveiligingsconfiguratie van infrastructuur (netwerken, systemen en servers) om de kwetsbaarheden te identificeren en de veerkracht tegen de gerichte aanvallen te controleren.
• Dit gebeurt in een pre-productie of productieachtige omgeving, waar de software, die klaar is voor gebruik, wordt getest en daarmee de real-time omgeving simuleert.
• Kwetsbaarheden worden geïdentificeerd met behulp van zowel scanners als handmatige technieken om valse positieven te elimineren. Tijdens handmatige tests worden ook realtime bedrijfsscenario's uitgevoerd.
• Er zal een eindrapport worden opgesteld over de volledige beveiligingsanalyse die voor het hele programma wordt uitgevoerd, waarin de status van eventuele risicovolle items wordt benadrukt.

Voorbeelden van testscenario's zijn:

• Om ervoor te zorgen dat kwetsbare HTTP-methoden niet zijn ingeschakeld.
• Om ervoor te zorgen dat gevoelige informatie van de andere gebruikers niet zichtbaar is in duidelijke tekst over het netwerk.
• Om ervoor te zorgen dat validatie voor het uploaden van bestanden wordt geïmplementeerd, wordt het uploaden van een schadelijk bestand voorkomen.

Tabeloverzicht voor SSDLC

De onderstaande tabel geeft een overzicht van de verschillende aspecten van beveiligingsanalyse die hierboven worden uitgelegd.

Gevolgtrekking

Dus, met de implementatie van al deze veiligheidsgerelateerde aspecten geïntegreerd in de verschillende fasen van SDLC, helpt het de organisatie om de beveiligingsgebreken vroeg in de cyclus te identificeren en stelt het de organisatie in staat om passende oplossingen te implementeren, waardoor de Beveiligingsfouten met een hoog risico in het Live-systeem.

De studie toont ook aan dat de meeste beveiligingsfouten in de software worden geïnduceerd tijdens de ontwikkelingsfase, dus tijdens de Coderingsfase , waarbij de codering om welke reden dan ook niet voldoende heeft gezorgd voor alle veiligheidsaspecten.

Idealiter zou geen enkele ontwikkelaar een slechte code willen schrijven die de beveiliging in gevaar brengt. Dus om de ontwikkelaars te begeleiden bij het schrijven van een veilige software, behandelt de komende tutorial Best practices en de coderingsrichtlijnen voor ontwikkelaars, om een ​​betere beveiliging van de software te garanderen.

We hopen dat deze tutorial over Secure SDLC of SSDLC nuttig was !!

Aanbevolen literatuur

• SDLC (Software Development Life Cycle) fasen, methodologieën, processen en modellen
• 10 beste tools voor het testen van beveiliging van mobiele apps in 2021
• 19 krachtige penetratietesttools die door professionals worden gebruikt in 2021
• Richtlijnen voor het testen van de beveiliging van mobiele apps
• Netwerkbeveiligingstests en de beste hulpprogramma's voor netwerkbeveiliging
• Beveiligingstests (een complete gids)
• Top 4 Open Source Security Testing Tools om webapplicaties te testen
• Handleiding voor het testen van webapplicaties