Capacidades mínimas de detección sin SOC dedicado: lo que la infraestructura que ya tienes puede hacer

TÉCNICO-GERENCIAL · DETECCIÓN · CAPACIDADES MÍNIMAS

Las capacidades de detección mínima viable están en las herramientas que la mayoría de las organizaciones medianas ya tienen. La brecha no es tecnológica: es de configuración y proceso.

Ayer planteé que la diferencia entre tener logs y tener detección no es tecnológica sino de proceso. Hoy quiero ir al nivel concreto: qué capacidades de detección son alcanzables para una organización mediana que no tiene un SOC dedicado, con la infraestructura que probablemente ya tiene instalada y sin inversión adicional significativa.

La respuesta es más alentadora de lo que parece. Las herramientas nativas de Fortinet, Cisco y Azure tienen capacidades de detección y correlación que la mayoría de las organizaciones medianas de la región no están usando porque nunca las configuraron explícitamente.

LO QUE FORTINET PERMITE SIN INVERSIÓN ADICIONAL

FortiAnalyzer, que acompaña a la mayoría de las implementaciones de FortiGate en organizaciones medianas, es una herramienta de correlación y análisis de logs que en muchos casos está instalada pero subutilizada. Su función no es solo almacenar logs del firewall: puede correlacionar eventos de múltiples FortiGates, generar alertas basadas en umbrales configurables, y producir reportes de comportamiento de red que permiten identificar patrones anómalos.

Con una configuración básica orientada a seguridad, FortiAnalyzer puede alertar sobre picos de tráfico saliente inusuales, intentos de conexión a destinos categorizados como maliciosos por FortiGuard, intentos de autenticación fallidos repetidos, y cambios de configuración en los FortiGates gestionados. Ninguna de esas capacidades requiere licencias adicionales si ya se tiene FortiAnalyzer en la infraestructura: requieren configuración activa por parte del equipo.

El FortiGate también tiene capacidades de IPS y detección de anomalías que con frecuencia están habilitadas pero con políticas por defecto que no están optimizadas para el entorno específico de la organización. Revisar y ajustar esas políticas es trabajo de horas, no de semanas, y puede mejorar significativamente la capacidad de detección perimetral.

LO QUE CISCO PERMITE EN LA INFRAESTRUCTURA EXISTENTE

El switching Cisco, presente en el core y las sucursales de la mayoría de las organizaciones medianas de la región, tiene capacidades de visibilidad de red que pocas organizaciones usan activamente. Syslog envía eventos de los switches a un servidor central, incluyendo cambios de estado de puertos, intentos de acceso a la consola de gestión, y eventos de spanning tree que pueden indicar actividad anómala. NetFlow, disponible en switches y routers Cisco, genera información de flujo de tráfico que permite identificar anomalías de volumen y destino sin necesidad de inspeccionar el contenido del tráfico.

Configurar el envío de Syslog de la infraestructura Cisco hacia FortiAnalyzer, si este ya está en el entorno, permite centralizar la visibilidad de red en una sola herramienta. Esa integración no requiere licencias adicionales en la mayoría de los casos: requiere configuración de ambos lados.

LO QUE AZURE INCLUYE EN LA SUSCRIPCIÓN BASE

Para las organizaciones que tienen entorno Azure, como TechCorp Latam después del incidente, hay capacidades de detección incluidas en la suscripción base que con frecuencia no están activamente configuradas. El Activity Log de Azure registra todas las operaciones sobre los recursos del entorno: quién creó un recurso, quién cambió una configuración, quién eliminó algo. Las alertas de Activity Log permiten recibir notificación inmediata cuando ocurren eventos específicos, como la creación de una nueva cuenta con privilegios de administrador o la modificación de reglas de red.

Entra ID, el directorio de identidades de Azure, genera Sign-in Logs que muestran cada autenticación: desde qué ubicación, desde qué dispositivo, con qué resultado. Microsoft Defender for Cloud, en su nivel gratuito, genera recomendaciones de seguridad y algunas alertas básicas sobre configuraciones de riesgo. Ninguna de estas capacidades requiere licencias premium en su nivel básico: requieren que alguien las habilite y configure las alertas que importan.

ERROR COMÚN

Habilitar todas las alertas disponibles en las herramientas de detección con la lógica de "más es mejor." El resultado es exactamente el problema del que hablé ayer: fatiga de alertas que hace que todas se ignoren. El punto de partida correcto es configurar un conjunto pequeño de alertas de alta señal, las que corresponden a comportamientos que casi nunca son legítimos en el entorno específico, y asegurarse de que esas alertas tengan un proceso de respuesta claro antes de agregar más.

LAS 5 ALERTAS QUE TODA ORGANIZACIÓN DEBERÍA TENER ACTIVAS

Si el punto de partida es cero alertas activas, hay cinco que tienen alta señal sobre ruido y cubren los vectores de ataque más frecuentes en organizaciones medianas.

La primera es autenticaciones fallidas masivas en un período corto: cientos o miles de intentos en minutos desde una misma IP o hacia un mismo usuario. Es el indicador más claro de un ataque de fuerza bruta o de credential stuffing. FortiAnalyzer y Azure Entra ID tienen esta capacidad nativa.

La segunda es acceso administrativo a sistemas críticos fuera del horario laboral habitual. Un administrador de dominio que se autentica a las 3 de la mañana de un martes es una señal que merece verificación, sea legítima o no. El horario de referencia requiere definirse para el entorno específico.

La tercera es tráfico saliente inusual en volumen o hacia destinos no habituales. La exfiltración de datos suele generar picos de tráfico saliente que el comportamiento normal no explica. FortiGate con FortiAnalyzer y el Activity Log de Azure permiten detectar esta anomalía.

La cuarta es la creación o modificación de cuentas con privilegios elevados, especialmente fuera de los procesos normales de gestión de identidades. En entornos on-premise, un evento de creación de cuenta en el grupo Domain Admins que no fue solicitado por el proceso formal es una señal crítica. En Azure, la asignación del rol Owner a una cuenta nueva merece atención inmediata.

La quinta es el movimiento lateral entre segmentos de red que según la arquitectura no debería ocurrir. Si la red está segmentada entre el área administrativa y los servidores de producción, tráfico iniciado desde un equipo del área administrativa hacia un servidor de producción en puertos de administración es una señal de posible movimiento lateral.

DECISIÓN QUE DEBE TOMAR EL CIO

Verificar cuáles de estas cinco alertas están actualmente configuradas en el entorno. Para las que no están, asignar la tarea de configurarlas en FortiAnalyzer, en los sistemas Cisco y en Azure según corresponda. El trabajo de configuración de las cinco alertas básicas no debería tomar más de dos o tres días a alguien familiarizado con las herramientas. Lo que sí requiere definirse antes de configurar las alertas es quién recibe cada una y qué hace cuando llega.

La brecha de detección en organizaciones medianas no es principalmente una brecha de herramientas. Es una brecha de configuración y proceso sobre las herramientas que ya existen. Mañana voy a ver la segunda parte de esa ecuación: cómo construir el proceso de respuesta básico que hace que las alertas produzcan acción.

Artículo núcleo de la semana en el blog. Mañana: proceso básico de respuesta a incidentes con el equipo existente.

#DetecciónDeIncidentes #IncidentResponse #Fortinet #FortiAnalyzer #Cisco #Azure #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #SOC #NISTCSF #ISO27001