Die voortdurende stryd om sekuriteit deur ontwerp

Wanneer dit kom by veiligheidsprobleme met nuwe, komplekse produkte, is die samelewing se reaksie tipies konsekwent: blameer eerstens die gebruiker. Eers later moet jy die vervaardiger aanspreeklik hou vir inherente ontwerpfoute in hul produkte. Ons het dit gesien met motors en toe met rekenaars. Maar net soos die motor verander het, is houdings in die IT-industrie ook besig om te ontwikkel.

Die eerste motors het in die laat 1890's in die VSA te koop gegaan. Daarna het 'n rits staatsveiligheidswette gekom. Connecticut het die eerste spoedgrens in 1901 ingestel. Toe kom die eerste verkeersligte. New York het die eerste wet op drankbestuur in 1910 aanvaar. Uiteindelik (maar stadig), het state begin om bestuurders te lisensieer en hulle selfs af en toe te toets.

Straf die gebruiker, spaar die verkoper

Hierdie maatreëls om bestuurdersgedrag te beheer was almal belangrik, maar niemand het die motorverkopers aanspreeklik gehou vir die ontwerp van veiligheid in hul produkte, om mee te begin nie. Dit was eers in 1965 toe Ralph Nader sy onthullingsboek oor voertuigveiligheid, Onveilig teen enige spoed, gepubliseer het dat verbruikers daaraan begin dink het om veiliger motors te eis. ’n Jaar later het die Kongres die Wet op Nasionale Verkeers- en Motorvoertuigveiligheid goedgekeur, wat die Departement van Vervoer geskep het en uiteindelik motorverkopers gedwing het om veiligheidsgordels in voertuie te sit.

Die kongres het daardie veiligheidsgordelwet goedgekeur 60 jaar nadat die eerste Ford Model T van die produksielyn afgerol het. Dit is dan miskien nie verbasend dat 42 jaar nadat IBM die rekenaar bekend gestel het, daar is amper geen wette nie tegnologie-produkverkopers insgelyks aanspreeklik te hou vir die veiligheid van hul produkte.

Die enigste werklike wette wat rekenaarveiligheid vandag reguleer, is daar om die gebruikers te polisieer. Die Wet op Rekenaarbedrog en Misbruik (CFAA), wat ontwerp is om kuberveiligheidsindringing te stop, is byna 40 jaar gelede goedgekeur en is sedertdien nie noemenswaardig opgedateer nie. Die Digital Millennium Copyright Act (DMCA) fokus daarop om mense te verhoed om digitale kopieregkontroles te omseil.

Word wakker met sekuriteit deur ontwerp

Nou is daar 'n toegewyde poging om vervaardigers te kry om die regte ding te doen en sekuriteit in hul produkte in te bou tydens die ontwerpfase eerder as as 'n na-mark-byvoeging. In April 2023 het die Cybersecurity and Infrastructure Security Agency (CISA) sy leiding oor veilige produkontwerp gepubliseer: Verskuiwing van die balans van kuberveiligheidsrisiko: beginsels en benaderings vir sekuriteit-deur-ontwerp en -verstek.

Sekuriteit deur ontwerp bou sekuriteit in vanaf die ontwerpfase eerder as as 'n nagedagte of na-mark-byvoeging. Sekuriteit verseker by verstek dat sekuriteit aangeskakel is om gebruikers uit die boks te beskerm sonder bykomende koste.

Die beginsels van die gesamentlike advies sluit 'n paar oënskynlike no-brainer in. Dit waarsku byvoorbeeld dat die las van sekuriteit nie net op die kliënt moet val nie. Sagtewareverkopers moet "eienaarskap neem van die sekuriteitsuitkomste van hul kliënt se aankoop." Dit was ook 'n strategiese doelwit in die Withuis se Maart 2023 Nasionale Kuberveiligheidstrategie.

Nog 'n ander is "radikale deursigtigheid", waarin sagtewareverkopers moet trots wees daarop om veilige produkte te skep, en te demonstreer hoe hulle dit doen.

Dit alles berus op die derde beginsel: die bou van 'n leierskapstruktuur wat hierdie doelwitte ondersteun. Senior bestuurders moet bereid wees om terugvoer van kliënte oor produksekuriteit in te samel en dan interne hulpbronne toe te wy om daardie kwessies aan te spreek. Daardie organisatoriese struktuur kan beteken dat 'n spesifieke persoon verantwoordelik is vir sagteware-sekuriteit, voeg die dokument by.

