Den igangværende kamp for sikkerhed ved design

Når det kommer til sikkerhedsproblemer med nye, komplekse produkter, er samfundets reaktion typisk konsekvent: for det første skal du give brugeren skylden. Først senere bør du holde producenten ansvarlig for iboende designfejl i deres produkter. Vi så det med biler og så med computere. Men ligesom bilen ændrede sig, udvikler holdningerne sig også i IT-branchen.

De første biler kom til salg i USA i slutningen af ​​1890'erne. Derefter kom en række statslige sikkerhedslove. Connecticut indførte den første hastighedsgrænse i 1901. Så kom de første trafiklys. New York vedtog den første spirituskørselslov i 1910. Til sidst (men langsomt) begyndte stater at give licens til chauffører og endda lejlighedsvis teste dem.

Straf brugeren, skån sælgeren

Disse foranstaltninger til at styre føreradfærd var alle vigtige, men ingen holdt billeverandørerne ansvarlige for at designe sikkerhed i deres produkter til at begynde med. Det var først i 1965, da Ralph Nader udgav sin bog om køretøjssikkerhed, Unsafe at Any Speed, at forbrugerne begyndte at tænke på at efterspørge sikrere biler. Et år senere vedtog kongressen National Traffic and Motor Vehicle Safety Act, der skabte Transportministeriet og til sidst tvang billeverandører til at sætte sikkerhedsseler i køretøjer.

Kongressen vedtog denne selelov 60 år efter, at den første Ford Model T rullede ud af produktionslinjen. Det er måske ikke overraskende, at der 42 år efter, at IBM lancerede pc'en, er der næsten ingen love at holde leverandører af teknologiprodukter ansvarlige for deres produkters sikkerhed.

De eneste rigtige love, der styrer computersikkerhed i dag, er der for at overvåge brugerne. Computer Fraud and Abuse Act (CFAA), designet til at stoppe cybersikkerhedsindtrængen, blev vedtaget for næsten 40 år siden og er ikke blevet væsentligt opdateret siden. Digital Millennium Copyright Act (DMCA) fokuserer på at forhindre folk i at omgå digital ophavsretskontrol.

Vågner op til Security By Design

Nu er der en dedikeret indsats for at få producenterne til at gøre det rigtige og indbygge sikkerhed i deres produkter i designfasen snarere end som et eftermarkeds-tillæg. I april 2023 offentliggjorde Cybersecurity and Infrastructure Security Agency (CISA) sin vejledning om sikkert produktdesign: Forskydning af balancen mellem cybersikkerhedsrisici: principper og tilgange til design-for-design og -standard.

Security by design bygger sikkerhed ind fra designfasen og frem i stedet for som en eftertanke eller et eftermarkedstillæg. Sikkerhed sikrer som standard, at sikkerheden er slået til for at beskytte brugerne ud af boksen uden ekstra gebyrer.

Den fælles rådgivnings principper omfatter nogle tilsyneladende no-brainer. For eksempel advarer den om, at byrden af ​​sikkerhed ikke udelukkende bør påhvile kunden. Softwareleverandører bør "tage ejerskab over sikkerhedsresultaterne af deres kundes køb." Dette var også et strategisk mål i Det Hvide Hus' marts 2023 National Cybersikkerhedsstrategi.

En anden er "radikal gennemsigtighed", hvor softwareleverandører bør være stolte af at skabe sikre produkter og demonstrere, hvordan de gør det.

Alt dette bygger på det tredje princip: opbygning af en ledelsesstruktur, der understøtter disse mål. Seniorledere skal være villige til at indsamle kundefeedback om produktsikkerhed og derefter dedikere interne ressourcer til at løse disse problemer. Den organisatoriske struktur kan betyde, at man dedikerer en specifik person, der er ansvarlig for softwaresikkerhed, tilføjer dokumentet.

Problemet med leverandørens ansvar

Sikkerhed ved design lyder som et simpelt forslag, men fortalere står over for flere barske udfordringer, hvoraf mange er monetære.

For det første er det en betydelig risiko for softwareleverandører at tage ansvar for softwaresikkerhed, hvis kunder hver dag risikerer store tab på grund af fejl i deres software. Kun i meget ekstreme tilfælde lider disse leverandører økonomisk. Eksempelvis SolarWinds' forsikringsselskaber betalt 26 millioner USD til kunder i et forlig, efter at dets kompromitterede software påvirkede omkring 18,000 organisationer i 2020.

For hver teknologileverandør, der stræber efter at sikre deres produkter fra bunden, vil der være masser, der ikke gør det. Det Hvide Hus har forpligtet sig til at samarbejde med Kongressen om at udvikle lovgivning, der etablerer leverandøransvar for teknologiproduktsikkerhed, men da vi går ind i et valgår, og Kongressen knap kan blive enige om nok til at holde regeringen kørende, synes chancerne for dette små.

