Als het om veiligheidsproblemen met nieuwe, complexe producten gaat, is de reactie van de maatschappij doorgaans consistent: geef eerst de gebruiker de schuld. Pas later moet u de fabrikant verantwoordelijk stellen voor inherente ontwerpfouten in hun producten. We hebben dit gezien met auto's en vervolgens met computers. Maar net zoals de auto veranderde, evolueerde ook de houding in de IT-industrie.

Eind jaren negentig van de negentiende eeuw kwamen de eerste auto's in de VS op de markt. Daarna volgde een hele reeks staatsveiligheidswetten. Connecticut introduceerde de eerste snelheidslimiet in 1890. Toen kwamen de eerste verkeerslichten. New York keurde in 1901 de eerste wet op rijden onder invloed goed. Uiteindelijk (maar langzaam) begonnen staten chauffeurs een vergunning te verlenen en deze zelfs af en toe te testen.

Straf de gebruiker, spaar de verkoper

Deze maatregelen om het rijgedrag te reguleren waren allemaal belangrijk, maar niemand hield de autoverkopers om te beginnen verantwoordelijk voor het inbouwen van de veiligheid in hun producten. Pas in 1965, toen Ralph Nader zijn boek over voertuigveiligheid, Unsafe at Any Speed, publiceerde, begonnen consumenten na te denken over het eisen van veiligere auto's. Een jaar later keurde het Congres de National Traffic and Motor Vehicle Safety Act goed, waardoor het Department of Transportation werd opgericht en uiteindelijk autoverkopers werden gedwongen veiligheidsgordels in voertuigen te plaatsen.

Het congres keurde de wet op de veiligheidsgordel goed, zestig jaar nadat de eerste Ford Model T van de productielijn rolde. Het is dan ook misschien niet verrassend dat 60 jaar nadat IBM de pc lanceerde, die er wel zijn bijna geen wetten leveranciers van technologieproducten op dezelfde manier verantwoordelijk houden voor de veiligheid van hun producten.

De enige echte wetten die tegenwoordig de computerveiligheid regelen, zijn er om toezicht te houden op de gebruikers. De Computer Fraud and Abuse Act (CFAA), ontworpen om inbreuken op de cyberveiligheid te stoppen, werd bijna 40 jaar geleden aangenomen en is sindsdien niet noemenswaardig bijgewerkt. De Digital Millennium Copyright Act (DMCA) richt zich op het voorkomen dat mensen digitale auteursrechtcontroles omzeilen.

Wakker worden met veiligheid door ontwerp

Nu wordt er hard aan gewerkt om fabrikanten zover te krijgen dat ze het juiste doen en beveiliging in hun producten inbouwen in de ontwerpfase, in plaats van als een add-on voor de aftermarket. In april 2023 publiceerde de Cybersecurity and Infrastructure Security Agency (CISA) haar richtlijnen voor veilig productontwerp: De balans van cyberbeveiligingsrisico's verschuiven: principes en benaderingen voor Security-by-Design en -Default.

Security by design bouwt beveiliging in vanaf de ontwerpfase en niet als een bijzaak of een aftermarket-add-on. Beveiliging zorgt er standaard voor dat de beveiliging is ingeschakeld om gebruikers direct en zonder extra kosten te beschermen.

De principes van het gezamenlijke advies omvatten enkele schijnbare no-brainers. Er wordt bijvoorbeeld gewaarschuwd dat de last van de beveiliging niet uitsluitend op de klant mag rusten. Softwareleveranciers moeten “eigenaar worden van de beveiligingsresultaten van de aankoop van hun klanten.” Dit was ook een strategische doelstelling in maart 2023 van het Witte Huis Nationale Cybersecurity Strategie.

Een andere is ‘radicale transparantie’, waarbij softwareleveranciers er trots op moeten zijn dat ze veilige producten maken en laten zien hoe ze dat doen.

Dit alles berust op het derde principe: het opbouwen van een leiderschapsstructuur die deze doelen ondersteunt. Senior managers moeten bereid zijn feedback van klanten over productbeveiliging te verzamelen en vervolgens interne middelen in te zetten om deze problemen aan te pakken. Die organisatiestructuur zou kunnen betekenen dat er een specifieke persoon wordt aangewezen die verantwoordelijk is voor de softwarebeveiliging, voegt het document eraan toe.