Die probleem met verkopersaanspreeklikheid

Sekuriteit deur ontwerp klink na 'n eenvoudige voorstel, maar advokate staar verskeie harde uitdagings in die gesig, waarvan baie geldelik is.

Eerstens is die aanvaarding van verantwoordelikheid vir sagteware-sekuriteit 'n aansienlike risiko vir sagtewareverkopers, wie se kliënte elke dag groot verliese waag as gevolg van foute in hul sagteware. Slegs in baie uiterste gevalle ly hierdie verkopers finansieel. Byvoorbeeld, SolarWinds se versekeraars betaal $26 miljoen aan kliënte in 'n skikking nadat sy gekompromitteerde sagteware ongeveer 18,000 2020 organisasies in XNUMX geraak het.

Vir elke tegnologieverkoper wat daarna streef om hul produkte van die grond af te beveilig, sal daar baie wees wat dit nie doen nie. Die Wit Huis het hom daartoe verbind om met die Kongres saam te werk om wetgewing te ontwikkel wat verskaffersaanspreeklikheid vir tegnologiese produksekuriteit bepaal, maar aangesien ons 'n verkiesingsjaar binnegaan en die Kongres skaars oor genoeg kan saamstem om die regering aan die gang te hou, lyk die kanse hiervoor skraal.

Vir eers kan dit die kliënt se taak wees om hulle te dwing om te verander. CISA beveel aan dat maatskappye met hul beursies stem, en hul verskaffers se pogings om produkte deur ontwerp en verstek te beveilig, beoordeel. Die Wit Huis help. In Julie is dit aangekondig die US Trust Mark, 'n kuberveiligheidsgraderingstelsel om verbruikers te help om gekoppelde toestelle te evalueer.

Daar is ander uitdagings vir verkopersaanspreeklikheid. Alhoewel sommige sekuriteitsfoute die verkoper se skuld kan wees, sal daar baie wees waar die verkoper die kliënt kan blameer vir die misbruik of verkeerde opstelling van die sagteware.

Een hulpmiddel om te help om sulke misbruik van kliënte te voorkom, is die sagteware-magtigingsprofiel. Hierdie ingeboude sekuriteitstaktiek, wat deur CISA in sy leiding uitgelig word, beveel aan hoe gebruikers van sekere tipes die sagteware moet gebruik, insluitend die uiteensetting van toegangsregte vir daardie verskillende rolle. Dit keer dat die poskamertoesighouer toegang kry tot dieselfde funksies in die onderneming se hulpbronbeplanningstelsel as byvoorbeeld die verkoopshoof. Ervare sagtewareverkopers kan gebruikers waarsku as hulle probeer om van die profiel af te wyk.

Koste en kompleksiteit

Ingeboude sekuriteit is kompleks en duur. Soos die gesamentlike advies uitwys: "Veilig-deur-ontwerp-ontwikkeling vereis die belegging van aansienlike hulpbronne deur sagtewarevervaardigers by elke laag van die produkontwerp- en ontwikkelingsproses wat nie later kan 'aangebou' word nie."

Dit is veral problematies wanneer dit met verouderde sagteware en hardeware produkte te doen het. Baie sagtewareverkopers werk met monolitiese nalatenskapkode wat oor jare ontwikkel is wat bros en moeilik is om op te dateer. Dit is moeiliker om op te dateer as modulêre sagteware, met baie onafhanklike en los-gekoppelde komponente.

Maatskappye kan hierdie tegniese skuld geleidelik oor verskeie produkiterasies afbetaal, maar dit verg aansienlike hulpbronne om daardie sagteware terug te skil na die fondamente en sekuriteit van die grond af te herstruktureer.

Veilige ontwerp: 'n Ondankbare taak

Dit bring ons by die volgende probleem: sigbaarheid, of die gebrek daaraan.

