ISO 27001 – Annexe A.14 : Acquisition, développement et maintenance de systèmes

Quel est l’objectif de l’annexe A.14.1 ?

L'annexe A.14.1 concerne les exigences de sécurité des systèmes d'information. L’objectif de ce domaine de l’annexe A est de garantir que la sécurité de l’information fait partie intégrante des systèmes d’information tout au long de leur cycle de vie. Cela inclut également les exigences relatives aux systèmes d'information qui fournissent des services sur les réseaux publics.

La norme ISO 27001:2013 couvre le cycle de vie de A.14.1.1 à A.14.1.3 et constitue une partie importante du système de gestion de la sécurité de l'information (SMSI), surtout si vous souhaitez obtenir la certification ISO 27001.

A.14.1.1 Analyse et spécification des exigences en matière de sécurité de l'information

Les exigences liées à la sécurité de l’information doivent être incluses dans toute exigence relative aux nouveaux systèmes d’information ou aux améliorations des systèmes d’information existants. Cela peut se produire parallèlement à A.6.1.5 dans le cadre de la sécurité des informations dans les projets et doit prendre en compte la valeur des informations à risque qui pourrait s'aligner sur le système de classification des informations en A.8.2.1.

Lors de tout développement de nouveau système ou modification de systèmes existants, il est important de comprendre quelles sont les exigences commerciales en matière de contrôles de sécurité en effectuant une évaluation des risques. Cela doit être fait avant la sélection ou le début du développement d’une solution. Les considérations de sécurité doivent être prises en compte dès que possible pour garantir que les exigences correctes sont identifiées avant le début de la sélection de la solution.

Les exigences de sécurité doivent être documentées et convenues afin qu'elles puissent être référencées lors de l'acquisition ou du développement de la solution. Ce n’est pas une bonne pratique de sélectionner ou de développer une solution puis d’évaluer ensuite le niveau de capacité de sécurité. Cela entraîne souvent des risques et des coûts plus élevés et peut également entraîner des problèmes dans la législation applicable telle que le RGPD qui encourage une philosophie de conception sécurisée et des techniques telles que les évaluations d'impact sur la protection des données et la vie privée (DPIA). Il existe également de nombreux sites Web prônant des pratiques de développement sécurisées et des principes clés à prendre en compte, tels que ceux préconisés par le National Cyber ​​Security Center (NCSC). La norme ISO 27002 comprend également des conseils de mise en œuvre. Tous les principes suivis doivent être documentés.

L'auditeur vérifiera que la sécurité est prise en compte à toutes les étapes du cycle de vie d'un projet, pour un nouveau système ou des modifications apportées à un système existant. Ils s’attendront également à ce que la confidentialité, l’intégrité et la disponibilité soient prises en compte au minimum avant le début du processus de sélection ou de développement.

A.14.1.2 Sécurisation des services d'application sur les réseaux publics

Les informations impliquées dans les services d'application transitant sur les réseaux publics doivent être protégées contre les activités frauduleuses, les litiges contractuels et la divulgation et la modification non autorisées. Pour les services fournis sur un réseau public, comme Internet, il est important de comprendre les niveaux de risque impliqués et les exigences commerciales en matière de protection des informations. Encore une fois, il est important de considérer la confidentialité, l’intégrité et la disponibilité.

Lorsque des transactions financières ou des informations personnelles sensibles font partie du service, il est particulièrement important de prendre en compte la sécurité afin de minimiser le risque d'activité frauduleuse, les exigences du RGPD en matière de cryptage et autres garanties devant constituer les exigences minimales. Une fois opérationnels, il est important de garantir que ces services sont constamment surveillés pour détecter toute attaque ou activité indésirable. L'auditeur s'attendra à ce que l'on prenne en compte le « degré de sécurité » des services d'application sur les réseaux publics, avec des décisions basées sur l'évaluation des risques et d'autres exigences légales, réglementaires et contractuelles.

A.14.1.3 Protection des transactions de services d'application

Les informations impliquées dans les transactions des services d'application doivent être protégées pour empêcher une transmission incomplète, un mauvais acheminement, une modification non autorisée des messages, une divulgation non autorisée, une duplication ou une relecture non autorisée des messages. Une protection supplémentaire est susceptible de sécuriser les transactions de services d'application (pas nécessairement uniquement les transactions financières). Ceux-ci peuvent inclure : Utilisation de signatures électroniques, Utilisation de cryptage ; et Utilisation de protocoles sécurisés. Il sera probablement également nécessaire de surveiller en permanence ces transactions en temps quasi réel.

Quel est l’objectif de l’annexe A.14.2 ?

L'annexe A.14.2 concerne la sécurité dans les processus de développement et de support. L'objectif de ce domaine de l'annexe A est de garantir que la sécurité de l'information est conçue et mise en œuvre au cours du cycle de vie de développement des systèmes d'information.

A.14.2.1 Politique de développement sécurisé

