NDR, EDR, SIEM, XDR, MDR

NDR es software de seguridad que observa el tráfico de red, señala los comportamientos que parecen un ataque y aporta las pruebas para responder. El cortafuegos y los agentes de endpoint ven cada uno su propio equipo; NDR ve cómo se comunican los equipos entre sí: beaconing de mando y control (C2), escaneos, movimiento lateral y volúmenes de salida inusuales. NetSenX es una plataforma de Network Detection and Response (NDR) para empresas medianas de la UE que detecta ataques a partir del comportamiento de la red, explica cada alerta en lenguaje claro y guarda los datos de los clientes en la UE.

Network detection and response: herramientas de seguridad que analizan el tráfico entre dispositivos para detectar el comportamiento de un atacante y apoyar la respuesta. Los productos anteriores de esta categoría solían llamarse network traffic analysis (NTA).

Copia el tráfico entre sus dispositivos hacia un sensor, aprende qué es normal para cada uno y lanza una alerta cuando alguno empieza a comportarse como un atacante. La copia procede de un puerto espejo del switch (SPAN), de un pequeño TAP físico en un cable o de un agente en los hosts que usted elija. El sensor no necesita leer el contenido: la hora, el volumen, los destinos, los puertos, las respuestas DNS y las partes no cifradas del intercambio TLS bastan para ver un equipo que llama a un servidor externo cada pocos minutos, llama a la puerta de muchos hosts internos, inicia sesión en servidores que nunca usaba o envía mucho más tráfico al exterior de lo habitual. La respuesta es lo que su equipo hace con la alerta: investigar, aislar el host, restablecer cuentas. NetSenX funciona así: nunca descifra el tráfico, explica cada alerta en lenguaje claro en todos los planes y deja la decisión de respuesta en sus manos. No ve los dispositivos que permanecen en silencio ni los segmentos que usted no copia.

El EDR se ejecuta en cada endpoint y ve los procesos y archivos de esa máquina. Un SIEM recoge registros de muchos sistemas y los correlaciona. El NDR observa el tráfico entre dispositivos, por lo que también cubre los que no pueden llevar agente y la actividad que no deja registro. Los tres se complementan.

El EDR vigila cada ordenador por dentro, el NDR vigila el tráfico entre dispositivos, el XDR reúne varias fuentes en una consola y el MDR es un equipo que vigila las alertas por usted. El EDR (endpoint detection and response) es software instalado en portátiles y servidores que ve los procesos, los archivos y la memoria de esa máquina. El NDR (network detection and response) es un sensor que ve cómo hablan los dispositivos entre sí, incluidas impresoras, cámaras y máquinas donde no se puede instalar nada. El XDR (extended detection and response) es una plataforma que combina señales de equipos, correo, identidad, nube y, a veces, red. El MDR (managed detection and response) no es software, sino un servicio: personas que leen las alertas las 24 horas y actúan. También verá el SIEM (security information and event management), que recoge registros. NetSenX es un NDR; trabaja junto a los demás y no los sustituye.

No. NetSenX añade la visión de red que no tienen las herramientas de endpoint y de registros; no sustituye la protección de endpoints (EDR), el antivirus, la agregación de registros (SIEM) ni un servicio gestionado de detección (MDR). Desde el plan Business, las alertas pueden exportarse al SIEM que ya utiliza.

A menudo sí, porque el EDR y el NDR fallan en sitios distintos. El EDR (endpoint detection and response) solo ve las máquinas donde su agente está instalado y en buen estado. No ve impresoras, cámaras, móviles en la wifi, sistemas del edificio, máquinas ni el portátil de un proveedor, y los atacantes suelen desactivarlo primero en la máquina que toman. El NDR (network detection and response) observa el tráfico entre dispositivos, así que sigue viendo un host comprometido que llama a un servidor externo, escanea la red o saca datos, pase lo que pase con su agente. Si su empresa son unos pocos portátiles con todo en la nube, un EDR y buenas copias de seguridad pueden bastar por ahora. Si tiene una red local con servidores y dispositivos donde no puede instalar nada, el NDR cubre ese hueco. NetSenX señala beaconing, escaneos, movimiento lateral y volumen saliente inusual en todos los planes, incluido Free, para que vea lo que aporta en su propia red antes de pagar.

