El papel del director ejecutivo en el liderazgo de seguridad

Clarke Rodgers (00:05):
El liderazgo en seguridad tiene que empezar desde arriba. Cuando los altos directivos se sientan a debatir las estrategias empresariales, la seguridad no solo debe ocupar un lugar en la mesa, sino que debe ser la primera prioridad en la mente de todos.

Soy Clarke Rodgers, director de estrategia empresarial de AWS, y su guía para una serie de conversaciones con líderes de seguridad de AWS aquí en Executive Insights.

Mi invitado de hoy no necesita presentación: es Adam Selipsky, director ejecutivo de AWS. Escuche nuestra conversación sobre cómo se estableció por primera vez la cultura de seguridad en AWS, cómo es la comunicación entre el director ejecutivo y el director de seguridad de la información, y cómo Adam apoya las iniciativas de seguridad desde arriba. Gracias por acompañarnos.

Clarke Rodgers (00:46):
Adam Selipsky, director ejecutivo de Amazon Web Services. Muchas gracias por acompañarme hoy.

Adam Selipsky (00:50):
Es un placer estar aquí.

Clarke Rodgers (00:51):
Entonces, retrocedamos un poco en la historia. Estamos en 2005. Jeff Bezos le ha dado el visto bueno para seguir adelante y avanzar con este pequeño experimento llamado "AWS". ¿Cómo has abordado esas primeras conversaciones sobre seguridad con esos clientes? Y entiendo que hubo muchos clientes que en ese momento decían: «¿Qué es la nube?, «¿Qué es la computación distribuida?» Es posible que ni siquiera las tuvieran, pero ¿qué conversaciones de seguridad tenían lugar en ese momento, si es que había alguna?

Adam Selipsky (01:22)
Era un concepto muy nuevo y, ciertamente, para mucha gente no era intuitivo entregar las cargas de trabajo y hacer que se ejecutaran «en algún lugar». Por supuesto, por eso se llama «la nube»; significa que está en algún lugar. Por lo tanto, es entendible que hiciera falta mucha formación, pero todo realmente empezó a cobrar sentido para la gente cuando explicamos algunos de los aspectos fundamentales, de los cuales el más importante era que Amazon había tenido que ser muy bueno en todo esto porque AWS no existía.

Clarke Rodgers (01:49):
Seguro que sí.

Adam Selipsky (01:50)
Entonces, Amazon tenía que ser realmente bueno en la ejecución de una infraestructura que fuera altamente escalable, altamente disponible, altamente rentable y, por supuesto, muy segura y disponible desde el punto de vista operativo. Y realmente nos basamos en toda esa experiencia dentro de Amazon, que operaba a una escala en la que, francamente, aún en ese entonces no había demasiadas empresas que operaran, y se creó AWS. Una de las grandes premisas era que había mucho trabajo pesado indiferenciado. A veces lo llamábamos la «basura» de la infraestructura. Y la mayoría de las empresas realmente no deberían tener que ser buenas en esa infraestructura.

Si vendes automóviles, si haces streaming de películas, si te dedicas a la investigación de medicamentos, ¿por qué deberías ser bueno en la gestión de una infraestructura masiva, en mantenerla disponible y segura, y además hacer que sea de bajo costo para seguir avanzando e innovar? Esa era, claro, la tarea de AWS.

Clarke Rodgers (02:50):
Exacto.

Adam Selipsky (02:51):
Por lo tanto, tenía sentido que fuéramos realmente buenos en todas esas cosas. Entonces, como una de las principales premisas de todo eso, realmente debíamos explicar nuestro enfoque sobre la seguridad, que innegablemente era el trabajo principal de AWS.

Me aseguro de ser muy elocuente al respecto porque simplemente es más importante que cualquier otra cosa que hagamos. De hecho, lo tuvimos muy claro desde el principio. Solíamos decir que había muy pocos potenciales acontecimientos que pudieran producir la extinción de AWS, pero el problema de una seguridad incorrecta era una de esas pocas cosas que podía efectivamente constituir un acontecimiento para la extinción de la empresa, particularmente al principio. Y nos lo tomamos muy en serio.

Clarke Rodgers (03:44):
Entonces, ¿eso impulsó ciertos comportamientos en los equipos de productos mientras desarrollaban los nuevos servicios, como SQS, S3 y EC2?

Adam Selipsky (03:54):
La forma en que realmente nos hemos asegurado de tener la mejor y la mayor seguridad posible es mediante un modelo de propiedad muy bien definido. Realmente es... supongo que podríamos llamarlo una matriz. Por lo cual, tenemos un equipo de seguridad de gran escala, altamente experto y absolutamente de primer nivel. Contamos con miles de personas que se ocupan de nada más que de la seguridad. No muchas empresas pueden decir eso... no tendría sentido desde el punto de vista económico para la mayoría de las empresas.

