CISA's frivillige Secure by Design Pledge og EU's Cyber Resilience Act fremmer begge mere sikre produkter, men de tjener forskellige formål og medfører forskellige forpligtelser.
To tilgange til sikre produkter
CISA Secure by Design Pledge er en frivillig, ikke-bindende forpligtelse for virksomheder, der leverer softwareprodukter og -tjenester til virksomheder. Deltagerne forpligter sig i god tro til at arbejde hen imod angivne sikkerhedsmål i løbet af det følgende år og, hvor det er muligt, offentligt dokumentere målbare fremskridt.
Løftet er ikke en certificering, en overensstemmelsesvurdering eller dokumentation for, at et produkt er sikkert. CISA håndhæver eller verificerer ikke efterlevelse og attesterer ikke sikkerheden af de anførte produkter, processer eller tjenester. Det angivne anvendelsesområde fokuserer på virksomhedssoftware og -tjenester. Fysiske IoT-produkter og forbrugerprodukter falder uden for dette område, selv om virksomheder kan rapportere fremskridt i relation til dem.
De syv mål i løftet
Løftet opfordrer til fremskridt på syv områder:
- øget brug af multifaktorgodkendelse;
- mindre afhængighed af standardadgangskoder;
- reduktion af sårbarhedsklasser;
- øget installation af sikkerhedsopdateringer hos kunder;
- offentliggørelse af en politik for indberetning af sårbarheder;
- gennemsigtig rapportering af CVE'er; og
- hjælp til kunder med at indsamle dokumentation for indtrængen.
Disse mål kan give produktteams et nyttigt praktisk udgangspunkt. De betyder ikke, at hvert mål gælder på samme måde for alle produkter.
Cyber Resilience Act
Cyber Resilience Act, forordning (EU) 2024/2847, fastsætter juridiske krav til producenter, der bringer produkter med digitale elementer i omsætning på EU-markedet, med forbehold for dens anvendelsesområde og undtagelser.
Artikel 13 kræver, at producenter opfylder de gældende krav i bilag I, gennemfører og dokumenterer en produktspecifik cybersikkerhedsrisikovurdering, håndterer sårbarheder i supportperioden og opretholder politikker og procedurer for koordineret offentliggørelse af sårbarheder.
Bilag I omfatter krav, der, hvor det er relevant, dækker sikker konfiguration som standard, sikkerhedsopdateringer, adgangskontroller, logning af relevant intern aktivitet, afhjælpning af sårbarheder, sikkerhedstest, koordineret offentliggørelse af sårbarheder og sikker distribution af opdateringer.
Hvor tilgangene overlapper
Der er et praktisk overlap mellem løftets mål og kravene i CRA. Begge retter for eksempel opmærksomhed mod adgangskontroller, håndtering af sårbarheder, praksis for offentliggørelse, opdateringer og evnen til at undersøge sikkerhedshændelser.
Dette overlap kan hjælpe teams med at organisere deres arbejde, men det gør ikke deltagelse i løftet til dokumentation for overensstemmelse med CRA. CRA er risikobaseret, produktspecifik og rækker ud over løftets syv mål.
Brug løftet som et planlægningsværktøj
Teams kan bruge løftets mål til at identificere nyttige optegnelser, der skal indsamles, og derefter knytte disse optegnelser til de CRA-krav, som gælder for deres produkter. Nyttig dokumentation kan omfatte produktspecifikke sikkerhedsforanstaltninger, basislinjer for konfiguration, optegnelser om håndtering af sårbarheder og relevante datoer.
Offentlig rapportering om fremskridt kan understøtte ansvarlighed, men den kan ikke erstatte den CRA-risikovurdering, tekniske dokumentation eller overensstemmelsesvurdering, der kræves for et produkt, som er omfattet.