Het probleem met leveranciersaansprakelijkheid

Security by design klinkt als een eenvoudig voorstel, maar voorstanders worden geconfronteerd met verschillende zware uitdagingen, waarvan er vele van monetaire aard zijn.

Ten eerste is het aanvaarden van de verantwoordelijkheid voor softwarebeveiliging een aanzienlijk risico voor softwareleveranciers, wier klanten dagelijks grote verliezen riskeren als gevolg van fouten in hun software. Alleen in zeer extreme gevallen lijden deze verkopers financieel. Bijvoorbeeld de verzekeraars van SolarWinds betaald $ 26 miljoen aan klanten in een schikking nadat de gecompromitteerde software in 18,000 ongeveer 2020 organisaties had getroffen.

Voor elke technologieleverancier die ernaar streeft zijn producten vanaf de basis te beveiligen, zullen er genoeg zijn die dat niet doen. Het Witte Huis heeft beloofd samen te werken met het Congres om wetgeving te ontwikkelen die de aansprakelijkheid van leveranciers voor de veiligheid van technologische producten vastlegt, maar nu we een verkiezingsjaar ingaan en het Congres het nauwelijks eens kan worden over genoeg om de regering draaiende te houden, lijkt de kans hierop klein.

Voorlopig is het misschien de taak van de klant om hen tot verandering te dwingen. CISA raadt bedrijven aan om met hun portemonnee te stemmen en de inspanningen van hun leveranciers te beoordelen om producten zowel qua ontwerp als qua standaard te beveiligen. Het Witte Huis helpt mee. In juli kondigde het het Amerikaanse Trust Mark aan, een cybersecurity-beoordelingssysteem om consumenten te helpen bij het evalueren van verbonden apparaten.

Er zijn nog andere uitdagingen op het gebied van de aansprakelijkheid van leveranciers. Hoewel sommige beveiligingsfouten de schuld van de leverancier kunnen zijn, zullen er ook vele zijn waarbij de leverancier de klant de schuld kan geven van misbruik of onjuiste configuratie van de software.

Eén hulpmiddel om dergelijk misbruik door klanten te helpen voorkomen, is het softwareautorisatieprofiel. Deze ingebouwde beveiligingstactiek, die door CISA in zijn richtlijnen wordt benadrukt, beveelt aan hoe gebruikers van bepaalde typen de software moeten gebruiken, inclusief het schetsen van toegangsrechten voor die verschillende rollen. Hierdoor heeft de postkamersupervisor geen toegang tot dezelfde functies in het Enterprise Resource Planning-systeem als bijvoorbeeld het hoofd verkoop. Slimme softwareleveranciers kunnen gebruikers waarschuwen als ze proberen af ​​te wijken van het profiel.

Kosten en complexiteit

Ingebouwde beveiliging is complex en duur. Zoals het gezamenlijke advies opmerkt: “Secure-by-Design-ontwikkeling vereist de investering van aanzienlijke middelen door softwarefabrikanten in elke laag van het productontwerp- en ontwikkelingsproces, die later niet kunnen worden ‘vastgeschroefd’.”

Dit is vooral problematisch als het gaat om oudere software- en hardwareproducten. Veel softwareleveranciers werken met monolithische oude code die in de loop der jaren is ontwikkeld en die broos en moeilijk te updaten is. Dit is moeilijker te updaten dan modulaire software, met veel onafhankelijke en losjes gekoppelde componenten.

Bedrijven kunnen deze technische schuld geleidelijk afbetalen over meerdere productversies, maar er zijn aanzienlijke middelen nodig om die software terug te brengen naar de basis en de beveiliging van de grond af aan te herstructureren.

Veilig ontwerp: een ondankbare taak

Dat brengt ons bij het volgende probleem: zichtbaarheid, of het gebrek daaraan.

Produceer een schitterende, goed zichtbare nieuwe functie, zoals generatieve AI, en u verleidt klanten om de volgende versie van uw product te kopen of hun abonnement te behouden. Omgekeerd: aanpassen code onder de motorkap voor meer veiligheid en goed georganiseerd is prijzenswaardig maar ondankbaar; het is voor veel klanten niet echt een verkoopargument. Een website die zegt: "Nu veilig van binnenuit" zal waarschijnlijk het antwoord oproepen: "Bedoel je dat het in de eerste plaats niet zo veilig was?"

