Evitar ataques APT con sistemas SWG, SEG y ATD ( y III)

 

En la primera parte expusimos algunos conceptos generales que ayudan a comprender cómo debe ser la defensa ante ataques APT. En la segunda se expusieron soluciones para el servicio web. En esta tercera veremos los Secure Email Gateway (SEG) y Advanced Threat Defense (ATD). De esta forma se completa el panorama de sistemas antiAPT.

Secure Email Gateway, SEG

Las pasarelas de correo seguro, SEG son dispositivos que además de proporcionar funciones básicas del agente de transferencia de correo MTA (Mail Transfer Agent), añaden motores para analizar en profundidad el correo.

 Definción de SEG según Gartner

 

El SEG no es un firewall, ni un servidor de correo, no sustituye a estos equipos y la organización debe mantener estos dispositivos debidamente configurados.

Para describir el funcionamiento del SEG en la red hay que convenir el sentido de los mensajes de correo. Desde el punto de vista de la organización, los mensajes entrantes son aquellos que se reciben desde fuera de la organización y mensajes salientes aquellos que se envían fuera de la misma como se muestra en la figura 1.

Figura 1. Sentido de los mensajes de correo.

Las tareas de la administración del equipo, tanto para el SEG como el SWG que hemos tratado anteriormente, se dividen en dos conjuntos. Las que gestionan al propio dispositivo como elemento (físico o virtual) o en la nube y las que gestionan las funciones de seguridad. Entre las primeras se encuentra configuración del puerto de acceso, permisos, contraseñas, actualizaciones y versiones del software, licenciamiento, ficheros logs, etc. Dedicamos los siguientes apartados a la gestión de la seguridad.

Arquitectura de la red

Al igual que el SWG, el SEG tiene diferentes formas de conectarse a la red e implica que el dispositivo se configure en diferentes modos.

Modo Switch. El equipo actúa como switch ethernet. En esta arquitectura el servidor de correo externo se comunica con el servidor interno corporativo directamente, como si no existiese el SEG intercalado. Los mensajes son interceptados y analizados por el SEG antes de ser liberados al servidor de correo corporativo. El SEG conecta dos segmentos físicos de red como un bridge, ambos segmentos pertenecen a la misma subred lógica. Los otros equipos como los clientes corporativos, firewall, servidores NAT, servidores de registro de intercambio de correo (registro MX) etc, pertenecen a la misma subred y tienen su propia configuración de dirección IP y máscaras. La configuración de este modo en el SEG es muy sencilla. En el ejemplo de la figura el SEG sólo actúa como bridge entre el router y el firewall.

 Figura 2. Modo Switch

Modo Router. El equipo actúa como un router. Intercepta el tráfico de correo electrónico entre dos subredes distintas. El tráfico que recibe por una red es analizado y reenviado al siguiente equipo situado en una red diferente, según unas tablas de enrutamiento incluidas en el mismo.

Un interfaz tiene una dirección IP para el tráfico analizado entrante y otra interfaz con IP diferente para el tráfico saliente. El funcionamiento del SEG es transparente a los servidores de correo.

El equipo debe situarse junto al firewall en el lado interno de la organización porque puede sustituir al router en la red.  

Figura 3. Modo Router

Los clientes tienen la dirección del “default gateway” a un puerto del SEG. El SEG tiene su dirección “default gateway” hacia la ruta de Internet. Los usuarios deben liberar mensajes corporativos dentro de la intranet de la organización sin salir al exterior.

Modo Servidor Proxy. Los dispositivos de red deben configurarse explícitamente para enviar tráfico al SEG. Luego, el SEG funciona como un proxy o retransmisor, procesando el tráfico en nombre de los dispositivos conectados.

Se debe configurar el servidor de correo interno para retransmitir el tráfico de correo electrónico al SEG. El SEG analiza el tráfico de correo electrónico antes de reenviarlo, en nombre del remitente, al servidor de correo externo. El servidor de correo externo reenvía el correo electrónico al receptor. De forma similar, la red debe estar configurada para que los correos electrónicos entrantes de Internet se entreguen en el SEG y no al servidor de correo interno.

El SEG analiza el tráfico antes de reenviarlo, en nombre del remitente, al servidor de correo interno para su entrega. Por ejemplo, un servidor de correo externo puede comunicarse directamente con el SEG, aunque el tráfico podría pasar a través de varios servidores de red antes de llegar al SEG. El camino percibido es desde el servidor de correo externo al SEG.

El modo de proxy explícito invalida las reglas de firewall configuradas para el acceso de los clientes a Internet. El firewall solo ve la información de la dirección IP física del SEG, no las direcciones IP de los clientes, por lo que el firewall no puede aplicar sus reglas de acceso a Internet a los clientes. Esto afecta a la configuración de los servidores externos del Sistema de Nombres de Dominio, DNS o NAT en el firewall para que el servidor de correo externo entregue el correo al SEG y no al correo interno servidor. En resumen, la configuración es más compleja y susceptible de no ser completamente correcta y por lo tanto más vulnerable.

 Figura 4. Modo Servidor Proxy

Gestión de la seguridad del correo

La gestión de la seguridad en el correo se centra en tres entornos. Dependiendo de las características de los productos de los fabricantes éstos pueden ser más o menos completos:

• Estado del propio dispositivo físico o virtual: información del sistema y de servicios adicionales del mismo.
• Estado general del tráfico de correo electrónico mediante indicadores del servicio de correo entrante y saliente.
• Detección y análisis del tráfico de correo, mensajes, adjuntos, malware, spam, etc.

