Secu
Dix raisons clés pour lesquelles vos produits ne sont pas sécurisés
Par La rédaction, publié le 31 décembre 2017
De nombreux projets, produits informatiques et applications sont des échecs du fait d’une sécurité inadéquate, médiocre ou même absente. Les raisons de ces défaillances, facilement évitables, entrent généralement dans dix catégories de base.
1 • Vous avez traité la sécurité après coup. Il est difficile de barrer les voies d’attaque possibles durant la phase de conception et presque impossible après le déploiement. Une évaluation continue doit donc être menée à chaque phase : analyse initiale, étude de faisabilité (le cas échéant), conception, tests unitaires, assurance qualité et disponibilité générale. Le produit sera plus sécurisé et son processus de développement plus rentable, car plus une vulnérabilité est découverte tôt, plus le coût de son atténuation est bas.
2 • Vous n’avez pas fait appel à des praticiens de la sécurité aguerris. La sécurité ne s’obtient pas en « parsemant » un peu de cryptage par-ci et quelques contrôles d’accès par-là. Les concepteurs et développeurs axés sur les processus métiers n’ont souvent pas une formation adéquate en sécurité. Le recours à une société de sécurité tierce ou à des spécialistes sous contrat est une option presque toujours moins chère que les coûts découlant d’une vulnérabilité exploitée.
3 • Vous avez refusé une revue externe indépendante. La sécurité des systèmes nécessite une revue indépendante et approfondie par des experts en sécurité expérimentés (et plus ils sont nombreux, mieux c’est). Dans des cas extrêmes, tels que ceux relatifs à la confiance publique, le code source doit être mis à la disposition du public pour examen. Par ailleurs, si vous ignorez les normes clés, vous laissez forcément la voie ouverte à des vulnérabilités.
4 • Vous avez fait confiance aux utilisateurs. La sécurité d’une application ou d’un appareil ne peut pas être fondée, même en partie, sur l’hypothèse qu’ils seront déployés et utilisés correctement et que les utilisateurs finaux — et les ordinateurs et autres logiciels qu’ils utilisent — se comporteront comme prévu.
5 • Vous avez sous-estimé les attaquants. La « sécurité par l’obscurité » est une approche faible. Le secret qui entoure les fonctions de sécurité administratives ne protégera aucun système si plus d’un individu connaît le secret : les défenses et accès privilégiés deviendront inévitablement connus des attaquants potentiels. Autre problème : les systèmes et processus de sécurité obscurs ne bénéficient souvent pas d’une revue adéquate par les pairs, parfois délibérément, comme moyen de maintenir l’obscurité.
6 • Vos interfaces utilisateur et administrative ne sont pas séparées. L’interaction entre les modes opérationnel et administratif devrait être impossible. Les utilisateurs standard ne doivent ni utiliser la même méthode d’authentification que les administrateurs, ni pouvoir « basculer » en mode administrateur (même s’ils ont les droits), ni, autant que possible, utiliser la même console physique.
7 • Vous proposez une sécurité plus faible par défaut. Les réglages « les plus pratiques » ou « les plus faciles à utiliser » se traduisent souvent par une sécurité minime ou inexistante, des mots de passe par défaut, l’activation du partage généralisé ou d’autres pratiques dangereuses. L’administrateur ou l’utilisateur final choisit ce mode la première fois qu’il utilise le produit et oublie vite, ensuite, de modifier les réglages. Le principe de conception par défaut doit être une « sécurisation maximale par défaut ».
8 • Votre produit n’assure pas son intégrité. Les systèmes doivent avoir une résistance aux falsifications logiques et physiques conçue, au minimum, pour ralentir la plupart des attaques suffisamment longtemps pour qu’elles soient détectées, ou pour dissuader les attaquants. Un témoin d’intégrité doit aussi être prévu pour indiquer quand le système a été modifié. Attention, toutefois, ces systèmes ne protègent pas contre les attaques par déni de service, qui les exploitent justement dans leurs tactiques.
9 • L’OS « standard » de votre produit n’a pas été adapté. Les OS courants comportent de nombreux services et interfaces superflus pour le fonctionnement d’un produit intégré et qui constituent des points d’attaque potentiels. Les systèmes embarqués sont, eux, souvent conçus sans prendre en compte l’impératif de correction ou de mise à jour de leurs composants. Pour être sécurisé, l’OS doit donc être adapté au produit, renforcé, et doit pouvoir accepter des correctifs par un processus lui aussi sécurisé.
10 • Votre produit ne fournit pas de preuve de l’intégrité transactionnelle. Les systèmes liés à des données personnelles confidentielles, des transactions financières, à la sécurité nationale et à la confiance publique doivent générer un enregistrement incontestable et vérifiable par les auditeurs et les utilisateurs de toutes les transactions, y compris toutes les fonctions administratives et opérationnelles. L’intégrité doit pouvoir être reconnue avant d’initier toute transaction.
Ray Wagner
Greg Young
Gartner
