Informatique légale

Vérification de l’intégrité des fichiers – Afficher les incidents de sécurité en noir et blanc ou en technicolor glorieux?

Posted by admin

Le PCI DSS et la surveillance de l’intégrité des fichiers

L’utilisation de FIM, ou surveillance de l’intégrité des fichiers, est depuis longtemps la pierre angulaire des meilleures pratiques en matière de sécurité des informations. Même ainsi, il existe encore des malentendus courants sur l’importance de la FIM et sur ce qu’elle peut offrir.

Ironiquement, la principale cause de cette confusion est la même norme de sécurité qui introduit la plupart des gens à la FIM en rendant son utilisation obligatoire – la PCI DSS.

La condition 11.5 de la norme PCI DSS utilise spécifiquement le terme “ surveillance de l’intégrité des fichiers ” en relation avec la nécessité de le faire pour alerter le personnel de la modification non autorisée de fichiers système critiques, de fichiers de configuration ou de fichiers de contenu; et configurer le logiciel pour effectuer des comparaisons de fichiers essentielles au moins une fois par semaine “

Puisque le terme «surveillance de l’intégrité des fichiers» n’est mentionné que dans l’exigence 11.5, on pourrait conclure que c’est le seul rôle que la FIM devrait jouer au sein de la norme PCI DSS.

En fait, l’application de la FIM est et devrait être largement répandue pour soutenir une position solide et sécurisée pour un domaine informatique. Par exemple, d’autres exigences importantes de la norme de sécurité des données PCI sont toutes mieux traitées en utilisant une technologie de surveillance de l’intégrité des fichiers telle que “ Définir des normes de configuration de pare-feu et de routeur ” (Req 1), “ Développer des normes de configuration pour tous les composants du système ” (Req 2), «Développer et maintenir des systèmes et des applications sécurisés» (Req 6), «Limiter l’accès aux données de titulaires de carte en fonction des besoins de l’entreprise» (Req 7), Fournir une bonne gestion de l’identification et de l’authentification des utilisateurs pour les utilisateurs non-consommateurs et les administrateurs sur tous les composants du système »(Req 8)), “Tester régulièrement les systèmes et processus de sécurité” (Req 11).

Seulement dans les limites de l’exigence 11.5, beaucoup interprètent cette exigence comme un simple «le dossier a-t-il changé depuis la semaine dernière?». et, prise isolément, ce serait une conclusion légitime à tirer. Cependant, comme indiqué précédemment, la norme PCI DSS est un réseau d’exigences liées et qui se chevauchent, et le rôle d’analyse de l’intégrité des fichiers est beaucoup plus large et prend en charge différentes exigences de renforcement de la configuration, d’application des normes de configuration et de gestion des modifications.

Mais ce n’est pas seulement un problème avec la façon dont les commerçants lisent et interprètent le PCI DSS. La nouvelle vague de fournisseurs SIEM en particulier tient à comprendre cette définition étroite comme «suffisamment sûre» et pour de bonnes raisons, quoique égoïstes.

Tout faire avec SIEM – ou FIM + SIEM est-il la bonne solution?

L’exigence PCI 10 concerne la journalisation et la nécessité de générer les événements de sécurité nécessaires, de sauvegarder les fichiers journaux et d’analyser les détails et les modèles. À cet égard, un système de journalisation devient un élément essentiel de votre ensemble d’outils PCI DSS.

Les systèmes SIEM ou de gestion des journaux d’événements reposent tous sur une sorte d’agent ou de méthode WMI interrogée pour afficher les fichiers journaux. Lorsque de nouveaux événements sont ajoutés au fichier journal, ces nouveaux événements sont détectés par le système SIEM, sauvegardés et analysés de manière centralisée pour détecter des preuves explicites d’incidents de sécurité ou simplement des niveaux d’activité inhabituels de toute nature pouvant indiquer un incident de sécurité. Cette approche a été étendue par de nombreux fournisseurs de produits SIEM pour fournir un test de base de FIM sur les fichiers système et de configuration et déterminer si les fichiers ont changé ou non.

Un fichier système modifié pourrait révéler qu’un cheval de Troie ou un autre logiciel malveillant a infiltré le système hôte, tandis qu’un fichier de configuration modifié pourrait affaiblir l’état intrinsèquement sûr «renforcé» de l’hôte, le rendant plus vulnérable aux attaques. L’exigence PCI DSS 11.5 susmentionnée utilise le mot «non autorisé», il y a donc une référence subtile à la nécessité d’effectuer un processus de gestion des changements. À moins que vous ne puissiez classer ou définir certaines modifications comme «programmées», «autorisées» ou attendues d’une manière ou d’une autre, vous ne pouvez pas étiqueter d’autres modifications comme «non autorisées» comme l’exige la norme.

Donc, dans un sens, ce niveau de FIM est un bon moyen de protéger votre infrastructure sécurisée. Dans la pratique, cependant, ce type de surveillance de l’intégrité des fichiers “ en noir et blanc ” est en pratique assez inutile et donne généralement à l’équipe de sécurité de l’information un flux de “ bruit ” – trop d’avertissements faux et déroutants, masquant généralement les véritables menaces de sécurité.

Événements de sécurité possibles? Oui.

Événements de sécurité utiles, classés et notés intelligemment? Non.

Donc, si ce niveau de FIM «modifié / non modifié» est le rendu noir et blanc, quelle est l’alternative Technicolor? En parlant maintenant de véritable FIM d’entreprise (pour se différencier du FIM standard, de style SIEM), ce niveau supérieur de FIM fournit des changements de fichiers qui ont été automatiquement évalués en contexte – est-ce un bon ou un mauvais changement?

Par exemple, si un paramètre de sécurité de stratégie de groupe a changé, comment savoir s’il augmente ou diminue la protection de la stratégie? Enterprise FIM rapporte non seulement le changement, mais fournit également les détails exacts de ce que le changement est, était-ce un changement planifié ou non planifié, et s’il est en conflit avec ou respecte votre norme de construction renforcée adoptée.

En fait, Enterprise FIM peut vous donner un instantané de la sécurité des bases de données, des serveurs, des systèmes EPoS, des postes de travail, des routeurs et des pare-feu – configurés selon votre norme de construction renforcée ou non. Un système SIEM, par contre, est complètement aveugle à la façon dont les systèmes sont configurés à moins qu’il n’y ait un changement.

Conclusion

Le vrai message est qu’essayer de s’acquitter de vos responsabilités en matière de conformité PCI nécessite une compréhension globale de toutes les exigences PCI. Les exigences prises séparément et trop littéralement peuvent vous laisser avec une solution PCI «bruyante», qui permet de masquer plutôt que d’exposer les risques de sécurité potentiels. En bref, il n’y a pas de failles de sécurité – vous avez besoin des bons outils pour le travail. Un bon système SIEM est essentiel pour répondre à l’exigence 10, mais un système FIM d’entreprise vous offre bien plus que simplement cocher la case Req 11.5.

La couleur est tellement meilleure que le noir et blanc.

Leave A Comment