Ven eller fjende? Uanset hvad, er loven om cyberresiliens på vej

Europa-Kommissionen har teknologileverandører og -sælgere i kikkerten. Forbrugere og virksomheder har været plaget af dårligt designet, konstrueret og vedligeholdt software og hardware for længe. Den hævder, at cyberkriminalitetsøkonomien er den primære gavn for disse fejl, som Kommissionen siger, var værd 5.5 billioner euro (4.7 tr. pund) i 2021. Udfordringens omfang er enormt. Antallet af nye softwaresårbarheder rapporteret af den amerikanske regering i 2022 steget med en fjerdedel årligt til at nå 25,096 – endnu en rekordhøj.

EU's svar er Cyber ​​Resilience Act (CRA). Selvom det stadig er ved at blive færdiggjort, har nogle hævdet, at dets bestemmelser truer open source-samfundet og endda kan gøre den digitale verden mindre sikker.

Hvad er der i CRA?

CRA har til formål at beskytte forbrugere og virksomheder, der køber produkter med en "digital komponent". Det søger at adressere to centrale udfordringer:

• De dårlige cybersikkerhedsforanstaltninger indbygget i mange produkter, herunder software og tilsluttede enheder som smarte babyalarmer og/eller utilstrækkelige opdateringer til software og enheder
• Manglen på et branchedækkende "dragemærke", som kunne hjælpe teknologikøbere til bedre at forstå, hvilke produkter der er sikre, og hvordan de konfigureres sikkert

Med dette i tankerne vil CRA mål til:

• Harmoniser regler på tværs af blokken for producenter og detailhandlere, der udvikler/sælger digitale produkter
• Angiv et strengt sæt cybersikkerhedskrav "der styrer planlægning, design, udvikling og vedligeholdelse" af disse produkter
• Forpligte relevante producenter/forhandlere til at yde omsorgspligt i hele livscyklussen af ​​digitale produkter
• Udrulning af et nyt CE-mærke, der indikerer, at produkter er CRA-kompatible, hvilket tilskynder producenter og detailhandlere til at prioritere sikkerhed og giver it-købere mulighed for at træffe bedre informerede beslutninger

Hvad er dækket, og hvad kræves?

Som det står, lovgivningen vil "gælde for alle produkter, der er direkte eller indirekte forbundet med en anden enhed eller et andet netværk med undtagelse af specificerede undtagelser såsom open source-software eller tjenester, der allerede er omfattet af eksisterende regler, hvilket er tilfældet for medicinsk udstyr, luftfart og biler."

Disse produkter er opdelt i tre kategorier:

Standard: Lavrisikoprodukter som smart legetøj og køleskabe, videospil og anden almindeligt anvendt software og enheder, som Kommissionen hævder dækker 90 % af markedet. Virksomheder skal udføre en selvevaluering for at sikre, at et produkt opfylder de relevante sikkerhedsstandarder.

Klasse I: Højrisikoprodukter, herunder identitets- og adgangsstyring software; browsere; adgangskodeadministratorer; ondsindet software detektionsværktøjer; produkter, der bruger VPN'er; netværksstyringskonfiguration, overvågning og ressourcestyringsværktøjer; systemer til sikkerhedsinformation og hændelsesstyring (SIEM); værktøj til håndtering af programrettelser; software til administration af mobilenheder og apper; fjernadgang software; mikrocontrollere; operativsystemer; firewalls; routere og modemer; industrielt kontroludstyr; og enhver industriel IoT, der ikke er omfattet af klasse II.

Klasse II: Endnu højere risikoprodukter end klasse I. Indeholder nogle operativsystemer; firewalls; mikrocontrollere; industrielle routere og modemer; afbrydere; smartkort og læsere; sikre elementer; hardware sikkerhedsmoduler; smarte målere; indtrængen detektion; robotsensor- og aktuatorkomponenter; og IIoT-enheder, der bruges af enheder beskrevet i NIS 2.

Hvor de samme produkttyper er opført i klasse I og II, vil det korrekte niveau blive besluttet i henhold til risikofaktorer, såsom om et produkt kører i følsomme NIS 2-miljøer, kører med privilegeret adgang, bruges til at behandle personlige oplysninger, indeholder en sårbarhed som kunne påvirke en "flerhed" af mennesker; eller om det allerede har forårsaget uønskede virkninger.

Bilag I beskriver sikkerhedskravene til producenter af digitale produkter. De burde:

• Designes, udvikles og produceres for at sikre et "passende" sikkerhedsniveau
• Leveres fri for kendte sårbarheder, der kan udnyttes
• Leveres med sikker-ved-standard konfiguration
• Sørg for beskyttelse mod uautoriseret adgang
• Beskyt fortroligheden og integriteten af ​​personlige og andre data
• Behandl kun den minimale mængde data, der er nødvendig
• Beskyt tilgængeligheden af ​​væsentlige funktioner, såsom mod DDoS-angreb
• Designes, udvikles og produceres for at begrænse angrebsoverflader og reducere virkningen af ​​hændelser
• Overvåg intern aktivitet for at give relevante sikkerhedsrelaterede oplysninger

