Elevar los estándares de seguridad en AWS y más allá

Clarke (10:27):
No creo que todos los desarrolladores que trabajan en AWS inicien necesariamente con una amplia experiencia en ingeniería de seguridad. ¿Qué tipo de mecanismos existen para conseguir que esos desarrolladores alcancen los estándares que se han establecido para la seguridad de AWS? Especialmente en las herramientas para creadores o incluso en los productos de seguridad orientados al cliente.

Eric (10:50):
Existen dos maneras de plantearse esta pregunta. Por un lado, la seguridad en Amazon es una disciplina para creadores. No podemos hacer todo lo que tenemos que hacer. No es posible escalar con el negocio si esto se hace únicamente a través de incorporar ingenieros al equipo. Por lo tanto, gran parte de nuestro trabajo consiste en crear herramientas. Consiste básicamente en desarrollar software, como se haría en cualquier otro equipo de Amazon, salvo que uno crea herramientas de seguridad. En consecuencia, muchos de nuestros ingenieros no son ingenieros de seguridad ni tienen experiencia en seguridad. No es necesario contar con experticia particular en seguridad para formar parte del equipo. A algunos les apasiona la seguridad, a otros simplemente les gusta el trabajo y el equipo en el que trabajan y son muy felices con lo que hacen, pero no tienen un interés particular en la seguridad, y eso está bien.

Eric (11:37):
La seguridad se basa en averiguar qué suposiciones ha hecho algún desarrollador y luego averiguar cómo violar esas suposiciones para llevar el sistema a un estado inesperado. ¿Qué ocurre si se introducen los datos de un disco duro entero en este campo? ¿Qué pasa cuando se aumenta la presión? ¿Qué ocurre cuando se introduce un número negativo en este campo? En mi experiencia, las personas que piensan así tienden a hacerlo de forma natural, por lo que no es fácil enseñar esa mentalidad.

Eric (12:18):
Cuando encontramos a alguien con esa mentalidad, podemos enseñarle todos los conocimientos específicos de seguridad, así como todas las tecnologías que se utilizan a diario. Podemos fácilmente otorgarles esas capacidades. Nada de lo que hago actualmente de forma cotidiana existía cuando estudié en la universidad. Los fundamentos que aprendí durante la carrera aún son válidos, pero ninguna de las tecnologías específicas lo son. Por eso, contamos con un programa muy sólido para aumentar la capacidad de las personas que tienen ese tipo de perfil de seguridad.

Eric (12:46):
La respuesta al interrogante es entonces doble. Existe un conjunto de personas para quienes no es necesario incrementar sus capacidades de seguridad. Se trata de un trabajo de desarrollo estándar. Es la función estándar de un desarrollador. Y se destacan. Y algunos manifiestan su interés por la seguridad, lo cual es estupendo, por lo que lo alentamos. Pero no es necesario. Por otro lado, encontramos a personas que tienen interés natural en saber cómo se pueden descomponer las cosas. La pregunta “¿Cómo se descomponen las cosas?” conduce naturalmente a “¿Cómo se arreglan de modo que no se puedan volver a descomponer?”. Así, podemos enseñar a la gente todas las habilidades específicas del trabajo.

Clarke (14:03):
En este sentido, o supongo que a la inversa, muchos de nuestros clientes, al intentar desarrollar una habilidad en seguridad dentro de sus propias comunidades de desarrollo, una de las opciones que eligen es asignar a un experto en seguridad a un “equipo de desarrollo normal” para que ayude a mejorar el nivel de seguridad dentro de ese equipo y, básicamente, se convierta en el promotor de la seguridad. Como tenemos un número limitado de profesionales de la seguridad, intentamos repartirlos entre los equipos de desarrollo y, al final, todos los equipos prosperan. ¿Ocurre algo parecido en AWS y Amazon, en cuanto a la forma en que concebimos las cosas, o bien, dado que la seguridad está integrada en nuestro ADN, todos son conscientes de que “tengo cierta responsabilidad en cuanto a la seguridad de la aplicación y, por lo tanto, voy a seguir el proceso”? ¿Podría explicarnos brevemente cómo funciona esto?