Por eso, nuestro equipo de seguridad, nuestro equipo centralizado de seguridad de AWS, desarrolla muchas capacidades técnicas y cuenta con muchos expertos que ayudan a auditar, asesorar e impulsar estrategias. Al mismo tiempo, nuestros equipos de servicios, EC2, S3, DynamoDB, Connect, Amazon Bedrock, los que sean, son 100% responsables de su seguridad. El equipo de seguridad no se terceriza.

Por lo tanto, si surge cualquier problema con uno de nuestros servicios, el director general de ese servicio se encarga exclusivamente del mismo, asume total responsabilidad, se centra de lleno en él y, por supuesto, cuenta con la plena colaboración de nuestro equipo de seguridad. Y creo que incorporar esa seguridad a la cultura de nuestro equipo de servicios garantiza que luego la incorporemos efectivamente al servicio. Esto es fundamental. Incorporamos la seguridad al servicio desde el primer día, no la añadimos después. Siempre estamos mejorando la seguridad, claro, pero lo fundamental es que incorporamos una seguridad sólida y de nivel empresarial en todo lo que hacemos y en todos nuestros servicios desde el momento en que empezamos a desarrollarlos.

Clarke Rodgers (05:43):
Tiene mucho sentido porque el responsable del servicio está más cerca de lo que está construyendo. Así, conoce los riesgos y todo a lo que se enfrenta ese servicio en particular.

Adam Selipsky (05:52):
Bueno, ningún problema de seguridad va a ser introducido por un equipo de seguridad central. Sería introducido involuntariamente por su propio equipo. Por lo tanto, lo mejor es que su propio equipo sea el que primero lo detecte y lo solucione. Y realmente seguimos un enfoque seguro con un conjunto muy sólido de capacidades de nuestro equipo de seguridad.

Clarke Rodgers (06:09):
Por supuesto. Han pasado 17 años y medio desde el lanzamiento inicial, ¿cómo la seguridad, y cuando digo seguridad, también me refiero a las conversaciones sobre riesgo y cumplimiento, cómo ha evolucionado todo esto en sus interacciones con los clientes?

Adam Selipsky (06:26):
Creo que la conversación sobre seguridad comenzó con la pregunta: «¿de verdad es posible que esto sea seguro?» Y, por supuesto, lo hemos cubierto. Lo hemos superado rápidamente, y creo que hubo algunos momentos trascendentales en los que Netflix anunció que podían (y por cierto, son muy capaces de desarrollar cualquiera de estas capacidades), pero que decidían no hacerlo. Cuando anunciaron que básicamente iban a abandonar el negocio de los centros de datos y poner toda su infraestructura en AWS (lo que implicaba implícitamente toda la seguridad y toda la disponibilidad), creo que mucha gente tomó nota de eso. Y eso cambió el tono de las conversaciones.

Varios organismos gubernamentales, incluidos miembros destacados de la comunidad de inteligencia del gobierno de los EE. UU., declararon públicamente que AWS ofrecía mayor seguridad que la que tenían en sus propios centros de datos. Y una vez más, mucha gente, incluyendo grandes empresas, bancos, compañías farmacéuticas, etcétera, lo notó. Así que, como muchos de esos grandes clientes decían: «Este es un excelente modelo de seguridad, vamos a confiar estas funciones a AWS». Creo que muchas otras empresas se dieron cuenta.

Clarke Rodgers (07:35):
El año pasado, en la segunda temporada de la serie, tuve el privilegio de entrevistar al director de seguridad de la información de AWS y hablamos sobre los mecanismos de seguridad, sobre lo que funciona en las grandes organizaciones y sobre lo que no funciona tan bien. Y uno de los mecanismos más eficaces a los que hizo referencia fue la reunión semanal entre el director ejecutivo y el director de seguridad de la información de AWS. Y, por supuesto, indicó que esto marca la pauta para el resto de la organización. Mantiene al director ejecutivo informado de lo que está sucediendo en el ámbito de la seguridad. Mantiene al director de seguridad de la información informado sobre lo que es importante para el director ejecutivo.

Por lo tanto, la pregunta que tengo para usted es que me encantaría escuchar su punto de vista sobre esa reunión. No como profesional de la seguridad, sino su perspectiva como líder empresarial. ¿Cómo funciona esa reunión para usted?

