SolarWinds: Moet beveiliging in InfoSec of DevOps zitten?

De cyberaanval op SolarWinds, ontdekt in december 2020, blijft een van de meest ingrijpende inbreuken op de softwareleveringsketen in de geschiedenis. Aanvallers plaatsten een kwaadaardige backdoor in de Orion-softwarebuildpipeline van SolarWinds, die vervolgens door de eigen codeondertekeningsinfrastructuur van SolarWinds werd ondertekend en als een legitieme update werd verspreid onder ongeveer 18,000 klanten, waaronder belangrijke Amerikaanse overheidsinstanties. De aanval leidde direct tot Executive Order 14028, het NIST Secure Software Development Framework (SSDF) en het Secure by Design-initiatief van CISA, waardoor organisaties anders gingen denken over de beveiliging van buildpipelines, codeondertekeningscontroles en de transparantie van de softwareleveringsketen. Het incident wakkerde ook het debat aan over waar de verantwoordelijkheid voor beveiliging zou moeten liggen: bij een aparte InfoSec-afdeling, bij DevOps-teams of in een geïntegreerd DevSecOps-model. De aanbevolen actie: de SolarWinds-aanval was geen InfoSec-falen of DevOps-falen op zich; het was een integriteitsfout in de buildpipeline die zowel beveiligingsexpertise (om de controles te definiëren) als ontwikkelingsondersteuning (om ze te implementeren) vereiste. Het antwoord is DevSecOps, waarbij InfoSec verantwoordelijk is voor het beleid en de architectuur, en de ontwikkelteams voor de implementatie van dat beleid in de pipeline. Voor het Secure Software Development Framework dat direct uit dit incident is voortgekomen, zie Secure Software Development Framework To Ensure The Correctness Of The Code . Voor codeondertekeningsmechanismen die de integriteit van de buildpipeline beschermen, zie CodeSign Secure.

Kort antwoord: Waar moet de beveiliging na SolarWinds worden ondergebracht?

De SolarWinds-aanval toonde aan dat de vraag InfoSec versus DevOps een valse tegenstelling is. De aanval maakte gebruik van een hiaat dat noch een traditioneel InfoSec-model, noch een DevOps-model zonder beveiligingsintegratie zou hebben gedicht: InfoSec-teams monitoren doorgaans geen build-pipelineprocessen in realtime, en DevOps-teams zonder beveiligingsmaatregelen implementeren standaard geen monitoring van de build-integriteit. De oplossing is een DevSecOps-model, waarbij InfoSec het beveiligingsbeleid, de architectuurstandaarden en de compliance-eisen vaststelt; DevOps implementeert deze eisen via geautomatiseerde beveiligingspoorten in de CI/CD-pipeline; en beide teams delen de verantwoordelijkheid voor de integriteit van de softwareleveringsketen. Codeondertekening met HSM-beveiligde sleutels en monitoring van de integriteit van de buildomgeving zijn de twee controles die het meest direct reageren op het aanvalspatroon van SolarWinds.

De SolarWinds-aanval: wat is er gebeurd?

De cyberaanval op SolarWinds, die in december 2020 werd ontdekt, betrof aanvallers die de Orion-softwarebuildpipeline van SolarWinds hadden gecompromitteerd en een geavanceerde backdoor genaamd SUNBURST in het software-updateproces hadden ingevoegd. Het buildproces compileerde en verpakte de kwaadaardige code vervolgens op de normale manier, waarna de code-ondertekeningsinfrastructuur van SolarWinds de resulterende update ondertekende met geldige SolarWinds-certificaten. Hierdoor was de gecompromitteerde update niet te onderscheiden van een legitieme release. De update werd verspreid onder ongeveer 18,000 SolarWinds-klanten, waaronder het Amerikaanse ministerie van Binnenlandse Veiligheid, het ministerie van Financiën en tal van andere overheidsinstanties en particuliere bedrijven.

De SolarWinds-aanval was een aanval op de toeleveringsketen : de aanvallers richtten zich op een externe softwareleverancier in plaats van op de organisaties zelf, en gebruikten het vertrouwde distributiekanaal van die leverancier om kwaadaardige software aan de klanten van de leverancier te leveren. Deze aanvalsvector is bijzonder effectief omdat klanten geen reden hebben om software-updates te wantrouwen die een geldige handtekening van een vertrouwde leverancier bevatten. De aanval benadrukte het cruciale belang van de beveiliging van de softwaretoeleveringsketen en met name de integriteitscontroles van de build-pipeline die voorkomen dat ongeautoriseerde code wordt ondertekend en gedistribueerd als legitieme software.

InfoSec en DevOps: wat zijn dat?

Voordat we ingaan op de vraag waar beveiliging thuishoort, is het belangrijk om te begrijpen wat InfoSec en DevOps zijn en waarvoor elk model is geoptimaliseerd.

