Fonctionnalités

Cette page décrit les fonctions livrées. Certaines lisent un moteur que vous exploitez : elles l’indiquent, et la page concernée dit « non configuré » tant qu’il ne l’est pas. Ce qu’un client voit dépend aussi de son offre de service.

Incidents et alertes

• Une seule file pour les alertes de toutes vos sources connectées et de l’API.
• Ma file : un bouton affiche vos dossiers encore à traiter.
• Échéance sur chaque élément ouvert : le temps restant avant le délai de résolution du client.
• Vues enregistrées : les filtres de la liste se gardent sous un nom. Ils figurent aussi dans l’adresse de la page, qui peut donc se partager.
• Regrouper plusieurs alertes dans un cas.
• Rouvrir une alerte écartée à tort comme faux positif.
• Motif obligatoire pour résoudre ou clôturer un incident.
• Notes internes à votre équipe, ou visibles du client.
• Couverture MITRE ATT&CK du périmètre : techniques couvertes par les règles de détection, activité réelle sur 90 jours, angles morts, et une fiche par technique.

SOAR

L’automatisation est native, sans outil externe.

• Règles : elles surveillent les nouvelles alertes (sévérité, niveau de la règle d’origine, source, identifiant de règle, technique ATT&CK, étiquettes, titre, clients) et enchaînent des actions : ouvrir un cas, prévenir l’équipe, lancer un playbook.
• Tester avant d’activer : une règle est créée désactivée et se teste sur les 7 derniers jours, avec le nombre d’alertes qu’elle aurait prises, par client et par jour.
• Éditeur visuel : chaque règle se dessine en flux (déclencheur, conditions, périmètre, contrôle, actions) et se modifie sur le schéma.
• Playbooks : un catalogue intégré, et des playbooks personnalisés construits sur le même schéma. Une étape qui lance un travail long (analyse, collecte) attend son résultat avant la suivante.
• Exécutions : la liste de toutes les exécutions, suivies en direct. Relancer, reprendre à l’étape en échec ou arrêter une exécution en attente. Une exécution garde la version du playbook avec laquelle elle a démarré.

Les garde-fous sont dans le serveur :

• aucune action d’isolement, d’arrêt de processus ou de blocage ;
• une collecte sur un poste attend l’approbation d’un administrateur et s’exécute sous son nom ;
• les collectes ne font que lire ; le confinement reste toujours une tâche humaine ;
• une règle agit au plus une fois par alerte, dans une limite horaire ;
• tout est écrit dans le journal d’audit.

Certaines étapes s’appuient sur un moteur : Cortex pour l’analyse, une plateforme de renseignement pour le partage d’indicateurs, un outil de collecte forensique pour la collecte sur un poste. Ces deux derniers fonctionnent avec un moteur compatible (liste sur demande).

Rapports

• Rapport d’incident en PDF.
• Rapport par machine en PDF : identité, système, exposition, comptes, services, vulnérabilités et recommandations.
• Rapport mensuel en PDF (Tableau de bord, Export) : synthèse écrite comparée au mois précédent, traitement des alertes, incidents notables, engagements, actions de l’équipe, recommandations.
• En français ou en anglais, protégés par mot de passe. Apparence au choix : claire, sombre ou impression.
• Une section dont la source ne peut pas être lue le dit, au lieu de rester vide.

Renseignement

• Liste de surveillance d’indicateurs : une adresse, un domaine, une empreinte ou une URL, collé tel quel depuis un bulletin. Il est recherché aussitôt dans les 90 jours d’alertes du client, puis chaque heure. Une nouvelle apparition prévient le client et l’équipe.
• Analyse d’observables avec les analyseurs de Cortex.
• Renseignement sur les menaces issu d’une plateforme de renseignement compatible.
• Actualités cyber issues des CERT officiels, et ce qui concerne votre parc parmi les vulnérabilités critiques récentes.

Surveillance du parc

Ces pages s’appuient sur les données d’un stockage d’évènements et d’un gestionnaire d’agents compatibles (liste sur demande, voir Moteurs existants) :

• Évènements : recherche dans les alertes, limitée par le serveur au périmètre de l’utilisateur ;
• Carte des menaces ;
• Actifs : chaque machine surveillée, son système, ses ports à l’écoute, ses comptes et ses vulnérabilités ;
• Vulnérabilités, les failles activement exploitées (catalogue CISA KEV) en premier ;
• Posture : l’état réel des contrôles de durcissement, machine par machine ;
• Santé de la collecte : agents connectés ou non, dernier évènement reçu, état des sources connectées. Quand le SIEM ne répond pas, l’état est dit inconnu, jamais « tout va bien ».

Tickets et messagerie

• Tickets avec échéance convenue et abonnés, et un tableau pour les faire avancer.
• Messagerie entre votre équipe et chaque client, avec recherche et fichiers.

Notifications

• Dans AarView : une cloche. Plusieurs alertes critiques arrivées ensemble donnent une seule entrée.
• Par e-mail, si la messagerie est configurée : chaque utilisateur choisit (incidents critiques, tous les incidents, tickets qui lui sont assignés, résumé quotidien) et peut s’envoyer un e-mail de test.

Assistant IA

Facultatif : il demande un service d’IA raccordé (voir Moteurs existants). Ses propositions sont des suggestions : un analyste décide. Une proposition de règle SOAR passe par la même validation qu’une règle écrite à la main et n’est jamais enregistrée sans l’analyste.

Journal d’audit

Les actions sont écrites dans un journal d’audit. L’administrateur d’une organisation lit celui de son organisation ; le super administrateur, le journal global. L’export demande une connexion récente.

Langues

L’interface, les rapports et les e-mails existent en français et en anglais.