Durante la semana 39 de 2026, nuestro SOC analizó 1.637 indicadores SonicWall registrados por firewalls SonicWall TZ270 y TZ370 instalados en diferentes entornos profesionales.
Entre las detecciones observadas durante el periodo destacan:
- Port Scan Possible
- SMTP Server on RBL Blacklist
Sin embargo, es importante empezar aclarando algo:
1.637 indicadores no significan 1.637 ataques confirmados.
SonicWall detecta y registra actividad relacionada con conexiones, reputación, patrones de red y diferentes mecanismos de seguridad.
Después:
nuestro SOC analiza los logs, su contexto y las posibles relaciones con otros eventos.
Esta diferencia evita convertir cualquier alerta automática en un incidente de seguridad sin haber comprobado previamente qué ocurrió realmente.
Indicadores SonicWall: ¿qué estamos supervisando?
Los firewalls incluidos en nuestra monitorización se encuentran desplegados en empresas y despachos de sectores como:
- administraciones de fincas;
- asesorías contables;
- asesorías laborales;
- despachos de abogados;
- arquitectura;
- interiorismo;
- constructoras;
- desarrollos de ingeniería;
- despachos profesionales ubicados en viviendas.
Aunque se trate de actividades muy diferentes, todas comparten una necesidad:
proteger el acceso entre su infraestructura e Internet.
Un firewall empresarial no debería limitarse a:
permitir o denegar conexiones.
También puede aportar información sobre:
- intentos de conexión;
- servicios publicados;
- patrones de escaneo;
- reputación;
- actividad de red.
Y cuando esos logs se integran con un SIEM, podemos disponer de una visión mucho más completa.
Indicadores SonicWall: qué significa Port Scan Possible
Una de las detecciones de esta semana fue:
Port Scan Possible
Un escaneo de puertos consiste en realizar conexiones contra diferentes puertos de un sistema para intentar averiguar qué servicios están disponibles.
Por ejemplo, un sistema podría comprobar secuencialmente si existen servicios relacionados con:
- administración;
- web;
- VPN;
- SSH;
- correo;
- bases de datos.
Ese comportamiento puede utilizarse legítimamente durante una auditoría.
Sin embargo, también es una técnica habitual durante la fase de reconocimiento previa a numerosos ataques.
Por tanto:
Port Scan Possible no significa compromiso.
Significa que SonicWall ha identificado un patrón de conexiones compatible con un posible reconocimiento de puertos.
¿Qué intenta descubrir un escaneo?
Un atacante no puede explotar fácilmente un servicio que desconoce.
Por eso una secuencia habitual puede ser:
localizar una dirección
↓
identificar puertos abiertos
↓
determinar qué servicio responde
↓
buscar una vulnerabilidad
↓
intentar explotarla
Un escaneo pertenece principalmente a las primeras fases de ese proceso.
Detectarlo no demuestra que las siguientes fases hayan ocurrido.
Sin embargo, sí proporciona información útil para conocer qué actividad está recibiendo nuestro perímetro.
Indicadores SonicWall: ¿Port Scan Possible fue bloqueado?
Este punto requiere precisión.
Una detección de SonicWall no debería describirse automáticamente como:
“ataque bloqueado”.
Para afirmar que una actividad fue bloqueada debemos disponer de un evento cuya acción confirme expresamente:
block / drop / prevent
o equivalente.
Si el registro únicamente identifica:
Port Scan Possible
lo correcto es hablar de:
detección o indicador.
Posteriormente debemos analizar qué ocurrió con las conexiones.
¿Qué revisamos si un escaneo no aparece como bloqueado?
Cuando el evento no confirma una acción de bloqueo, nuestro SOC puede revisar diferentes elementos.
Por ejemplo:
Puerto de destino
¿Qué servicio estaba intentando alcanzar?
NAT
¿Existe realmente una publicación desde Internet?
Regla del firewall
¿La comunicación podía atravesar el perímetro?
Destino
¿Existía un equipo escuchando en ese puerto?
Conexiones posteriores
¿El mismo origen volvió a comunicarse?
Endpoint o servidor
¿Existe actividad relacionada después del intento?
Esta información permite pasar de:
“tenemos una alerta”
a:
“entendemos qué ocurrió”.
Indicadores SonicWall y superficie de ataque
La mejor forma de gestionar muchos escaneos no consiste simplemente en bloquear cada dirección que aparezca.
Internet cambia constantemente.
Además, un atacante puede utilizar:
- servidores cloud;
- VPS;
- proxies;
- VPN;
- infraestructura comprometida.
Por tanto, una estrategia más robusta consiste en reducir:
la superficie de ataque.
Es decir:
no publicar aquello que no necesita estar publicado.
Menos servicios expuestos, menos oportunidades
Una empresa debería revisar periódicamente:
- NAT;
- reglas WAN;
- VPN;
- servicios web;
- administración remota;
- RDP;
- SSH.
Una regla creada hace años puede continuar activa aunque ya no sea necesaria.
Por ello, conviene preguntarse:
¿necesitamos que este servicio siga siendo accesible desde Internet?
Si la respuesta es no:
cerrarlo reduce riesgo.
Indicadores SonicWall: no recomendamos RDP directamente en Internet
El escritorio remoto puede resultar necesario en determinadas organizaciones.
Sin embargo:
RDP publicado directamente hacia Internet no debería ser la opción habitual.
En su lugar, recomendamos utilizar:
VPN + autenticación + permisos adecuados
y, cuando sea posible:
MFA.
De esta forma reducimos considerablemente la exposición del servicio.
Indicadores SonicWall: qué significa SMTP Server on RBL Blacklist
La segunda categoría relevante registrada esta semana fue:
SMTP Server on RBL Blacklist
Una RBL o Real-time Blackhole List es una base utilizada para identificar direcciones asociadas con:
- spam;
- abuso;
- actividad sospechosa;
- mala reputación de correo.
Por tanto, este evento está relacionado principalmente con:
reputación SMTP.
No significa automáticamente:
servidor infectado.
Tampoco significa necesariamente:
ataque entrante.
¿Por qué puede aparecer un servidor SMTP en una RBL?
Existen diferentes motivos.
Por ejemplo:
- envío previo de spam;
- servidor comprometido;
- IP compartida por varios clientes;
- mala reputación del proveedor;
- configuración incorrecta;
- infección anterior;
- falso positivo.
Por eso el análisis necesita contexto.
Indicadores SonicWall: qué revisar ante un evento RBL
Si aparece una detección de este tipo podemos revisar:
- servidor SMTP relacionado;
- reputación de la dirección;
- dominio;
- volumen de correo;
- autenticaciones;
- actividad de las cuentas;
- logs del servidor;
- posibles reenvíos;
- configuración SPF, DKIM y DMARC cuando corresponda.
Además, resulta importante saber:
si estamos observando una conexión entrante desde un servidor listado
o:
un problema relacionado con nuestra propia infraestructura de correo.
El mismo nombre de alerta no debería conducir automáticamente a la misma conclusión.
Una RBL no demuestra malware
Esta precisión es especialmente importante.
Una dirección incluida en una lista de reputación puede estar relacionada con:
spam
sin que exista:
malware.
Además, si la IP pertenece a infraestructura compartida, diferentes usuarios pueden haber contribuido a su reputación.
Por tanto:
RBL ≠ infección confirmada.
Es un indicador adicional que necesita análisis.
Indicadores SonicWall: 1.637 eventos y su contexto
Los 1.637 indicadores SonicWall revisados esta semana estuvieron asociados principalmente con:
posibles escaneos de puertos
y:
eventos de reputación SMTP.
Eso permite construir una fotografía semanal de la actividad que reciben las empresas protegidas.
Sin embargo, el verdadero valor no se encuentra únicamente en contar eventos.
Está en poder responder preguntas como:
¿qué servicio intentaban alcanzar?
¿estaba publicado?
¿la comunicación fue permitida?
¿existió actividad posterior?
¿se repite el patrón?
¿existen otros eventos relacionados?
Indicadores SonicWall: origen geográfico de la actividad
El listado técnico revisado durante la semana muestra infraestructura asociada a diferentes regiones.
Entre las geolocalizaciones observadas aparecen direcciones asociadas, según las bases de geolocalización y registro consultadas, con:
🇺🇸 Estados Unidos
🇳🇱 Países Bajos
🇪🇸 España
🇵🇱 Polonia
🇬🇧 Reino Unido
🇦🇺 Australia
y diferentes localizaciones de Asia.
Por ejemplo, algunos de los recursos examinados aparecen asociados a Países Bajos, Estados Unidos, Polonia y Australia en las fuentes de inteligencia consultadas. IPinfo
Sin embargo, existe una aclaración imprescindible:
el país asociado a una IP no identifica el país del atacante.
Geolocalización no significa atribución
Una dirección geolocalizada en Estados Unidos puede pertenecer a:
un servidor cloud utilizado desde cualquier parte del mundo.
Una IP asociada a Países Bajos puede ser:
- VPS;
- VPN;
- proxy;
- servidor comprometido.
Por tanto:
IP en país X ≠ atacante situado en país X.
La geolocalización aporta contexto de infraestructura.
No demuestra la identidad o ubicación física del responsable.
Indicadores SonicWall y proveedores cloud
Otro patrón relevante de esta semana es la presencia de infraestructura perteneciente o asociada a distintos proveedores de cloud, hosting y centros de datos.
Entre las redes verificadas encontramos infraestructura relacionada con:
- Microsoft
- DigitalOcean
- IONOS
- UCloud
- DataCamp / CDNext
- TechTies
- Hydra Communications / Infrawatch
- otros proveedores de hosting y conectividad.
Por ejemplo, una de las redes revisadas está anunciada por Microsoft, mientras que varias direcciones diferentes corresponden a la infraestructura de DigitalOcean. También aparecen redes pertenecientes a IONOS, UCloud y DataCamp/CDNext. IPIP Whois
Esto tampoco significa que:
Microsoft, DigitalOcean, IONOS o cualquier otro proveedor estén realizando los ataques.
Un proveedor de hosting no es el atacante
Este concepto es fundamental para interpretar los logs.
Un proveedor cloud alquila recursos.
Un tercero puede contratar:
una máquina virtual
y utilizarla para diferentes finalidades.
Además, un servidor legítimo puede ser comprometido y utilizado posteriormente para:
- escaneos;
- ataques;
- spam;
- proxies.
Por tanto:
proveedor de infraestructura ≠ responsable de la actividad.
Nuestro análisis utiliza esta información únicamente como:
contexto de red.
Indicadores SonicWall y DigitalOcean
Dentro del conjunto revisado encontramos varias redes correspondientes a DigitalOcean. Las fuentes de registro consultadas identifican esos recursos bajo el ASN de DigitalOcean. IPinfo
Esto es habitual en actividad de Internet.
Los proveedores VPS permiten desplegar servidores en pocos minutos.
Esa facilidad es útil para:
- desarrolladores;
- empresas;
- servicios web.
Pero también puede utilizarse para:
- automatización;
- scanners;
- proxies.
De nuevo:
que una dirección pertenezca a DigitalOcean no convierte a DigitalOcean en origen del ataque.
Indicadores SonicWall y Microsoft
También aparece infraestructura perteneciente a Microsoft.
El bloque analizado está anunciado por el ASN de Microsoft Corporation. IPIP Whois
En servicios cloud puede existir actividad procedente de máquinas virtuales o aplicaciones alojadas por clientes.
Por tanto, debemos diferenciar:
proveedor Microsoft
de:
usuario que utiliza infraestructura de Microsoft.
Esta misma regla debe aplicarse a cualquier plataforma cloud.
Indicadores SonicWall y servicios de hosting europeos
El análisis también incluye redes relacionadas con proveedores como:
- IONOS;
- TechTies;
- Hydra Communications;
- DataCamp/CDNext.
Algunas de estas infraestructuras aparecen geolocalizadas en España, Países Bajos, Polonia o Reino Unido. IPinfo
La variedad refuerza una conclusión:
la actividad de Internet no tiene una frontera geográfica sencilla.
Por eso bloquear países completos no sustituye al análisis técnico.
No atribuimos proveedores sin evidencia
Durante el análisis evitamos asociar una dirección con un proveedor únicamente por:
- reputación;
- similitud;
- información antigua.
Las asignaciones IP pueden cambiar.
Además, existen:
- revendedores;
- reasignaciones;
- infraestructuras compartidas.
Por ello utilizamos información actual de ASN y red antes de atribuir una infraestructura.
Esto resulta especialmente importante cuando hablamos públicamente sobre ciberseguridad.
Indicadores SonicWall: ¿por qué no publicamos las direcciones?
En nuestros informes públicos mostramos:
- tendencias;
- países;
- proveedores;
- tipos de detección.
Sin embargo, evitamos publicar innecesariamente:
las direcciones IP concretas analizadas.
Nuestro objetivo no es crear una lista pública de infraestructura.
Queremos explicar:
qué estamos detectando y cómo lo analizamos.
Los datos técnicos completos permanecen dentro de los procesos internos necesarios para la investigación.
Indicadores SonicWall y sectores profesionales
Los SonicWall TZ270 y TZ370 monitorizados durante la semana protegen entornos muy diferentes.
Administraciones de fincas
Pueden manejar:
- propietarios;
- proveedores;
- facturación;
- cuentas bancarias;
- documentación.
Asesorías contables y laborales
Trabajan con:
- datos fiscales;
- nóminas;
- contratos;
- información empresarial.
Despachos de abogados
Gestionan:
- expedientes;
- documentación confidencial;
- comunicaciones.
Arquitectura e interiorismo
Pueden disponer de:
- planos;
- proyectos;
- presupuestos;
- documentación de clientes.
Constructoras e ingenierías
Trabajan con:
- proyectos técnicos;
- proveedores;
- documentación contractual;
- acceso remoto.
Despachos profesionales en viviendas
También pueden disponer de:
- NAS;
- VPN;
- servidores;
- documentación empresarial.
El tamaño de la oficina no determina:
el valor de su información.
Indicadores SonicWall: pequeñas empresas también reciben reconocimiento automatizado
Un scanner de Internet no necesita saber previamente:
qué empresa existe detrás de una dirección.
Puede analizar grandes cantidades de recursos automáticamente.
Por tanto, una pyme puede recibir:
- escaneos;
- intentos de conexión;
- enumeraciones;
sin haber sido seleccionada específicamente por un atacante.
Este concepto ha ganado todavía más importancia con la automatización.
La pregunta ya no es «¿por qué iban a atacarme?»
Una pregunta más útil es:
¿qué encontrarían si analizaran hoy nuestra dirección pública?
¿Encontrarían:
- RDP?
- VPN antigua?
- panel administrativo?
- servicio sin actualizar?
- regla NAT olvidada?
Por eso recomendamos revisar periódicamente el perímetro.
Indicadores SonicWall: TZ270 y TZ370 como primera capa
SonicWall TZ270 y TZ370 pueden actuar como una capa importante dentro de una estrategia de seguridad.
Permiten aplicar:
- reglas;
- segmentación;
- control de tráfico;
- VPN;
- inspección;
- generación de logs.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
Sin embargo:
instalar un firewall no es el final del trabajo.
Firewall instalado frente a firewall monitorizado
Existe una diferencia importante entre:
Firewall instalado
Se configura.
Se deja funcionando.
Solo se revisa cuando aparece un problema.
Firewall administrado
Se revisan:
- reglas;
- firmware;
- VPN;
- usuarios;
- logs;
- exposición;
- alertas.
Y existe un tercer nivel:
Firewall integrado con SIEM y SOC
Los eventos pueden relacionarse con:
- endpoints;
- servidores;
- Microsoft 365;
- red.
Ese contexto permite investigaciones mucho más completas.
Indicadores SonicWall y SIEM Wazuh
Nuestro servicio integra la telemetría del perímetro dentro del SIEM Wazuh para empresas.
Dependiendo de cada infraestructura podemos correlacionar información procedente de:
🔥 SonicWall
📡 UniFi
💻 Windows
🍎 macOS
🐧 Linux
🖥️ servidores
💾 NAS
☁️ Microsoft 365
🛡️ Endpoint / antivirus
De esta forma evitamos analizar el firewall como:
una isla.
Indicadores SonicWall: una conexión puede necesitar contexto del servidor
Imagine que SonicWall registra un posible escaneo.
Por sí solo sabemos:
qué ocurrió en el perímetro.
Sin embargo, podemos comprobar posteriormente:
Servidor → ¿hubo conexión aceptada?
Endpoint → ¿apareció un proceso extraño?
Sistema → ¿se produjo autenticación?
Firewall → ¿existió tráfico posterior?
Eso permite construir una secuencia.
Correlaciones personalizadas para cada empresa
No todas las infraestructuras requieren las mismas reglas.
Por ejemplo, si una empresa no publica ningún servicio:
cualquier acceso entrante permitido puede resultar especialmente relevante.
Sin embargo, una empresa con:
- VPN;
- web;
- correo;
tendrá un patrón diferente.
Por eso desarrollamos:
correlaciones adaptadas a cada infraestructura.
Indicadores SonicWall: detección no significa bloqueo
Este punto merece aparecer claramente en cualquier informe de seguridad.
Existen tres conceptos diferentes:
Detección
El sistema identifica un patrón.
Bloqueo
El sistema confirma que ha impedido la comunicación.
Compromiso
Existe evidencia de que un sistema ha sido afectado.
No son equivalentes.
Por tanto:
detección ≠ bloqueo ≠ compromiso.
¿Qué hacemos cuando no podemos confirmar el bloqueo?
Analizamos.
Por ejemplo:
- identificamos el evento;
- comprobamos la acción;
- revisamos destino;
- analizamos servicios publicados;
- buscamos actividad relacionada;
- correlacionamos otras fuentes.
Después podemos determinar si:
- no existía exposición;
- la regla rechazó posteriormente;
- el servicio respondió;
- se necesita investigación adicional.
Indicadores SonicWall y hasta 400 días de histórico
¿Qué ocurre si dentro de varios meses descubrimos una nueva campaña?
Podemos necesitar responder:
¿esa infraestructura contactó anteriormente con nosotros?
Por eso nuestro servicio de SIEM puede conservar hasta 400 días de histórico de logs de las fuentes integradas.
Esto permite:
- investigación retrospectiva;
- auditorías;
- threat hunting;
- análisis forense.
El histórico cambia una investigación
Imagine que hoy aparece un nuevo indicador.
Podemos preguntar:
¿lo vimos hace seis meses?
Si conservamos siete días:
no podremos saberlo.
Con un histórico amplio podemos buscar:
- conexiones;
- autenticaciones;
- sistemas;
- patrones.
Eso aporta una ventaja importante durante incidentes descubiertos tardíamente.
Indicadores SonicWall: no queremos miles de alertas sin contexto
Un firewall puede generar una enorme cantidad de información.
El objetivo no debería ser enviar al cliente:
cada línea del log.
Eso genera:
ruido.
Nuestro trabajo consiste en:
centralizar
↓
correlacionar
↓
priorizar
↓
analizar
↓
comunicar
De esta forma el cliente recibe información útil y no simplemente un contador de eventos.
SIEM automatiza, SOC interpreta
Wazuh puede ayudarnos a:
- centralizar;
- normalizar;
- correlacionar;
- almacenar.
Sin embargo:
nuestro SOC analiza el contexto.
Por ejemplo:
un origen cloud puede generar una alerta.
El SIEM puede detectarla.
Después el SOC comprueba:
- qué proveedor existe detrás;
- qué actividad realizó;
- qué servicio alcanzó;
- si se relaciona con otros eventos.
Indicadores SonicWall: recomendaciones para empresas
A partir de las detecciones de esta semana podemos extraer varias recomendaciones prácticas.
Revisar servicios publicados
Eliminar aquellos que ya no sean necesarios.
Revisar reglas NAT
Especialmente configuraciones antiguas.
Evitar RDP directamente en Internet
Utilizar VPN y controles adecuados.
Actualizar firmware
Mantener los dispositivos dentro de versiones soportadas.
Revisar usuarios VPN
Eliminar cuentas antiguas.
Implementar MFA
Cuando la tecnología utilizada lo permita.
Centralizar logs
Evitar que toda la evidencia quede solamente en cada dispositivo.
Correlacionar
Relacionar firewall con servidores, endpoints y cloud.
Indicadores SonicWall: semana 39 en cifras
El resumen semanal queda así:
🔥 1.637 indicadores analizados
🛡️ SonicWall TZ270 y TZ370
🔎 Port Scan Possible
📧 SMTP Server on RBL Blacklist
🌍 actividad asociada a infraestructuras de Europa, Norteamérica, Australia y Asia
☁️ presencia de redes relacionadas con proveedores cloud, hosting y datacenter
📊 integración con SIEM Wazuh
🔗 correlaciones personalizadas
🔎 análisis realizado por nuestro SOC
🗄️ hasta 400 días de histórico de logs
Y, de nuevo:
1.637 indicadores no significan 1.637 ataques confirmados.
Indicadores SonicWall: conclusión de la semana 39
Durante la semana 39 de 2026, nuestro SOC analizó 1.637 indicadores SonicWall generados por firewalls TZ270 y TZ370 desplegados en diferentes entornos profesionales.
Las principales categorías fueron:
Port Scan Possible
y:
SMTP Server on RBL Blacklist.
En los datos revisados aparece infraestructura relacionada con distintos proveedores de cloud y hosting, entre ellos Microsoft, DigitalOcean, IONOS, UCloud, DataCamp/CDNext y otras redes de datacenter. IPIP Whois
Además, la geolocalización asociada a la infraestructura analizada es diversa, con presencia en Europa, Norteamérica, Australia y Asia.
Sin embargo:
el proveedor no es el atacante
y:
el país de la IP no identifica al atacante.
Es información que utilizamos para añadir contexto a cada investigación.
Igualmente:
Port Scan Possible no significa intrusión
y:
SMTP Server on RBL Blacklist no significa automáticamente malware.
El valor aparece cuando relacionamos:
detección + acción + destino + servicio + comportamiento posterior.
Por eso nuestro enfoque combina:
🔥 SonicWall, que detecta y registra
📊 Wazuh, que centraliza y correlaciona
🔎 nuestro SOC, que analiza el contexto
🗄️ hasta 400 días de logs, que permiten investigar retrospectivamente
Puede conocer nuestras soluciones de ciberseguridad para empresas o nuestro servicio de SIEM Wazuh para empresas.
Porque disponer de un firewall es importante.
Pero conocer:
qué está detectando, qué exposición existe y qué ocurrió después
es lo que convierte sus logs en información útil para proteger una empresa.
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores SonicWall
¿Cuántos indicadores SonicWall se analizaron durante la semana 39?
Nuestro SOC analizó 1.637 indicadores procedentes de SonicWall TZ270 y TZ370.
¿1.637 indicadores significan 1.637 ataques?
No. Son eventos o indicadores registrados por los firewalls que posteriormente necesitan contexto y análisis.
¿Qué detecciones destacaron durante la semana?
Principalmente Port Scan Possible y SMTP Server on RBL Blacklist.
¿Qué significa Port Scan Possible?
Indica un patrón compatible con un posible escaneo de puertos para descubrir servicios disponibles.
¿Un Port Scan Possible significa que han entrado en la empresa?
No. Un escaneo no implica compromiso.
¿SonicWall bloquea siempre un Port Scan Possible?
No debería darse por hecho. Hay que revisar la acción concreta registrada en cada evento.
¿Qué hacemos si no aparece como bloqueado?
Revisamos puertos, reglas, NAT, servicios publicados, destino y actividad posterior.
¿Qué significa SMTP Server on RBL Blacklist?
Indica que un servidor SMTP relacionado con una comunicación aparece en una lista de reputación o bloqueo.
¿Significa que ese servidor tiene malware?
No necesariamente. Puede relacionarse con spam, reputación, infraestructura compartida o actividad anterior.
¿Qué países aparecen relacionados con la actividad?
Las fuentes analizadas muestran infraestructura asociada a diferentes zonas de Europa, Norteamérica, Australia y Asia.
¿El país de una IP identifica al atacante?
No. La IP puede pertenecer a un VPS, VPN, proxy, cloud o servidor comprometido.
¿Se observaron proveedores cloud?
Sí. Entre las redes verificadas aparecen Microsoft, DigitalOcean, IONOS, UCloud, DataCamp/CDNext y otras infraestructuras de hosting. IPIP Whois
¿Significa que esos proveedores están atacando?
No. El proveedor proporciona infraestructura; no debe confundirse con quien la está utilizando.
¿Por qué GHM no publica las IP analizadas?
Porque el objetivo del informe público es mostrar patrones, tipos de eventos y contexto sin divulgar innecesariamente los indicadores técnicos concretos.
¿Qué sectores utilizan estos SonicWall?
Entre otros, administraciones de fincas, asesorías, despachos jurídicos, arquitectura, interiorismo, construcción, ingeniería y despachos profesionales.
¿Qué aporta integrar SonicWall con Wazuh?
Permite centralizar los logs y relacionarlos con eventos de servidores, endpoints, Microsoft 365 y otras fuentes.
¿Qué aporta el SOC?
Nuestro SOC analiza los logs y su contexto para determinar si una detección necesita investigación o actuación.
¿Qué son las correlaciones personalizadas?
Son relaciones entre diferentes eventos diseñadas teniendo en cuenta cómo funciona cada infraestructura.
¿Cuánto histórico puede conservarse?
Nuestro servicio puede conservar hasta 400 días de logs de las fuentes integradas.
¿Por qué conservar 400 días?
Porque un incidente o un nuevo indicador puede descubrirse meses después y ser necesario investigar retrospectivamente.
¿Cuál es la principal conclusión de los indicadores SonicWall de la semana 39?
El valor del firewall no está únicamente en detectar actividad, sino en poder determinar qué ocurrió, si existía exposición, qué acción se aplicó y si hubo actividad relacionada posteriormente.