La implantación de la seguridad en el SEG se realiza mediante la configuración de reglas similares a las vistas en el equipo anterior y no repetiré aquí.

Información del sistema

La información se extrae del funcionamiento del equipo y de la configuración que se haga del mismo. Se clasifica en los siguientes grupos de indicadores.

Información del Sistema. Destaca la siguiente:

• Entorno físico.
  

-    Temperatura interna, externa, de los procesadores, etc. Avisos de las variaciones.
-    Funcionamiento de los ventiladores.
-    Estado de la fuente de alimentación

• Rendimiento del sistema electrónico.
  

-    Rendimiento de los procesadores, porcentaje de utilización en periodos de tiempo determinados.
-    Disponibilidad de espacio en la memoria. Espacio ocupado y espacio libre.
-    Disponibilidad de espacio en el disco. Espacio ocupado y espacio libre.
-    Niveles de tensión y corriente en los distintos módulos del dispositivo.

• SAI (Sistema de Alimentación Ininterrumpida).

-    El SAI está o no activado.
-    Conexión del dispositivo a la red o a la batería.
-    Estado de la batería: en uso, cargando, descargando, etc.

• Estados de los discos de almacenamiento.
  

-    Estado del Sistema RAID. Discos en funcionamiento, fallos en los discos, degradación de la capacidad de los discos.

• Interfaces de red

-    Estado de los interfaces.
-    Velocidad de interfaz, datos transmitidos y recibidos, errores.
-    Tramas rechazadas y sus causas.
-    Estados de los protocolos de nivel de enlace y de red. Estado de las conexiones.

• Sistema redundante. si el dispositivo forma parte de un conjunto redundante, ofrece información del estado del equipo individual y del conjunto.

-    Estado del conjunto: activo, en espera, sin comunicación con el resto, etc.
-    Estado de la comunicación administrativa del conjunto.
-    Estado del balanceo de carga en periodos de tiempo.

Servicios adicionales del sistema. Se refiere a otros servicios adicionales que exigen conexión con otros equipos. Necesitan su propia configuración. Sin entrar en detalles destacar:

 
-    Estado de servicio SNMP para la gestión remota y el envío de eventos.
-    Estado de servicio Syslog para registro del sistema.
-    Estado de servicio NTP para mantener la sincronización con el resto de equipos de la red.
-    Estado de servicios de listas de reputación. Tanto para las locales como las externas: si están disponibles, actualizadas, descargadas, corruptas, etc.
-    Estado de servicios antimalware. Similar al anterior.
-    Estado de otros servicios propietarios

La evaluación de los indicadores nos mostrará en la ventana de monitorización unos mensajes con las acciones a tomar sobre los componentes o partes afectadas:

• Correcto: los elementos sobre los que se informa funcionan con normalidad.
• Requiere atención: se ha superado un umbral de advertencia y así se notifica.
• Requiere atención inmediata: se ha superado un umbral de advertencia crítico.

Los umbrales de advertencia y de alerta se configuran por los administradores. Cuando el elemento supere el umbral configurado, se activará un evento además de los mensajes anteriores. Este puede ser un correo al administrador, un mensaje log, un dato estadístico, etc.

Indicadores del Servicio de Correo

Los indicadores del servicio de correo entrante y saliente muestran un resumen de la entrega y estado de los mensajes recibidos en la organización y enviados desde ella. La clasificación es la siguiente:

• Número total de mensajes recibidos.

-    Mensajes recibidos a través de conexiones estándar
-    Mensajes recibidos a través de conexión no estándar. Mensajes cifrados a través de una conexión TLS o No-TLS. El contenido cifrado con Secure Web Mail, S/Mime, PGP u otros.

• Número total de mensajes enviados.

-    Mensajes enviados a través de conexiones estándar
-    Mensajes enviados a través de conexión no estándar. Mensajes cifrados a través de una conexión TLS o No-TLS. El contenido cifrado con Secure Web Mail, S/Mime, PGP u otros.

Cada mensaje recibido o enviado es interceptado y marcado con alguna de las siguientes etiquetas:

• Entregado
• Bloqueado
• Devuelto
• Análisis omitido
• En cola para análisis
• En cuarentena

La asignación de las etiquetas destinadas para analizar el correo o sus adjuntos forzarán la ejecución de las reglas que se hayan configurado para actuar en consecuencia en estos casos.

Análisis del correo

La seguridad del correo exige un análisis profundo y para ello se aplican sus reglas y motores de análisis. Los criterios de cumplimiento y validación permiten encontrar anomalías o desconfianza en la conexión, el remitente, el destinatario o el contenido del correo. El resultado es el bloqueo y la prohibición de la entrega a los destinatarios, mostrando en su lugar avisos de la circunstancia excepcional.

El análisis de los mensajes se realiza para los diferentes protocolos de correo y en sus diferentes partes: destinatario, remitente, copia, contenidos, adjuntos, firma, etc. Las reglas y los motores de análisis se configuran para cada caso.

Se puede clasificar:

• Mensajes bloqueados por la conexión o el remitente

-    Bloqueo por el remitente. Direcciones no deseadas inscritas en listas negras.
-    Aplicación del método basado en BATV (Bounce Address Tag Validation)
-    Verificaciones de la relación URL e IP basados en FCrDNS (Forward-Confirmed Reverse DNS) consultas inversas en registros PTR de los DNS que confirmen la relación directa e inversa entre la URL y la IP.
-    RBL (Real-time Blackhole List) o DNS RBL. Son listas negras con las direcciones y dominios de creadores de spam, pero también incluye a los proveedores de servicios que no eliminan o detienen este tipo de mensajes.
-    SPF (Sender Policy Framework). Listas que identifican servidores válidos de correo.

