Gregory Rudy is directeur businessdevelopment bij de afdeling Integrity Security Services van Green Hills Software.

20 November 2015

Beveiligen van embedded devices is geen sinecure. Een aanvaller heeft vaak maar een enkel lek nodig om binnen te kunnen dringen. Gregory Rudy van Green Hills Software behandelt de vijf vragen die ontwikkelaars zich moeten stellen over hun beveiligingsontwerp.

Het aantal cyberaanvallen op netwerken blijft gestaag stijgen, en tegelijk neemt ook het aantal netwerkverbindingen steeds maar toe. Daarmee groeit de dreiging van oneigenlijk gebruik en dataverlies. Dergelijke inbreuken resulteren in verlies van intellectueel eigendom, en in verlies van het vertrouwen dat gebruikers hebben in embedded apparaten. Zij moeten er immers – soms met hun leven – op kunnen vertrouwen dat hardware en software werken zoals het hoort.

Als recente krantenkoppen ons iets hebben geleerd, is het dat we it-netwerken niet kunnen vertrouwen. Apparaten zijn niet langer veilig achter firewalls van het bedrijf. Als gevolg daarvan moeten beveiligingsontwerpen nu inspelen op de reële dreiging van aanvallers met onbeperkte netwerktoegang tot apparaten.

Van oudsher zijn de procedures om de kwaliteit van het productieproces te garanderen gericht op functionele tests en milieueisen. Maar de netwerkaanvallen waar apparaten nu aan worden blootgesteld, zijn niet in een testomgeving te reproduceren.

Veilig ontwerpen is een organisatiebrede opgave die krachtig ondersteund moet worden door het management. Om managers te helpen bij het beoordelen van de kwaliteit van hun beveiligingsontwerp, zijn er vijf vragen die iedere fabrikant zich moet stellen en voor zich moet beantwoorden.

1. Weigert je apparaat opdrachten die niet authentiek zijn?

Aanvallers gebruiken twee manieren om toegang te krijgen tot lokale netwerken: via informatiesystemen die reeds op een netwerk zijn aangesloten, of door in te breken in het fysieke netwerk. In beide gevallen kunnen aanvallers datapakketten bekijken en protocollen reverse-engineeren voor kwaadaardige doeleinden.

Oneigenlijk gebruik kan daarom worden voorkomen door allereerst alle devices, controlesystemen, gebruikers en andere it-systemen die data ontvangen op een netwerk te identificeren. Besturingssoftware mag alléén commando’s versturen na authenticatie op het apparaat, terwijl apparaten alléén opdrachten mogen accepteren na authenticatie van de gebruiker. Het beveiligingsontwerp mag nooit zomaar gebruikers of besturingssystemen accepteren alleen omdat de ontvangen informatie er goed uitziet.

Een bekend voorbeeld is een hack van infuuspompen die op een netwerk waren aangesloten. De software van de pomp nam aan dat elke opdracht van een geldige bron kwam. Aanvallers kregen echter toegang tot het netwerk om daarna het protocol te reverse-engineeren en zo de applicatie te misleiden. Het was hierdoor mogelijk om opdrachten te versturen waardoor in theorie dodelijke doses aan een patiënt toegediend hadden kunnen worden.

2. Kan je apparaat detecteren of ermee is geknoeid?

Er is een aantal manieren waarop malware kan worden geïnjecteerd in een embedded apparaat. Via een hardwaredebuginterface zoals Jtag kan het device opnieuw worden geprogrammeerd, en door het openlaten van ongebruikte test- en debuginterfaces zoals Telnet en FTP kan software worden aangepast. Ook kan code soms worden geïnjecteerd via besturingsinterfaces voor eindgebruikers, wanneer deze niet ontwikkeld zijn met codestandaarden gericht op security. Verder kan een software-updatemechanisme misbruikt worden als dat geen verificatiemechanisme toepast.

GHS Aanvalsboom
Aanvallers kunnen een slecht beveiligd netwerk op verschillende manieren uitbuiten.

Fysieke bescherming, het scannen van kwetsbare onderdelen en penetratietests kunnen helpen bij het voorkomen van geknoei met software. Maar deze maatregelen kunnen uiteindelijk niet het uitvoeren van gemanipuleerde software tegenhouden. Hiervoor is het nodig om cryptografisch ondertekende software te gebruiken. Met behulp van een beveiligde systeemstart zijn hiermee de bron en de integriteit van software te verifiëren voorafgaand aan elke uitvoer door het apparaat.

Het is essentieel dat het genereren van de digitale handtekeningen niet op het apparaat zelf gebeurt. De privésleutels die hiervoor worden gebruikt, mogen namelijk nooit in handen vallen van een aanvaller; die zou ze kunnen gebruiken om zijn eigen, gemanipuleerde software te ondertekenen. Wanneer deze sleutels niet op het apparaat aanwezig zijn, wordt het voor de aanvaller een stuk lastiger om ze buit te maken.

3. Hoe beschermt je apparaat zijn gegevens?

Intellectueel eigendom, configuratiebestanden, gebruikersgegevens, maar ook sleutels opgeslagen in bijvoorbeeld flashgeheugen zijn allemaal kwetsbaar als een aanvaller toegang krijgt tot een apparaat. Daarom zijn er beveiligingsprocedures nodig die de data beschermen, zowel tijdens de opslag als tijdens transport. Door scheiding en versleuteling en door de toegang tot geverifieerde software en gebruikers te beperken, kunnen data worden beschermd.

