Beveiligingspostuur voor DevOps-omgeving

Voltooid

Met een toename van cyberaanvallen op broncodebeheersystemen en continue integratie/continue leveringspijplijnen, is het beveiligen van DevOps-platforms tegen het diverse aantal bedreigingen dat is geïdentificeerd in de DevOps Threat Matrix cruciaal. Dergelijke cyberaanvallen kunnen code-injectie, escalatie van bevoegdheden en gegevensexfiltratie mogelijk maken, wat kan leiden tot een grote impact.

DevOps-postuurbeheer is een functie in Microsoft Defender voor Cloud die:

• Biedt inzicht in de beveiligingspostuur van de volledige levenscyclus van de software-toeleveringsketen.
• Maakt gebruik van geavanceerde scanners voor diepgaande evaluaties.
• Behandelt verschillende resources, van organisaties, pijplijnen en opslagplaatsen.
• Hiermee kunnen klanten hun kwetsbaarheid voor aanvallen verminderen door de verstrekte aanbevelingen bloot te leggen en erop te reageren.

DevOps-scanners

DevOps-houdingsbeheer maakt gebruik van DevOps-scanners om zwakke plekken in broncodebeheer en continue integratie/continue leveringspijplijnen te identificeren door controles uit te voeren op basis van de beveiligingsconfiguraties en toegangsbeheer.

Azure DevOps- en GitHub-scanners worden intern in Microsoft gebruikt om risico's te identificeren die zijn gekoppeld aan DevOps-resources, waardoor de kwetsbaarheid voor aanvallen wordt verminderd en bedrijfs DevOps-systemen worden versterkt.

Zodra een DevOps-omgeving is verbonden, Defender voor Cloud deze scanners automatisch configureert om elke 24 uur terugkerende scans uit te voeren op meerdere DevOps-resources, waaronder:

• Builds
  
• Beveiligde bestanden
• Variabelegroepen
• Serviceverbindingen
• Organisaties
• Opslagplaatsen

Risicobeperking devOps-bedreigingsmatrix

DevOps-houdingsbeheer helpt organisaties bij het detecteren en herstellen van schadelijke onjuiste configuraties in het DevOps-platform. Dit leidt tot een tolerante DevOps-omgeving met nul vertrouwen, die wordt versterkt tegen een reeks bedreigingen die zijn gedefinieerd in de DevOps-bedreigingsmatrix. De primaire besturingselementen voor postuurbeheer zijn onder andere:

• Geheime toegang binnen het bereik: minimaliseer de blootstelling van gevoelige informatie en verminder het risico op onbevoegde toegang, gegevenslekken en zijdelingse verplaatsingen door ervoor te zorgen dat elke pijplijn alleen toegang heeft tot de geheimen die essentieel zijn voor de functie ervan.
  
• Beperking van zelf-hostende runners en hoge machtigingen: voorkom niet-geautoriseerde uitvoeringen en mogelijke escalaties door zelf-hostende runners te voorkomen en ervoor te zorgen dat pijplijnmachtigingen standaard alleen-lezen zijn.
  
• Verbeterde vertakkingsbeveiliging: behoud de integriteit van de code door vertakkingsbeveiligingsregels af te dwingen en schadelijke code-injecties te voorkomen.
  
• Geoptimaliseerde machtigingen en beveiligde opslagplaatsen: verminder het risico op onbevoegde toegang, wijzigingen door minimale basismachtigingen bij te houden en het inschakelen van geheime pushbeveiliging voor opslagplaatsen.
  

DevOps-bedreigingsmatrix

Ons doel voor het ontwikkelen van de bedreigingsmatrix voor DevOps is het bouwen van een uitgebreide knowledgebase die Defenders kan gebruiken om verdediging tegen relevante aanvalstechnieken bij te houden en te bouwen. Met behulp van het MITRE ATT&CK-framework als basis hebben we technieken en aanvalsvectoren verzameld die zijn gekoppeld aan DevOps-omgevingen en hebben we een matrix gemaakt die is toegewezen aan DevOps-aanvalsmethoden.

