Test d’intrusion d’objets connectés et de systèmes embarqués

Deux à trois exemplaires fonctionnels sont un bon point de départ. Le premier sert aux manipulations non destructives, un deuxième aux analyses qui peuvent endommager la carte (lecture directe de la mémoire par exemple), le troisième de remplacement. Pour un produit coûteux, nous cherchons avec vous une alternative, comme une carte d’évaluation ou un exemplaire d’ingénierie. Le nombre exact se fixe au cadrage.

Le texte ne cite pas le test d’intrusion par son nom. Il demande en revanche que les produits comportant des éléments numériques soient conçus avec un niveau de sécurité adapté aux risques, que les vulnérabilités soient gérées pendant toute la durée de vie du produit et que la sécurité fasse l’objet de tests et de revues réguliers. Un test d’intrusion est un moyen reconnu d’y répondre, mais il ne remplace ni l’analyse de risques ni la procédure d’évaluation de conformité propre à votre produit.

Oui, c’est même le cas courant, notamment quand le firmware vient d’un sous-traitant. L’analyse part du binaire extrait de l’objet. Disposer du code ou de la documentation accélère la mission et permet d’aller plus loin dans le temps imparti, mais n’est pas un préalable. Si votre fournisseur est lié par contrat, il vaut mieux l’avertir avant le début des tests.

Oui, si vous le souhaitez. L’objet, l’application et le cloud forment un seul système, et les défauts les plus lourds se logent souvent entre les trois : une clé d’appairage lisible dans l’application, une API qui accepte l’identifiant d’un autre objet. Nous les testons dans la même mission, avec la méthode du test d’intrusion mobile et du test d’API, ce qui évite de payer deux cadrages.