COMMENTAAR

Na log4jworden softwaretoeleveringsketens strenger gecontroleerd op beveiligingsproblemen. De Amerikaanse regering verplichte softwarestuklijsten (SBOM's) voor federale softwareprojecten, zodat beveiligingsteams de potentiële risico's van softwarecomponenten kunnen begrijpen. De Cybersecurity and Infrastructure Security Agency (CISA), de Commissie van de Europese Unie, het Britse National Cyber ​​Security Centre en Japan werken samen aan de manier waarop SBOM’s nuttiger en waardevoller kunnen worden gemaakt.

Er zijn echter problemen die moeten worden overwonnen. Het daadwerkelijk implementeren van SBOM’s staat nog steeds op de prioriteitenlijst van veel Chief Information Security Officers (CISO’s). Toen ik de CISO's in Groot-Brittannië vroeg waarom, kwam het neer op het stellen van prioriteiten. Hoeveel waarde biedt een SBOM vandaag de dag als u met zoveel vraagstukken te maken heeft?

Daarnaast heb je de vraag wie verantwoordelijk is voor het onderhoud van de betreffende software. Is dit een first-party applicatie die uw interne team heeft samengesteld, of een third-party applicatie die u bij een leverancier heeft gekocht? Hoe zit het met uitbestede software die voor uw organisatie is ontwikkeld door een externe ontwikkelaar? Wie moet de verantwoordelijkheid dragen voor het beheer van zowel de SBOM als de code?

Beveiliging van de softwaretoeleveringsketen en het toekennen van verantwoordelijkheid

In de softwarewereld is het een uitdaging om bij te houden wat er wordt gebruikt, omdat werklasten van minuut tot minuut kunnen worden gecreëerd en stopgezet op basis van de vraag. Toch is het essentieel om nauwkeurige lijsten te hebben van wat er is geïnstalleerd, wat er actief is en wat mogelijk kwetsbaar is als het gaat om het beheersen van risico's.

Dit alles is in theorie logisch. Waarom staat het dan op de prioriteitenlijst van zowel CISO's, beveiligingsteams als ontwikkelaars? De uitdaging is hoe deze programma’s in de praktijk worden uitgerold. Met zoveel IT om voor te zorgen, zoveel veranderingen die plaatsvinden en zoveel software om bij te houden, kunnen de gegevens teams overweldigen.

Het vaststellen van de verantwoordelijkheid voor applicatiebeveiliging en -beheer moet zich richten op praktische verantwoordelijkheden. Software wordt bijvoorbeeld vaak gebouwd door externe aanbieders. Deze contracten moeten de levering van SBOM omvatten als onderdeel van de ontwikkelingsopdracht, evenals wie verantwoordelijk zal zijn voor het bijhouden van die documentatie in de loop van de tijd. Het belangrijkste is dat iemand verantwoordelijk wordt gehouden en dat de rest van de organisatie ook zijn verantwoordelijkheden kent.

Teams helpen effectief samen te werken

SBOM’s worden snel volwassen, maar er is nog een weg te gaan voordat ze gestandaardiseerd zijn. Te vaak worden veiligheidskwesties de spreekwoordelijke hete aardappel, die zo snel mogelijk wordt doorgegeven aan de volgende persoon. Door ontwikkelaars honderden of duizenden softwareproblemen toe te wijzen om op te lossen, worden deze oplossingen niet op magische wijze gerealiseerd; Sterker nog, het kan tot meer problemen leiden, omdat teams niet weten waar ze zich op moeten concentreren.

Om dit op te lossen moeten we betere praktijken implementeren rond de beveiliging van de softwaretoeleveringsketen, te beginnen met SBOM's en activabeheer en gevolgd door goede prioriteringsgesprekken tussen beveiligings- en ontwikkelaarsteams. Beide teams moeten een groter deel van het proces rond het oplossen van problemen of het implementeren van updates automatiseren.

Aan de beveiligingskant gaat het om geautomatiseerde patches voor problemen met een laag risico. Voor ontwikkelaars betekent dit het implementeren van beveiliging door middel van ontwerppraktijken. IT-beveiliging kan tools bieden die vroegtijdig in de workflows van ontwikkelaars kunnen worden geïntegreerd, zodat problemen eerder kunnen worden opgelost. Beveiliging kan ook helpen door andere manieren te signaleren om problemen op te lossen.

Een CISO met wie ik samenwerkte, had bijvoorbeeld gedemoraliseerde teams op het gebied van zowel beveiliging als softwareontwikkeling. Er waren meer dan een miljoen softwareproblemen en beveiligingskwetsbaarheden op eindpunten, applicaties en infrastructuur. Om de oorzaak van dit probleem te achterhalen, hebben we gekeken waar de problemen zich voordeden. Wat al snel duidelijk werd, was dat er niemand direct verantwoordelijk was voor updates in software-imagebibliotheken. Beide partijen werkten hard om problemen aan te pakken, maar elke keer dat er een nieuw beeld uit die bibliotheek werd gemaakt, kwamen de ‘oude’ problemen weer terug. Deze afbeeldingen bevatten ook meerdere versies van Java, waardoor ze verantwoordelijk waren voor honderden kwetsbaarheidsdetecties per afbeelding.

Door iedereen rond de tafel te krijgen en de afbeeldingen te repareren, is het aantal kwetsbaarheden en waarschuwingen dramatisch verminderd. Het team zag het aantal openstaande kwetsbaarheden met de helft dalen, waardoor tijd vrijkwam en beide partijen elkaar meer gingen waarderen.

Zonder data is dit soort discussie niet mogelijk. Door meer inzicht te krijgen, kunt u prioriteiten stellen voor al uw systemen, inclusief eigen software, zodat u voor meer samenwerking, echte verandering en echt succes voor uw teams kunt zorgen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://www.darkreading.com/vulnerabilities-threats/software-security-how-to-move-supply-chain-security-up-the-agenda