Des règles pour le développement de logiciels et de systèmes doivent être établies et appliquées aux développements au sein de l'organisation. Une politique de développement sécurisé est utilisée pour garantir que les environnements de développement sont eux-mêmes sécurisés et que les processus de développement et de mise en œuvre des systèmes et des modifications du système encouragent l'utilisation de pratiques de codage et de développement sécurisées.

Ces politiques incluront notamment la démonstration de la manière dont la sécurité doit être prise en compte à toutes les étapes du cycle de vie du développement, de la conception à la mise en œuvre réelle. Les langages de codage et les outils de développement spécifiques présentent des vulnérabilités différentes et nécessitent en conséquence des techniques de « renforcement » différentes. Il est important que celles-ci soient identifiées et acceptées et que les développeurs soient conscients de leurs responsabilités pour les suivre.

Les politiques conformes aborderont les points de contrôle de sécurité pendant le développement ; référentiels sécurisés ; sécurité dans le contrôle de version ; connaissance de la sécurité des applications ; et la capacité des développeurs à éviter les vulnérabilités, puis à les trouver et à les corriger lorsqu'elles se produisent. L'auditeur vérifiera ici que les considérations de sécurité sont adaptées au niveau de risque pour les systèmes en cours de développement ou de modification et que ceux qui effectuent le développement comprennent la nécessité d'inclure des considérations de sécurité tout au long du cycle de vie du développement. Une sélection initiale rigoureuse lors de l'embauche pour ces compétences, la gestion de la vie et la formation des ressources sont essentielles et des pratiques telles que la programmation en binôme, les examens par les pairs et l'assurance qualité indépendante, les révisions de code et les tests sont tous des attributs positifs.

A.14.2.2 Procédures de contrôle des modifications du système

Les modifications apportées aux systèmes au cours du cycle de vie de développement doivent être contrôlées par l'utilisation de procédures formelles de contrôle des modifications. Les procédures de contrôle des modifications du système doivent s’intégrer, être alignées et soutenir le contrôle des modifications opérationnelles. Les procédures formelles de gestion des modifications sont conçues pour réduire le risque de développement accidentel ou délibéré de vulnérabilités susceptibles de compromettre les systèmes une fois les modifications mises en œuvre. Pour le contrôle des modifications du système, il est important que le propriétaire du système comprenne quelles modifications sont apportées à son système, pourquoi et par qui. Il est de leur responsabilité de garantir que leurs systèmes ne sont pas compromis par un développement médiocre ou malveillant.

Ils devraient donc être impliqués dans l’établissement des règles d’autorisation et de tests et contrôles préalables. Les journaux d'audit sont requis pour fournir la preuve de l'utilisation correcte des procédures de changement. La norme ISO 27002 documente de nombreux aspects du contrôle des modifications qui doivent être inclus, allant de la simple documentation des modifications jusqu'à la prise en compte du temps de déploiement pour éviter un impact négatif sur l'entreprise. Ce contrôle, comme d'autres en A.14, est également conforme aux procédures documentées en A.12.1.2.

A.14.2.3 Examen technique des applications après des modifications de la plateforme d'exploitation

Lorsque les plates-formes d'exploitation sont modifiées, les applications critiques pour l'entreprise doivent être examinées et testées pour garantir qu'il n'y a pas d'impact négatif sur les opérations ou la sécurité de l'organisation. Lorsque les plates-formes de système d'exploitation changent, il est courant que certaines applications puissent avoir des problèmes de compatibilité. Il est donc important de tester les modifications du système d'exploitation dans un environnement de développement ou de test où la compatibilité des applications métier critiques peut être vérifiée avec le système d'exploitation modifié. Les procédures de contrôle et de test des modifications du système d'exploitation doivent suivre le contrôle standard de gestion des modifications.

A.14.2.4 Restrictions sur les modifications apportées aux progiciels

Les modifications des progiciels doivent être découragées, limitées aux changements nécessaires et toutes les modifications doivent être strictement contrôlées. Les progiciels fournis par les fournisseurs sont conçus pour le marché de masse et ne sont pas vraiment conçus pour les organisations qui y apportent leurs propres modifications. En fait, la plupart du temps, la possibilité d'effectuer de telles modifications est verrouillée par le fournisseur et la personnalisation limitée au package. Lorsqu'un logiciel open source est utilisé, il est beaucoup plus probable que des modifications puissent être apportées par l'organisation. Toutefois, celles-ci doivent être restreintes et contrôlées pour garantir que les modifications apportées n'ont pas d'impact négatif sur l'intégrité ou la sécurité interne de l'organisation. logiciel.

A.14.2.5 Principes d'ingénierie des systèmes sécurisés

Les principes d’ingénierie des systèmes sécurisés doivent être établis, documentés, maintenus et appliqués à tout effort de mise en œuvre de systèmes d’information. Les principes du génie logiciel sécurisé existent à la fois au niveau général et au niveau spécifique aux plates-formes de développement et aux langages de codage. Partout où un développement est en cours, la sélection et l’application de ces principes doivent être prises en compte, évaluées, formellement documentées et mandatées. L'auditeur voudra s'assurer que, comme pour de nombreux contrôles, l'utilisation des principes d'ingénierie système est prise en compte par rapport aux niveaux de risque identifiés et recherchera des preuves pour étayer les choix effectués.

