Proteger Internet con la innovación en la nube

Clarke Rodgers (00:10):
Es difícil creer que hubo un tiempo antes de Internet en el que los problemas de seguridad eran más simples y claros. El mundo ha cambiado drásticamente en los últimos 40 años, y la conexión en línea ahora es fundamental para nuestras vidas y negocios. Esto conlleva mayores oportunidades, pero también un riesgo mucho más alto.

Soy Clarke Rodgers, Director of Enterprise Strategy de AWS, y su guía para una serie de conversaciones con líderes de seguridad de AWS aquí en Executive Insights.

Hoy charlamos con Paul Vixie, Deputy CISO, Vice President y Distinguished Engineer de AWS Paul aporta una perspectiva única a la seguridad de AWS, ya que fue una de las primeras personas influyentes en la evolución de Internet. Únase a nuestra conversación mientras analizamos el papel de los líderes de seguridad a la hora de hacer de Internet un lugar más seguro para comunicarse. Esperamos que lo disfrute.

Clarke Rodgers (00:57):
Paul, muchas gracias por participar y estar aquí hoy. Llevas bastante tiempo en el mundo de Internet. ¿Puedes compartir tus impresiones sobre cómo comenzó y cómo hemos llegado a donde estamos hoy, especialmente desde el punto de vista de la seguridad?

Paul Vixie (01:11):
Bueno, la seguridad era algo secundario. Así que entra en la historia considerablemente más tarde, pero las historias son ciertas. Internet comenzó como una red del gobierno de EE. UU. Los militares nunca lo usaron, al menos al principio. Y por eso existe el mito de que los protocolos se diseñaron para protegerse mejor ante ataques físicos o cosas así. Y eso no es cierto. Siempre ha sido un sistema de mejor esfuerzo. Y cuando funciona, funciona muy bien para mucha gente. Cuando no funciona, pueden producirse algunos fallos catastróficos que una red más sólida no tendría.

Clarke Rodgers (01:48):
¿En qué momento te diste cuenta de que no se había tenido en cuenta la seguridad? ¿Y qué pensaste que tenía que pasar?

Paul Vixie (01:56):
Empecé a dar la voz de alarma muy pronto y mi preocupación inicial era el spam. No teníamos autenticación, nada que impidiera que las personas enviaran tráfico no deseado, porque en una red exclusivamente gubernamental, no había nadie que se beneficiara del envío de tráfico no deseado.

Así que di la voz de alarma ya en el 92. Y después de dedicarme solo a la consultoría, etc., también empecé el primer proyecto antispam, que se convirtió en la primera empresa antispam. Y nuestro sistema de reputación distribuido fue el primero de su tipo. Ojalá lo hubiera patentado. Quiero decir, ese sistema todavía se sigue usando mucho hoy en día, aunque la empresa en la que empecé a luchar contra el spam fue demandada hasta que acabó por desaparecer. Así que esa empresa ya no existe. Pero la idea y las tecnologías siguen vivas y, definitivamente, estuve en lo cierto desde el principio.

Clarke Rodgers (02:57):
Entonces, ¿te motiva el hecho de que la seguridad se tome más en serio, no solo por parte de los grandes proveedores de servicios en la nube, sino también de las empresas de clientes? ¿Te da esperanzas?

Paul Vixie (03:13):
Me da esperanzas, aunque también me produce cierta decepción, porque todo lo que estamos haciendo es muy poco o se hace muy tarde. Pero hay que esperar a que el mercado entero despierte y vea el problema. No puedes hacer saltar las alarmas siendo solo una única persona o empresa.

Algo que me hace tener esperanza es la colección de tecnologías con las que me topé cuando llegué a Amazon. Resulta que, a gran escala, hay algunos problemas que se pueden generalizar y soluciones que luego se pueden implementar, algo que no pueden hacer empresas de menor tamaño que trabajan a pequeña escala. Por ejemplo, lo que hemos hecho en los procesadores Graviton para que nuestras máquinas virtuales sean más seguras frente a otras máquinas virtuales, somos los únicos que lo hemos hecho.

Si nos fijamos en el conjunto de chips Nitro y el hipervisor Nitro, somos los únicos que lo hemos hecho. Cuando apareció Log4j, por ejemplo, nos vimos afectados, pero teníamos un parche para todos nuestros clientes en unas pocas docenas de horas porque somos lo suficientemente grandes como para saber cómo hacerlo y poder implementarlo con rapidez de forma global, mientras que en un sistema menos centralizado en el que cada uno es responsable de lo suyo hay que esperar a que la cadena de suministro se active.

Y muchas de las cosas que hacíamos al principio con pocos medios, cuando los transistores costaban un dólar cada uno, están desapareciendo gradualmente. Además de no hacer las estupideces que nos ayudaron a llegar al mercado más rápido que los protocolos OSI, no hay otra forma de solucionar este problema excepto con nubes como la nuestra.

