Historique de la question :
Les exigences en matière de sécurité de l'information sont un élément essentiel des grands projets IT depuis l'époque où les premiers standards d'audit de sécurité ont commencé à apparaître (par exemple, ISO 27001 ou les exigences de la loi fédérale 152 en Russie). Sans une analyse claire et une formalisation des exigences, la sécurité du système risque d'être déclarative et non applicable en pratique.
Problème :
Les exigences de sécurité sont souvent formulées de manière abstraite (« tout doit être protégé »), ne tenant pas compte des processus métier réels et de l'architecture, et ne sont pas décryptées par niveaux : organisationnels, technologiques, utilisateurs. De plus, les clients et les développeurs peuvent interpréter différemment les mêmes exigences - il en résulte un décalage entre réalisabilité et conformité.
Solution :
L'analyste système commence par une étude des normes corporatives, gouvernementales et sectorielles (par exemple : normes GOST, GDPR, PCI DSS, ISO 27001). Ensuite, il collabore avec l'architecte et les spécialistes de la sécurité pour identifier les processus critiques pour l'entreprise, les points de stockage et de transmission des données, les menaces potentielles, et détermine la liste des risques associés. Sur cette base, l'analyste prépare une matrice détaillée des exigences concernant l'accès, le stockage, la journalisation, le chiffrement, ainsi que des scénarios d'incidents. Après approbation, il les formalise dans des documents - de manière à ce que chaque exigence puisse être vérifiée par des tests ou lors d'un audit.
Points clés :
Pourquoi ne faut-il pas se fier uniquement aux moyens techniques d'assurance de la sécurité de l'information (antivirus, pare-feu, SIEM) ?
Parce que la sécurité de l'information est un processus, et pas simplement un ensemble de systèmes. Les procédures organisationnelles, le facteur humain, les vérifications régulières, la formation des utilisateurs jouent un rôle crucial.
Peut-on considérer que les exigences sont satisfaites si le système a seulement passé des tests internes ?
Non - souvent pour être conformes aux normes, un audit externe, une certification, et parfois même des tests de stress sous la supervision d'un régulateur sont nécessaires.
Est-il suffisant de transmettre dans le cahier des charges l'exigence "le système doit être protégé conformément à la loi 152-FZ" ?
Ce n'est pas suffisant - il est nécessaire de spécifier des mesures concrètes (contrôle d'accès, stockage des journaux d'événements, chiffrement des données), les lieux de leur mise en œuvre, les critères de vérification.
Cas négatif : Dans un projet de banque en ligne, l'analyste a transmis dans le cahier des charges uniquement la phrase générale "les exigences de la loi 152-FZ doivent être respectées". Les sous-traitants ont mis en œuvre une autorisation standard et un certificat SSL, et lors de l'audit externe, il s'est avéré qu'il n'y avait pas de contrôle du stockage des données et que le journal d'authentification n'était pas protégé.
Avantages :
Inconvénients :
Cas positif :
Au début du projet, l'analyste système a convenu avec les spécialistes de la sécurité et le client d'une liste de menaces, a développé des exigences détaillées en matière de chiffrement et d'audit pour chaque scénario, et a défini les responsables. En sortie, le système a passé l'audit sans réserves.
Avantages :
Inconvénients :