De wereldwijde softwaretoeleveringsketen staat altijd onder druk dreiging van cybercriminelen die dreigen gevoelige informatie of intellectueel eigendom te stelen en de systeemintegriteit in gevaar brengen. Deze problemen kunnen van invloed zijn op commerciële bedrijven en op het vermogen van de overheid om op veilige en betrouwbare wijze diensten aan het publiek te leveren.
Het United States Office of Management and Budget (OMB) publiceerde in juli 2022 een memo over deze kwestie, die we behandelden hier in detail. In september 2022 werd een nieuwe memo uitgebracht, dit keer gericht op de veiligheid en integriteit van de softwaretoeleveringsketen, waarin de belangrijke rol van SBOM’s werd onderstreept. Het presenteert een lijst met precieze vereisten en deelt – voor het eerst – een daadwerkelijke bindende tijdlijn voor het implementeren van veranderingen.
De memo bevat twee hoofdpunten met betrekking tot Executive Order (EO) 14028, Improving the Nation's Cybersecurity:
- De EO geeft het National Institute of Standards and Technology (NIST) opdracht om richtlijnen te delen voor het ontwikkelen van praktijken die gericht zijn op het vergroten van de veiligheid van de softwaretoeleveringsketen. Om dit te helpen bereiken heeft NIST twee documenten vrijgegeven: het Secure Software Development Framework (SSDF), SP800-218 en Beveiligingsrichtlijnen voor softwaretoeleveringsketen. Samen heten ze NIST Guidance en schetsen ze een reeks praktijken die de basis vormen voor het creëren van veilige software.
- De EO geeft ook opdracht aan het Office of Management and Budget om van agentschappen te eisen dat ze zich houden aan de NIST-richtlijnen en eventuele andere updates.
Zelfattestatie is een voorwaarde, maar is dat alles?
Softwareproducenten zijn nu verplicht om bureaus een zelfattest te geven voordat ze hun software gaan gebruiken. Er zijn eigenlijk drie categorieën waarvoor zelfattestering vereist is: nieuwe softwareaankopen, grote versie-upgrades en softwarevernieuwingen. Het doel is om bureaus uit te rusten met veilige en veerkrachtige softwareproducten die hen beschermen tegen dergelijke bedreigingen SolarWinds ervaren, waardoor verschillende instanties in gevaar kwamen.
Laten we beginnen met de basis: wat is zelfattest precies?
Zelfattestatie is een document dat werkt als een conformiteitsverklaring en waarin wordt bevestigd dat de softwareproducent voldoet aan de praktijken uit de NIST-richtlijnen. Het idee is dat bureaus zelfattesten krijgen voor elk softwareproduct of -dienst van derden die onder de vereisten van de memo valt. Dit omvat softwarevernieuwingen en belangrijke versie-updates.
Een ander belangrijk punt in de memo is dat bureaus softwarebedrijven moeten aanmoedigen om productinclusief te zijn. Hierdoor zouden ze aan alle aankoopbureaus hetzelfde attest kunnen bezorgen.
Het bureau mag het zelfattesteringsdocument bewaren, tenzij het softwarebedrijf het openbaar publiceert en in zijn voorstel een link naar het bericht aanbiedt.
Opmerking: Hoewel alle andere memo's en richtlijnen tot nu toe beweren dat zelfattestering in het begin goed genoeg is, stelt deze vertrouwen en transparantie als de belangrijkste doelen. Het richt zich specifiek op de softwaretoeleveringsketen, niet alleen op cyberbeveiliging of de SSDF (zelfs als ze daar deel van uitmaken).
Wat gebeurt er als het softwarebedrijf geen zelfattestatie in het standaardformaat kan leveren?
Het is mogelijk dat een softwareproducent niet in staat is een of meer praktijken uit de NIST-richtlijnen te attesteren, zoals geïdentificeerd in het standaard zelfattestformulier. In dit geval zal de instantie die de software aanvraagt van het bedrijf eisen dat het:
- Identificeer de praktijken waarvan ze niet kunnen getuigen
- Documenteer alle praktijken die worden gebruikt om deze risico's te beperken
- Ontwikkel een actieplan en mijlpalen (POA&M)
Uiteraard moet het bureau ervoor zorgen dat de documentatie niet openbaar wordt gemaakt (door de verkoper of door het bureau zelf).
Stel dat de verkoper alle documentatie levert en dat deze naar tevredenheid van het bureau is. In dat geval mag deze laatste de softwareproducten of -diensten gebruiken ondanks het ontbreken van een volledige zelfattest bij de producent.
Wat moet een aanvaardbare zelfverklaring bevatten?
Een zelfattesteringsdocument moet aan de volgende minimumvereisten voldoen:
- De naam van het softwarebedrijf
- Een beschrijving van de softwareproducten waarnaar de verklaring verwijst (idealiter beschrijft dit punt het niveau van het softwarebedrijf of de productlijn, inclusief alle niet-geclassificeerde producten die aan bureaus worden aangeboden)
- Een verklaring waarin wordt bevestigd dat de leverancier opereert in overeenstemming met veilige ontwikkelingspraktijken en -taken (gespecificeerd in het zelfattestformulier)
Dit type zelfattest is het minimaal vereiste niveau. Maar als instanties software zonder deze software willen aanschaffen (bijvoorbeeld vanwege de kritieke aard ervan) kunnen ze op risico gebaseerde bepalingen uitvoeren met behulp van een beoordeling door een derde partij (gedefinieerd in M-21-30).
Toch moedigt de richtlijn agentschappen aan om een standaardformulier voor zelfverklaring te gebruiken. De Federal Acquisition Regulatory (FAR) Council zal regelgeving voorstellen rond het gebruik van een dergelijk standaard en uniform zelfattesteringsformulier.
Zelfattestering voor open-sourcesoftware
Stel dat het bureau open-sourcesoftware wil aanschaffen of een softwareproduct dat open-sourcecomponenten bevat. In dat geval kan het zich wenden tot een beoordeling door een derde partij, uitgevoerd door een gecertificeerde FedRAMP Third Party Assessor Organization (3PAO) of een beoordeling die door de instantie zelf is goedgekeurd.
Een dergelijke beoordeling is aanvaardbaar in plaats van de zelfverklaring van een leverancier, zolang de 3PAO de NIST-richtlijnen als basislijn gebruikt.
SBOM’s worden een industriestandaard. Ben je er klaar voor?
Hoewel zelfattestatie het minimaal vereiste niveau is, hebben bureaus dit misschien niet nodig als het product of de dienst die ze willen verkrijgen van cruciaal belang is en zelfattestatie niet in een standaardvorm kan bieden.
Wat belangrijk is, is dat de memo bureaus aanmoedigt om artefacten te verkrijgen van leveranciers die aantonen dat ze voldoen aan veilige softwareontwikkelingspraktijken. Eén van die praktijken omvat het hebben van een SBOM.
Wat is een SBOM en hoe werkt het?
Onder SBOM wordt een Software Bill of Materials verstaan, een inventarisatie van alle componenten en afhankelijkheden die onderdeel zijn van de ontwikkeling en oplevering van een softwareproduct.
Een bureau kan een SBOM als onderdeel van sollicitatievereisten, afhankelijk van de mate waarin de software belangrijk is voor het bureau.
In de notitie zijn de volgende richtlijnen opgenomen voor de aanschaf en het gebruik van SBOM door instanties:
- Het bureau kan de SBOM behouden, tenzij de softwareproducent deze publiceert en een link ernaar deelt met het bureau.
- SBOM's moeten worden gegenereerd met behulp van een van de gegevensformaten die zijn gedefinieerd in het NTIA-rapport “De minimale elementen voor een Software Bill of Materials (SBOM)” of vervolgrichtlijnen gepubliceerd door de Agentschap voor cyberbeveiliging en infrastructuurbeveiliging.
- Bij het overwegen van SBOM's moeten agentschappen rekening houden met de wederkerigheid van SBOM en andere artefacten van softwareproducenten die door andere instanties worden onderhouden. Dit is gebaseerd op de directe toepasbaarheid en valuta van het artefact.
- De instantie kan indien nodig andere artefacten dan SBOM nodig hebben, bijvoorbeeld artefacten die verband houden met geautomatiseerde tools en processen voor het valideren van de integriteit van de broncode of het uitvoeren van controles op kwetsbaarheden.
- Het bureau kan ook van het softwarebedrijf eisen dat het bewijs levert dat het deelneemt aan een Programma voor openbaarmaking van kwetsbaarheden.
De memo suggereert ook dat bureaus leveranciers zo vroeg mogelijk in het acquisitieproces op de hoogte stellen van deze vereisten. Om te voldoen aan de Order en NIST-richtlijnen moeten bureaus op de juiste manier plannen en alle vereisten opnemen in hun software-evaluatieproces. Merk op dat dit ook in lijn moet zijn met de tijdlijn die in de memo wordt gespecificeerd (dit wordt in de volgende sectie behandeld).
Agentschappen moeten vereisten specificeren in de Request for Proposal (RFP) of in andere uitnodigingsdocumenten. Het idee hier is dat het bureau ervoor zorgt dat de leverancier het implementeert en gebruikt veilige softwareontwikkelingspraktijken in lijn met NIST-richtlijnen gedurende de gehele levenscyclus van softwareontwikkeling.
SBOM is duidelijk een best practice in de sector op weg naar breed gebruik, vooral als het gaat om het beperken ervan risico's in de toeleveringsketen van software.
Om bedrijven te helpen vertrouwen op te bouwen in hun softwareproducten, hebben we onlangs een gebruiksvriendelijk platform gelanceerd dat helpt bij het genereren van SBOM's en het delen ervan binnen en tussen organisaties. Proberen gratis om te zien hoe eenvoudig het kan zijn om SBOM's te genereren, beheren en delen.
Het is niet langer alleen maar een aanbeveling; nu is er een verplichte tijdlijn die moet worden gevolgd
Agentschappen moeten voldoen aan de memovereisten in overeenstemming met deze tijdlijn:
- Agentschappen hebben 90 dagen om al hun software van derden te inventariseren, inclusief een afzonderlijke inventaris voor ‘kritieke software’.
- Binnen 120 dagenmoeten ze “een consistent proces creëren om de relevante vereisten in dit memorandum aan leveranciers te communiceren en ervoor te zorgen dat attestatiebrieven die niet openbaar door softwareleveranciers worden gepost, in één centraal bureausysteem worden verzameld.”
- Ze hebben ook 270 dagen om attestatiebrieven te verzamelen die niet publiekelijk zijn gepost voor ‘kritieke software’. Binnen een jaar zouden bureaus de brieven voor alle software van derden moeten hebben verzameld.
- Eindelijk binnen 180 dagen Vanaf de datum van de memo (14 september 2022) moeten de CIO's van het bureau alle trainingsbehoeften hebben beoordeeld en trainingsplannen hebben ontwikkeld voor het beoordelen en valideren van de attestatiedocumenten en artefacten.
Agentschappen kunnen ten minste 30 dagen vóór de in de memo genoemde relevante deadline een verlenging aanvragen, samen met een plan om aan de openstaande vereisten te voldoen. Het is ook mogelijk om een ontheffing aan te vragen, maar alleen in uitzonderlijke omstandigheden en voor een beperkte periode.
Samenvatting
Het OMB zal specifieke instructies delen voor het indienen van verzoeken om ontheffingen of verlengingen binnen 90 dagen vanaf de memodatum (tot medio december 2022). Bovendien zal het, in overleg met CISA en de General Services Administration, de vereisten bepalen voor een “gecentraliseerde opslagplaats voor softwareattesten en artefacten” met de juiste mechanismen voor bescherming en uitwisseling tussen instanties.
Zo'n centrale plek zou op een dag een centrale locatie kunnen worden voor een verscheidenheid aan beveiligingsbewijs en attesten die verder gaan dan het zelfattesteringsformulier of SBOM. Door al het bewijsmateriaal op één enkele, deelbare plek te plaatsen, kunnen organisaties omgaan met gedeelde problemen, zoals opkomende nieuwe exploits of CVE’s.
Dit is precies waar het bij Scribe om draait. Kijk eens naar deze pagina voor meer informatie over ons uitgebreide platform voor het genereren, beheren en delen van SBOM's binnen en tussen organisaties.
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