For øjeblikket kan det være kundens opgave at tvinge dem til at skifte. CISA anbefaler, at virksomheder stemmer med deres tegnebøger og vurderer deres leverandørers indsats for at sikre produkter ved design og standard. Det Hvide Hus hjælper. I juli, det annoncerede US Trust Mark, et cybersikkerhedsvurderingssystem, der hjælper forbrugere med at vurdere tilsluttede enheder.

Der er andre udfordringer med leverandørens ansvar. Selvom nogle sikkerhedsfejl kan være leverandørens fejl, vil der være mange, hvor leverandøren kan bebrejde kunden for at misbruge eller fejlkonfigurere softwaren.

Et værktøj til at forhindre sådan kundemisbrug er softwareautorisationsprofilen. Denne indbyggede sikkerhedstaktik, fremhævet af CISA i sin vejledning, anbefaler, hvordan brugere af visse typer skal bruge softwaren, herunder skitsering af adgangsprivilegier for disse forskellige roller. Dette forhindrer postrummets supervisor i at få adgang til de samme funktioner i virksomhedens ressourceplanlægningssystem som f.eks. salgschefen. Erfarne softwareleverandører kan advare brugere, hvis de forsøger at afvige fra profilen.

Omkostninger og kompleksitet

Indlejret sikkerhed er kompleks og dyr. Som den fælles rådgivning påpeger: "Secure-by-Design-udvikling kræver, at softwareproducenterne investerer betydelige ressourcer på hvert lag af produktdesign- og udviklingsprocessen, som ikke kan 'boltes på' senere."

Dette er især problematisk, når man har at gøre med ældre software- og hardwareprodukter. Mange softwareleverandører arbejder med monolitisk legacy-kode udviklet over år, som er skør og svær at opdatere. Dette er sværere at opdatere end modulær software med mange uafhængige og løst koblede komponenter.

Virksomheder kan nedbetale denne tekniske gæld gradvist på tværs af flere produktiterationer, men det kræver betydelige ressourcer at skrælle denne software tilbage til fundamentet og omstrukturere sikkerheden fra bunden.

Sikkert design: En utaknemmelig opgave

Det bringer os til det næste problem: synlighed eller manglen på samme.

Fremstil en skinnende, meget synlig ny funktion som generativ AI, og du vil friste kunder til enten at købe den næste version af dit produkt eller opretholde deres abonnement. Omvendt justeres kode under hætten for at være mere sikker og velorganiseret er prisværdigt, men utaknemmeligt; det er ikke meget af et salgsargument for mange kunder. Et websted, der siger "Sikker nu indefra og ud" vil sandsynligvis få svaret: "Hvad, du mener, det var ikke så sikkert i første omgang?"

Sikkerhed har altid været lidt ligesom ejendoms- eller livsforsikring: du skal gøre det, men det er svært at sælge. At gøre dine egne ikke-sikkerhedsprodukter mere sikre genererer ikke direkte indtægter. Det er dog lukrativt at sælge eftermarkedssikkerhedsprodukter som anti-malware-software og firewalls.

Taktik for sikkerhed ved design

Når alt dette er sagt, bør udfordringerne ikke afholde os fra at forfølge sikkerhed ved design. Organisationer kan vedtage nogle taktikker, der vil hjælpe med at fremme softwaresikkerhed fra begyndelsen. En af disse, fremhævet i CISA-vejledningen, er brugen af ​​hukommelsessikre sprog.

Nogle traditionelle programmeringssprog på lavt niveau, især C og C++, tillader programmører at manipulere områder af hukommelsen, som de ikke burde. De kan læse hukommelse, der kan indeholde følsomme oplysninger eller upassende kode. De kan også ændre, hvordan andre programmer kører, eller sætte dem i en forvirret tilstand, hvilket gør dem sårbare over for angreb.

Operativsystemleverandører har indført hukommelsesbeskyttelsesforanstaltninger, men CISA siger, at disse er utilstrækkelige i sig selv. I stedet anbefaler det at bruge programmeringssprog med indbyggede hukommelsessikringer, som C#, Go eller Rust.

Håndtering af dette problem fra begyndelsen kan give betydelige sikkerhedsforbedringer. I 2019, Microsoft ingeniører sagde at omkring syv ud af ti af alle sårbarheder i Microsoft-produkter skyldtes problemer med hukommelsessikkerhed.

Hvem er førende inden for sikkerhed ved design

Flere regerings- og industrigrupper har allerede sikre designprincipper og rammer med fokus på forskellige niveauer af teknologistakken. På softwaresiden omfatter disse NIST's Secure Software Development Framework og et branchedækkende initiativ til sikker softwareudvikling kaldet SafeCode. Der er også nogle bestræbelser på at bygge sikkerhed ind i specifikke områder, såsom webapplikationsdesign, igennem OWASPs sikre designprincipper.

På hardwaresiden har virksomheder i årevis arbejdet sammen om TPM-systemer (trusted platform module), der fysisk gemmer hemmeligheder i manipulationssikkert silicium på bundkortet. På dette tidspunkt kan du ikke installere Windows 11 uden en version 2.0 TPM.

