Ampliar la responsabilidad sobre la seguridad a lo largo de toda la organización

Clarke (00:05):
Megan, gracias por participar y estar presente hoy.

Megan: (00:07)
Sí, por supuesto.

Clarke (00:08):
¿Podría contarnos un poco acerca de su trayectoria y de cómo llegó a AWS?

Megan: (00:13)
He desempeñado diferentes funciones en el ámbito de la seguridad durante más de 15 años. Comencé como especialista en seguridad de redes para un hospital. Posteriormente, ingresé en un minorista global basado en Seattle y ayudé a desempeñar diferentes funciones de ingeniería y arquitectura de seguridad. De hecho, en 2014 nos convertimos en clientes de AWS y ayudé a establecer la estrategia de seguridad en la nube y a implementar los controles de seguridad correspondientes. Más adelante, trabajé en Slalom y formé parte de su equipo de operaciones de desarrollo y ayudé a clientes de toda América del Norte a hacer lo mismo: establecer una estrategia de seguridad en la nube e implementar controles de seguridad. Después, me uní a AWS como arquitecta de soluciones empresariales para la región del Noroeste del Pacífico y posteriormente entré a formar parte del equipo de especialistas en seguridad.

Clarke (01:02):
Genial.

Megan: (01:03)
Así que, he trabajado en AWS durante aproximadamente cuatro años. Sí.

Clarke (01:04):
Genial.

Megan: (01:04)
Gracias.

Clarke: (01:05)
Comenzó, según creo, con una formación en ciencias de la computación. ¿Qué le atrajo a la seguridad?

Megan: (01:12)
La verdad es que es una historia interesante. Al principio opté por la ingeniería mecánica y realicé prácticas en Boeing durante tres veranos, donde pude trabajar con los ingenieros de manufactura de la línea 767-400. Les pregunté: si fueran a la escuela en la actualidad, ¿qué estudiarían? La respuesta fue: ciencias de la computación. Lo cual me pareció interesante. De forma rotunda, todos dijeron lo mismo. Entonces, pensé: “De acuerdo, tomaré una clase de seguridad informática o de ciencias de la computación”. Y me encantó. Fue realmente divertido. Se trataba de resolver rompecabezas, ¿verdad?

Clarke (01:47):
Correcto.

Megan: (01:47)
La mitad de los alumnos se retiraron porque no era lo suyo. Yo seguí adelante. Uno de los cursos optativos era el de seguridad digital, lo que me pareció sumamente interesante. Tomé ese curso y me cautivó. Me pareció muy interesante. Son solo más rompecabezas que resolver, que cambian constantemente. De hecho, creé un Sistema de Detección de Intrusiones (IDS) como proyecto de grado para obtener mi título en ciencias de la computación. Creé un pequeño programa que analizaba las capturas de paquetes de red y determinaba los comportamientos de red nefastos. Fue realmente divertido.

Clarke: (02:21)
Genial. Evidentemente ese fue el origen de una gran carrera.

Megan: (02:23)
Sí.

Clarke: (02:24)
Se desempeña en AWS como arquitecta sénior de soluciones de seguridad. ¿Qué significa eso? ¿Y cuáles son sus responsabilidades principales en ese cargo?

Megan: (02:33)
Ayudo a los clientes con la seguridad de AWS. Me encargo de ofrecer orientación sobre cómo sentar las bases de la seguridad, establecer barreras de protección e implementar controles de seguridad, a la vez que ayudo a comprender: “¿cuál es el modelo operativo para la nube? ¿qué aspecto tiene?” También ayudo a educar a los clientes en eventos, talleres de creación, sesiones para creadores, así como en el campo interno. Contamos con algunos programas a nivel interno en los que realizamos ensayos de campo internos, en los que educamos sobre los diferentes aspectos de la seguridad. Logramos que pasen del nivel 100 de seguridad al nivel 300, de modo que sean más eficaces en las conversaciones con los clientes.

Clarke: (03:20)
Megan, en AWS, existe una cultura de seguridad muy fuerte y disponemos de muchos mecanismos destinados a aplicar esa cultura. ¿Hay algún mecanismo en particular que prefiera?

