Blog / Ciberseguridad / La auténtica Ciber Resiliencia
Escrito por Luis Miguel Acosta el 06 de Junio de 2022
Comencé mi carrera profesional como ingeniero/analista de ciberseguridad y parte del trabajo consistía en desplegar, customizar y operar tecnologías de ciberseguridad como mecanismos de protección, así como analizar los eventos de seguridad generados por estos para identificar y contener amenazas reales. La tarea de detección de amenazas se convirtió eventualmente en mi parte favorita ya que era bastante divertida, pero al mismo tiempo muy retadora. Como seguramente saben muchos de ustedes, identificar las amenazas relevantes se siente muchas veces como buscar una aguja en un pajar.
La tarea de operaciones de ciberseguridad era abrumadora y hoy, 12 años después, todavía lo es. Muchas organizaciones “se llenan” de herramientas de seguridad en lugar de enfocarse en construir una arquitectura de seguridad.
Esto al pasar el tiempo se transforma en complejidad: pequeños equipos de ingeniería y análisis navegando en un mar de consolas, logs y eventos de seguridad a los que de alguna forma deben darles sentido, analizar y correlacionar con la esperanza de encontrar las amenazas relevantes, amenazas que representen una potencial o real brecha de seguridad; eventos que sean significativos para la organización en cuestión, aquellos con la capacidad de causar un impacto negativo.
Hacer que un evento de seguridad disparado por un IPS tenga sentido para una organización en particular es fundamental para reducir dos métricas de seguridad clave: el TTD (tiempo de detección por sus siglas en inglés) y el TTR (tiempo de respuesta por sus siglas en inglés). Darle sentido a un evento de seguridad implica correlacionar el evento contra una amenaza asociada a una vulnerabilidad que puede o no existir dentro de algún elemento de la organización. Tanto el TTD como el TTR son métricas cruciales en una estrategia de ciberseguridad ya que mientras menos tiempo nos tome identificar que algo “está mal” y mientras menos tiempo nos tome contener y remediar el incidente menor será el impacto resultante.
Las IPS (Intrusion Prevention Systems) son una de las tecnologías de seguridad más antiguas, pero no por eso obsoletas, incluso con la creciente adopción de modelos de nube pública y privada, la inspección del tráfico de red para detectar y bloquear tráfico malicioso es todavía una de las capacidades de seguridad más importantes dentro de una arquitectura de seguridad. Tal es el caso, que la mayoría de los fabricantes de estas tecnologías ofrecen actualmente una opción virtual específicamente para ambientes de nube pública o privada e incluso ofrecen la capacidad de IPS como servicio entregado de forma nativa desde la nube (alineado hacia un modelo SASE).
FTD (Firewall Threat Defense) es el nombre actual (el cual ha cambiado varias veces en el transcurso del tiempo) del Firewall de siguiente generación/IPS de Cisco y tiene su origen en una tecnología legendaria, Sourcefire, una compañía adquirida por Cisco en 2013.
En mi opinión FTD no solo es una gran tecnología por sus características y capacidades de detección, sino que también es una solución que facilita la vida de muchos equipos de ciberseguridad en muchas organizaciones alrededor del mundo.
Un error muy común es que muchas organizaciones y equipos de seguridad tienen la creencia de que basta con colocar el IPS en la red y dejarlo hacer su trabajo. Se les olvida que los eventos de seguridad que este genere deben ser investigados puesto que un evento de seguridad, aún si ha sido bloqueado por el IPS, puede ser tan solo la punta del iceberg. Un evento de seguridad podría ser un indicador de un ataque a gran escala o de mayor impacto está ocurriendo, incluso podría ser un indicador de que existe ya una brecha de seguridad.
Recuerdo como en mi época como ingeniero de seguridad solía mirar en la pantalla múltiples eventos de seguridad en una consola gráfica de múltiples IPS y utilizaba un algoritmo que seguramente muchos de ustedes conocen y han utilizado para identificar los eventos significativos y darles prioridad a mis investigaciones. El algoritmo básicamente consiste en organizar los eventos de seguridad en un periodo de tiempo con base en su severidad y así comenzar a trabajar primero en aquellos de severidad crítica, continuar con los de severidad alta, después los de severidad media y así sucesivamente.
Este método, como podrás imaginarte, no escala tan bien. Durante aquellos días solía sentirme afortunado si durante mi jornada laboral completaba la investigación de tan solo los eventos con severidad crítica; además, utilizar este método es frustrante porque no te garantiza que vas a utilizar tu tiempo investigando eventos de seguridad que realmente son importantes para tu red o para tu organización. Esto se debe a que la severidad de un evento de IPS es una característica intrínseca en él y que tiene que ver principalmente con la naturaleza del ataque, la vulnerabilidad o la amenaza asociada con la firma de IPS que disparó el evento, la severidad no toma en cuenta las características específicas del ambiente o de la red que ese sensor IPS está tratando de proteger.
Muchas veces me encontré investigando lo que parecía ser un evento de seguridad crítico tan solo para darme cuenta, en muchos casos, después de varias horas de trabajo, que ese evento no tenía ningún impacto en mi ambiente. ¿Por qué un evento de IPS con severidad crítica podría no tener relevancia para una red en específico? Imaginemos que el IPS reporta un evento de seguridad relacionado con la detección de tráfico con la intención de explotar una vulnerabilidad crítica en MS-SQL y dicho evento está dirigido al segmento de red donde se encuentran los servidores de bases de datos donde además sabemos que en efecto MS-SQL es el principal DBMS utilizado por la organización, sin embargo, el destino específico para este evento era de un servidor CentOS corriendo MySQL como DBMS. En este ejemplo, aun cuando el evento de IPS reporta una severidad crítica, el hecho de que el host destino no sea vulnerable hace que este evento crítico, en particular no tenga impacto al menos para ese host en esta red en esta organización.
Evitar malgastar el tiempo investigando eventos de seguridad irrelevantes o sin impacto para nuestra red es crucial para poder invertir el tiempo valioso en aquellos eventos que realmente podrían causar algún daño. Esta es una de las características donde brilla Firepower Threat Defense (FTD).
FTD cuenta de forma nativa con un motor de descubrimiento de red que de forma automática genera un mapa con los perfiles de los hosts que viven en la red que el sensor se encuentra protegiendo. Los perfiles de host incluyen información tal como: el historial de usuarios de LDAP asociados con el host, los protocolos y servicios que están siendo utilizados por el host, los puertos en los que el host está escuchando, el tipo y versión del sistema operativo y las aplicaciones que están corriendo en cada host. Esta última, le da la habilidad a FTD de inferir las vulnerabilidades existentes en cada host de la red. Por defecto, el descubrimiento de red ocurre de forma pasiva al analizar el tráfico que pasa a través del sensor FTD, sin embargo, el descubrimiento puede realizarse de forma activa utilizando un motor de Nmap (la herramienta de descubrimiento de red más utilizada) incluido en FTD o a través de la integración con diversos escáneres de vulnerabilidades.
Con esta visibilidad de la red que protege, FTD resuelve el problema de la priorización de una forma muy elegante al presentar todos los eventos de seguridad no solo con su severidad intrínseca sino también con un valor de impacto asignado de forma dinámica, este valor de impacto se construye a través de la correlación entre la naturaleza del evento y el conocimiento que tiene FTD de la red, los hosts dentro de ella y sus vulnerabilidades. Como resultado, la bandera de impacto que FTD asigna a cada evento de seguridad que reporta, representa el impacto real que podría tener ese evento en esa red y en esa organización en particular. De esta forma el ingeniero o analista de ciberseguridad puede enfocarse en aquellos eventos realmente importantes.
Muchas veces me he encontrado con organizaciones que piensan que una buena solución IPS es aquella que puede empezar a proteger una red desde el momento en el que la sacamos de la caja, sin necesidad de configuración avanzada o customización. Esto obedece al hecho de que la mayoría de los equipos de seguridad están sobrecargados de trabajo y responsabilidades, eso los lleva a solicitar soluciones simples, sin embargo, es justo decir que no existe tal cosa como un IPS unitalla que permita proteger a cualquier organización con una política “estandarizada”.
La customización es una característica fundamental para una tecnología IPS, en particular, la customización de la política de detección que regirá que tipo de tráfico deberá ser bloqueado. Esta customización permitirá reducir la cantidad de falsos positivos, reducir la cantidad de falsos negativos (algo que no deseamos en lo absoluto) y optimizar los recursos de cómputo del IPS.
La customización de un IPS tiene su encanto y no es precisamente algo sencillo, sin embargo, FTD hace de la customización algo bastante sencillo.
Por un lado, FTD le proporciona a un administrador control total de la customización tanto de las firmas de detección, las políticas, los umbrales y las variables. A través de un elemento de configuración dentro de las políticas llamado “variable set” que no es más que un conjunto de variables, el administrador puede especificar las características de la red que un sensor estará protegiendo de manera que las firmas del IPS hagan sentido para esa red en particular. Por otro lado, si un administrador no tiene experiencia o la menor idea de lo que está haciendo al customizar una política de IPS, FTD puede ayudarle de forma automática a customizarla, una vez más, gracias al descubrimiento de red y los perfiles de hosts resultantes.
FTD utiliza la visibilidad obtenida a través del descubrimiento de la red para generar algo llamado “Firepower recommendations” que son modificaciones customizadas al conjunto de reglas y firmas que definirán la política de IPS, estas modificaciones estarán basadas en las vulnerabilidades que existen en la red que FTD está protegiendo. Básicamente, FTD tiene la habilidad de customizarse a si mismo dependiendo de la red que se encuentre protegiendo. Esta simplicidad y eficiencia se traduce en eficacia y ciber resiliencia.
Muchas organizaciones tienen el presupuesto para implementar centros de operaciones de seguridad que permitan mantener las capacidades de análisis y detección de amenazas funcionando 24/7, desafortunadamente, esa no es la realidad de la mayoría.
Estas últimas solo pueden permitirse contar con equipos de trabajo en horario laboral de lunes a viernes dejando así una ventana abierta de alrededor de 16 horas cada día.
Anteriormente mencioné cuán importante es no solo confiar en que el IPS bloqueará el tráfico malicioso y toda la actividad maliciosa en la red sino tener la capacidad de investigar estos eventos para llegar al fondo de la actividad maliciosa y poder realmente prevenir una brecha de seguridad. ¿Qué sucede entonces cuando un evento de seguridad relacionado con un ataque importante ocurre en un sábado por la noche cuando no hay nadie que pueda investigarlo? En este escenario, probablemente la investigación demoraría hasta la mañana del lunes y eso si el evento reportado no se pierde dentro de un mar de logs y otros eventos.
Este escenario describe una situación que sufren muchas organizaciones en el mundo real, una situación que coloca a estas organizaciones en un riesgo de seguridad elevado ya que al incrementarse el tiempo de respuesta (TTR) se agravia el potencial impacto resultante del incidente.
FTD cuenta con una característica que permite resolver este problema: las reglas de correlación (correlation rules). Con la configuración de reglas de correlación es posible definir acciones que serán disparadas de forma automática ante la ocurrencia de un evento en específico.
El disparador de la regla de correlación podría ser prácticamente cualquier tipo de evento de seguridad tal como un evento de detección de malware o un evento de IPS con bandera de impacto crítica. De manera similar, la acción de respuesta puede ser algo tan simple como una notificación por correo electrónico (que con algo de suerte despertará al ingeniero de seguridad “on-call”) o algo un poco más elaborado como podría ser la ejecución de un escaneo de Nmap o la inyección de una ruta “blackhole” en un ruteador de manera que el tráfico malicioso sea descartado a nivel de ruteo.
Más allá, FTD cuenta con una integración nativa con Cisco ISE, la tecnología de Cisco para el control de acceso a la red y AAA basado en identidades, a través de un protocolo abierto llamado pxGrid. Como paréntesis, vale la pena señalar que las capacidades de integración son una característica que definen a una arquitectura de seguridad. Esta integración permite habilitar una capacidad llamada “Rapid Threat Containment” que en términos simples significa que FTD puede disparar de forma automática una acción de “adaptive network control” en ISE para que este último ponga en cuarentena o expulse de la red a aquel dispositivo que este generando algún tipo de comportamiento o tráfico malicioso detectado por FTD.
Una acción de “Rapid Threat Containment” donde el dispositivo ofensor sea puesto en cuarentena ante la detección de algún comportamiento malicioso abre la puerta para que, en un escenario como el del ejemplo, la investigación pudiera ser retrasada siendo que la amenaza ha sido ya contenida de forma automática y sin ninguna interacción por parte del administrador o del ingeniero de seguridad.
Una capacidad de automatización como “Rapid Threat Containment” es justo a lo que aspiramos cuando hablamos de resiliencia en ciberseguridad: tener la capacidad de aguantar un evento adverso y emerger más fuertes que nunca.