Het is de moeite waard om te vermelden dat de tactieken in deze matrix vanuit het devOps-perspectief moeten worden bekeken. Uitvoeringstechnieken in een virtuele machine met Windows- of Linux-besturingssysteem verschillen bijvoorbeeld van de uitvoering in een DevOps-pijplijn. In het Linux-geval betekent de uitvoering het uitvoeren van code in het besturingssysteem. Wanneer we het hebben over DevOps-omgevingen, betekent dit het uitvoeren van code in de pijplijn of DevOps-resources. Naast het gebruik van deze bedreigingsmatrix om aanvallen en bijbehorende verdedigingsmethoden te categoriseren, kunnen Defenders samen met rode teams continu veronderstellingen testen en nieuwe mogelijke aanvalstechnieken vinden.

MITRE ATT&CK gedefinieerd

De MITRE ATT&CK-matrix is een openbaar toegankelijke knowledge base voor het begrijpen van de verschillende tactieken en technieken die door aanvallers worden gebruikt tijdens een cyberaanval.

De knowledge base is ingedeeld in verschillende categorieën: pre-aanval, initiële toegang, uitvoering, persistentie, escalatie van bevoegdheden, verdedigingsontduiking, toegang tot referenties, detectie, laterale verplaatsing, verzameling, exfiltratie en opdracht en controle.

Tactieken (T) vertegenwoordigen de 'waarom' van een ATT&CK-techniek of subtechniek. Het is het tactische doel van de aanvaller: de reden voor het uitvoeren van een actie. Een kwaadwillende persoon wil bijvoorbeeld toegang tot referenties verkrijgen.

Technieken (T) vertegenwoordigen 'hoe'' een kwaadwillende persoon een tactisch doel bereikt door een actie uit te voeren. Een kwaadwillende persoon kan bijvoorbeeld referenties dumpen om toegang tot referenties te verkrijgen.

Common Knowledge (CK) in ATT&CK staat voor algemene kennis, in wezen de gedocumenteerde modusoperandi van tactieken en technieken die worden uitgevoerd door aanvallers.

Initial Access

De eerste toegangstactiek verwijst naar technieken die een aanvaller kan gebruiken voor het verkrijgen van toegang tot de DevOps-resources: opslagplaatsen, pijplijnen en afhankelijkheden. De volgende technieken kunnen een voorwaarde zijn voor de volgende stappen:

SCM-verificatie (Broncodebeheer): toegang door een verificatiemethode te hebben voor het broncodebeheer van de organisatie. Het kan een persoonlijk toegangstoken (PAT), een SSH-sleutel of een andere toegestane verificatiereferentie zijn. Een voorbeeld van een methode die een aanvaller kan gebruiken om deze techniek te bereiken, is het gebruik van een phishing-aanval tegen een organisatie.

Continue integratie (CI) en CD-serviceverificatie (Continuous Integration), vergelijkbaar met SCM-verificatie, kan een aanvaller gebruikmaken van verificatie bij de CI/CD-service om de DevOps van de organisatie aan te vallen.

Openbare opslagplaatsen van de organisatie: toegang tot de openbare opslagplaatsen van de organisatie die zijn geconfigureerd met CI/CD-mogelijkheden. Afhankelijk van de configuratie van de organisatie kunnen deze opslagplaatsen een pijplijnuitvoering activeren nadat een pull-aanvraag (PR) is gemaakt.

Eindpuntinbreuk: met behulp van een bestaand compromis kan een aanvaller gebruikmaken van het werkstation van de ontwikkelaar en zo toegang krijgen tot de SCM, het register van de organisatie of een andere resource waar de ontwikkelaar toegang toe heeft.