Normalmente primero el EDR, porque proteger cada ordenador frente al malware es la necesidad más básica. Un EDR (endpoint detection and response) o un buen antivirus moderno detiene buena parte del malware habitual en portátiles y servidores y, junto con la autenticación multifactor, las actualizaciones rápidas y copias de seguridad desconectadas y probadas, cubre los ataques que más sufren las pequeñas empresas. El NDR (network detection and response) viene después, y sube en la lista cuando tiene una red local con servidores, impresoras, cámaras o máquinas de producción sin agente, cuando un contrato con un cliente o NIS2 le pide detectar y notificar incidentes, o cuando quiere comprobar de forma independiente que la herramienta de los equipos no es el único testigo. No tiene que elegir a ciegas: el plan Free de NetSenX cubre 3 dispositivos sin límite de tiempo, así que puede poner un agente en un puerto espejo y ver lo que muestra la red antes de gastar dinero.

No por sí solo, aunque es un comienzo necesario. El antivirus y la protección de equipos detienen el malware conocido en los ordenadores donde funcionan. No cubren una contraseña robada usada para entrar desde fuera, un correo que lleva a contabilidad a pagar una factura falsa, un dispositivo donde no puede funcionar ningún antivirus ni un intruso que usa sus propias herramientas de administración, que el antivirus considera legítimas. Una base razonable para una pequeña empresa es autenticación multifactor en el correo y el acceso remoto, actualizaciones aplicadas rápido, protección en cada ordenador, copias de seguridad desconectadas o inmutables y probadas, y un breve plan escrito de a quién llamar. Después, la supervisión de la red muestra lo que el antivirus no ve: un dispositivo que de repente habla con muchos otros, llama a un servidor externo cada pocos minutos o envía muchos datos de noche. NetSenX lo hace en todos los planes; no sustituye a su antivirus.

El comportamiento entre máquinas, que un antivirus en un solo ordenador no puede ver. Cuatro patrones son los más importantes. Beaconing: un host que llama al mismo servidor externo a intervalos regulares, que es como el software de un atacante recibe instrucciones (command and control, C2). Escaneo: un dispositivo que llama a muchas direcciones o puertos para trazar el mapa de su red. Movimiento lateral: un puesto de trabajo que de pronto abre sesiones de administración hacia servidores que nunca usaba, a menudo con herramientas legítimas que el antivirus deja pasar. Volumen saliente inusual: muchos más datos de lo normal salen de un host, por ejemplo de noche. La detección de red cubre también los dispositivos donde no se puede instalar antivirus, como impresoras, cámaras y máquinas. NetSenX señala estos cuatro patrones en todos los planes, incluido Free, y explica cada alerta en lenguaje claro. No ve lo que ocurre dentro de un ordenador sin tocar la red, como abrir un archivo malicioso: eso sigue siendo tarea del antivirus o del EDR.

Los dispositivos sin agente, los agentes desactivados y el patrón de un ataque repartido entre varias máquinas. El EDR (endpoint detection and response) informa desde dentro de cada ordenador donde funciona. No informa desde una impresora, un grabador de cámaras, un NAS, un controlador del edificio, el móvil de un visitante ni un portátil no gestionado que alguien ha conectado. No informa desde un servidor donde lo desinstalaron o manipularon. Y cada agente ve un solo host, así que un patrón lento que solo tiene sentido en muchos hosts, como una máquina que toca decenas de recursos compartidos o que llama discretamente al exterior cada cinco minutos, se escapa con facilidad. La red ve todo esto, porque cualquier dispositivo tiene que comunicarse para hacer daño. NetSenX observa ese tráfico y mantiene un mapa de red de los dispositivos que ve. No ve el interior de un host, por eso las dos herramientas se complementan.

