Confidentialité des données : Configurations recommandées

Document created by RSA Information Design and Development on Feb 8, 2017
Version 1Show Document
  • View in full screen mode
  

Cette rubrique décrit la mise en œuvre recommandée pour la confidentialité des données Security Analytics. En outre, elle présente plusieurs exemples d'utilisation supplémentaires pour gérer l'exposition des données sensibles/confidentielles dans Security Analytics. Les administrateurs peuvent configurer les hôtes et services Security Analytics en réponse aux exigences de confidentialité des données de leur environnement. RSA dispose de configurations recommandées pour la confidentialité des données et la rétention de données.

Configuration recommandée pour la confidentialité des données

La configuration recommandée pour obtenir la meilleure valeur analytique avec obfuscation des données consiste à définir les métadonnées sensibles/confidentielles, puis à conserver les valeurs d'origine et obfusquées (hachage) des données sensibles/confidentielles sur disque pour les composants Decoder, Log Decoder, Concentrator et Broker.

Il est supposé qu'une petite partie des métadonnées (environ 10 clés méta) est classée comme protégée, et qu'un algorithme de hachage compatible FIPS 140 est utilisé avec une valeur salt pour compliquer l'ingénierie inverse de la valeur d'origine. La solution préconisée consiste à utiliser un algorithme de hachage SHA256 avec une valeur salt dont la longueur est comprise entre 16 et 60 caractères.

Remarque : Par défaut, les valeurs de hachage sont stockées au format binaire pour réduire les temps de réponse. En outre, ce format nécessite moins d'espace de stockage dans la base de données que l'enregistrement au format chaîne. Le format texte/chaîne correspond à la méthode de stockage recommandée.

Broker et Investigation peuvent comporter des données d'origine obfusquées dans le cache, si des responsables de la confidentialité des données se servent d'Investigation pour confirmer la valeur d'origine à laquelle est mappée la valeur obfusquée pendant les procédures d'enquête. Des services en aval peuvent également limiter l'utilisation des valeurs sensibles d'origine au traitement en mémoire afin que les données ne soient pas conservées sur disque sur les systèmes en aval. Cela est vérifié pour ESA et Malware Analysis.

La solution recommandée pour supprimer les données nécessaires repose sur l'application automatique et intégrée de la rétention de données, car elle entraîne la suppression des données à un certain seuil. Vous pouvez utiliser cette méthode pour les composants suivants dans Security Analytics 10.5 : Decoder, Log Decoder, Log Collector, Archiver, Malware Analysis, Incident Management et Reporting Engine. Vous pouvez configurer manuellement Event Stream Analysis afin qu'il prenne en charge de manière similaire l'application automatique de la rétention de données.

Pour gérer le stockage du cache, le serveur Security Analytics efface le cache relatif aux procédures d'enquête des événements, toutes les 24 heures. Vous pouvez également configurer le composant Broker pour exécuter une suppression périodique du cache stocké localement.

Options relatives aux configurations de rétention de données

Security Analytics fournit des contrôles alternatifs qui permettent à l'administrateur d'appliquer des restrictions plus strictes au stockage des données sensibles/confidentielles lorsque l'obfuscation des données est activée.

Stockage des données avec options de rétention de données en vigueur

Le tableau suivant résume l'emplacement de stockage des données dans la configuration par défaut en l'absence de confidentialité des données, et pour chaque solution alternative de rétention de données. Une coche indique que les données sensibles/confidentielles sont enregistrées dans le composant. Une croix (X) indique qu'aucune donnée sensible/confidentielle n'est stockée dans le composant.

                                                                                                                                                   
ComposantConfiguration par défautOptions de stockage des données
 Stockage des données d'origineStockage des données d'origine et du hachage
(recommandé)
Stockage du hachage uniquementAucun stockage des données (toutes les métadonnées sont transitoires)
Ingestion
Décoder checkmark3.png checkmark3.png X X
Log Decoder checkmark3.png checkmark3.png X X
Agrégation des métadonnées
Concentrator checkmark3.png checkmark3.png X X
Broker checkmark3.png (Cache uniquement) checkmark3.png (Cache uniquement)X X
Analyse en temps réel  
Investigation checkmark3.png checkmark3.png (Cache uniquement)X X
Event Stream Analysis checkmark3.png X X X
Malware Analysis checkmark3.png X X X
Gestion des incidents checkmark3.png X X X
Reporting
Reporting Engine checkmark3.png checkmark3.png (facultatif)X X
Analyse à long terme
Archiver checkmark3.png (facultatif) checkmark3.png (facultatif)X X
Warehouse checkmark3.png (facultatif) checkmark3.png (facultatif)X X
Contenu
Lives.o.s.o.s.o.s.o.
Analyse des fraudes     
Web Threat Detections.o.s.o.s.o.s.o.
Protection des points de terminaison
ECATs.o.s.o.s.o.s.o.
Remarques :
La mention « Cache uniquement » signifie que les données sensibles se trouvent dans le cache du serveur Broker ou Security Analytics. Configurer la rétention de données fournit des informations détaillées sur le nettoyage automatisé et manuel du cache.