Produseer 'n blink, hoogs sigbare nuwe kenmerk soos generatiewe KI, en jy sal kliënte in die versoeking bring om óf die volgende weergawe van jou produk te koop óf hul intekening te behou. Omgekeerd, aanpassing kode onder die enjinkap om veiliger te wees en goed georganiseerd is lofwaardig maar ondankbaar; dit is nie veel van 'n verkoopspunt vir baie kliënte nie. 'n Webwerf wat sê "Nou veilig van binne na buite" sal waarskynlik die antwoord vra: "Wat, jy bedoel dit was in die eerste plek nie so veilig nie?"

Sekuriteit was nog altyd 'n bietjie soos eiendom of lewensversekering: jy moet dit doen, maar dit is moeilik om te verkoop. Om jou eie nie-sekuriteitsprodukte veiliger te maak, genereer nie direkte inkomste nie. Die verkoop van na-mark sekuriteitsprodukte soos teen-wanware sagteware en firewalls is egter winsgewend.

Taktiek vir sekuriteit deur ontwerp

Met dit alles gesê, moet die uitdagings ons nie daarvan weerhou om sekuriteit deur ontwerp na te streef nie. Organisasies kan sekere taktieke aanneem wat sal help om sagtewaresekuriteit van die begin af aan te moedig. Een hiervan, wat in die CISA-leiding uitgelig word, is die gebruik van geheue-veilige tale.

Sommige tradisionele laevlak-programmeertale, veral C en C++, laat programmeerders toe om areas van geheue te manipuleer wat hulle nie moet nie. Hulle kan geheue lees wat sensitiewe inligting of onvanpaste kode kan bevat. Hulle kan ook verander hoe ander programme loop of hulle in 'n verwarde toestand plaas, wat hulle kwesbaar maak vir aanvalle.

Bedryfstelselverkopers het geheuebeskermingsmaatreëls ingestel, maar CISA sê dat dit op hul eie onvoldoende is. In plaas daarvan beveel dit aan om programmeertale met ingeboude geheuebeskermingsmaatreëls te gebruik, soos C#, Go of Rust.

Om hierdie probleem van die begin af te hanteer, kan aansienlike sekuriteitsverbeterings oplewer. In 2019, Microsoft-ingenieurs gesê dat ongeveer sewe uit tien van alle kwesbaarhede in Microsoft-produkte te wyte was aan geheueveiligheidsprobleme.

Wie lei in sekuriteit deur ontwerp

Verskeie regerings- en bedryfsgroepe het reeds veilige ontwerpbeginsels en -raamwerke wat op verskeie vlakke van die tegnologiestapel fokus. Aan die sagteware kant sluit dit in NIST se veilige sagteware-ontwikkelingsraamwerk en 'n industriewye inisiatief vir veilige sagteware-ontwikkeling genaamd SafeCode. Daar is ook 'n paar pogings om sekuriteit in spesifieke gebiede in te bou, soos webtoepassingsontwerp, deur OWASP se veilige ontwerpbeginsels.

Aan die hardewarekant werk maatskappye al jare saam aan betroubare platformmodule (TPM)-stelsels wat fisies geheime in peutervaste silikon op die moederbord stoor. Op hierdie stadium kan jy nie Windows 11 installeer sonder 'n weergawe 2.0 TPM nie.

'n Wedloop na die bodem (van die stapel)

Microsoft se aandrang op TPM-hardeware is 'n voorbeeld van hoe sommige verskaffers hul bes doen om sekuriteit deur ontwerp aan te pak, wat met mekaar saamwerk om sekuriteitskettings te skep wat in die silikon begin en tot in die bedryfstelsel uitbrei.

Een voorbeeld is Secure Boot, 'n sekuriteitskenmerk wat kodes stoor wat deur die vervaardiger goedgekeur is, wat bewys dat verskeie komponente op die stelsel, soos die firmware en die bedryfstelsel, wettig is. Dit maak staat op 'n TPM, saam met Unified Extensible Firmware Interface (UEFI), die moderne weergawe van rekenaarfirmware - die ding wat die res van die rekenaar laat loop en selflaai wanneer dit aanskakel.

Deur kode op laer stelselvlakke te verifieer en te beskerm, poog die bedryfstelselverskaffers en oorspronklike toerustingvervaardigers om volledige beheer te verseker oor alles wat op daardie kode staatmaak. Hierdie beskermings is egter onderhewig aan hul eie sekuriteitsfoute, net soos alles anders. In Secure Boot se geval het 'n kwesbaarheidskode genaamd Baton Drop aanvallers toegelaat om 'n UEFI-wortelstel genaamd BlackLotus bekend te stel wat hierdie beskerming omseil het, wat aanvallers in staat stel om die stelsel vir sy aanvallers te besit.

