Une plateforme de gestion de flotte résistante aux cybermenaces

15 recommandations de sécurité pour créer une plateforme télématique résistante aux cybermenaces

14. November 2016 — Auteur : Alex Sukhov, développeur de systèmes embarqués

Cyber-Threats

Un véhicule connecté offre d'innombrables nouveaux avantages, à savoir la sécurité, l'efficacité et la commodité. Cependant, la connexion des véhicules à Internet a soulevé des inquiétudes à propos de la cybersécurité et a suscité des discussions à l'échelle de l'industrie. Ces préoccupations ont été exprimées, entre autres, par le FBI, la NHTSA et la NAFA. 1,2,3, En particulier, le FBI a recommandé que « les propriétaires de véhicules vérifient les politiques de sécurité et de confidentialité des fabricants et fournisseurs de services tiers de dispositifs, et ne branchent pas de dispositifs inconnus ou non autorisés au port OBD II ». Dans la même veine, la NAFA recommande que « les gestionnaires de flottes aient des politiques en place pour garantir que seuls des dispositifs sécurisés soient branchés au port ». Nous proposons ce blogue en partie comme point de départ à ces discussions.

Ce travail d'évaluation des politiques de sécurité et des mesures liées à leur plateforme télématique pourrait sans doute être ardu pour les propriétaires de véhicules et les gestionnaires de flottes. Le but de ce blogue est de fournir des conseils à cet égard et d'inviter à une discussion plus approfondie sur la façon dont le secteur de la télématique dans son ensemble peut et devrait promouvoir la sécurité.

Dans le passé, le secteur de la télématique dépendait en grande partie des réseaux sans fil 3G et des infrastructures cellulaires plus récentes qui fournissent une certaine mesure de sécurité. Pourtant, le système GSM nous a montré que l'infrastructure cellulaire, comme tout autre système connecté, n'est pas à l'abri des violations et que davantage de protection est nécessaire.4 Les heures innombrables et les efforts consacrés à étudier le problème et à en parler avec d'autres experts nous permettent de proposer ces 15 recommandations de sécurité pour une plateforme télématique fiable.

1. Mettre en œuvre le transfert sécurisé des données

La mise en œuvre du chiffrement des données par interface de connexion assure la confidentialité des données indépendamment de l'état du réseau cellulaire ou de tout autre moyen de connexion intermédiaire. La mise en œuvre de l'authentification permet de vérifier que les sources de données reçues / transmises et les destinations sont conformes à vos attentes. Voir les recommandations de NIST pour les algorithmes acceptables de chiffrement et d'authentification.5

Utiliser des bibliothèques standard si possible. L'élaboration de vos propres algorithmes prend du temps et est très difficile à mettre en œuvre correctement. Si le système comporte des éléments pour lesquels les approches standard ne répondent pas aux exigences ou ne sont pas compatibles, veillez à ce qu'un tiers (ou des tiers) effectue des tests d’intrusion. Il est beaucoup mieux d'identifier et de corriger les problèmes avant que des failles ne se produisent.

Implement Secure Data Transfer

2. Signer numériquement les mises à jour

La signature numérique des mises à jour des applications est un élément essentiel de la sécurité des dispositifs télématiques. Les violations de la communication des données, même si dangereuses, limitent le champ d’action d’un intrus au cadre des caractéristiques du dispositif. Souvent, les attaques les plus dangereuses sur les systèmes embarqués nécessitent l'introduction d'un logiciel ou d'une image de micrologiciel malveillants. Cela permettra à un intrus d'activer des éléments de système non prévus ou limités par la conception (p. ex., pour des raisons de sécurité).

La signature des mises à jour des applications permet aux dispositifs de vérifier que les mises à jour proviennent d'une source approuvée. Pour en savoir plus sur les algorithmes acceptables à utiliser pour la signature, passez en revue ces recommandations de NIST.5Il est important de mettre en place un processus de signature interne et un répertoire de stockage de clé sécurisés pour réduire au minimum les menaces internes.

Digitally Sign Updates

3. Activer la protection du code du matériel

Si le microcontrôleur le prend en charge, la possibilité de lire le code de micrologiciel à partir du dispositif doit être désactivée. L'activation de la protection du code sur le microcontrôleur limite considérablement la capacité d'un intrus à rétro-concevoir les dispositifs, car il n'aura plus un accès facile au code. C'est un excellent outil pour se protéger contre les intrus de compétences ou de ressources limitées, mais il offre peu d'avantages contre ceux dont les compétences et les ressources sont moyennes ou supérieures. Il existe des entreprises qui, moyennant des frais, réalisent des extractions de code à partir de divers processeurs protégés par code. Ceci est un excellent exemple de la raison pour laquelle vous devriez toujours supposer que l'intrus connait parfaitement la configuration de votre système.