• Mensajes bloqueados por el destinatario

-    El destinatario no está permitido. Prohibido enviar mensaje.
-    Listas grises de destinatarios.
-    Retransmisión bloqueada

• Mensajes bloqueados por contenido

-    Listas negras de reputación de URL o dominios
-    Listas negras de contenidos.
-    Correos con firmas no autorizadas o sin firmar, según los mecanismos de DKIM (Domain Keys Identified Mail).
-    Detección de Spam. Actualizaciones de las listas de spam cuando los usuarios etiquetan como tal un correo recibido.
-    Detección de “phishing”: petición fraudulenta del nombre de usuario y su contraseña.
-    Filtrado de correo, por ejemplo, por tamaño.
-    Filtrado de archivos. Tipos de archivos no autorizados
-    Filtrado de imágenes.
-    Detección de malware.
-    Detección de Programas Potencialmente no Deseados PUP (Potentially Undesirable Programs) o Hacking Tools.
-    Reputación de URL donde se han producido ataques de denegación de servicio (DoS)
-    Data Loss Prevention, DLP, sistemas de prevención de pérdida o robo de ficheros clasificados.
-    Conformidad con la política de la empresa sobre el uso del correo electrónico corporativo.

• Mensajes devueltos.
• Mensajes que por algún criterio no fueron analizados.
• Mensajes en cuarentena.

Los indicadores de amenazas muestran indicios más o menos fiables de su presencia. A modo de resumen se clasifican según sus reglas de detección formando los siguientes grupos:

• Remitentes que podrían ser origen de spam
• Contenidos que albergarían ataque de phishing.
• Mensajes rechazados por tener tamaño excesivo.
• Imágenes inapropiadas o pornográficas.
• Posible presencia de malware.
• Programas potencialmente no deseados en el correo.
• Posibles contenidos de compresores.

Las clasificaciones pueden variar, sobre todo para aportar conocimiento del servicio de correo. Será más fácil localizar los agujeros de seguridad y la necesidad de ser reforzados.

Elaboración de informes

Una de las cualidades más importantes que debe tener los SEG o un SWG es la elaboración de informes útiles para la vigilancia del servicio.

Los informes se pueden generar localmente desde el propio SEG, o enviar los datos a otros equipos remotos que serán los encargados de crearles.

La capacidad de almacenamiento de datos para mostrar en los informes es un factor limitante sobre todo en el SEG local, por tal motivo, dependiendo del volumen de correo y los motores de análisis implementados, se hace necesario el uso de equipos externos.

Sistemas ATD

El concepto de “sandbox” inicialmente se empleó para verificar aplicaciones en un entorno Unix. Conceptualmente consiste en situar el programa bajo observación en un entorno aislado, sin interacciones de otros procesos y sin acceso al exterior, de este modo es más fácil manipular variables para analizar y verificar concienzudamente el funcionamiento del programa. Del uso en este entorno de desarrollo ha pasado al entorno de la seguridad, para comprobar la funcionalidad de una aplicación de dudosa confianza.

La virtualización ha facilitado que el concepto de sandbox amplíe su significado a cualquier entorno de prueba y desarrollo.

La Figura 5 muestra un ejemplo de análisis dinámico en un entorno virtual. En este caso, un programa se ha etiquetado como sospechoso por los diversos sistemas que conforman la cadena de protección. El programa sospechoso se descargó en un puerto USB desde un “pendrive”. Primero lo ha analizado el antivirus local del puesto de usuario, sin llegar a una conclusión. El programa se envía desde el puesto de usuario a servidores con listas locales más amplias, también cuentan con el apoyo de realizar consultas remotas, con mayor número de firmas de malware. Ante la incapacidad de ofrecer un resultado determinante, el fichero se traslada a al servidor ATD. En él se arranca el sistema operativo virtual idéntico al que tiene instalado el puesto de usuario que detectó el programa sospecho. En el entorno virtualizado se ejecuta el programa sospechoso y se analiza su comportamiento, incluso la posibilidad de acceso a la red para añadir más código malicioso. Si el resultado definitivo es que se trata de malware, sus características se incluirán en las listas de reputación, tanto locales como remotas, y sobre todo, el programa se bloquea en el puesto de usuario.
 

Figura 5. Esquema de un análisis en un entorno virtual

El sistema ATD debe tener todos los sistemas operativos de la compañía susceptibles de ser infectados por malware. Esto exige una gestión de los activos software muy rigurosa y actualizada.

El ataque de WannaCry de mayo de 2017 puso de manifiesto el problema que puede sobrevenir si las aplicaciones y programas no están puestos al día. El ataque aprovechó una vulnerabilidad conocida en el sistema operativo, pero que el fabricante Microsoft había solucionado en sus parches. Muchas compañías no habían actualizado sus sistemas operativos con la incorporación del parche. Por lo tanto, eran vulnerables. El “ransomware” se pudo ejecutar con el resultado de sobra conocido.

Esto también pone en evidencia la dificultad que supone para los administradores de sistemas mantener una buena gestión de las versiones software. Cada día aparecen fallos, arreglos, parches, paquetes, versiones de cualquier aplicación. Es difícil mantener una instalación estable que no altere el curso de las operaciones sin comprometer la seguridad. Aunque nos desviamos del tema, habrá que dejar este tema para otra ocasión.

Nuevo reto: eludir los análisis en entornos virtuales

Ahora nos cruzamos al lado oscuro: ¿cómo pueden los atacantes eludir los análisis en entornos virtuales? Vamos a responder en unas notas muy breves a este reto propuesto. 