El equipo se queda en silencio, y la herramienta del equipo no puede avisar de su propio silencio, así que necesita un segundo testigo. Desactivar o desinstalar la protección de los equipos es un paso temprano habitual de intrusos y operadores de ransomware, con derechos de administrador robados o mediante un controlador vulnerable. A partir de ahí, la consola puede mostrar la máquina como desconectada o dejar de recibir eventos. Ayudan dos cosas. Primero, trate un agente silencioso como un incidente: configure en la consola del EDR una alerta para los agentes que dejan de informar y revise quién tiene permiso para desinstalarlos. Segundo, vigile la red, que el atacante no puede apagar desde esa única máquina. NetSenX sigue viendo el comportamiento del host pase lo que pase con su EDR: beaconing, escaneos, movimiento lateral y subidas inusuales. No ve el estado del propio EDR, así que no le dirá que el agente se detuvo; le dirá qué hace después la máquina.

Convierta el propio silencio en una alerta en su consola de protección de equipos y mantenga una vista independiente desde la red. La mayoría de las consolas de EDR y antivirus pueden avisar de los agentes que no se han comunicado durante un tiempo; actívelo, envíelo a un buzón que alguien lea y decida de antemano qué hará cuando un servidor se quede callado: llamar al responsable, comprobar si fue una reinstalación prevista y mirar qué hizo la máquina en la red. Compare cada mes la lista de máquinas que deberían tener agente con las que lo tienen. Limite el permiso para desinstalar o pausar el agente a unas pocas cuentas nominales con autenticación multifactor. La vista de red es el segundo testigo: NetSenX no lee el estado de su EDR, pero sigue señalando el servidor si empieza a hacer beaconing, escaneos, movimiento lateral o envíos inusuales, de modo que un agente silencioso no significa un ataque silencioso.

No. El XDR (extended detection and response) es una plataforma que reúne señales de varias fuentes en una sola consola, mientras que el NDR (network detection and response) es una de esas posibles fuentes. La mayoría de los productos XDR se construyen alrededor de un agente en los equipos y añaden registros de correo, identidad y nube; unos incorporan datos de red y otros no. Esto importa en los dispositivos donde no se puede instalar un agente, como impresoras, cámaras, sistemas del edificio, máquinas y appliances: un XDR basado solo en los equipos no los ve si no recibe datos de red. Antes de comprar, pregunte qué fuentes ingiere de verdad el XDR en su licencia, no en el folleto. NetSenX es un NDR: observa el tráfico entre dispositivos y señala beaconing, escaneos, movimiento lateral y volumen saliente inusual en todos los planes, incluido Free. No sustituye a un EDR ni a una plataforma XDR, y desde el plan Business sus alertas pueden exportarse al SIEM o XDR que ya utilice.

El MDR (managed detection and response) es un servicio en el que un equipo externo vigila sus alertas de seguridad las 24 horas y responde por usted; lo necesita si nadie en su empresa puede reaccionar a una alerta de noche o en fin de semana. Es un servicio, no una herramienta: el proveedor sigue dependiendo de sensores como el EDR (endpoint detection and response) en sus equipos y, a veces, de datos de red. Antes de firmar, compruebe qué hace realmente el proveedor a las 3 de la madrugada. ¿Aísla un equipo o solo envía un correo? ¿Qué sensores incluye y de quién son los datos si usted se va? ¿Con qué rapidez responde, por escrito? Muchas pequeñas empresas combinan en su lugar la detección automática con una guardia de su proveedor de TI. NetSenX es software, no un MDR: detecta y explica alertas a cualquier hora, y esas alertas llegan a su equipo o a su proveedor de TI, que deciden qué hacer.

El EDR es software; el MDR es un servicio prestado por personas. El EDR (endpoint detection and response) se instala en sus ordenadores y servidores; vigila procesos y archivos, lanza alertas y permite a un administrador aislar una máquina. Alguien tiene que leer esas alertas y decidir. El MDR (managed detection and response) es un proveedor cuyos analistas leen las alertas por usted, las 24 horas, y responden en un plazo acordado. La mayoría de los servicios MDR aportan o exigen su propio EDR, y algunos también toman datos de red o de nube. Así que la pregunta real no es EDR o MDR, sino quién lee las alertas de noche. Si tiene personal o un proveedor de TI de guardia, un EDR y la detección de red pueden bastar. Si nadie puede reaccionar fuera del horario de oficina, un servicio gestionado cubre ese hueco. NetSenX es software de detección, no un MDR: explica cada alerta para que su equipo o su proveedor puedan actuar.