Geconfigureerde webhooks: wanneer een organisatie een webhook heeft geconfigureerd, kan een aanvaller deze gebruiken als een initiële toegangsmethode in het netwerk van de organisatie door de SCM zelf te gebruiken om aanvragen in dat netwerk te activeren. Dit kan de aanvaller toegang verlenen tot services die niet openbaar moeten worden gemaakt of die oude en kwetsbare softwareversies in het particuliere netwerk uitvoeren.

Uitvoering.

De uitvoeringstactiek verwijst naar technieken die kunnen worden gebruikt door een kwaadwillende kwaadwillende aanvaller om uitvoeringstoegang te krijgen tot pijplijnbronnen: de pijplijn zelf of de implementatiebronnen. Sommige van de technieken in deze sectie bevatten uitleg over de verschillende manieren om ze uit te voeren, of wat we subtechnieken noemen:

Gifpijplijnuitvoering (PPE): verwijst naar een techniek waarbij een aanvaller code kan injecteren in de opslagplaats van een organisatie, wat resulteert in de uitvoering van code in het CI/CD-systeem van de opslagplaats. Er zijn verschillende subtechnieken voor het uitvoeren van code:

• Direct PPE (d-PPE): gevallen waarin de aanvaller het configuratiebestand rechtstreeks in de opslagplaats kan wijzigen. Omdat de pijplijn wordt geactiveerd door een nieuwe pull-aanvraag en wordt uitgevoerd volgens het configuratiebestand, kan de aanvaller schadelijke opdrachten naar het configuratiebestand injecteren en worden deze opdrachten uitgevoerd in de pijplijn.
  
• Indirecte PBM (i-PPE): gevallen waarin de aanvaller de configuratiebestanden niet rechtstreeks kan wijzigen of waarbij deze wijzigingen niet in aanmerking worden genomen wanneer deze worden geactiveerd. In dergelijke gevallen kan de aanvaller scripts infecteren die door de pijplijn worden gebruikt om code uit te voeren, bijvoorbeeld make-files, testscripts, buildscripts, enzovoort.
• Openbare PBM: gevallen waarin de pijplijn wordt geactiveerd door een opensource-project. In deze gevallen kan de aanvaller d-PPE of i-PPE in de openbare opslagplaats gebruiken om de pijplijn te infecteren.

Manipulatie van afhankelijkheden: verwijst naar een techniek waarbij een aanvaller code kan uitvoeren in de DevOps-omgeving of productieomgeving door schadelijke code in de afhankelijkheden van een opslagplaats te injecteren. Wanneer de afhankelijkheid wordt gedownload, wordt de schadelijke code dus uitgevoerd. Enkele subtechnieken die kunnen worden gebruikt voor het uitvoeren van code, zijn onder andere:

• Verwarring over openbare afhankelijkheid: een techniek waarbij de kwaadwillende persoon openbare schadelijke pakketten publiceert met dezelfde naam als privépakketten. In dit geval wordt het schadelijke pakket gedownload, omdat het zoeken in pakketbeheermechanismen meestal eerst in openbare registers wordt weergegeven.
• Openbare pakketkaap ('repo-jacking'): hijacking van een openbaar pakket door de controle over het onderhouder-account te nemen, bijvoorbeeld door de naam van de GitHub-gebruiker te benutten.
• Typosquatting : schadelijke pakketten publiceren met vergelijkbare namen als bekende openbare pakketten. Op deze manier kan een aanvaller gebruikers verwarren om het schadelijke pakket te downloaden in plaats van het gewenste pakket.

Inbreuk op DevOps-resources: pijplijnen zijn, in de kern, een set rekenresources die de CI/CD-agents uitvoeren, naast andere software. Een aanvaller kan zich op deze resources richten door misbruik te maken van een beveiligingsprobleem in het besturingssysteem, de code van de agent, andere software die is geïnstalleerd op de VM's of andere apparaten in het netwerk om toegang te krijgen tot de pijplijn.