Eric (14:58):
Por supuesto. La seguridad es una labor fundamental. Tenemos la convicción esencial de que, al igual que la escalabilidad, la disponibilidad, la baja latencia y la baja fluctuación, la seguridad forma parte de la experiencia del cliente. Forma parte de todo aquello que creamos. No obstante, la habilidad en seguridad es poco común. No disponemos de tantos ingenieros de seguridad como nos gustaría tener. Me encantaría que todos los desarrolladores de nuestro equipo de trabajo fueran también expertos en seguridad. No espero que esto ocurra pronto. Es interesante que haya utilizado el término “promotor de seguridad”, porque se relaciona con el nombre del programa que tenemos internamente, en el que buscamos a personas con mentalidad de seguridad dentro de los equipos de servicio y les ofrecemos formación y apoyo para que aumenten sus habilidades de seguridad y puedan influir en sus equipos de servicios.

Eric (16:38):
De esta forma, cuando se toma una decisión importante, no tendrán que adoptar una posición solitaria y decir: “Yo, como único promotor de la seguridad, creo que esto no está listo para el lanzamiento, o que es necesario efectuar una tarea adicional”. Existe una organización de seguridad completa a la que se puede recurrir y con la que es posible trabajar conjuntamente desde una perspectiva de obsesión por el cliente en aras de determinar qué es lo más adecuado para los clientes. Si se suministra un servicio inseguro, el resultado es negativo para los clientes, pero si no se suministra el servicio… Un servicio que no existe no deleita a ningún cliente, por lo que hay que encontrar el equilibrio adecuado. Al contar con un experto en seguridad integrado en el equipo de servicios, que está profundamente comprometido con el equipo de servicios, así como con expertos del equipo de seguridad de AWS que también están comprometido con el equipo de servicios, pero que actúan principalmente como auditores, se toman decisiones mucho más acertadas y mucho más rápidas.

Clarke (17:28):
Y supongo que eso alivia… De nuevo, en muchas de las conversaciones que mantengo con los clientes, el departamento de seguridad es percibido como el departamento del no, o es el departamento que se debe evitar para poder lanzar la aplicación. Bajo el modelo que acaba de exponer, parece que se amplía la confianza y todos se dan cuenta de que la seguridad forma parte del trabajo y de que así es como se procede en Amazon, en nuestro caso. El resultado final es un producto más seguro que sale al mercado.
 
Eric (18:00):
Hace un tiempo intentamos formular la declaración de la misión. Una manera de expresar aquello que hace el área de seguridad de AWS. Y lo mejor que se nos ocurrió fue: “suministrar con seguridad”. Son tres palabras que creo que reflejan muy bien la razón de nuestra existencia. Se trata de una empresa que no se dedica a la seguridad. Se llama Amazon Web Services, no se llama Amazon Security. Por lo tanto, nos encargamos de suministrar esos servicios web a los clientes. Si no se suministran, no se ejecuta. Nuestras tareas no son precisamente la actividad social de AWS. Por lo tanto, nuestra misión es hacer posible el negocio. No somos el motivo del negocio. No obstante, es imposible tener este negocio si no se cuenta con una seguridad ejemplar, pero nosotros somos únicamente una faceta del negocio.
 
Eric (18:44):
Lo más importante para nosotros es el apoyo que recibimos de los ejecutivos. Evidentemente, la seguridad es increíblemente importante y eso se transmite desde arriba. No decimos: “Somos el equipo de seguridad, tienen que escucharnos”. Presten atención, por favor…” No tengo que enfrentar ese problema. Desde el director general hacia abajo, se ha marcado la pauta. Todos son conscientes de que la seguridad es importante.
 
Clarke (20:04):
Gracias. Con respecto a la medición de un programa de seguridad, específicamente en el caso de los desarrolladores y otras personas que escriben código en AWS, ¿cuáles son algunas de las métricas clave que se utilizan para medir la eficacia del programa de seguridad con la comunidad de desarrolladores de AWS?
 
Eric (20:57):
Hay dos puntos en los que se aplican las métricas.
 