Elija según lo que ocurre a las 3 de la madrugada, por escrito, no según el folleto. Hágale cinco preguntas a cada proveedor. ¿Qué hacen exactamente cuando ven un ataque: nos llaman, aíslan la máquina, restablecen cuentas o solo abren un ticket? ¿Qué tiempo de respuesta compromete el contrato y cómo se mide? ¿Qué sensores incluye: solo equipos o también red, correo, identidad y nube? ¿Dónde están nuestros datos y sus analistas, y qué subencargados utilizan? ¿Qué conservamos si nos vamos? Pida un informe de incidente de ejemplo y un cliente de referencia de su tamaño. Compruebe que el modelo de precio le encaja: por equipo, por usuario o por sede. Un sensor de red puede funcionar junto a un servicio MDR: las alertas de NetSenX salen por correo en todos los planes, por Slack o webhook desde el plan Pro y hacia un SIEM desde el plan Business, de modo que un proveedor puede recibirlas.

La mayoría de las empresas por debajo de unos cientos de personas lo externalizan o funcionan sin un SOC completo, porque cubrir las 24 horas exige varias personas formadas, no una. Un SOC (security operations centre) es un equipo que vigila alertas y responde, a menudo de forma continua. Montar uno significa contratar y retener analistas para turnos de noche y fin de semana, comprar y ajustar herramientas y redactar procedimientos; para una empresa mediana es un coste fijo elevado. Externalizarlo a un proveedor de MDR o MSSP lo convierte en un contrato, pero sigue necesitando a alguien dentro que conozca el negocio y tome decisiones. Un camino intermedio encaja a muchos: detección automática que funciona a cualquier hora, alertas explicadas lo bastante bien para un generalista, una guardia con su proveedor de TI y una empresa de respuesta a incidentes contratada de antemano. NetSenX encaja en ese camino como software de detección; no es un SOC y nadie en NetSenX vigila sus alertas por usted.

No, pero sí un plan para las horas en que ese administrador no está. Un SOC (security operations centre) es un equipo que vigila alertas las 24 horas; una empresa con un solo administrador no puede dotarlo de personal y normalmente no lo necesita. Lo que necesita es más concreto: detección que funcione sola, alertas lo bastante breves y claras como para actuar, una segunda persona que las reciba cuando el administrador no está y el teléfono de una empresa de respuesta a incidentes. Deje por escrito quién decide desconectar un equipo o la línea de internet en una emergencia. Mantenga lo básico: autenticación multifactor, actualizaciones, protección de equipos y copias desconectadas. NetSenX se creó para esta situación: un agente en un puerto espejo vigila todo un segmento, cada alerta se explica en lenguaje claro y las alertas se envían por correo en todos los planes, así que pueden llegar también a un suplente o a su proveedor de TI.

Sí, si la herramienta pide minutos al día y no un analista dedicado. Lo que lo hace posible son menos alertas, más claras, y una rutina. Decida quién lee las alertas cada mañana, quién cubre las vacaciones y qué es lo bastante urgente como para llamar a alguien de noche. Escriba una nota de respuesta de una página: cómo aislar un ordenador, quién puede restablecer cuentas, a qué proveedor llamar. Revise una vez al mes las alertas cerradas para ver qué era normal y debería marcarse así. Elija una herramienta que explique sus alertas, porque un simple nombre de regla o una puntuación devuelve al generalista a los registros en bruto. NetSenX explica cada alerta en lenguaje claro en todos los planes y le permite marcar falsos positivos. No elimina la necesidad de una persona: investigar y contener un incidente sigue correspondiendo a su equipo, a su proveedor de TI o a una empresa de respuesta a incidentes.

Para guardar los registros de muchos sistemas en un solo lugar, consultarlos y relacionar eventos entre ellos. Un SIEM (security information and event management) recoge registros de cortafuegos, servidores, directorios, VPN y servicios en la nube, los conserva durante un periodo fijado y ejecuta búsquedas de combinaciones sospechosas, como un inicio de sesión fallido en la VPN seguido de otro correcto desde otro país. Las empresas lo usan por tres motivos: detección, investigación a posteriori y pruebas para auditores y reguladores que esperan una conservación centralizada de registros. Su punto débil es el esfuerzo: alguien tiene que elegir las fuentes, escribir y ajustar las búsquedas y leer los resultados, o el SIEM se convierte en un archivo caro. Un SIEM solo ve lo que los sistemas registran; no ve el tráfico que no deja registro. La detección de red cubre esa parte, y NetSenX puede exportar sus alertas a su SIEM desde el plan Business.