Enable Hardware Code Protection

4. Supposer que votre code est public

La sécurité mise en œuvre dans l’ignorance est une solution très fragile. Les éléments de sécurité devraient être conçus en supposant que l'intrus possède une connaissance approfondie de votre système et dispose déjà d'un accès complet au code. Même si les serveurs et les référentiels internes sont actuellement considérés comme étant sécurisés, cela peut-être n’était pas vrai dans le passé ou pourrait ne pas être vrai dans le futur. Un ancien employé a peut-être eu l'occasion de copier le code du système sur son propre ordinateur.

Assume

5. Utiliser des nombres aléatoires à cryptographie renforcée

La génération de nombres aléatoires est utilisée par de nombreux algorithmes dans le domaine de la sécurité. Il est important que la source des nombres aléatoires puisse fournir des nombres aléatoires à cryptographie renforcée. Si les nombres aléatoires générés ne sont pas à cryptographie renforcée (« pas suffisamment aléatoire »), les points forts des algorithmes qui utilisent ces nombres aléatoires peuvent être considérablement affaiblis.

Use Cryptographically Strong Random Numbers dice

6. Individualiser les données dont la sécurité est critique

Les données dont la sécurité est critique, telles que les clés de chiffrement et les jetons d'authentification, devraient être uniques pour chaque dispositif. Si un dispositif est compromis, il ne devrait jamais compromettre un autre dispositif ou une partie du système. Les systèmes intégrés sont particulièrement connus pour l'utilisation d'une seule clé pour plusieurs dispositifs.6

Individualize Security-Critical Data

7. Utiliser des clés différentes pour différents rôles

La compromission d'un élément de la logique de sécurité ne devrait jamais mettre en péril un autre. Il faut utiliser différentes clés pour différents rôles. Par exemple, la même clé ne doit pas être utilisée pour la communication par interface de connexion et la signature de l'application.

Use Different Keys For Different Roles keys

8. Surveiller les métadonnées

La détection précoce d’une activité suspecte et l’intervention rapide sont essentielles pour réduire au minimum les dommages causés par les acteurs malveillants. La recherche active d’erreurs ou de tendances dans les données de débogage peut réduire ou prévenir les dommages causés par une attaque. De nombreux services de traitement en nuage permettent même la surveillance de grands volumes de données de performance en temps réel. La création de services qui avisent les personnes concernées en cas de détection d’erreurs ou d’anomalies est essentielle pour cerner les attaques dès leur enchaînement.

Monitor Metadata magnifying glass

9. Désactiver les fonctionnalités de débogage

Les modes et les données de débogage sont une partie essentielle du développement, du dépannage et de la vérification de la fonctionnalité. Ils sont également d'excellents outils pour détecter les anomalies dans un système. Cependant, la logique liée au débogage peut souvent être négligée du point de vue de la sécurité. La logique de débogage qui contient des informations critiques du point de vue de la sécurité ne devrait pas être accessible dans les versions de logiciels en mode production.

Disable Debug Features

10. Effectuer des vérifications externes

Tous les éléments essentiels pour la sécurité du système devraient faire l’objet de vérifications appropriées. La divulgation de votre code à une société professionnelle tierce à des fins d’examen devrait être encouragée, car votre système devrait être conçu en supposant qu'un intrus a une connaissance approfondie du code de base. Il est préférable de découvrir et de corriger les vulnérabilités en privé. Il faut prévoir, dans un délai raisonnable, des contre-mesures pour les vulnérabilités relevées dont le niveau de risque est inacceptable.

Perform Third-Party Auditing

11. Limiter l’accès au serveur

Il faut établir une hiérarchie des comptes internes pour permettre l'accès aux serveurs principaux et aux fonctionnalités uniquement aux personnes qui en ont besoin. L'authentification multifacteur est un outil extrêmement puissant pour le contrôle d'accès. Différents types de matériel ou d’applications de téléphone cellulaire peuvent être utilisés à cette fin. Les enregistrements des connexions aux serveurs sont essentiels dans l'analyse judiciaire des activités de connexion suspectes.

Limit Server Access

12.Adopter des pratiques de conception sécurisées

La sécurité doit être intégrée dans les étapes de conception et non ajoutée après coup. Appliquer le principe du privilège minimum - s’assurer que chaque élément du système ne permet l'accès qu'à ceux qui en ont besoin. Ne pas faire confiance aux caractéristiques du système pour limiter le nombre de moyens dont un intrus peut explorer votre système.

