Transcription

• Speaker #0

  Bonjour mamie. Bonjour et bienvenue dans la cybersécurité expliquée à ma grand-mère, le podcast pour expliquer la cybersécurité à des gens qui ne comprennent rien. un film de science-fiction réalisé par Terry Gilliam. À l'instar de bon nombre de films cultes, Brazil n'a pas rencontré son public à sa sortie en 1985. L'histoire se déroule dans un univers futuriste et kafkaïen, où une bureaucratie oppressante et omniprésente régit la vie des individus. Le monde présenté est à la fois étrangement familier et bizarrement étranger. combinant les éléments de la société moderne et des éléments bien plus rétro. L'esthétique visuelle est un mélange de décorations industrielles, d'architectures délabrées et de technologies anachroniques, créant une ambiance à la fois surréaliste et oppressante. Certains d'entre vous ont peut-être reconnu ici la description de leur système d'information, et peut-être même de leur gouvernance. Mais le parallèle avec ce film ne s'arrête pas là. Le personnage principal, Sam Laurie, est un employé modeste du gouvernement qui rêve d'une vie plus excitante et libre. Sa vie bascule lorsqu'il tente de corriger une erreur administrative due à un insecte tombé dans une imprimante, ayant conduit à l'arrestation et la mort d'un homme innocent. Car l'imprimante désigna Archibald Buttle, un innocent, à la place d'Archibald Tuttle, qui lui est un dangereux terroriste. Je ne sais pas si Terry Gilliam a volontairement utilisé l'insecte qui tombe dans l'imprimante pour faire référence à un bug informatique, mais il faut avouer que ceci décrit parfaitement un système d'information tel qu'on le connaît dans beaucoup d'organisations. Un mélange assez anarchique de technologies, une gouvernance qui semble bureaucratique et peu efficace sans oublier une complexité grandissante. Suivant. Oui, bonjour, je voudrais refaire ma carte vitale, j'ai rempli le dossier.

• Speaker #1

  Ouais, c'est plus les bons formulaires, hein. Là, faut les changer, ils donnent les mauvais. Daniel ! Retournez les formulaires,

• Speaker #0

  hein ! Non mais attendez, je trouve où le dossier ?

• Speaker #1

  Sur l'Internet. Vous les imprimez. Bah en fait, c'est bon, les autres formulaires, ils marchaient finalement. Par contre, on ne ferait que...

• Speaker #0

  Oh non, s'il vous plaît. Ah bah si,

• Speaker #1

  imaginez, tout le monde fait comme vous. Bon, les attestations de travail, vous les avez ? Non. Bah c'est nouveau, il faut les avoir, faut suivre, y a des trucs nouveaux tout le temps.