Zekerheid is altijd een beetje zoals een eigendoms- of levensverzekering geweest: je moet het doen, maar het is moeilijk te verkopen. Het veiliger maken van uw eigen niet-beveiligingsproducten levert geen directe inkomsten op. Het verkopen van aftermarket-beveiligingsproducten zoals anti-malwaresoftware en firewalls is echter lucratief.

Tactieken voor beveiliging door ontwerp

Dit alles gezegd hebbende, mogen de uitdagingen ons er niet van weerhouden om security by design na te streven. Organisaties kunnen een aantal tactieken toepassen die vanaf het begin de softwarebeveiliging helpen bevorderen. Eén daarvan, die in de CISA-richtlijnen wordt benadrukt, is het gebruik van geheugenveilige talen.

Sommige traditionele programmeertalen op laag niveau, met name C en C++, stellen programmeurs in staat geheugengebieden te manipuleren die ze niet zouden moeten gebruiken. Ze kunnen geheugen lezen dat mogelijk gevoelige informatie of ongepaste code bevat. Ze kunnen ook de manier waarop andere programma's werken veranderen of deze in een verwarde staat brengen, waardoor ze kwetsbaar worden voor aanvallen.

Verkopers van besturingssystemen hebben maatregelen voor geheugenbescherming geïntroduceerd, maar CISA zegt dat deze op zichzelf onvoldoende zijn. In plaats daarvan raadt het aan programmeertalen te gebruiken met ingebouwde geheugenbeveiligingen, zoals C#, Go of Rust.

Als u dit probleem vanaf het begin aanpakt, kan dit aanzienlijke beveiligingsverbeteringen opleveren. In 2019, Microsoft-ingenieurs zei dat grofweg zeven op de tien van alle kwetsbaarheden in Microsoft-producten te wijten waren aan geheugenveiligheidsproblemen.

Wie is toonaangevend op het gebied van beveiliging door ontwerp

Verschillende overheids- en industriegroepen beschikken al over veilige ontwerpprincipes en -kaders die zich richten op verschillende niveaus van de technologiestapel. Aan de softwarekant omvatten deze Het Secure Software Development Framework van NIST en een branchebreed initiatief voor veilige softwareontwikkeling genaamd SafeCode. Er zijn ook enkele pogingen ondernomen om beveiliging in specifieke gebieden, zoals het ontwerp van webapplicaties, in te bouwen De veilige ontwerpprincipes van OWASP.

Aan de hardwarekant werken bedrijven al jaren samen aan Trusted Platform Module (TPM)-systemen die geheimen fysiek opslaan in fraudebestendig silicium op het moederbord. Op dit moment kunt u Windows 11 niet installeren zonder TPM versie 2.0.

Een race naar de bodem (van de stapel)

De nadruk van Microsoft op TPM-hardware is een voorbeeld van hoe sommige leveranciers hun best doen om security by design aan te pakken, waarbij ze met elkaar samenwerken om beveiligingsketens te creëren die beginnen in het silicium en zich uitstrekken tot in het besturingssysteem.

Een voorbeeld is Secure Boot, een beveiligingsfunctie die door de fabrikant goedgekeurde codes opslaat die bewijzen dat verschillende componenten van het systeem, zoals de firmware en het besturingssysteem, legitiem zijn. Dit is afhankelijk van een TPM, samen met Unified Extensible Firmware Interface (UEFI), de moderne versie van computerfirmware – het ding dat de rest van de computer uitvoert en opstart wanneer deze wordt ingeschakeld.

Door code op lagere systeemniveaus te verifiëren en te beschermen, streven de leveranciers van besturingssystemen en fabrikanten van originele apparatuur ernaar volledige controle te garanderen over alles dat afhankelijk is van die code. Deze beveiligingen zijn echter, net als al het andere, onderhevig aan hun eigen beveiligingsfouten. In het geval van Secure Boot stelde een kwetsbaarheidscode genaamd Baton Drop aanvallers in staat een UEFI-rootkit genaamd BlackLotus te introduceren die deze beveiligingen omzeilde, waardoor aanvallers het systeem voor hun aanvallers konden bezitten.

