Het integreren van beveiliging in het kenmerk tijdens de ontwerpfase

Het is opwindend hoe verschillende disciplines kunnen worden samengevoegd om de processen efficiënter te maken. In 2009 werd DevOps geïntroduceerd om de wrijving tussen de ontwikkelings- en operationele teams aan te pakken. Als gevolg hiervan bewoog de industrie zich naar het samenvoegen van beide teams, zodat het ontwikkelingsteam verantwoordelijk was voor de gehele cyclus, van het schrijven van code tot de productie-implementatie. Natuurlijk, wie zou de intricaties beter begrijpen dan de mensen die ze hebben ontwikkeld?

Na deze verschuiving hebben we gezien dat functies snel werden opgeleverd en dat de time-to-market voor nieuwe functies snel daalde. DevOps diende ook als basis voor vele andere praktijken zoals MLOps, DataOps, GitOps, en ongetwijfeld zijn er nog veel meer ontstaan.

Vandaag zullen we het hebben over een dergelijke praktijk waarmee velen van jullie misschien bekend zijn, genaamd DevSecOps (Development Security Operations). Dus, wat is DevSecOps?

Beveiliging is traditioneel behandeld als een bijzaak, met teams die eerst functies naar productie verzonden en vervolgens snel moesten proberen beveiligingsmaatregelen te implementeren tijdens een beveiligingsreview of een incident. Met de toename van cyberbeveiliging, supply chain en andere geavanceerde aanvallen, realiseerde de industrie zich snel dat, net als ontwikkeling en operaties, beveiliging ook deel uit zou moeten maken van het proces. Het moet zo vroeg mogelijk in de ontwikkelingscyclus worden ingebed, omdat het later aanpakken van beveiliging duur kan zijn (zowel vanuit architectuur- als operationeel perspectief).

Laten we nu bespreken hoe dit kan worden toegepast in verschillende fasen van onze ontwikkelingscyclus, zodat de code die we verzenden niet alleen efficiënt maar ook veilig is.

Gewoonlijk houdt het proces van het verzenden van een functie in:

1. Ontwikkeling – waar de functie wordt gebouwd
2. Distributie – waar de artefacten worden gemaakt en voorbereid voor levering
3. Implementatie – waar de functie wordt vrijgegeven in de productieomgeving

Laten we de stappen bespreken die we kunnen nemen om de beveiligingshouding van de functie die we bouwen tijdens de ontwikkelingsfase te verbeteren.

In de ontwikkelingsfase doorloopt een functie een ontwerpreview, codering en vervolgens een pull request review. Als onderdeel van de ontwerpreview bespreekt de functieleider hoe de API-contracten eruitzien, welke databases we gebruiken, indexering, cachingstrategieën, gebruikerservaring, enzovoort (geen uitputtende lijst). In een security-first cultuur is het ook belangrijk om dreigingsmodellering uit te voeren.

Voer Dreigingsmodellering uit

Gewoongezegd, dreigingsmodellering is “het proces van het identificeren van kwetsbaarheden, het uitvoeren van een risicoanalyse en het implementeren van de aanbevolen mitigaties zodat de beveiligingshouding van de producten/organisaties niet in gevaar komt.”

Laten we een voorbeeld nemen om dit te begrijpen. Stel je voor dat je een API ontwikkelt die:

• Producten in je productcatalogus opsomt.
• Zoekt naar een product of producttype.

GET /api/products?search=laptop

​

Een dreigingsmodel kan er als volgt uitzien:

Dit zijn dingen waar we aan kunnen denken bij het bekijken van de product-eindpunten. Het beste is dat je geen beveiligingsexpert hoeft te zijn om deze kwetsbaarheden te herkennen.

Tools zoals Microsoft Threat Modeling-tools en OWASP Threat Dragons kunnen helpen ze te identificeren.

Voorbeeld van een Dreigingsmodel in de Microsoft Threat Modeling Tool

Analyseweergave

De analyseweergave van de dreigingsmodelleringstool toont verschillende aanvallen die op de API kunnen plaatsvinden.

Het beoordelen van het dreigingsmodel met je team kan fungeren als een brainstormsessie om zoveel mogelijk beveiligingshiaten te identificeren en te verhelpen.

• Zwakke cryptografische methoden. Bijvoorbeeld, het gebruik van SHA1 of MD5 wordt als zwak beschouwd.CA530 is een voorbeeld van een waarschuwing die C# genereert wanneer er zwakke hashfuncties in de code worden gebruikt.
• SQL-injectieaanvallen. CA2100 controleert bijvoorbeeld of de code vatbaar is voor injectieaanvallen
• Hardgecodeerde wachtwoorden, zwakke authenticatie- en autorisatiemechanismen, en misconfiguraties van de infrastructuur kunnen ook worden gedetecteerd met statische analyzers.

Er zijn ook bestaande tools in deze ruimte. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check, en Snyk hebben enkele geweldige aanbiedingen in deze ruimte.

Het integreren van statische analyse in build-pijplijnen is ook belangrijk. Het biedt voordelen zoals:

• Een consistente ervaring in het detecteren van kwetsbaarheden voor uw ontwikkelaars.
• Verbetert de beveiligingshouding van uw dienst omdat elke productie-implementatie door deze stappen moet gaan.

Codebeoordelingen vanuit een beveiligingsperspectief

Hoewel codebeoordelingen traditioneel gericht zijn op het identificeren van bugs en het waarborgen van best practices, is het belangrijk om het ook vanuit een beveiligingsperspectief te evalueren ook. Door de beveiligingsimplicaties van elke pull request te overwegen, kunt u proactief toekomstige bedreigingen voorkomen en de integriteit van uw applicatie waarborgen.

Conclusie

Samenvattend is het met de toenemende complexiteit in het cybersecurity-landschap belangrijk om beveiliging in de vroege fasen te overwegen in plaats van het tot het einde te laten. Als onderdeel van dat, voeg dreigingsmodellering en geautomatiseerde statische analyse toe aan je reguliere ontwikkelingscyclus.

In de komende artikelen zullen we bespreken welke beveiligingspraktijken we kunnen opnemen tijdens distributie, wat inhoudt dat containerafbeeldingen worden gescand, dynamische applicatiebeveiligingstests (DAST) en artefactondertekening om de service te beschermen tegen aanvallen op de supply chain.