• Speaker #0

  Mais l'élément le plus significatif est l'insecte, le bug, ce petit grain de sable qui fait tout dérailler. C'est exactement ce qui se passe en cybersécurité. L'exploitation consciente ou inconsciente d'une faille qui entraîne de graves conséquences. Vous avez très certainement maintenant dans votre esprit une question parfaitement légitime. Comment faire pour que ce genre de problème n'arrive pas dans une organisation, sans pour autant mettre en place un système de contrôle draconien, et tout en sachant que par définition un système d'information est souvent très hétérogène ? Eh bien, l'une des réponses que l'on peut apporter, c'est le SDLC, le Secure Development Lifecycle, ou en français, le cycle de vie du développement sécurisé. Pour comprendre qu'est-ce que le SDLC, il faut partir d'un constat. C'est l'humain qui fait évoluer le système d'information. L'humain est faillible, dès lors le système d'information est faillible. Ce n'est pas une réflexion misanthropique, mais simplement un fait qu'il faut garder à l'esprit. Mettre en place une architecture, administrer un système ou développer un logiciel sont des tâches qui sont loin d'être faciles et nécessitent de l'expérience et de la concentration. C'est la raison pour laquelle il est crucial de s'organiser pour améliorer la qualité et la robustesse des produits proposés. Le LDLC est un peu comme s'organiser pour arrêter de fumer ou faire de l'exercice. C'est se positionner dans la meilleure posture pour atteindre ses objectifs. On peut trouver plusieurs étapes, ou plutôt plusieurs grands principes à suivre. Étape 1. La collecte et l'analyse des exigences. Avant toute chose, il faut comprendre le niveau d'exigence en matière de sécurité. Il peut y avoir des exigences réglementaires quant à la façon de gérer les données. L'exemple le plus commun est très certainement celui du RGPD, qui impose tout un ensemble de contrôles et de règles en matière de traitement des données. Comme pour le stockage des mots de passe par exemple. Ensuite, il y a le contexte lui-même. Par exemple, il y a fort à parier que les contraintes ne seront pas les mêmes si vous développez un système pour un avion de chasse ou une centrale nucléaire. Il est évident que dans ce cas, les contraintes ne seront pas les mêmes que pour d'autres systèmes d'information. Ensuite, il faut prendre en compte le triptyque sécurité, convivialité, performance et coût. Si votre système est parfaitement sécurisé, Mais que l'utilisateur soit obligé de rentrer trois mots de passe différents ainsi que deux paramètres biométriques, il y a fort à parier que la solution que vous lui proposez risque d'être délaissée. Il en va de même avec les aspects de coût. Certaines architectures proposées, très souvent sur le cloud, peuvent sembler être de bonnes solutions d'un point de vue sécurité, mais peuvent avoir des coûts considérables. Étape 2, la conception. C'est durant cette étape que vous allez pouvoir mettre en œuvre des fondations saines pour le produit que vous développez. Par exemple, vous assurez que les droits sont octroyés en suivant le principe du moindre privilège. Si par exemple les processus tournent tous en mode administrateur, et qu'en plus vos utilisateurs ont les mêmes profils avec un maximum de droits, vous allez assez rapidement avoir des problèmes. Un autre aspect concerne la mise à l'échelle de votre infrastructure. C'est la capacité de supporter une montée en charge, ce qu'on appelle souvent en franglais la scalabilité. Et le dernier aspect qui n'est pas l'un des moindres est d'imaginer les menaces potentielles en fonction du contexte. Avez-vous un risque de DDoS par exemple, car votre application est exposée sur Internet ? L'étape de conception est cruciale, car si vous commettez une erreur, il sera très difficile de revenir en arrière. Mais par chance, concevoir une application, c'est souvent du bon sens paysan. C'est un peu comme si sur le plan d'une maison, vous aviez une prise d'électricité dans la douche. C'est une vraie erreur de conception, mais elle est facile à détecter. L'intérêt aussi d'être très attentif pendant cette étape est que vous pouvez dès à présent identifier les contrôles à mettre en œuvre dans le futur, pour vous aider à mieux comprendre la relation entre architecture, sécurité et contrôle, Très utile dans le contexte de l'edit, je vous invite à regarder le site web OSA pour Open Security Architecture. C'est un excellent moyen de faire le lien entre architecture et les frameworks de contrôle comme le NIST ou l'ISO 27001. Étape numéro 3, l'implémentation. C'est encore une fois un peu comme dans le bâtiment. Si vous avez revu vos plans et qu'ils sont justes et parfaits, il ne reste plus qu'à trouver de bons maçons pour bâtir votre édifice. Mais quelle va être la norme de fabrication ? Faut-il prendre du béton normalisé ? Eh bien, il en va de même pour le développement. Il est nécessaire d'avoir des normes de codage. Il est crucial que les développeurs aient une connaissance des pièges à éviter dans les langages qu'ils utilisent pour réaliser les applications. Mais comme l'erreur est humaine, il faut s'aider d'outils d'analyse de code. Il y a principalement deux grandes familles. Les analyseurs de code statique, qui vont lire le code et détecter des failles de sécurité uniquement sur cette base, et les analyseurs de code dynamique, qui eux vont exécuter le code dans le but de tester ses limites. L'avantage de ces solutions, c'est d'avoir des indicateurs sur la qualité du code et surtout de son évolution. Un dernier point, mais qui n'est pas le moindre, est de traiter les dépendances avec le code extérieur. Il est assez rare, pour des raisons de coûts assez évidentes, de développer certains modules qui existent déjà. Et la raison est assez simple. Pourquoi investir du temps et de l'énergie à développer des fonctions qui sont déjà disponibles ? Dans bon nombre des cas, on va utiliser des modules externes. Mais quid de la qualité du code ? Y a-t-il des failles de sécurité ? Peut-être qu'il n'y en a pas maintenant, mais qu'est-ce qui se passe s'il y en a dans le futur ? Est-ce que ce code est sous licence ? Et si oui, laquelle ? La dépendance à des modules externes peut être très complexe à gérer en matière de cybersécurité. C'est comme les traçabilités alimentaires. À chaque instant, vous devez être capable de remonter la chaîne jusqu'à l'origine du code. C'est devenu quelque chose de tellement important qu'il existe un executive order du président Biden qui impose aux fournisseurs d'applications à l'usage de l'administration américaine de mettre un contrôle de bout en bout de tous les modules utilisés pour produire une application. Ce qui revient à dire qu'ils ont l'obligation de justifier le moindre octet de leur application. Étape numéro 4, les tests. Vous devez intégrer dans le cycle de vie de votre application des tests automatiques, des tests qui aideront le développeur à comprendre et à corriger les failles de sécurité potentielles. Vous pouvez par exemple synchroniser les tests avec les versions du code, par exemple lancer des tests à chaque fois qu'un développeur enregistre son code. Mais vous pouvez aussi aller plus loin, en organisant un pen test ou un audit de sécurité par exemple. Généralement, il est conseillé de le faire une fois que votre code est stabilisé et prêt à être mis en production. Bien évidemment, les résultats de ces tests doivent être pris en compte et donner lieu à des correctifs. Dans certains cas, si les tests révèlent des failles de sécurité majeures, il faudra certainement corriger immédiatement, alors que des failles mineures pourront peut-être bénéficier d'un délai plus long. Étape numéro 5. Le déploiement et la maintenance. Cette étape paraît anodine, mais elle ne l'est pas du tout. Comment s'assurer que le code que vous avez patiemment amélioré et corrigé est bien celui que vous allez déployer en production ? D'autant plus qu'il y aura très certainement différents environnements à gérer en parallèle. C'est spécialement le cas avec les déploiements dans le cloud. Un autre point crucial dans cette étape, c'est l'intégration de votre application dans un environnement de production à travers le monitoring. Monitoring purement applicatif dans le but de s'assurer que l'application fonctionne correctement, mais aussi le monitoring de sécurité. Le monitoring là a pour but de détecter une éventuelle attaque. Il faudra par exemple intégrer les logs de votre application dans le SIEM et mettre en place des règles spécifiques pour traiter les alertes. Il ne faudra pas aussi oublier de faire la jonction avec les processus de correctif et de gestion des vulnérabilités. Au-delà de ces cinq étapes, il est important de connaître les clés du succès. La première clé est la formation et la sensibilisation de chaque intervenant. Les développeurs, bien sûr, mais aussi les équipes techniques qui doivent être informées et pas simplement sensibilisées à la sécurité, mais aussi aux bonnes connaissances des différentes techniques et menaces. La seconde clé du succès, c'est la gouvernance et la conformité. La gouvernance doit être transverse dans toute l'organisation, y compris au niveau du management. Il va sans dire que les contrôles dont nous avons parlé à l'étape 2, avec l'Open Security Architecture, est la clé qui permet de démontrer que l'application est bien conforme aux attendus réglementaires et fonctionnels. Mais suivre ces étapes est-il suffisant ? Est-ce qu'implémenter des processus comme SecDevOps, Security Chaos Engineering ou SafeAgile est-il suffisant ? Bien entendu, il est conseillé de le faire, mais ce n'est pas pour autant suffisant. N'oubliez pas que de nombreux facteurs influencent nos choix. Par exemple, il est parfois très tentant d'utiliser des modules que l'on connaît comme étant vulnérables, mais qu'on veut utiliser quand même car ils sont disponibles et gratuits. Il faut se rappeler qu'une organisation est une combinaison d'infrastructures, de personnes, de menaces, de ressources, de temps et d'argent. Certaines approches seront meilleures que d'autres et mieux adaptées à votre stratégie. C'est ce qui rend le sujet du SDLC complexe par nature. Et c'est ce qui rend aussi certaines alternatives, comme acheter une solution sur étagère, totalement illusoires. Une fois de plus, la cybersécurité ne vient pas d'un outil ou d'un process, mais dans l'ingéniosité des gens qui la mettent en œuvre. Si vous ne voulez pas mettre en place une bureaucratie oppressante et contre-productive dans votre organisation, et que vous ne souhaitez pas qu'un insecte tombé dans une imprimante bloque votre business, alors vous avez tout intérêt à mieux comprendre le SDLC, avec ses bénéfices, mais surtout ses limites. Encore merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à le liker, à le partager avec d'autres et à en parler autour de vous. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout n'oubliez pas, pour certains, la cybersécurité est un enjeu de vieux noir, c'est bien plus sérieux que ça.

• Speaker #2

  Merci.