SolarWinds: Bör säkerhet finnas i InfoSec eller DevOps

Cyberattacken mot SolarWinds, som upptäcktes i december 2020, är ​​fortfarande en av de mest betydelsefulla komprometteringarna i mjukvaruleveranskedjan i historien. Angripare infogade en skadlig bakdörr i SolarWinds Orion-pipeline för mjukvaruutveckling, vilken sedan signerades av SolarWinds egen kodsigneringsinfrastruktur och distribuerades som en legitim uppdatering till cirka 18 000 kunder, inklusive stora amerikanska myndigheter. Attacken informerade direkt EO 14028, NIST Secure Software Development Framework (SSDF) och CISA:s Secure by Design-initiativ, och omformade hur organisationer tänker kring säkerhet i byggpipeline, kodsigneringskontroller och synlighet i mjukvaruleveranskedjan. Händelsen intensifierade också debatten om var äganderätten till säkerheten borde ligga: i en separat InfoSec-funktion, i DevOps-team eller i en integrerad DevSecOps-modell. Den rekommenderade åtgärden: SolarWinds-attacken var inte ett InfoSec-fel eller ett DevOps-fel i isolering; det var ett integritetsfel i byggpipeline som krävde både säkerhetsexpertis (för att definiera kontrollerna) och utvecklingsoperationer (för att implementera dem). Svaret är DevSecOps, där InfoSec äger policy och arkitektur, och utvecklingsteamen äger implementeringen av dessa policyer i processen. För det ramverk för säker programvaruutveckling som uppstod direkt ur denna incident, se Säkert ramverk för programvaruutveckling för att säkerställa kodens korrekthet . För kodsigneringskontroller som skyddar integriteten i byggpipelinen, se CodeSign Secure.

Snabbt svar: Var ska säkerheten finnas efter SolarWinds?

SolarWinds-attacken visade att frågan InfoSec kontra DevOps var ett felaktigt val. Attacken utnyttjade en lucka som varken en traditionell InfoSec-modell eller en DevOps-modell utan säkerhetsintegration skulle ha täckt: InfoSec-team övervakar vanligtvis inte byggpipelineprocesser i realtid, och DevOps-team utan säkerhetskontroller implementerar inte byggintegritetsövervakning som standard. Svaret är en DevSecOps-modell där InfoSec sätter säkerhetspolicy, arkitekturstandarder och efterlevnadskrav; DevOps implementerar dessa krav genom automatiserade säkerhetsgrindar i CI/CD-pipelinen; och båda teamen delar ansvaret för programvarans leveranskedjas integritet. Kodsignering med HSM-skyddade nycklar och övervakning av byggmiljöns integritet är de två kontroller som mest direkt reagerar på SolarWinds attackmönster.

SolarWinds-attacken: Vad som hände

SolarWinds cyberattack, som upptäcktes i december 2020, involverade angripare som komprometterade SolarWinds Orion-programvarupipeline och infogade en sofistikerad bakdörr med namnet SUNBURST i programuppdateringsmekanismen. Byggprocessen kompilerade och paketerade sedan den skadliga koden normalt, och SolarWinds kodsigneringsinfrastruktur signerade den resulterande uppdateringen med giltiga SolarWinds-certifikat, vilket gjorde den komprometterade uppdateringen omöjlig att skilja från en legitim utgåva. Uppdateringen distribuerades till cirka 18 000 SolarWinds-kunder, inklusive det amerikanska inrikesdepartementet, finansdepartementet och ett flertal andra myndigheter och privata företag.

SolarWinds-attacken var en leveranskedjeattack : angriparna riktade sig mot en tredjepartsleverantör av programvara snarare än organisationerna själva, och använde leverantörens betrodda distributionskanal för att leverera skadlig programvara till leverantörens kunder. Denna attackvektor är särskilt effektiv eftersom kunder inte har någon anledning att misstro programuppdateringar som har en giltig signatur från en betrodd leverantör. Attacken belyste den kritiska vikten av säkerhet i programvaruleveranskedjan och särskilt integritetskontrollerna för byggpipeline som förhindrar att obehörig kod signeras och distribueras som legitim programvara.

InfoSec och DevOps: Vad är det?

