Un document d'exigences de sécurité est le registre des énoncés de sécurité vérifiables qu'un système doit respecter : méthode d'authentification et niveau visé de l'Application Security Verification Standard (ASVS) de l'Open Worldwide Application Security Project (OWASP), chiffrement, validation des entrées, gestion des sessions, règles de partage entre origines (CORS) et de sécurité du contenu (CSP), gestion des secrets, défense en profondeur et réponse aux incidents. Il vous permet de décider quels contrôles sont obligatoires et de prouver que chacun a été vérifié avant la mise en production.
Les exigences de sécurité écrites à la main arrivent sous forme de slogans. « Le système doit être sécuritaire » n'a ni déclencheur, ni test, ni responsable; l'énoncé traverse toutes les revues intact et on le redécouvre en incident. Même les équipes rigoureuses reformulent le paysage des menaces en prose, puis perdent le lien entre un contrôle et la menace qu'il adresse dès qu'un des deux documents change.
Quelles sections un document d'exigences de sécurité contient-il?
Le gabarit gouverné par défaut de Specira produit neuf sections, de la méthode d'authentification au plan de réponse aux incidents en passant par le diagramme d'architecture de sécurité, chacune avec ses décisions et ses preuves requises.
| Section | Profondeur | Comment elle est produite |
|---|---|---|
| Méthode d'authentification | base | Prose synthétisée depuis la découverte |
| Bases du chiffrement | base | Prose synthétisée depuis la découverte |
| Stratégie de validation des entrées | standard | Prose synthétisée depuis la découverte |
| Gestion des sessions | standard | Prose synthétisée depuis la découverte |
| Politique CORS et CSP | standard | Prose synthétisée depuis la découverte |
| Gestion des secrets | standard | Prose synthétisée depuis la découverte |
| Diagramme d'architecture de sécurité | complet | Diagramme généré |
| Couches de défense en profondeur | complet | Prose synthétisée depuis la découverte |
| Guide de réponse aux incidents | complet | Prose synthétisée depuis la découverte |
Comment Specira construit-elle le document d'exigences de sécurité?
L'analyste en sécurité est propriétaire de cet artefact; il lit les obligations réglementaires, les contraintes de sécurité et les politiques de gouvernance de votre base de connaissances avant de poser une question. Dans l'exemple, la section 1 (portée, déclencheurs et palier d'assurance) consigne quels déclencheurs étaient vrais (données personnelles, contrats d'entreprise, fonctions d'IA) et lesquels étaient faux (paiements, données de santé); la famille Payment Card Industry Data Security Standard (PCI DSS) est donc omise avec la raison écrite, pas sautée en silence. La section 2 (registre des exigences de sécurité) est le cœur : un identifiant stable, un énoncé « doit » testable, le déclencheur cité comme identifiant de menace, règlement ou clause de contrat, une méthode de vérification tirée d'une liste fermée, un rôle responsable et un statut. La section 3 (protection et classification des données) relie chaque classe de données aux lignes qui la protègent, rétention et résidence comprises.
Le déclencheur de chaque ligne doit se résoudre, et les validateurs du gabarit rejettent les formulations subjectives; les notes en ligne du le critique Red Team sur une lacune de preuve ou une exposition de conformité tombent donc avant l'exportation. Une catégorie sans ligne décidée s'affiche comme une lacune nommée, ou comme « non applicable » avec une justification écrite; l'exemple le fait justement pour l'encodage des sorties. La provenance est sur chaque ligne : qui a approuvé, quand, sur quelle preuve, avec la citation de la base de connaissances et son score de confiance. La porte d'exportation compte les décisions résolues, sort les décisions reportées dans un rapport de lacunes, et livre en DOCX, Markdown, JSON ou par envoi vers Jira, Confluence, GitHub ou Linear.
Exemple rendu
Rendu à partir du gabarit gouverné par défaut de Specira sur une entreprise fictive, filigrané, avec ses diagrammes. Document en anglais.
Comment les équipes utilisent-elles le document d'exigences de sécurité?
- ✓Cadrer le palier d'assuranceLes valeurs des déclencheurs décident quelles familles d'exigences s'activent; une équipe qui réduit la portée écrit pourquoi au lieu d'espérer que personne ne demande.
- ✓Tracer les contrôles vers les menacesChaque ligne cite l'entrée du modèle de menaces, la clause ou la base de référence qui l'a exigée; une menace qui change retrouve son contrôle.
- ✓Planifier la vérification tôtLa méthode de vérification est choisie par ligne (configuration, revue de code, test dynamique), ce qui alimente directement le plan de tests de sécurité.
- ✓Arriver prêt à l'auditResponsables, statuts et déclencheurs sur un seul registre répondent à la plupart des questions de conformité sans présentation.
À quoi ressemble le registre dans Specira?
Ces écrans suivent une ligne d'exigence depuis la question du l'analyste en sécurité jusqu'à la décision typée, au registre compilé et à son exportation.
Écrans tirés d'un espace de démonstration Specira; compteurs et scores sont des données d'exemple.
Réservez une démo et regardez l'analyste en sécurité dériver votre premier registre d'exigences de sécurité des obligations déjà dans votre base de connaissances.
Réserver une démo