De snelheid waarmee nieuwe kwetsbaarheden worden onthuld, neemt voortdurend toe. Momenteel bedraagt dit gemiddeld 15,000 CVE's per jaar. 2022 valt op met meer dan 26,000 gerapporteerde nieuwe CVE’s. Uiteraard zijn niet alle kwetsbaarheden relevant voor uw software. Om erachter te komen of een bepaalde kwetsbaarheid een probleem is, moet u eerst uitzoeken of u de bibliotheek of het product gebruikt dat de kwetsbaarheid bevat, en vervolgens uitzoeken of u de problematische versie en module van die bibliotheek gebruikt. Ten slotte moet u uw ontwikkelingsteam raadplegen om te zien of die kwetsbaarheid relevant is voor uw specifieke product en de manier waarop u die kwetsbare bibliotheek of product hebt gebruikt.
Het proces om dit allemaal uit te zoeken is niet eenvoudig en kan behoorlijk wat tijd in beslag nemen. Tom Alrich, een bekende cybersecurity-expert, schat dat in ongeveer 95% van alle CVE's in een bepaald softwareproduct zijn niet exploiteerbaar. Maar als u een eindgebruiker bent of een bedrijf dat op het punt staat software van derden in hun systeem te integreren, hoe kunt u dan de problematische 5% identificeren, zodat u om een goede oplossing of patching kunt vragen?
Dit is waar het idee van Vulnerability Exploitability Exchange (VEX) komt binnen. Het doel van VEX, zoals gedefinieerd door leiding van de Amerikaanse National Telecommunications and Information Administration (NTIA) in 2021, is “om gebruikers (bijvoorbeeld operators, ontwikkelaars en serviceproviders) aanvullende informatie te bieden over de vraag of een product wordt getroffen door een specifieke kwetsbaarheid in een opgenomen component en, indien getroffen , of er acties worden aanbevolen om te herstellen.”
Op dit moment denkt u waarschijnlijk: hoe kan ik deze VEX-documenten verkrijgen en mijn componenten gaan controleren? Welnu, de realiteit van VEX-gebruik is, zoals gewoonlijk, ingewikkeld.
Ontdek het doel van VEX
Simpel gezegd zou VEX snel en gemakkelijk de vraag moeten beantwoorden: kan mijn versie van deze software hiervoor worden misbruikt? kwetsbaarheid?'.
Het antwoord op die vraag zou een van de vier belangrijkste opties moeten zijn:
- Niet beinvloed: Er is geen herstel nodig voor dit beveiligingslek.
- Aangetast: Er worden acties aanbevolen om dit beveiligingslek te verhelpen of aan te pakken.
- Fixed: Deze productversies bevatten een oplossing voor het beveiligingslek.
- In onderzoek: Het is nog niet bekend of deze productversies getroffen zijn door het beveiligingslek. Een update zal in een latere release worden verstrekt.
Omdat VEX geacht wordt zowel machinaal leesbaar als machinaal gegenereerd te zijn, is het de bedoeling om ergens een doorzoekbare database van deze documenten te hebben, zodat elke geïnteresseerde partij deze kan doorzoeken en het benodigde antwoord kan krijgen.
Aangezien de aanname is dat 95% van de kwetsbaarheden in geen enkel softwareproduct kan worden uitgebuit, is dit systeem bedoeld om de enorme lijst met kwetsbaarheden die voor elk product worden gevonden, uit te dunnen tot alleen de kwetsbaarheden die de gebruiker in de gaten moet houden of om herstel of patching moet verzoeken. voor.
Er zijn een aantal interessante feiten over de geschiedenis van VEX
In 2020 was NTIA (de Amerikaanse National Telecommunications and Information Administration) begon het idee van VEX te bespreken als begeleidend instrument voor de SBOM (Softwarestuklijst). In september 2021 bracht de NTIA een introductie van één pagina uit met uitleg over wat VEX zou moeten doen.
Later kwamen de inspanningen om de vereisten van het nieuwe adviesformat te verfijnen onder auspiciën van CISA – de Amerikaanse Cybersecurity and Infrastructure Security Agency, die zijn eigen document begin 2022 gaat wat dieper in op enkele gebruiksscenario's waarbij het VEX-document zou moeten helpen. Het document, een concept, definieerde de minimaal vereiste velden van het VEX-document op dezelfde manier waarop NTIA de minimaal vereiste velden van de SBOM definieerde.
Sindsdien zijn er twee grote pogingen ondernomen om daadwerkelijk een machinaal leesbaar VEX-documentatieformaat te creëren:
- De Gemeenschappelijk veiligheidsadvieskader (CSAF) was het eerste beschikbare formaat. Dit formaat werd eind 2022 uitgebracht door OASIS Open, een internationale non-profitorganisatie die zich toelegt op het produceren van open-sourcestandaarden voor cyberbeveiliging, blockchain, IoT en andere gebieden.
- Cycloon DX, een gestandaardiseerd formaat voor SBOM's gelanceerd door OWASP (Open Web Application Security Project), dat werd aangepast om ook VEX-documenten te creëren.
CSAF is een veelomvattend formaat, maar om het daadwerkelijk met succes te kunnen gebruiken, moet je meerdere velden en veel meta-informatie opnemen, waardoor een daadwerkelijke adoptie onwaarschijnlijk is. Het CyclonDX VEX-initiatief is veel slanker, dus als je bedenkt welke VEX-standaard je het meest zou gebruiken, zou het waarschijnlijk het meest geschikt zijn. met het CyclonDX-formaat.
Waarom VEX op een wegversperring stuitte – Het blootleggen van de problemen die het succes ervan saboteren
VEX is een goed idee en kan de waardevolle mogelijkheid bieden om snel te controleren of een bepaalde kwetsbaarheid daadwerkelijk kan worden misbruikt in een bepaald softwareproduct.
Er zijn echter verschillende problemen die de implementatie ervan tot nu toe in de weg staan:
- Indieningsverantwoordelijkheid – wie moet verantwoordelijk zijn voor het indienen van de vereiste VEX-documenten? Zijn het de softwareproducenten? Externe beveiligingsbedrijven of non-profitorganisaties? Een overheidsinstantie? Wat zou er gebeuren als meerdere bronnen tegenstrijdige informatie zouden indienen?
- VEX-database – wie of wat moet de VEX-informatie opslaan en categoriseren? Ervan uitgaande dat sommige documenten exploiteerbare problemen in software beschrijven, bestaat er dan geen gevaar dat de informatie in de verkeerde (kwaadwillige) handen terechtkomt?
- De huidige formaten dekken de kwestie van de versies niet goed, en nog minder het probleem van het gecombineerde versiebeheer.
Gecombineerde software-/pakketversies verwijzen naar de praktijk waarbij meerdere softwarepakketten of componenten samen worden gebundeld in één release- of installatiepakket.
Als het gaat om het patchen van kwetsbaarheden, kunnen gecombineerde software-/pakketversies het proces zowel helpen als belemmeren. Aan de ene kant kan het hebben van één installatiepakket dat alle benodigde componenten bevat, het proces van het identificeren en patchen van kwetsbaarheden vereenvoudigen. In plaats van dat u elk afzonderlijk onderdeel handmatig hoeft te identificeren en patchen, kunt u de patch eenvoudigweg op het hele pakket toepassen.
De keerzijde hiervan is echter dat als één onderdeel binnen het pakket kwetsbaar is, de hele software kwetsbaar is. Dit betekent dat zelfs als sommige componenten in het pakket zijn gepatcht, het totale pakket nog steeds gevaar kan lopen als er een enkel ongepatcht onderdeel aanwezig is.
Stel dat versie 1 van bibliotheek A in uw software een kwetsbaarheid bevat. Dat probleem manifesteert zich alleen als bibliotheek A aanwezig is met versie 2 van bibliotheek B. Er is een beveiligingspatch, maar niet iedereen zou deze hebben geïnstalleerd. Dat betekent dat het VEX-document voor die kwetsbaarheid in uw software alle mogelijke combinaties van het product, de versies ervan, de daarin opgenomen bibliotheken, hun versies en de mogelijke uitgebrachte patches moet omvatten. Dat is veel complexe informatie die niet eenvoudig uit te drukken is.
- Hoe zou VEX software dekken die is ingebed in hardware met alle mogelijke versies en patches die daar beschikbaar zijn? Wiens verantwoordelijkheid zou het zijn om deze software te patchen, aangezien je de hardware niet gemakkelijk kunt openen en zelf dingen kunt patchen?
Dit zijn slechts enkele van de problemen die elke automatische tool voor het omgaan met VEX zou moeten begrijpen en waarmee rekening moet worden gehouden.
Zou het niet eenvoudiger zijn als u voor elke versie informatie kunt opvragen en verkrijgen?
De veronderstelling dat de beste manier om deze belangrijke informatie te delen via een document is, is mogelijk onjuist. Het produceren van voldoende VEX-documenten om elke combinatie van versie, patch en kwetsbaarheid te dekken is een gedenkwaardige taak die, begrijpelijkerwijs, niemand wil ondernemen.
Schriftgeleerde heeft een platform gebouwd voor het volgen en delen van beveiligingsgerelateerde informatie voor elke build van een bepaald softwareproject of product. Als onderdeel daarvan genereert elke build een nauwkeurige SBOM en een lijst met kwetsbaarheden die in het product zijn ontdekt.
Scribe stelt de softwareproducent in staat om aan elk van deze kwetsbaarheden adviezen in VEX-formaat toe te voegen om vast te stellen of ze niet kunnen worden misbruikt, worden onderzocht, enz. Zodra een versie is vrijgegeven, kan alle beveiligingsinformatie over die versie worden gedeeld met geïnteresseerde derde partijen, gebruikers , toezichthouders, enzovoort. Het opnemen van zowel de kwetsbaarheidslijst als de VEX-advieslijst betekent dat de ontvanger alleen naar die kwetsbaarheden moet kunnen kijken die een potentieel probleem vormen in dit specifieke product. Het ontlast zowel de softwareproducent die zijn product op de ‘witte lijst’ kan zetten als de softwareconsument die precies begrijpt welk risiconiveau een specifiek softwareproduct met zich meebrengt.
Omdat de softwareproducent de enige is die definitief kan zeggen of een bepaalde kwetsbaarheid inderdaad relevant is voor een bepaalde versie van het product, zijn zij de enigen die adviezen over hun eigen producten kunnen toevoegen en wijzigen. Het oordeel van de softwareproducent ter zake is definitief en onbetwistbaar. De beslissing met wie deze informatie wordt gedeeld, is ook het voorrecht van de softwareproducent.
Omdat de volledige geschiedenis van de productbuilds, SBOM's en beveiligingsinformatie door Scribe wordt opgeslagen, kunnen gebruikers deze informatie eenvoudig opvragen en verkrijgen voor elke versie die ze gedurende de gehele levenscyclus van de software gebruiken.
Conclusie
Bedenk dat elke fatsoenlijke scan van een softwareproduct tegenwoordig honderden, zo niet duizenden mogelijke kwetsbaarheden zou opleveren. De meeste mensen kunnen niet omgaan met zo’n aantal. Alertheidsmoeheid treedt op en het aantal kwetsbaarheden wordt precies dat: een getal.
De mogelijkheid om het aantal gedetecteerde problemen terug te brengen tot een beheersbaar aantal zou een zegen zijn voor softwareproducenten en -gebruikers. Het doel is om alleen te focussen op de echte problemen, zodat de softwareproducent deze zo snel mogelijk kan patchen en verhelpen.
Geautomatiseerde hulpmiddelen, zoals Schriftgeleerde bieden een gemakkelijke manier om alleen de relevante kwetsbaarheden voor elk van uw projecten en builds te zien, informatie die u gemakkelijk kunt delen, waardoor de berg kwetsbaarheden aanzienlijk kleiner en veel beter beheersbaar wordt.
Een belangrijk voorbehoud is echter dat deze toekomst, waarin we gemakkelijk alleen de relevante kwetsbaarheden kunnen zien en erop kunnen reageren, niet mogelijk zou zijn zonder de actieve deelname van de open-sourcegemeenschap. De meeste code bestaat tegenwoordig uit aanzienlijke hoeveelheden open-sourcesoftware, dus we hebben de beheerders en ontwikkelaars van dergelijke bibliotheken nodig om deel te nemen aan de ontdekking en het herstel van de exploiteerbare kwetsbaarheden die hun code teisteren.
Het probleem van relevante, exploiteerbare kwetsbaarheden gaat niet weg, dus het is aan ons allemaal om de meest efficiënte, kosteneffectieve manier te vinden om het antwoord te krijgen op de vraag: 'is mijn versie van deze software hiervoor te exploiteren?' kwetsbaarheid'.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