Innan vi tar upp frågan om var säkerhet bör finnas är det viktigt att förstå vad InfoSec och DevOps är och vad varje modell är optimerad för.

InfoSec (informationssäkerhet) innebär att skydda informationssystem, nätverk och data från obehörig åtkomst, användning, avslöjande, störningar, modifieringar eller förstörelse. InfoSec-team identifierar sårbarheter, utvecklar säkerhetspolicyer och utbildar användare om bästa praxis. De är vanligtvis strukturerade som en funktion som tillhandahåller tillsyn, revision och policystyrning i hela organisationen, oberoende av enskilda utvecklingsteam eller projekt.

DevOps är en metod för mjukvaruutveckling som betonar samarbete och kommunikation mellan utvecklings- och driftteam. Syftet är att effektivisera utvecklingsprocessen genom att automatisera uppgifter, kontinuerligt testa kod och integrera arbetsflöden för snabbare och mer tillförlitliga programvarusläpp. DevOps-team är direkt ansvariga för den pipeline som producerar och levererar programvara, vilket gör dem till de logiska ägarna av alla säkerhetskontroller som är inbäddade i den pipelinen.

Var bör säkerheten finnas: InfoSec eller DevOps?

SolarWinds -attacken väcker frågan om säkerheten bör ligga i InfoSec eller DevOps. Vissa menar att säkerheten bör vara InfoSec-teamens ansvar, medan andra menar att säkerheten bör integreras i DevOps-processen. Båda argumenten har meriter, och verkligheten är att ingen av modellerna ensamma skulle ha förhindrat SolarWinds.

Argument för informationssäkerhet

• Fokus på riskhantering

  InfoSec-team är utbildade för att fokusera på riskhantering och hotreducering. De har en djup förståelse för potentiella sårbarheter och hot, och de är utrustade för att utveckla och implementera de policyer och procedurer som skyddar mot dessa hot. För attacker i leveranskedjan tillhandahåller InfoSec-team den expertis som krävs för att modellera hot för att inse att integritet i byggpipelines är ett säkerhetsproblem och för att definiera de kontroller som behövs för att hantera det.

• Oberoende

  InfoSec-team är oberoende av utvecklingsprocessen, vilket gör att de kan ge ett opartiskt perspektiv på säkerhetsfrågor. De är inte utsatta för pressen att möta utvecklingsdeadlines och kan prioritera säkerhetsproblem utan att kompromissa med utvecklingsprocessen. Denna oberoende är värdefull när säkerhetskrav står i konflikt med leveranshastigheten.

Argument för DevOps

• Säkerhet som kod

  DevOps-team ansvarar för att skapa och driftsätta kod, så de är bäst positionerade för att integrera säkerhet i utvecklingsprocessen. Genom att integrera säkerhetskontroller i CI/CD-pipelinen som kod kan DevOps-team säkerställa att säkerhet är inbyggd i programvaran från början snarare än att läggas till som en eftertanke. Integritetsövervakning av byggpipeline, SAST, SCA och hemlig skanning implementeras alla av DevOps-team i praktiken.

• Snabbare svarstider

  DevOps-team distribuerar kod snabbt och effektivt. Genom att integrera säkerhet i utvecklingsprocessen kan de reagera snabbare på säkerhetsproblem och sårbarheter. När en CVE publiceras i ett beroende kan ett DevOps-team med SCA i pipeline upptäcka och åtgärda den på några timmar; samma process genom en separat InfoSec-grind kan ta veckor.

Beslutsfaktorer: Att välja rätt modell för värdepappersägande

• Organisationskultur

  Beroende på om organisationen prioriterar säkerhet och efterlevnad eller innovation och flexibilitet kan antingen InfoSec- eller DevOps-ägarskap vara bättre lämpat som primär modell. Organisationer med starka efterlevnadskrav inom finans och hälso- och sjukvård har vanligtvis en dedikerad InfoSec-funktion; organisationer med snabba releasecykler i SaaS bäddar vanligtvis in säkerhet i DevOps genom automatisering.

• Utvecklingsmetodik

  I en vattenfallsutvecklingsmetodik kan ett separat InfoSec-team som tillhandahåller granskningar i olika steg vara mer lämpligt. Med agila eller DevOps-metoder är det mer genomförbart och effektivt att integrera säkerhetsåtgärder i utvecklingsprocessen genom automatisering än regelbundna granskningar.

