Continue zekerheid: een integrale praktijk voor de beveiliging van de softwaretoeleveringsketen

Deze is het tweede in een reeks artikelen waarin de nieuwe NIST SP 800-218-richtlijnen worden onderzocht. Het eerste artikel kan gevonden worden hier.

Continue zekerheid:
Een integrale praktijk voor software supply chain-beveiliging

Zoals we in ons vorige artikel hebben besproken, zullen de richtlijnen van het Amerikaanse National Institute of Standards and Technology (NIST) de manier waarop softwareproducten en -diensten aan de Amerikaanse overheid worden geleverd dramatisch veranderen. 

Specifiek NIST SP 800-218 stelt een reeks veilige softwareontwikkelingspraktijken op hoog niveau vast die moeten worden geïntegreerd in elke Software Development Life Cycle (SDLC). Verwacht wordt dat de integratie van deze praktijken in de hele softwaretoeleveringsketen zal leiden tot veiligere producten en diensten die niet alleen aan de Amerikaanse overheid worden geleverd, maar uiteindelijk aan alle sectoren en over de hele wereld. 

In dit artikel bekijken we de cruciale rol van Continuous Assurance (CA) bij het voldoen aan deze nieuwe vereisten. 

Overzicht: Wat is Continuous Assurance en hoe werkt het? 

CA is een concept en een reeks oplossingen in wording, complementair aan de reeds bekende concepten van Continuous Integration, Development en Testing in de DevOps-discipline. CA verzamelt op gedetailleerde wijze bewijsmateriaal over alle gebeurtenissen in de ontwikkelingslevenscyclus, inclusief de productontwikkeling en de implementatie die van invloed kunnen zijn op de veiligheid van het uiteindelijke softwareproduct. Het is een middel voor consumenten van software (zoals gebruikers, kopers en andere risico-stakeholders) om de risico's van de producten die zij gebruiken te beheersen. 

Tegenwoordig passen ondernemingen een groot aantal beveiligingshulpmiddelen toe om de beveiliging van de softwareproducten die zij ontwikkelen te verbeteren. Ze gebruiken echter zelden een algemeen beleid om de norm te bepalen voor het consistente gebruik van deze tools. Bovendien, als de consumenten van softwareproducten afkomstig zijn van een andere organisatie, beschikken zij niet over de informatie of hulpmiddelen die nodig zijn om de lat voor hun risico te bepalen. In een notendop is dit de blinde vlek van de softwaretoeleveringsketen die CA wil wegnemen. 

Het onmiddellijke resultaat van CA is een middel om ervoor te zorgen dat er niet met softwareproducten is geknoeid en dat er tijdens de ontwikkeling kritische beveiligingsgerelateerde tests zijn uitgevoerd, maar er valt meer uit te halen.

Om het knoeien door aanvallers of het verdoezelen door leveranciers van verborgen componenten van twijfelachtige oorsprong, zoals uit verboden landen, te voorkomen, verandert CA het verzamelde bewijsmateriaal in een fraudebestendig attest door de informatie cryptografisch te ondertekenen en op te slaan in een onveranderlijke opslagplaats in een beveiligde omgeving. een geïsoleerde, veilige omgeving. 

Door het verzamelde bewijsmateriaal machinaal leesbaar te maken, kan een beleidsengine continu de normen of regels valideren die door de risico-stakeholder zijn vastgesteld voor elke productversie of update. Op deze manier kunnen belanghebbenden er zeker van zijn dat een product voldoet aan de beveiligingsnormen. 

Conceptueel gezien verbetert het gebruik van de CA-methodologie ook de productkwaliteit. Door de basisnorm voor codebeoordeling en beveiligingstests te beheersen met een centraal beleid voor de pijplijnen van een bepaald product, zouden inconsistenties en ad-hocwijzigingen in ordelijke processen worden geëlimineerd.

Waarom Continu?

Beveiligingsconfiguraties in het ontwikkelingsproces zijn niets nieuws. U hebt bijvoorbeeld al vastgesteld dat geen enkel binair bestand in productie zal gaan zonder scannen op kwetsbaarheden. 

Tegenwoordig worden de leveringscycli van software steeds korter. Als gevolg hiervan kunnen hoeken worden afgesneden. Het kan zijn dat codebeoordeling wordt overgeslagen, of dat beveiligingstests of belangrijke procedures niet worden uitgevoerd. Bovendien worden er voortdurend nieuwe CVE's en exploits gerapporteerd en worden er voortdurend nieuwe componentversies gepubliceerd. 

Al deze factoren gecombineerd zorgen ervoor dat we voortdurend componenten testen aan de hand van de vastgestelde beveiligingsstandaard om te verifiëren dat de gebruikte processen nog steeds voldoen aan het beveiligingsbeleid. 

Het beveiligingsbeleid wordt bepaald door de risicohouder. Hier volgen enkele voorbeelden van beleidsregels die kunnen worden toegepast: 

• Sta alleen het gebruik van open-sourcepakketten uit een goedgekeurde lijst toe
• Vereist twee reviewers voor elke pull-aanvraag.
• Controleer of alle bedrijfseigen componenten in het uiteindelijke artefact terug te voeren zijn op de bronbeheerrepository's.

De lat voor softwarebeveiliging hoger leggen

Software supply chain-aanvallen veranderen het verwachte gedrag van softwarecomponenten. Tegenwoordig zijn deze aanvallen afhankelijk van het gebrek aan vermogen van zowel softwareconsumenten als -producenten om de integriteit van de softwarecomponenten te verifiëren. 

Door echter bewijsmateriaal uit elk onderdeel van de ontwikkelingscyclus te ondertekenen – van open source-afhankelijkheden tot het eindproduct – en dit bewijsmateriaal voortdurend te vergelijken met wat er wordt verwacht, zullen aanvallers met grotere problemen worden geconfronteerd wanneer ze proberen te knoeien met bestanden, tools of de verwacht gedrag van uw CI/CD-pijplijn.     

Bewijs verzamelen: voorbeelden en aanbevelingen

Hier zijn enkele voorbeelden van bewijsmateriaal dat via de SDLC kan worden verzameld:

En hier zijn de soorten beleid die kunnen worden gebruikt op basis van dit bewijsmateriaal:

De toekomst van continue codegarantie

In het Secure Software Development Framework van februari 2022 (SSDF), suggereert de NIST dat de implementatie van beveiligingstools in het hele ontwikkelingsproces in hoge mate afhankelijk zou moeten zijn van automatisering. Onze benadering van Continuous Assurance is consistent met deze aanbeveling. 

Zelfs als u er zeker van bent dat alle beveiligingsstappen en veiligheidsmaatregelen correct zijn geconfigureerd, moet u nog steeds de middelen bieden om klanten en leveranciers ervan te verzekeren dat uw beveiligingsbeleid consistent en voortdurend wordt gehandhaafd. Alle belanghebbenden, softwareproducenten (ontwikkelaars of verkopers) en consumenten (gebruikers of kopers) moeten het bewijsmateriaal van elke schakel in de softwaretoeleveringsketen voortdurend en automatisch kunnen onderzoeken en verifiëren om er zeker van te zijn dat aan hun eigen beveiligingscriteria wordt voldaan. 

Het vertrouwen in de softwaretoeleveringsketen is momenteel laag, en dit is een constante bron van zorg voor alle belanghebbenden. Het vergroten van de zichtbaarheid van de beveiligingsmaatregelen die zijn geïmplementeerd en het leveren van bewijs van Continuous Code Assurance zijn een integraal onderdeel van het herstel van het vertrouwen in de softwaretoeleveringsketen en het produceren van aantoonbaar veiligere producten.