Clarke Rodgers (05:09):
De cara a los próximos dos años, ¿hay alguna tecnología o metodología en particular que te entusiasme especialmente y que pienses que va a ayudar no solo a empresas como la nuestra, sino también a nuestros clientes a seguir adelante con sus cargas de trabajo de seguridad y cumplimiento?

Paul Vixie (05:31):
Bueno, sin duda, una cosa que es alentadora a nivel interno es el funcionamiento de los contenedores. El hecho de que podamos tener 10 000 de ellos funcionando en un solo chip y poner en marcha miles de ellos por segundo si hay un pico de carga, pero sin que sea necesario que alguien cambie por completo la forma en que hacían su ingeniería de software, es alentador porque, a medida que las personas pasen a ese modelo, nos alejaremos del problema que tenemos ahora, por ejemplo, con los parches.

Todos los días hay algo que necesita un parche. Y a menos que tengas un equipo dedicado a eso, lo vas a posponer y lo harás una vez a la semana, una vez al mes, o algo así. Y cuando lo hagas, es posible que te des cuenta de que “vaya, para que este parche se adapte al sistema que tengo, también tengo que actualizar estas otras cosas, lo que significa que tengo que ponerlo todo en un laboratorio de pruebas”. Por lo tanto, podrían pasar meses desde el momento en que descubras que algo realmente necesita un parche hasta el momento en que por fin tengas ese parche en el sistema.

No creo que podamos llegar al glorioso futuro de Star Trek en el que todo funciona si seguimos por ese camino. Por lo tanto, cosas como los contenedores, ya sean Lambda, Kubernetes o Firecracker, te dan la oportunidad de hacer que tu canalización, lo que se llama CI/CD, cree una imagen y la ejecute durante sus pruebas y, si se aprueba, puedas ponerla en servicio.

No es necesario tener una máquina virtual que tenga suficientes herramientas y lógica integradas como para poder acceder a ella y hacer que se aplique un parche. Eso es lo que hacemos hoy: no va a escalar. Ya se le notan algunas grietas, aunque sigo haciéndolo así porque ese es el mundo en el que crecí, pero no recomiendo a otros que lo hagan. No hay razón para hacerlo y sería muy beneficioso si pudiéramos ponernos de acuerdo: “sí, vamos a crear cosas y luego no las vamos a tocar”.

Por lo tanto, la idea de que vamos a dejar de tener a los humanos involucrados es otra cosa alentadora. Y me entristece decirlo porque los humanos inventaron y desarrollaron esto, pero tenemos que reducir el elemento humano ahora si queremos tener una seguridad que no se reduzca con el tiempo.

La cantidad de software y hardware que se interpone entre un ser humano y el valor entregado a un cliente es mayor que nunca. Y nuestra comprensión se ha mantenido relativamente fija; es decir, entendemos una fracción más pequeña cada vez que crece. Eso no va a funcionar. Vamos a tener que averiguar cómo asegurarnos de que la complejidad no genere resultados indeseables. Y de nuevo, eso depende de tener más disciplina y de mantener a los humanos al margen.

Clarke Rodgers (08:18):
Con la idea del acceso humano y las redes, la idea de Zero Trust ha evolucionado a lo largo de los años. ¿Qué opinas sobre Zero Trust, tanto desde la perspectiva de AWS, por ejemplo, cómo pensamos las cosas e implementamos las cosas internamente, como también desde la perspectiva de los clientes, cómo deberían ver Zero Trust?

Paul Vixie (08:39):
El elemento clave e irreductible de Zero Trust se malinterpreta. Por ejemplo, he oído hablar de esto a personas que dicen: “ponlo todo en línea, haz que todo sea accesible y asegura los servicios y los servidores en sí mismos. Asegura la red sin tener un perímetro”. Ese no es el objetivo de Zero Trust y no funciona. Sigues necesitando un firewall, solo que una vez que estés dentro del firewall, no descubrirás que tienes algún tipo de confianza especial solo porque estés dentro del perímetro.

Por lo tanto, está acabando con la suposición de que la accesibilidad implica fiabilidad. Se solía decir que había una parte externa sólida y una parte interna suave y mullida. No queremos tener una parte interna suave y mullida por mucho que tengamos una parte externa sólida. Así que necesitas un sistema que automatice la identidad, la autenticación y los permisos a escala. Por ejemplo, mientras tú y yo mantenemos esta conversación, se producen un par de miles de millones de eventos de autenticación por segundo en la nube de Amazon.

Y no utilizamos ningún tipo de truco barato, como almacenar en caché los resultados recientes y decir “bueno, si tenías permiso hace un segundo, probablemente todavía lo tengas”. No, lo comprobamos cada vez y, en algún momento, nos armamos de valor y decidimos que eso era “lo mínimo para que la seguridad sea la máxima prioridad”.

Pero, repito, la mayoría de los sistemas se diseñaron con la idea de que, si podías entrar, ya que no tenían un control de acceso detallado que funcionara a gran escala, simplemente te permitían hacer lo que quisieras. Eso es lo que estamos cambiando. Y hay varios estándares de autenticación diferentes. El nuestro fue el primero y es muy grande, pero nunca pretendió ser un estándar de la industria. Y hay otras nubes que tienen cosas similares en las que están trabajando y algunos estándares de la industria que están intentando establecerse.

