In september 2022 heeft het Amerikaanse Office of Management and Budget (OMB) een mijlpaal memo met betrekking tot de stappen die nodig zijn om uw softwaretoeleveringsketen te beveiligen in een mate die aanvaardbaar is voor de Amerikaanse federale overheid. Elk bedrijf dat zaken wil doen met de overheid en elk federaal agentschap dat software produceert, moet voldoen aan de vereisten en de tijdlijn die zijn vastgelegd in de M-22-18-memo.
M-22-18 richtte zich op de veiligheid en integriteit van de softwaretoeleveringsketen, met bijzondere aandacht voor de rol van SBOM's. Het bevatte een lijst met vereisten en een tijdlijn voor het implementeren van de noodzakelijke stappen voor naleving.
In de memo werden twee hoofddocumenten opgesteld die door NIST waren geproduceerd: het Secure Software Development Framework (SSDF), SP800-218 en Beveiligingsrichtlijnen voor softwaretoeleveringsketen als NIST's leidraad voor veilige softwareontwikkeling. De memo schetst ook de verantwoordelijkheid van softwareproducenten om zelf te getuigen van hun naleving van de richtlijnen van NIST voordat federale instanties vrij zijn om hun producten te gebruiken. Deze zelfverklaring moet de vorm aannemen van een ondertekende zelfverklaring “gemeenschappelijke vorm”. Drie categorieën software vereisen dit zelfattesteringsformulier: nieuwe softwareaankopen, grote versie-upgrades en softwarevernieuwingen.
M-22-18 vereiste dat de CISA dit standaard ‘gemeenschappelijke formulier’ voor zelfverklaring opstelde binnen 120 dagen vanaf de datum van dat memorandum (14 september 2022). Die 120 dagen zijn verstreken in januari 2023, maar de vorm zit er nog steeds in conceptformulier ook al sloot de commentaarperiode ervoor op 26 juni 2023. Dat is ongeveer het moment waarop de OMB Memo agentschappen oorspronkelijk opdracht gaf om attesten voor kritieke software te gaan verzamelen.
Op basis van enkele van de ontvangen opmerkingen voor dat gemeenschappelijke attestformulier achtte OMB het passend om op 22 juni 18 een amendement op M-9-2023 vrij te geven. Dit amendement is getiteld M-23-16. Het nieuwe memorandum verlengt de tijdlijn die op M-22-18 is gepubliceerd voor agentschappen om attesten van softwareproducenten te verzamelen. Instanties zijn nu verplicht om de zelfattest “gebruikelijke vorm” van softwareproducenten voor “kritieke” software, uiterlijk drie maanden nadat het gemeenschappelijke zelfattesteringsformulier van de CISA door OMB is goedgekeurd. Alle andere softwareproducenten hebben zes maanden de tijd nadat het zelfattesteringsformulier door OMB is goedgekeurd.
Sinds dit Het standaardformulier voor zelfverklaring lijkt centraal te staan. Laten we eens wat gedetailleerder bekijken wat daarin is opgenomen. Ook kijken we wie het precies moet ondertekenen en wat zo'n handtekening zou betekenen.
Veilige software-zelfattest Gemeenschappelijk formulier
Als we de reguleringsketen volgen, van EO 14028 tot de richtlijnen van NIST en de OMB-memo's, is het duidelijk dat de regering ernaar streeft iedereen, zowel federale instanties als bedrijven uit de particuliere sector, te beschermen tegen Kwetsbaarheden in de toeleveringsketen van software en inbraken. Omdat de particuliere sector er (naar de mening van de overheid) niet genoeg aan heeft gedaan, heeft de overheid nieuwe regels opgesteld waaraan iedereen (die aan de federale overheid verkoopt) zich moet houden.
Zelfs als u (nog) niet aan de federale overheid verkoopt, is het natuurlijk in uw belang om deze regels te volgen en zelf te bevestigen dat u 'veilig' bent, aangezien dergelijke bedrijven een aantrekkelijkere zakenpartner zullen zijn. Wie zou zaken willen doen met een bedrijf dat niet kan bevestigen dat het er alles aan doet om zijn product en gebruikers te beschermen?
Aangezien we al hebben vastgesteld dat de NIST-richtlijnen de basis vormen voor de nieuwe regelgeving en beste praktijken, is het geen verrassing dat dezelfde suggesties die bijvoorbeeld voorkomen in de SSDF verschijnen ook op het zelfverklaringsformulier.
Hier is een kort voorbeeld uit het conceptdocument:
Genomen uit het Secure Software Self-Atestation Common Form-concept
We zien de vereiste aan de linkerkant, gevolgd door de gerelateerde EO-sectie en vervolgens door de SSDF-praktijken en -taken. Dit is een behoorlijk uitgebreide lijst met vereisten (anderhalve pagina) die niet noodzakelijkerwijs volledig duidelijk zou zijn als de lezer zich niet bezighoudt met cyberbeveiliging en/of DevOps of DevSecOps.
Het document vereist dat de ondertekenaar van het bedrijf PERSOONLIJK bevestigt dat alle vereisten die in het formulier zijn beschreven consequent worden nageleefd en dat het bedrijf de betrokken instanties op de hoogte zal stellen als een element op de lijst niet langer geldig is.
Het document specificeert niet wie binnen het bedrijf het document moet ondertekenen, maar aangezien dit formulier de vereiste is voor het bedrijf om zaken te doen met de federale overheid en haar agentschappen, ligt het voor de hand dat de CEO de persoon is die de verantwoordelijkheid moet nemen. hier. De CEO zal het waarschijnlijk niet blindelings ondertekenen en zijn CTO en CISO vragen om (eventueel schriftelijk) te verifiëren dat het bedrijf al deze richtlijnen en vereisten volgt.
Omdat er geen vaststaand product of werkwijze bestaat die aan al deze eisen voldoet, moet elk ondertekenaar in zekere zin 'het wiel opnieuw uitvinden' voor zichzelf en hopen dat er niets ergs gebeurt.
Als er iets ergs gebeurt, gaat de federale overheid achter de ondertekenaar aan om aan te tonen en te bewijzen dat hij aan alle eisen van de formulieren kan voldoen.
Wat gebeurt er als ik niet teken?
Ten eerste is dit hele attesteringsgedoe momenteel alleen relevant als uw software wordt gebruikt door een federale instantie, als u van plan bent uw software aan de federale overheid te verkopen, of als uw software wordt gebruikt door een leverancier wiens software in gebruik is of is bedoeld om te worden verkocht aan de federale overheid.
Merk op dat ik 'momenteel' zei, omdat er alle aanwijzingen zijn dat SSDF-compliance, hetzij als zelfattest of in een andere verifieerbare vorm, een nieuwe 'best practice' op het gebied van softwareproductie gaat worden.
Ervan uitgaande dat uw bedrijf binnen de hierboven genoemde groep valt en u de weg niet kunt vinden om dit document met een zuiver geweten te ondertekenen, is alles nog niet verloren. Zolang u maar kunt uitleggen waar de tekortkoming in de attest zit en een bevredigend aanbod kunt doen Plan van aanpak en mijlpalen (POA&M) de betreffende federale instantie kan uw product nog steeds kopen/gebruiken en namens u een uitbreiding van uw software aanvragen bij OMB.
Het slechte nieuws is dat u, met of zonder een POA&M-plan, uiteindelijk een volledig attestatieformulier moet overleggen, wat betekent dat u bij een federale rechtbank moet kunnen verifiëren dat alle stappen die in het formulier zijn vereist, door uw bedrijf zijn gevolgd en dat uw bedrijf Het softwareontwikkelingsproces is minstens zo veilig als de vereisten van het formulier.
De enige software die momenteel is vrijgesteld van deze vorm van attestering is door federale instanties ontwikkelde software en vrij verkrijgbare software, ook wel open-sourcesoftware genoemd. Natuurlijk, de meeste beveiliging van de toeleveringsketen van software gaten kunnen op de een of andere manier worden herleid tot een open-sourcepakket in uw code, maar er is een reëel probleem bij het proberen open-sourceontwikkelaars en -onderhouders, die gratis werken, te dwingen een juridisch bindende garantie voor hun software te bieden. Het zou aan iedereen moeten zijn die open-sourcesoftware gebruikt om de veiligheid ervan te verifiëren, zowel in het algemeen als als het gaat om de software waarin deze is ingebed in het bijzonder.
Erger geval scenario
Deze hele zorgvuldigheid in de beveiliging van de toeleveringsketen van software begon na de beroemde SolarWinds houwen. Zonder al te veel in details te treden: op het moment van de hack waren meer dan 18,000 klanten van het bedrijf getroffen, waaronder 9 federale agentschappen.
Het is pas nu, jaren later, dat we enkele juridische gevolgen van dit incident beginnen te zien. De seconde, Amerikaanse Securities and Exchange Commission, gaat achter het bedrijf aan als geheel, maar ook na verschillende C-level executives. Dit kan worden gezien als een voorbeeld van de bedoelingen van de overheid mocht een dergelijk incident of iets dergelijks een softwareproducent overkomen die getuigde van zijn veilige ontwikkelingspraktijken en toch het slachtoffer werd van een hack.
In het geval van SolarWinds steunt het bedrijf elke werknemer die het doelwit wordt van dergelijke juridische stappen volledig. Als je het Amerikaanse rechtssysteem kent, zullen dergelijke zaken waarschijnlijk jaren duren en veel geld kosten. Boetes zijn niet uitgesloten en kunnen oplopen tot miljoenenbedragen op basis van een schatting van de boetes geleden schade.
U kunt zich voorstellen dat niet alle bedrijven, vooral kleine en middelgrote, hun werknemers even onwankelbaar beschermen als SolarWinds. Het probleem is dat als de beschuldigde partij de CEO van het bedrijf is, er een reële kans bestaat dat het vertrouwen van de markt in het bedrijf en zijn product ernstig zal lijden. Een confrontatie met de SEC zonder de steun van een groot bedrijf met diepe zakken zou zowel een nietsvermoedende CEO als zijn bedrijf kunnen ruïneren. Het is uiteraard de bedoeling om mensen ertoe aan te zetten hun verantwoordelijkheid voor het veiligstellen van de ontwikkeling serieus te nemen, maar de angst kan ertoe leiden dat mensen de kant van zelfbehoud kiezen. Dat betekent dat mensen cyberveiligheidsincidenten liever verbergen als ze denken dat ze een potentiële SEC-zaak niet kunnen winnen, of als ze zich zorgen maken dat de kosten en de slechte publiciteit van een dergelijke zaak zo ernstig zouden zijn dat het beter is om ze te verbergen, ongeacht de uitkomst van de rechtszaak.
Hoe kan ik tekenen?
De NIST SSDF-richtlijnen staan vol met suggesties en best practices, maar zijn weinig praktisch. Omdat elk bedrijf uniek is, is het vrij moeilijk om een product of systeem op de markt te brengen dat voor iedereen zou werken. In dit geval komt de particuliere sector tussenbeide om het vacuüm op te vullen en een ecosysteem te creëren dat u helpt aan de vereisten te voldoen.
Bijvoorbeeld Scribe heeft een platform gebouwd gebaseerd op het concept van het maken van attesten, het ondertekenen ervan en het bieden van de mogelijkheid om ze te verifiëren. We zullen binnenkort een document vrijgeven dat op maat is gemaakt voor de CISA-zelfattestformulier, waarin wordt gedemonstreerd hoe de Scribe-oplossing u kan helpen bij elk onderdeel van de vereisten. Blijf kijken.
Uitproberen Het platform van Scribe is gratis. Ik moedig u aan om het eens te proberen en te zien hoe u het platform aan uw vereisten kunt aanpassen en tegelijkertijd het zelfverklaringsformulier van CISA met een zuiver geweten kunt ondertekenen.
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