Megan: (03:29)
Sí, por supuesto. Uno de los procesos que existen es la presentación de un sev dos. Independientemente de quién sea dentro de la empresa, si cree que existe un problema de seguridad, el proceso consiste en presentar un ticket, que se conoce como sev dos. Esto es atendido por una persona encargada, es decir, un ingeniero de seguridad que ayudará a evaluar si se trata de un problema o no, y a asumir la tarea a partir de ahí. No hay ningún inconveniente si no se trata de un problema de seguridad. Es genial. Además, no se asignan culpas. Se trata de que nadie se sienta preocupado o intimidado por pensar que existe un problema de seguridad. Queremos enterarnos. Queremos reaccionar ante cualquier problema, de una buena manera, de una forma positiva. Esto cuenta con el respaldo de la dirección, lo que es realmente bueno. Con frecuencia, cuando se imparte formación en materia de seguridad y se habla con los propios dirigentes, todos tienen una opinión favorable al respecto. Creo que eso fomenta una cultura de transparencia en torno a la seguridad y una apertura que creo que nunca había visto en ningún otro lugar. Es algo que realmente aprecio.

Clarke: (04:44)
Correcto. Al hablar con los distintos clientes con quienes trata en los diferentes niveles de las organizaciones, ¿existen áreas de interés particulares que fomente para ayudarles a crear su propia cultura de seguridad? ¿El tipo de cultura de seguridad sin asignación de culpas?

Megan: (05:01)
Sí, por supuesto. Y observo esto en un par de áreas. Acostumbro a invitar a los clientes a que conciban la operación de los equipos de seguridad como un factor que facilita el negocio y ayuda a los desarrolladores, de modo que se logre hacer lo que es sencillo y correcto desde una perspectiva de seguridad, para así allanar el camino que permita, al operar bajo el modelo correcto y con transparencia en torno a los requisitos de seguridad, acelerar el desarrollo y evitar obstáculos, para decirlo de alguna forma. Considero que eso genera un equilibrio agradable entre la seguridad y el desarrollo en las instancias en las que trabajan conjuntamente. Realmente me encanta ver la forma en que esto da resultados con los clientes. Definitivamente es algo que he presenciado en un par de casos de clientes. Esto constituye una forma adecuada de operar desde el punto de vista de la seguridad y del desarrollo, de manera conjunta y con apoyo mutuo.

Clarke: (06:00)
¿De este modo, el área encargada de la seguridad deja de ser el departamento del “no”, para de hecho convertirse en un aliado que presta apoyo para alcanzar el éxito?

Megan: (06:05)
Sí, exacto.

Clarke: (06:07)
Desde el punto de vista del liderazgo de los clientes, ¿qué pueden hacer los máximos responsables de una empresa para ayudar a fomentar esa cultura de seguridad que intentamos forjar en las relaciones con los clientes?

Megan: (06:20)
Creo que bastante ha cambiado y ahora las cosas se hacen de una manera diferente a la tradicional El equipo de seguridad no es el único responsable por la seguridad, no puede serlo. Los desarrolladores deben adueñarse más del tema. De hecho, me encanta explicar a los clientes: “Existe el modelo de responsabilidad compartida entre AWS y el cliente”, pero ese modelo de responsabilidad compartida se amplía a todos los diversos controles de seguridad y aspectos de seguridad para la nube en el resto de la organización y de forma transparente todos son conscientes de la responsabilidad que tienen.

Clarke: (06:53)
Correcto.

Megan: (06:53)
Posteriormente, ayudar a que esas cosas sean fáciles de hacer y sea sencillo hacerlas de forma adecuada. Se trata de ampliar el modelo de responsabilidad compartida dentro de la propia organización, de modo que sea tangible para todos. Creo que es una forma muy eficaz de proceder.

Clarke: (07:05)
Genial. Estoy seguro de que muchos de sus clientes cuentan con una cantidad de expertos en seguridad muy inferior a la que les gustaría tener. ¿Qué oportunidades ha detectado para que los equipos de seguridad amplíen su enfoque e influencia en el resto de la organización del cliente?