Normalmente no como primer paso, salvo que un cliente, un auditor o un regulador pida expresamente la conservación centralizada de registros. Un SIEM (security information and event management) compensa su coste cuando alguien tiene tiempo para conectar fuentes, escribir búsquedas y leer los resultados. Una pequeña empresa suele conseguir más protección, antes, con la autenticación multifactor, la protección de equipos, las copias desconectadas y una detección que funcione sin ingeniería de registros. En cualquier caso, conserve los registros que más importan en una investigación: inicios de sesión en el correo y el acceso remoto, registros del cortafuegos y la VPN y registros de seguridad de los servidores, guardados donde un atacante no pueda borrarlos con facilidad y con la hora correcta en cada dispositivo. Muchos servicios en la nube guardan los registros de inicio de sesión por usted si lo activa. NetSenX mantiene un registro de auditoría en todos los planes y un historial de alertas según el plan, y si más adelante añade un SIEM, las alertas pueden exportarse a él desde el plan Business.

No necesariamente: muchas pequeñas y medianas empresas obtienen más de un NDR y una buena protección de equipos que de un SIEM que nadie tiene tiempo de ajustar. Un SIEM (security information and event management) recoge y correlaciona registros de muchos sistemas: cortafuegos, servidores, directorios, servicios en la nube. Es potente cuando alguien escribe y mantiene sus búsquedas, y pesado cuando nadie lo hace. El NDR (network detection and response) ofrece detecciones a partir del tráfico de red sin ingeniería de registros. Responden a preguntas distintas: el SIEM dice quién inició sesión y dónde; el NDR, qué hicieron los dispositivos en la red. Puede que necesite un SIEM de todos modos si un auditor, un contrato con un cliente o un regulador espera la conservación centralizada de registros, o cuando tenga personal para usarlo. Si ya tiene uno, las alertas del NDR pueden alimentarlo: NetSenX ofrece exportación al SIEM desde el plan Business, de modo que las detecciones de red llegan al SIEM ya explicadas.

Sí, la mayoría de las herramientas de detección de red pueden hacerlo, y suele ser mejor que enviar registros de red en bruto. Un SIEM (security information and event management) que recibe alertas de red explicadas gana una visión que de otro modo no tiene, sin el coste de almacenamiento ni el ruido de cada registro de conexión. Antes de conectarlo, decida qué niveles de alerta van al SIEM, quién los lee allí y cómo comparten ambas herramientas un nombre de host o una dirección para poder cruzar las alertas con los eventos de los registros. En NetSenX, la exportación al SIEM está incluida desde el plan Business. En el plan Pro, las alertas también pueden salir por la API, Slack o un webhook, y en todos los planes se envían por correo y se guardan en el panel durante el historial de alertas de su plan. Exportar no cambia lo que ve NetSenX: sigue siendo comportamiento de red, nunca el contenido de las sesiones cifradas.

Un IDS basado en firmas compara el tráfico con patrones de ataque conocidos; NetSenX puntúa el comportamiento de cada equipo, de modo que una variante nueva de malware sin firma también deja rastro. Cada alerta indica en lenguaje claro las características de red que determinaron su puntuación (valores SHAP). NetSenX funciona junto a su IDS, EDR y SIEM; no los sustituye.