La mention « Facultatif » signifie qu'il existe effectivement un stockage des données sensibles, mais qu'il peut être limité par des configurations facultatives. Par exemple, pour limiter l'emplacement de stockage des données sensibles, n'activez pas l'accès DPO pour Reporting, et n'agrégez pas les données protégées d'origine dans Archiver.

Option 1 : aucun enregistrement des données d'origine sur disque, stockage du hachage uniquement

Les administrateurs peuvent éliminer la persistance des données sensibles sur disque, et stocker uniquement une valeur obfusquée si le risque d'exposition est trop important. Dans ce scénario, les métadonnées générées durant l'analyse dans les composants Decoder et Log Decoder sont utilisées uniquement en mémoire. Elles ne sont pas écrites sur disque. Les administrateurs peuvent configurer chaque clé méta sur un Decoder ou Log Decoder transitoire pour s'assurer que les métadonnées sensibles ne sont pas écrites sur le disque. Les services en aval ne voient pas les valeurs d'origine. Ils doivent utiliser les valeurs obfusquées pour mener les procédures d'enquête et effectuer l'analytique.

Pour configurer ce modèle de confidentialité des données, l'obfuscation des données doit être activée avec des valeurs de hachage configurées. Vous pouvez configurer chaque clé méta sur un Decoder ou Log Decoder transitoire pour vous assurer que les valeurs d'origine ne sont pas écrites sur disque.

  • Les valeurs d'origine identifiées comme sensibles sont extraites des données brutes lors de l'analyse dans le Decoder et Log Decoder et sont accessibles sur le système lors de l'analyse (parsers, règles, feeds).
  • Le Decoder n'enregistre pas les valeurs d'origine des clés méta identifiées comme sensibles. Il stocke uniquement le hachage des valeurs d'origine avec d'autres métadonnées non sensibles relatives à l'événement.

Ces options ont un effet secondaire, elles entraînent une dégradation de la capacité analytique. Toutefois, vous pouvez les configurer pour répondre aux besoins de votre environnement.

  • En configurant toutes données sensibles en mode Transitoire, ces valeurs sensibles ne sont pas conservées en permanence sur le disque, et les fonctionnalités d'analyse utilisant la valeur d'origine ne sont disponibles qu'au moment de l'analyse (parsers, règles, feeds).
  • Les systèmes Event Stream Analysis (ESA) et Malware Analysis doivent s'appuyer sur les métavaleurs obfusquées lors de leurs opérations respectives de mise en corrélation et d'attribution de score.
  • Reporting Engine se limite à l'extraction de rapports à l'aide des valeurs non sensibles et non obfusquées.
  • Le responsable de la confidentialité des données ne peut pas visualiser la valeur d'origine. Toutefois, il peut utiliser la valeur de hachage et la valeur salt configurées pour déterminer si une valeur obfusquée représente une valeur d'origine spécifique connue.

Option 2 : aucun stockage des valeurs d'origine ou des valeurs obfusquées (non recommandé)

Les administrateurs peuvent éliminer complètement la persistance de la valeur d'origine sur disque si le risque d'exposition est trop important. Comme pour l'option 1, dans ce scénario, les métadonnées générées durant l'analyse dans les composants Decoder et Log Decoder sont utilisées uniquement en mémoire. Elles ne sont pas écrites sur disque. Les administrateurs peuvent configurer chaque clé méta sur un Decoder ou Log Decoder transitoire pour s'assurer que les métadonnées sensibles ne sont pas écrites sur le disque. Les services en aval ne voient pas les valeurs d'origine, et ne disposent pas de valeurs obfusquées pour mener les procédures d'enquête et effectuer l'analytique.

Pour configurer ce modèle de confidentialité des données, configurez chaque clé méta sur un Decoder ou Log Decoder transitoire afin de vous assurer que les valeurs d'origine ne sont pas écrites sur disque.

  • Les valeurs d'origine identifiées comme sensibles sont extraites des données brutes lors de l'analyse dans le Decoder et Log Decoder et sont accessibles sur le système lors de l'analyse (parsers, règles, feeds).
  • Le Decoder n'enregistre pas les valeurs d'origine des clés méta identifiées comme sensibles. Il stocke uniquement les métadonnées non sensibles relatives à l'événement.

Ces options ont un effet secondaire, elles entraînent une dégradation très importante de la capacité analytique. Toutefois, vous pouvez les configurer pour répondre aux besoins de votre environnement.

  • En configurant toutes données sensibles en mode Transitoire, ces valeurs sensibles ne sont pas conservées en permanence sur le disque, et les fonctionnalités d'analyse utilisant la valeur d'origine ne sont disponibles qu'au moment de l'analyse (parsers, règles, feeds). Voir Configurer la rétention de données.
  • Aucun des composants en aval n'a de visibilité des valeurs d'origine, obfusquées ou non.
  • Le responsable de la confidentialité des données n'a aucune visibilité des valeurs d'origine, obfusquées ou non.

Options de remplacement des données facultatives