Aanvallen als deze betekenen niet dat we niet moeten streven naar beveiliging door het ontwerp en de standaardinstellingen. Door vanaf het begin meer beveiliging in het systeem te brengen, wordt de naald in het voordeel van de verdedigers gedrukt en worden aanvallen moeilijker. Maar aanvallen als BlackLotus laten zien dat zelfs tijdens de ontwerpfase opgelegde beveiliging kan worden omzeild. Het antwoord is om meerdere beschermingslagen en facetten van bescherming in systemen te ontwerpen, waardoor het aanvalsoppervlak wordt geminimaliseerd en meerdere hindernissen worden geboden die aanvallers moeten overwinnen.

reglement

Regeringen gaan serieus aan de slag met security by design, en er zijn diverse wetgevende maatregelen in voorbereiding of in de maak. In de VS hebben Californië en Oregon IoT-beveiligingswetten aangenomen. Deze vereisen dat individuele verbonden apparaten unieke, voorgeprogrammeerde wachtwoorden hebben of gebruikers dwingen een nieuw authenticatiemiddel te genereren voordat ze voor de eerste keer toegang krijgen tot het apparaat.

In Groot-Brittannië zal de Product Security and Telecommunications Act basisveiligheidseisen voor kant-en-klare aangesloten producten opleggen. Deze omvatten unieke wachtwoorden, informatie over het melden van beveiligingsproblemen met een product en de minimale ondersteuningsperiode voor beveiligingsupdates.

Dit is een begin, maar er ontbreken nog steeds enkele kansen om robuuste beveiliging door ontwerp af te dwingen voor essentiële producten. Desktop- en laptopcomputers en tablets zijn bijvoorbeeld uitgesloten van de Britse wetgeving, evenals medische apparaten, slimme meters en smartphones. In ieder geval zijn uw aangesloten waterkokers en webbeveiligingscamera's gedekt.

Het probleem met dergelijke wetten is het vinden van de balans tussen effectiviteit en complexiteit. Wetten die de toepassing van veiligheidsprincipes op microniveau regelen, zijn moeilijk te controleren en bij te werken. Niettemin is het verplicht stellen van de toepassing en documentatie van a veilige levenscyclus van softwareontwikkeling zou helpen om veel producten veilig te stellen.

De EU hoopt ook het ingebouwde veiligheidsprobleem op blokniveau aan te pakken. In september 2022 publiceerde het een ontwerpwetgeving, veel strenger dan de Britse wet, die de cyberbeveiligingsregels zou aanscherpen om een ​​betere productbeveiliging af te dwingen. De Wet Cyberweerbaarheid zou fabrikanten dwingen de veiligheid van producten gedurende de gehele levenscyclus van een product te verbeteren.

Leren van de geschiedenis

De benadering van de pc-industrie op het gebied van security by design is momenteel hetzelfde als die van de auto-industrie halverwege de jaren zestig. Cyberbeveiliging is een wijdverspreide publieke zorg geworden, en sommige organisaties hebben op vrijwillige basis benaderingen van ingebouwde beveiliging onderzocht om zich te onderscheiden en hun gebruikers te beschermen.

Nu dringen regeringen deze kwestie geleidelijk aan met wetgeving. Er is nog een lange weg te gaan, deels omdat de complexiteit van IT-oplossingen en de digitale toeleveringsketens die deze ondersteunen een orde van grootte groter is dan die voor de automobielsector vóór de digitalisering.

Sommige dingen blijven hetzelfde, met name het gebrek aan bewustzijn of ambivalentie bij de consument. Toen de VS de opname van veiligheidsgordels in auto's verplicht stelden, was het gebruik ervan vrijwillig. Toen de eerste staten bijna twintig jaar later het gebruik van veiligheidsgordels begonnen te eisen, gebruikte minder dan één op de vijf mensen deze. Het is aan overheden en leveranciers om een ​​betere beveiliging van technologieproducten af ​​te dwingen en ervoor te zorgen dat deze standaard zijn ingeschakeld voor gebruikers.