Un IDS o un IPS compara el tráfico con patrones de ataque conocidos; el NDR observa cómo se comporta cada dispositivo a lo largo del tiempo. Un IDS (intrusion detection system) lanza una alerta cuando el tráfico coincide con una firma, como un exploit o un patrón de malware conocido. Un IPS (intrusion prevention system) hace lo mismo y puede descartar el tráfico coincidente, normalmente como parte de un cortafuegos. Ambos funcionan bien con amenazas conocidas y peor cuando un atacante usa herramientas legítimas o una variante nueva sin firma. El NDR (network detection and response) aprende qué es normal para cada host y señala las desviaciones: nuevos interlocutores, llamadas regulares al exterior, escaneos, volúmenes inusuales. Muchas empresas usan ambos. NetSenX es un NDR: evalúa el comportamiento de los hosts, explica cada alerta en lenguaje claro y no descarta ni bloquea tráfico, así que puede funcionar junto al IPS de su cortafuegos sin cambiar el camino de la red.

Un cortafuegos decide qué conexiones se permiten; el NDR observa lo que ocurre dentro de las conexiones que se han permitido. Un cortafuegos se sitúa en el borde de la red, o entre segmentos, y aplica reglas: esta dirección puede llegar a ese servidor en este puerto y todo lo demás se rechaza. Es imprescindible, pero un atacante que entra por un correo de phishing o una contraseña robada usa conexiones que el cortafuegos permite, y la mayoría de los cortafuegos ni siquiera ven el tráfico entre dispositivos del mismo segmento. El NDR (network detection and response) recibe una copia del tráfico y busca comportamientos: un puesto de trabajo que de pronto habla con muchos servidores, un host que llama a una dirección externa cada pocos minutos, datos que salen de noche. Necesita los dos. NetSenX no filtra ni bloquea nada; avisa y explica, y es usted o su cortafuegos quien actúa.

La supervisión NetFlow registra quién habló con quién, el análisis de tráfico estudia esos registros y el NDR añade encima la detección y la respuesta. NetFlow y formatos similares son resúmenes que routers y switches exportan por cada conexión: direcciones, puertos, hora de inicio, bytes y paquetes. Las herramientas de supervisión los convierten en gráficos de ancho de banda y listas de los mayores emisores, útiles para la capacidad y la resolución de problemas, pero el juicio de seguridad queda en sus manos. El análisis de tráfico de red (network traffic analysis, NTA) era el nombre anterior de las herramientas que estudiaban el tráfico con fines de seguridad. El NDR (network detection and response) es el nombre actual: aprende qué es normal por host, alerta sobre comportamientos de atacante y respalda la respuesta con evidencias. Los resúmenes de flujos por sí solos pierden detalles como las respuestas DNS o el intercambio TLS. NetSenX lee su propia copia del tráfico desde un agente o un puerto espejo, en lugar de depender solo de registros de flujos exportados.

Ninguna es mejor por sí sola: las firmas son precisas ante amenazas conocidas, los métodos de comportamiento detectan lo que aún no tiene firma y las buenas herramientas usan ambos. Una firma reconoce algo ya conocido, como la huella de un malware o una cadena de exploit, así que rara vez da falsas alarmas, pero se le escapan las variantes nuevas y los atacantes que usan sus propias herramientas de administración. La detección de comportamiento o basada en aprendizaje automático compara la actividad con lo normal y puede ver una herramienta nueva que llama a su servidor, pero necesita tiempo para aprender su red y debe explicarse, o cada alerta se vuelve un misterio. Cuidado con la etiqueta: pregunte al proveedor qué mira realmente el modelo, cómo reduce los falsos positivos con sus datos y si cada alerta dice por qué saltó. NetSenX evalúa el comportamiento de los hosts y explica cada alerta en lenguaje claro. No da una tasa de falsos positivos que no pueda respaldar con sus propios datos.

Un puerto espejo o un TAP suele ser mejor para todo un segmento de oficina, y los agentes para servidores concretos o lugares donde no se puede copiar el tráfico. Con SPAN (una función del switch que copia el tráfico a un puerto) o un TAP (un pequeño dispositivo que copia el tráfico de un cable), un solo sensor ve todos los dispositivos del segmento, incluidas impresoras, cámaras y máquinas, sin instalar nada en ellos. Requiere un switch gestionable o un TAP, y solo ve los segmentos que se copian. Un agente en un host ve el tráfico propio de ese host esté donde esté, incluidos servidores en un centro de datos o en la nube donde no se puede copiar nada. Muchas empresas combinan ambos. NetSenX admite los dos: un agente en un puerto SPAN o TAP cuenta como un solo dispositivo para todo el segmento, y los agentes funcionan en Linux y macOS. La huella TLS requiere captura de paquetes, que el modo básico de macOS no realiza.

Sí, con límites. El ritmo, el volumen, los destinos y el handshake TLS siguen siendo visibles sin descifrar, y bastan para detectar beaconing, escaneos o envíos inusuales. Sin descifrar, ningún NDR puede leer el contenido de una sesión. NetSenX nunca descifra.

En parte: ve las conexiones de sus dispositivos con los servicios en la nube y SaaS, no lo que ocurre dentro de esos servicios. Desde la red de la oficina, el NDR (network detection and response) ve qué hosts se conectan con qué proveedores de nube, con qué frecuencia y cuántos datos envían, así que un servidor que sube de noche un archivo grande a una cuenta de almacenamiento desconocida llama la atención. Lo que no ve es la actividad dentro de la propia aplicación SaaS: una regla de buzón creada en su servicio de correo, un archivo compartido públicamente desde una unidad en la nube o un inicio de sesión con una contraseña robada desde otro país. Eso queda en los registros de auditoría y de acceso del proveedor, que conviene activar y revisar. El tráfico de portátiles en casa que nunca pasa por su red también queda fuera de vista, salvo que funcione en ellos un agente. NetSenX muestra en todos los planes los destinos en la nube en una cola de revisión del mapa de red, y el volumen saliente inusual como alerta.

Depende del producto; NetSenX alerta y recomienda, y no bloquea tráfico por sí mismo. Algunos productos NDR se colocan en el camino del tráfico o se integran con cortafuegos para cortar conexiones automáticamente. Eso puede detener un ataque, y también su línea de producción ante un falso positivo, por lo que el bloqueo automático suele limitarse a casos acotados y bien probados. Un sensor en un puerto espejo, que es como se despliega la mayoría de los NDR, solo recibe una copia del tráfico y no puede bloquear nada por sí mismo; la respuesta pasa por su cortafuegos, su switch, su herramienta de equipos o una persona. NetSenX explica cada alerta, ofrece acciones de respuesta manuales desde el plan Starter y recomendaciones de respuesta automáticas desde el plan Pro, y nunca bloquea el tráfico por su cuenta. Decidir aislar una máquina, bloquear una dirección o restablecer cuentas sigue en manos de su equipo, y por eso cada acción queda en el registro de auditoría.

Observe la red durante un tiempo y anote cada dispositivo que envía tráfico, con el nombre que anuncia, su dirección y con quién habla. Los dispositivos se delatan al pedir una dirección (DHCP), resolver nombres (DNS), anunciarse en la red local o conectarse a servidores. Un sensor en un puerto espejo recoge esto de forma pasiva, sin escanear nada, lo que importa en dispositivos delicados como impresoras, cámaras y máquinas. Compare el resultado con la lista que cree tener: dispositivos desconocidos, servidores olvidados y equipos personales suelen aparecer en los primeros días. Después asigne un responsable a cada dispositivo y decida si debe estar ahí. NetSenX mantiene un mapa de red en todos los planes, incluido Free: los dispositivos vistos en la LAN, los nombres que anuncian, su primera y última aparición y quién habla con quién. Solo ve los segmentos supervisados, y un dispositivo que nunca envía tráfico no aparece.

No. Un mapa de red pasivo solo conoce los dispositivos que envían algo en un segmento supervisado, así que un dispositivo totalmente silencioso queda invisible. En la práctica, muy pocos dispositivos están del todo callados: la mayoría pide una dirección, resuelve nombres, busca actualizaciones o responde en la red de vez en cuando, y por eso aparecen en horas o días. Los que no aparecen suelen estar apagados, desconectados, en un segmento que usted no copia o callados a propósito. Para cerrar ese hueco, compare el mapa con otras fuentes: la tabla de puertos del switch, las concesiones del servidor DHCP, sus registros de compras y un recorrido por el edificio. El escaneo activo encuentra dispositivos silenciosos que responden cuando se les pregunta, pero úselo con cuidado en impresoras y equipos industriales. NetSenX construye su mapa de red de forma pasiva en todos los planes y nunca sondea los dispositivos, lo que es seguro para los equipos delicados y significa que un dispositivo silencioso no está en el mapa.