Option 1 : Limiter l'espace disque pour le remplacement continu des anciennes données

Si vous connaissez la période souhaitée de rétention de données pour le stockage des données, et par conséquent l'espace de stockage requis pour ces données, vous pouvez utiliser cette information pour limiter la taille du matériel sousjacent ou de la partition correspondante. En réduisant l'espace de stockage du disque dur ou la taille de la partition, vous limitez également la quantité d'espace disponible à remplir avant qu'il ne soit remplacé par de nouvelles données. Les nouvelles données reçues remplacent en permanence les données plus anciennes. Chaque solution doit être mise en place au moment du déploiement pour être efficace.

Les effets secondaires de cette option sont les suivants :

  • La suppression de certains disques limite le nombre de ressources disponibles pour la distribution des E/S, ce qui entraîne une dégradation des performances.
  • La réduction de la taille de la partition peut entraîner une dégradation des performances. Toutefois, cela atténue en partie l'impact sur les performances que représente la suppression des disques.

Option 2 : utiliser le stockage hiérarchisé pour remplacer les données de manière planifiée

S'il s'avère nécessaire de remplacer les données de manière automatique et planifiée, configurez les composants Decoder et Concentrator pour utiliser le stockage hiérarchisé. La configuration du stockage hiérarchisé fournit un mécanisme qui appelle un script après la suppression d'un fichier de base de données de l'application, mais avant sa suppression du système de fichiers. Si nécessaire, au lieu de déplacer le fichier vers le deuxième niveau, ou stockage à froid (données peu actives), qui est la fonction prévue dans l'exemple d'utilisation d'un stockage hiérarchisé, le script peut faire appel à un utilitaire de destruction tel que shred de CentOS pour remplacer le fichier. Cet outil est moins efficace lorsque la base de données est stockée sur un système de fichiers de consignation comme XFS, où réside la base de données Security Analytics Core, et sur un disque logique RAID similaire à ceux auxquels se connectent les hôtes Security Analytics Core.

La plupart des autres composants Security Analytics ne disposent pas de cette option. Leurs données sont stockées dans une base de données qui ne prend pas en charge le mécanisme de stockage hiérarchisé. Le seul autre composant qui peut utiliser cette méthode de remplacement est Reporting Engine, car il enregistre les rapports et les alertes sous forme de fichiers individuels. Toutefois, comme les graphiques Reporting Engine sont stockés dans une base de données, ils ne sont pas impactés par cette technique.

Option 3 : purger les données via l'option de rédaction de chaînes et de modèles

La purge des données fournit un mécanisme qui remplace de manière stratégique un sousensemble spécifique de données du système en cas de persistance des données sensibles, volontairement ou par accident. L'utilitaire wipe de Security Analytics permet d'écrire des modèles uniques sur les données des bases de données des métadonnées et des paquets pour les services Security Analytics Core, qui peuvent contenir des paquets ou des logs RAW de sessions actives, en fonction d'un identifiant de session. Tous les composants Security Analytics Core sont capables de remplacer un sousensemble de données trouvé via l'exécution d'une chaîne de requête, notamment les modèles regex. Les identifiants de session résultant de la requête sont fournis à l'utilitaire wipe de Security Analytics.

Remarque : Cette option n'est pas disponible si les données de la base de données SA Core ont été compressées (ce qui est habituellement le cas dans les déploiements Archiver).

Dans la plupart des composants Security Analytics, la base de données utilisée ne fournit pas de mécanisme intégré de rédaction ou de suppression sécurisée. Le composant Malware Analysis peut remplacer l'objet de données dans la base de données par la valeur private au lieu de le supprimer durant le processus de gestion de la rétention de données. Toutefois, cela ne constitue pas un mécanisme de suppression sécurisée.

Attention : L'utilisation de cette méthode sur un grand nombre de sessions a deux inconvénients : elle peut prendre beaucoup de temps et impacter les performances.

Limites du remplacement des données

Il existe des limites aux techniques de remplacement décrites dans le cadre des options 2 et 3. Pour permettre le remplacement des données des secteurs du disque, les options cidessus et l'outil en ligne de commande shred (une fonction de CentOS), présenté comme une solution alternative, doivent reposer sur des hypothèses concernant la structure du disque.  Les hôtes Security Analytics utilisent des disques SSD et des configurations RAID pour des raisons de performance et de fiabilité, mais cela entraîne une limitation des fonctionnalités liées aux techniques de remplacement. Si les techniques de remplacement modifient les disques SSD et les configurations RAID dans le but d'améliorer la sécurité, il en résulte inévitablement un prix à payer au niveau des performances, notamment en matière de taux de réception, de vitesse des requêtes et éventuellement dans d'autres domaines. Les outils en ligne de commande permettant d'effectuer des remplacements sont recommandés uniquement pour des exemples d'utilisation particuliers, où il est nécessaire de masquer des données spécifiques. Les outils ne sont pas destinés à une méthode d'utilisation continue en temps réel, en raison de son impact potentiel sur les performances.

You are here
Table of Contents > Présentation de la protection des données > Configurations recommandées

Attachments

    Outcomes