Una manera de eludir este tipo de comprobaciones es que el código malware, cuando se descargue en el entorno virtual, ralentice su arranque. De esta forma transcurre el tiempo mientas que el código maligno se propaga, instala y se ejecuta en sus objetivos reales de la organización. Cuando el departamento de ciberseguridad concluya el análisis del entorno virtual puede que sea demasiado tarde y el malware se haya reubicado en los sistemas.

Otra técnica programada en el malware es que éste, antes de ejecutarse, pueda verificar si se encuentra confinado en un entorno virtual donde será descubierto; o, por el contrario, si se encuentra en el entorno abierto de la organización, como cabría esperar. El malware, para comprobar dónde está, realiza conexiones a través de los puertos abiertos de la red. Si consigue establecer comunicación con un servidor externo deducirá que no se encuentra en un entorno virtual, del cual, además podrá descargar código adicional para desarrollar el ataque. Cuando está en un entorno virtualizado, puede que éste no le permita establecer esa conexión al exterior. En este caso el malware se queda inactivo, tratando de pasar como confiable y pueda pasar el filtro. De esta forma puede alcanzar su objetivo.

Comprobamos como los ciberdelincuentes encuentran constantemente las estrategias para evitar se detectados por los sistemas más sofisticados y complejos de defensa, como los ATD. Todavía queda mucho por conocer de estos sistemas y las relaciones con otros. Habrá que dedicarles más tiempo en otra ocasión.

Conclusión

La dificultad de los equipos vistos reside en el ajuste de los análisis.

Cada nueva versión y modelo proporcionan nuevas funcionalidades que se integran o amplían con las existentes. En el portafolio de la empresa un año aparecen productos individuales y al año siguiente se venden integrados en uno único.

El cliente puede decidir cambiar aspectos de su negocio, modificar los servicios y la infraestructura TI. Estas situaciones alteran constantemente la arquitectura de seguridad que se diseñó originalmente. La revisión es continua, no sólo por los sofisticados ataques que ocurren cada día, las herramientas de seguridad mejoradas; sino que también, para adaptarse a los nuevos cambios que implementan los clientes. 

Referencias

CCN-CERT Centro Criptológico Nacional. “CCN-STIC-401 Glosario y Abreviaturas”.

Gartner Glossay La investigación y evaluación de productos que realiza Gartner debe ser la primera fuente de consulta para conocer aquellos que tienen más impacto tecnológico.

En la Sala de Lecturas, Reading Room, de SANS Institute se pueden leer los artículos más destacados sobre ciberseguridad.

Cisco Cyber Threat Defense.

McAfee Advanced Threat Defense

Fotografías y esquemas de L. F. Real. Iconos diseñados por Kameleon

L. F. Real

Evitar ataques APT con sistemas SWG, SEG y ATD (parte II)

 

En la primera parte expusimos algunos conceptos generales que ayudan a comprender cómo debe ser la defensa ante ataques APT. En las siguientes páginas vamos a conocer las soluciones tecnológicas para la seguridad del servicio web.

Secure Web Gateway, SWG

Según la definición en el glosario de Gartner: “Las pasarelas web seguras (SWG) utilizan filtros URL y malware conocido como defensa avanzada. Se utilizan para proteger a los usuarios de las amenazas transmitidas por Internet y para ayudar a las empresas a cumplir las políticas de uso de Internet. Los SWG se implementan como dispositivos locales, virtuales o físicos, o servicios basados en la nube; también es posible una combinación en local y en la nube denominada modo híbrido.” Pero Gartner concluye “Los proveedores continúan discrepando en el grado de madurez y las características de los servicios basados en la nube, y en su capacidad para proteger a las empresas de amenazas avanzadas.”

 

 Definición según Gartner

La función principal de SWG es interceptar y filtrar el tráfico web según las reglas que se configuren. Adicionalmente, algunos modelos de equipos pueden añadir otras funciones como autenticar usuarios mediante consultas internas o externas con diversos métodos como NTLM (NT-LAN Manager es un conjunto de protocolos de Microsoft), LDAP (Lightweight Directory Access Protocol), RADIUS (Remote Authentication Dial-In User Service), Kerberos, entre otros. De este modo se consigue el control administrativo de los usuarios sobre el mismo dispositivo que se controla el tráfico web.

La protección del tráfico web generalmente se basa en respuestas reactivas. Como se ha visto anteriormente, éstas son el resultado del uso de reglas estáticas. Las reglas más habituales son filtrar direcciones utilizando listas negras o listas blancas, y bloquear malware con antivirus basados en firmas. En estos casos hay que disponer de datos previos conocidos: las direcciones calificadas como maliciosas y las firmas del malware y virus detectados.

Los métodos reactivos no sirven para ataques “Día 0” o el surgimiento de nuevas URL dañinas. No obstante, los análisis estáticos son necesarios, pero deben ir acompañados de otras medidas de seguridad más avanzadas que puedan hacer frente a ataques complejos.

 

La incorporación de SWG en la red corporativa debe permitir el análisis de: 

Tráfico saliente. Solicitudes de páginas web iniciadas por el usuario.

• Aplicación de las políticas de la empresa para el acceso y uso de internet por los empleados.
• Si el tráfico a internet está permitido, entonces se emplean las siguientes técnicas de análisis.

-    En las solicitudes iniciadas por el usuario primero se aplica las políticas de uso de Internet de la empresa.

-    Consulta de las listas de reputación de URL, direcciones o dominios; en listas negras o blancas, tanto en bases de datos locales como remotas (llamada también globales) de servicios en la nube. Filtrado basado en categorías (páginas comerciales, juegos, apuestas, adultos, etc.)