Beheer van algemeen register: een aanvaller kan controle krijgen over een register dat door de organisatie wordt gebruikt, wat resulteert in schadelijke installatiekopieën of pakketten die worden uitgevoerd door de pijplijn-VM's of productie-VM's.

Persistentie

De persistentietactiek bestaat uit verschillende technieken die een aanvaller kan gebruiken voor het onderhouden van de toegang tot een slachtofferomgeving:

Wijzigingen in de opslagplaats: kwaadwillende personen kunnen de automatische tokens vanuit de pijplijn gebruiken om toegang te krijgen tot en code naar de opslagplaats te pushen (ervan uitgaande dat het automatische token voldoende machtigingen heeft om dit te doen). Ze kunnen op deze manier persistentie bereiken met behulp van verschillende subtechnieken:

• Scripts in code wijzigen/toevoegen: we kunnen enkele van de initialisatiescripts wijzigen/nieuwe scripts toevoegen, zodat ze een backdoor/starter voor de aanvaller downloaden, dus telkens wanneer de pijplijn deze scripts uitvoert, wordt de code van de aanvaller ook uitgevoerd.
  
• Wijzig de pijplijnconfiguratie. We kunnen nieuwe stappen in de pijplijn toevoegen om een door een aanvaller beheerd script naar de pijplijn te downloaden voordat u doorgaat met het buildproces.
• Wijzig de configuratie voor locaties van afhankelijkheden: om door aanvallers beheerde pakketten te gebruiken.

Inject in Artifacts: sommige CI-omgevingen hebben de functionaliteit voor het maken van artefacten die moeten worden gedeeld tussen verschillende pijplijnuitvoeringen. In GitHub kunnen we bijvoorbeeld artefacten opslaan en downloaden met behulp van een GitHub-actie uit de pijplijnconfiguratie.

Installatiekopieën in het register wijzigen: in gevallen waarin de pijplijnen machtigingen hebben voor toegang tot het installatiekopieënregister (bijvoorbeeld voor het terugschrijven van installatiekopieën naar het register nadat de build is voltooid) kan de aanvaller schadelijke installatiekopieën in het register wijzigen en installeren, die door de containers van de gebruiker worden uitgevoerd.

Servicereferenties maken: een kwaadwillende aanvaller kan gebruikmaken van de toegang die ze al in de omgeving hebben en nieuwe referenties maken voor gebruik als de eerste toegangsmethode verloren gaat. Dit kan worden gedaan door een toegangstoken te maken voor de SCM, de toepassing zelf, de cloudresources en meer.

Escalatie van bevoegdheden

De uitbreidingstechnieken voor bevoegdheden worden door een aanvaller gebruikt om de bevoegdheden in de omgeving van het slachtoffer uit te breiden en hogere bevoegdheden te verkrijgen voor reeds gecompromitteerde resources:

Geheimen in privéopslagplaatsen: door gebruik te maken van een reeds opgedane initiële toegangsmethode, kan een aanvaller privéopslagplaatsen scannen op verborgen geheimen. De kans dat verborgen geheimen in een privéopslagplaats worden gevonden, is hoger dan in een openbare opslagplaats, omdat dit vanuit het oogpunt van de ontwikkelaar niet toegankelijk is van buiten de organisatie.

Doorvoeren/pushen naar beveiligde vertakkingen: de pijplijn heeft toegang tot de opslagplaats die kan worden geconfigureerd met machtigingen voor toegang, waardoor code rechtstreeks naar beveiligde vertakkingen kan worden gepusht, zodat een kwaadwillende persoon code rechtstreeks in de belangrijke vertakkingen kan injecteren zonder tussenkomst van het team.

Certificaten en identiteiten van metagegevensservices: zodra een aanvaller wordt uitgevoerd op pijplijnen in de cloud, kan de aanvaller toegang krijgen tot de metagegevensservices vanuit de pijplijn en certificaten extraheren (waarvoor hoge bevoegdheden zijn vereist) en identiteiten van deze services.

Toegang tot referenties

