Dans mon article précédent, DevSecOps et coordination des versions j'ai présenté l'idée de quatre acteurs clés dans le processus de gestion des versions médiées par DevSecOps. L'idée est de consolider les étapes de validation et d'approbation à partir d'un processus «fermé» et de déplacer le travail réel de validation plus tôt dans le développement. Dans cet article, nous explorerons le rôle de l'architecte de sécurité dans le développement global, les tests et la sortie du logiciel. Pour aider les équipes à mieux comprendre ce rôle, j'ai créé un personnage . Ceci est une description à la première personne du rôle, des responsabilités, de l'outillage et des artefacts clés.
Je suis donc heureux de vous présenter Sanghita, votre architecte de sécurité.
Architecte de sécurité Persona
En tant qu'architecte de sécurité , Je suis responsable de veiller à ce que toutes les politiques de sécurité d'entreprise appropriées soient définies, communiquées, suivies et que le produit soit conforme aux meilleures pratiques de sécurité réglementaires, d'entreprise et de l'industrie.
Ma principale responsabilité est de garantir la conformité avec la politique de sécurité et que l'application est construite à l'aide de pratiques de codage sécurisées. J'assure également le contrôle des intégrations de composants tiers pour les risques. Mon implication est tout au long du processus de développement, en commençant par le propriétaire du produit pour l'examen des histoires d'utilisateurs ayant une incidence sur la conformité réglementaire, le responsable du développement pour déterminer les vulnérabilités systématiques potentielles dans l'application et pour m'assurer que l'équipe de test a créé des cas de test de sécurité fonctionnelle appropriés. Lorsque le propriétaire du produit planifie une version candidate à la production, j'affirme que les cas de test de sécurité ont réussi et que tous les contrôles / atténuations de sécurité appropriés sont en place.
l'un des quatre rôles clés dans la coordination des versions.
Avant le déploiement de la production proprement dite, il existe quatre états de préparation des versions clés requis (figure 2). Ces quatre statuts de produit garantissent à l'équipe de publication, composée du responsable du produit, du coordinateur des opérations, de l'architecte de la sécurité et du coordinateur de la version, que la version candidate de production est prête pour les heures de grande écoute. Cette équipe représente le seul décideur de ce qui est et n'est pas mis en production. La décision n'est influencée que par la qualité du produit, la conformité et la disposition de l'organisation à prendre en charge. Chaque membre de l'équipe de publication est responsable de l'un de ces états; ce rôle assure la préparation de la mise en production de l'organisation. Au cours des réunions de version régulièrement planifiées, l'équipe examine chaque version de produit planifiée et capture les quatre états de préparation. La version du produit progresse avec l'approbation de tous les états de préparation.
États de préparation à la libération
Figure 2. États de préparation à la publication avec des personnages propriétaires
Dans cette approche, seulement quatre examinateurs / des approbateurs existent pour toute version de produit donnée . L'autorité complète pour cette version ne naît également que de ces quatre rôles, ce qui améliore considérablement la vitesse d'approbation de la version et attribue clairement la responsabilité ultime du succès de la version.
Utilisation des outils et responsabilités du flux de travail
L'architecte de sécurité utilise plusieurs des outils automatisés pour effectuer une grande partie du «travail lourd» pour l'examen de la sécurité et de la conformité des versions candidates. Parmi ceux-ci, la numérisation du code et des composants (par exemple Nexus IQ, Veracode, etc.) est de la plus haute valeur. Cela permet à l'architecte de la sécurité de fournir un retour direct sur les violations de politique de sécurité au début de l'effort de développement, facilitant ainsi la correction ou l'atténuation de la vulnérabilité. Enfin, dans le cadre de la «modélisation de la surface d'attaque», l'architecte de sécurité fournit des conseils utiles aux équipes de développement sur où concentrer les efforts de renforcement de la sécurité des applications. pour accomplir bon nombre de ses responsabilités de flux de travail
Les responsabilités de l'architecte de sécurité comprennent:
- examen de tous les résultats de l'analyse (c.-à-d. code statique, application dynamique, vulnérabilités des composants)
- recommandations pour les contrôles de correction ou de compensation
- examen de la sécurité et politique de conformité (en particulier pour les outils automatisés)
- gouvernance des meilleures pratiques de codage sécurisé
- examen périodique des exigences de conformité réglementaire avec les groupes de développement
L'architecte de la sécurité vérifie que tous les tests fonctionnels de sécurité se sont correctement déroulés. Elle assure également l'atténuation ou le contrôle de toutes les vulnérabilités découvertes.
Artefacts clés
Il existe plusieurs artefacts clés que l'architecte de sécurité utilise, suit ou gère d'une autre manière:
- Security Checklis t – Une brève description des failles de sécurité courantes à utiliser lors de l'examen des nouvelles demandes commerciales.
- Stratégie relative aux composants tiers – Déclarations de politique automatisées (par exemple via Sonatype Nexus IQ) pour garantir que l'entreprise utilise l'ouverture sécurisée composants source. Ces politiques nécessitent un examen et une mise à jour périodiques pour garantir le contrôle des nouveaux exploits.
- Politique de sécurité du développement – Collection de politiques de sécurité conçues pour aider les équipes de développement à corriger / contrôler les vulnérabilités les plus courantes.
- Résultats de l'analyse du code et des applications – Résultats compilés à partir des divers outils de sécurité automatisés. Utilisé pour communiquer avec l'équipe de développement pour la correction / atténuation des vulnérabilités.
Conclusion
Le rôle de l'architecte de sécurité dans la coordination des versions se concentre principalement sur la création de code sécurisé. Cela comprend l'identification et l'atténuation des vulnérabilités potentielles et l'affirmation de la disponibilité des versions. Les états de préparation sont basés sur les résultats d'audit des revues de sécurité automatisées et manuelles. En tant que responsable de la sécurité, l'architecte de la sécurité travaille en étroite collaboration avec les membres de l'équipe pour assurer la livraison d'un produit hautement sécurisé.
Source link