Para MSSP y equipos SOC
Zedmos no es un SIEM y no le pide que sustituya el que ya tiene. Es el punto de aplicación en el borde del cliente, la fuente que alimenta su plataforma con un registro que merece la pena correlacionar y —a diferencia de la mayoría de los sensores— también el lugar donde puede ocurrir la respuesta. Una consola cubre a todos los clientes, y un analista solo ve el que tiene asignado.
Todo lo que hay en esta página es una pantalla del cortafuegos. Ningún conector que construir, ningún colector que alojar en medio.
Splunk y ArcSight aceptan CEF sobre TCP, QRadar acepta LEEF y el syslog seguro acepta JSON sobre TLS. Elegir el perfil fija a la vez el transporte, el encuadre y el puerto.
Reenvíe solo las acciones de aplicación y fije un techo de eventos por segundo. Aquí es donde un MSSP decide por qué se factura la licencia de un cliente, antes de que los eventos salgan de la máquina.
La inteligencia de amenazas, el IDS/IPS, el DNS, los análisis de archivos, el TLS, la identidad y el tráfico de aplicaciones son interruptores distintos, y cada uno indica qué campos lleva. El tráfico permitido normal está desactivado por defecto.
Lo entregado, los errores, las reconexiones y los descartes por límite de velocidad se cuentan por separado, de modo que un techo que usted fijó nunca se lee como una caída que no hubo. Una captura de cinco segundos muestra los siguientes eventos sobre el cable.
El almacenamiento, la correlación entre fuentes, la búsqueda de amenazas y la gestión de casos son tarea de su plataforma, y ya la ha pagado. La nuestra es ser la fuente mejor educada que tenga dentro: CEF para Splunk y ArcSight, LEEF 2.0 para QRadar, JSON estructurado, RFC 5424 o 3164, sobre UDP, TCP o TLS en el 6514, o directamente a un punto final bulk de Elasticsearch donde no se quiera un salto por syslog.
El evento lleva la decisión y la regla que hay detrás —la política y el grupo que coincidieron, el identificador de la regla, la aplicación y la categoría, el SNI, la consulta DNS que se hizo, la URI, la interfaz, el recuento de bytes— y el usuario y el dispositivo a los que pertenecía el flujo, resueltos en la propia máquina a partir del directorio y de la identidad de la VPN. La primera pregunta tras una alerta es quién, y ya está respondida en el registro.
El filtrado ocurre antes de que el evento salga del cortafuegos: por tipo de evento, categoría de flujo, gravedad mínima, tamaño mínimo, subred de origen, interfaz, o solo los flujos bloqueados, con un techo de eventos por segundo por encima de todo ello. El volumen de ingesta se convierte en un mando que usted fija por cliente en lugar de en el precio de activar la inspección.
Cuando el destino deja de responder, el sumidero escribe a disco por adelantado y reproduce el atraso en cuanto vuelve, dentro de un límite de tamaño que usted fije. Un evento descartado por el techo que usted eligió se cuenta aparte de uno que no se pudo enviar, así que un tope deliberado nunca se lee como una caída.
El destino de exportación es por cortafuegos. Un cliente que tiene su propio SIEM lo conserva; un cliente al que vigila de forma centralizada envía al suyo; un parque cogestionado envía a los dos. Nada se canaliza a través de un tenant del fabricante, porque no hay ningún tenant del fabricante en el camino.
El acceso es un rol —propietario, administrador u observador— concedido en el inquilino, en la sucursal o en una sola pasarela. Un analista de primer nivel puede acotarse a un cliente, o a una sede dentro de él, y la consola no muestra nada al lado. La frontera está en el modelo de datos, no en un filtro que alguien tenga que recordar.
Un administrador emite un token de instalación de un solo uso ligado al cliente y a una caducidad. El cortafuegos lo presenta en su primer registro, el token se consume y la máquina queda ligada a ese cliente desde entonces. El token se guarda como hash y se muestra una sola vez, de modo que una página de la consola filtrada no regala a nadie una inscripción.
La mayoría de los sensores solo pueden avisarle. Más allá de permitir y descartar, este puede poner el dispositivo en cuarentena, ralentizar el origen, escalar, reescribir o enviar un POST a su webhook SOAR, despachado en un hilo de trabajo, de modo que la ruta en línea nunca espera a su automatización y un webhook lento no puede convertirse en un problema de red.
Si la consola no está accesible, o caduca una licencia, cada cortafuegos sigue aplicando la política que ya tiene y sigue escribiendo sus registros. Nada en la ruta de detección depende de que un tenant en la nube siga en pie, y nada se detiene porque lo haya hecho la facturación.
Demostración y precios: info@zedmos.com
Solicitar una demostración