La filtración o pérdida de datos puede ser una lamentable experiencia, larga y costosa, y ocasionar pérdidas económicas y una asociación negativa con la marca, así como sanciones como resultado de leyes de protección de la privacidad. Veamos, por ejemplo, un incidente de exfiltración de información confidencial de I+D de medición y de la smart grid (red eléctrica inteligente) de un sistema de control industrial de una empresa eléctrica de EE. UU. mediante un ataque que se sospecha que se originó desde dentro de la red. El acceso no autorizado a los datos de una empresa de servicios públicos puede poner en riesgo una smart grid o causar cortes de energía.
En otro ejemplo, un investigador de seguridad encontró puntos de conexión de la API expuestos y desconocidos (no documentados) para Tesla Backup Gateway, que podrían haberse utilizado para exportar datos o realizar cambios no autorizados. Esto habría tenido importantes consecuencias físicas si un atacante hubiera utilizado el punto de conexión de la API no autenticado para dañar la batería o la red eléctrica conectada.
Ambos ejemplos enfatizan la importancia de tener en cuenta las amenazas internas y externas a la hora de proteger una red contra la exfiltración de datos. Una amenaza interna no es necesariamente un usuario que causa daño de forma intencionada. Según el informe sobre amenazas internas de Fortinet de 2019, al 71 % de las organizaciones encuestadas les preocupaba que el descuido de un usuario causara una brecha accidental, y al 65 % que los usuarios ignoraran las políticas, aunque no fuera de forma maliciosa. El atacante que llevó a cabo con éxito el hackeo de Twitter en 2020 para acceder a algunas cuentas importantes empezó con un ataque de ingeniería social contra los empleados. Luego pasó a utilizar herramientas administrativas internas para cambiar la configuración de las cuentas de los clientes, como publicar en su nombre o modificar sus correos electrónicos y 2FA.
A primera vista, puede parecer solo una estafa de bitcoin, pero los atacantes también descargaron y exfiltraron datos de siete cuentas. Si se pusiera en riesgo con éxito la cuenta de un usuario interno con un intento de vishing (una forma de ataque de ingeniería social que utiliza el phishing basado en la voz), añadir claves de seguridad o implementar permisos de cuenta granulares a las herramientas administrativas podría impedir el acceso del atacante. Durante la Semana de la seguridad explicamos el hackeo de Twitter desde el punto de vista de un ataque de apropiación de cuentas y cómo se podría haber mitigado.
La exfiltración de datos no requiere el uso de técnicas sofisticadas ni de herramientas extrañas. Los usuarios objetivo de un ataque de phishing, junto con políticas excesivamente permisivas en un punto de conexión, en lugar de una cuenta, pueden proporcionar a un atacante el acceso que necesita para la exfiltración de datos. Para responder a los ataques de ingeniería social, muchos equipos de seguridad dependen de que se bloqueen los dominios maliciosos en tu solución de protección del correo electrónico. ¿Pero qué pasa si un recurso malicioso se comparte de forma lateral y no desde una fuente externa a una interna? Los empleados pueden compartir los dominios maliciosos por el chat, o a través de alguna otra forma de comunicación que no sea el correo electrónico. Esto crea brechas, que dificultan aún más a los equipos de seguridad la protección de los usuarios y datos internos.
Siempre hemos hecho hincapié en un enfoque multicapa para la prevención y la vigilancia. Para nuestras herramientas internas, tenemos controles de acceso basados en roles y en riesgos. Ponemos nuestras aplicaciones detrás de Access para que haya una capa de autorización adicional sobre la autenticación. Añadir aplicaciones SaaS detrás de Access nos permite conectar de forma segura a los usuarios con aquello que necesitan, ya sea localmente o en la nube. Con una plantilla en remoto, Access nos permite configurar políticas basadas en la ubicación, el tipo de dispositivo, la postura del dispositivo y el método MFA. Según avanzamos hacia un entorno sin VPN, Access actúa en su lugar como un túnel seguro. Nuestro equipo de detección y respuesta supervisa tanto los registros de Access como los registros de las aplicaciones SaaS en busca de anomalías. Pronto añadiremos el registro de Access en las aplicaciones SaaS, lo que enriquecerá y contextualizará todavía más los registros.
La protección de los puntos de conexión con Cloudflare también incluye un cliente que se utiliza para aplicar las políticas. Podemos utilizar las reglas de firewall de Gateway con Access para adoptar un enfoque más integral en las capas 4 (red) y 7 (HTTP). Usamos las ubicaciones de Gateway para restringir las consultas de DNS a los dominios maliciosos.
Con los empleados trabajando en remoto, las empresas no pueden aplicar las políticas de red en los puntos de salida de sus oficinas corporativas. Al usar nuestro cliente de escritorio WARP junto con Gateway en los puntos de conexión de nuestros usuarios, los equipos de seguridad pueden tener visibilidad de los registros de DNS, con la posibilidad de aplicar políticas que antes se podían utilizar en las oficinas corporativas, a la vez que se mantiene la privacidad. Gateway funciona como el solucionador de DNS en los dispositivos corporativos. Esto no solo permite que los equipos reaccionen a los incidentes e identifiquen la raíz del problema de forma más eficiente, sino que también ayuda con la prevención al identificar las máquinas en riesgo que visitaron dominios maliciosos. WARP garantiza que el tráfico de DNS está encriptado, protegiendo así la privacidad de los usuarios.
Nuestra herramienta de aislamiento de navegador ofrece protección en la capa más cercana al usuario, y donde probablemente pasa la mayor parte de su tiempo accediendo a las aplicaciones basadas en la nube. Resulta útil tanto en la prevención como en la respuesta. Se puede utilizar para eliminar el acceso a determinadas aplicaciones SaaS, impedir que los usuarios copien/peguen, restringir la impresión y bloquear la descarga de archivos. En otras palabras, los datos alojados en los servicios en la nube pueden estar protegidos en varios puntos cruciales, así que su exfiltración será más difícil. Las políticas permiten configurar el aislamiento de navegador para dominios o usuarios individuales o para amplias categorías de sitios web. El aislamiento de navegador también puede permitir que el personal de respuesta identifique rápidamente los puntos de conexión que pueden estar ya en riesgo, al detectar aquellos que han visitado dominios maliciosos conocidos o han descargado determinados archivos con el navegador.
Aquí es donde entra en juego un modelo Zero Trust. Si aún no lo conoces, aquí te presentamos una buena introducción. Cloudflare Access es un componente importante del conjunto de herramientas de Cloudflare One que ayuda a las organizaciones a implementar un modelo Zero Trust en su red. Usamos Cloudflare Access para gestionar un enfoque uniforme a las políticas para los recursos internos. Como ingeniero de seguridad del equipo de detección y respuesta que responde a incidentes para los que hay que hacer cambios de acceso en toda la empresa, las aplicaciones Cloudflare Access y Cloudflare Access for SaaS nos ponen en condiciones de aplicar de forma eficiente las políticas, así que podemos centrarnos en elementos más prioritarios sin tener que preocuparnos de los cambios a nivel de aplicación. La gestión centralizada del acceso a las aplicaciones que, de otro modo, se tendría que gestionar de forma individual, mejora drásticamente nuestro tiempo de respuesta.
Pasando a la capa de la API, Cloudflare API Shield actúa como el punto principal para gestionar los controles de seguridad de las API. Pensemos en los dispositivos IoT que se exponen mediante numerosas API, como Tesla Gateway. API Shield proporciona un enfoque multicapa para limitar la exposición accidental de datos. Por ejemplo, se pueden validar los esquemas para minimizar la probabilidad de que una entrada inesperada ponga en riesgo un sistema downstream; las solicitudes al punto de conexión se pueden restringir, para que solo las envíen clientes que tengan certificados SSL/TLS válidos, y se puede filtrar el ruido procedente de fuentes como los proxies Open SOCKS, junto con las solicitudes procedentes de dispositivos o regiones con los que la API no debería comunicarse. El anuncio de hoy incluye nuevas funciones de ofuscación de datos, y esta semana anunciaremos formas de descubrir API "en la sombra", que tu equipo quizá no sepa que existen, y de detectar actividades de llamadas anómalas.
Como ingeniero de detección y respuesta, en numerosos incidentes un problema de seguridad nos exigía entender en el acto cómo funcionaba el acceso a estos sistemas. Cada sistema se gestiona de distinta forma, y las funciones no siempre están definidas de manera uniforme. Esto hace que sea muy difícil responder de forma inmediata y, la mayoría de las veces, nos obliga a mantener conversaciones con los propietarios del sistema para entender mejor el acceso. Gracias a la protección multicapa que proporcionan Cloudflare One, Browser Isolation y API Shield, los equipos de seguridad pueden centrarse en la prevención y no en la respuesta.