Megan: (07:22)
Se me ocurren un par de cosas. En primer lugar, creo que no siempre encontramos al profesional adecuado que buscamos para el cargo. Por lo tanto, a veces, eso implica ampliar un poco el horizonte y pensar: “Existe personal de seguridad que no necesariamente conoce la nube, pero que está interesado, por lo que es preciso encaminarlos para que se acerquen a esta”. De la misma forma, si cuenta con desarrolladores o expertos en DevOps que están interesados en la seguridad, pero que no tienen precisamente la formación necesaria, encamínelos para que lo consigan. Ofrezca parte de esa formación. Existen muchas herramientas disponibles para lograr ese objetivo. Uno de mis métodos favoritos es ver los videos de sesiones pasadas de re:Invent o re:Inforce. Reproduzca una sesión de 30 o 45 minutos sobre las prácticas recomendadas de seguridad básica. Muchos de los videos que hay disponibles son ejemplos bastante ilustrativos de cómo algunos clientes logran estos objetivos, lo que nos hace pensar de forma diferente a la convencional, por lo que creo que pueden resultar muy útiles. Además, obtener un certificado de arquitecto de soluciones de AWS asociado o profesional es una excelente vía para adquirir esos conceptos básicos. Además, por supuesto, la certificación de especialista en seguridad es realmente buena.

Clarke: (08:39)
Los últimos 18 meses, más o menos, han sido difíciles para todos. La pandemia ha aumentado la cantidad de personas que trabajan desde casa. ¿La pandemia ha provocado un incremento o una disminución en la cantidad de personas que adoptan la nube? ¿Qué percibe en los clientes?

Megan: (08:54)
Sí, por supuesto. He notado que varios grandes clientes han tenido que aumentar el uso de la nube para hacer frente a los cambios que se han producido. El negocio de la venta al por menor en línea se disparó porque los establecimientos físicos tuvieron que cerrar. Y creo que notamos algunos patrones interesantes surgir a partir de eso. Creo que a partir de ello se han adquirido lecciones para otros clientes, en función de cómo sentaron las bases iniciales de seguridad y el modo en que desarrollaron su estrategia de varias cuentas. Si fueron capaces de aprovechar la automatización para tal fin, realmente acertaron porque pudieron crear más cuentas e implementar la automatización. Ya tenían la automatización para sentar esas bases de seguridad y los controles estaban presentes. Mientras que, si no estaba automatizado, a veces ayudábamos, por supuesto, a crear algunos sin automatización y a ponerlos en marcha lo antes posible. Sin embargo, hacerlo manualmente es agotador y lento. Por lo tanto, creo que asegurarse de que todo está … automatizado será muy importante. Todas las barreras de protección, la estrategia de varias cuentas. Y este fue un muy buen ejemplo de cómo el mundo real impone eso. Cuando comencé como cliente de AWS, teníamos dos equipos de desarrollo que se dedicaban a experimentar. Seis meses después, ya eran 20 equipos de desarrollo, los sistemas se encontraban en fase de producción y todos los demás deseaban incorporarse a la plataforma. Por lo tanto, aprendí esa lección pronto y creo que muchos clientes tuvieron que vivir esa experiencia.

Clarke: (10:31)
Porque después había que volver a trabajar para cumplir con ese estándar de seguridad que se deseaba tener.

Megan: (10:35)
Sí, exactamente.

Clarke: (10:37)
Así que, por una tangente similar, los equipos de seguridad, los equipos de seguridad dentro de las cuentas de los clientes. ¿Hay alguna manera de que ese tipo de seguridad pueda allanar el camino a la nube para los clientes?

Megan: (10:50)
He notado esto con clientes en los que muchas veces la seguridad se queda en el último lugar. Pero no tiene que ser así. Creo que, si son capaces de utilizar el marco de seguridad que han adoptado en las instalaciones y tomar los controles y actualizarlos para la nube, realizar algún tipo de mapeo y, esencialmente, poner en marcha esas barreras de protección con antelación, todo será mucho más fácil. Estarán preparados para que las personas realicen implementaciones. Además, si no hay nadie que ejerza presión, estupendo. Puede tener algo así como métricas definidas. Es posible tener la automatización configurada sin que alguien tenga que presionar y decir: “Eh, vamos”. Además, creo que nos brinda la oportunidad, como equipo de seguridad, de ser transparentes en cuanto a los requisitos de seguridad, de ayudar a los desarrolladores a comprender cómo tienen que crear y qué especificaciones espera el equipo de seguridad. Y creo que, de nuevo, esto se remonta a la relación entre los desarrolladores y la seguridad y … Es una relación más eficaz y eficiente y sencillamente contribuirá a implementar las características empresariales que los desarrolladores intentan conseguir.