Eric (21:43):
No es conveniente medir el tiempo que se tarda para cerrar un ticket. El ticket tarda en cerrarse lo que tarda el ticket en cerrarse. Lo que sí se mide es nuestra capacidad de respuesta. Contamos con acuerdos de nivel de servicio para la primera intervención. Por ejemplo, si envía un correo electrónico al área de seguridad de AWS, públicamente indicamos que obtendrá una respuesta de una persona en un plazo de 24 horas. Eso se mide. De hecho, contamos con gráficos y tablas que miro cada semana y que muestran: “Este es el tiempo que tardamos en responder a las personas que nos envían correos electrónicos”. La capacidad de respuesta es, por tanto, muy importante. En primer lugar, porque al no reaccionar, se pierde la confianza de la gente. En segundo lugar, el hecho de que se responda suele indicar que hay acciones positivas en curso.
 
Eric (22:25):
Otro ámbito en el que aplicamos un pensamiento similar es en el estancamiento de la resolución de tickets.
…
Todo se gestiona a través de tickets. En consecuencia, hemos incorporado una gran cantidad de automatización en el sistema de emisión de tickets para asegurarnos de que si un ticket se estanca, y medimos tanto la cantidad de tiempo entre la correspondencia del equipo de servicio como la cantidad de tiempo entre la correspondencia del equipo de seguridad, y así sabemos cuándo los tickets decaen, sabemos cuándo estamos bloqueados en el equipo de servicio o el equipo de servicio está bloqueado en nosotros, y podemos sacar a la luz muy rápidamente los tickets que necesitan atención inmediata. Esto también nos proporciona los datos necesarios para realizar análisis introspectivos y retrospectivos y descubrir qué procesos no funcionan, en qué lugares hay que cambiar el personal y en qué partes hay que invertir en mejores herramientas. Medimos los procesos en torno a la seguridad y descubrimos qué es lo que realmente impulsa los resultados correctos en materia de seguridad.
 
Eric (23:20):
Otra cosa que medimos activamente no es si acertamos o no. Dedicamos gran cantidad de tiempo a la seguridad de las aplicaciones para diseñar un buen servicio, pero Amazon nunca lanza nada y se desentiende. Agregamos regularmente funciones, respondemos con frecuencia a la retroalimentación que nos proporcionan los clientes y nuestros servicios cambian rápidamente en base a dicha retroalimentación. Nuestro objetivo no es hacer un lanzamiento seguro, sino que el servicio se mantenga seguro durante toda su vida útil, lo cual implica que las tareas que se realizan durante la revisión inicial de la seguridad de la aplicación rápidamente pierden vigencia y valor. Parte del proceso de seguridad de las aplicaciones consiste en determinar las invariantes, las afirmaciones que siempre deseamos que sean verdaderas sobre el servicio, para luego averiguar cómo se van a verificar esas invariantes en el código.
 
Eric (24:10):
Si un servicio siempre debe rechazar una solicitud con un formato determinado, debe haber un valor controlado que se encargue de invocar ese servicio en producción que tenga una solicitud con ese formato en particular para asegurarse de que se rechace. Y posteriormente se miden los valores controlados. ¿Qué parte de la superficie del servicio abarcan? ¿Con qué frecuencia se ejecutan? ¿Con qué frecuencia arrojan un error? ¿Con qué frecuencia obtienen resultados anómalos? Se miden esos procesos, con lo que se valida nuestra posición de seguridad. No se trata de medir la seguridad suministrada. Eso es difícil de medir. En cambio, se miden los retrocesos en los niveles de seguridad ya establecidos. Esto es increíblemente importante porque siempre se presentará otro problema de seguridad. Nuestros equipos son innovadores, no dejan de idear servicios nuevos y emocionantes que no hemos tenido que proteger antes. Es otra de las cosas que me motivan para venir a trabajar todos los días.
 
Clarke (26:00):
Eso es fantástico. Una pregunta relacionada, pero desde la perspectiva del cliente, hay algunos clientes que están sumamente avanzados, que trabajan con infraestructura como código a través de una canalización CI/CD hacia la producción. Por otra parte, hay clientes que se limitan a usar la consola para actividades que solo requieren apuntar y hacer clic. Según mi experiencia, la mayoría de nuestros clientes se encuentran en algún punto intermedio, e intentan alcanzar el “nirvana” que ofrece la infraestructura como código. ¿Qué consejo daría a los directivos de los clientes para que se centren más en la ingeniería que en los aspectos operativos de apuntar y hacer clic en la administración de una infraestructura?
 
