Column - Fourth Party Risk Management, SBOM, CSAF en VEX
Door Dimitri van Zantvliet 17 feb 2023
We beginnen het nieuwe jaar vol goede moed en bereiden ons voor op weer een jaar vol Log4J, Log4text, OpenSSL en vele andere soortgelijke kwetsbaarheden. Overnight en in het weekend lekker de eigen repo’s scannen, uitpluizen en patchen en de leveranciers (third parties) bevragen of ze direct of indirect een risico vormen voor onze bedrijfsvoering. De leveranciers van de leveranciers (fourth parties) zijn echter zelden goed in beeld terwijl Supply Chain Risico’s inmiddels bovenaan de lijst met cyberdreigingen staan. Hoe kunnen we de komende jaren beter zicht krijgen op deze afhankelijkheden en responstijden verkleinen op het moment dat het nodig is?
Op momenten dat we vermoeden dat er iets mis is met een softwarecomponent moeten we gaan onderzoeken of we kwetsbaar zijn. We kijken naar security advisories, bevragen de leverancier (“schiet maar een ticket in”), gaan zelf op onderzoek uit of gaan zoeken in de Software Bill Of Materials (SBOM). Als we die laatste hebben en deze up-to-date en voldoende gedetailleerd is tenminste. Het is duidelijk dat het zo dagen kost om vast te kunnen stellen of producten kwetsbaar zijn en die dagen kunnen we nu net niet missen. Automatisering is wat we hier missen.
Als we kijken naar de CVE’s, de bekende kwetsbaarheden in software en netwerken, dan zien we een sterke stijging in het aantal per jaar en ze zitten ook echt overal en nergens. Op het moment van schrijven van deze column (4 december 2022) staat de teller al op 46.416 stuks. Echter, niet alle CVE’s zijn ook (direct) exploiteerbaar en vormen daarmee een even groot risico. Er zit dus veel ruis in het grote aantal wat het duiden ervan en het snel schakelen evenmin versnelt.
Op de OneConference, het flagship store cyber event in Europa van het NCSC, sprak dr. Allan Friedman van de Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) over software transparantie en het tracken van software kwetsbaarheden via CSAF, de SBOM en VEX. Veel afkortingen die ons het dagelijkse cyberleven gemakkelijker moeten maken de komende jaren.
Het Common Security Advisory Framework (CSAF) is de set van afspraken over een taal waarmee security advisories en kwetsbaarheden in producten eenduidig en geautomatiseerd uitgewisseld kunnen worden binnen een keten van leveranciers. CERTS, ISACs en NCSCs gebruiken het al en in combinatie met een Vulnarability Exploitability Exchange (VEX) biedt het, volgens Friedman, de oplossing voor al het uitzoekwerk.
De VEX, ontwikkeld door de Amerikaanse overheid, biedt de leveranciers en gebruikers de mogelijkheid te focussen op de CVE’s die daadwerkelijk direct risico’s opleveren en geen tijd te verspillen aan kwetsbaarheden die geen impact hebben op de producten die jouw organisatie gebruikt. De combinatie van SBOM, CSAF en VEX geven dus direct inzicht of een product “affected”, “not affected”, “fixed” of “under investigation” is. De status “not affected” kan dan ook weer diepere uitleg bevatten waarom niet en de nachtrust bevorderen. De hamvraag gaat nu worden hoeveel tienduizenden VEX-en we per jaar moeten gaan verwerken. Is de VEX het licht aan het eind van de CVE-tunnel of slechts de volgende cybertrein die op ons afkomt?
Dimitri van Zantvliet
CISO bij de Nederlandse Spoorwegen en columnist van iB-Magazine.
Deze column verscheen in iB1-2023.