Les rouages de la mise en conformité en matière de sécurité - La contribution d'Anove aux bonnes pratiques de la De Nederlandse Bank (DNB)
Les exigences de sécurité des informations des organismes de réglementation qui supervisent le secteur financier manquent d'informations sur la manière dont ces exigences et directives peuvent être mises en œuvre dans un environnement Agile/DevOps et sur l'infrastructure (cloud) qui le soutient. Le respect de ces exigences est une condition préalable au maintien d'une licence bancaire et d'assurance. Outre la nécessité commerciale de maintenir la licence, les risques liés au travail dans un environnement Agile/DevOps sont similaires à ceux liés au travail dans un environnement plus traditionnel ; ainsi, ne pas atténuer ces risques conduirait à une position de risque inacceptable. Les exigences réglementaires à venir dans le secteur financier ajoutent à la complexité. Cet article examine les dynamiques DevOps et Agile, les exigences réglementaires et les lacunes des approches actuelles. Nous terminons par quelques détails de la méthode actuelle de travail en matière de supervision et de mise en place d'une sécurité et d'une conformité réelles pour le secteur financier.
NUMÉRISATION ET MODERNISATION
L'évolution de l'information et des technologies numériques a un impact considérable sur les capacités des sociétés de services financiers et du secteur des services financiers (FSI) dans son ensemble. La transformation numérique nécessite le changement rapide des compétences existantes et le développement de nouvelles compétences expressément pertinentes pour appliquer la numérisation (Mavlutova & Volkova, 2019).
Les clients sont attirés par les entreprises capables de commercialiser rapidement des produits nouveaux et pertinents. La reconnaissance accrue de la marque et la valeur perçue contribuent également à l'innovation des produits (Agolla, Makara et Monametsi, 2018). Les attentes des clients en matière d'accessibilité, de confort, de simplicité d'utilisation et de personnalisation ont évolué en raison des avancées technologiques, de la numérisation et de la future législation (Wójcik & Ioannou, 2020).
Les institutions financières s'adaptent aux besoins en constante évolution des clients et font face à de nouveaux concurrents sous la forme de sociétés de technologie financière. Pour garder une longueur d'avance, ces institutions adoptent des méthodologies agile/DevOps et utilisent l'infrastructure cloud pour rationaliser leur processus de publication de logiciels. Cette approche les aide à lancer des produits plus sûrs, plus stables et plus rapides qui répondent à l'évolution des demandes de leurs clients (Jelassi & Martínez-López, 2020).
LES RISQUES ASSOCIÉS À LA MODERNISATION
Bien que la méthode de travail moderne Agile/DevOps favorise une mise sur le marché plus rapide, elle introduit également de nouveaux risques. L'utilisation d'outils de déploiement automatisés immatures, le manque de ressources compétentes, des politiques de sécurité incohérentes et l'absence de normes et de directives (Akbar, Smolander, Mahmood et Alsana, 2022) font partie des risques critiques qui se traduisent par des produits de mauvaise qualité.
En raison de la nature du cloud, les risques de confidentialité des données, de violation de données, de mauvaise configuration, de compromission des informations d'identification, de piratage de comptes, etc. (Groupe de travail CSA, 2020) sont également accrus.
NORME DE BONNES PRATIQUES DE LA BANQUE CENTRALE DES PAYS-BAS (DNB)
Aux Pays-Bas, tous les établissements placés sous la supervision de la banque centrale (De Nederlandsche Bank DNB) sont tenus de procéder à une auto-évaluation périodique qui mesure les niveaux de maturité opérationnelle de l'établissement.
Dans le cas des Pays-Bas, la Banque nationale néerlandaise déclare (Banque nationale des Pays-Bas, 2019) : « Ce document de bonnes pratiques fournit aux institutions sous notre supervision des conseils pratiques sur la mise en œuvre de mesures de contrôle visant à garantir l'intégrité, la disponibilité continue et la sécurité du traitement électronique des données. » Le document contient 22 thèmes et 58 mesures de contrôle couvrant les sujets suivants : les personnes, les processus, la technologie, les installations, l'externalisation, les tests, le cycle de gestion des risques, la gouvernance et l'organisation.
L'établissement doit évaluer la conception, la mise en œuvre et l'efficacité opérationnelle des mesures de contrôle dans le cadre de cette auto-évaluation. La DNB s'attend à ce que les institutions placées sous sa supervision aient un niveau de maturité d'au moins 3 sur 5 pour COBIT 4.1, allant de 0 (inexistant) à 5 (amélioration continue) pour 55 mesures de contrôle et un score de niveau de maturité de 4 pour les trois mesures de contrôle du cycle de gestion des risques.
POURQUOI LE MAPPAGE EXISTANT NE FONCTIONNE PAS
La sécurité des informations est essentielle, mais les équipes agile/DevOps/Cloud ont besoin d'aide pour comprendre les exigences de la DNB fondées sur des principes ou pour prouver leur conformité en matière de sécurité. Par exemple, l'utilisation du pipeline permet d'éliminer de nombreux risques traditionnels tels que les modifications non autorisées de l'environnement. Les modifications des paramètres de configuration peuvent être éliminées en les traitant spécifiquement.
D'après notre enquête auprès de professionnels de la sécurité dans un environnement financier réglementé, 93,9 % d'entre eux connaissaient un cadre. À la question « Dans quelle mesure cette bonne pratique favorise-t-elle l'utilisation d'Agile/DevOps ? « les personnes interrogées pouvaient obtenir un score sur une échelle de 1 à 5, 5 étant le niveau de soutien le plus élevé. Près de 46 % ont donné une note de 1 ou 2, ce qui peut être considéré comme une réponse négative, 27 % ont obtenu une note neutre et 27 % ont donné une note positive.
Les exigences des organismes de réglementation sont traduites sur la base des connaissances existantes en matière d'environnement, de processus, etc. La transition vers le cloud et les méthodes de travail modernes sont toujours en cours. Il y a donc un conflit entre la traduction (qui est basée sur l'environnement traditionnel) et la nouvelle méthode de travail moderne. En outre, chaque entreprise réalise sa propre traduction de ces directives basées sur les principes. Dans de nombreux cas, ces traductions sont basées sur une infrastructure physique traditionnelle non automatisée sur site et sur des méthodes en cascade pour la réalisation de projets. De plus, ces commandes permettent de remonter le temps (pilotage via le rétroviseur). L'une des caractéristiques essentielles du travail dans un environnement agile/DevOps/Cloud est que la situation peut évoluer rapidement au cours d'une période donnée.
Sur le plan opérationnel, les employés ne savent pas quoi faire et comment livrer les produits en toute sécurité. Ils sont confrontés à des contrôles dans un cadre de contrôle inadapté à la prise en charge de ces cycles de développement rapides et courts de produits. Les principes contenus dans les directives elles-mêmes sont toujours valables (dans la plupart des cas), mais la manière de les appliquer dans un environnement Agile/DevOps/Cloud n'est pas claire.
Maria Chtepen de l'Antwerp Management School a examiné la conformité en matière de sécurité dans le cadre de la méthode de travail agile (Chtepen, 2020). Cependant, aucune étude n'a été menée sur la manière dont cela se traduit par les mesures de contrôle utilisées par les sociétés financières pour contrôler et guider les équipes Agile/DevOps. En outre, les recherches disponibles n'ont pas encore révélé l'essentiel de ce qui est nécessaire pour piloter une méthode de travail agile axée sur la sécurité et fournir une assurance aux différents organismes de surveillance, à la fois en interne au sein de l'organisation, comme la gestion des risques et les auditeurs internes, et en externe, comme les auditeurs légaux et les organismes de réglementation.
NOS RECHERCHES
120 personnes provenant de 10 institutions financières ont participé à notre étude. Ces personnes interrogées ont confirmé notre affirmation selon laquelle les équipes et les institutions ont du mal à comprendre et à adapter les normes de bonnes pratiques de la DNB à leurs environnements agile/DevOps et Cloud.
L'étape suivante consistait à mieux comprendre les différents cadres de contrôle, leurs objectifs et leurs contrôles. Nous avons utilisé plus de 60 articles scientifiques pour mieux comprendre et façonner nos idées. Ensuite, nous avons examiné de manière plus approfondie les 58 mesures de contrôle de la DNB afin de comprendre et de déterminer si le contrôle allait changer ou non dans le cadre de la méthode de travail moderne : agile, DevOps soutenue par le cloud. Nous avons conclu que les mesures de contrôle décrites dans la norme de bonnes pratiques de la DNB, telles qu'un plan de sécurité de l'information, des normes technologiques, l'évaluation et la gestion des risques, la sécurité physique, etc., ne changeaient pas grand-chose entre une configuration traditionnelle et la nouvelle méthode de travail agile et DevOps soutenue par le cloud. Il s'agit de contrôles basés sur des entités/organisations qui ne sont pas spécifiques au mode de travail agile/DevOps pris en charge par l'infrastructure cloud.
La dernière étape a été franchie lors d'une table ronde à laquelle ont participé 15 experts en sécurité possédant plus de 300 ans d'expérience pertinente. Au total, 24 mesures de contrôle ont été considérées comme identiques lorsqu'il s'agit de travailler selon des méthodes de travail traditionnelles ou modernes. Nous nous sommes concentrés sur les 34 contrôles restants, qui seraient affectés par les méthodes de travail modernes. Ils devaient être traduits dans les termes et technologies utilisés par les nouvelles équipes modernes. Pour chacun des 34 contrôles, nous avons examiné les normes de sécurité de l'ISF, de la CSA, du CIS et du NIST (NIST, 2011) et avons noté leurs meilleures pratiques et recommandations. Nous avons résumé ces bonnes pratiques et recommandations en directives essentielles qui peuvent être utilisées par les nouvelles équipes modernes Agile, DevOps et Cloud.
L'énoncé de pratique peut être facilement compris par les équipes Agile/DevOps/Cloud, et il montre également qu'un énoncé de pratique peut répondre à plusieurs exigences et mesures de contrôle de la DNB. Au total, 14 thèmes et 48 énoncés de pratique constituent notre artéfact final.
ARTEFACT DE CONFORMITÉ À LA SÉCURITÉ DE L'INFORMATION
L'artefact conçu s'appelle Information Security Compliance Artefact et couvre les mesures de contrôle de la DNB qui sont différentes de la méthode de travail traditionnelle. Il comprend 14 thèmes et 48 énoncés de pratiques qui peuvent être utilisés par les organisations (financières) qui entreprennent une transition vers l'Agile, le DevOps et le Cloud.
L'artefact a été vérifié auprès d'un groupe de praticiens et d'experts du domaine, et leurs conseils d'experts ont enrichi les énoncés de pratique. Enfin, nous avons comparé les meilleures pratiques d'Azure et d'AWS aux énoncés de pratiques de notre artefact, qui peut être facilement utilisé.
L'artefact peut jouer un rôle clé en permettant à l'équipe Agile/DevOps de mieux comprendre les exigences de la DNB fondées sur des principes. Cet artefact peut être utilisé comme guide par l'équipe Agile/DevOps et les trois lignes de défense pour engager des discussions sur la sécurisation par la conformité.
CONCLUSIONS
Grâce à sa méthode de travail moderne, CI/CD Pipeline, qui permet de créer et de développer des logiciels, joue un rôle essentiel dans le déploiement de (nouvelles) modifications dans l'environnement de production. Les équipes de développement et d'exploitation utilisent Pipeline, une suite automatisée d'outils et de processus, pour créer, tester et publier du code logiciel plus rapidement et plus efficacement. Il est garanti que la sécurité et la conformité peuvent être assurées en mettant en œuvre des principes de sécurité tels que le contrôle d'accès des utilisateurs, la gestion des vulnérabilités, la gestion des modifications, la gestion de la configuration, la conformité à l'état technique, la cryptographie, la destruction des données, etc. dans le code via un pipeline. Des exemples de la manière dont la sécurité peut être assurée par le biais de pipelines sont principalement établis via :
- Gestion de l'accès des utilisateurs: assurez-vous que les informations d'identification et les secrets sont récupérés dans des endroits sûrs tels que Key Vaults plutôt que d'être incorporés dans des fichiers de configuration et de code via une infrastructure en tant que code. Les vérifications de confiance peuvent être effectuées beaucoup plus rapidement grâce à des outils automatisés. De plus, les écarts dans les droits peuvent être signalés beaucoup plus rapidement.
- Gestion du changement: Les mesures de contrôle telles que les vérifications à quatre yeux, le test du code/de la fonctionnalité/du produit dans des environnements hors production avant de les déployer en production et le contrôle des versions sont automatisées et intégrées au pipeline. Cela signifie que les preuves d'audit sont principalement « dans le code » et en temps (quasi) en temps réel.
- Gestion opérationnelle: les paramètres de configuration sont exécutés par code et les modifications (non autorisées), le cas échéant, sont capturées dans la surveillance des événements de sécurité. Les paramètres de sauvegarde de la configuration et des données sont également automatisés par code. Les tests de restauration réguliers sont également automatisés et peuvent être vérifiés régulièrement. En raison de l'évolution constante du paysage des menaces et des vulnérabilités, les pratiques considérées auparavant comme du codage sécurisé ne le sont peut-être plus. La stratégie la plus résiliente et la plus complète consiste à automatiser l'analyse du code à l'aide d'un outil ou d'une technologie capable de suivre l'évolution constante du paysage des menaces.
La sécurisation des environnements cloud via des pipelines bénéficie de l'automatisation et profite des preuves automatisées qui peuvent être obtenues grâce à la mise en œuvre de ces trois principaux domaines de contrôle. Toutes ces pratiques de contrôle permettent de tester immédiatement l'efficacité opérationnelle puisqu'elles sont codées en dur, ce qui permet de faire un bond en avant considérable en termes de temps d'audit et de travail manuel.
Nous concluons que davantage d'instructions opérationnelles sont nécessaires pour rendre la norme de bonnes pratiques de la DNB plus facile à comprendre et à mettre en œuvre. Cela le rendra plus concret. D'autre part, cela nécessite des capacités nouvelles et plus tournées vers l'avenir de l'évaluateur, telles que la gestion des risques et l'audit, car il doit évaluer les preuves différemment de ce qu'il ferait normalement dans une entreprise non issue de la technologie avec un mode de travail traditionnel.
REMARQUE : Cette étude a été menée avec le soutien de représentants du FSI d'Achmea, d'ING Bank, d'ABN AMRO, d'Aegon, d'AIA Group, de Baloise Insurance, de BeFrank, de BNP Paribas, de Discover Financial Services, d'Euroclear, de Leaseplan, de Monuta, de Nationale Nederlanden/NN-Group ONVZ, de Rabobank, de MUFG Bank Europe, de Volksbank, etc.
Les résultats de la recherche ont été transmis à la Banque nationale néerlandaise (DNB) et ont été bien accueillis et intégrés dans le nouveau cadre, qui a été publié récemment : Good Practice Informatiebeiliging 2023.
Vous pouvez contacter directement les auteurs pour plus de détails et demander un article complet.
L'article est disponible sur ISACA journal NL : https://isaca.nl/isaca-journal/the-nuts-and-bolts-of-achieving-security-compliance/
