Pour les MSSP et les équipes SOC
Zedmos n'est pas un SIEM et ne vous demande pas de remplacer celui que vous exploitez. C'est le point d'application en bordure du client, la source qui alimente votre plateforme d'un enregistrement digne d'être corrélé, et — contrairement à la plupart des capteurs — l'endroit où la réponse peut aussi avoir lieu. Une console couvre chaque client, et un analyste ne voit jamais que celui qui lui est confié.
Tout ce qui est sur cette page tient dans un seul écran du pare-feu. Aucun connecteur à développer, aucun collecteur à héberger entre les deux.
Splunk et ArcSight prennent du CEF sur TCP, QRadar prend du LEEF, et le syslog sécurisé prend du JSON sur TLS. Choisir le profil règle d'un coup le transport, l'encadrement et le port.
Ne transmettre que les actions d'application, et fixer un plafond d'événements par seconde. C'est là qu'un MSSP décide de ce que la licence d'un client fera facturer — avant que les événements ne quittent la machine.
Renseignement sur les menaces, IDS/IPS, DNS, analyses de fichiers, TLS, identité et trafic applicatif sont des interrupteurs distincts, chacun nommant les champs qu'il transporte. Le trafic normal autorisé est désactivé par défaut.
Les envois réussis, les erreurs, les reconnexions et les abandons dus au plafond sont comptés séparément : un plafond que vous avez fixé ne se lit jamais comme une panne que vous n'avez pas provoquée. Une capture de cinq secondes montre les prochains événements sur le fil.
Le stockage, la corrélation entre sources, la chasse et la gestion des cas sont le travail de votre plateforme, et vous l'avez déjà payée. Le nôtre est d'être la source la mieux élevée qui s'y branche : CEF pour Splunk et ArcSight, LEEF 2.0 pour QRadar, JSON structuré, RFC 5424 ou 3164, sur UDP, TCP ou TLS au port 6514 — ou directement vers un point de terminaison Elasticsearch en masse quand un saut syslog n'est pas souhaité.
L'événement porte la décision et la règle qui la fonde — politique et groupe correspondants, identifiant de règle, application et catégorie, SNI, question DNS posée, URI, interface, nombre d'octets — ainsi que l'utilisateur et l'appareil auxquels appartenait le flux, résolus sur la machine à partir de l'annuaire et de l'identité VPN. La première question après une alerte, c'est qui, et elle est déjà répondue dans l'enregistrement.
Le filtrage a lieu avant que l'événement ne quitte le pare-feu : par type d'événement, catégorie de flux, gravité minimale, taille minimale, sous-réseau source, interface, ou flux bloqués seulement — avec, au-dessus de tout cela, un plafond à seau de jetons sur les événements par seconde. Le volume ingéré devient un bouton que vous réglez par client, au lieu d'être le prix à payer pour activer l'inspection.
Quand la cible cesse de répondre, la destination écrit par anticipation sur disque et rejoue l'arriéré à son retour, dans une limite de taille que vous fixez. Un événement abandonné par le plafond que vous avez choisi est compté séparément d'un événement qui n'a pas pu être envoyé : un plafond délibéré ne se lit donc jamais comme une panne.
La cible d'export est par pare-feu. Un client qui exploite son propre SIEM le garde ; un client que vous surveillez de façon centralisée envoie vers le vôtre ; un parc co-administré envoie vers les deux. Rien n'est canalisé au passage par un locataire éditeur, parce qu'il n'y a pas de locataire éditeur sur le chemin.
L'accès est un rôle — propriétaire, administrateur ou observateur — accordé au locataire, à l'agence ou à la seule passerelle. Un analyste de premier niveau peut être limité à un client, ou à un site à l'intérieur de celui-ci, et la console ne montre rien à côté. La frontière est dans le modèle de données, pas dans un filtre que quelqu'un doit penser à appliquer.
Un administrateur émet un jeton d'installation à usage unique, lié au client et à une date d'expiration. Le pare-feu le présente à son premier enregistrement, le jeton est consommé, et la machine est liée à ce client à partir de là. Le jeton est stocké sous forme de condensat et affiché une seule fois : une page de console divulguée ne donne donc à personne un enrôlement.
La plupart des capteurs ne peuvent que vous prévenir. Au-delà d'autoriser et d'abandonner, celui-ci peut mettre l'appareil en quarantaine, ralentir la source, escalader, réécrire, ou faire un POST vers votre webhook SOAR — le tout envoyé depuis un fil de travail, pour que le chemin en ligne n'attende jamais votre automatisation et qu'un webhook lent ne devienne pas un problème réseau.
Si la console est injoignable, ou si une licence expire, chaque pare-feu continue d'appliquer la politique qu'il détient déjà et continue d'écrire ses enregistrements. Rien dans le chemin de détection ne dépend du bon fonctionnement d'un locataire cloud, et rien ne s'arrête parce que la facturation, elle, s'est arrêtée.
Démonstration et tarifs: info@zedmos.com
Demander une démonstration