La security by design, produit marketing

No Comments

Depuis plusieurs mois, on nous rebat les oreilles de la « security by design », nouveau mantra sensé sécuriser paradigme qui sécurisera toutes les applications et programmes informatiques de manière native.

Source

Pour autant quelques problèmes résiduels se font jour. C’est ainsi que la société Spiral toys a mis en vente des jouets connectés avec une faille de sécurité. La mésaventure est esquissée ici, contée par le menu . Comment cela est-ce possible ?

Une piste nous est aimablement fournie par Andrew Tannenbaum, IBM’s first chief cybersecurity attorney qui nous expose plusieurs raisons pour lesquelles la security by design s’avère défaillante dans l’internet des objets.

La première est affligeante : The problem is that many IoT devices are not designed or maintained with security as a priority. C’est ballot quand on nous parle de security by design, ou tout simplement de priorité donnée à la sécurité. L’explication de l’explication étant que 80% of organizations do not routinely test their IoT apps for security vulnerabilities. Il est évident que nier un problème participe à sa résolution. Je croyais que le petit père Queuille (auteur des célèbres « Il n’est pas de problème dont une absence de solution ne finisse par venir à bout » et « La politique n’est pas l’art de résoudre les problèmes, mais de faire taire ceux qui les posent ») était une spécificité française, il a vraisemblablement fait école… Osons donc « Il n’est pas de problème de cybersécurité dont une absence de solution ne finisse par venir à bout » ainsi que « la cybersécurité n’est pas l’art de résoudre les problèmes, mais de faire taire ceux qui les posent. »

Une deuxième est aussi étonnante : Some observers attribute the failure to the IoT gold rush, and are calling for government to step in to regulate smart devices. La régulation, voilà la panacée ! Un problème ? Une loi, un décret, une ordonnance, un code ! Cette hypothèse est rapidement abandonnée au profit de a constitution d’un framework for IoT. Mais comme l’auteur est américain, il ne pousse pas le Queuillisme à fond lorsqu’il écrit It would be a mistake, however, for the IoT industry to wait for governments to step in. Ce qui va sans dire va parfois mieux en le disant.

Il faut donc intégrer la sécurité dès la conception des objets connectés, voire forcer l’utilisateur à modifier login et mot de passe à la première utilisation. C’est un peu mieux que de réguler.

Mettre aussi  à jour les logiciels équipant les objets connectés, et inscrire une date de « péremption », au-delà de laquelle la sécurité n’est plus assurée, et alerter les utilisateurs de l’existence de failles de sécurité.

Que reste-t-il de la lecture de cet article ?

Que toutes ces recommandations ne sont pas superflues, mais une phrase me semble particulièrement pertinente et pas assez développée : Some observers attribute the failure to the IoT gold rush. Ne jamais oublier l’appât du gain, cela fait faire des folies. En effet, l’appât du gain n’a sûrement pas été suffisamment mis en exergue. Lorsque des chefs d’entreprise déclarent qu’il faut accélérer la cadence de mise sur le marché de produits logiciels (ou à base de logiciels), cela ne peut s’effectuer qu’au détriment de la sécurité. Pourquoi ? Car elle prend du temps, notamment en essais.

Que l’historique de l’informatique ne l’a pas été non plus. Le nombre de lignes de code constituant chaque logiciel est impressionnant. Il est donc illusoire de s’assurer que tout est sécurisé, dans la mesure où les programmes s’empilent les uns sur les autres. Et comme les premiers ont été conçus à une époque où la sécurité n’était pas un problème, certaines découvertes peuvent avoir des conséquences énormes. Si on estime qu’un bon programmeur écrit environ 4000 lignes de code par an, voyez donc combien de temps et de personnes il faudrait pour réécrire, de manière sécurisée, votre logiciel préféré. Sans oublier cette réflexion de Ken Thompson ni celle-ci.

Actualisation : je ne pense pas que 2008 représente les temps préhistoriques de l’informatique. Pourtant, cette année-là, Intel construisait une puce avec une faille de sécurité découverte il y a peu

Categories: Sécurité Étiquettes : ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *