Noticias y Alertas
Header

Estrategias básicas para mitigar una ciberintrusión

junio 16th, 2012 | Posted by kwelladm in Análisis Forense / Vulnerabilidades | Publicaciones

El ICS-CERT ha publicado recientemente una serie de recomendaciones muy básicas sobre cómo mitigar una ciberintrusión dirigida, sobre todo, a entornos industriales e infraestructuras críticas, y aplicable tanto a redes empresariales como a sistemas de control. Aunque estas recomendaciones no entran en detalle en cada una de las acciones que se deben realizar, si que conviene tenerlas en cuenta, ya que proporcionan una serie de buenas pautas a seguir, importantes dentro de la seguridad en un entorno industrial.

1. Dónde comenzar: recomendaciones para detección y mitigación

  • § Prevención de movimientos laterales: cuando descubrimos que hay un equipo comprometido en nuestra red, nuestra principal preocupación debería ser minimizar los movimientos laterales a través de la red. Es decir, no tiene sentido ir desinfectando equipo por equipo comprometido conforme se vayan detectando si la infección no ha sido contenida, ya que ésta seguirá expandiéndose. Es esencial que se identifique cuanto antes el grado de intrusión y en qué áreas de la red están los equipos comprometidos para aislarlos. Los movimientos laterales pueden ser identificados por diversas herramientas y técnicas como IPS, IDS, analizando los logs de firewalls, proxys, DNS o realizando capturas de paquetes.
  • § Gestión de credenciales: El almacenamiento de credenciales en caché debería estar desactivado en todas las máquinas; la caché de credenciales almacena autenticadores de dominio localmente permitiendo a los usuarios iniciar sesión en un sistema usando credenciales de dominio, incluso si la máquina está desconectada de la red.

Una técnica muy común empleada por los ciberdelincuentes es “pass the hash”, técnica por la que, a través de los hashes de las contraseñas almacenados en la SAM o en la caché del sistema extraídos de una máquina comprometida, podemos acceder a otras máquinas del dominio.

Se recomienda, por tanto, desactivar en la medida de lo posible el almacenamiento de credenciales en caché en todas las máquinas. Cuando sea necesario almacenarlas, solo deberían guardarse las del usuario menos privilegiado, nunca las de la cuenta de administrador. Tras desactivar la caché de credenciales es necesario restablecer todas las contraseñas de nuevo, para asegurarnos de que las antiguas contraseñas no son válidas y las nuevas no se almacenan en local.

Se insta también a que las empresas dejen de usar hash LM ya que es débil y fácil de romper por fuerza bruta o por tablas precomputadas.

  • § Benditos logs: A la hora de gestionar un incidente de seguridad, una de nuestras mayores fuentes de información son los registros o logs de los sistemas (sea a nivel de comunicaciones, aplicaciones o sistema). Se recomienda por tanto habilitarlos y guardarlos al menos durante seis meses. Son interesantes los de los firewalls, proxys, DNS, IDS, capturas de paquetes, flujos de datos de routers y switches, logs de aplicaciones y logs de host.
  • § Registro de peticiones DNS cliente: se recomienda a las organizaciones desplegar un registro de peticiones DNS a nivel de host para que los administradores de red sean capaces de identificar el equipo interno que realiza una petición DNS específica, bien por nombre o por dirección IP ya que esto permite identificar a los equipos que están conectados a dominios maliciosos.
  • § Comprobaciones de integridad en los equipos cliente: Si un hash MD5 se sabe que pertenece a un archivo malicioso, cualquier fichero con ese hash debe ser considerado sospechoso. Diversas herramientas forenses o HIDS pueden ayudarnos al respecto.

2. Recolección de evidencias

La recopilación de todos los datos forenses durante el proceso de respuesta ante el incidente es fundamental tanto para contener la intrusión como para mejorar nuestras defensas ante un posterior ataque. Ante todo se recomienda consultar con expertos en análisis forense para la recolección de las mismas. Lo más importante es documentar absolutamente todo lo que se va realizando tanto las medidas que se toman para paliar el incidente como las que no y por qué, fechas/horas, fotografías (de equipos, de cableados,etc), etc.

Es importante desactivar el antivirus en esta fase ya que los análisis del propio antivirus podrían cambiar la fecha de acceso de ficheros críticos así como evitar aplicar cualquier cambio en el sistema operativo o en el hardware (actualizaciones, parches,etc.) ya que se podría sobreescribir información relevante para la investigación.

3. Recomendaciones a largo plazo

  • § Control ‘estricto’ de acceso basado en roles: se debe otorgar o negar el acceso a los recursos basándose en la función del trabajo que se realice, así se evita que los usuarios tengan acceso a equipos que no sean necesarios para su trabajo. Cada empresa debe definir grupos según roles y aplicar los permisos que le correspondan. Se permite una mejor auditoría y se reduce el riesgo reduciendo al mínimo los privilegios asociados a cada grupo. Esto provoca una segmentación de la red lógica que hace que sea más difícil para los atacantes moverse por la red después de una intrusión.
  • § Segmentación de red: implica la separación de una gran red en redes funcionales más pequeñas usando firewalls, switches, u otros dispositivos similares. Una adecuada segmentación restringe la comunicación entre cada segmento, lo que disminuye el riesgo de que se produzcan movimientos laterales tras una intrusión.

Lo ideal sería que la red empresarial y la red del control de los sistemas estén físicamente separadas.

Se debe incluir también uno o más segmentos de DMZ, incluyendo los servicios externos de una organización que estén expuestos a Internet o los sistemas críticos accesibles desde múltiples segmentos de red internos.

  • § Lista blanca de aplicaciones: permitir sólo la ejecución de lo estrictamente autorizado (en la lista blanca), prohibiendo la ejecución de cualquier software fuera de esa lista. Se recomienda implementar listas blancas en servidores como controladores de dominio o servidores de correo.

Este ha sido un breve y ‘personalizado’ resumen de las recomendaciones propuestas por el ICS-CERT. Si quieren ampliar este resumen no duden en leer la publicación: http://www.us-cert.gov/control_systems/pdf/ICS-TIP-12-146-01.pdf

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

Deja un comentario