CISA:s frivilliga Secure by Design-åtagande och EU:s cyberresiliensakt främjar båda säkrare produkter, men de har olika syften och medför olika skyldigheter.
Två sätt att skapa säkra produkter
CISA Secure by Design Pledge är ett frivilligt, icke-bindande åtagande för företag som erbjuder programvaruprodukter och tjänster för företag. Deltagarna gör ett åtagande i god tro att arbeta mot angivna säkerhetsmål under det följande året och, där så är möjligt, offentligt dokumentera mätbara framsteg.
Åtagandet är inte en certifiering, en efterlevnadsbedömning eller bevis på att en produkt är säker. CISA genomdriver eller verifierar inte efterlevnaden och intygar inte säkerheten hos listade produkter, processer eller tjänster. Dess angivna omfattning fokuserar på programvara och tjänster för företag. Fysiska IoT-produkter och konsumentprodukter omfattas inte, även om företag kan rapportera framsteg som rör dem.
De sju målen i åtagandet
Åtagandet uppmuntrar framsteg inom sju områden:
- ökad användning av multifaktorautentisering;
- minskat beroende av standardlösenord;
- minskning av sårbarhetsklasser;
- ökad kundinstallation av säkerhetsuppdateringar;
- publicering av en policy för sårbarhetsrapportering;
- transparent rapportering av CVE:er; och
- hjälp till kunder att samla bevis på intrång.
Dessa mål kan ge produktteam en användbar praktisk utgångspunkt. De innebär inte att varje mål tillämpas på samma sätt för varje produkt.
Cyber Resilience Act
Cyber Resilience Act, förordning (EU) 2024/2847, fastställer rättsliga krav för tillverkare som släpper ut produkter med digitala element på unionsmarknaden, med förbehåll för dess tillämpningsområde och undantag.
Artikel 13 kräver att tillverkare uppfyller tillämpliga krav i bilaga I, genomför och dokumenterar en produktspecifik cybersäkerhetsriskbedömning, hanterar sårbarheter under supportperioden samt upprätthåller policyer och förfaranden för samordnad sårbarhetsrapportering.
Bilaga I omfattar krav på bland annat säkra standardinställningar, säkerhetsuppdateringar, åtkomstkontroller, loggning av relevant intern aktivitet, åtgärdande av sårbarheter, säkerhetstestning, samordnad sårbarhetsrapportering och säker distribution av uppdateringar, där så är tillämpligt.
Där metoderna överlappar
Det finns en praktisk överlappning mellan målen i åtagandet och kraven i CRA. Båda riktar till exempel uppmärksamheten mot åtkomstkontroller, sårbarhetshantering, rutiner för rapportering, uppdateringar och möjligheten att utreda säkerhetsincidenter.
Överlappningen kan hjälpa team att organisera sitt arbete, men gör inte deltagande i åtagandet till bevis på överensstämmelse med CRA. CRA är riskbaserad och produktspecifik och sträcker sig längre än åtagandets sju mål.
Använd åtagandet som stöd i planeringen
Team kan använda åtagandets mål för att identifiera användbara underlag att samla in och sedan koppla dessa underlag till de CRA-krav som gäller för deras produkter. Användbara bevis kan omfatta produktspecifika säkerhetsåtgärder, konfigurationsbaslinjer, dokumentation om sårbarhetshantering och relevanta datum.
Offentlig rapportering av framsteg kan stödja ansvarstagande, men kan inte ersätta den CRA-riskbedömning, tekniska dokumentation eller bedömning av överensstämmelse som krävs för en tillämplig produkt.