InfoSec (Informatiebeveiliging) omvat het beschermen van informatiesystemen, netwerken en gegevens tegen ongeautoriseerde toegang, gebruik, openbaarmaking, verstoring, wijziging of vernietiging. InfoSec-teams identificeren kwetsbaarheden, ontwikkelen beveiligingsbeleid en geven gebruikers voorlichting over best practices. Ze zijn doorgaans gestructureerd als een functie die toezicht, audits en beleidsbeheer binnen de hele organisatie verzorgt, onafhankelijk van individuele ontwikkelteams of projecten.

DevOps is een benadering van softwareontwikkeling die de nadruk legt op samenwerking en communicatie tussen ontwikkel- en operationele teams. Het doel is om het ontwikkelingsproces te stroomlijnen door taken te automatiseren, code continu te testen en workflows te integreren voor snellere en betrouwbaardere softwarereleases. DevOps-teams zijn direct verantwoordelijk voor de pipeline die software produceert en levert, waardoor zij de logische beheerders zijn van alle beveiligingsmaatregelen die in die pipeline zijn ingebed.

Waar hoort beveiliging thuis: informatiebeveiliging of DevOps?

De SolarWinds-aanval roept de vraag op of beveiliging thuishoort bij InfoSec of DevOps. Sommigen beweren dat beveiliging de verantwoordelijkheid is van InfoSec-teams, terwijl anderen stellen dat beveiliging geïntegreerd moet worden in het DevOps-proces. Beide argumenten zijn terecht, en de realiteit is dat geen van beide modellen op zichzelf SolarWinds had kunnen voorkomen.

Argumenten voor InfoSec

• Focus op risicomanagement

  InfoSec-teams zijn getraind om zich te richten op risicobeheer en het beperken van bedreigingen. Ze hebben een diepgaand begrip van potentiële kwetsbaarheden en bedreigingen en zijn in staat om beleid en procedures te ontwikkelen en te implementeren die tegen die bedreigingen beschermen. Bij aanvallen op de toeleveringsketen bieden InfoSec-teams de expertise op het gebied van bedreigingsmodellering om te herkennen dat de integriteit van de productieketen een beveiligingsrisico vormt en om de benodigde beheersmaatregelen te definiëren om dit aan te pakken.

• Onafhankelijkheid

  InfoSec-teams zijn onafhankelijk van het ontwikkelingsproces, waardoor ze een onbevooroordeeld perspectief op beveiligingskwesties kunnen bieden. Ze staan ​​niet onder druk om ontwikkelingsdeadlines te halen en kunnen prioriteit geven aan beveiligingsaspecten zonder het ontwikkelingsproces in gevaar te brengen. Deze onafhankelijkheid is waardevol wanneer beveiligingsvereisten botsen met de snelheid waarmee producten worden opgeleverd.

Argumenten voor DevOps

• Beveiliging als code

  DevOps-teams zijn verantwoordelijk voor het creëren en implementeren van code, en zijn daarom bij uitstek geschikt om beveiliging in het ontwikkelingsproces te integreren. Door beveiligingsmaatregelen als code in de CI/CD-pipeline op te nemen, kunnen DevOps-teams ervoor zorgen dat beveiliging vanaf het begin in de software is ingebouwd in plaats van achteraf te worden toegevoegd. Integriteitsmonitoring van de buildpipeline, SAST, SCA en het scannen op geheimen worden in de praktijk allemaal door DevOps-teams geïmplementeerd.

• Snellere reactietijden

  DevOps-teams implementeren code snel en efficiënt. Door beveiliging te integreren in het ontwikkelingsproces kunnen ze sneller reageren op beveiligingsproblemen en kwetsbaarheden. Wanneer een CVE wordt gepubliceerd voor een afhankelijkheid, kan een DevOps-team met SCA in de pipeline deze binnen enkele uren detecteren en verhelpen; hetzelfde proces via een aparte InfoSec-gateway kan weken duren.

Beslissingsfactoren: Het juiste model voor effectenbezit kiezen

• Organisatiecultuur

  Afhankelijk van of de organisatie prioriteit geeft aan beveiliging en compliance of aan innovatie en wendbaarheid, kan InfoSec- of DevOps-beheer beter geschikt zijn als primair model. Organisaties met strenge compliance-eisen in de financiële sector en de gezondheidszorg hebben doorgaans een aparte InfoSec-afdeling; organisaties met snelle releasecycli in SaaS integreren beveiliging meestal in DevOps door middel van automatisering.

• Ontwikkelingsmethodologie

  Bij een watervalontwikkelingsmethodologie is een apart InfoSec-team dat fase- en poortbeoordelingen uitvoert wellicht geschikter. Met Agile- of DevOps-methodologieën is het integreren van beveiligingsmaatregelen in de ontwikkelingspipeline door middel van automatisering haalbaarder en effectiever dan periodieke poortbeoordelingen.