Bilag I indeholder også en lang liste over krav til sårbarhedshåndtering, herunder at fabrikanter dokumenterer og adresserer og afhjælper sårbarheder uden forsinkelse, regelmæssigt tester produktsikkerheden og offentliggør information om eventuelle fejl, de retter. CRA kræver også, at udviklere håndhæver politikker for afsløring af sårbarheder, deler oplysninger om fejl, giver en måde at distribuere sikkerhedsopdateringer på og gør det uden forsinkelse og gratis.

Rapportering og overensstemmelseskrav

Mens standardklasseproducenter effektivt selv kan vurdere, om et produkt er markedsklar, skal de i klasse I gennemgå en tredjeparts overensstemmelsesvurdering eller anvende harmoniserede standarder. Alternativt kunne de anvende europæiske cybersikkerhedscertificeringsordninger på deres produkter. De i klasse II skal gennemgå en tredjeparts overensstemmelsesvurdering.

CRA kræver også, at producenter underretter sikkerhedsbureauet ENISA inden for 24 timer efter at have fået kendskab til en aktivt udnyttet sårbarhed eller sikkerhedshændelse. Importører og distributører skal på samme måde informere producenterne om eventuelle nye fejl uden forsinkelse og potentielt nationale markedsovervågningsmyndigheder i tilfælde af alvorlige risici.

Kunne en ISMS hjælpe producenter?

Med bøder for manglende overholdelse fastsat til €15 millioner eller 2.5 % af den årlige omsætning, skal alle organisationer inden for rammerne overveje, hvordan de tilpasser sig den nye ordning. Hunton Andrews Kurth partner, David Dumont, fortæller ISMS.online at organisationer i nogle sektorer, som IoT-producenter af medicinsk udstyr, allerede kan have et forspring på grund af eksisterende regulatoriske krav. Hans kollega hos advokatfirmaet, Sarah Pearce, tilføjer, at organisationer fuldt ud overholder GDPR, som kræver "robuste sikkerhedskontroller og relaterede politikker og procedurer", bør finde overholdelse af CRA "opnåelig med begrænset justering".

Men det hele er måske ikke almindeligt.

"Overholdelse af strenge betingelser for at introducere og beholde digitale produkter på EU-markedet kan resultere i yderligere omkostninger," advarer Dumont. "Enhver sådan yderligere overholdelsesomkostninger kan gøre det sværere for små og mellemstore virksomheder at konkurrere på det digitale marked og kan hæmme teknologiske fremskridt."

Det er her en Informationssikkerhedsstyringssystem (ISMS) kunne hjælpe ved at understøtte ISO 27001-overholdelse og de robuste GDPR-manderede kontroller, politikker og procedurer citeret af Pearce.

"Der er et overlap mellem eksisterende europæiske og internationale cybersikkerhedsstandarder såsom ISO 27001 og nogle af de vigtigste cybersikkerhedskrav i CRA," forklarer Dumont. "Virksomheder, der overholder sådanne eksisterende standarder, vil være i stand til at udnytte dette, når de håndterer CRA-overholdelse."

Hvad er de potentielle problemer?

Nogle har hilst kommissionens forsøg på at forbedre grundlæggende sikkerhed og gennemsigtighed blandt teknologiske produkter velkommen. John Smith, CTO i Veracode EMEA, beskriver det som et "betegnende stykke lovgivning."

"Det bringer ikke kun mere gennemsigtighed til et område, der ofte er uigennemskueligt, men tilskynder også softwareleverandører, producenter og detailhandlere til at øge cybersikkerheden for de produkter, de sælger, samt hjælper købere med nemt at vælge produkter, der er robuste," tilføjer han. "Forhåbentlig vil dette tilskynde organisationer til at gå ud over de obligatoriske krav og sætte sikkerhed højere på dagsordenen."

Andre har dog alvorlige bekymringer. Den almennyttige rettighedsgruppe Electronic Frontier Foundation fremhæver to potentielt alvorlige implikationer, hvis CRA godkendes i sin nuværende form:

Åben kilde: Enhver open source-udvikler, der anmoder om donationer eller opkræver betaling for supporttjenester til deres software, er erstatningsansvarlige, hvis deres "produkt" indeholder en fejl, der trænger ind i andre produkter. I betragtning af den komplekse, indbyrdes forbundne karakter af open source software forsyningskæde, kan dette have en afkølende effekt på industrien og kan tvinge udviklere til at forlade regionen helt.

Afsløring af sårbarhed: For det første kan den meget korte (24-timers) tidsramme for rapportering af nye sårbarheder til ENISA tilskynde til hurtige, men "overfladiske" rettelser, som ikke løser hovedårsagen til problemer. For det andet rapporterer ENISA efterfølgende til medlemslandenes Computer Security Incident Response Teams (CSIRT'er) og markedsovervågningsmyndigheder. EFF er bekymret for, at statslige hackere kan udnytte disse sårbarhedsoplysninger og/eller lække ud til cyberkriminalitetssamfundet.

Desværre ser det ikke ud til, at lovgivere vil lytte til disse bekymringer.

"Med cyberangreb, der ubestrideligt er steget i de senere år, med enorm økonomisk og samfundsmæssig indvirkning, er behovet for nogle statslige indgreb klart og opvejer uden tvivl opvejer sådanne bekymringer," slutter Pearce.