DevSecOps-besturingselementen

DevSecOps past innovatiebeveiliging toe door beveiligingsprocessen en hulpprogramma's te integreren in het DevOps-ontwikkelingsproces.

Omdat DevOps zelf een opkomende discipline is met een hoge mate van procesvariaties, is DevSecOps afhankelijk van het begrijpen en zorgvuldig integreren van beveiliging in het ontwikkelingsproces. Het toevoegen van beveiliging moet beginnen met wijzigingen in de code, de ontwikkelingsprocessen en de infrastructuur die als host fungeert voor de workload. Richt u eerst op wijzigingen met het hoogste positieve effect op beveiliging, terwijl u een lage belasting plaatst voor DevOps-processen en -vaardigheden.

In deze documentatie wordt elke fase van een CI/CD DevOps-proces (continue integratie en continue levering) beoordeeld en welke beveiligingsmaatregelen u het beste eerst integreert.

Plannen en ontwikkelen

Moderne ontwikkeling volgt doorgaans een flexibele ontwikkelingsmethodologie. Scrum is één implementatie van agile-methodologie die elke sprint start met een planningsactiviteit. Het introduceren van beveiliging in dit deel van het ontwikkelingsproces moet zich richten op:

• Bedreigingsmodellering om de toepassing te bekijken via de lens van een potentiële aanvaller
• IDE-beveiligingsinvoegtoepassingen en vooraf doorvoerhaken voor lichtgewicht statische analysecontrole binnen een geïntegreerde ontwikkelomgeving (IDE).
• Peerbeoordelingen en veilige coderingsstandaarden om effectieve beveiligingscoderingsstandaarden , peer reviewprocessen en vooraf doorvoerhaakjes te identificeren.

Het is niet verplicht om al deze stappen toe te voegen. Maar elke stap helpt bij het vroegtijdig onthullen van beveiligingsproblemen, wanneer ze veel goedkoper en eenvoudiger te verhelpen zijn.

Bedreigingsmodellen

Bedreigingsmodellering is waarschijnlijk de belangrijkste beveiligingspraktijk. Het levert onmiddellijke resultaten en helpt bij het vaststellen van een beveiligingsmentaliteit in ontwikkelaars om de beveiliging in al hun toekomstige projecten te verbeteren.

Threat modeling is een eenvoudig concept, maar het kan gedetailleerd en technisch zijn als dat nodig is. Bedreigingsmodellering onthult en documenteert een realistische beveiligingsweergave van uw toepassing met:

• Hoe aanvallers het ontwerp van de toepassing kunnen misbruiken
• Beveiligingsproblemen oplossen
• Hoe belangrijk het is om problemen op te lossen

Met threat modeling krijgt u effectief de mindset van een aanvaller. Hiermee kunt u de toepassing zien via de ogen van een aanvaller. U leert hoe u pogingen kunt blokkeren voordat aanvallers er alles aan kunnen doen. Als uw team gebruikerspersoonlijkheden heeft in het ontwerp, kunt u de aanvaller behandelen als vijandige persona van de gebruiker.

Er zijn gepubliceerde benaderingen voor threat modeling die variëren van eenvoudige vraag- en antwoordmethoden tot gedetailleerde analyse op basis van hulpprogramma's. U kunt uw benadering baseren op methodologieën zoals het STRIDE-model of OWASP-bedreigingsmodellering.

Bedreigingsmodellering: eenvoudig starten

Omdat sommige benaderingen voor bedreigingsmodellering tijdrovend en vaardigheidsintensief kunnen zijn, raden we u aan om te beginnen met een eenvoudigere benadering met basisvragen. Eenvoudigere methoden zijn niet zo grondig, maar ze beginnen met het kritieke denkproces en helpen u snel belangrijke beveiligingsproblemen te identificeren.

Met de volgende eenvoudige vragen kunt u aan de slag:

• Eenvoudige vragenmethode van Microsoft: met deze methode worden specifieke technische vragen gesteld die zijn ontworpen om veelvoorkomende beveiligingsontwerpfouten te maken.
• OWASP-bedreigingsmodellering: deze methode is gericht op het stellen van eenvoudige, niet-technische vragen om het threat modeling-proces te starten.

U kunt een of beide methoden gebruiken, afhankelijk van wat beter werkt voor uw team.

Wanneer uw team vertrouwd raakt met het proces, kunnen ze geavanceerdere technieken toepassen vanuit de levenscyclus van Microsoft-beveiligingsontwikkeling. En ze kunnen hulpprogramma's voor bedreigingsmodellering, zoals het hulpprogramma voor bedreigingsmodellering van Microsoft, integreren om meer inzicht te krijgen en het proces te automatiseren.