• Naleving van de regelgeving

  Als de organisatie moet voldoen aan strenge wettelijke eisen zoals HIPAA, PCI DSS of DORA, is een aparte InfoSec-afdeling met gedocumenteerd beleid en verantwoordelijkheid daarvoor doorgaans noodzakelijk om aan de auditvereisten te voldoen. Een DevOps-model mist mogelijk de formele documentatie en het onafhankelijke auditspoor dat toezichthouders verwachten.

• Vaardigheden en middelen

  Organisaties met een groot, ervaren InfoSec-team profiteren van het benutten van die expertise voor beleidsbeheer en architectuurbeoordeling. Als het InfoSec-team klein is of als de beveiligingsbehoeften snel veranderen (zoals de beveiligingsvereisten voor de toeleveringsketen na SolarWinds), kan het integreren van beveiliging in DevOps door middel van automatisering praktischer zijn dan het uitbreiden van het InfoSec-team.

Beveiligingsmaatregelen voor de toeleveringsketen die SolarWinds verplicht heeft gesteld

De SolarWinds-aanval toonde aan welke specifieke beveiligingsmaatregelen nodig zijn om de softwareontwikkelingspipeline te beschermen, ongeacht of deze onder de verantwoordelijkheid valt van InfoSec, DevOps of een gedeeld model:

• Isolatie en integriteitsbewaking van de bouwomgeving: De buildomgeving moet geïsoleerd zijn van algemene netwerken en worden bewaakt op ongeautoriseerde procesuitvoering of bestandswijziging die kan duiden op een inbreuk op de buildpipeline.
• Codeondertekening met HSM-beveiligde sleutels en dubbele autorisatie: Privésleutels voor codeondertekening moeten worden opgeslagen in FIPS 140-3 gevalideerde HSM's met dubbele autorisatiecontroles, waarbij meerdere goedkeuringen vereist zijn voordat een sleutel kan worden gebruikt. Dit beperkt de mogelijkheid voor een gecompromitteerd buildsysteem om onopgemerkt betrouwbare handtekeningen te produceren. Zie CodeSign Secure voor implementatie
• Genereren van een software-stuklijst (SBOM): Elke software-release moet een SBOM (Software-Based Material Document) bevatten waarin alle componenten en hun herkomst worden gedocumenteerd, zodat defecte componenten snel kunnen worden geïdentificeerd na een inbreuk in de toeleveringsketen.
• Reproduceerbare builds: Het bouwproces moet deterministisch zijn, zodat de gecompileerde uitvoer onafhankelijk kan worden geverifieerd en overeenkomt met de ondertekende broncode.
• Geheime scans in CI/CD: Inloggegevens, API-sleutels en privésleutels moeten worden gescand vanuit repositories en buildomgevingen om te voorkomen dat ze per ongeluk openbaar worden gemaakt via buildartefacten.
• SSDF-conformiteit: Het NIST Secure Software Development Framework, dat rechtstreeks als reactie op SolarWinds is gepubliceerd, biedt het complete praktijkkader voor het aanpakken van al deze beveiligingsmaatregelen. Zie Veilig softwareontwikkelingsframework om de correctheid van de code te garanderen

Updatelogboek

Datum	Evenement / Update
December 2020	Er is een beveiligingslek ontdekt in de toeleveringsketen van SolarWinds Orion; de SUNBURST-achterdeur is geïdentificeerd in een ondertekende update die naar ongeveer 18,000 klanten is verzonden.
mei 2021	Executive Order 14028 ondertekend, waarin federale instanties worden opgedragen de beveiliging van de softwareleveringsketen te verbeteren en softwareleveranciers te verplichten te verklaren dat ze voldoen aan de SSDF-normen.
februari 2022	NIST publiceert SP 800-218 (SSDF), het Secure Software Development Framework, dat zich direct richt op de integriteit van de build-pipeline en de herkomst van softwarecomponenten.
mei 2023	Oorspronkelijke blogpost waarin de kwestie van de verantwoordelijkheid voor beveiliging binnen InfoSec versus DevOps wordt geanalyseerd in de context van SolarWinds.
September 2026 (deze update)	De inhoud is bijgewerkt met diepgaande technische informatie over het SUNBURST-aanvalsmechanisme, beveiligingsmaatregelen in de toeleveringsketen, de beslissingstabel InfoSec versus DevOps, de SSDF-context, het update-logboek en de FAQ-sectie.

Conclusie

