Alertes : Données sensibles

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

Cette rubrique explique comment ESA traite les données sensibles telles que les noms d'utilisateur ou l'adresse IP reçue de Security Analytics Core. Le rôle du responsable de la confidentialité des données peut identifier les clés méta qui contiennent des données sensibles et doivent afficher des données obfusquées. ESA n'affichera et ne stockera pas les métadonnées sensibles. Par conséquent, ESA ne transmettra pas les données sensibles à Incident Management.

ESA peut également ajouter une version obfusquée des données sensibles à un événement. Par exemple, le DPO identifie user_dst comme étant sensible. ESA peut ajouter une version obfusquée, telle que user_dst_hash, à un événement. Les métadonnées obfusquées ne sont pas sensibles ; ESA les affichera et stockera donc de la même façon que toute autre métadonnée non sensible.

Pour plus d'informations sur la stratégie et les avantages de l'obfuscation des données, voir Guide de gestion de la confidentialité des données Security Analytics.

La rubrique qui suit aborde les points suivants :

  • La façon dont ESA traite les données sensibles qu'il reçoit de Security Analytics Core
  • La façon d'éviter les fuites de données sensibles dans une règle EPL avancée

La façon dont ESA traite les données sensibles de Security Analytics Core

Lorsqu'ESA reçoit des données sensibles de Security Analytics Core, ESA ne transmet que la version obfusquée des données. ESA ne stocke et n'affiche pas les données sensibles.

Les fonctionnalités suivantes sont impactées :

  • Sorties – ESA ne transfère pas de données confidentielles aux sorties, comprenant les alertes, les notifications et le stockage MongoDB.
  • Règles EPL avancées – Si une instruction EPL crée un alias pour une clé méta confidentielle, une fuite de données confidentielles est possible. Cette rubrique illustre la façon dont ce problème se produit afin que vous puissiez l'éviter.
  • Enrichissements – Si une clé méta confidentielle est utilisée dans la condition join, une fuite de données confidentielles est possible. Cette rubrique illustre la façon dont ce problème se produit afin que vous puissiez l'éviter.

Règle EPL avancée

Si une instruction de requête EPL renomme une clé méta sensible, les données ne seront pas protégées.

ESA identifie une clé méta sensible par le nom :

ip_src est la clé méta confidentielle.
ip_src_hash est la version non confidentielle, obfusquée.

Pour soutenir la confidentialité des données, la clé méta sensible ne doit pas être renommée dans une requête EPL. Si une métaclé sensible est renommée, les données ne seront plus protégées.

Par exemple, dans une règle telle que select ip_src as ip_alias..., ip_alias contient les données sensibles mais n'est pas protégé car ESA ne connaît qu'ip_src, et non ip_alias. Dans ce cas, les adresses IP ne seraient pas obfusquées. Les valeurs réelles seraient affichées.

Source d'enrichissement

Lorsqu'une métaclé sensible est utilisée dans une condition join, les données sensibles peuvent être affichées.

La base de données d'enrichissement, qui est l'autre partie de la condition join, possède une colonne qui correspond à la métaclé sensible. Cette référence croisée se rapporte aux valeurs réelles, et non à celles illisibles. Par conséquent, les valeurs réelles s'affichent.

Dans l'exemple suivant, les deux parties de la condition join sont mises en évidence.

DataObEnr.png

  • ip_src contient des données sensibles.
  • ipv4 sera ajouté à l'alerte et exposé en tant que données non sensibles

La valeur ipv4 étant identique à la valeur ip_src, ipv4 contient et affiche des données sensibles. 

You are here
Table of Contents > Mode de génération d'alertes par ESA > Données sensibles

Attachments

    Outcomes