Apply Secure Design Practices

13. Assurer le soutien des mises à jour logiciels/micrologiciels

Il n'est pas réaliste de supposer qu'un système soit parfaitement sécurisé à n'importe quel moment de son cycle de vie. Des problèmes liés à la sécurité surgiront et il faudrait avoir un processus mis en place pour les corriger. La possibilité de mettre à jour le logiciel/micrologiciel est une caractéristique de sécurité essentielle dans un système connecté. La capacité d'effectuer des mises à jour rapidement est précieuse pour atténuer les menaces inconnues (zero-day). Il est essentiel que le fabricant soit chargé du maintien du micrologiciel du dispositif. Il ne faut pas compter sur l'utilisateur final pour assurer la mise à jour et la sécurité de son dispositif. Les mises à jour doivent être automatiquement activées sur tous les dispositifs. Les fabricants de dispositifs télématiques (ou d'autres appareils IdO) devraient être responsables de leurs propres correctifs de sécurité.

Support for Software/Firmware Updates cloud image

14. Vérifier et mettre à l’essai

Le code de base du système change constamment. Il faut avoir un processus de développement formel. L'examen par les pairs de chaque modification détectera d'innombrables problèmes avant même qu'ils puissent causer des dégâts. Les tests unitaires sont également essentiels pour garantir que la logique de sécurité demeure fonctionnelle. Les tests unitaires devraient être mis en place à la fois au niveau du code et du matériel pour l’intégralité du système.

Verify and Test

15. Favoriser une culture de sécurité

Même les systèmes dont la sécurité est conçue de façon optimale peuvent être attaqués par leurs opérateurs. Le personnel ayant accès au réseau (non seulement les développeurs de sécurité!) devrait recevoir une formation régulière et leurs pratiques d’utilisation sûre de l'Internet devraient être vérifiées. Cela inclut la résilience aux attaques d’hameçonnage, l'utilisation de mots de passe difficiles à déchiffrer, la sensibilisation aux liens URL et l'attention aux certificats de sécurité. La formation en elle-même est un bon départ, mais intéresser et sensibiliser le personnel à la sécurité est beaucoup plus efficace.

Develop a Security Culture for cybersecurity

Pour en savoir plus, lire le document: "Preserving Privacy and Security in the Connected Vehicle: The OBD Port on the Road Ahead".

Bien que nous croyions que ces recommandations contribueraient grandement à rendre une plateforme télématique résistante aux cybermenaces, l'apprentissage et l'amélioration seront essentiels pour sécuriser les systèmes et les utilisateurs. Cela doit englober les efforts de tout le secteur. Par conséquent, si vous avez des idées sur les moyens de communiquer la sensibilisation à la sécurité, n'hésitez pas à faire partie des efforts et à laisser vos commentaires ci-dessous!

Références:
  1. Federal Bureau of Investigation, « Alert Number I-031716-PSA: Motor Vehicles Increasingly Vulnerable to Remote Exploits », 17 mars 2016. [En ligne] Consultable sur : https://www.ic3.gov/media/2016/160317.aspx.
  2. National Highway Traffic Safety Administration, « 25-16: U.S. DOT issues Federal guidance to the automotive industry for improving motor vehicle cybersecurity », 24 oct. 2016. [En ligne] Consultable sur : https://www.nhtsa.gov/About-NHTSA/Press-Releases/nhtsa_cybersecurity_best_practices_10242016.
  3. NAFA Fleet Management Association. « Fleet Management and the Connected Vehicle », Oct. 2016. [En ligne] Consultable sur : www.nafa.org/.
  4. G. Cattaneo, G. De Maio, et U.F. Petrillo, « Security Issues and Attacks on the GSM Standard: a Review », Journal of Universal Computer Science, vol. 19, no. 16 (2013), 2437-2452, Oct. 2013. [En ligne] Consultable sur : http://www.jucs.org/jucs_19_16/security_issues_and_attacks/jucs_19_16_2437_2452_cattaneo.pdf.
  5. E. Barker, « National Institute of Standards and Technology Special Publication 800-57 Part 1, Revision 4. Recommendation for Key Management », Janv. 2016. [En ligne] Consultable sur : http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf.
  6. I. Arce et autres, « Avoiding the Top 10 Software Security Design Flaws », IEEE Computer Society, 13 nov. 2015. [En ligne] Consultable sur : http://cybersecurity.ieee.org/blog/2015/11/13/avoiding-the-top-10-security-flaws/.

Share This Story

Facebook LinkedIn Twitter Google+ Email