Estas semanas en Cloudflare en Español

Hola, buenos días, buenas tardes, buenas noches, donde quiera que nos sintonicen o estén viendo la retransmisión de este programa en Cloudflare TV, Estas Semanas en Cloudflare en Español. Mi nombre es Alex Mayorga Dame y actualmente trabajo en Cloudflare como ingeniero de soluciones desde nuestra oficina de Austin, Texas. Bueno, para los que nos sintonizan por primera vez, un poco de la logística del programa. En la parte baja de la transmisión pueden ver tanto un correo electrónico como un número telefónico en el que nos pueden hacer llegar cualquier pregunta o comentario que tengan sobre el programa o algún producto de Cloudflare que les gustaría que revisáramos en específico. El enfoque del programa es básicamente revisamos las novedades de producto de Cloudflare en dos recursos. Una es la página de novedades y la otra es el blog de Cloudflare. Comenzamos entonces en Cloudflare.com diagonal Watts guión New. Podemos encontrar las distintas novedades en mejoras de producto que se están anunciando y aquí podemos hacer el filtrado de las mismas si queremos enfocarnos en alguna categoría en particular o algún producto de la plataforma de Cloudflare. Está toda las herramientas que les proveemos para la protección y optimización de sus sitios web. Asimismo, el formato en que queremos que éstas sean ordenadas. Vayamos entonces y revisemos un poco las novedades que tenemos. Tenemos acá un blog en donde se anuncia la disponibilidad de sesiones basadas en el cliente. En donde podemos construir ahora reglas de Zero Trust para requerir la reautenticación periódica para permitir el acceso a la red, tanto en conexiones de TCP como UDP. Esto, bueno, nos permite crear una mejor mitigación del riesgo en la cuestión de sesiones permanentes, como cuando hay pérdida de dispositivos o equipos compartidos o el uso de dispositivos personales. Esto nos permite reautenticar y continuar comprobando constantemente la identidad de quien tenga el control de esos dispositivos. Y bueno, nos permite determinar con qué frecuencia se hace esta reautenticación. Y bueno, recordar a los usuarios a través de pop-ups sin, sin estarlos molestando demasiado. Después tenemos otro anuncio también en la plataforma de Zero Trust. La disponibilidad de logueo de comandos de SSH. Que bueno, en aquel momento está en un beta cerrado. Nos permite hacer el logueo de los comandos que se introducen a la terminal de SSH que se despliega en web a través de Zero Trust. Y bueno, se estará abriendo a más usuarios en el futuro. Y básicamente nos permite ver el listado completo de todos los comandos que se hayan hecho en una sesión de SSH. Para, bueno, en el caso de que haya algún incidente, algún ataque o alguna brecha. Poder hacer un análisis más detallado de la situación. Y bueno, nos cuenta también que este SSH es una extensión del Secure Web Gateway de la solución de Cloudflare Zero Trust. Y bueno, no hay que instalar ningún software de logueo en los equipos remotos. Básicamente es completamente transparente. También tenemos la parte de que hay un, una nueva entrada para la conexión de Zero Trust a través de túneles de IP. Conocidos como Magic IP Layer Tunnels. Y tenemos acá que esto nos permite que los clientes de Zero Trust puedan router automáticamente a cualquier red conectada. Ya sea NICAS de GRE, IPsec o Cloudflare Network Interconnect. Lo que nos da mayor flexibilidad de conectar a las redes existentes y ayudar a transicionar de una arquitectura tradicional de VPNs. Tenemos también un anuncio en donde se hace el manejo de diferentes nubes con el CASB de Cloudflare. Y bueno, nos dice que se encuentra ahora disponible para que ustedes puedan anotarse a la lista para participar en la beta de esta funcionalidad. Y bueno, se estarán enviando a la brevedad las invitaciones. Nos cuenta acá que, bueno, en este caso la solución de CASB de Cloudflare muestra tantos datos como usuarios de aplicaciones de software como servicio. Cuando hay algún acceso no autorizado o alguna exfiltración o exposición de archivos. También cuando hay algún error en la configuración de Shadow IT que este está incorrecta. Y puedes comprobar en esta beta integraciones tenemos con Google Workspace y momentáneamente con GitHub. Y también nos menciona que se estarán agregando otros software como servicio, como pueden ser Zoom, Slack, Okta, Microsoft 365 y Salesforce a lo largo del año. También se agregarán más capacidades, como el manejo de dispositivos, las guías de remediación y workflows automatizados para que, para que se pueda sustentar cualquier, cualquier tipo de brecha más rápidamente. Así como integraciones con Cloudflare Gateway para, para un mejor manejo del Shadow IT. Y bueno, obviamente esperamos sus comentarios en esta beta próximamente. Un anuncio también muy interesante que ahora tenemos disponible la opción Client List de Browser Isolation. En el que ahora se encuentran generalmente disponibles. Esto dentro de la, del catálogo de Zero Trust nuevamente. Bueno, esto se hizo generalmente disponible. Y ahora podemos utilizar un, un hipervínculo o un enlace básicamente con nuestro nombre del equipo, cloud .Cloudflareaccess.com, diagonal browser. Y directamente vamos a poder hacer navegación aislada desde este lugar. Una vez que se autentican, se establece una conexión de baja latencia de su navegador hacia el centro de datos de Cloudflare, más performante y cercano a ustedes. Sin tener que instalar ningún certificado, ningún software, ningún plugin en el dispositivo final. Y de esta forma pueden directamente hacer navegación segura. Y obviamente protegerse de cualquier amenaza que pudiera haber en algún sitio malicioso. Y bueno, también el poder acceder a datos sensitivos desde dispositivos que no tengan algún manejo del endpoint directamente. Y bueno, vamos a seguir ahora a revisar un poco lo que tenemos en el, en el blog. Pero bueno, de nuevo recordarles que Cloudflare.com, diagonal whats, guión new, contiene todas las novedades relevantes de producto para que les puedan dar un vistazo. Como entramos en el blog, tenemos a un blog de Abe, que es nuestro equipo de Zero Trust. Donde nos cuenta sobre la facilidad, gran facilidad que tenemos para el uso de túneles ahora. Bueno, nos cuenta un poco sobre la historia de Cloudflare. Bueno, para los que quizás no sepan, Cloudflare comenzó en un Tech Crunch Disrupt. Ahí nos deja un enlace para que vean el video, básicamente, del lanzamiento de Cloudflare hace ya más de 10 años. Y bueno, nos cuenta los pilares principales o los principios que dirigen el trabajo en Cloudflare. Es ser más seguro, tener mejor desempeño y ser ridículamente fácil de usar. Como menciona, la facilidad de uso es una de las, de las razones que consideramos en todas las decisiones de producto que se toman. Y bueno, nos comenta que eso obviamente también aplica para Cloudflare. Y bueno, nos cuenta esta mejora en la calidad de vida al crear los túneles. Básicamente, anteriormente se tenían que teclear hasta 14 comandos en la terminal. Y ahora todo esto se ha simplificado para que no tengamos que hacer ningún comando, sino simplemente seguir algunos sencillos pasos directamente en el dashboard de Cloudflare. Bueno, directamente nos cuenta que podemos hacer la inscripción a Cloudflare Zero Trust y directamente utilizar nuestra red privada a través de Cloudflare. Pero también nos cuenta que podemos también leer un poco la historia, que es lo que haremos en este caso. Nos cuenta sobre el conector que utilizamos, conocido como Cloudflare Tunnel o Cloudflare D. Este, bueno, es un conector open source que nos deja ahí el enlace al proyecto en GitHub directamente. Y nos ofrece alta disponibilidad por diseño, ya que crea cuatro conexiones a dos centros de datos distintos en la red de Cloudflare. Y bueno, si hay alguna indisponibilidad en este caso, no nos afecta, ya que tenemos la redundancia de las conexiones. Nos cuenta básicamente que históricamente este despliegue se hacía a través de la línea de comandos, pero ahora tenemos una posibilidad de crear remotamente y hacer la administración de las configuraciones desde el dashboard directamente. Y bueno, nos dice que ahora esto puede hacer que podamos garantizar acceso a la red en 15 minutos o menos para nuestros usuarios. Bueno, la decisión aquí de si hacerlo con línea de comandos o con interfaz gráfica. Y básicamente, ¿por qué no los dos? ¿Qué es lo que lo que tenemos? Nos cuenta un poco AVE sobre los beneficios de las líneas de comandos, como ya sabemos, pues mayor control, facilidad de uso para los usuarios que están familiarizados con ellas. Pero también pues tenemos la desventaja de un poco una curva de aprendizaje quizá más elevada. Y quizá no, usuarios que no desean invertir tanto tiempo en hacer la investigación para saber los comandos exactos que tenemos que teclear, etc. Y bueno, nos cuenta que de inicio, cuando Cloudflare Tonal inició, básicamente había menos de 10 distintos comandos, pero ahora conforme el producto ha evolucionado, se han agregado funcionalidades y casos de uso. Y un poco se volvió complicado el poder descubrir todas las variantes de los comandos que podemos hacer. Nos cuenta también que, bueno, en ocasiones si teníamos un error tipográfico dentro de los comandos, esto causaba frustración a los usuarios. Y también puede ser complicado de recordar todos y cada uno de los comandos. Ahora tenemos que simplemente lo podemos hacer con la interfaz gráfica. Pero ambas posibilidades de uso nos permiten obtener los mismos resultados. Esto básicamente reducirá la fricción en la adopción de Cloudflare Tonal. Y bueno, nos deja aquí directamente un enlace a la documentación para los developers que podemos encontrar en developers.Cloudflare.com. Y bueno, también nos cuenta que también se deseaba mejorar algunos conceptos en la parte de los permisos de los túneles. Y ahora tenemos la parte de que también podemos hacer clientless Zero Trust en este caso. Nos cuenta también un poco sobre las políticas que podemos implementar en Zero Trust. Básicamente podemos hacer esto a través de Cloudflare Tonal y Access. Básicamente vamos a configurar en el dashboard. Y el dashboard nos va a proveer un script de configuración que ya va a estar pre-configurado para el sistema operativo en donde lo vayamos a desplegar. Y se crean básicamente los nombres de host o las rutas privadas para el túnel. Vemos acá un poco cómo como luce esta configuración. Y nos cuenta ahí un poco de los planes a futuro que se tienen. Nos cuenta que hemos visto una gran adopción. Cientos de miles de túneles se han creado desde que Cloudflare Tonal comenzó. Y algunos van a ser migrados a la nueva modo de orquestación que tenemos. Y se está construyendo la herramienta para hacer esta migración completamente transparente en este caso. Nos cuenta que esto estará disponible en algunas semanas más. Y también el lanzamiento, como ya mencionamos, de la documentación para developers. Y el agregar más comandos incrementalmente. Nos deja también un enlace a una guía. Si aún no ha probado Cloudflare Tunnels, directamente pueden hacer una prueba desde nuestro dashboard. Vayamos ahora a los siguientes blogs. Tenemos un blog de Celso, Sofía y Joao. Que nos cuentan sobre nueva funcionalidad en Cloudflare Radar. En donde tenemos ahora páginas para los sistemas autónomos. Comenzamos, bueno, una explicación de nuestros colegas. En donde nos explican un poco lo que es un sistema autónomo. Que es un grupo de IPs ruteables. Un perifico que pertenece a una única entidad. Y nos cuentan que también es una de las de los bloques de construcción básicos para Internet. Vemos ahí algunos tipos de organizaciones que pudieran tener sistemas autónomos, como los proveedores de Internet, las nubes públicas, los gobiernos y muchas otras organizaciones. Pueden tener uno o más asignados hacia ellos. Y bueno, es como informan a otros sistemas en Internet. Cómo pueden alcanzar sus redes en particular. Nos cuenta que la información de tráfico estadístico nos puede dar visibilidad cuando hay alguna anomalía o una caída en Internet. Algún ataque o algún otro cambio en los proveedores. Y bueno, nos dejan aquí un enlace en donde podemos ver en radar.Cloudflare.com y a una ASN. Colocamos ahí el número del sistema autónomo del que queremos ver información. Y también nos muestran cómo aparece en la vista general de los países. Tenemos ahí un nuevo módulo al lado derecho de la página. En donde podemos ver esta información. También vemos aquí un ejemplo de cómo luce esta distribución geográfica. Y nos cuentan también cómo el hecho de que haya un incremento en los anuncios de BGP puede ser indicativo de algún cambio disruptivo que haya habido en alguna región en Internet. O en alguna, en alguna organización o institución asociada con un número de sistema autónomo. Nos dejan aquí enlaces cómo se vio el incremento de anuncios de BGP cuando hubo el corte del cable submarino en Tonga en este año. Y también el pasado, la pasada caída que hubo en la red de Facebook en octubre del 2021. Así como cuando hubo bloqueos de Internet en algunos países el año pasado. Y bueno, nos cuenta, como quizás ya sepan, Cloudflare está comprometido con mantener la transparencia del funcionamiento interno en Internet. Y ya que esto nos permite, como es nuestra misión, ayudar a mantener el Internet más seguro y abierto para todos. Nos dejan acá finalmente un enlace a Cloudflare Radar, en donde ustedes podrán ver esta nueva funcionalidad de los ASN. Se los dejamos ahí para que lo visiten. Después tenemos el siguiente blog, que es una, la investigación, información que realizó, perdón, la investigación que realizó Cloudflare sobre el compromiso que hubo en Okta en enero de 2022. Este blog es escrito por John, Lucas y Daniel. Y bueno, nos dicen aquí que el marzo 22 del 2022, a las 3.30 UTC, fue Cloudflare informado de un compromiso en Okta. Nos cuentan acá que nosotros utilizamos Okta internalmente para identificar, como parte de la identificación de nuestros usuarios y la autenticación. Se ha investigado cuidadosamente este compromiso y no creemos que hayamos sido comprometidos como resultado de esta investigación. No utilizamos Okta para cuentas de usuarios. Y bueno, los usuarios de Cloudflare no tendrían que tomar ninguna acción ellos mismos, a menos de que utilicen Okta en su infraestructura. Tenemos un poco la información sobre la investigación que se hizo. Se notificó aparentemente que en enero de 2022, algunos atacantes fuera de Okta habían tenido acceso a una cuenta de un empleado de soporte en Okta. Y que fueron como resultado capaces de tomar acciones como si fueran este empleado. Se compartió una captura de pantalla en algunas cuentas de redes sociales. En la que el correo externo de un empleado de Cloudflare estaba visible. Y había un pop up ahí indicando que el atacante se estaba haciendo pasar por este empleado de Okta para iniciar un reset de la contraseña. Nos cuenta que nosotros nos enteramos de este evento a través de nuestro equipo interno de respuesta a incidentes. Y bueno, nos comentan también en este caso, cualquier empleado puede levantar una alerta a este equipo cuando hay un problema potencial. A las 3.30 UTC, básicamente uno de nuestros empleados le envió un correo electrónico con un enlace al tweet que aparece aquí enlazado. Que había sido enviado a las 03.22 UTC. En donde se indicaba que potencialmente había una brecha de seguridad en Okta. Múltiples empleados de Cloudflare contactaron al equipo de respuesta a incidentes en las siguientes dos horas. Y bueno, nos da una línea de tiempo de cómo fue la respuesta en este caso. A las 3.30 tenemos que el equipo de respuesta a incidentes recibe la primera alerta de la existencia de sus tweets en la red social. Después a las 3 .38 confirma el equipo de respuesta que aparentemente hay información de Cloudflare como un logo y un nombre de usuario. A las 3.41 se crea un, una, una cuarta de incidencias para comenzar la investigación y empezar a reunir al personal necesario. A las 3.50 el equipo determina que no hubo ningún log relevante como cambios de password para el usuario que aparece en los, en las capturas de pantalla. A las 4.13 se contacta directamente con Okta para obtener información más detallada para continuar la investigación. A las 4.23 todos los logs que se ingestan hacia el SIEM, hacia los sistemas de SIEM son revisados por actividad sospechosa potencial. Tenemos que a las 5.03 se suspenden las cuentas que pudieran haber sido afectadas. Y temporalmente se suspendió el acceso a todos los empleados que, cuyos correos aparecen en las capturas de pantalla que los atacantes publican. A 05.06 el equipo comienza la investigación de los logs, como las IPs, las ubicaciones, los métodos de multifactor. Y a las 05.38 tenemos una respuesta en Twitter de nuestro CEO, Matthew Prince, en donde básicamente confirma el problema. Porque aparentemente el empleado de soporte de Okta podía forzar el reseteo de passwords en los clientes de Okta. Y bueno, se decide, dado esto, hacer una revisión de todos aquellos que hayan hecho un reset de su password o hayan modificado su multifactor de autenticación desde la fecha de diciembre primero del año pasado. Tenemos ahí que 144 empleados habían realizado esas actividades, por lo que se forzó un reseteo de sus passwords a raíz de este cambio y se les notifica del mismo. A las 05.44 una lista de todos los usuarios que habían cambiado su password en las últimas tres meses es finalizado. Y todas estas cuentas fueron requeridas a realizar un reseteo del password nuevamente. A las 06 .40 tenemos otro tweet de nuestro CEO, Matthew Prince, acerca del reseteo de cuentas. Y a las 07.57 se recibe una confirmación de Okta que no hay ningún evento relevante que indique actividad maliciosa de la consola de soporte en las instancias de Okta de Cloudflare. Y bueno, básicamente nos siguen elaborando en la forma en que se utiliza Okta dentro de Cloudflare. Nos enlazan también a blogs anteriores en donde ya se detallaba esta información de cómo se utilizan llaves de hardware en este caso y multifactor de autenticación para incrementar la seguridad de todos los que trabajamos en Cloudflare y de todos nuestros clientes. Bueno, básicamente el atacante en realidad debiera haber requerido acceso a las llaves de hardware, lo cual no, no es posible en este tipo de ataques. Y también nos cuenta cómo almacenamos los logs de Okta hacia acá. Confirman también que Okta no es usado para autenticación de usuarios en nuestros sistemas y tampoco almacenamos ningún tipo de dato de cliente en Okta. Y nos hacen un resumen básicamente de la línea de tiempo que ya detallé anteriormente. Nos comunicamos con Okta, se suspendieron las cuentas que eran visiblemente, que eran visibles, perdón, en las capturas de pantalla. Se revisaron los logs en este caso. Y también se revisaron los logs de Google Workspace para cambios de cuentas. Se compiló una lista y se requirió que todos aquellos que potencialmente fueran afectados hicieran un cambio en sus passwords. Finalmente, algunas recomendaciones. Si su organización es también cliente de Okta, habilitar el múltiple factor de autenticación en los passwords. Revisar si algún cambio en el password o los múltiples factores de autenticación ocurrieron en los periodos de la brecha. Revisar, obviamente, si fueron iniciados por soporte y solicitar el cambio de todos aquellos passwords que pudieran estar potencialmente comprometidos. También, pues, el agregar múltiples capas de seguridad para proveer mayor seguridad en estos casos. Creo que estamos sobre el tiempo. Chao.