Een andere nuttige resource is de handleiding voor threat modeling voor ontwikkelaars.

IDE-beveiligingsinvoegtoepassingen en voordoorvoeringshaken

Ontwikkelaars richten zich op de snelheid van levering en beveiligingscontroles kunnen het proces vertragen. Normaal gesproken treedt de vertraging op als de beveiligingscontroles beginnen bij de pijplijn. Een ontwikkelaar vindt meer informatie over het potentiële beveiligingsprobleem nadat de code naar de opslagplaats is gepusht. Om het proces te versnellen en direct feedback te geven, is het de moeite waard om stappen toe te voegen, zoals IDE-beveiligingsinvoegtoepassingen en voordoorvoeringshaken.

IDE-beveiligingsinvoegtoepassingen (Integrated Development Environment) identificeren verschillende beveiligingsproblemen tijdens het ontwikkelingsproces in de vertrouwde IDE-omgeving van de ontwikkelaar. Invoegtoepassingen kunnen direct feedback geven als er een mogelijk beveiligingsrisico bestaat in de geschreven code van de ontwikkelaar. Invoegtoepassingen kunnen ook risico's in de bibliotheek of het pakket van derden blootleggen. Afhankelijk van de IDE die u kiest, zijn er veel opensource- of commerciële invoegtoepassingen beschikbaar en geleverd door beveiligingsbedrijven.

Een andere optie om rekening mee te houden is het gebruik van een framework vooraf doorvoeren als het versiebeheersysteem dit toestaat. Een framework voor vooraf doorvoeren biedt Git-hookscripts waarmee problemen kunnen worden geïdentificeerd voordat een ontwikkelaar code indient voor codebeoordeling. Een voorbeeld is vooraf doorvoeren die u kunt instellen in GitHub.

Standaarden voor peerbeoordeling en veilige codering

Pull-aanvragen zijn standaard in het ontwikkelingsproces. Een deel van het pull-aanvraagproces is peerbeoordelingen die vaak onontdekte defecten, bugs of problemen met betrekking tot menselijke fouten onthullen. Het is een goede gewoonte om een beveiligingskampioen of deskundige beveiligingsteamgenoot te hebben die de ontwikkelaar kan begeleiden tijdens het peerbeoordelingsproces voordat u een pull-aanvraag maakt.

Richtlijnen voor veilige coderingspraktijken helpen ontwikkelaars essentiële principes voor veilig coderen te leren en hoe ze moeten worden toegepast. Er zijn veilige coderingsmethoden beschikbaar, zoals veilige coderingsprocedures van OWASP, die moeten worden opgenomen in algemene coderingsprocedures.

De code doorvoeren

Normaal gesproken maken, beheren en delen ontwikkelaars hun code in opslagplaatsen zoals GitHub of Azure-opslagplaatsen. Deze aanpak biedt een centrale, versiebeheerde bibliotheek met code, zodat ontwikkelaars eenvoudig kunnen samenwerken. Het inschakelen van veel medewerkers op één codebasis loopt echter ook het risico dat er wijzigingen worden geïntroduceerd. Dit risico kan leiden tot beveiligingsproblemen of onbedoeld, waaronder referenties of tokens in doorvoeringen.

Om dit risico te verhelpen, moeten ontwikkelteams een mogelijkheid voor het scannen van opslagplaatsen evalueren en implementeren. Hulpprogramma's voor het scannen van opslagplaatsen voeren statische codeanalyses uit op broncode in opslagplaatsen. De hulpprogramma's zoeken naar beveiligingsproblemen of referentieswijzigingen en markeren items die zijn gevonden voor herstel. Deze mogelijkheid fungeert ter bescherming tegen menselijke fouten en is een nuttige beveiliging voor gedistribueerde teams waar veel mensen samenwerken in dezelfde opslagplaats.

Beheer van afhankelijkheden

Maximaal 90 procent van de code in de huidige toepassingen bevat elementen van of is gebaseerd op externe pakketten en bibliotheken. Met de acceptatie van afhankelijkheden in de broncode is het essentieel om potentiële risico's aan te pakken. Veel bibliotheken van derden hebben ernstige beveiligingsproblemen. Ontwikkelaars volgen ook niet consistent de beste levenscyclus en houden afhankelijkheden up-to-date.

Zorg ervoor dat uw ontwikkelteam weet welke onderdelen in hun toepassingen moeten worden opgenomen. Ze willen veilige en up-to-date versies van bekende bronnen downloaden. En ze willen een proces hebben voor het up-to-date houden van versies. Uw team kan hulpprogramma's gebruiken, zoals het project OWASP Dependency-Check, WhiteSource en andere.