Technieken voor toegang tot referenties worden door een aanvaller gebruikt om referenties te stelen:

Gebruikersreferenties: in gevallen waarin de klant toegang nodig heeft tot externe services vanuit de CI-pijplijn (bijvoorbeeld een externe database), bevinden deze referenties zich in de pijplijn (kan worden ingesteld door CI-geheimen, omgevingsvariabelen, enzovoort) en kunnen ze toegankelijk zijn voor de aanvaller.

Servicereferenties: er zijn gevallen waarin de aanvaller servicereferenties kan vinden, zoals SERVICE-principal-names (SPN), SAS-tokens (Shared-Access-Signature) en meer, waardoor toegang tot andere services rechtstreeks vanuit de pijplijn mogelijk is.

Zijwaartse beweging

De tactiek voor laterale bewegingen verwijst naar technieken die door aanvallers worden gebruikt om door verschillende resources te lopen. In CI/CD-omgevingen kan dit verwijzen naar het verplaatsen naar implementatiebronnen, het bouwen van artefacten en registers of naar nieuwe doelen.

Inbreuk maken op buildartefacten: net als bij andere aanvallen in de toeleveringsketen, kan de aanvaller, nadat de aanvaller controle heeft over de CI-pijplijnen, de buildartefacten verstoren. Op deze manier kan schadelijke code worden geïnjecteerd in de bouwstenen voordat het bouwen wordt uitgevoerd, waardoor de schadelijke functionaliteit in de buildartefacten wordt geïnjecteerd.

Registerinjectie: als de pijplijn is geconfigureerd met een register voor de buildartefacten, kan de aanvaller het register infecteren met schadelijke installatiekopieën, die later worden gedownload en uitgevoerd door containers die dit register gebruiken.

Verspreid naar implementatiebronnen: als de pijplijn is geconfigureerd met toegang tot implementatiebronnen, heeft de aanvaller dezelfde toegang tot deze resources, zodat de aanvaller zich kan verspreiden. Dit kan leiden tot het uitvoeren van code, gegevensexfiltratie en meer, afhankelijk van de machtigingen die aan de pijplijnen zijn verleend.

Verdedigingsontduiking

Beveiligingsontduikingstechnieken kunnen worden gebruikt door aanvallers om verdediging te omzeilen die in een DevOps-omgeving worden gebruikt en om aanvallen onder de radar te laten blijven:

Bewerking van servicelogboeken: met servicelogboeken kunnen Defenders aanvallen in hun omgeving detecteren. Een aanvaller die in een omgeving wordt uitgevoerd (bijvoorbeeld in de build-pijplijnen), kan de logboeken wijzigen om te voorkomen dat Defenders de aanval observeren. Dit is vergelijkbaar met een aanvaller die de geschiedenislogboeken op een Linux-computer wijzigt, waardoor een waarnemer de opdrachten kan zien die door de aanvaller worden uitgevoerd.

Compilatiemanipulatie: als een aanvaller geen sporen in de SCM-service wil achterlaten, kan de aanvaller het compilatieproces wijzigen om de schadelijke code te injecteren. Dit kan op verschillende manieren worden gedaan:

• De code direct wijzigen: wijzig de code direct voordat het buildproces begint, zonder deze in de opslagplaats te wijzigen en traceringen erin te laten.
  
• Geknoeid compiler: het wijzigen van de compiler in de buildomgeving om de schadelijke code te introduceren zonder sporen achter te laten voordat het proces begint.

Vertakkingsbeveiliging opnieuw configureren: met hulpprogramma's voor vertakkingsbeveiliging kan een organisatie stappen configureren voordat een pull-aanvraag/doorvoer wordt goedgekeurd in een vertakking. Zodra een aanvaller beheerdersmachtigingen heeft, kunnen ze deze configuraties wijzigen en code in de vertakking introduceren zonder tussenkomst van de gebruiker.

Impact

