Meilleures pratiques DevSecOps – Conformité automatisée

Les pratiques logicielles sécurisées sont au cœur de tout développement de système; doublement pour les secteurs hautement réglementés tels que les prestataires de soins de santé. Plusieurs contrôles réglementaires sont nécessaires pour la garde des données des patients et des clients, la création de systèmes logiciels sécurisés, la gouvernance des environnements de développement et la bonne gestion des informations d'audit. En tant que meilleure pratique, il est recommandé d'adopter l'automatisation de certains audits de sécurité, l'intégration de la surveillance de la conformité dans les domaines clés du processus de développement (par exemple, la prise en charge, la construction, la gestion des versions) et les outils de pipeline DevOps.

Un aspect essentiel de la sécurité et L'audit de DevSecOps doit permettre l'automatisation de l'analyse des vulnérabilités du code système. Cela inclut la structure d'application statique, le comportement d'application dynamique, les niveaux de correctif / version des composants tiers et la conformité globale de l'environnement de déploiement avec les systèmes d'exploitation renforcés. La valeur de cette automatisation est la réduction de temps pour le personnel de sécurité pour auditer, rassembler et publier les vulnérabilités du système pour la correction. Cela garantit que les problèmes découverts ont été résolus en temps opportun. Avec une approche automatisée, la gouvernance de la sécurité est plus fréquente, la détection des vulnérabilités améliorée et les preuves de correction pour les auditeurs externes.

Le développement de logiciels est un processus complexe et il existe plusieurs bonnes pratiques pour lutter contre la vulnérabilité des applications. Les sections suivantes couvrent les principaux domaines de préoccupation lors du développement d'une pratique de codage sécurisé et de l'automatisation de la gouvernance de la sécurité.

Analyse du code source

Une mesure défensive de première ligne consiste à effectuer une analyse statique du code source pendant un processus de génération continu. Ce mécanisme de détection actif empêche les vulnérabilités connues d'être intégrées par inadvertance dans le système. Les équipes de sécurité et d'architecture devraient être impliquées dans la culture d'un ensemble standard de pratiques de sécurité pour aider à soutenir un processus assisté par outil. À des fins d'efficacité, ces politiques doivent être codées dans un outil d'analyse automatisé, avec en sortie un ensemble d'étapes de correction recommandées pour réduire ou supprimer les vulnérabilités détectées. Par exemple, si un développeur crée un élément d'interface utilisateur (c'est-à-dire une zone de texte) pour la collecte de données, mais ne valide pas le contenu de cet élément, la possibilité existe pour une attaque par injection SQL, une attaque d'exécution de script intersite ou autre vulnérabilités connues (voir figure 1). L'analyse de code sécurisé détectera ces situations, les signalera pour plus d'attention et créera un journal d'audit des résultats de l'analyse. Dans le processus d'intégration continue (CI), ces analyses se produisent pendant ou juste avant l'étape de génération du pipeline DevOps.

Figure 1. Résultat de l'analyse de sécurité SonarQube [19659008] Analyse dynamique des applications

L'analyse dynamique des applications est un processus automatisé exécuté sur une application déployée pour détecter diverses formes de vulnérabilités connues. Étant donné que les dix principales vulnérabilités de l'OWASP sont bien connues dans la communauté du développement mais continuent de générer des incidents, des pannes, des pertes et des violations de données, il est important d'inclure une analyse de vulnérabilité des applications dynamiques avec chaque déploiement de système . Ceci est particulièrement important lorsqu'un système est déployé en production, mais a une valeur significative dans le cadre du processus global de déploiement continu (CD). Plusieurs outils sont disponibles sur le marché commercial, tels que Veracode analyse dynamique, qui peut analyser les applications / API déployées pour détecter les vulnérabilités possibles, signaler ces résultats aux équipes de conformité et de développement et fournir un enregistrement d'audit de

Data Stewardship

Bien que ne faisant pas techniquement partie de l'architecture d'audit de sécurité automatisée DevSecOps, la gouvernance des données est essentielle pour une organisation hautement conforme. Bien qu'au-delà de la portée de l'automatisation CI / CD discutée dans ce billet de blog, il est néanmoins utile d'envisager d'ajouter une automatisation pour l'audit de la validation du chiffrement des données, des règles et autorisations de visibilité des données, des politiques de conservation des données et du transport sécurisé des données dans le cadre du développement global.

Composant tiers

Un nombre important de bibliothèques et de composants utilisés dans le développement de logiciels modernes sont réutilisés dans tous les projets. De nombreux groupes de développement s'appuient sur des composants tiers pour gagner en efficacité de développement (c'est-à-dire open source ou sous licence commerciale), avec pour conséquence l'introduction de vulnérabilités éventuelles. Il est important d'élaborer un plan pour régir les types de bibliothèques, de composants, de licences et de versions de ces dépendances dont l'utilisation dans l'environnement informatique est autorisée. Un processus actif doit noter les composants qui sont approuvés pour une utilisation dans le développement et la version de ces composants dans les applications existantes. Cela signifie qu'un référentiel contrôlé central (par exemple JFrog Artifactory, Nexus Repo, Azure DevOps Artifacts, etc.) doit être établi pour stocker et mettre à disposition tous les composants approuvés et le code réutilisable. Dans le cas de la plupart des composants open source et commerciaux, la NIST National Vulnerability Database fournit une liste constamment mise à jour des vulnérabilités connues ou suspectées. Cependant, étant donné que cette base de données n'est pas mise à jour aussi rapidement que les menaces sont détectées, plusieurs produits commerciaux ont été créés pour fournir un mécanisme de rapport plus rapide (par exemple, Sonatype Nexus IQ).

