Su red emite señales todo el día: una dirección MAC que se mueve, un vecino que nadie conoce, una configuración modificada de noche, un certificado a punto de caducar, una CVE que acaba de ser explotada. Soron, el módulo de alertas de red de ConnectMyAssets, las convierte en una monitorización de eventos de red que usted controla: 62 detectores, reglas definidas por grupo de equipos de red, una vista previa antes de activar nada y una única consola para reconocer, asignar y resolver cada alerta. Soron no envía nada a sus equipos: lee lo que nuestras recopilaciones y escaneos ya almacenan.
Solicitar una demoVecinos LLDP/CDP desconocidos, nuevas direcciones MAC, fabricantes prohibidos, equipos desconocidos en las tablas ARP y direcciones que responden sin propietario: cada equipo no autorizado se notifica con el switch y el puerto donde se vio, para poder aislarlo rápidamente.
Una dirección MAC presente en dos puertos de acceso a la vez, una ráfaga de nuevas direcciones en una VLAN, una puerta de enlace resuelta a una MAC inesperada: los signos de suplantación y flooding se convierten en alertas en lugar de indicios enterrados en tablas.
Hosts inaccesibles, latencia y pérdida ICMP, CPU y memoria, fuentes de alimentación, ventiladores y stacks, equipos desaparecidos: y cuando cae toda una sede, una sola alerta «muchos equipos ausentes» en lugar de cientos.
Nuevos enlaces, enlaces eliminados, direcciones MAC que cambian de puerto o de switch: sabrá cuándo cambia la red física, dónde y si se ha perdido redundancia.
Una configuración modificada fuera de ConnectMyAssets, una versión de software cambiada, una clave de host sustituida: cada cambio hecho fuera de su proceso se detecta en la siguiente recopilación, con el antes y el después en el historial de configuraciones.
Nuevas CVE críticas, CISA KEV, ransomware, umbrales y subidas del EPSS, plazos de corrección superados, exposición amplia: Soron convierte los datos de vulnerabilidades de cada equipo en una cola priorizada que se vacía sola tras cada actualización de firmware.
Puntuaciones de cumplimiento por debajo del objetivo, regresiones tras un cambio, puertos prohibidos abiertos, certificados caducados: y para cada alerta, una cronología inalterable de quién la vio, quién la trató y cuándo, una evidencia útil para las auditorías NIS2, ISO 27001 y PCI-DSS.
Escriba sus reglas una vez en el grupo superior y deje que todos los grupos de clientes las hereden; bloquee las que no se deben desactivar y deje que cada cliente añada sus propias listas, umbrales y excepciones. Cada técnico solo ve las alertas de los clientes que atiende.
En las redes OT, donde nada debería cambiar, una nueva dirección MAC, un vecino desconocido o un fabricante prohibido es un evento que conviene conocer. Soron lee lo que ya reunieron los escaneos y las recopilaciones que usted permitió por subred, y no añade tráfico propio.
Mantenga la lista de SSID permitidos y la de SSID prohibidos: cualquier punto de acceso que emita otra red, o cuyos clientes se conecten a una, se identifica con la red que difunde.
Subredes casi llenas, subredes solapadas entre sedes, direcciones fuera de los rangos declarados, grupos que ningún escaneo cubre, equipos a los que no llega ninguna recopilación: las brechas que debilitan a todos los demás detectores se listan cada día.
Fin de soporte próximo, firmware por detrás de su objetivo, certificados a punto de caducar: Soron avisa con la antelación que usted elija, para que las renovaciones se planifiquen en lugar de hacerse con prisas.
Cada alerta es una regla que usted escribió o conservó, sobre el ámbito que eligió, con las personas que eligió notificar.
Una regla indica un detector, sus parámetros, una gravedad y un grupo: se aplica a ese grupo y a todos los grupos inferiores. Una sede puede desactivar una regla heredada en su ámbito indicando un motivo, salvo que la regla esté bloqueada, y puede excluir subgrupos de sus propias reglas.
Afine cualquier regla con condiciones (todas, alguna, no, anidadas) sobre el equipo, su modelo y su fin de soporte, su grupo y sus atributos personalizados, sus vulnerabilidades y sus interfaces. La regla muestra sus condiciones en palabras claras.
Antes de guardar, vea cuántas alertas generaría la regla, cuántas cubre ya una excepción y las primeras coincidencias. Ajuste el ámbito, los parámetros o las condiciones hasta obtener el resultado que busca.
Marque como conocido una dirección MAC, un bloque de fabricante, un vecino, un SSID, una dirección, una red o un equipo, con un motivo y una fecha de fin. La excepción caduca sola: el ruido baja sin crear un punto ciego duradero. Las excepciones nunca debilitan una regla bloqueada.
Asigne una alerta a una persona o a un equipo, coméntela, reconózcala, ciérrela con una nota o silénciela hasta una fecha. Cada acción, en bloque o una a una, queda en la cronología de la alerta, que nunca se puede modificar.
Cuando la condición desaparece, la alerta se da por resuelta; cuando vuelve, se reabre la misma alerta con sus comentarios, su asignatario y su historial. Una alerta por asunto, nunca un duplicado.
Notificaciones en la aplicación agrupadas por regla y grupo, nunca una por equipo; correo electrónico por regla según el evento y la gravedad mínima; syslog y webhook HTTPS hacia su SIEM o su herramienta de tickets (ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty...) en CEF, LEEF, JSON o GELF.
Una vista general de Soron integrada (alertas activas y críticas, equipos no autorizados, nuevas alertas en 7 días, tiempo medio de reconocimiento y de resolución, alertas por detector, grupo y asignatario) y una vista general de monitorización. Cada detector tiene sus propios indicadores para añadir a cualquier panel, y cada cifra abre las alertas que hay detrás.
Una alerta pertenece al grupo del equipo o de la subred al que se refiere. Los usuarios solo leen las alertas de los grupos que pueden ver, y los títulos solo nombran lo que su grupo puede leer, en pantalla, en las notificaciones y a través de la API.
Cada detector puede usarse en tantas reglas como necesite, sobre grupos distintos, con sus propios parámetros, gravedad, condiciones y excepciones. En el primer arranque se instala una regla por defecto para cada detector; las que necesitan su lista (fabricantes prohibidos, SSID) o sus condiciones empiezan desactivadas.
Un equipo declara un vecino LLDP o CDP que no está en su inventario: un switch no gestionado, un router doméstico o un equipo conectado sin ticket aparece en cuanto se anuncia.
Dos equipos conocidos se enlazan por primera vez: un cable añadido entre switches, un nuevo uplink o un bucle en ciernes se notifica antes de que sorprenda a nadie.
Un enlace entre dos equipos lleva ausente más tiempo que su umbral y el vecino no se ve en ningún otro puerto: se señala un uplink cortado o una ruta redundante perdida, y la alerta se cierra cuando el enlace vuelve.
Un switch aprende una dirección MAC nunca vista en ninguna parte de la red: la primera señal de un nuevo endpoint, notificada en el equipo y el puerto donde apareció.
Una dirección MAC pertenece a un fabricante o a un prefijo que usted ha prohibido (hardware de consumo, una marca excluida por política): sabrá dónde está conectada, por cable o wifi.
Una dirección MAC aparece en otro puerto de la misma VLAN: detecta endpoints movidos sin solicitud de cambio y el flapping que delata un bucle.
Un endpoint que estaba en un puerto de acceso está ahora en otro puerto u otro switch, sin contar los uplinks: siga los traslados físicos en toda la sede, con la ubicación anterior y la nueva.
La misma dirección MAC está presente al mismo tiempo en puertos de acceso de dos equipos, salvo pares MLAG y VSX: el signo clásico de una dirección clonada o suplantada.
Un switch aprende en una VLAN más direcciones MAC nuevas que su umbral en pocos minutos: detecta un MAC flooding, un switch no gestionado lleno de clientes o un host de virtualización conectado al puerto equivocado.
Un router o un firewall resuelve una dirección IP que no pertenece a ningún equipo conocido, y la alerta indica en qué switch y puerto se vio por última vez.
Una dirección IP en uso no pertenece a ninguna subred declarada en su IPAM: salen a la luz errores de direccionamiento estático, rangos olvidados y equipos configurados a mano.
Una dirección responde por SSH pero no pudo convertirse en equipo gestionado (credenciales rechazadas, clave de host modificada, fabricante desconocido): la parte desconocida de la red se convierte en una lista que tratar.
Una dirección responde a los escaneos en una de sus subredes sin que ningún equipo conocido la tenga: la propia red encuentra el equipo que nadie declaró.
Un punto de acceso emite un SSID fuera de su lista permitida, o sus clientes se conectan a él: las redes no autorizadas y de pruebas se identifican con el punto de acceso que las difunde.
Se emite o se usa un SSID de su lista prohibida: detecta la red de invitados que se quedó activa en un edificio sensible o un nombre conocido de evil twin.
Un equipo notifica una nueva versión de software: se registra cada actualización y cada vuelta atrás, incluidas las que nadie anunció.
Un equipo ejecuta una versión más antigua que la imagen objetivo de su biblioteca: el retraso de actualizaciones se convierte en una lista de alertas que se cierran solas a medida que se actualizan los equipos.
La configuración en ejecución cambió sin que hubiera abierta en el equipo ninguna sesión del bastión, script, actualización de firmware ni aprovisionamiento ZTP de ConnectMyAssets: el cambio hecho fuera de su proceso se detecta en la siguiente recopilación.
Un equipo presenta una clave de host SSH distinta de la de confianza: un equipo sustituido, o un intento de interceptación, queda bloqueado hasta que alguien acepte la nueva clave.
Un equipo recopilado antes falla ahora recopilación tras recopilación (una contraseña que dejó de funcionar, un tiempo de espera agotado): su inventario y sus copias de seguridad no se quedan obsoletos en silencio.
Un equipo inventariado incluido en una recopilación programada lleva sin recopilarse más tiempo del que usted permite, con el motivo del último intento: se detecta un equipo retirado, robado o desconectado.
Desaparecen a la vez más equipos que su umbral: una sola alerta por la caída de una sede, un corte de WAN o un cambio de firewall, en lugar de cientos.
Un equipo de los tipos que usted elija baja de la puntuación de cumplimiento que ha fijado: la deriva del bastionado es visible antes de la auditoría.
Un equipo incumple una política de cumplimiento que cumplía justo antes, para las gravedades que usted elija: sabrá qué cambio rompió qué control, y cuándo.
Un modelo de equipo llega a su fin de soporte o de vida dentro del número de días que usted fije, o ya lo ha alcanzado: las renovaciones se planifican antes de que termine el soporte.
Un equipo no tiene nombre de host: una comprobación de higiene rápida que mantiene legibles los logs, los mapas y los tickets.
Un equipo, un grupo de equipos de red o una subred cumple condiciones sobre sus propios atributos personalizados (responsable, fin de contrato, criticidad, código de sede), incluidos los valores heredados.
Un grupo que ningún escaneo programado cubre, una subred que todos los escaneos excluyen, un equipo al que no llega ninguna recopilación: los puntos ciegos de su supervisión se listan cada día.
Una subred alcanza el umbral de ocupación que usted ha fijado: amplíela o límpiela antes de que el DHCP se quede sin direcciones.
Dos sedes o dos clientes declaran subredes que se solapan: detecta el conflicto de direccionamiento antes de que lo revele el enrutamiento o una fusión.
Se encontró un equipo en una dirección que no pertenece a ninguna subred de sus grupos, así que acabó en Unassigned: le indica qué subred declarar o qué equipo clasificar.
Un equipo deja de responder a ICMP: la primera señal de un corte de corriente, un enlace roto o un equipo bloqueado, que se cierra en cuanto vuelve a responder.
El tiempo de ida y vuelta hacia un equipo supera su umbral: los enlaces WAN congestionados y las sedes sobrecargadas destacan antes de que llamen los usuarios.
La pérdida de paquetes hacia un equipo supera su umbral: detecta el enlace o el transceptor defectuoso que pierde tráfico sin llegar a caer.
La CPU de un equipo se mantiene por encima de su umbral: se notifica una sobrecarga del plano de control, una tormenta de enrutamiento o un proceso bloqueado.
El uso de memoria de un equipo supera su umbral: las fugas de memoria y las tablas que desbordan el hardware se detectan antes del reinicio.
Cualquier métrica numérica que elija supera su umbral (temperatura, errores de interfaz, PoE, clientes, sesiones, peers BGP caídos, ocupación de canal), por interfaz, SSID o radio cuando procede.
Una fuente de alimentación, un ventilador, un stack o un par de alta disponibilidad notifica un estado fuera de los valores aceptados: las averías de hardware se detectan mientras la redundancia aún aguanta.
Un puerto que usted marcó como prohibido (Telnet, SMB, una consola de administración) está abierto en un host: una alerta por host y puerto, que se cierra cuando el puerto se cierra.
Un servicio TLS presenta un certificado caducado: se indican el host, el puerto y la fecha de fin para que la renovación llegue al equipo adecuado.
Un certificado caduca dentro del número de días que usted fije: renuévelo antes de que fallen integraciones, inicios de sesión y copias de seguridad.
Un servicio sigue usando un certificado autofirmado: se listan las impresoras, cámaras, tarjetas de SAI y BMC que acostumbran a los usuarios a ignorar las advertencias del navegador.
Un puerto abierto cumple sus propias condiciones sobre su certificado o su servicio (un emisor distinto de su CA, una clave RSA de menos de 2048 bits, TLS 1.0 o 1.1, un comodín, un servidor web inesperado).
Cualquier equipo que cumpla sus condiciones sobre cualquiera de sus campos, su grupo y los registros vinculados: «un switch de core sin soporte en una sede crítica», escrito en unos pocos clics.
Cualquier vulnerabilidad que cumpla sus condiciones sobre el hallazgo, la CVE y el equipo: «EPSS superior al 20 % y abierta desde hace más de 7 días en un firewall».
Cualquier interfaz que cumpla sus condiciones: un puerto de acceso sin descripción, un uplink a la velocidad equivocada, una interfaz caída en una VLAN de producción.
Cualquier entrada de la tabla MAC que cumpla sus condiciones: un bloque de fabricante en la VLAN equivocada, una cámara fuera de la red de vídeo, una dirección en un puerto que nunca debería usar.
Cualquier entrada ARP que cumpla sus condiciones: un rango de direcciones usado en el router equivocado, una puerta de enlace resuelta a una dirección MAC inesperada.
Cualquier regla de seguridad de FortiGate o PAN-OS que cumpla sus condiciones: any/any permitido, registro desactivado, un servicio inseguro entre zonas, una regla fuera de su política de nomenclatura.
Una CVE con una puntuación base CVSS de 9,0 o más pasa a aplicarse al fabricante, al modelo y al firmware de un equipo: las urgencias del día, equipo por equipo.
Se aplica a un equipo una CVE cuya puntuación CVSS, puntuación de riesgo de ConnectMyAssets o EPSS alcanza su umbral: usted fija el listón, por grupo de equipos de red.
Un riesgo aceptado, una marca de urgencia o una lista blanca llegó a su fecha de fin mientras la CVE sigue aplicándose: las decisiones de riesgo se revisan en lugar de durar para siempre.
Se aplica a un equipo una CVE del catálogo Known Exploited Vulnerabilities de CISA, con la fecha en que CISA la incluyó: lo que los atacantes ya usan va primero.
CISA acaba de añadir a su catálogo una CVE que se aplica a uno de sus equipos: una amenaza que acaba de activarse se notifica dentro de los días que usted elija.
Se aplica a un equipo una CVE explotada conocida que usan campañas de ransomware: los hallazgos que justifican un cambio de emergencia.
Se aplica a un equipo una CVE cuyo EPSS (la probabilidad de explotación en los próximos 30 días publicada por FIRST) alcanza su umbral: priorice por probabilidad, no solo por gravedad.
El EPSS de una CVE en uno de sus equipos sube los puntos que usted elija en los días que usted elija: una vulnerabilidad que los atacantes empiezan a atacar se detecta pronto.
Una CVE sigue abierta en un equipo más allá de su plazo según su tipo (explotada conocida, crítica o alta), y pasa a crítica cuando el retraso se ha duplicado: su SLA de parches se cumple.
Una CVE explotada conocida está abierta en al menos el número de equipos que usted fije: una alerta por CVE, con los equipos de cada grupo, para lanzar una campaña en lugar de cien tickets.
Solo las CVE explotadas conocidas cuya versión de firmware está dentro de un rango publicado, sin nada que confirmar, con la versión corregida y el aviso del fabricante: ninguna duda antes de actuar.
Una CVE que solo «puede aplicarse» a un equipo queda ahora confirmada por los datos de firmware: los hallazgos que había aparcado merecen una segunda mirada.
Nuestro servicio de vulnerabilidades no puede resolver el fabricante, el modelo y el firmware de un equipo: ninguna vulnerabilidad conocida no es lo mismo que ninguna, y usted sabe dónde mirar.
Para ingenieros de redes y de seguridad: de dónde vienen los datos, cuándo se evalúan las reglas y cómo viven las alertas.
Cada detector lee lo que ConnectMyAssets ya almacena: recopilaciones SSH (configuraciones, tablas MAC y ARP, LLDP/CDP, interfaces, versiones), escaneos de red y puertos auditados, lecturas de monitorización, resultados de cumplimiento y datos de vulnerabilidades. Ninguna sonda adicional, ninguna credencial adicional.
Las reglas se ejecutan tras cada recopilación de un equipo y al final de cada escaneo, limitadas a lo que se acaba de leer; cada cinco minutos para lo que cambia solo con el tiempo (un equipo desaparecido, un enlace eliminado); cada hora y cada día sobre todo su ámbito; y al instante cuando se crea o modifica una regla.
Un detector de condición (un puerto abierto, un certificado caducado) da por resuelta su alerta cuando la condición desaparece y la reabre cuando vuelve. Un detector de evento (una dirección MAC que se movió, una configuración modificada) cuenta cada nueva ocurrencia en la misma alerta, que cierra una persona.
Las reglas de evento empiezan en su fecha de creación, menos un periodo retroactivo que usted fija (24 horas por defecto): una regla creada hoy no genera alertas por las direcciones MAC aprendidas el año pasado, y la primera recopilación de un equipo es su inventario, no una novedad.
Cada regla se evalúa como una única consulta sobre todo su ámbito, nunca como un bucle sobre los equipos, y el trabajo se reparte por grupo en los árboles grandes. Usted fija la retención de las alertas cerradas (365 días por defecto).
Las alertas, las reglas y las excepciones están disponibles a través de la REST API (por ejemplo GET /api/v1/soron/alerts) con tokens de API de ámbito limitado, y cada cambio de una regla o una excepción se escribe en el registro de auditoría.
Parta de una regla por defecto o elija uno de los detectores y después fije sus parámetros, su gravedad, sus condiciones y su grupo.
Compruebe lo que encontraría la regla y afínela antes de activarla.
Reciba las alertas en la consola, por correo electrónico, syslog o webhook, con la gravedad que usted fije.
Reconozca, asigne y resuelva con el historial completo, y siga sus tiempos de respuesta en un panel.
Prepare su proyecto y defina su alcance.
Soron tiene 62 detectores en diez familias: topología y vecinos; MAC, ARP y direccionamiento; equipos no autorizados y wifi; configuración, firmware y recopilación; cumplimiento y ciclo de vida; cobertura e IPAM; monitorización; puertos y certificados; condiciones sobre cualquier dato; y vulnerabilidades. La lista completa está en esta página.
Conserve las reglas por defecto para vecinos LLDP/CDP desconocidos, nuevas direcciones MAC, equipos desconocidos en las tablas ARP y equipos desconocidos que responden a los escaneos, y añada su lista de fabricantes prohibidos. Cada alerta indica el switch y el puerto donde se vio el equipo, y la lista Rogue devices los reúne todos.
Defina el ámbito de cada regla en el grupo adecuado, añada condiciones y compruebe la vista previa antes de activarla. Las excepciones con fecha de caducidad absorben los casos conocidos, el silencio acalla una alerta hasta una fecha y las notificaciones se agrupan por regla y grupo, nunca una por equipo.
Sí. Las reglas pertenecen a grupos de equipos de red y los subgrupos las heredan; una sede o un cliente puede desactivar una regla heredada salvo que esté bloqueada, y añadir sus propias reglas. Las alertas respetan los permisos de cada usuario y siguen el ámbito elegido en la cabecera.
Soron evalúa las reglas tras cada recopilación de un equipo y al final de cada escaneo, sobre lo que se acaba de leer. Como las recopilaciones y los escaneos pueden programarse hasta cada 5 minutos, las alertas siguen el ritmo de su red; los detectores basados en el tiempo también se comprueban cada cinco minutos.
Sí. Las alertas llegan a syslog (RFC 5424 o RFC 3164, por UDP, TCP o TLS) y a webhooks HTTPS en CEF, LEEF, JSON (ECS) o GELF, lo que hace a Soron compatible con ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty y su SIEM. El correo electrónico se configura por regla.
Sí. Todos los detectores aceptan condiciones, y seis detectores generan una alerta para cualquier equipo, vulnerabilidad, interfaz, entrada MAC, entrada ARP o regla de firewall que cumpla las condiciones que usted escriba, sobre cualquier campo. La regla muestra sus condiciones en palabras claras y la vista previa muestra lo que encuentra.
No. Soron no envía nada a los equipos: trabaja con los datos que ConnectMyAssets ya recopila por SSH y mediante sus escaneos de red. Lo que puede ver es lo que contiene su inventario, y por eso las brechas de cobertura tienen su propio detector.
Descubra lo que ConnectMyAssets puede cambiar para su equipo. En su infraestructura, con sus requisitos.
Solicitar una demo