De impacttactiek verwijst naar de technieken die een aanvaller kan gebruiken voor het misbruiken van toegang tot de CI/CD-resources voor schadelijke doeleinden, en niet als een andere stap in de aanval, omdat deze technieken lawaaierig en gemakkelijk te detecteren zijn:

DDoS (Distributed Denial of Service): een kwaadwillende persoon kan de rekenresources gebruiken waar ze toegang toe hebben om DDoS-aanvallen (Distributed Denial of Services) uit te voeren op externe doelen.

Cryptovaluta mining – De rekenresources kunnen worden gebruikt voor crypto mining beheerd door een kwaadwillende gebruiker.

Local Denial of Service (DoS): zodra de aanvaller wordt uitgevoerd op de CI-pijplijnen, kan de aanvaller een Denial Service-aanval uitvoeren van deze pijplijnen naar klanten door agents af te sluiten, opnieuw op te starten of door de VM's te overbelasten.

Resourceverwijdering: een aanvaller met toegang tot resources (cloudresources, opslagplaatsen, enzovoort) kan de resources permanent verwijderen om denial of services te bereiken.

Exfiltration (Exfiltratie)

De exfiltratietactiek verwijst naar verschillende technieken die door een aanvaller kunnen worden gebruikt om gevoelige gegevens uit de slachtofferomgeving te exfiltreren:

Persoonlijke opslagplaatsen klonen: zodra aanvallers toegang hebben tot CI-pijplijnen, krijgen ze ook toegang tot de privéopslagplaatsen (bijvoorbeeld de GITHUB_TOKEN kunnen worden gebruikt in GitHub), en kunnen ze daarom de code klonen en openen, waardoor ze toegang krijgen tot privé-IP-adressen.

Pijplijnlogboeken: een kwaadwillende persoon kan toegang krijgen tot de uitvoeringslogboeken van de pijplijn, de toegangsgeschiedenis, de buildstappen, enzovoort. Deze logboeken kunnen gevoelige informatie bevatten over de build, de implementatie en in sommige gevallen zelfs referenties voor services, voor gebruikersaccounts en meer.

Exfiltreren van gegevens uit productiebronnen: in gevallen waarin de pijplijnen toegang hebben tot de productiebronnen, hebben de aanvallers ook toegang tot deze resources. Daarom kunnen ze deze toegang misbruiken voor het exfiltreren van productiegegevens.

Aanbevelingen voor Het beheer van DevOps-houding

Wanneer de DevOps-scanners afwijkingen ontdekken van aanbevolen beveiligingsprocedures binnen broncodebeheersystemen en continue integratie/continue leveringspijplijnen, levert Defender voor Cloud nauwkeurige en bruikbare aanbevelingen. Deze aanbevelingen hebben de volgende voordelen:

• Verbeterde zichtbaarheid: krijg uitgebreide inzichten in de beveiligingspostuur van DevOps-omgevingen, zodat u een goed afgerond inzicht krijgt in eventuele bestaande beveiligingsproblemen. Identificeer ontbrekende vertakkingsbeveiligingsregels, risico's voor escalatie van bevoegdheden en onveilige verbindingen om aanvallen te voorkomen.
  
• Actie op basis van prioriteit: filter resultaten op ernst om resources en inspanningen effectiever uit te geven door eerst de meest kritieke beveiligingsproblemen aan te pakken.
• Kwetsbaarheid voor aanvallen verminderen: los gemarkeerde beveiligingsproblemen op om kwetsbare kwetsbaarheid voor aanvallen aanzienlijk te minimaliseren, waardoor beveiliging tegen potentiële bedreigingen wordt beschermd.
• Realtime meldingen: de mogelijkheid om te integreren met werkstroomautomatiseringen om onmiddellijke waarschuwingen te ontvangen wanneer beveiligde configuraties veranderen, zodat u snel actie kunt ondernemen en ervoor kunt zorgen dat beveiligingsprotocollen voortdurend worden nageleefd.