Et kapløb til bunden (af stakken)

Microsofts insisteren på TPM-hardware er et eksempel på, hvordan nogle leverandører gør deres bedste for at tackle sikkerhed ved design, og samarbejder med hinanden for at skabe sikkerhedskæder, der begynder i silicium og strækker sig ind i operativsystemet.

Et eksempel er Secure Boot, en sikkerhedsfunktion, der gemmer koder godkendt af producenten, som beviser, at forskellige komponenter på systemet, såsom firmwaren og operativsystemet, er legitime. Dette er afhængigt af en TPM sammen med Unified Extensible Firmware Interface (UEFI), den moderne version af computerfirmware - den ting, der kører og bootstrapper resten af ​​computeren, når den tændes.

Ved at verificere og beskytte kode på lavere systemniveauer sigter operativsystemleverandørerne og producenterne af originalt udstyr på at sikre fuldstændig kontrol over alt, der er afhængigt af denne kode. Disse beskyttelser er dog underlagt deres egne sikkerhedsbrister, ligesom alt andet. I Secure Boots tilfælde tillod en sårbarhedskode ved navn Baton Drop angribere at introducere et UEFI-rootkit kaldet BlackLotus, der omgik disse beskyttelser, hvilket gjorde det muligt for angribere at eje systemet til dets angribere.

Angreb som disse betyder ikke, at vi ikke skal forfølge sikkerhed ved design og standard. At drive mere sikkerhed ind i systemet fra begyndelsen skubber nålen i forsvarernes favør og gør angreb vanskeligere. Men angreb som BlackLotus viser, at selv sikkerhed pålagt under designfasen kan omgås. Svaret er at designe flere lag og facetter af beskyttelse i systemer, minimere angrebsoverfladen og give flere forhindringer for angribere at overvinde.

forordninger

Regeringer bliver seriøse med sikkerhed ved design, med adskillige lovgivningsmæssige foranstaltninger enten her eller i værkerne. I USA har Californien og Oregon vedtaget IoT-sikkerhedslove. Disse kræver, at individuelle tilsluttede enheder enten har unikke forprogrammerede adgangskoder eller tvinger brugerne til at generere en ny godkendelsesmetode, før de kan få adgang til enheden for første gang.

I Storbritannien vil produktsikkerheds- og telekommunikationsloven påbyde grundlæggende sikkerhedskrav for tilsluttede produkter ud af kassen. Disse omfatter unikke adgangskoder, oplysninger om rapportering af sikkerhedsproblemer med et produkt og minimumssupportperioden for sikkerhedsopdateringer.

Dette er en begyndelse, men savner stadig nogle muligheder for at håndhæve robust sikkerhed ved design på tværs af vigtige produkter. For eksempel er stationære og bærbare computere og tablets udelukket fra britisk lovgivning, ligesom medicinsk udstyr, smarte målere og smartphones. I det mindste er dine tilsluttede elkedler og webovervågningskameraer dækket.

Problemet med sådanne love er at finde balancen mellem effektivitet og kompleksitet. Love, der mikrostyrer anvendelsen af ​​sikkerhedsprincipper, er vanskelige at kontrollere og opdatere. Ikke desto mindre påbud om ansøgning og dokumentation af en sikker softwareudviklings livscyklus ville være med til at sikre mange produkter.

EU håber også at løse det indbyggede sikkerhedsproblem på blokniveau. I september 2022 offentliggjorde den et udkast til lovgivning, langt strengere end den britiske lov, der ville stramme cybersikkerhedsreglerne for at håndhæve bedre produktsikkerhed. Lov om cyberresiliens ville tvinge producenterne til at forbedre produkternes sikkerhed gennem hele produktets livscyklus.

Lær af historien

PC-industriens tilgang til security by design er i øjeblikket, hvor bilindustriens var i midten af ​​tresserne. Cybersikkerhed er blevet en udbredt offentlig bekymring, og nogle organisationer har udforsket tilgange til indbygget sikkerhed på frivillig basis for at differentiere sig og beskytte deres brugere.

Nu presser regeringerne gradvist på spørgsmålet med lovgivning. Der er lang vej igen, blandt andet fordi kompleksiteten af ​​it-løsninger og de digitale forsyningskæder, der understøtter dem, er en størrelsesorden større end for den før-digitaliserede bilindustri.

Nogle ting forbliver de samme, især forbrugernes manglende bevidsthed eller ambivalens. Da USA gav mandat til at inkludere sikkerhedsseler i biler, var brugen af ​​dem frivillig. Da de første stater begyndte at kræve brug af sikkerhedsseler næsten to årtier senere, brugte færre end hver femte mennesker dem. Det vil være op til regeringer og leverandører at håndhæve bedre sikkerhed i teknologiprodukter og sikre, at de er tændt for brugere som standard.