• Regelefterlevnad

  Om organisationen måste följa strikta myndighetskrav som HIPAA, PCI DSS eller DORA, är en separat InfoSec-funktion med dokumenterat policyägarskap vanligtvis nödvändig för att uppfylla revisionskraven. En DevOps-modell kan sakna den formella dokumentation och oberoende revisionsspårning som tillsynsmyndigheter förväntar sig.

• Kompetens och resurser

  Organisationer med ett stort, erfaret InfoSec-team drar nytta av att utnyttja den expertisen för policystyrning och arkitekturgranskning. Om InfoSec-teamet är litet eller om säkerhetsbehoven utvecklas snabbt (som med säkerhetskrav för leveranskedjan efter SolarWinds) kan det vara mer praktiskt att integrera säkerhet i DevOps genom automatisering än att skala upp antalet InfoSec-personal.

Säkerhetskontroller i leveranskedjan som SolarWinds gjorde obligatoriska

SolarWinds-attacken demonstrerade de specifika kontroller som behövs för att skydda programvaruutvecklingspipelinen, oavsett om de ägs av InfoSec, DevOps eller en delad modell:

• Isolering av byggmiljö och integritetsövervakning: Byggmiljön bör isoleras från allmänna nätverk och övervakas för obehörig processkörning eller filmodifiering som kan indikera en kompromiss mellan byggpipeline och system.
• Kodsignering med HSM-skyddade nycklar och dubbel auktorisering: Privata nycklar för kodsignering bör lagras i FIPS 140-3-validerade HSM:er med dubbla auktoriseringskontroller som kräver flera godkännanden innan en nyckel kan användas; detta begränsar möjligheten för ett komprometterat byggsystem att producera betrodda signaturer utan detektering. Se CodeSign Secure för genomförande
• Generering av programvaruförteckning (SBOM): Varje programvaruversion bör innehålla en SBOM som dokumenterar alla komponenter och deras ursprung, vilket möjliggör snabb identifiering av komprometterade komponenter efter ett intrång i leveranskedjan.
• Reproducerbara byggen: Byggprocesser bör vara deterministiska så att den kompilerade utdata kan verifieras oberoende för att matcha den signerade källkoden.
• Hemlig skanning i CI/CD: Inloggningsuppgifter, API-nycklar och privat nyckelmaterial bör skannas från arkiv och byggmiljöer för att förhindra att de oavsiktligt exponeras genom byggartefakter.
• SSDF-efterlevnad: NIST:s ramverk för säker programvaruutveckling, publicerat som ett direkt svar på SolarWinds, tillhandahåller ett komplett ramverk för att hantera alla dessa kontroller. Se Säkert ramverk för mjukvaruutveckling för att säkerställa kodens korrekthet

Uppdateringslogg

Datum	Händelse / Uppdatering
december 2020	SolarWinds Orions leveranskedja upptäckt; SUNBURST-bakdörr identifierad i signerad uppdatering som distribuerats till cirka 18 000 kunder
Maj 2021	EO 14028 undertecknad, som instruerar federala myndigheter att förbättra säkerheten i programvaruleveranskedjan och kräver att programvaruleverantörer intygar SSDF-efterlevnad
februari 2022	NIST publicerar SP 800-218 (SSDF), Secure Software Development Framework, som direkt behandlar integriteten i byggpipelinen och varifrån mjukvarukomponenter kommer.
Maj 2023	Ursprungligt blogginlägg publicerat som analyserar frågan om äganderätt till InfoSec kontra DevOps-säkerhet i samband med SolarWinds
September 2026 (denna uppdatering)	Innehåll uppdaterat med teknisk djupgående information om SUNBURST-attackmekanismen, säkerhetskontroller för leveranskedjan, beslutstabellen InfoSec vs DevOps, SSDF-kontext, uppdateringslogg och FAQ-sektion

Slutsats

