Comprendre les politiques de sécurité pour le développement

Développement de logiciels sécurisés

Comprendre les politiques de sécurité et leur application aux pratiques de développement est la clé de la livraison de logiciels sécurisés. Malheureusement, la plupart des équipes de développement n'ont pas une compréhension claire de la mise en œuvre de la sécurité. Cela peut être dû à plusieurs facteurs, mais un thème commun est que les professionnels de la sécurité parlent un «langage» différent des développeurs (c.-à-d. Exigences vs contrôles, code vs vulnérabilité, fonctionnalité vs facteurs de risque). Cette absence de moyen commun de communiquer la conformité à la sécurité empêche l'identification et la suppression des vulnérabilités du système. Il existe de nombreux exemples de violations de système et de données qui se sont produites en raison de normes de sécurité mal comprises ou laxistes.

Cela ne veut pas dire qu'il n'y a pas de ressources très utiles déjà disponibles. Le groupe Open Web Application Security Project (OWASP) publie régulièrement des conseils sur la façon d'identifier et de prévenir les vulnérabilités courantes au niveau du code. Le cadre de sécurité commun HITRUST (CSF) fournit un cadre de sécurité unifié pour pratiquement toutes les normes de conformité et réglementaires actuelles, telles que NIST, ISO et HIPAA (voir figure 1). Le Center for Internet Security (CIS) fournit des ressources open source pour le renforcement de tous les principaux systèmes d'exploitation, ainsi que des outils pour aider à établir et à maintenir des environnements de déploiement sécurisés.

Figure 1. Catégories de contrôle HITRUST CSF v. 9.3.1

Ainsi, même si les informations disponibles pour l'identification et la correction des risques de sécurité ne manquent pas, il est difficile de déterminer exactement ce qui répondra à l'objectif d'une organisation spécifique en matière de conformité aux politiques de sécurité. Même un standard bien organisé, tel que le CSF HITRUST, fait bien plus de 500 pages! Attendre que toutes vos équipes de développement lisent et comprennent chaque aspect n'est tout simplement pas raisonnable. Au lieu de cela, l'équipe de développement a besoin de conseils pour trouver les ressources exactes nécessaires pour respecter la politique via des contrôles appropriés.

Stratégies de sécurité du développement

Pour ce faire, je propose que les architectes de solution de l'organisation et les experts en sécurité unissent leurs forces pour créer un ensemble de ' politiques de sécurité du développement ». Comme le montrent les figures 2 et 3, ces retraitements des politiques de sécurité standard permettent aux équipes de développement d'identifier rapidement les lignes directrices, les normes et les pratiques qui répondront à l'objectif de conformité. Dans ces exemples (extraits du CSF HITRUST, version 9.3), les politiques sont organisées en fonction de la catégorie de contrôle et de l'objectif. La déclaration de politique va plus loin pour définir des «indicateurs» spécifiques pour le moment où la politique est applicable, des «contrôles» pour garantir la conformité et des «implications» pour noter les effets secondaires probables de la conformité. L'énoncé de politique dirige ensuite l'équipe de développement vers les normes, directives, pratiques et références utiles applicables.

Figure 2. Exemple de politique de sécurité de développement pour la gestion des identités

Cette approche réduit considérablement la confusion des équipes de développement. Il reformule la politique de sécurité en termes spécifiques qu'une équipe de développement peut à la fois comprendre, implémenter et tester. Enfin, il comble le fossé entre les groupes de développement et les professionnels de la sécurité en traduisant les déclarations globales en exigences exploitables. Plutôt que de faire l'objet d'audits de sécurité externes, chaque équipe de développement est habilitée à évaluer ses propres systèmes. L'équipe de sécurité obtient des informations précieuses sur le fonctionnement des équipes de développement, en particulier dans les pratiques agiles où le «décalage à gauche» s'applique également aux besoins de sécurité. Enfin, par la création et la conservation d'un ensemble ciblé de politiques définies, il y a une adoption accrue des meilleures pratiques conduisant à des versions de logiciel plus sûres et plus fiables.

Figure 3. Exemple de politique de sécurité de développement pour l'intégrité des données

Conclusion

Les équipes de sécurité comprennent les normes et les politiques de conformité. Les équipes de développement comprennent les exigences et créent des solutions aux problèmes. La mise à jour des politiques de conformité, comme indiqué dans cet article, bénéficiera aux deux équipes en créant une définition de conformité de sécurité commune. La collaboration de ces équipes est cruciale pour la livraison de logiciels sécurisés, stables et productifs.