Esta es la primera entrega de nuestra serie sobre bloqueos, en la que analizamos los métodos que puede utilizar para contener eficazmente los eventos de seguridad y cómo Vectra puede ayudarle. Permanezca atento a la siguiente entrega, en la que destacaremos las capacidades de bloqueo automatizado de Vectra y nuestra cobertura para Microsoft Azure y AWS.
El tiempo es oro
Cualquiera que trabaje en respuesta a incidentes (IR) le dirá que cuanto más rápido se contenga un suceso, menos probable es que se convierta en un incidente en toda regla. A la validación de una detección debe seguirle rápidamente el aislamiento. Así se gana tiempo para reunir pruebas, determinar el alcance y, en última instancia, poner remedio. Dependiendo del tipo de detección, es posible que sólo tengamos una parte de la imagen.
Tomemos, por ejemplo, una detección de barrido de puertos dirigida a varios hosts desde una única fuente. En este caso, necesitamos saber cómo se está accediendo al sistema, cómo se ha afianzado el atacante, durante cuánto tiempo ha tenido acceso o si se ha producido algún movimiento lateral con éxito. Todas estas preguntas requieren tiempo para responderlas.
También hay que tener en cuenta el tiempo de permanencia del atacante. Cuanto más tiempo tenga acceso al entorno, más cerca estará de conseguir su objetivo (por ejemplo, cifrar servidores de archivos y pedir un rescate a la empresa, o filtrar esa nueva investigación en la que su organización lleva trabajando varios años). Obstruir el avance del atacante y dar al personal de respuesta a incidentes un tiempo valioso para investigar permitirá tomar decisiones mejor fundamentadas durante la reparación. Una vez que un atacante tiene acceso privilegiado, puede avanzar más rápido y más lejos para completar su misión.
Consideremos el ejemplo del ransomware MAZE: los atacantes crearon sus propias cuentas y aprovecharon las cuentas privilegiadas para propagarse por la red. La contención es la respuesta para interrumpir este avance e impedir que atacantes como los operadores de MAZE utilicen cuentas privilegiadas en la red para desplegar su ransomware.
¿Cómo aplicarlo?
Hay varias formas de contener a un atacante. Podríamos aislar el ataque de dos maneras: en primer lugar, a través de un agente de punto final en el host; en segundo lugar, en la pila de red deshabilitando la cuenta utilizada para el movimiento lateral o modificando el servicio explotado. En la mayoría de los casos, el aislamiento del punto final puede detener rápida y eficazmente cualquier interacción interrumpiendo la comunicación de los sistemas objetivo hacia o desde cualquier lugar excepto una lista predefinida de sistemas. Esto permite la recopilación remota de más pruebas sin necesidad de desconectar el sistema y enviarlo a su equipo de respuesta a incidentes, que puede realizar la investigación de forma remota antes de devolver el sistema al equipo de TI local o al usuario final.
Si identificamos una cuenta de la que se está abusando para el movimiento lateral, entonces podemos desactivar la cuenta en Active Directory. Si se trata de una cuenta local, es menos probable que el atacante sea capaz de llegar muy lejos, ya que las cuentas locales no tienen privilegios de grupo aplicados y prohibirán a un atacante moverse lateralmente.
También podemos conseguir un resultado similar aprovechando la pila de red para realizar el aislamiento, aprovechando las ACL (listas de control de acceso) o colocando el sistema en una VLAN separada que impida la interacción con otros sistemas de la red. La creación de una VLAN para la corrección es una práctica común, y esta VLAN permite que el endpoint se comunique con sistemas de gestión como el servidor de actualizaciones Windows Patch Server, Microsoft System Center Configuration Manager ( SCCM), o la detección y respuesta antivirus de endpoints (EDR), pero con ningún otro sistema de la red.
Otra forma de conseguir el aislamiento es aprovechar los GPO (objetos de directiva de grupo) de Microsoft para gestionar las reglas del cortafuegos de los extremos de Windows. Se crea una política para bloquear todos los servicios por defecto y, a continuación, se ponen en la lista blanca los servicios críticos. Una nota importante aquí es que tendrá que asegurarse de que se ignoran las políticas locales, ya que un usuario (o malware) puede modificar las reglas del cortafuegos de los sistemas locales de forma predeterminada.
Para servicios críticos en los que no podemos simplemente aislar el sistema sin afectar al negocio, considere limitar el acceso al servicio basándose en la IP de origen o en la cuenta. En un sistema Linux, podríamos aprovechar las tablas ip o actualizar /etc/host.deny. También deberíamos considerar el acceso desde el sistema: si se trata de una retransmisión de correo, quizá podamos limitar exclusivamente el tráfico hacia y desde el puerto TCP 25 y a un destino de Internet (Exchange) mientras investigamos más a fondo. No será posible escribir un libro de jugadas para cada escenario; dicho esto, es importante ser consciente de que pueden surgir escenarios inusuales que requerirán experiencia en Respuesta a Incidentes.
Segunda parte: llevarlo a la cloud:
La velocidad es un ingrediente clave para el éxito de la contención, iniciar sesión en otra plataforma, encontrar el host o la política que desea y aplicarla todo lleva tiempo. Vectra permite a los equipos de seguridad contener directamente en la plataforma, los usuarios pueden ver y gestionar fácilmente la configuración de contención desde un único panel de vidrio.
En la siguiente parte de esta serie de blogs, veremos qué acciones se pueden tomar para la infraestructura en la cloud y cómo automatizar las acciones de bloqueo desde Vectra.