Figure 2. Rapport de violation de sécurité Sonatype Nexus IQ

De plus, en surveillant en permanence l'état de la version des composants tiers pour les logiciels déployés dans les environnements de production, la surface d'attaque globale de l'application (et ses dépendances) est considérablement réduit. L'automatisation de ces analyses via des outils commerciaux est donc fortement recommandée, toutes les vulnérabilités détectées étant immédiatement recherchées pour leur validité et leur correction.

En tant que partie centrale du développement, de l'intégration et du déploiement de systèmes logiciels, il est nécessaire de configurer l'application logicielle pour le déploiement. dans plusieurs environnements informatiques inférieurs et supérieurs (par exemple DEV / TST / INT / UAT / STG / PRD). Cela nécessite que chaque application soit configurée avec des informations de connexion / configuration qui incluent souvent diverses clés, certificats, informations d'identification et autres informations qui doivent rester privées et sécurisées. Dans le modèle DevSecOps, ceci est accompli en séparant le nom de l'élément de configuration (par exemple «DB_Connection») de la valeur (par exemple «SERVER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)) (HOST = MyHost) (PORT = MyPort) ) (CONNECT_DATA = (SERVICE_NAME = MyOracleSID))); uid = myUsername; pwd = myPassword; ”). L'approche courante consiste à séparer ces secrets dans un «coffre-fort» auquel on accède pendant le processus de déploiement continu. Les secrets sont récupérés en toute sécurité via l'automatisation du déploiement, associée à l'unité de déploiement produite par CI Automation, et le produit résultant est déployé dans l'environnement cible.

La gestion et la gouvernance de ces secrets d'application doivent être séparées. de l'équipe de développement elle-même, mais facilement accessible via l'automatisation du déploiement.

Gestion des secrets

Les secrets sont nécessaires au fonctionnement de tous les systèmes logiciels modernes. Ces secrets peuvent prendre la forme d'une clé de chiffrement SSH, d'un certificat signé numériquement ou d'informations d'identification d'utilisateur (par exemple, nom d'utilisateur / mot de passe). Ces secrets doivent être sécurisés et séparés du code système principal. Comme indiqué ci-dessus, les applications sont configurées avec les informations d'identification / clés / certificats appropriés pendant le processus de déploiement, lorsque ces éléments de configuration sont remplacés par des valeurs d'espace réservé dans le fichier de configuration d'application / la banque de données. Une approche courante du défi de la gestion des secrets consiste à utiliser une application spécialement conçue pour sécuriser ces informations, mais qui est accessible de manière pragmatique par l'automatisation du déploiement si nécessaire. Les exemples incluent Hashicorp Vault, Azure Vault et d'autres systèmes de gestion secrets.

Séparation des tâches

Une partie essentielle de la création de systèmes sécurisés consiste à séparer les tâches des responsables de la création du système logiciel de ceux chargés de l'audit. l'état de sécurité de ces systèmes. Dans la plupart des organisations, cette séparation est imposée par une équipe centralisée de sécurité / conformité qui travaille en étroite relation avec les équipes de développement. Ces «responsables de la conformité» sont chargés d'établir les bonnes pratiques de codage sécurisé, les politiques de développement et l'automatisation des politiques pour un audit efficace et fréquent. À leur tour, les équipes de développement doivent connaître et comprendre toutes les politiques d'entreprise applicables, les exigences en matière de documentation et comprendre où / quand dans le processus de développement le responsable de la conformité de la sécurité doit être consulté.

NIST 800 Series – IT Security Standard – Les normes du gouvernement américain pour la sécurité informatique

OWASP Security Center – Un groupe d'intérêt spécial spécialisé dans la sécurité informatique, les pratiques de codage sécurisées et l'évaluation de la maturité organisationnelle des pratiques de sécurité des logiciels

Renforcement du système d'exploitation CIS – Une collection de contrôles spécifiques au système d'exploitation pour minimiser la surface d'attaque des applications s'exécutant sur ces systèmes d'exploitation

À propos de l'auteur <! -: blieberman, Architecte de solution principal ->

Ben Lieberman est actuellement architecte de solutions senior au sein du groupe de livraison DevOps de Perficient Inc.. Le Dr Lieberman possède plus de vingt ans d'expérience en développement de logiciels et de systèmes dans un large éventail d'industries, y compris les finances, le gouvernement, les télécommunications, les sciences de la vie, les services de voyage et les systèmes de lancement spatial. Il est très expérimenté sur plusieurs sujets de développement logiciel, y compris l'analyse des exigences, l'analyse et la conception de systèmes, le développement de systèmes sécurisés, la gestion de configuration et le déploiement automatisé (alias DevSecOps). Il possède également une expérience en développement direct dans plusieurs langages, notamment les langages de codage Java, C #, C ++ et Salesforce (APEX), et travaille directement avec les équipes de développement sur les pratiques de livraison agiles. Le Dr Lieberman est un écrivain professionnel accompli avec un livre («The Art of Software Modeling», Auerbach Publishing, 2006) et plus de trois douzaines d'articles professionnels en informatique à son actif. Le Dr Lieberman est titulaire d'un doctorat en biophysique et génétique de l'Université du Colorado, Anschutz Medical Center, Denver, Colorado.

More from this Author