Y por lo que sé, sin haber hablado con el equipo de servicio, nos aseguraremos de que cualquier cliente que quiera operar de esa manera pueda hacerlo.

Clarke Rodgers (10:49):
En el último año, más o menos, la IA generativa ha acaparado todos los titulares y prácticamente aparece a diario en mi resumen de noticias. ¿Qué opinas al respecto desde la perspectiva de un profesional de la seguridad? ¿Cómo crees que los profesionales de seguridad la utilizan para ayudar a proteger, investigar, ese tipo de cosas?

Paul Vixie (11:10):
Por lo tanto, hay que dejar de lado esa sobreexpectación y pensar “¿en qué quedará cuando se asiente?”. Y en algunos casos, no lo sabemos. Es una tecnología bastante nueva y se está diseñando una gran cantidad de hardware y software para ella. Y nunca se sabe realmente cuál será el impacto de una herramienta hasta que no la utilice alguien que no sea su creador. Si usas una llave inglesa como un martillo, probablemente no sea lo que el fabricante de llaves inglesas pensó que ibas a hacer, pero podría funcionar en algunas situaciones.

No hemos visto indicios sólidos de lo que será capaz de hacer una vez que se acabe esa sobreexpectación y haya otra cosa acaparando los titulares. Dicho esto, en Amazon hemos estado investigando, desarrollando e implementando soluciones basadas en IA durante al menos los últimos doce años. Por lo tanto, esto no fue una sorpresa del todo para nosotros.

Ya tenemos un ejemplo en el sistema CodeWhisperer de algo que utiliza técnicas de IA generativa pero que no se parece en nada a lo que ha acaparado los titulares. Veo que eso ocurre en todo tipo de sistemas. Por ejemplo, cuando detectas anomalías, observas los flujos de telemetría del sistema, estás fijándote en los eventos que indican que quizá haya algo que va mal o en los que te indican que puede que alguien te esté atacando. Va a ser posible correlacionarlos mejor ahora que tenemos esta tecnología. Y de nuevo, siento que apenas hemos visto el 1 % de lo que será posible.

Así que, aunque, por un lado, desprecio ese ciclo de sobreexpectación y me gustaría que pudiéramos hablar en serio desde el principio, también entiendo que hay algo de mérito en este sentido. Estoy trabajando con algunos equipos de seguridad de AWS que están intentando responder exactamente a esa pregunta: “¿qué podemos hacer para ofrecer un mejor servicio a nuestros clientes ahora que esto está disponible de forma generalizada y todo el mundo lo entiende?”.

Clarke Rodgers (13:14):
¿Y luego ayudar a ese profesional de la seguridad humana con gran parte del trabajo duro desde una perspectiva tecnológica con herramientas de IA generativa?

Paul Vixie (13:25):
Sí, y no quiero que esto suene a publicidad, pero el mayor éxito de Amazon con nuestra nube siempre han sido los flujos de trabajo que permitimos a nuestros clientes adoptar y crear. Así que una de las primeras cosas que hicimos en el área de modelos de lenguaje de gran tamaño fue Bedrock. La idea es que si quieres utilizar un modelo de lenguaje de gran tamaño, ¿también quieres pagar el coste de la formación? ¿Quieres tener que construir el modelo?

Porque hacerlo puede llevar miles de horas o decenas de miles de horas de tiempo frente a la computadora, lo que sale muy caro. Y en lugar de eso puedes disponer de varios modelos prediseñados que aparecen en un menú y puedes elegir los que quieres, pero no tienes que pagar para copiarlos a tu propio sistema, simplemente puedes poner lógica en tu VPC o en lo que sea que estés haciendo en nuestro entorno de nube, que tiene acceso directo a las API que saben que tienen acceso a estos modelos de suscripción.

Así que, la premisa original, la cual desconocía y aprendí cuando llegué aquí, la premisa de la nube resultó ser que puedes tener una cantidad elástica de procesamiento, toda lo que realmente necesites, junto a una cantidad elástica de almacenamiento, una vez más, toda la que realmente necesites, sin penalización de acceso: así es cómo crecimos. Y ahora acabamos de replicar eso dentro de la IA generativa para que esas personas que quizás sean muy ambiciosas en su propio segmento del mercado puedan hacer con nuestra nube y nuestros LLM lo que siempre han hecho con nuestra nube sin LLM. Eso nos encanta. Me encanta porque el verdadero poder de esto será lo que nuestros clientes hayan hecho.

Clarke Rodgers (15:13):
Y que los clientes tienen esa confianza acumulada gracias a todas las herramientas de seguridad que han utilizado durante años y a otros aspectos que ahora se pueden aplicar a herramientas como Bedrock y cualquier otra cosa que se presente en el futuro.

Paul, gracias por participar y estar aquí hoy.

Paul Vixie (15:26):
Ha sido genial. Gracias de nuevo por invitarme.