Adam Selipsky (08:20):
En este caso particular, uno de nuestros muchos mecanismos de seguridad es esta reunión semanal que tenemos con mi director de seguridad de la información, Chris Betz. Como usted bien ha mencionado, da una señal cultural. Es una reunión semanal, no es broma. Y le damos prioridad. Su contenido es increíblemente simple. Analizamos los dos o tres principales problemas de seguridad que hayan surgido la semana anterior.

Siempre tenemos la reunión y siempre hay dos o tres problemas. Algunas veces, algunas reuniones pueden resultar más «interesantes» que otras, pero nunca dejamos de hacerlas. Siempre nos centramos en los problemas principales y los analizamos muy a fondo. Por lo tanto, no es una presentación. Muy al estilo de Amazon, se elabora un documento escrito, un resumen por escrito del problema de seguridad. Este se examina cuidadosamente antes de la reunión, se completa y contiene la información exacta sobre dónde estamos parados y cuáles son los próximos pasos a seguir en relación con ese problema de seguridad. Y todos los miembros del equipo de servicios correspondiente y, por supuesto, del equipo de seguridad, así como cualquiera que esté directamente involucrado, todos están presentes en esa reunión.

Y definitivamente es muy formativa. A veces todo resulta cómodo y, otras veces, francamente, menos cómodo, porque nos lo tomamos muy en serio. Si vemos algún problema que deba solucionarse, algún comportamiento que deba cambiarse, algo que necesitemos hacer de manera diferente desde el punto de vista técnico para garantizar los resultados que queremos, entonces seremos muy abiertos al respecto en esa reunión. Por lo tanto, creo que eso también envía una señal cultural de que nos tomamos esto muy en serio. Por lo tanto, técnicamente nos ayuda a mejorar. Y creo que también es importante desde el punto de vista cultural para reforzar que, de hecho, la seguridad sigue siendo realmente el trabajo principal de Amazon.

Clarke Rodgers (10:13):
Hablemos de algo relacionado, su línea de líderes empresariales. ¿Cómo hace que asuman responsabilidad por la seguridad de su servicio particular o por otro negocio que lleven a cabo en AWS?

Adam Selipsky (10:24)
Bueno, en general, ellos mismos se hacen responsables. Y esa es la cultura que hemos creado en torno a esto, que es, por lejos, una mejor respuesta que la de que alguien más intente hacer que asuman su responsabilidad. Por eso, creo que con la cultura que hemos creado en torno a la seguridad, con el claro modelo de propiedad que hemos establecido que realmente forma parte de su trabajo diario, no es algo adicional. Además, con mecanismos como la reunión semanal de seguridad, a la que por supuesto asisten si es su equipo el que tiene un problema esa semana, creo que eso realmente crea muchas fuerzas diferentes para impulsar su responsabilidad. Y es mucho más fácil y mejor así.

Es importante tener un equipo de seguridad centralizado. Son los verdaderos expertos en todo lo relacionado con la seguridad. Pueden analizar las mejores prácticas en todos nuestros equipos. Son ellos quienes pueden garantizar que, si hay algún equipo en el que sospechemos que necesitamos hacer algo diferente en materia de seguridad, puedan hablar con los líderes de ese equipo, ya sean líderes técnicos o empresariales. Por lo tanto, realmente creo que tener estos múltiples mecanismos que se unen es lo que realmente hace que ese equipo asuma la responsabilidad.

En las raras ocasiones en las que hay un problema con el equipo, se hace evidente de inmediato que esperamos que ese equipo comprenda el problema y que ese equipo solucione el problema. Por supuesto, van a recibir ayuda de quien la necesiten, pero el problema es de ellos.

Varios organismos gubernamentales, incluidos miembros destacados de la comunidad de inteligencia del gobierno de los EE. UU., declararon públicamente que AWS ofrecía mayor seguridad que la que tenían en sus propios centros de datos. Y una vez más, mucha gente, incluyendo grandes empresas, bancos, compañías farmacéuticas, etcétera, lo notó. Así que, como muchos de esos grandes clientes decían: «Este es un excelente modelo de seguridad, vamos a confiar estas funciones a AWS». Creo que muchas otras empresas se dieron cuenta.

Clarke Rodgers (11:53):
Creo que ese es un punto muy importante a destacar, que ese líder empresarial sea responsable tanto de la seguridad así como de la funcionalidad del producto que está creando y de las pérdidas y ganancias, ¿verdad? Muchos de nuestros clientes tienen esas responsabilidades por separado y, a veces, surgen problemas por eso, pero tener ese único camino de responsabilidad es fantástico.

Adam, muchísimas gracias por tomarse el tiempo de su ocupado día para reunirse conmigo hoy.

Adam Selipsky (12:16):
Es un placer. Gracias.