1 - Principe de fonctionnement

La solution Nucleon Security inclus un module de surveillance des flux réseaux. Exécuté au niveau système celui-ci relie les demandes d'accès réseaux (socket) aux applications qui en font la requête. Ainsi il est possible de tracer les activités de chaque applications à la recherche d'accès délictueux, signaux faibles ou autre suspicions. Ces activités prennent en compte les différents critères usuels d'un flux à savoir (Nom de domaine, adresse IP, numéro de port et types de protocoles courants TCP/UDP/ICMP.

Vous obtenez alors un contrôle de type pare-feu réseau de manière précise par exécutable. Le filtrage est alors plus fin que par un équipement réseau (dont il ne retire par l'importance bien sûr), mais aussi très simplement appliqué à l'ensemble de votre parc par l'activation ou la désactivation des règles idoines.

De même les règles systèmes usuelles de Nucleon peuvent identifier une destination de type Share, ce qui permet de ne pas seulement identifier les flux réseaux, mais dans ce cas précis un chemin d'accès fichier (UNC) complet même appliqué à un serveur de fichier ou un partage de fichier (DFS, CIFS, SMB...).

2 - Investigation & Recherche de menace

Vous pouvez explorer et analyser les informations directement depuis le menu hunt que ce soit pour qualifier, identifier ou clarifier une situation.

La vue Hunt vous propose par défaut un filtre sur les signaux faibles.

Complétez la avec un filtre sur le type d'évènement Network ...

Vous pouvez aussi identifier les évènements liés à un partage réseau sur les autres types d'évènements Execute, Process Access, Read, Write, Delete & rename. 

Pour cela 

• Utilisez le filtre Target File Path
• Le compléter avec les identifiants de chemin de ressource réseau \\

            ⚠️ \\ en Expression régulière s'écrit \\\\ avec les échappements

3 - Administration/Exploitation

Pour configurer la protection réseau, rien de bien compliqué, mais plusieurs façon de procéder :

• Via l'assistant depuis un évènement de la vue Hunt
• Via l'assistant depuis un évènement corrélé dans une manace Threat
• Directement dans les règle d'un conteneur Application

Les règles peuvent décrire plusieurs cas de figure parmis les suivants:

• Autoriser un flux légitime d'une application vers une ressource réseau
• Tolérer des flux suspects sporadiques (Signal Faible)
• Interdire un flux illégitime d'une application vers une ressource réseau
• Interdire un flux illégitime pour toutes les applications (IOC, bannissement d'usage...)

Créer un objet réseau

• Dans la barre de menu de gauche, choisir Application
  
• Dans l'espace Objects à droite, séléctionnez New Object
• Par défaut la création d'objet est de type système, sélectionnez Network
• Vous pouvez remplir tous les critères qui vous semblent nécessaire pour décrire la ressource visée
  

⚠️RAPPEL : Il n'y a aucune obligation de remplir l'ensemble des champs. Un objet qui ne contient que peu de détails est dit générique, un objet très détaillé sera dit spécifique. Tout dépendra de l'usage à en faire.

⚠️ RAPPEL : Remplir plusieurs "badges" dans un même champ agit comme un OU logique (exemple : www.google.fr www.google.com dans le champ domaine fera un objet qui correspondra à l'un comme à l'autre).

⚠️ RAPPEL : Remplir plusieurs champs agit comme un ET logique (exemple : www.google.fr et 8.8.8.8 dans les champs domaine ainsi que le champ IP ne fera correspondance que lors d'un flux www.google.fr vers le serveur d'IP 8.8.8.8).

• Vous pouvez cliquer sur Create
• Votre objet est créé et utilisable dans les jeux de règles

Pour une règle d'interdiction à la portée globale

• Dans la barre de menu de gauche, choisir Application
  
• Prenons le conteneur d'Application Illegal Domains
• Dans cette règle, le contexte est déjà paramétré à tout exécutable (Any) tentant un accès réseau (Network)
  
• Il suffit de rajouter un Objet réseau ici dans Target

Pour une règle spécifique à une application

• Dans la barre de menu de gauche, choisir Application
  
• Sélectionnez votre application
• Créez une nouvelle règle
• Ajouter en source votre/vos applications de contexte, et définissez le type d'action sur Network, puis ajouter votre ressource de destination (ici exemple d'un cas keepass).

⚠️ Network Hardening

Par défaut la règle de network Hardening surveille et traque ce qui n'a pas été explicitement autorisé. Mais vous pouvez vous aussi décrire votre propre règle de signal faible au sein d'une application pour plusieurs cas de figure:

• Garantir l'interdiction après tolérance sans risque qu'une règle mal définie dans d'autre conteneur ne contrevienne (avant la règle de network hardening)
• Faciliter la visibilité et le rappel à cette application en cas d'usage de l'assistant
• Pour préparer une règle à raffiner ultérieurement

4- Limites & Cas connus (known issues)

Les techniques permettant à l'agent d'associer les noms de domaines aux adresses IP font appel à des mécanismes internes de Windows proche de la notion de cache DNS sans en être. Dans certains cas de figures sporadiques l'agent ne peut parvenir à accéder au nom DNS. Les objets basé sur un nom FQDN peuvent alors ne pas entrer en correspondance et le flux être alors vu comme un signal faible.

Qu'est-ce que cela induit ?

Si plusieurs flux sont considéré signal faible pour la même exécution, alors le premier seul est autorisé. Le second est alors bloqué. L'application va alors retenter et refaire une demande au système par l'usage du nom de domaine FQDN. La nouvelle itération sera alors autorisée conformément au jeux de règles. 

L'impact ressentis côté utilisateur est alors nul.

Mais un impact d'exploitation peut être possible avec un déclenchement de menaces inappropriés et donc de notifications.

Comment faire ?

Plusieurs possibilités qui ne peuvent pas être appliquées génériquement à tout contexte client. 

Si le contexte est vérifié et que les flux doivent être autorisés, alors nous pouvons régler le faux positif de deux manières :

• par une règle explicite d'autorisation sur la base d'objets IP spécifiques
• par une règle explicite d'autorisation sur la base d'objet IP génériques

Si le contexte est vérifié et que les flux doivent être interdit, alors nous pouvons envisager cela deux manières :

• Cela arrivera, inutile de prévenir : Création d'une règle en Ignore
• Cela peut être toléré, mais je veux être prévenu : Création d'une règle en Signal Faible (Weak Signal)
• Cela ne devrait pas arriver et vous voulez resté avertis : Création d'une règle de blocage (Block)

Contacter le support pour toute autre question.

La version 5 de l'agent intégrera une meilleure gestion de la résolution. Seul le DNS over HTTPs directement dans le navigateur sera une possibilité de soucis de résolution.