Phase 2 : Pendant la définition et la conception

Phase 2.1 Examiner les exigences de sécurité

Les exigences de sécurité définissent le fonctionnement d'une application du point de vue de la sécurité. Il est essentiel que les exigences de sécurité soient testées. Dans ce cas, les tests consistent à tester les hypothèses qui sont faites dans les exigences et à vérifier s'il y a des lacunes dans les définitions des exigences.

Par exemple, s'il existe une exigence de sécurité qui stipule que les utilisateurs doivent être enregistrés avant de pouvoir accéder à la section des livres blancs d'un site web, cela signifie-t-il que l'utilisateur doit être enregistré auprès du système ou que l'utilisateur doit être authentifié ? Assurez-vous que les exigences sont aussi claires que possible.

Lorsque vous recherchez des lacunes dans les exigences, envisagez d'examiner les mécanismes de sécurité tels que :

• Gestion des utilisateurs
• Authentification
• Autorisation
• Confidentialité des données
• Intégrité
• Responsabilité
• Gestion des sessions
• Sécurité du transport
• Ségrégation des systèmes à plusieurs niveaux
• Conformité législative et normative (y compris la confidentialité, les normes gouvernementales et industrielles)

Phase 2.2 Examiner la conception et l'architecture

Les applications doivent avoir une conception et une architecture documentées. Cette documentation peut inclure des modèles, des documents textuels et d'autres artefacts similaires. Il est essentiel de tester ces artefacts pour s'assurer que la conception et l'architecture appliquent le niveau de sécurité approprié tel que défini dans les exigences.

L'identification des failles de sécurité dans la phase de conception est non seulement l'un des endroits les plus rentables pour identifier les failles, mais peut être l'un des endroits les plus efficaces pour apporter des modifications. Par exemple, s'il est identifié que la conception appelle à des décisions d'autorisation à prendre à plusieurs endroits, il peut être approprié d'envisager un composant d'autorisation central. Si l'application effectue la validation des données à plusieurs endroits, il peut être approprié de développer un cadre de validation central (c'est-à-dire que la correction de la validation des entrées à un endroit, plutôt qu'à des centaines d'endroits, est beaucoup moins coûteuse).

Si des faiblesses sont découvertes, elles doivent être transmises à l'architecte système pour des approches alternatives.

Phase 2.3 Créer et examiner les modèles UML

Une fois la conception et l'architecture terminées, créez des modèles UML (Unified Modeling Language) qui décrivent le fonctionnement de l'application. Dans certains cas, ceux-ci peuvent déjà être disponibles. Utilisez ces modèles pour confirmer avec les concepteurs des systèmes une compréhension exacte du fonctionnement de l'application. Si des faiblesses sont découvertes, elles doivent être transmises à l'architecte système pour des approches alternatives.

Phase 2.4 Créer et examiner les modèles de menaces

Muni des revues de conception et d'architecture et des modèles UML expliquant exactement comment le système fonctionne, entreprenez un exercice de modélisation des menaces. Développez des scénarios de menace réalistes. Analysez la conception et l'architecture pour vous assurer que ces menaces ont été atténuées, acceptées par l'entreprise ou attribuées à un tiers, tel qu'une compagnie d'assurance. Lorsque les menaces identifiées n'ont pas de stratégies d'atténuation, revisitez la conception et l'architecture avec l'architecte système pour modifier la conception.