Clarke: (12:10)
Correcto. Me imagino que existe un cierto nivel de confianza que se construye una vez que se comprueba que el equipo de seguridad avanza hacia la nube con anterioridad y, como desarrollador o propietario del producto, uno cree: “Bueno, realmente ya no tengo ninguna excusa si el equipo de seguridad lo hace”.

Megan: (12:25)
Exactamente. Una de las cosas que he visto funcionar bastante bien con los clientes es cuando describen los requisitos de seguridad apoyados por ejemplos, como un sitio interno de Wiki que aborde temas como: “¿qué características tiene una política de identidad y acceso segura?, ¿”cómo se diferencia un buen grupo de seguridad de uno malo?”, entre otros ejemplos tangibles. Esto podría tener un impacto significativo. Y a esto nos referimos exactamente. Ninguna estrella de acción contra una estrella de recurso para las políticas de acceso. Ese tipo de cosas. Otro aspecto importante es que los equipos de seguridad se muestren disponibles, en caso de que un equipo de desarrollo se bloquee, independientemente de la razón. Por ejemplo, si un cliente tiene dificultades con respecto a un requisito de seguridad específico y el equipo de seguridad se encuentra disponible y presta atención durante el horario de oficina una vez a la semana, o a través de un canal de Slack, todo el proceso será más sencillo para los desarrolladores. Tienen un equipo al que pueden acudir. En muchas ocasiones desarrollan amistades con estos colegas, por lo que ya no tendrán que permanecer bloqueados por 24 horas ni nada parecido. Pueden sencillamente obtener retroalimentación de forma rápida. La retroalimentación quizá sea: “nuestra documentación es demasiado complicada” o “necesitamos especificar algo”; o, en caso de que se solicite a alguien arrancar un agente de seguridad en un host, ¿por qué no simplemente escribir un script y ponerlo a disposición de la persona encargada en un repositorio de código?

Clarke: (14:02)
Con respecto a lo que ha compartido, he notado que hay ciertas habilidades que quizá el equipo de seguridad promedio no tenga. Si examinamos un equipo de seguridad tradicional, notaremos que han llevado a cabo tareas como la ejecución del IDS y de diferentes servicios de red, la revisión de sistemas, entre otras; sin embargo, lo que escucho, y corríjame si me equivoco, es que ahora los equipos de seguridad realmente deben comprender cómo funcionan los ciclos de desarrollo e incluso deben saber cómo codificar. ¿Es ese el caso?

Megan: (14:33)
Sí, por supuesto. Creo que no … En función de la trayectoria del profesional de seguridad; quizá no se haya formado como desarrollador ni cuente con un diploma en ciencias de la computación, lo cual no es un requisito; no obstante, creo que saber un poco de programación con Python jamás será perjudicial y la formación en la nube es sencilla de adquirir. Ansible, es simplemente un archivo de configuración YAML. Además, creo firmemente que operar de forma similar a un equipo de desarrollo, mediante prácticas ágiles con una lista de tareas y un propietario del producto que gestione las prioridades desde una perspectiva de seguridad, resultará bastante útil. En primer lugar, comprender el modo en que trabajan los desarrolladores, que, de hecho, es una manera bastante eficiente de trabajar. Cuando trabajé como profesional, lo hacíamos de esa forma debido a que, particularmente desde el punto de vista de la seguridad, el ritmo del cambio es acelerado y los requisitos empresariales cambian rápidamente. De repente, es necesario escalar verticalmente y cambiar la manera en que se opera. Por lo tanto, es útil valorar y reorganizar las prioridades según una cadencia regular.

Clarke: (15:39)
¿Básicamente ejecutar la seguridad como un servicio dentro de una organización?

Megan: (15:44)
Sí, definitivamente.

Clarke: (15:46)
Genial. Cambiemos un poco de tema y centrémonos en algunas noticias que han ocupado los titulares recientemente. El ransomware, por ejemplo. No hay que indagar demasiado para encontrar una historia tras otra de ransomware. ¿Qué ha notado con los clientes y que consejo puede brindar con respecto a técnicas para mitigar el ransomware?