A.14.2.6 Environnement de développement sécurisé

Les organisations doivent établir et protéger de manière appropriée des environnements de développement sécurisés pour les efforts de développement et d’intégration de systèmes qui couvrent l’ensemble du cycle de vie du développement du système. Les environnements de développement doivent être protégés pour garantir le développement et la mise à jour malveillants ou accidentels de code susceptible de créer des vulnérabilités ou de compromettre la confidentialité, l'intégrité et la disponibilité. Les exigences en matière de protection doivent être déterminées à partir de l’évaluation des risques, des exigences commerciales et d’autres exigences internes et externes, notamment la législation, la réglementation, les accords contractuels ou les politiques. En particulier, si une forme de données actives est utilisée dans des environnements de développement, elle doit être particulièrement protégée et contrôlée.

A.14.2.7 Développement externalisé

L'organisation doit superviser et surveiller l'activité de développement de systèmes externalisés. Lorsque le développement de systèmes et de logiciels est sous-traité en totalité ou en partie à des parties externes, les exigences en matière de sécurité doivent être spécifiées dans un contrat ou un accord joint. C’est là qu’il est important que l’Annexe A 15.1 soit correcte, ainsi que l’Annexe A.13.2.4 pour la non-divulgation et la confidentialité.

Il est également important de superviser et de surveiller le développement pour avoir l'assurance que les normes organisationnelles et les exigences en matière de sécurité au sein des systèmes sont respectées. En fonction du degré d'intégration des partenaires externalisés au sein de l'organisation, en particulier si le personnel est situé dans les locaux de l'organisation, il est important d'inclure leur personnel dans les formations de sensibilisation à la sécurité, ainsi que dans les programmes et communications de sensibilisation. Il est essentiel de garantir que les pratiques de sécurité interne du partenaire externalisé, par exemple le contrôle du personnel, répondent au moins aux exigences d'assurance pertinentes aux niveaux de risque liés aux développements sur lesquels ils travailleront.

L'auditeur vérifiera que, lorsque l'externalisation est utilisée, il existe des preuves de diligence raisonnable avant, pendant et après la mission du partenaire externalisant et inclut la prise en compte des dispositions en matière de sécurité de l'information.

A.14.2.8 Tests de sécurité du système

Les tests des fonctionnalités de sécurité doivent être effectués pendant le développement. Des tests spécifiques des fonctionnalités de sécurité pour tout développement doivent être effectués et approuvés par une autorité appropriée possédant la compétence et la responsabilité en matière de sécurité. Les résultats attendus des tests de sécurité doivent être documentés avant le début des tests et doivent être basés sur les exigences commerciales en matière de sécurité. L'auditeur voudra s'assurer qu'il existe des preuves que des tests spécifiques à la sécurité ont été effectués dans tout développement pertinent pour la sécurité.

A.14.2.9 Tests d'acceptation du système

Des programmes de tests d'acceptation et des critères associés doivent être établis pour les nouveaux systèmes d'information, les mises à niveau et les nouvelles versions. Pour les tests d'acceptation, les tests et les critères permettant de démontrer la réussite d'un test doivent être conçus et développés en fonction des exigences commerciales avant que les tests ne soient effectués. Les tests d'acceptation doivent également inclure des tests de sécurité. L'auditeur recherchera des preuves démontrant que les critères et les méthodes des tests d'acceptation ont été conçus conformément aux exigences de l'entreprise et incluent des dispositions pour les tests d'acceptation de sécurité.

Quel est l’objectif de l’annexe A.14.3 ?

L'annexe A.14.3 concerne les données d'essai. L’objectif de ce domaine de l’annexe A est d’assurer la protection des données utilisées pour les tests.

A.14.3.1 Protection des données d'essai

Les données de test doivent être sélectionnées avec soin, protégées et contrôlées. Les données de test doivent idéalement être créées sous une forme générique sans rapport avec les données système en direct. Cependant, il est reconnu que des données réelles doivent souvent être utilisées pour effectuer des tests précis. Lorsque des données en direct sont utilisées pour les tests, elles devraient l'être ; Anonymisé autant que possible ; Soigneusement sélectionné et sécurisé pour la période de test ; Supprimé en toute sécurité une fois les tests terminés. L'utilisation des données en direct doit être pré-autorisée, enregistrée et surveillée. L'auditeur s'attendra à ce que des procédures robustes soient mises en place pour protéger les données utilisées dans les environnements de test, en particulier s'il s'agit de données entièrement ou partiellement actives.

Vous trouverez davantage d'aide sur les exigences de la norme ISO 27001 et les contrôles de l'annexe A dans le coach virtuel ISMS.online qui complète nos cadres, nos outils et notre contenu politique.