-    Inspección de paquetes tráfico SSL (Secure Socket Layer), TLS (Transport Layer Security) y otras aplicaciones ocultas con el cifrado.

-    Análisis del contenido del tráfico generado por el usuario en todos los protocolos web principales, incluidos HTTP, HTTPS y FTP. 

-    Vigilancia de la pérdida de información confidencial, sensible o clasificada que se filtra desde la organización a las redes sociales, blogs, “wikis” o herramientas de productividad en red, como el correo, las agendas y los calendarios basados en la web.

-    Vigilancia que los datos no autorizados no puedan salir de la organización a través de equipos infectados por “bots” (reducción del plural de robots). Enviando información confidencial al atacante.

-    Ajuste continuo de las reglas para adaptar los filtros, las listas de reputación, los tipos de medios (video, audio, voz, etc.) y otras aplicaciones a las necesidades de la red de la organización.

Tráfico entrante. Incluye las respuestas a las solicitudes de los usuarios, así como las entradas no solicitadas o espontáneas. Especial atención al tráfico dirigido a los servidores de la empresa, a través de descargas de datos o documentos. El contenido se analiza antes de que se deposite en el destino protegiendo tanto el propio servidor como otras aplicaciones instaladas en él.

• Aplicación de las políticas de la empresa para empleados, pero también las que se refieren a las conexiones remotas, descargas de contenidos, ficheros, códigos ejecutables o programas.
• Se emplean las técnicas análisis cuando el tráfico a internet está permitido. Análisis de las sesiones establecidas entre el tráfico entrante y saliente.

-    En las solicitudes web iniciadas por el usuario se aplican las políticas de la empresa sobre la configuración de los navegadores. Por ejemplo, prohibir la apertura de ventanas emergentes, controlar las facilidades de descargas de contenidos, los cambios de configuración por un usuario no autorizado.

 -    Examen del tráfico SSL con el fin de ofrecer protección exhaustiva contra código malicioso o aplicaciones de control que se ocultan con técnicas de cifrado.

 -    Técnicas de análisis locales compartidas con otros dispositivos internos o externos con función soporte. Estos dispositivos emplean las técnicas “sandboxing”. Es necesaria la conectividad y la comunicación con estos dispositivos para analizar contenidos ejecutables que entran en la red a través de las páginas web solicitadas.

Arquitectura de la red

Los SWG se puede integrar en la red de tres maneras según los distintos modelos de los fabricantes. En los modos switch y router, los usuarios no son conscientes de la presencia del SWG en la red.

Modo Switch. El SWG actúa como un bridge entre sus clientes y la web. No es necesaria la configuración de los clientes. Comparten el mismo segmento de red.

Modo Router. El SWG tiene un extremo en una red y el otro en otra red diferente. El tráfico debe ser enrutado de acuerdo a las tablas de enrutamiento que los administradores deben configurar en el dispositivo.

Modo Servidor Proxy. Los usuarios se comunican con el SWG. Los usuarios deben configurar sus interfaces de red hacia el dispositivo.

Proceso de análisis del Servicio Web

En el SWG se pueden arrancar cuatro procesos de análisis independientes, que se inician por:

• Las solicitudes de los usuarios
• Las respuestas a las solicitudes
• Análisis de los objetos (ficheros, código ejecutable, programas, etc.) embebidos en las solicitudes
• Análisis de los objetos embebidos en las respuestas

La Tabla I muestra los procesos de análisis web y quién inicia los procesos.

 

Las políticas de seguridad de la compañía se implementan en las reglas. La s

elección y configuración de las reglas debe realizarse inicialmente para asegurar determinadas áreas de la red interna. Las reglas se configuran con elementos que realizan un filtrado muy amplio y poco a poco se añaden y se ajustan las reglas para que permitan un filtrado más minucioso, más granular. Las áreas básicas de protección deben estar cubiertas por filtros de listas de reputación (URL, IP, dominios), contenidos, tipo de tráfico y filtros antimalware. 

Por ejemplo, si la política de seguridad debe ser que los usuarios no puedan acceder a una determinada página web, la regla de filtro URL de “lista negra” tiene que estar activa y la dirección prohibida contenida en dicha lista. Cuando un usuario solicitase el acceso a esta web, la regla verifica la presencia de la dirección en la lista y en consecuencia se bloqueará la página web. Al usuario se le envía un mensaje de aviso sobre su prohibición debido a la política de la compañía.
Cada uno de los procesos aplicas sus reglas, aunque algunas pueden ser similares o compartidas. Las reglas pueden estar en diferente orden de ejecución y promover acciones y resultados diferentes según el proceso en que se encuentren. Proporcionan mucha versatilidad al sistema de seguridad, pero la configuración y administración son más complejas.

Reglas de análisis

Las reglas tienen las siguientes partes configurables:

• Activación de la regla para que participe en los procesos de análisis.
• Los criterios de cumplimiento: se selecciona qué elemento se va a comparar y el valor que debe de tener para que sea coincidente con los de las listas.
• Las acciones que se deben ejecutar cuando existe o no coincidencia.
• Los eventos que se dispararán junto con las acciones cuando exista o no coincidencia.