Megan: (16:11)
Probablemente he sostenido más de 20 conversaciones directas con clientes sobre ransomware en solamente los últimos dos meses. Me encantan este tipo de conversaciones porque me dicen cosas como: “queremos comprender qué mensajes transmite AWS”. Eso me indica que nos perciben como un socio, lo cual es genial. Usualmente tengo a la mano 10 prácticas recomendadas principales, puesto que no existe una solución milagrosa para el ransomware. Es indispensable contar con un programa de seguridad sólido y controles de seguridad fuertes, así como garantizar que estos funcionan de forma eficiente. También existen áreas clave que se deben abordar, por lo que examinamos asuntos como la estrategia de varias cuentas y el principio del acceso de privilegio mínimo. Hay un área en la que realmente insisto. Averiguo si tienen credenciales de administración de identidad estáticas y antiguas en alguna parte. Si ese es el caso, es hora de revisarlas cuidadosamente y de determinar, en primer lugar, ¿se necesitan? ¿es posible rediseñar la arquitectura? Y, en caso de que realmente se necesiten, como ocurre en algunos casos para el acceso híbrido, es preciso minimizar el acceso asociado a las credenciales de modo que se reduzca su impacto en el entorno y, posteriormente, supervisar cuando se utilizan y mantenerlas como un riesgo. Se deben anotar como un riesgo. No se pueden perder de vista. Adicionalmente, si en el futuro surge la oportunidad de deshacerse de estas, aprovéchela. Tiende a ser uno de los principales riesgos que notamos y queremos asegurarnos de que somos proactivos a la hora de ayudar a nuestros clientes a evitar eventos indeseados, por decirlo de alguna forma.

Clarke: (17:44)
Con base en lo que entiendo, la mitigación del ransomware consiste sencillamente en poner en práctica los aspectos básicos de la seguridad de manera extremadamente cuidadosa y correcta. ¿Es una interpretación adecuada?

Megan: (17:52)
Sí, lo es. Las revisiones son un concepto nuevo. Y, de hecho, se pueden realizar en AWS de diferentes maneras. Puede utilizar el método de quitar y reemplazar con un grupo de escalado automático y volver a lanzar los sistemas desde una canalización de CI/CD. Puede utilizar Systems Manager. Systems Manager es como una herramienta mitad operaciones, mitad seguridad en este punto. Es asombroso lo que puede lograr con esta. Así es. Existen muchas opciones. Y también las abordamos. Otro tema que han planteado los clientes, que creo que abre las puertas para sostener una buena conversación, es: “solíamos hacer copias de seguridad bajo la modalidad air gapping en las instalaciones. Teníamos literalmente copias de seguridad en cinta, y las colocábamos en un camión de Iron Mountain para que nadie pudiera tocar esas copias de seguridad. ¿Cómo hacemos eso en AWS?” Todo funciona con API, por lo que se encuentra conectado; no obstante, si se concibe la cuenta de AWS como el perímetro de seguridad, hay maneras de crear una cuenta separada con diferentes… y enviar las copias de seguridad a esa cuenta. Es posible automatizar con mecanismos de tipo push-pull para tener una cuenta de almacenamiento para las copias de seguridad. Y posteriormente, una cuenta separada desde la que puede extraer a partir de un buen origen conocido. Además, puede utilizar funciones como el bloqueo de objetos de S3, que es para escribir una vez y leer varias veces en ese bucket de S3, así como seguridad y controles realmente sólidos, y acceso reducido incluso a menos administradores de la cuenta. También está AWS Backup. Recientemente, creo que hace dos semanas, hace poco, anunciaron el Bloqueo de almacenes de AWS Backup, que tiene una funcionalidad similar que se aplica, en este caso, al almacén y permite escribir una vez y leer varias veces. De este modo, básicamente se evita que las copias de seguridad se modifiquen después de que se realizan. Por lo que no es posible eliminar nada. Por lo tanto, al utilizar el Bloqueo de almacenes de AWS Backup es posible establecer una política de acceso y evitar que personas realicen cambios. Es esencialmente similar al bloqueo de objetos de S3 en el sentido que los datos que ahí se almacenan no se pueden manipular durante cierto periodo.

Clarke: (20:05)
Entiendo. Además de algunas de las herramientas y prácticas recomendadas que ha mencionado, no he escuchado sobre la preparación de respuesta a incidentes. ¿Qué tan importante es y qué deben hacer los clientes al respecto?

