Software verkopen aan de Amerikaanse overheid? Ken eerst de beveiligingsverklaring

Software verkopen aan de Amerikaanse overheid? Ken eerst de beveiligingsverklaring

Software verkopen aan de Amerikaanse overheid? Ken eerst de beveiligingsattest PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.

De afgelopen maanden heeft de Amerikaanse overheid verschillende nieuwe vereisten geïntroduceerd die van toepassing zijn op organisaties die software verkopen aan overheidsinstanties. Omdat deze nieuwe vereisten complex zijn, weten veel leiders nog niet zeker welke impact hun organisatie zal hebben. In dit artikel deel ik enkele van de belangrijkste concepten die u moet begrijpen, zodat u uw overheidsactiviteiten kunt beschermen en aan de regels kunt blijven voldoen.

Nieuwe softwarebeveiligingsvereisten: wat is er veranderd?

In de afgelopen jaren hebben spraakmakende beveiligingsincidenten zoals die getroffen SolarWinds en het open source pakket log4j hebben meer aandacht van de overheid voor softwarebeveiliging. Beginnend met Uitvoeringsbesluit 14028 van het Witte Huis over het verbeteren van de cyberbeveiliging van het land in mei 2021, heeft een reeks acties in de afgelopen twee jaar geleid tot een reeks duidelijke vereisten die van invloed zijn op elke softwareleverancier van de overheid.

In de toekomst zal elke organisatie die software aan de Amerikaanse overheid verkoopt, verplicht zijn zelf te verklaren dat zij voldoet aan de veilige softwareontwikkelingspraktijken die door de overheid zijn uiteengezet in de NIST Veilig softwareontwikkelingsframework.

Een van de belangrijkste dingen om te begrijpen is dat organisaties niet alleen moeten bevestigen dat ze deze praktijken zelf volgen voor de softwarecode die ze schrijven, maar ook dat de open source-componenten die ze in hun applicaties binnenhalen deze praktijken ook volgen.

Begin juni heeft de regering deze eisen opnieuw bevestigd OMB-memorandum M-23-16 (PDF), en stel deadlines vast voor naleving die snel nadert - waarschijnlijk in het vierde kwartaal van dit jaar (voor kritieke software) en het eerste kwartaal van volgend jaar (voor alle andere software).

Dit betekent dat organisaties de komende maanden zullen worstelen om deze nieuwe attestvereisten te begrijpen en te bepalen hoe hun organisatie hieraan zal voldoen, zowel voor de code die ze zelf schrijven als voor de open source-componenten die ze in hun softwareproducten opnemen.

Volgens M-23-16 is de straf voor niet-naleving zwaar:

“Het [federale] agentschap moet stoppen met het gebruik van de software als het bureau de documentatie van de softwareproducent onbevredigend vindt of als het bureau niet kan bevestigen dat de producent de praktijken heeft geïdentificeerd waarvan het niet kan getuigen ... "

Bijzonder uitdagend geval van open source

Nu veel organisaties dieper in de attestvereisten duiken, ontdekken ze dat compliance, vooral met krappe deadlines, een uitdaging kan zijn. De NIST SSDF is een complex raamwerk voor beveiliging en het zal tijd kosten voor organisaties om niet alleen ervoor te zorgen dat ze aan deze praktijken voldoen, maar hun praktijken ook in detail te documenteren.

Maar nog angstaanjagender is dat de overheid leveranciers vraagt ​​om te getuigen van de beveiligingspraktijken van hun volledige softwareproduct, inclusief de open source-componenten in die software. Tegenwoordig bestaat moderne software vaak grotendeels uit open source-componenten die aan elkaar zijn geplaveid, samen met wat aangepaste software. In ons onderzoek hebben we dat gevonden meer dan 90% van de applicaties bevat open source-componenten, en in veel gevallen open source maakt meer dan 70% uit van de codebasis.

Uw organisatie kan getuigen van haar eigen beveiligingspraktijken, maar hoe kunt u precies getuigen van de beveiligingspraktijken die worden gevolgd door de open source-onderhouders die de open source-code schrijven en onderhouden die u in uw applicaties gebruikt?

Het is een enorme uitdaging en organisaties zijn op zoek naar open source-beheerders voor meer informatie over hun beveiligingspraktijken. Helaas zijn veel van deze open source-beheerders onbetaalde vrijwilligers, die 's nachts en in het weekend als hobby aan open source werken. Het is dus niet praktisch om hen te vragen het extra werk te doen om te valideren dat hun beveiligingspraktijken overeenkomen met de hoge normen die zijn vastgesteld door de NIST SSDF.

Een manier waarop organisaties deze uitdaging kunnen omzeilen, is door gewoon geen open source in hun applicaties te gebruiken. En hoewel dat op het eerste gezicht een simpele oplossing lijkt, is het ook een steeds minder levensvatbaar alternatief, aangezien open source in veel opzichten het de facto moderne ontwikkelingsplatform is geworden.

Een betere manier om dit probleem op te lossen, is ervoor te zorgen dat de beheerders van de pakketten waarop u vertrouwt, worden betaald om dit belangrijke beveiligingswerk te doen.

Dit kan vereisen dat u extra onderzoek doet om ervoor te zorgen dat de open source-componenten die u gebruikt, beheerders achter zich hebben die worden betaald - hetzij door zakelijke weldoeners, door stichtingen of door commerciële inspanningen - om te valideren dat hun pakketten voldoen aan deze belangrijke beveiligingsnormen. Of u kunt zelfs zelf contact opnemen met beheerders en een bedrijfssponsor van hun werk worden. Houd er bij het ontwerpen van uw aanpak rekening mee dat de meeste niet-triviale moderne applicaties duizenden verschillende open source-afhankelijkheden hebben, elk gemaakt en onderhouden door een ander individu of team, dus de handmatige inspanning om deze aanpak op te schalen is aanzienlijk.

Een uitdagende maar noodzakelijke stap voorwaarts

Deze vereisten kunnen pijnlijk zijn om aan te voldoen, maar tegen de achtergrond van toenemende beveiligingsproblemen die enorme schade toebrengen aan de publieke en private sector, zijn ze een noodzakelijke stap voorwaarts. De Amerikaanse overheid is de grootste afnemer van goederen en diensten ter wereld, en dat geldt zowel voor IT als voor andere domeinen. Door haar koopkracht te gebruiken om verbeteringen af ​​te dwingen aan de algehele beveiligingsstandaard voor software, draagt ​​de overheid bij aan een veiligere, zekerdere toekomst.

Tijdstempel:

Meer van Donkere lezing