Als u zich alleen wilt richten op beveiligingsproblemen met afhankelijkheden of hun levenscyclus, is dit niet voldoende. Het is ook belangrijk om de beveiliging van pakketfeeds aan te pakken. Er zijn bekende aanvalsvectoren die gericht zijn op pakketbeheersystemen: typfouten, compromitteren van bestaande pakketten, vervangingsaanvallen en andere. Daarom moet het beheer van verantwoordelijke pakketten deze risico's aanpakken. Zie drie manieren om risico's te beperken bij het gebruik van privépakketfeeds voor meer informatie.

Statische toepassingsbeveiligingstests

Nadat uw team bibliotheken en pakketbeheer van derden heeft aangepakt, is het essentieel om de focus te verplaatsen en codebeveiliging te verbeteren. Er zijn verschillende manieren om codebeveiliging te verbeteren. U kunt IDE-beveiligingsinvoegtoepassingen gebruiken. U kunt ook incrementele statische analyse vooraf doorvoeren en doorvoercontroles wireden, zoals eerder besproken. Het is ook mogelijk om een volledige broncodescan uit te voeren om fouten te ondervangen die zijn gemist door eerdere stappen. Het is nodig, maar het kan uren of zelfs dagen duren om een groot codeblok te scannen. Deze aanpak kan dus de ontwikkeling vertragen en last veroorzaken.

Maar een team moet ergens beginnen bij het implementeren van statische codescanprocedures. Een manier is om statische codeanalyse te introduceren binnen continue integratie. Met deze methode wordt de beveiliging gecontroleerd zodra codewijzigingen plaatsvinden. Een voorbeeld is SonarCloud. Het verpakt meerdere SAST-hulpprogramma's (Static Application Security Testing) voor verschillende talen. SonarCloud beoordeelt en houdt technische schulden bij met een focus op onderhoudbaarheid. Het kijkt naar de kwaliteit en stijl van de code en heeft beveiligingsspecifieke controles. Maar er zijn veel andere commerciële en opensource-hulpprogramma's beschikbaar op de markt.

Om ervoor te zorgen dat de feedbacklus effectief is, is het van cruciaal belang om het hulpprogramma af te stemmen. U wilt fout-positieven minimaliseren en duidelijke, bruikbare feedback geven over problemen die moeten worden opgelost. Het is ook handig om een werkstroom te implementeren, waardoor codedoorvoeringen naar de standaardbranch worden voorkomen als er bevindingen zijn. U zou zowel kwaliteits- als beveiligingsresultaten willen behandelen. Beveiliging maakt dus deel uit van de eenheidstestervaring.

Beveiligde pijplijnen

DevOps neemt automatisering naar een ander niveau omdat alles in de ontwikkelingslevenscyclus een pijplijn doorloopt. Continue integratie en continue levering (CI/CD) vormen een belangrijk onderdeel van moderne ontwikkelingscycli. In CI/CD voegt uw team code voor ontwikkelaars samen in een centrale codebasis volgens een regelmatig schema en voert standaard builds en testprocessen automatisch uit.

Infrastructuurpijplijnen vormen een centraal onderdeel van de ontwikkeling. Maar het gebruik van pijplijnen om scripts uit te voeren of code te implementeren in productieomgevingen kan unieke beveiligingsuitdagingen veroorzaken. U wilt ervoor zorgen dat uw CI/CD-pijplijnen geen mogelijkheden worden om schadelijke code uit te voeren, referenties te laten worden gestolen of aanvallers toegang te geven tot het oppervlak. U wilt er ook voor zorgen dat alleen de code die uw team wil vrijgeven en vervolgens implementeert.

DevOps-teams moeten ervoor zorgen dat ze de juiste beveiligingscontroles voor de pijplijn implementeren. Afhankelijk van het gekozen platform zijn er verschillende richtlijnen voor het oplossen van de risico's. Zie Azure Pipelines beveiligen voor meer informatie.

Maken en testen

Veel organisaties gebruiken build- en release-pijplijnen om de processen voor het bouwen en implementeren van code te automatiseren en te standaardiseren. Met releasepijplijnen kunnen ontwikkelteams iteratieve wijzigingen aanbrengen in secties van code snel en op schaal. De teams hoeven geen grote hoeveelheden tijd te besteden aan het opnieuw implementeren of upgraden van bestaande omgevingen.