Eric (26:42):
Nunca he creado algo hermoso. He creado cosas por las que me siento increíblemente orgulloso, cosas que han funcionado muy bien en el marketplace, ya sea el público de los servicios de AWS o el interno donde nuestros clientes son nuestros propios equipos de servicio y otros compañeros de Amazon. Pero todos son sistemas que comenzaron con el núcleo de una idea que creamos como lo más pequeño que podíamos crear para deleitar a los clientes, para luego iterar tan rápido como pudimos. Y crecieron a lo largo del tiempo. Es gracias a la iteración que se consiguen herramientas magníficas. Las personas cercanas a ellas las consideran el monstruo de Frankenstein. Es ese pedazo de basura, como si fuera todo alambre de embalar y cinta adhesiva, como si lo hubiera creado MacGyver. Pero a decir verdad, se trata de magníficas herramientas. Son increíblemente eficaces. Y dado que se crearon para la función que desempeñan, gradualmente, paso a paso, cumplen su misión.
 
Eric (27:42):
Cuando alguien llega, tanto si es para incorporarse al equipo como si se trata de un cliente al que le explicamos cómo funcionamos internamente, se encuentra con todo este conjunto de herramientas de las que disponemos, todos los mecanismos que hemos creado, y resulta abrumador. Da la impresión de que no es posible replicarlo. En primer lugar, no es necesario replicarlo. Esto es para gestionar nuestros problemas de seguridad específicos. En segundo lugar, no creamos estas cosas, sino que las hicimos crecer con el tiempo, y todas ellas empezaron como algo pequeño. Se trata de un enfoque gradual. Cuando recién hablábamos sobre las métricas, mencioné que no había retrocesos, de no tener que resolver el mismo problema dos veces. De mejorar todos los días. Todos los días se eleva el nivel de seguridad y aparece así el crecimiento exponencial.
 
Clarke (29:34):
¿Para los clientes que ven esto, la idea es, básicamente, empezar poco a poco con los esfuerzos de ingeniería y luego simplemente crecer con el tiempo y conseguir que estos sean cada vez mejores, en lugar de tener que cambiar el enfoque de todo de una vez?
 
Eric (29:48):
Por supuesto. La mentalidad de progreso gradual siempre produce resultados. Y se tiene que contar con profesionales de la seguridad que no tengan aversión al riesgo. A diario, todos convivimos con el riesgo. Cruzar la calle, conducir un automóvil y conectar un portátil a la red suponen riesgos. Por lo tanto, es necesario sentirse cómodo al asumir los riesgos adecuados. La seguridad es un arte, y me gustaría que fuera más bien una ciencia, pero creo que es el arte de gestionar esos riesgos, de comprender cuáles son aceptables, cuáles se pueden mitigar y cuáles son totalmente inaceptables. Como profesional de la seguridad, en cualquier función, en cualquier ámbito de la seguridad, hay que ser capaz de explicar la gravedad de un riesgo.
 
Eric (30:38):
En la organización de seguridad, al hablar sobre seguridad, una frase que usamos todo el tiempo es clínica y precisa. Si afirma: “Esta es la peor vulnerabilidad de seguridad de la historia, y no hay nada que podamos hacer para solucionarla”, va a perder una enorme cantidad de credibilidad. No dejó campo para sostener una conversación. Ya no es posible negociar sobre cuál es la mejor manera de avanzar. Simplemente agotó las posibilidades. En cambio, si dice: “Este es un asunto bastante preocupante. Me inquieta este impacto en particular. A continuación, les presentaré tres posibles maneras de proceder. Me gusta la primera que, aunque es más costosa, proporciona este determinado beneficio. Hablemos sobre el curso de acción que debemos tomar”. Es clínico, es preciso e instaura una conversación. Aporto mi experticia de modo que podamos sostener una conversación sobre el negocio. El ingeniero que crea este conjunto de herramientas de seguridad debe tener eso en cuenta. Debe considerar: “¿De qué manera contribuyo a mejorar el negocio?”, no: “Dios, todo se quema y todo está terrible”.