Frågan om var säkerheten ska finnas, i InfoSec eller DevOps, är inte enkel. Båda metoderna har fördelar, och det bästa tillvägagångssättet beror på organisationen och dess specifika sammanhang. Vad SolarWinds-attacken definitivt visade är att varken en traditionell InfoSec-gatekeepingmodell eller en DevOps-pipeline utan säkerhetsintegration skulle ha förhindrat det. InfoSec övervakade inte byggpipelinen i realtid; DevOps hade inga kontroller för att upptäcka obehörig kodinjicering före signering. Den mest effektiva modellen integrerar båda: InfoSec-teamens egen säkerhetspolicy, arkitekturstandarder och efterlevnadsövervakning; DevOps-team implementerar dessa standarder genom automatiserade säkerhetsgrindar i CI/CD-pipelinen. Detta är DevSecOps, och det är modellen som ger både det djup av säkerhetsexpertis och den operativa hastighet som behövs för att skydda moderna programvaruleveranskedjor. För NIST-ramverket som direkt kodifierar dessa lärdomar, se Secure Software Development Framework To Ensure The Correctness Of The Code . För kodsignering och integritetskontroller för byggartefakter, se CodeSign Secure.

Vanliga frågor om partihandel med mat och dryck

Vad var SolarWinds cyberattack och hur fungerade den?

SolarWinds-attacken, som upptäcktes i december 2020, var en leveranskedjeattack där angripare komprometterade SolarWinds Orion-pipeline och infogade en bakdörr (SUNBURST) i uppdateringsmekanismen. Bakdörren kompilerades normalt och signerades av SolarWinds egen kodsigneringsinfrastruktur, vilket gjorde den komprometterade uppdateringen omöjlig att skilja från en legitim utgåva. Den distribuerades till cirka 18 000 kunder, inklusive stora amerikanska myndigheter, vilket gav angriparna permanent åtkomst till offrens nätverk.

Vad är skillnaden mellan InfoSec och DevOps som modeller för att äga säkerhet?

InfoSec-team specialiserar sig på säkerhetspolicy, riskbedömning, efterlevnad och säkerhetsövervakning; de erbjuder djupgående expertis och är oberoende av leveranstryck, men arbetar utanför utvecklingsprocessen där kodbeslut fattas. DevOps-team äger leveransprocessen för programvara och är positionerade för att integrera säkerhetsautomation där, men saknar vanligtvis djupgående säkerhetsexpertis. DevSecOps integrerar båda: InfoSec sätter policy och arkitektur, DevOps implementerar den genom automatiserade säkerhetsgrindar i processen.

Vilka specifika säkerhetsåtgärder skulle ha minskat risken i leveranskedjan av SolarWinds-typ?

Kontroller som direkt adresserar risker i leveranskedjan i SolarWinds-stil inkluderar: integritetsövervakning av byggmiljön för att upptäcka obehörig kodinjicering före signering; kodsignering med HSM-skyddade nycklar och kontroller med dubbel auktorisering; SBOM-generering för spårning av komponenters proveniens; reproducerbara byggen för oberoende verifiering; nätverkssegmentering av byggmiljön; och beteendeövervakning av byggartefakter. NIST SSDF (SP 800-218) tillhandahåller det praxisramverk som hanterar alla dessa kontroller.

Hur förändrade SolarWinds-attacken säkerhetsrutiner för mjukvaruleveranskedjan?

SolarWinds informerade direkt om EO 14028 (maj 2021), NIST SP 800-218 SSDF (februari 2022) och CISA:s Secure by Design-initiativ. EO 14028 krävde att programvaruleverantörer intygade SSDF-efterlevnad för federal upphandling och obligatoriska SBOM-krav. Attacken är nu det kanoniska referensargumentet för varför integritet i byggpipeliner, kodsigneringskontroller och synlighet i leveranskedjan är viktiga delar av företagssäkerhetsprogram.

Vad är DevSecOps-modellen och hur skiljer den sig från traditionella InfoSec- eller DevOps-säkerhetsmodeller?

DevSecOps integrerar säkerhet i DevOps-pipelinen snarare än att behandla den som en separat grindvaktningsfunktion. InfoSec äger policy, arkitektur, hotmodellering och efterlevnadsövervakning; utvecklingsteamen äger implementering och åtgärd; automatiserad säkerhetstestning (SAST, DAST, SCA, hemlig skanning) körs som en CI/CD-kvalitetsgrind med omedelbar feedback. Säkerheten blir kontinuerlig snarare än episodisk, och både InfoSec- och DevOps-teamen delar definierade säkerhetsansvar.