Transcription

• Speaker #0

  Aujourd'hui on va parler d'une erreur classique en ISO 27001. Les entreprises qui s'imposent des contrôles qui ne les concernent pas du tout. Tu sais, surtout la série A.8.25 jusqu'à A.8.33. Les contrôles liés au développement logiciel. Et pourtant, certaines boîtes n'ont aucun développeur et aucune ligne de code en interne. Résultat, elles perdent du temps, de l'argent et elles se compliquent la vie pour rien. Alors dans cet épisode, je vais t'expliquer... Quel contrôle tu peux mettre de côté point de vue développement logiciel ? Les pièges qui font cocher applicable à tort et partout ? Et comment justifier une non-applicabilité sans stress devant ton auditeur ? Bienvenue dans Compliance Without Coma, le podcast qui parle cybersécurité, gouvernance et ISO sans coma. Je suis Fabrice De Paepe et aujourd'hui je te partage une erreur que je vois souvent. Tu connais peut-être déjà la scène. Tu vises ISO 27001, tu bosses dur, tu arrives à ta déclaration d'applicabilité et là panique. On va tout cocher, ça sera plus sûr. Résultat, tu sécurises du vide, tu payes, tu complexifies. et tu fatigues les équipes. Je te fais un petit rappel éclair sur la déclaration d'applicabilité et sur l'ISO 27002. Dans la déclaration d'applicabilité, SOA en anglais, Statement of Applicability, tu dois justifier pourquoi tu choisis ou exclus chaque contrôle. Ce serait donc normal de dire que, si tu ne fais aucun développement logiciel, de ne pas choisir les contrôles liés à cela, non ? Car, pas de dev logiciel, pas de risque. Pas de risque ? Pas de contrôle. Or, l'ISO 27001 veut qu'on protège nos actifs les plus critiques. Et, par la même occasion, démontrer qu'on a un lien entre notre déclaration d'applicabilité, la SOA, et la sélection des contrôles. Mais comment peux-tu avoir des vulnérabilités liées au développement que tu ne fais pas ? CQFD, ce que Fabrice dit. Et l'autre partie, c'est l'ISO 27002. Ah ben on mettra les 93 contrôles pour faire sûr. Et vendre des jours en plus sur un malentendu, on sait jamais, ça peut passer. Faux, on s'en fiche. La 27002 est un guide de bonne pratiques. Ce que tu dois faire, c'est vérifier l'annexe A, de l'ISO 27001, et quel contrôle s'applique à ton SMSI en approche top-down. Et non pas partir de tous les contrôles parce que... Qu'est-ce qui t'empêche alors de rajouter un contrôle sur le MFA, où il n'est pas dans la norme ? Et tous les contrôles du NIST, pour être certain. Et tout ceux lié tient à PCI DSS, Payment card Industry Data Security Standard, même si tu n'as pas de plateforme en ligne de paiement par carte de crédit. On ne sait jamais, non ? Donc, sûr que ta voiture va avancer plus vite avec tout ça. Sûr que tu vas avoir le budget et gagner la confiance du board. Et d'aucuns diront encore, je les entends, que l'ISO 27001 est lourd. Et aussi est un frein au lieu d'être un accélérateur de croissance. Parfois c'est le consultant qui est lourd. parfois l'auditeur, mais ça c'est un autre débat. Plus concrètement, ce que je vois dans mes audits, c'est que les entreprises sans développement logiciel cochent quand même la série de A.8.25 à A.8.33. Spoiler, la moitié ne s'applique pas. L'autre moitié, parfois, souvent différemment. On va clarifier tout ça. T'es toujours là ? Allez, suis-moi, on replonge dans le SDLC pour System Development Lifecycle. On va nuancer chaque contrôle. Et en fait, le principe est simple. Si tu n'écris pas de code et que personne ne code pour toi, la chaîne d'approvisionnement, en termes de développement, ne s'applique pas. Mais si tu fais coder, même en externalisé, si tu fais du low-code ou du no-code avancé, ou si tu bricoles du script qui met en prod, c'est plus la même histoire. Les contrôles devs un par un de A8.25 à A8.33. Ausha, car en audio, c'est lourd. Peut-être que je vais faire une petite vidéo pour un visuel, tu me diras en commentaire si tu as besoin. Commençons par le A8.25, le cycle de vie du développement sécurisé. Eh bien, c'est non applicable si tu ne développes pas. C'est applicable si tu développes, que ce soit en interne ou en externe. Ou si tu fais du no-code ou du low-code avec des composants maison en prod. Et là, je pense aux fonctions lambda d'AWS. des outils comme Zapier, des workflows générés par IA. Mais attention, s'il y a IA, attention, 42001, du coup, pour l'ISO. Donc, à retenir... Configurer un ERP, c'est différent de développer. Mais un workflow Power Platform, quel qu'il soit, et qui serait critique et qui exécute du custom en prod, oui, ça ressemble déjà à du dev. Donc, exemple de justification pour la SOA, nous ne développons aucun logiciel ni composant interne, aucune capacité SDLC n'est requise, par exemple. Le suivant, A8.26. Exigence de sécurité applicative. C'est non applicable si zéro application développée par toi ou pour toi. Et c'est applicable si tu fais écrire une app, même par un prestataire. Tu dois exiger des spécifications de sécurité, méthodes d'authentification, fichiers journaux, chiffrement, rôle, identity access management, etc. Dans ce cas-là, au niveau de la SOA, tu vas dire aucune application développée en interne ni commandité. Seules des solutions du marché sont utilisées. On continue notre parcours avec le A.8.27, architecture sécurisée et principe d'ingénierie. Non applicable si tu n'as pas de conception logicielle chez toi. Applicable si tu fais concevoir une app ou un système, même externe. Parce que là, il te faut du threat modeling, donc les fameux modèles de menace, des patterns de sécu, des principes d'ingénierie. Donc au niveau de la SOA, tu pourrais dire... Pas d'architecture logicielle conçue pour notre compte. Architecture applicatif fournie par des éditeurs. On passe par le A.8.28, codage sécurisé. Non applicable si zéro code. Applicable si quelqu'un écrit du code en interne ou en externe, avec des dépendances, des revues de code. Et attention, configurer est différent de coder. Un script qui tourne en prod du Bash, du Python, du SQL, c'est du code. Donc, au niveau de la SOA, on pourrait dire aucune activité d'écriture de code déployée en production au sein de l'organisation. A.8.29, test de sécurité dans le développement. Non applicable si pas de développement. Applicable si tu développes des tests dynamiques, Fuzzy, des pentests d'acceptation avant la mise en prod. Et il y a une zone grise. Même sans dev, un pentest d'une application SaaS critique pourrait être pertinent. Mais ça relève plus des tests de sécurité opérationnelle que du contrôle de dev. Toi, tu crées ta toile d'araignée. Donc au niveau de la SOA, on pourrait dire absence de pipeline de développement, pas de test de sécurité logiciel requis côté développement. Le A.8.30, développement externalisé. Et là, c'est subtil. C'est applicable si tu fais développer pour toi par un tiers, parce que tu vas avoir besoin de contrat, de clause de sécu, ta propriété intellectuelle. Comment vas-tu la protéger ? Des revues, des livrables, des droits d'audit, etc. C'est non applicable si tu achètes on the shelf, sur une étagère, même customisé via des options officielles. Et là, tu n'as pas de demande de développement spécifique. Alors il y a un cas limite, ce sont des intégrateurs qui écrivent des plugins pour toi. Là, c'est du développement externalisé. Donc dans la SOA, on pourrait dire, aucun développement en commodité à des tiers. intégration limitée en fonctionnalité standard des éditeurs. A.8.31. Séparation des environnements, dev, test, prod, UAT, QA, peu importe comment tu les appelles. C'est non applicable s'il n'y a pas de dev et pas de test structuré. C'est partiellement applicable si tu testes tes solutions achetées en UAT, User Acceptance and Testing par exemple, ou dans un bac à sable, une sandbox. Donc là, tu dois séparer le test et la prod et les jeux de données et les accès. Et c'est applicable en dev, parce que là, il te faut une séparation stricte. Tu vas avoir des branches différentes, des environnements différents, des accès, des données masquées, etc. Donc au niveau de la SOA, déclaration d'applicabilité, tu pourrais dire que c'est partiellement applicable, on n'a pas d'environnement de développement, on a un environnement de test d'acceptation qui est maintenu pour valider les logiciels du marché avant mise en prod, par exemple. A.8.32, gestion des changements. celui-là, il est toujours là, quasi toujours applicable, même sans code. Tu changes des configs, tu patches, tu déploies des versions. Les exigences, ça veut dire que tu as des demandes de changement, des validations, tu vas avoir une évaluation des risques, des impacts, des différents rôles, des gens qui vont accepter, des rollbacks, revenir en arrière, si jamais ça foire, une journalisation, et en fait, c'est un pivot pour les organisations, même sans dev, ne les sous-estime pas. A.8.33, t'es toujours là ? Je t'avais dit que c'était lourd. A.8.33, c'est information de test. C'est non applicable s'il n'y a aucun test chez toi. C'est applicable ou partiellement applicable si tu fais des tests d'acceptation, des données anonymisées, masquées, et on en a besoin aussi pour le RGPD, des accès limités, une purge après test. Il y a aussi un contrôle sur le DLP, Data Leakage Prevention. Et là, j'ai envie de dire, il peut y avoir un anti-pattern, c'est-à-dire que tu pourrais copier la base de prod en test avec des données clients. Non, on ne fait pas ça. Donc, on pourrait dire pour les SOA partiellement applicables, Les tests d'acceptation utilisent des données masquées. L'accès est restreint et les jeux sont purgés après usage. Alors si t'es arrivé jusqu'ici sans coma, bravo, c'est que j'ai réussi ma mission. Ce que je veux que tu retiennes, ce sont les trois pièges qui font cocher applicable à tort. La peur du consultant. On va tout mettre, on sera tranquille. Non, tu seras surtout plus cher et moins clair. Le réflexe plus strict égale mieux, côté direction. Faux. Mieux égale adapté. Le template générique, ta SOA, doit refléter ton contexte, pas une checklist universelle. Et ici, je te donne un autodiagnostic express avant de plonger dans tout ça. 4 questions. Quelqu'un écrit-il du code chez nous ? A-t-on des développeurs internes ? Est-ce qu'on commande du code à des tiers ? Donc j'imagine des plugins, des modules, des applis. Si t'es pas certain, va voir ta liste de fournisseurs. Et attention... un fournisseur qui n'émet pas de facture est également un fournisseur. Je pense à des plugins open source. Attention à ça. Modifie-t-on du code source ? Des forks, du script maison, en prod, etc. Si tout est non, bravo ! De A.8.25 à A.8.29, c'est not applicable. Et t'as ta justification pour ton auditeur. A.8.30, le développement externalisé dans ce cas-là est non applicable. A.8.31, la séparation des environnements. pourrait s'appliquer si tu fais des tests. A.8.33, l'information de test peut s'appliquer si tu fais des tests. Et là, A.832, j'ai inversé, sorry. La gestion des changements est de toute façon applicable. Je ne connais pas une boîte qui n'a pas d'IT et pas de changement. Donc tu dois bien justifier dans ta SOA. Déclarer non applicable, ça se justifie. Sinon, c'est une non-conformité. C'est une ligne claire, factuelle, sans roman. Tu peux reprendre les exemples ci-dessus, adaptés à ton contexte évidemment. Et aussi, tu relis à chaque changement d'activité. Si tu démarres du DEV, tu réactives les contrôles. Et dans cette partie, je vais te parler des cas modernes qui brouillent un peu les cartes. Le low code ou le no code. Si tes flows exécutent du custom en prod et impactent la sécu, traite-les comme du DEV light. Pense à ce moment-là à A.8.25, A.8.28, A.8.32. A825, cycle de vie du développement sécurisé. A.8.28, codage sécurisé. A.8.32, gestion des changements. On pourrait avoir aussi un SAAS, un software as a service, qui est très configuré. La config reste. Tu deviens dev si tu ajoutes du code, des scripts, des lambdas, des extensions. Tu pourrais faire appel à des intégrateurs. Donc, il y a un connecteur unique codé pour toi. C'est du A.8.30, développement externalisé, applicable, contrat, exigence, livrable et test. Tu pourrais également mettre tes scripts d'admin. S'ils tournent en prod et touchent la sécu, traite-les comme du code. Revue, dépôt, change, secret management, tout ça. En conclusion, ISO 27001 n'est pas « plus tu en mets, mieux c'est » . C'est juste ce qu'il faut, au bon endroit, au bon moment, avec le bon tempo. Tu ne fais pas de dev, n'invente pas une usine à gaz. Concentre tes efforts là où ça protège vraiment ton business. C'était Compliance Without Coma. Et si cet épisode t'a évité des contrôles inutiles et quelques milliers d'euros, mission accomplie. On se retrouve la semaine prochaine et d'ici là, garde ta SOA vivante. C'est une information documentée et elle doit être vue à intervalles réguliers. C'est la clause 7.5 de l'ISO.