De vraag waar beveiliging thuishoort, in InfoSec of DevOps, is niet eenvoudig. Beide benaderingen hebben hun voordelen en de beste aanpak hangt af van de organisatie en haar specifieke context. De SolarWinds-aanval heeft onomstotelijk aangetoond dat noch een traditioneel InfoSec-model met poortwachters, noch een DevOps-pipeline zonder beveiligingsintegratie de aanval had kunnen voorkomen. InfoSec monitorde de build-pipeline niet in realtime; DevOps had geen controles om ongeautoriseerde code-injectie te detecteren vóór het ondertekenen. Het meest effectieve model integreert beide: InfoSec-teams zijn verantwoordelijk voor het beveiligingsbeleid, de architectuurstandaarden en het compliance-toezicht; DevOps-teams implementeren deze standaarden via geautomatiseerde beveiligingspoorten in de CI/CD-pipeline. Dit is DevSecOps, en het is het model dat zowel de diepgang van beveiligingsexpertise als de operationele snelheid biedt die nodig zijn om moderne softwareleveringsketens te beschermen. Voor het NIST-framework dat deze lessen direct vastlegt, zie Secure Software Development Framework To Ensure The Correctness Of The Code . Voor codeondertekening en integriteitscontroles van build-artefacten, zie CodeSign Secure.

Veelgestelde Vragen / FAQ

Wat was de cyberaanval op SolarWinds en hoe werkte die?

De SolarWinds-aanval, ontdekt in december 2020, was een supply chain-aanval waarbij aanvallers de Orion-buildpipeline van SolarWinds compromitteerden en een backdoor (SUNBURST) in het updateproces inbouwden. De backdoor werd normaal gecompileerd en ondertekend door de eigen code-ondertekeningsinfrastructuur van SolarWinds, waardoor de gecompromitteerde update niet te onderscheiden was van een legitieme release. De update werd verspreid onder ongeveer 18,000 klanten, waaronder belangrijke Amerikaanse overheidsinstanties, waardoor aanvallers permanente toegang kregen tot de netwerken van de slachtoffers.

Wat is het verschil tussen InfoSec en DevOps als modellen voor het beheren van beveiliging?

InfoSec-teams zijn gespecialiseerd in beveiligingsbeleid, risicobeoordeling, compliance en beveiligingsmonitoring; ze bieden diepgaande expertise en onafhankelijkheid van de leveringsdruk, maar opereren buiten de ontwikkelingspipeline waar codebeslissingen worden genomen. DevOps-teams beheren de softwareleveringspipeline en zijn in staat om beveiligingsautomatisering daarin te integreren, maar missen doorgaans diepgaande beveiligingsexpertise. DevSecOps integreert beide: InfoSec stelt beleid en architectuur vast, DevOps implementeert dit via geautomatiseerde beveiligingspoorten in de pipeline.

Welke specifieke beveiligingsmaatregelen zouden het risico in de toeleveringsketen, zoals bij SolarWinds, hebben verminderd?

Controles die direct inspelen op risico's in de toeleveringsketen zoals die bij SolarWinds voorkomen, omvatten: monitoring van de integriteit van de buildomgeving om ongeautoriseerde code-injectie vóór ondertekening te detecteren; codeondertekening met HSM-beveiligde sleutels en dubbele autorisatiecontroles; SBOM-generatie voor het traceren van de herkomst van componenten; reproduceerbare builds voor onafhankelijke verificatie; netwerksegmentatie van de buildomgeving; en gedragsmonitoring van build-artefacten. De NIST SSDF (SP 800-218) biedt het praktijkkader dat al deze controles omvat.

Hoe heeft de SolarWinds-aanval de beveiligingspraktijken in de softwaretoeleveringsketen veranderd?

SolarWinds heeft rechtstreeks informatie verstrekt over Executive Order 14028 (mei 2021), NIST SP 800-218 SSDF (februari 2022) en het Secure by Design-initiatief van CISA. Executive Order 14028 verplichtte softwareleveranciers om te bevestigen dat ze voldoen aan de SSDF-normen voor federale aanbestedingen en schreef SBOM-vereisten voor. De aanval is nu hét referentiegeval voor waarom integriteit van de build-pipeline, controle op codeondertekening en transparantie in de toeleveringsketen essentiële elementen zijn van bedrijfsbeveiligingsprogramma's.

Wat is het DevSecOps-model en hoe verschilt het van traditionele InfoSec- of DevOps-beveiligingsmodellen?

DevSecOps integreert beveiliging in de DevOps-pipeline in plaats van het als een aparte controlefunctie te beschouwen. InfoSec is verantwoordelijk voor beleid, architectuur, dreigingsmodellering en compliance; ontwikkelteams zijn verantwoordelijk voor implementatie en herstel; geautomatiseerde beveiligingstests (SAST, DAST, SCA, secret scanning) fungeren als kwaliteitscontrole in het CI/CD-proces met directe feedback. Beveiliging wordt een continu proces in plaats van incidenteel, en zowel InfoSec- als DevOps-teams delen gedefinieerde verantwoordelijkheden op het gebied van beveiliging.