Las reglas especifican unos criterios y condiciones que deben cumplir los datos y los objetos embebidos del tráfico interceptado. Los valores que configura el administrador del SWG se comparan con los valores en el flujo a través de sentencias lógicas, bajo ellas se ejecutan los motores de análisis. Desde la perspectiva de la configuración de las reglas, los criterios de cumplimiento se basan en las sentencias comparativas. En sistemas más complejos pueden configurarse reglas anidadas; es decir, el resultado de la sentencia de una regla pueda ser la ejecución de otra regla diferente.
Las acciones pueden variar según la importancia o gravedad del análisis que haga la regla. Afectan al propio flujo de datos u objetos embebidos. Por ejemplo, son muy importantes las reglas para analizar el malware porque si no se filtra, tendrá un gran impacto en la infraestructura y servicios TI. En cuanto a los eventos, son respuestas adicionales que consisten principalmente en el incremento de contadores para datos estadísticos, notificación de correo a los administradores, mensajes “log”, indicaciones de alarmas, etc.

La Figura 1 muestra esquemáticamente el aspecto más formal de las reglas.

Figura 1. Esquema de las reglas

Algunas reglas tienen largos procesos de análisis; por ejemplo, cuando se consulta una lista de reputación global en la nube. En este caso, mientras se espera la respuesta, se siguen ejecutando las siguientes reglas. Si la respuesta de la consulta previa exigiese el bloqueo del flujo de datos o de un objeto embebido entonces éste sería bloqueado inmediatamente y no se tendrían en cuenta los resultados de las reglas posteriores. Esta forma de proceder evita que el SWG sea un cuello de botella para el tráfico desde y hacia internet.

El administrador debe gestionar los elementos adecuadamente. Se pueden añadir, ordenar, mover o borrar. Los valores se tienen que ajustar día a día para que los filtros funcionen eficazmente. No obstante, hay que proporcionar unas reglas preconfiguradas y activas para el análisis inicial, cuando el equipo se conecta a la red por primera vez. Por ejemplo, la lista de firmas del antimalware ha de estar instalada localmente para su uso antes de permitir la conexión de los usuarios. La lista aumentará según se añadan firmas y ofrecerá con el tiempo un filtro más completo. 

Los SWG proporcionan un conjunto de reglas aplicadas por defecto y otras que se deja al administrador su selección y configuración según las necesidades de su red. La Tabla II contiene las reglas más habituales en un SWG.

 

Los administradores gestionan estas reglas. Las tareas de gestión consisten en editar, modificar, activar, borrar, importar o exportar a ficheros para poder reinstalar o instalar en otros equipos.
Algunas acciones permitidas en las reglas están en la Tabla III.

 

La configuración del dispositivo es la configuración del modo en que el SWG se integra en la red local (modo switch, router o proxy), los puertos para su administración y conectividad con otros dispositivos y servicios adicionales entre otros.

Listas de confianza y niveles de riesgo

Las reglas utilizan elementos de comparación en listas dinámicas y largas. Las listas son gestionadas por el administrador. Sus elementos pueden ser creados, movidos, ordenados, borrados, exportados, importados, etc. La Tabla IV muestra las listas más habituales.

Los SWG pueden utilizar listas externas que se encuentran almacenadas en otros servidores remotos. La gestión puede ser:

• Las listas se importan, instalan y procesan en módulos dedicados. Tienen un tamaño limitado debido a la memoria disponible. Las listas se descargan de servidores web utilizando protocolos HTTP, HTTPS ó FTP; servidores LDAP y LDAPS, Bases de Datos SQL etc. 
• La lista no se descarga. El dispositivo realiza la consulta remota y se recibe una respuesta. En este caso, el tiempo de consulta es más lento pero se evita la tarea de descargar y mantener las listas ocupando memoria.

Las listas externas tienen desventajas. La configuración del SWG es más compleja. Implica la configuración de los interfaces para la conexión remota. La habilitación de este tráfico en los firewalls o NAT (Network Address Translation) de la red interna, los procedimientos de autenticación en los extremos, la transferencia de los ficheros, los periodos de uso de la caché donde se guardan, así como atributos específicos. Esta red con conexión al exterior forma parte de la red dedicada a la seguridad como expusimos anteriormente.

La ventaja de uso de listas externas es que eliminan los intervalos de desprotección que ocurren entre el momento de cambio de un elemento de la lista y su actualización en el sistema. Durante esos breves instantes no estaría operativa para su uso por los motores de análisis. Las listas externas ofrecen una amplia cobertura con datos de cientos de millones de muestras que aportan los equipos de clientes distribuidos por el mundo, por eso a veces se denominan globales. La responsabilidad del mantenimiento y actualización de las listas externas puede ser del propio fabricante del SWG o puede recaer en otras compañías que ofrecen el servicio. Los resultados de los análisis incrementan las listas internas locales, pero pueden ser exportados a enriquecer las listas externas.

Filtrado antimalware y niveles de riesgo

El módulo antimalware del SWG tiene su conjunto de reglas y motores de análisis. Su objetivo es detectar virus o programas maliciosos.

El malware suele estar comprimido. Los motores de análisis de malware deben ser capaces de descomprimir código para obtener los códigos ejecutables originales para su inspección. Esto exige que los módulos cuenten con una amplia variedad programas descompresores instalados, con la capacidad de actualizar versiones y descubrir, descargar e instalar aquellos que surjan nuevos. Estos programas son requeridos por el SWG a otros dispositivos de la red o a servidores remotos que ofrecen soporte en la nube, de los cuales son importados preparados para funcionar. Es otro ejemplo del uso de la red de seguridad.
Con el código original descomprimido se pueden buscar atributos e instrucciones para comparar en las listas. 

La Tabla V con los códigos ejecutables más comunes que pueden ser analizados y la Tabla VI muestra tipos de malware y su acción en los sistemas.

El módulo puede ejecutar su función de dos maneras diferentes.

