In een tijdperk waarin organisaties worden geconfronteerd met complexe digitale omgevingen, Attack Surface Management (ASM) een belangrijk onderdeel van moderne cyberbeveiligingsstrategieën. In essentie is ASM een continu proces van het ontdekken, registreren, classificeren en monitoren van alle digitale activa die door kwaadwillenden kunnen worden misbruikt. Dit kunnen openbare webapplicaties, interne netwerken, openbare cloudresources en, cruciaal, open-sourcecomponenten zijn die zijn geïntegreerd of gecompileerd in de technologiestack van de organisatie.
Wanneer bedrijven vertrouwen op open-sourcebibliotheken, frameworks en tools om de ontwikkeling te versnellen en de kosten te verlagen, moeten ze ook rekening houden met de veiligheidsrisico's die aan die afhankelijkheden verbonden zijn. Het beheer van open-sourceaanvalsoppervlakken is belangrijker dan ooit na het oudere SolarWinds-incident en het recentere Log4j-incident, waarbij kwetsbaarheden werden gevonden in een open-sourcecomponent, wat resulteerde in een grootschalige aanval op een aantal ondernemingen.
Wat is open source attack surface management?
Open source attack surface management verwijst naar het identificeren, monitoren en beperken van risico's als gevolg van open source-componenten binnen de technologische infrastructuur van een organisatie.
Terwijl traditionele ASM zich richt op de perimeter en extern zichtbare assets, graaft open source ASM dieper in de softwaretoeleveringsketen en kijkt naar de bibliotheken, frameworks en pakketten die de bouwstenen vormen van moderne applicaties. Hiermee wordt erkend dat kwetsbaarheden niet exclusief zijn voor de eigen code van een organisatie, maar inherent zijn aan het uitgebreide ecosysteem van open-sourceafhankelijkheden van derden waarvan applicaties afhankelijk zijn.
Traditioneel ASM is doorgaans gericht op het ontdekken en monitoren van netwerkuiteinden, domeinen, IP-adressen en andere extern blootgestelde activa. Open-source ASM breidt deze visie verder uit naar binnen en kijkt naar de samenstelling van de applicaties zelf. Het omvat het creëren en bijwerken van een complete software bill of materials (SBOM), het verzamelen van versie-informatie en bekende kwetsbaarheden in afhankelijkheden, en het begrijpen van het web van relaties tussen softwarecomponenten.
Waarom is open source ASM belangrijk?
Open source software vormt de ruggengraat van moderne enterprise-technologiestacks. Volgens sommige schattingen bevatten meer dan 90% van de commerciële applicaties open source-componenten en bevat de gemiddelde applicatie honderden open source-bibliotheken. Deze massale acceptatie heeft geleid tot efficiëntieverbeteringen en innovatie, maar heeft ook het aanvalsoppervlak dat organisaties moeten beschermen aanzienlijk vergroot.
Het groeiende aanvalsoppervlak
Open-source afhankelijkheden hebben ernstige gevolgen voor de veiligheid. De kwetsbaarheid die werd bijgehouden als Log4j (CVE-2021-44228) was voor veel organisaties een wake-upcall. Deze kwetsbaarheid had gevolgen voor miljoenen apparaten en leidde wereldwijd tot enorme patch-inspanningen. Incidenten zoals de compromittering van het npm-pakket event-stream laten zien hoe kwaadwillende actoren de populariteit van open-sourcebibliotheken kunnen gebruiken als vector voor supply chain-aanvallen op downstreamgebruikers.
De uitdaging van zichtbaarheid
De meeste organisaties hebben geen breed inzicht in de impact van hun open source. Vaak introduceren ontwikkelingsteams nieuwe afhankelijkheden zonder beveiligingscontrole, wat leidt tot het ontstaan van zogenaamde "schaduwwaanscheidingen" zonder dat het beveiligingsteam hiervan op de hoogte is. Deze slechte zichtbaarheid leidt ertoe dat kwetsbaarheden lang na het beschikbaar komen van fixes onopgelost blijven, waardoor organisaties worden blootgesteld aan gemakkelijk te voorkomen aanvallen.
Druk vanuit regelgeving en compliance
Regelgevingskaders eisen dat organisaties steeds nauwkeuriger inventarissen van softwarecomponenten bijhouden en bekende kwetsbaarheden snel verhelpen. Van de AVG tot sectorspecifieke regelgeving zoals PCI DSS, compliance vereist gezonde open-sourcebeheerpraktijken die perfect aansluiten bij de principes van Open Source ASM.
Belangrijkste componenten van Open Source Attack Surface Management
Voor effectief open-source ASM is een gestructureerde aanpak nodig waarbij technologie en processen worden gebruikt en in de organisatie worden geïntegreerd. De belangrijkste componenten stellen organisaties in staat om slim te werken om risico's van open source-afhankelijkheden te ontdekken, te prioriteren en te verhelpen.
Software-inventaris
Open source ASM begint met een potentieel volledige en nauwkeurige lijst van alle software-assets. Dat houdt in dat er gedetailleerde Software Bills of Materials (SBOM's) worden bijgehouden, waarin elke gebruikte open source-component, de versie, licentie-informatie en herkomst worden vermeld. Dankzij gestandaardiseerde formaten, zoals CycloneDX en SPDX, kunnen ontwikkelaars deze afhankelijkheden op een onafhankelijke manier beschrijven, waardoor ze beter zichtbaar, gemakkelijker te analyseren en gemakkelijker te delen met andere partijen zijn.
Continue monitoring van kwetsbaarheden
Het regelmatig scannen van codebases en deze vergelijken met kwetsbaarheidsdatabases zoals de National Vulnerability Database (NVD), GitHub Security Advisories en taalspecifieke kwetsbaarheidsfeeds. Monitoring voor CVE's is onvoldoende, het moet kwetsbaarheden correleren met hoe een organisatie systemen daadwerkelijk gebruikt om te bepalen wat echt exploiteerbaar is.
Risicogebaseerd prioriteringskader
Omdat niet alle kwetsbaarheden gelijk zijn, moeten ze worden geprioriteerd om middelen effectief toe te wijzen. De prioritering moet op basis van vele aspecten gebeuren, zoals de ernst van de kwetsbaarheid (CVSS-scores), de exploiteerbaarheid in de omgeving, de toegankelijkheid van de kwetsbare component, de algehele impact op het bedrijf of de beschikbare mitigatiemaatregelen.
Naadloze integratie met ontwikkelingspijplijnen
Door Open Source ASM te integreren in de CI/CD-pijplijn verandert ASM van een periodieke handmatige activiteit in een geautomatiseerd, continu proces. Door te controleren op kwetsbare afhankelijkheden met pre-commit hooks, scans tijdens geautomatiseerde buildtijd en containerimage-analyse wordt voorkomen dat slechte afhankelijkheden ooit in productie komen.
Remediërings- en mitigatiestrategieën
Duidelijk gedefinieerde remediëringsworkflows maken ook deel uit van een ecosysteem voor het omgaan met gevonden kwetsbaarheden. Herstelstrategieën bestaan uit het upgraden naar gepatchte versies, het toepassen van virtuele patchoplossingen (WAF of RASP), het gebruik van alternatieve componenten of het toepassen van compenserende controles wanneer er geen patch beschikbaar is.
Veelvoorkomende bedreigingen die worden aangepakt door open source ASM
Open-source attack surface management evalueert bedreigingen voor een breed scala aan beveiligingskwetsbaarheden die gericht zijn op of gebruikmaken van open-sourcecomponenten. Door inzicht te krijgen in deze bedreigingen, zijn organisaties beter in staat om tegenmaatregelen te nemen.
Misbruik van bekende kwetsbaarheden
Als weg van de minste weerstand naar anders goed beveiligde systemen richten aanvallers zich vaak op bekende kwetsbaarheden in populaire open source-componenten. Het voortdurende risico werd benadrukt in de Equifax-inbreuk van 2017, waarbij aanvallers misbruik maakten van een bekende maar niet-gepatchte kwetsbaarheid in Apache Struts die al maanden was gepatcht, maar niet was uitgerold naar de systemen van Equifax. Hetzelfde patroon doet zich in alle sectoren voor, aangezien veelvoorkomende open-sourcekwetsbaarheden zoals Log4j, Spring4Shell en OpenSSL vanwege hun implementatieschaal een belangrijk doelwit voor aanvallers zijn geworden.
Compromittering van de toeleveringsketen
De softwaretoeleveringsketen is een belangrijk doelwit voor geavanceerde aanvallers, omdat ze met één enkele aanvalsvector meerdere slachtoffers kunnen treffen. De SolarWinds-incidenten hebben aangetoond hoeveel schade dergelijke aanvallen kunnen aanrichten, terwijl kleinere incidenten, zoals de manipulatie van het event-stream npm-pakket, hebben aangetoond dat aanvallers zich steeds meer richten op open-sourcepakketten die door hun beoogde slachtoffers worden gebruikt. Andere soorten van dergelijke aanvallen zijn gebaseerd op het injecteren van code in legitieme pakketten of repositories, het compromitteren van build-servers of het kapen van ontwikkelaarsaccounts.
Aanvallen door verwarring over afhankelijkheden
Verwarring over afhankelijkheden is een type aanval op de toeleveringsketen waarbij misbruik wordt gemaakt van het gedrag van pakketbeheerders wanneer zij te maken krijgen met naamconflicten tussen openbare en privé-repositories. Aanvallers kunnen openbare pakketten registreren met namen die identiek zijn aan de interne pakketten van een organisatie, waarna de buildsystemen automatisch de openbare versie, de kwaadaardige versie, ophalen. Deze aanvalsvector begon in 2021 aandacht te trekken toen onderzoeker Alex Birsan aantoonde hoe effectief deze was tegen meerdere grote organisaties.
Risico's van verlaten pakketten
Naarmate open source-projecten groeien, worden bepaalde pakketten niet langer onderhouden of afgeschreven door hun oorspronkelijke ontwikkelaars. Deze "dode" afhankelijkheden vormen een groot veiligheidsrisico omdat ze geen beveiligingsupdates of bugfixes meer ontvangen, waardoor organisaties kwetsbaar zijn voor aanvallen wanneer er nieuwe exploits worden ontdekt. In sommige gevallen hebben kwaadwillenden verlaten pakketten overgenomen om malware te injecteren.
Schendingen van licentievoorwaarden
Problemen met het naleven van licentievoorwaarden zijn niet per se een bedreiging voor de veiligheid, maar ze kunnen wel grote juridische en financiële risico's met zich meebrengen voor gebruikers van open source-software. Sommige licenties bevatten vereisten die in strijd kunnen zijn met het winstmodel of de strategie voor intellectueel eigendom van een organisatie. Helaas kan het onbedoeld opnemen van code die onder een incompatibele licentie is verpakt, een bedrijf blootstellen aan claims van schending van het authorsrecht, gedwongen openbaarmaking van de code in zijn productiesoftwareketen en kostbare herstelmaatregelen.
Uitdagingen in open source ASM
Open source ASM brengt veel uitdagingen met zich mee voor organisaties die het implementeren. Met de voortdurende toename van het gebruik van open source-componenten moeten beveiligingsteams een manier vinden om deze uitdagingen aan te pakken en hun organisatie te beschermen tegen kwetsbaarheden die kunnen leiden tot datalekken en een verstoring van diensten die kan leiden tot financiële verliezen of boetes van toezichthouders.
Complexiteit van afhankelijkheden
Moderne applicaties hebben diep geneste afhankelijkheidsstructuren, waarbij een enkele applicatie afhankelijk kan zijn van honderden of duizenden directe en transitieve afhankelijkheden. Dit creëert een "afhankelijkheids pool" waarin beveiligingsteams niet langer kunnen zien waaruit hun software bestaat. Deze lagen creëren een complex web van relaties, en een nauwkeurig begrip van de implicaties van kwetsbaarheden in een organisatie is zeer uitdagend; een kritieke kwetsbaarheid in een hypertechnische afhankelijkheid van het derde of vierde niveau kan een cascade-effect hebben op vele systemen in de organisatie.
Beperkte algehele zichtbaarheid
De meeste organisaties beschikken niet over een volledige software bill of materials (SBOM), waardoor u niet alle open-sourcecomponenten kunt identificeren die in hun omgeving worden gebruikt. De zichtbaarheidskloof wordt alleen maar groter door gedecentraliseerde ontwikkelingspraktijken, schaduw-ITen de DevOps de neiging om het tempo van software-implementatie te verhogen. Componenten kunnen worden toegevoegd vanuit verschillende bronnen, pakketbeheerders, containerimages, gekopieerd van een webpagina of software die door leveranciers wordt geleverd, wat leidt tot blinde vlekken in de beveiligingsmonitoring.
Gebrek aan middelen en technische beperkingen
Voor de implementatie van effectieve open-source ASM zijn gespecialiseerde tools en bekwaam personeel nodig, die beide schaars kunnen zijn. Veel organisaties beschikken niet over speciale middelen voor het beheer van open-sourcebeveiliging en verdelen de verantwoordelijkheid in plaats daarvan over de reeds overbelaste ontwikkelings- en beveiligingsteams. De technische uitdagingen van het scannen van gecontaineriseerde applicaties, serverloze functies en dynamisch gecompileerde code maken detectie nog ingewikkelder.
Integratie met ontwikkelingsworkflows
Het achteraf aanpassen van beveiligingspraktijken in gevestigde ontwikkelingsworkflows zorgt voor wrijving die de acceptatie van open-source ASM kan belemmeren. Ontwikkelaars die zich richten op het leveren van functies, kunnen zich verzetten tegen extra beveiligingspoorten die hun releasecycli vertragen of een herziening van bestaande implementaties vereisen. Traditionele beveiligingstools genereren vaak grote hoeveelheden bevindingen zonder context, wat leidt tot alarmmoeheid en verminderde effectiviteit.
Top open source tools voor attack surface management
Open-source attack surface management wordt ondersteund door een overvloed aan tools die organisaties helpen bij het ontdekken, monitoren en aanpakken van kwetsbaarheden in hun open-sourcecomponenten.
CrowdStrike Falcon
CrowdStrike Falcon gaat verder dan zijn kernfuncties voor endpointbeveiliging en biedt robuuste functies voor het beheer van open-sourcebeveiligingsrisico's. De applicatiebeveiligingsmodule van het platform biedt continue scanning van ontwikkelomgevingen om kwetsbare open-sourcecomponenten vroeg in de ontwikkelingscyclus te identificeren.
RiskIQ
RiskIQ, dat nu deel uitmaakt van Microsoft, biedt krachtige mogelijkheden voor het opsporen van aanvalsoppervlakken, waarmee organisaties hun externe activa kunnen identificeren, inclusief die welke afhankelijk zijn van kwetsbare open-sourcecomponenten. De Internet Intelligence Graph van het platform brengt de aan het internet blootgestelde infrastructuur van een organisatie in kaart en detecteert verouderde systemen, verkeerd geconfigureerde services en applicaties die bekende kwetsbare componenten gebruiken. RiskIQ blinkt uit in het opsporen van schaduw-IT en vergeten activa die vaak aan interne inventarisaties ontsnappen, maar toegankelijk blijven voor aanvallers.
Palo Alto Xpanse
Xpanse biedt uitgebreid beheer van externe aanvalsoppervlakken met gespecialiseerde mogelijkheden voor het detecteren van open-source kwetsbaarheden. Het platform monitort continu aan het internet blootgestelde activa om systemen te identificeren die kwetsbare open-source software draaien, van webservers en applicaties tot netwerkservices en IoT-apparaten. De kracht van Xpanse ligt in het vermogen om onbekende of vergeten activa te ontdekken bij cloudproviders, dochterondernemingen en recent overgenomen bedrijven, plaatsen waar kwetsbare open-sourcecomponenten vaak verborgen zijn.
Nuclei Cloud
Nuclei Cloud maakt gebruik van de populaire open-source Nuclei-kwetsbaarheidsscanner om continu toezicht te houden op het externe aanvalsoppervlak van een organisatie op kwetsbare open-sourcecomponenten. Het platform maakt gebruik van op sjablonen gebaseerde scans om specifieke kwetsbaarheidspatronen te detecteren in webapplicaties, API's en infrastructuurcomponenten. Wat Nuclei bijzonder waardevol maakt voor open-source ASM is de uitgebreide sjabloonbibliotheek met controles voor veelvoorkomende open-source kwetsbaarheden en de community-gedreven aanpak die zorgt voor een snelle dekking van nieuw ontdekte problemen.
Best practices voor open-source ASM
De onderstaande best practices helpen organisaties bij het opzetten van een degelijk open-source ASM-programma dat een evenwicht biedt tussen risicobeperking en innovatie.
Categoriseer op basis van risico
Ga verder dan ruwe CVSS-scores door een standaardaanpak voor het prioriteren van kwetsbaarheden te creëren. Houd rekening met zaken als: Wordt de kwetsbare functionaliteit daadwerkelijk gebruikt? Is de component rechtstreeks toegankelijk voor externe gebruikers? Zijn de gegevens die door de component worden verwerkt gevoelig? Zijn er compenserende controles aanwezig? Maak documentatie voor dit raamwerk en zorg ervoor dat alle teams deze op dezelfde manier toepassen. Het goede nieuws is dat geautomatiseerde tools kwetsbaarheidsgegevens automatisch kunnen verrijken met contextspecifieke risico-informatie.
Integreer beveiliging in ontwikkelingsprocessen
Integreer open source ASM in de huidige ontwikkeltools en -praktijken om beveiliging een natuurlijk verlengstuk van het ontwikkelingsproces te maken. U kunt dit op verschillende manieren doen, bijvoorbeeld door IDE-plugins te bouwen die ontwikkelaars informeren over kwetsbare componenten terwijl ze de code schrijven. Gebruik buildsystemen om afhankelijkheden automatisch te controleren voordat u applicaties verpakt. Formuleer beknopte richtlijnen voor herstelmaatregelen, zodat ontwikkelaars deze snel kunnen oplossen zonder zelf beveiligingsspecialisten te hoeven zijn.
Beleidsregels en normen voor governance
Stel formele beleidsregels voor het gebruik van open source op, waarin risicotoleranties worden gekoppeld aan aanvaardbare licenties en minimale onderhoudsvereisten voor afhankelijkheden. Pas deze beleidsregels toe om controles in de CI/CD-pijplijn te automatiseren door middel van technische controles. Stel een governancecommissie samen met vertegenwoordigers van de afdelingen beveiliging, juridische zaken en ontwikkeling, die uitzonderingen en beleidswijzigingen beheert. Deze governancekaders maken een gemeenschappelijke risicobeheerbenadering voor de hele organisatie mogelijk, terwijl ze tegelijkertijd flexibiliteit bieden voor bedrijfskritische applicaties door middel van een goed gedocumenteerd uitzonderingsproces.
Investeer in het automatiseren van het verhelpen van kwetsbaarheden
Minimaliseer menselijke betrokkenheid bij het herstelproces om de reactie op ontdekte zwakke punten te stroomlijnen. Waar toegestaan, kunnen de tools pull-verzoeken genereren die kwetsbare afhankelijkheden reactief bijwerken met veilige alternatieven. Zorg voor sjablonen voor veelvoorkomende herstelpatronen, zodat ontwikkelaars de snelste oplossing voor verschillende soorten kwetsbaarheden kunnen vinden. Implementeer geautomatiseerde tests om ervoor te zorgen dat nieuwe wijzigingen bestaande functies niet verstoren.
Volg de afhankelijkheidsvoorzieningsketen
Neem een bredere kijk om de beveiligingsstatus van uw open-sourcevoorzieningsketen te evalueren. Beoordeel uw afhankelijkheden per pakket op basis van de activiteiten van de beheerder, de kwaliteit van de code, de beveiliging van de code en de ondersteuning door de community. Wees alert op vreemde activiteiten in afhankelijkheidsrepositories, zoals de toevoeging van nieuwe beheerders, ongebruikelijke commitpatronen of onverwachte wijzigingen in machtigingen die op compromittering kunnen duiden. Download pakketten op een veilige manier en controleer hun integriteit met behulp van checksums of handtekeningen.
Conclusie
Open-source attack surface management is een belangrijke ontwikkeling in de toepassing van beveiligingspraktijken door moderne organisaties. Nu bedrijven steeds meer vertrouwen op open-sourcecomponenten om innovatie te versnellen en ontwikkelingstijden te verkorten, moeten ze ook het hoofd bieden aan de unieke beveiligingsuitdagingen die deze afhankelijkheden met zich meebrengen. De juiste Open Source ASM met zichtbaarheid, monitoring en herstelmogelijkheden zorgt ervoor dat de ontwikkelingssnelheid in evenwicht kan worden gebracht met de noodzaak om deze risico's te beheren.
De reeks bedreigingen van open-source ASM, van misbruik van bekende kwetsbaarheden tot aanvallen op de toeleveringsketen, illustreert waarom deze discipline een must is geworden om volwassen beveiligingsprogramma's te garanderen. Organisaties die sterke open-source ASM-praktijken toepassen, verkleinen echter drastisch hun aanvalsoppervlak en de tijd die nodig is om nieuwe kwetsbaarheden bloot te stellen, en creëren meer mogelijkheden voor veerkracht tegen nieuwe bedreigingen.
"Veelgestelde vragen over Open Source Attack Surface Management (ASM)
Open Source Attack Surface Management (ASM) is een gespecialiseerde beveiligingsdiscipline die zich richt op het identificeren, monitoren en beperken van risico's die verband houden met open-sourcecomponenten binnen het software-ecosysteem van een organisatie. Het breidt traditionele ASM uit door dieper in te gaan op de samenstelling van applicaties om bibliotheken, frameworks en pakketten te onderzoeken die de bouwstenen vormen van moderne applicaties, waardoor inzicht wordt gecreëerd in afhankelijkheden die kwetsbaarheden of nalevingsproblemen kunnen veroorzaken.
Het gebruik van open source-tools voor Attack Surface Management biedt verschillende voordelen: kosteneffectiviteit in vergelijking met commerciële oplossingen, flexibiliteit om tools aan te passen aan specifieke organisatorische behoeften, toegang tot community-gedreven innovaties die vaak snel reageren op opkomende bedreigingen, transparantie waardoor beveiligingsteams kunnen controleren hoe tools functioneren, en compatibiliteit met DevOps-praktijken door middel van API-gedreven integraties.
Open source en commerciële ASM-oplossingen hebben elk hun eigen voordelen. Open source tools bieden doorgaans meer aanpassingsmogelijkheden, ondersteuning door de community en kostenbesparingen, maar vereisen mogelijk meer technische expertise om te implementeren en te onderhouden. Commerciële oplossingen zoals SentinelOne bieden geïntegreerde platforms met professionele ondersteuning, geavanceerdere automatisering en schaalbaarheid op bedrijfsniveau, en bevatten vaak extra mogelijkheden zoals runtime-bescherming.
Populaire tools voor Attack Surface Management zijn onder andere CrowdStrike Falcon, Cycode ASPM, RiskIQ, Palo Alto Xpanse en Nuclei Cloud. Elk biedt gespecialiseerde mogelijkheden voor het detecteren van kwetsbare open-sourcecomponenten, van runtime-bescherming tot het opsporen van externe aanvalsoppervlakken en continue monitoring.