Met behulp van release-pijplijnen kunnen teams ook code promoten vanuit ontwikkelomgevingen, via testomgevingen en uiteindelijk in productie. Als onderdeel van automatisering moeten ontwikkelteams beveiligingshulpprogramma's bevatten die scripts uitvoeren, geautomatiseerde tests bij het implementeren van code in testomgevingen. De tests moeten eenheidstests bevatten voor toepassingsfuncties om te controleren op beveiligingsproblemen of openbare eindpunten. Testen zorgt voor opzettelijke toegang.

Dynamische toepassingsbeveiligingstests

In een klassiek watervalontwikkelingsmodel werd de beveiliging meestal geïntroduceerd in de laatste stap, vlak voordat u naar productie gaat. Een van de populairste beveiligingsmethoden is penetratietests of pentests. Met penetratietests kan een team de toepassing bekijken vanuit een black-box-beveiligingsperspectief, zoals in, die zich het dichtst bij een aanvaller bevindt.

Een penetratietest bestaat uit verschillende actiepunten, een daarvan is dynamische DAST (Application Security Testing). DAST is een beveiligingstest voor webtoepassingen waarmee beveiligingsproblemen in de actieve toepassing worden gevonden door te zien hoe de toepassing reageert op speciaal gemaakte aanvragen. DAST-hulpprogramma's worden ook wel scanners voor beveiligingsproblemen van webtoepassingen genoemd. Een voorbeeld hiervan is een opensource-hulpprogramma, OWASP Zed Attack Proxy (ZAP). Er worden beveiligingsproblemen gevonden in de actieve webtoepassing. Er zijn verschillende manieren waarop OWASP ZAP-scans: een passieve basislijnscan of een volledige scan, afhankelijk van de configuratie.

Het nadeel van pentesten is dat het tijd kost. Een grondige pentest kan enkele weken duren en met de snelheid van DevOps-ontwikkeling kan dat tijdsbestek onhoudbaar zijn. Maar het is nog steeds de moeite waard om tijdens het ontwikkelproces een lichtere versie van pentests toe te voegen om problemen te ontdekken die zijn gemist door SAST en andere stappen. DAST-hulpprogramma's zoals OWASP ZAP kunnen helpen.

Ontwikkelaars integreren OWASP ZAP in de pijplijn als een taak. Tijdens de uitvoering draait de OWASP ZAP-scanner in de container en voert de scan uit en publiceert vervolgens de resultaten. Deze benadering is misschien niet perfect, omdat het geen volledige penetratietests is, maar het is nog steeds waardevol. Het is nog een kwaliteitsmaatregel in de ontwikkelingscyclus voor het verbeteren van het beveiligingspostuur.

Validatie van cloudconfiguratie en scannen van infrastructuur

Zorg er naast het scannen en beveiligen van de code voor toepassingen voor dat de omgevingen waar u toepassingen in implementeert ook veilig zijn. Veilige omgevingen zijn essentieel voor organisaties die willen overstappen op tempo, innoveren en nieuwe technologieën willen gebruiken. Veilige omgevingen helpen teams ook om snel nieuwe omgevingen te maken voor experimenten.

Met Azure-mogelijkheden kunnen organisaties beveiligingsstandaarden maken op basis van omgevingen, zoals Azure Policy. Teams kan Azure Policy gebruiken om beleidssets te maken. Met de beleidssets wordt voorkomen dat bepaalde workloadtypen of configuratie-items, zoals openbare IP-adressen, worden gemaakt. Met deze kaders kunnen teams experimenteren binnen een veilige en gecontroleerde omgeving, waarbij innovatie en governance in balans worden gehouden.

Een van de manieren waarop DevOps ontwikkelaars en bewerkingen in een stap met elkaar kan brengen, is het converteren van de bestaande infrastructuur naar een benadering van infrastructuur als code.

Infrastructuur als code (IaC) is het beheer van infrastructuur (netwerken, virtuele machines, load balancers en verbindingstopologie) in een beschrijvend model. IaC maakt gebruik van hetzelfde versiebeheermodel als het DevOps-team gebruikt voor broncode. Net als bij het principe van dezelfde broncode wordt hetzelfde binaire bestand gegenereerd, genereert een IaC-model steeds dezelfde omgeving wanneer deze wordt toegepast. IaC is een belangrijke DevOps-praktijk die wordt gebruikt met continue levering.

DevSecOps verschuift de beveiliging naar links en laat zien dat beveiliging niet alleen gaat over toepassingsbeveiliging, maar ook infrastructuurbeveiliging. Een van de manieren waarop DevSecOps infrastructuurbeveiliging ondersteunt, is door beveiligingsscans op te nemen voordat de infrastructuur in de cloud wordt geïmplementeerd. Naarmate de infrastructuur code werd, zou u vervolgens dezelfde beveiligingsacties toepassen op de infrastructuur als de toepassingsbeveiliging. Er zijn beveiligingshulpprogramma's beschikbaar om infrastructuurbeveiligingsscans uit te voeren op basis van uw gekozen IaC-strategie.