• Método reactivo. Utiliza las listas de firmas de malware. Sólo detecta malware cuyas firmas son conocidas porque ya han sido detectados. Las reglas determinan si se consultan las listas locales o las externas.
• Método proactivo. Es un método heurístico, basado en el estudio del comportamiento de objetos embebidos y códigos ejecutables. Si no es el esperado, el analizador le considera sospechoso y vigila con más atención. Para ello agrega una etiqueta a la URL sospechosa. La etiqueta será elimina cuando el finalice el análisis.

Las matemáticas heurísticas son complejas, se basan en modelos de comportamiento y no aportan una solución precisa y clara, los resultados sólo son aproximaciones. El resultado del análisis de código es un porcentaje de riesgo potencial; es decir, la probabilidad que el código sea más o menos malicioso. 

 

Uno de los parámetros ajustables en este tipo de reglas es el umbral de riesgo que supone si el código examinado se permite ejecutar. Un umbral bajo, por ejemplo 10 sobre 100, significa que el ejecutable puede ser clasificado potencialmente malicioso, aunque se hayan cumplido sólo unos pocos criterios que así lo determinen. El umbral bajo crea muchos falsos positivos; es decir, indica que un ejecutable es malware cuando en realidad no lo es. Por el contrario, un umbral de riesgo alto, por ejemplo 90, implica que tienen que cumplirse muchos criterios que determinen que el ejecutable es malware. Este umbral alto y exigente crea pocos falsos positivos, si el diagnóstico es malware, es muy probable que realmente si lo sea. Pero puede crear peligrosos falsos negativos, el riesgo que se deje pasar un malware como un ejecutable fiable es más alto.

Cuando se marca un ejecutable como malicioso, el motor le bloquea e informa al administrador del sistema a través de las pantallas de control y monitorización. Se indica el nivel de riesgo y la probabilidad por la cual se ha bloqueado. Será el administrador el que actúe en consecuencia de forma manual, si decide mantenerlo bloqueado o permitir su paso. El administrador puede modificar los umbrales para afinar los ajustes para posteriores análisis.

Los SWG permiten seleccionar diferentes umbrales de riesgo para distintos ejecutables. La eficacia de los filtros depende de los algoritmos heurísticos utilizados y esto es propiedad de los fabricantes.

El análisis más seguro de los ejecutables se realizará cuando el SWG se conecte al dispositivo ATD. El SWG redirigirá los ejecutables sospechosos a aquél. En el ATD se despliega el entorno virtual, se ejecutará el código sospechoso y observando su comportamiento real será posible determinar realmente si es o no seguro. Si no lo fuese, el objeto analizado será bloqueado inmediatamente.

Pérdida de datos

Las aplicaciones de prevención de pérdida de datos, DLP (Data Loss Prevention), son una solución de la estratégica de la compañía para evitar que se borren o extraigan datos importantes y sensibles. Aplica políticas que identifican la información y la clasifican según criterios de confidencialidad. Los sistemas, por un lado clasifican y etiquetan y por otro lado monitorizan, detectan y bloquean la información. No sólo se implementan en el entorno tecnológico de la red para el flujo de datos, sino que se extiende a los equipos finales de usuario, almacenamiento o sistemas en la nube. Incluye el desarrollo de normativa éticas y compromisos contractuales con los empleados propios y de empresas colaboradoras, suministradoras o clientes.

El análisis más sencillo de la información clasificada según las políticas DLP puede ser a través:

• Contenido: palabras clave, etiquetas, códigos de documentos, etc.
• Contexto: origen y destino de la información.

Las reglas deben estar en concordancia con las políticas y de otras aplicaciones DLP instaladas para que el ámbito de la seguridad DLP funcione correctamente.

Geolocalización

La geolocalización es otra función necesaria que permite completar la información de ciberataques producidos. También es útil para extremar las precauciones en comunicaciones que se establezcan con determinados países donde es más fácil que se originen ataques.

Conclusión

Con todo lo expuesto nos permite tener una idea de cómo funcionan estas pasarelas para el servicio web. Las empresas dedicadas a proporcionar estos servicios necesitan estos sistemas de protección para garantizar la confidencialidad de la información, la integridad de los contenidos y la disponibilidad del servicio.

 L. F. Real

 

Ataque a FireEye, así terminamos el año 2020

 

 

Este año se presenta con esperanza e incertidumbre, tal vez a partes iguales, tal vez no. Si la amenaza biológica no es suficiente, se sigue sumando la tecnológica que también golpea los cimientos económicos de la sociedad.

El caso de FireEye

Hace unas semanas saltaban las alarmas. La empresa FireEye anunciaba públicamente que habías sido víctima de un robo de herramientas de ciberseguridad de carácter ofensivo; es decir, aquellas que permiten realizar ataques informáticos.

Kevin Mandia, CEO de FireEye, anunció el 8 de diciembre el descubrimiento y robo de herramientas de ciberseguridad muy especializadas. Estás son desarrolladas internamente para ser utilizadas por el Equipo Rojo.
(FireEye Shares Details of Recent Cyber Attack, Actions to Protect Community)
 

 

Equipo Rojo contra Equipo Azul

En ciberseguridad, el Equipo Rojo (Red Team) es un conjunto recursos, personas y herramientas, que realizan un ataque a empresas objetivo. La finalidad es comprobar la viabilidad de los vectores de entrada, los desplazamientos transversales en el interior de la red, el acceso a la información y la facilidad de su extracción.

