Un cadre pour intégrer la sécurité applicative dans l'ingénierie logicielle (FIASSE)

Remarque : Ce dépôt est un travail en cours. Les contributions sont les bienvenues !

Aperçu

TL;DR : veuillez lire la DOC. Explorez le site web FIASSE. Visitez les GitHub Discussions pour contribuer.

Ce dépôt contient des ressources et des documents pour le cadre OWASP pour l'intégration de la sécurité applicative dans l'ingénierie logicielle (FIASSE). FIASSE (prononcé /feiz/ comme « phase ») est un cadre indépendant des fournisseurs qui promeut une approche fondée sur des principes et centrée sur les développeurs pour construire des logiciels sécurisables. Il reconnaît que la sécurité est un processus dynamique et continu, comme le développement. Il introduit le Modèle d'ingénierie logicielle sécurisable (SSEM) comme langage de conception commun qui utilise des termes d'ingénierie logicielle établis pour intégrer la sécurité dans l'architecture, la conception et l'ingénierie logicielles en ancrant la sécurité dans les principes qui façonnent le code lui-même. Le cadre permet aux équipes de développement d'ajouter de la valeur informatique de manière résiliente tout en réduisant la probabilité d'un impact matériel dû à des événements cyber au cours de la durée de vie du code.

FIASSE est un cadre de création. Il traite de la manière dont la sécurité est mise en œuvre dans les logiciels, en reliant directement les décisions d'ingénierie à des résultats sécurisables. Ce n'est pas un cadre d'assurance, un modèle de maturité, ni un remplacement pour les catalogues de contrôles ou les métriques de vulnérabilités. Il complète ces approches et allège la pression en aval sur l'assurance et la conformité.

Objectif

Fournir des lignes directrices pratiques qui autonomisent les développeurs pour créer des logiciels sécurisables sans nécessiter une expertise approfondie en sécurité, et guider les professionnels de la sécurité dans l'intégration efficace de leur expérience en sécurité dans l'ingénierie logicielle. FIASSE y parvient à travers un prisme d'ingénierie logicielle, réduisant la charge cognitive et favorisant la collaboration entre les équipes de développement et de sécurité.

En quoi est-ce différent ?

Alors que les projets axés sur l'assurance comme l'OWASP Top 10 mettent en évidence ce qu'il faut éviter (une liste de blocage), OWASP FIASSE fournit un ensemble d'attributs et de pratiques positifs à suivre (une liste d'autorisation). Cette approche s'appuie sur les compétences existantes en ingénierie logicielle pour construire des logiciels sécurisables, plutôt que d'exiger des développeurs qu'ils apprennent des techniques d'exploitation ou adoptent un état d'esprit axé sur les vulnérabilités. L'accent est mis sur la possibilité d'un codage sécurisé et pratique grâce à des principes d'ingénierie familiers.

En définissant clairement le rôle pratique de la sécurité dans le processus de développement, ce cadre garantit que la valeur métier est capturée efficacement. Fixer des attentes de sécurité explicites avant l'écriture du code réduit la probabilité que des failles de sécurité soient découvertes et nécessitent une remédiation ultérieure. Une adoption efficace devrait améliorer les métriques d'assurance existantes, réduire le va-et-vient des constats, produire des correctifs plus durables et raccourcir le temps de remédiation.

Valeurs fondamentales

FIASSE est orienté par quatre valeurs fondamentales. Chacune exprime une préférence relative : les deux côtés ont de la valeur, mais lorsqu'il faut faire des choix, FIASSE privilégie celui de gauche.

• Les attributs sécurisables plutôt que les contrôles de sécurité : privilégier les qualités d'ingénierie qui permettent de construire et de maintenir un système défendable plutôt que les contrôles de sécurité ajoutés après coup pour compenser des faiblesses.
• La participation plutôt que l'évaluation : privilégier un engagement structuré entre la sécurité et le développement tout au long du cycle de vie plutôt qu'une évaluation réalisée une fois le travail terminé.
• Les principes premiers de l'ingénierie plutôt que le jargon de sécurité : privilégier l'ancrage dans les principes premiers établis de l'ingénierie logicielle plutôt que le jargon spécifique à la sécurité ou les heuristiques adverses.
• La valeur métier plutôt que l'activité de sécurité : privilégier une sécurité qui soutient la création de valeur de l'organisation plutôt qu'une sécurité poursuivie comme une fin en soi.

Principes clés