Met de acceptatie van de cloud is containerisatie een populaire benadering die teams nemen bij beslissingen over de toepassingsarchitectuur. Sommige containeropslagplaatsen scannen installatiekopieën om pakketten met bekende beveiligingsproblemen te ondervangen. Er is nog steeds een risico dat een container verouderde software kan hebben. Vanwege dit risico is het essentieel om de container te scannen op beveiligingsrisico's. Er zijn tal van opensource- en commerciële beveiligingshulpprogramma's die gericht zijn op dit gebied en ondersteuning bieden voor een nauwe integratie in het CD-proces. Met de beveiligingshulpprogramma's kunnen teams DevSecOps gebruiken voor infrastructuur als code en meer specifiek leren hoe u containers gebruikt.

Naar productie gaan en werken

Wanneer de oplossing naar productie gaat, is het essentieel om toezicht te houden op en de beveiligingsstatus te beheren. In deze fase van het proces is het tijd om te focussen op de cloudinfrastructuur en de algehele toepassing.

Scannen van configuratie en infrastructuur

Voor inzicht in cloudabonnementen en resourceconfiguratie voor meerdere abonnementen gebruikt u de Azure-tenantbeveiligingsoplossing van het AzSK-team.

Azure bevat bewakings- en beveiligingsmogelijkheden. Deze mogelijkheden detecteren en waarschuwen eventuele afwijkende gebeurtenissen of configuraties waarvoor onderzoek en mogelijke herstel nodig zijn. Technologieën zoals Microsoft Defender voor Cloud en Microsoft Sentinel zijn eigen hulpprogramma's die systeemeigen worden geïntegreerd in de Azure-omgevingen. Deze technologieën vormen een aanvulling op de hulpprogramma's voor omgevings- en codebeveiliging. En de technologieën bieden uitgebreide beveiligingsbewaking, zodat organisaties snel en veilig kunnen experimenteren en innoveren.

Indringingstests

Penetratietests zijn een aanbevolen procedure om te controleren op beveiligingsproblemen in de infrastructuur of toepassingsconfiguratie, waardoor aanvallers mogelijk zwakke plekken kunnen misbruiken.

Veel producten en partners bieden penetratietests. Microsoft biedt richtlijnen voor penetratietests in Azure.

Testen omvat doorgaans de volgende testtypen:

• Tests op uw eindpunten om beveiligingsproblemen te ontdekken
• Fuzz-tests (programmafouten vinden door onjuiste invoergegevens op te geven) van uw eindpunten
• Poortscans van uw eindpunten

Bruikbare intelligentie

De hulpprogramma's en technieken in deze richtlijnen bieden een holistisch beveiligingsmodel voor organisaties die willen overstappen en experimenteren met nieuwe technologieën die gericht zijn op innovatie. Een belangrijk element van DevSecOps is gegevensgestuurde, gebeurtenisgestuurde processen. Met deze processen kunnen teams potentiële risico's identificeren, evalueren en erop reageren. Veel organisaties kiezen ervoor om waarschuwingen en gebruiksgegevens te integreren in hun ITSM-platform (IT Service Management). Het team kan vervolgens dezelfde gestructureerde werkstroom overbrengen naar beveiligingsevenementen die ze gebruiken voor andere incidenten en aanvragen.

Feedbacklussen

Al deze technieken en hulpprogramma's stellen teams in staat om risico's en beveiligingsproblemen te vinden en te markeren die onderzoek en mogelijke oplossing vereisen. Operations-teams die een waarschuwing ontvangen of een mogelijk probleem ontdekken wanneer ze een ondersteuningsticket onderzoeken, hebben een route terug naar het ontwikkelteam nodig om items te markeren voor revisie. Een soepele, gezamenlijke feedbacklus is essentieel om problemen snel op te lossen en het risico van een beveiligingsprobleem zoveel mogelijk te minimaliseren.

Een veelvoorkomend patroon voor feedback is om het te integreren in een werkbeheersysteem voor ontwikkelaars, zoals Azure DevOps of GitHub. Een organisatie kan waarschuwingen of incidenten koppelen aan werkitems voor ontwikkelaars om te plannen en actie te ondernemen. Dit proces biedt ontwikkelaars een effectieve manier om problemen in hun standaardwerkstroom op te lossen, waaronder ontwikkeling, testen en release.