SDLC

Cycle de développement sécurisé : le référentiel de SAFECode.

La prise en compte de la cyber sécurité dans les cycles de développement est une activité primordiale. Plusieurs référentiels de bonne pratique sont disponibles. Par exemple, la norme ISO 27034 fournit un cadre pour renforcer la sécurité du processus de développement. Autres exemples, le modèle BSIMM et SSDFSAFECode est une association internationale qui se focalise sur les bonnes pratiques visant à améliorer la sécurité dans les développements. Cette organisation publie et met à jour régulièrement son référentiel de sécurisation du cycle de développement. Comment identifier les exigences. Comment gérer les composants externes « OpenSource » ou et propriétaires. Comment gérer les problèmes de sécurité. Comment traiter les vulnérabilités découvertes dans ses applications.

Le référentiel de développement sécurisé du NIST

Le SSDF (Secure Development Framework)du NIST propose des bonnes pratiques pour mettre sous contrôle son cycle développement, à l’instar d’autres référentiels comme celui de SAFECode, de BSIMMou de l’ISO 27034. Le contenu du référentiel est orienté sur l’organisation, les compétences et les outils à mettre en place, les protections contre les accès non autorisés aux composants, les pratiques de développant pour minimiser les vulnérabilités et les réponses en cas de détection de failles. Le référentiel répond à la section 4 du document fédéral signé par le Président des Etats-Unis sur l’amélioration de la Cybersécurité. Il répond aussi à l’augmentation des risques liés à la sous-traitance : voir à ce sujet l’ISO 27036et le SCRM.

Modélisation des menaces ou Threat Modeling

La modélisation des menaces (Threat Modeling) est une activité fondamentale pour identifier et traiter les failles dès la conception avant la phase de développement d’un logiciel ou d’un système. Cette activité fait partie des connaissances requises par les programmes des certifications CISSP : domaine 8, CCSP et CCSK. Certaines méthodes se focalisent sur les menaces et les problèmes de sécurité alors que d’autres comprennent une évaluation des risques au travers leur impact et leur vraisemblance. L’idéal est de planifier cette activité le plus tôt possible dans le cycle de développement, dès que l’architecture est définie. La modélisation doit être mise à jour si nécessaire. Par exemple dans le cas de changement de classification des informations, de modification de l’architecture, de changement de mode d’authentification ou d’autorisation, de modification des exigences métier concernant les exigences de traçabilité ou encore de mise à jour des méthodes cryptographiques.

SABSA pour les architectes sécurité : acteurs plutôt que censeurs

La plupart des groupes vivent au quotidien des transformations digitales structurantes. L’objectif est de développer le business avec des outils performants et sécurisés, de le faire vite, avec agilité et en maitrisant les coûts. Il faut créer de la valeur et la protéger. La sécurité doit évidemment accompagner cette transformation, sans la freiner mais avec des garanties que les risques sont traités et sous contrôle. On a de plus en plus besoin de professionnels de la sécurité qui participent activement aux phases de conception et de développement afin d’intégrer la sécurité de manière continue aux différents projets. Le travail des architectes sécurité est facilité si un cadre méthodologie est défini et adapté aux besoins et au contexte business de l’entité. Cet article examine comment utiliser le référentiel SABSA pour mettre en place ce cadre et faciliter le travail des architectes sécurité au sein des programmes de transformation (migrations vers des plateformes Cloud publics et privés, agilité dans les cycles de développement logiciel, initiatives « big data », test des technologies blockchain, utilisation des containers, développement d’API pour automatiser l’orchestration…).