Los equipos pequeños rara vez tienen tiempo de leer a diario los registros del cortafuegos y del DNS, y los atacantes que usan herramientas de administración legítimas dejan pocas huellas en otros sitios. El NDR observa el tráfico de forma continua y avisa de lo que se desvía. NetSenX tiene un plan Free, así que un equipo puede probarlo en su propia red antes de pagar.

Pregunte cómo se cobra, qué necesita de usted, qué no ve y cómo justifica una alerta, y pruébelo en su propia red. Precio: ¿está publicado y cuál es la unidad, un dispositivo, un sensor o un gigabit? Despliegue: ¿hace falta hardware en cada sede o un sensor en un puerto espejo cubre un segmento? Visibilidad: qué segmentos, tráfico cifrado, nube y portátiles remotos; pida al proveedor que diga claramente qué queda fuera de vista. Alertas: ¿cada una explica por qué saltó, con palabras que entienda su equipo? Falsos positivos: ¿cómo se mide la tasa y con qué datos? Datos: ¿dónde se guardan, quiénes son los subencargados, qué recupera al irse? Respuesta: ¿bloquea o solo alerta? Después, déjelo funcionar unas semanas con tráfico real. NetSenX publica sus precios y tiene un plan Free sin límite de tiempo para esa prueba.

Genere versiones inofensivas del comportamiento que debería detectar, en un host de pruebas suyo, y compruebe qué alertas aparecen y con qué rapidez. Empiece por lo sencillo y avise de la prueba a quien pudiera reaccionar. Un escaneo de puertos desde un portátil de repuesto contra su propia subred debería señalarse. Un script que llama al mismo servidor externo de pruebas cada pocos minutos durante una hora imita el beaconing. Copiar de noche un archivo grande desde un servidor de pruebas a una cuenta de almacenamiento externa imita un robo de datos. Anote qué hizo, cuándo y qué detectó la herramienta, y después lea el texto de la alerta: ¿sabría un compañero qué hacer? Repita tras cambios importantes en la red o en la herramienta. La simulación de brechas y ataques (breach and attack simulation, BAS) automatiza estas pruebas. NetSenX incluye BAS desde el plan Business; en todos los planes puede hacer estas pruebas a mano frente a las detecciones que genera.

La simulación de brechas y ataques (breach and attack simulation, BAS) es software que imita de forma segura el comportamiento de un atacante en su red, para comprobar si sus herramientas de seguridad lo detectan. En lugar de esperar un ataque real o la prueba de penetración anual, ejecuta escenarios controlados, como un escaneo, una llamada a un servidor de pruebas o una transferencia de datos simulada, y registra cuáles detectaron sus herramientas. Una empresa mediana le saca más partido cuando debe demostrar a auditores o clientes que la detección funciona, y no solo que está instalada, o tras cambiar su red o sus herramientas. Si aún no tiene ninguna herramienta de detección, compre primero la detección: una simulación que nadie detecta solo demuestra eso. Una prueba de penetración hecha por personas sigue encontrando cosas que la BAS no ve, como contraseñas débiles o configuraciones erróneas. NetSenX incluye la simulación de brechas y ataques desde el plan Business, para probar sus propias detecciones.

Haga una prueba breve tras cada cambio importante, una más completa al menos una vez por trimestre y otra antes de una auditoría. La detección se rompe sin hacer ruido: se cambia un switch y no se vuelve a configurar el puerto espejo, un agente se detiene tras una actualización, aparece un segmento que nadie supervisa. Una prueba corta después de cada cambio lo detecta. Una ronda trimestral de los escenarios principales, como escaneo, beaconing, movimiento lateral y una gran transferencia saliente, muestra si algo se ha desviado y le da pruebas fechadas para auditores, aseguradoras y clientes. Lleve un registro sencillo: fecha, escenario, alerta esperada, alerta obtenida, tiempo hasta la alerta y seguimiento. Avise a su equipo y a sus proveedores antes de la prueba para que nadie aísle una máquina por error. NetSenX incluye la simulación de brechas y ataques desde el plan Business; en los demás planes puede ejecutar a mano los mismos escenarios.