En el otro lado se encuentra el Equipo Azul (Blue Team). Su misión es detectar y evitar los ataques del equipo contrario. Evaluar las herramientas de defensa implantadas en el cliente, reconfigurar o desplegar aquellas que puedan cubrir las brechas de seguridad descubiertas.

Estas acciones están enmarcadas en contratos de servicios de seguridad muy concretos entre la empresa de seguridad, donde forma parte el Equipo Rojo (en este caso es FireEye) y la empresa cliente. Una vez concluido el servicio, el equipo redactará los oportunos informes técnicos donde se exponen las acciones realizadas y las debilidades descubiertas. Se complementará con recomendaciones de mejora o la propuesta de medidas correctoras para reforzar la seguridad.

Herramientas ofensivas de FireEye: CommandVM

Las herramientas comprometidas, según un comunicado de Kevin Mandia, son bastante comunes en el ámbito de ciberseguridad; es decir, no son nada excepcional.

Entre las mencionadas, destaca la máquina virtual Commando VM que aglutina todas las herramientas de ataque propias del Equipo Rojo. Esta máquina se puede descargar desde GitHub. (Commando VM,)

(Para más información de Commando VM  Commando VM 2.0: Customization, Containers, and Kali, Oh My!)

Encontrar las herramientas robadas

No obstante, como la función de estas herramientas es ejecutar ataques e intrusiones, la compañía ha puesto a disposición de otras empresas del sector, las reglas para la detección de estas herramientas y prevenir sus acciones. Estos descubrimientos servirán para rastrear desde dónde se originan y quién las posee.

En el sector, esta respuesta de la compañía constituye un ejemplo de colaboración para combatir, dentro de lo posible, los ataques. Este es el camino a seguir por instituciones y compañías del sector.
(Respuesta ejemplar de FireEye tras sufrir un ataque que expone herramientas de Red Team)

FireEye ha puesto en la plataforma GitHub las reglas basadas en firmas: Snort, YARA, ClamAV, HXIOC
(Unauthorized Access of FireEye Red Team Tools, FireEye Red Team Tool Countermeasures )

Repasamos brevemente.

Reglas YARA. YARA es un lenguaje de programación de código abierto utilizado para la identificación de malware basada en firmas.
Es multiplataforma y se puede utilizar tanto desde su interfaz de línea de comandos como a través de sus propios scripts de Python.
La biblioteca de reglas es el repositorio Github YaraRules. Este es un conjunto de reglas bajo la licencia GNU-GPLv2 mantenido por un gran grupo de expertos en seguridad, dividido por categorías y actualizado con frecuencia.

Reglas Snort. Las reglas de Snort son agrupadas, por lo general, en conjuntos de   firmas que categorizan los incidentes. Así, encontraremos conjuntos de reglas  asociadas a la detección de troyanos, a la detección de ataques de tipo buffer overflows, etcétera. Snort posee una sintaxis propia que permite especificar hasta  el  más  mínimo detalle las condiciones que han de cumplirse para que un paquete sea asociado a las acciones indicadas por cada una de la reglas.

Reglas HXIOC. Las reglas HXIOC se basan en el formato OpenIOC creado originalmente por Mandiant. Es una codificación extensible en XML ya preparada para ser tratada por sistemas de información como, por ejemplo, sistemas de detección de intrusiones y cortafuegos avanzados (capaces de filtrar la capa de aplicación). Mandiant estandarizó OpenIOC y lo puso a disposición de la comunidad haciéndolo código abierto (“open source”) en 2011.

Reglas ClamAV. ClamAV® es un motor antivirus de código abierto (GPL) que se utiliza en una variedad de situaciones que incluyen escaneo de correo electrónico, escaneo web y seguridad de punto final. Proporciona una serie de utilidades que incluyen un demonio multiproceso flexible y escalable, un escáner de línea de comandos y una herramienta avanzada para actualizaciones automáticas de bases de datos.

Ataque selectivo y organizado

Tal como ha comunicado FireEye, el ataque fue “altamente sofisticado, cuya disciplina, seguridad operativa y técnicas nos llevan a creer que fue un ataque patrocinado por un estado”... “el atacante apuntó y accedió a ciertas herramientas de evaluación del Equipo Rojo que usamos para probar la seguridad de nuestros clientes. Estas herramientas imitan el comportamiento de muchos actores de amenazas cibernéticas”. Es posible deducir, que del conocimiento de las herramientas robadas, se crearían nuevos métodos de defensa más específicos y por otro; crear o rediseñar estas mismas herramientas o similares para perpretar ataques diferentes más complejos y ocultando las actuaciones. En resumen, conociendo cómo es la arma de ataque, es más fácil preparar la defensa.

La misma compañía, como hemos visto en los párrafos anteriores, ha preparado contramedidas para que bloquen el uso de las herramientas del Equipo Rojo robadas. Una respuesta que tranquiliza, si es que este concepto existe en ciberseguridad, tanto a los clientes de FireEye como a otras compañías.

Las sospechas de Rusia

El New York Times, publicaba el día 8 de diciembre que los ataques podrían tener un origen ruso. La División Cibernética del FBI está explorando esta línea de investigación. En el artículo del periódico se recogen los pasos que se están dando a otros niveles como la intervención de agencias gubernamentales, no podía faltar la NSA y otras empresas como Microsoft.
(FireEye, a Top Cybersecurity Firm, Says It Was Hacked by a Nation-State) 


No nos queda más que esperar si las contramedidas publicadas por FireEye tienen efecto y detectan e impiden los ataques. También es posible que apareceran modificaciones que realicen ofensas más contundentes. En definitiva, estaremos atentos, durmiendo con un ojo abierto, aunque no sea de fuego.

 L. F. Real