Aanvalle soos hierdie beteken nie dat ons nie sekuriteit deur ontwerp en verstek moet nastreef nie. Om van die begin af meer sekuriteit in die stelsel in te dryf, druk die naald in die verdedigers se guns en maak aanvalle moeiliker. Maar aanvalle soos BlackLotus wys dat selfs sekuriteit wat tydens die ontwerpfase opgelê is, omseil kan word. Die antwoord is om veelvuldige lae en fasette van beskerming in stelsels te ontwerp, die aanvaloppervlak tot die minimum te beperk en verskeie hindernisse te bied vir aanvallers om te oorkom.

Regulasies

Regerings raak ernstig oor sekuriteit deur ontwerp, met verskeie wetgewende maatreëls hetsy hier of in die werke. In die VSA, Kalifornië en Oregon het IoT-sekuriteitswette deurgevoer. Dit vereis dat individuele gekoppelde toestelle óf unieke voorafgeprogrammeerde wagwoorde moet hê óf gebruikers dwing om 'n nuwe manier van stawing te genereer voordat hulle vir die eerste keer toegang tot die toestel kan kry.

In die Verenigde Koninkryk sal die Wet op Produksekuriteit en Telekommunikasie die basislynsekuriteitsvereistes vir gekoppelde produkte uit die kassie verplig. Dit sluit in unieke wagwoorde, inligting oor die rapportering van sekuriteitskwessies met 'n produk, en die minimum ondersteuningstydperk vir sekuriteitsopdaterings.

Dit is 'n begin, maar mis steeds 'n paar geleenthede om robuuste sekuriteit deur ontwerp oor noodsaaklike produkte af te dwing. Byvoorbeeld, rekenaar- en skootrekenaars en tablette is uitgesluit van die Britse wetgewing, asook mediese toestelle, slimmeters en slimfone. Ten minste is jou gekoppelde ketels en websekuriteitskameras gedek.

Die probleem met sulke wette is om die balans tussen doeltreffendheid en kompleksiteit te vind. Wette wat die toepassing van sekuriteitsbeginsels mikrobestuur, is moeilik om te polisieer en by te werk. Nietemin, mandaat die aansoek en dokumentasie van a veilige sagteware-ontwikkeling lewensiklus sal help om baie produkte te beveilig.

Die EU hoop ook om die ingeboude sekuriteitskwessie op 'n blokvlak aan te spreek. In September 2022 het dit konsepwetgewing gepubliseer, veel strenger as die Britse wet, wat kuberveiligheidsreëls sou verskerp om beter produksekuriteit af te dwing. Die Wet op Kuberveerkragtigheid sal vervaardigers dwing om die sekuriteit van produkte deur die hele produklewensiklus te verbeter.

Leer uit die geskiedenis

Die rekenaarbedryf se benadering tot sekuriteit deur ontwerp is tans waar die motorbedryf s'n in die middel-sestigerjare was. Kuberveiligheid het 'n wydverspreide openbare bekommernis geword, en sommige organisasies het benaderings tot ingeboude sekuriteit op 'n vrywillige basis ondersoek om hulself te onderskei en hul gebruikers te beskerm.

Nou druk regerings die kwessie geleidelik met wetgewing. Daar is 'n lang pad om te stap, deels omdat die kompleksiteit van IT-oplossings en die digitale voorsieningskettings wat hulle ondersteun, 'n orde van grootte groter is as dié vir die pre-digitaliseringsmotorsektor.

Sommige dinge bly dieselfde, veral verbruikersgebrek aan bewustheid of ambivalensie. Toe die VSA die insluiting van veiligheidsgordels in motors beveel het, was die gebruik daarvan vrywillig. Toe die eerste state amper twee dekades later die gebruik van veiligheidsgordels begin vereis het, het minder as een uit elke vyf mense dit gebruik. Dit sal aan regerings en verskaffers wees om beter sekuriteit in tegnologieprodukte af te dwing en te verseker dat dit by verstek vir gebruikers aangeskakel is.