In april 2023 bracht CISA een nieuwe gezamenlijke gids voor softwarebeveiliging uit, genaamd De balans van cyberbeveiligingsrisico’s verschuiven: Security-by-Design en standaardprincipes. De gids is samengesteld met medewerking van negen verschillende instanties, waaronder onder meer de NSA, het Australian Cyber Security Centre (ACSC) en het Duitse Federale Bureau voor Informatiebeveiliging (BSI). Het feit dat meerdere instanties van over de hele wereld hebben samengewerkt bij het opstellen van een cyberbeveiligingsgids zou een sterk bewijs moeten zijn van het belang dat het onderwerp cyberbeveiliging op dit moment wereldwijd heeft.
Jen Easterly, directeur van CISA, heeft haar gedachten over het onderwerp cyberveiligheid gedeeld in een recente toespraak die ze hield voor de studenten en docenten van de Carnegie Mellon Universiteit in Pittsburgh. Volgens de CISA-directeur zouden deze leidende principes de mondiale software-industrie de komende jaren moeten helpen leiden:
- De last van de veiligheid mag nooit uitsluitend op de klant rusten. Softwarefabrikanten moeten de verantwoordelijkheid nemen voor hun producten en code.
- Technologiefabrikanten moeten radicale transparantie omarmen als een verplichting tot verantwoordelijkheid voor hun producten.
- Technologiefabrikanten moeten zich concentreren op het bouwen van veilige producten, en producten ontwikkelen die zowel veilig zijn door hun ontwerp als standaard veilig zijn.
De CISA-gids neemt deze basisprincipes over en breidt ze uit, inclusief een uitgebreide lijst met praktische suggesties die softwarefabrikanten kunnen nemen om veiliger producten op de markt te brengen.
Het is interessant om op te merken dat veel van de expliciete suggesties daarop zijn gebaseerd NIST's SSDF-framework maar op een meer praktische, minder vrijwillige manier geformuleerd.
Een van de suggesties in de gids, die rechtstreeks verband houdt met radicale transparantie, is dat softwarefabrikanten de productie van een softwarepakket erbij moeten betrekken SBOM in hun SDLC om inzicht te geven in de componenten van hun software.
Maar is het maken van een SBOM en het zelfs publiceren ervan wel voldoende? Wat kan een softwareproducent of een softwareconsument eigenlijk met een SBOM JSON- of XML-bestand?
In dit artikel gaan we kijken naar de toepassingen die een SBOM vandaag de dag kan bieden aan een softwareproducent, de informatie die aan een SBOM kan worden toegevoegd om deze te verrijken, en de bedrijfsinformatie die kan worden verkregen door het onderzoeken van dergelijke verrijkte documenten. We gaan kort in op de compliance-kant van het gebruik van een SBOM en waar uw aansprakelijkheid ligt als softwareproducent, software-aggregator of open source-onderhouder. We sluiten af met een gesprek over risicobeheer en hoe de CISA-principes van 'secure by design' en 'secure by default' aansluiten bij de naleving van de cyberbeveiligingsregelgeving en verlicht risicobeheer.
Niet alle SBOM's zijn gelijk gemaakt
Er zijn tegenwoordig veel tools beschikbaar voor het maken van SBOM's, van open-source tot bedrijfseigen oplossingen. Een persoon of bedrijf die het maken van SBOM's in zijn SOP wil opnemen, zou dat gemakkelijk kunnen doen. Men kon kiezen tussen de verschillende normen degene die het meest geschikt is voor hun behoeften, maar zelfs dan kun je te maken krijgen met veel te veel hulpmiddelen om een weloverwogen beslissing te nemen. Dus waar kunt u nog meer op letten bij het kiezen van precies het goede SBOM-generatie hulpmiddel voor jou?
Controleer eerst welke informatie wel of niet wordt meegenomen bij het maken van de SBOM. Een stuklijst die tools en code bevat die deel uitmaakten van het ontwikkelingsproces, maar geen deel uitmaakten van het eigenlijke product, zou waarschijnlijk veel overtollige informatie bevatten die heel moeilijk uit het resulterende bestand te 'opschonen' is, zodat u alleen de informatie kunt behouden de meest relevante informatie. Op dezelfde manier zouden tools of code die niet is opgenomen of met opzet zijn weggelaten, opvallend ontbreken wanneer u bijvoorbeeld op kwetsbaarheden wilt scannen.
De lijst met software-ingrediënten en afhankelijkheden is op zichzelf grotendeels zinloos. Het heeft weinig nut behalve wat je ermee kunt doen. Het meest voorkomende gebruik van SBOM's vandaag de dag is het scannen van de softwarecomponenten om een lijst met kwetsbaarheden te krijgen die van invloed kunnen zijn op uw product.
Het is belangrijk om te onthouden dat ongeveer 95% van de kwetsbaarheden die u ontdekt, niet kunnen worden misbruikt in uw product. De truc is om die ongrijpbare 5% te vinden, een werkplan te maken en deze exploiteerbare kwetsbaarheden aan te pakken. Hoe weet je wat exploiteerbaar is en wat niet? Dat is de grote vraag die beveiligings- en technische mensen wakker houdt. Een huidige suggestie is om een oplossing te gebruiken genaamd VEX – een Vulnerability Exploitability eXchange, een vorm van beveiligingsadvies waarbij het doel is om de exploiteerbaarheid van componenten met bekende kwetsbaarheden te communiceren in de context van het product waarin ze worden gebruikt. Het blijft nog steeds een groot deel van het werk van het doorzoeken van de hooiberg aan informatie over kwetsbaarheden en het vinden van de naald van exploiteerbare kwetsbaarheden, grotendeels over aan het technische team. Wie kent zijn product immers beter dan de mensen die het hebben gecodeerd?
Er zijn echter nog andere dingen die u kunt doen, vooral als het gaat om overgeërfde kwetsbaarheden die afkomstig zijn van bovenliggende afbeeldingen van uw docker-image of van afhankelijkheden ver terug in uw afhankelijkheidsketen. Met behulp van open source-tools zoals ouderbeeld u kunt erachter komen welke kwetsbaarheden bij de bovenliggende afbeelding kwamen en welke een direct gevolg waren van uw code. Dat zou een potentieel grote hoeveelheid kwetsbaarheden moeten elimineren en het sorteerwerk eenvoudiger moeten maken. Het is ook een goed idee om verschillende adviezen over verschillende kwetsbaarheden te gebruiken. Als u eenmaal hebt vastgesteld dat een kwetsbaarheid niet kan worden misbruikt, is het verstandig om anderen in uw team of uw gebruikers hiervan op de hoogte te stellen, zodat u niet in elke versie dezelfde kwetsbaarheid blijft controleren. van uw product waarbij u de module waarin het werd gevonden niet eens hebt gewijzigd. Het is ook raadzaam om uw open-source- en externe afhankelijkheden te volgen, zodat u, zodra ze exploiteerbare kwetsbaarheden hebben gevonden en opgelost, die code in uw product kunt bijwerken om zeker dat u ook beschermd bent tegen dat specifieke potentiële probleem.
Wat kunt u nog meer toevoegen aan een SBOM?
Zoals hierboven vermeld, is een van de meest voorkomende toepassingen van SBOM's tegenwoordig een checklist voor het scannen op kwetsbaarheden. Met behulp van verschillende gratis beschikbare databases zoals de NVD (Nationale Vulnerability Database) kunt u een lijst met componenten scannen, vergelijkbaar met die van een SBOM, en kijken welke kwetsbaarheden deze bevat. Zodra u een lijst met kwetsbaarheden heeft, kunt u deze rangschikken op ernst, controleren of er bestaande oplossingen zijn, enzovoort.
Een andere informatielaag die nuttig is over uw componenten is hun licentie. Veel open-sourcecomponenten worden geleverd met een licentie die niet compatibel is met commercieel gebruik. Het is belangrijk om ervoor te zorgen dat al uw open-sourcecomponenten, zelfs de componenten die u niet zelf hebt opgenomen maar wel door een andere component zijn opgenomen, compatibel zijn met wat u ook probeert te maken in termen van hun licentie.
Een laatste suggestie is om open-source beveiligings-'gezondheids'-meters te volgen voor uw afhankelijkheden, zoals de OpenSSF-scorekaart. Het hebben van een objectieve, relatief eenvoudige maatstaf voor de cyberbeveiligingsgezondheid van open-sourcebibliotheken zou een grote hulp kunnen zijn bij het beslissen welke bibliotheken u wel of niet in uw product moet opnemen. Deze scores, gecombineerd met de ernst van de kwetsbaarheden, zijn een goede manier om te helpen de kwetsbaarheden te ordenen waaraan u eerst wilt werken.
Risicobeheer als een Business Intelligence-oefening
Er bestaan er meerdere veiligheidsrisico's waar elke softwareproducent tegenwoordig mee te maken krijgt. Tussen malware, cryptominers, wachtwoordstelers en ransomware is het een wonder dat fabrikanten zich veilig voelen om iets op de markt te brengen. Niemand kan alles in één keer aan, dus creëren bedrijven dreigingsmodellen en proberen ze hun risico’s te beheersen op basis van wat zij als hun zwakste schakels beschouwen. De eenvoudigste eerste stap is ervoor te zorgen dat uw code en ontwikkelingsproces voldoen aan alle relevante regelgeving en best practices. Nist's SSDF en OpenSSF's SLSA zijn een goed startpunt, evenals de Amerikaanse vereisten voor zaken als een SBOM. Het volgen van de regelgeving en best practices zou op zijn minst relatieve veiligheid kunnen beloven tegen rechtszaken onder de Veilige haven programma. Maar dat is nog maar het begin.
De CISA-gids moedigt fabrikanten aan om bij het bouwen van hun producten eerst de veiligheid in gedachten te houden. Sommige 'bolt-on'-beveiliging nadat het product klaar is, kan een aantal fundamentele zwakheden die deel uitmaken van de architectuur van het product niet verzachten. Volgens de gids zijn producten die Secure-by-Design zijn, producten waarbij de veiligheid van de klanten een kerndoelstelling is en niet slechts een technisch kenmerk. Fabrikanten worden ook aangemoedigd om dit te omarmen radicale transparantie en verantwoording. Dat betekent onder meer dat we ervoor moeten zorgen dat kwetsbaarheidsadviezen en de daarmee samenhangende gemeenschappelijke kwetsbaarheid en blootstelling (CVE) gegevens zijn volledig en nauwkeurig. Het betekent ook dat de componenten van de code, de afhankelijkheden en kwetsbaarheden ervan worden aangemoedigd om te worden gedeeld als een manier om gebruikers en klanten te laten zien dat de fabrikant op zijn minst op de hoogte is van potentiële problemen in het product.
Volgens Wikipedia, Business intelligence (BI) omvat de strategieën en technologieën die door ondernemingen worden gebruikt voor de gegevensanalyse en beheer van bedrijfsinformatie. Zoals u zich kunt voorstellen, is het verzamelen van een SBOM voor elke build, evenals het kwetsbaarheidsrapport, de licentie-informatie en de adviezen waarin wordt uiteengezet welke kwetsbaarheden wel en niet kunnen worden misbruikt, veel informatie. Het aantal informatiepunten neemt toe als je rekening houdt met de levensduur van een typisch softwareproduct en het feit dat je deze informatie wilt hebben voor code of tool van derden die je gebruikt, evenals voor open-sourcepakketten die je gebruikt. direct of tijdelijk. Om dit allemaal te kunnen begrijpen op een manier die bruikbaar is voor de beveiligingsbevoegdheden van de organisatie (waarschijnlijk de CISO en de mensen onder hen) heb je een systeem nodig, één enkel 'pane-of-glass'-platform waarmee u al die informatie kunt ordenen, effectief kunt doorzoeken en indien nodig in nuttige rapporten kunt presenteren. Om maar één voorbeeld te geven van hoe cruciaal een BI-platform zou kunnen zijn voor een cyberbeveiligingsplatform: stel je voor: Log4J drama van vorig jaar. Zou het niet geweldig zijn om al uw producten, inclusief afhankelijkheden en tools van derden, met een paar toetsaanslagen te doorzoeken op deze 'nieuwe' dreiging? Hoe zit het met het controleren op de aanwezigheid van een andere nieuwe bedreigende CVE die net is uitgekomen? Of het opstellen van een rapport over hoe het totale aantal kwetsbaarheden van uw bedrijf in de loop van de tijd geleidelijk afneemt (of in ieder geval niet toeneemt). Dat is het soort nuttige ‘big picture’-informatie die alleen een BI-systeem bovenop een cybersecurity-SBOM-verrijkt verzamelplatform kan bieden.
Pas als u over alle relevante informatie beschikt, kunt u uw risico echt evalueren, zowel in uw huidige code, in uw afhankelijkheden, als in de keuze om een tool of code van derden in uw product op te nemen of weg te laten. Wanneer u deze risicobeoordeling voortdurend uitvoert, kunt u deze risicobeoordeling ook gebruiken om builds te bewaken en de productie of levering ervan te stoppen als er verdachte activiteit wordt ontdekt.
Kijkend naar de toekomst
De technologie blijft voortdurend vooruitgaan. Waar ooit monolithische codeprojecten op servers in het kantoor van de organisatie de norm waren, zijn het tegenwoordig de multi-cloud microservices-architectuur en LLM's die voorop lopen. SBOM's moeten vooruitgang blijven boeken om alle complexe architectuur- of infrastructuursoftware te kunnen ondersteunen om hun relevantie en bruikbaarheid te behouden. OWASP's CycloneDX werkt bijvoorbeeld al aan het opnemen ervan ML-transparantie in hun SBOM-formaat. Hetzelfde formaat zorgt er ook voor dat VEX-mogelijkheden en een SBOM-sharing-API worden opgenomen bij het plannen van de toekomst. Ik voorspel dat steeds meer platforms zoals die gecreëerd door Schriftgeleerde zal worden gecreëerd voor het verzamelen en delen van veiligheidsgerelateerde informatie, inclusief SBOM's, zowel om regelgevingsredenen als vanwege het voordeel en de waarde die dergelijke verrijkte informatie heeft voor de organisaties die deze op de juiste manier gebruiken.
Het Scribe-platform staat op het punt een nieuwe BI-tool uit te brengen als onderdeel van het bestaande beveiligingsplatform met alle mogelijkheden die ik heb voorgesteld en meer. Ik moedig je aan probeer het eens, bekijk het nut van dergelijke informatie die in de loop van de tijd is verzameld en kijk waarvoor u de informatie kunt gebruiken. Ongeacht of u ervoor kiest om het Scribe-platform in uw SDLC op te nemen of niet, de race naar een veiliger ecosysteem en een uitgebreidere, bruikbare SBOM is nog lang niet voorbij. Het is beter om nu op de transparantiewagen te stappen dan dat radicale transparantie u wordt opgedrongen door regelgeving of druk van de markt.
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