Sommige fabrikanten gaan ervan uit dat hun apparaten veilig communiceren omdat ze standaard encryptie gebruiken voor draadloze communicatie. Helaas, dit beschermt alleen de dataverbinding, niet de gegevens. Ieder ander apparaat op het draadloze netwerk kan pakketten onversleuteld bekijken. En draadloze netwerken worden vaak voor verschillende doeleinden gebruikt.

Bij communicatie moet de vertrouwelijkheid daarom worden gewaarborgd door netwerkbeveiligingsprotocollen zoals TLS (Transport Layer Security), dat beveiligde client-servercommunicatie via wederzijds geverifieerde en uniek versleutelde sessies mogelijk maakt.

4. Hoe beschermt je apparaat zijn sleutels?

Als alle apparaten dezelfde cryptografische sleutels gebruiken, kan een enkel geval van misbruik het hele systeem kwetsbaar maken. Naarmate het aantal apparaten toeneemt, groeit ook het risico. Dus hoewel het eenvoudiger is om met gedeelde sleutels te werken, is het beter om unieke sleutels of digitale identiteiten te gebruiken die tijdens het fabricageproces worden gegenereerd. Het niveau van bescherming dient in overeenstemming te zijn met de impact van mogelijk misbruik. Afhankelijk van de gevoeligheid van de gegevens kunnen beveiligingsmodules van sommige besturingssystemen worden ingezet om risicovolle en niet-risicovolle domeinen te scheiden.

5. Wat is je procedure om bugs sneller te vinden en op te lossen?

Laten we eerlijk zijn. Aanvallen van buitenaf zijn niet de grootste bedreiging voor de veiligheid van apparaten. De grootste bedreiging komt uit onbekende fouten en gebreken in de vele softwareniveaus die benodigd zijn om moderne, onderling verbonden apparaten te ontwikkelen. Veilige codestandaarden, testprocedures, hoogst betrouwbare besturingssystemen en de beste ontwerpgereedschappen moeten worden gebruikt om eventuele gebreken zo vroeg mogelijk in de softwarelevenscyclus te vinden en te herstellen. Een goede architectuur en het implementeren van modulaire scheiding minimaliseren de impact van softwarefouten en nieuwe cybersecurity-aanvallen.

End-to-end security

Security-ontwerpen zijn alleen zinvol als ze een end-to-end-werking hebben; de zwakste schakel in de keten bepaalt het totale securityconcept. De volgende vijf regels zijn algemeen toepasbaar en noodzakelijk in een goed security-ontwerp:

  1. Communiceer zonder vertrouwen te hebben in het netwerk
  2. Zorg ervoor dat er niet met de software kan worden geknoeid
  3. Bescherm kritieke gegevens
  4. Beveilig sleutels dienovereenkomstig
  5. Handel betrouwbaar

Deze regels zijn van toepassing op alle fases van de productlevenscyclus, van het ontwerp bij de engineeringafdeling tot aan de uiteindelijke productie. En zelfs nadat een product in gebruik is genomen, blijft security een sleutelrol spelen: permissies of certificaten moeten teruggetrokken kunnen worden als het apparaat niet meer te vertrouwen is.

Deze vijf regels kunnen in de praktijk worden toegepast door een goede device security-architectuur te koppelen aan een enterprise security-architectuur. In de device security-architectuur zorgen we ervoor dat met behulp van een chain-of-trust-controller alleen bekende en vertrouwde software start, en dat dankzij cryptografie en securityprotocollen geheime data geheim blijven in opslag en transport.

In de enterprise security-infrastructuur wordt programmacode van een digitale handtekening voorzien, waardoor het kopiëren van software zinloos wordt; elk apparaat kan alleen zijn eigen unieke software-image uitvoeren. In de illustratie codeert het sleutelbeheer bijvoorbeeld elk software-image op het moment dat het in een productiebedrijf in het apparaat wordt geprogrammeerd. Een belangrijk aspect hierbij is dat het sleutelbeheersysteem niet fysiek in de productieomgeving hoeft te staan. Dit geeft extra veiligheid ten aanzien van grijze productie van hoogwaardige elektronica.

Een end-to-end-beveiligingsontwerp vereist een aantal aanvullende componenten in het device. Een set netwerkbeveiligingsprotocollen is nodig voor identiteitscontrole en versleuteling van gegevens op eindpunten, en een cryptografische module is nodig om publieke sleutels op te slaan en basisalgoritmes uit te voeren. Software en gegevens moeten via een vertrouwensketen worden geverifieerd.
De backendarchitectuur moet dit ondersteunen met de juiste diensten. Tijdens de fabricage van de apparaten moeten er unieke sleutels en certificaten voor elk apparaat worden gegenereerd. Een digitale-handtekeningenservice ondertekent vervolgens software en gegevens voor elk apparaat, en een devicebeheersysteem zorgt voor de verspreiding van de uniek versleutelde gegevens naar de apparaten.

Deze unieke binding van apparatuur en software zorgt niet alleen voor veilige producten en productieomgevingen, maar creëert ook mogelijkheden om met uniek versleutelde en ondertekende licentiebestanden functies aan en uit te schakelen of bijvoorbeeld extra inkomsten genererende inhoud te verspreiden. Daarnaast kunnen software-updates op afstand en beveiligde realtime controle op oneigenlijk gebruik worden toegevoegd.

Dergelijke oplossingen zijn op de markt afgestemd en kunnen worden toegesneden op specifieke klantbehoeftes. De kosten van onbeveiligde apparatuur kunnen zeer hoog zijn, en dreigingen zijn reëel. Wacht daarom niet tot na de cyberaanval, maar neem concrete stappen om apparatuur te beveiligen met een end-to-end-beveiligingsontwerp.

Edited by Pieter Edelman