Megan: (20:19)
Siempre que sostenemos estas conversaciones sobre ransomware específicamente, siempre pregunto a los clientes: “¿han hecho realmente un ejercicio práctico de un evento de seguridad de ransomware?” Porque los ejercicios prácticos son fundamentales. Si nunca ha trabajado en el ámbito de respuesta a incidentes, se puede tratar de una situación estresante. Los ejercicios prácticos constituyen una oportunidad para examinar muchos de los aspectos que no se necesitan gestionar durante un evento real, durante el cual querrá estar concentrado y tener la capacidad de investigar sin inconvenientes. El ejercicio práctico consiste, esencialmente, en indagar: ¿cómo se sabe que el evento ocurrió? ¿Tenemos acceso a todas nuestras cuentas de AWS para realizar las investigaciones necesarias? ¿Dónde se visualizaría el evento? ¿Provendría de nuestro centro de operaciones de seguridad? ¿Contamos con un manual de procedimientos que describa todas las actividades que las personas a cargo deben realizar para responder de manera coherente y disponer de todos los datos necesarios para tomar esas decisiones? Y, ¿se involucra a las partes interesadas adecuadas? Porque, en caso de que ocurra un evento de seguridad, debemos saber cómo comunicarnos con nuestros clientes y con sus clientes. Sencillamente resuelve muchos de nuestros problemas y nuestro equipo de servicio profesional puede intervenir y ayudar a que los clientes también lo logren. Lo hemos hecho en repetidas ocasiones y la práctica hace al maestro, ¿o me equivoco? Por lo tanto, siempre que tenga miedo de que un determinado escenario se materialice, la solución es practicar. Después de practicar, ya no tendrá tanto miedo. Es tan sencillo como practicar y mejorar en algo.

Clarke: (21:55)
Mencionó a las partes interesadas. ¿Se trata de un ejercicio que no se limita al equipo de seguridad?

Megan: (22:00)
Exactamente.

Clarke: (22:01)
¿Qué otras partes interesadas deberían participar en estos ejercicios prácticos?

Megan: (22:06)
Sí. El departamento jurídico con frecuencia participa, así como un equipo de privacidad, otro de administración de seguridad y, en función del tipo de ejercicio, según el incidente que se aborda, podría participar el servicio de asistencia técnica, así como los equipos de aplicaciones y desarrollo para facilitar la comprensión en caso de que fuera necesario algún tipo de mitigación, por ejemplo. ¿Cuáles serían los impactos posteriores de esa acción?

Clarke: (22:36)
¿Todos los niveles de la jerarquía de un cliente se involucran? ¿Participaría el director ejecutivo en uno de estos ejercicios prácticos? ¿Qué niveles? ¿Hasta qué punto?

Megan: (22:50)
Sí. También se trata de identificar quién desea participar y de que quienes participen comprendan el proceso, dado que cuando realmente ocurre un evento de seguridad, con frecuencia es confidencial. Se debe garantizar que únicamente las personas adecuadas se enteren, de modo que sea posible gestionar las comunicaciones de forma calculada. No obstante, en el marco de un ejercicio, no hay motivos para impedir que participen personas que desean hacerlo. Y, si el director ejecutivo está interesado en hacerlo, bienvenido.

Clarke: (23:21)
Genial.

Megan: (23:22)
Todos pueden aprender algo a partir de estos ejercicios.

Clarke: (23:24)
Otro tema que ha ocupado los titulares recientemente, sobre el que además preguntan los clientes, es el concepto de confianza cero. ¿Qué significa para usted la confianza cero?

Megan: (23:34)
Sí. Tradicionalmente, para los controles de seguridad y acceso que regían nuestro entorno, confiábamos bastante en el perímetro de la red. Sin embargo, actualmente, buscamos autenticar y autorizar llamadas a la capa de la API. Esto implica que, tanto si se trata de un usuario que accede a nuestro entorno, como si se trata de una llamada de API a API, queremos asegurarnos de que se autentica y autoriza cada paso en el camino de esa comunicación de red.

Clarke: (24:10)
Megan, gracias por participar el día de hoy.

Megan: (24:12)
Sí. Gracias. Fue realmente divertido.