AWS re:Invent 2022: Cómo Neiman Marcus adoptó un enfoque de seguridad centrado en los desarrolladores

En la conferencia AWS re:Invent de este año, Ravi Maira, vicepresidente de marketing de producto de Snyk, conversó con Omar Peerzada, arquitecto de ciberseguridad de Neiman Marcus, sobre cómo su equipo pasó de las prácticas de seguridad tradicionales a una estrategia centrada en los desarrolladores. Mira ahora la charla completa o sigue leyendo para conocer los puntos más destacados.

https://youtu.be/BH2GY5GrsQM

De la infraestructura heredada a la nube

Peerzada explicó que Neiman Marcus, una empresa con 100 años de historia, fue uno de los primeros minoristas en adoptar la transformación digital. Al inicio de la transición, la empresa trabajaba con mucha infraestructura y aplicaciones heredadas. Los problemas habituales de los sistemas locales (escalabilidad, rendimiento y seguridad) fueron los principales motivos que llevaron a Neiman Marcus a buscar alternativas a la infraestructura local y migrar a la nube.

Trazar el camino: ¿cómo fue la migración?

Maira preguntó: «¿Cómo fue la migración a la nube? ¿Cómo se llevó a cabo esa transformación?»

Después de investigar mucho, eligieron AWS como su socio de nube. Luego crearon un grupo llamado Cloud Center of Excellence, responsable de implementar las prácticas de DevSecOps en toda la organización. Crearon pipelines para garantizar que la seguridad estuviera integrada en distintas etapas. También ofrecieron una arquitectura escalable en la que los desarrolladores pudieran trabajar dentro de límites de seguridad.

Peerzada señaló que, con arquitecturas escalables en la era de la transformación digital, es fundamental no comprometer la seguridad. Ahora, en su sexto año desde que migraron a la nube, el equipo de Peerzada ha trasladado casi el 90 % de sus cargas de trabajo de la infraestructura local a la nube.

La pregunta clave: ¿quién es responsable de la seguridad en la nube?

«Entonces», dijo Maira, «ya migraste a la nube. Ya comenzaste la migración. ¿Cómo comenzó la parte de seguridad del proceso y cuáles fueron algunas de las primeras lecciones?»

La pregunta del millón que todas las organizaciones se hacen: ¿quién es responsable de la seguridad en la nube? ¿El equipo de DevOps? ¿El equipo tradicional de seguridad de la información? ¿O tienen un equipo de seguridad en la nube? Para responderla, hay que buscar la orientación de los líderes.

El equipo de Peerzada decidió que Cloud Center of Excellence era el más indicado para dirigir el programa de seguridad en la nube, porque era el «equipo sobre el terreno» que conocía el proceso de primera mano, aunque debía operar dentro de los límites establecidos por las políticas de seguridad de la empresa. Dentro de esos límites, el equipo podía elegir las herramientas de seguridad. Fue una decisión clave que permitió al equipo de Cloud Center of Excellence trabajar a escala sin bloquear a los equipos de producto en el entorno acelerado de la empresa.

Cómo encontrar las herramientas de seguridad en la nube

El equipo comenzó a implementar controles en AWS usando la infraestructura local como modelo y comparando ambos entornos en igualdad de condiciones. Sin embargo, se encontró con los mismos problemas de seguridad en la nube que tenía en la infraestructura local. Por eso, pronto cambió a las herramientas nativas de AWS, que le permitieron mantener la velocidad a un costo razonable.

El equipo de Peerzada implementó controles de seguridad de AWS. Desde el principio, la automatización fue su prioridad: configuraron varios controles de seguridad predeterminados y cifraron todo. Dieron prioridad a la «higiene cibernética básica» y se aseguraron de que los controles de administración de identidades y accesos fueran estrictos, lo que les ayudó a crear un marco de confianza cero. Habilitaron la corrección automatizada de controles clave; por ejemplo, en su lago de datos de AWS, usaron S3 para almacenar objetos y habilitar la corrección automática del cifrado de S3.

Cómo incorporar la seguridad de las aplicaciones

Maira preguntó entonces: después de abordar la seguridad en la nube, ¿cómo comenzaron a usar soluciones más tradicionales de seguridad de aplicaciones, como las pruebas estáticas de seguridad de aplicaciones (SAST) o el análisis de composición de software (SCA)?

Peerzada recordó que su equipo usaba varias herramientas de código abierto para realizar comprobaciones básicas de seguridad y calidad del código. Mientras se enfocaban en implementar su infraestructura en la nube en producción sin vulnerabilidades, el equipo de Peerzada se dio cuenta de que necesitaba mejorar la seguridad de las aplicaciones. Querían conectar los dos silos y aplicar a la seguridad de las aplicaciones la misma frecuencia de trabajo y el mismo ciclo de retroalimentación que ya tenían para la seguridad en la nube.

Nos faltaba cubrir un aspecto de la seguridad de las aplicaciones. Queríamos conectar de alguna manera estos dos silos, estos dos mundos, para asegurarnos de tener la frecuencia de trabajo adecuada y el ciclo de retroalimentación que teníamos para la seguridad en la nube... (y aplicarlos también) a la seguridad de las aplicaciones. Fue entonces cuando conocimos Snyk y entendimos que era exactamente lo que buscábamos.

El equipo comenzó a usar Snyk Open Source para analizar dependencias y paquetes de terceros como parte de su proceso de SCA. Luego conectaron Snyk a sus repositorios de Git para saber qué vulnerabilidades podían aparecer, y los resultados fueron inmediatos. Gracias al valor que aportó Snyk al permitir que los desarrolladores corrigieran vulnerabilidades, Neiman Marcus se convirtió rápidamente en cliente empresarial de Snyk.

Maira preguntó: «¿Cómo lograron que los desarrolladores se involucraran más en la seguridad?»

El equipo introdujo Snyk de manera gradual. Primero lo usaron en unos pocos proyectos críticos seleccionados: integraron los repositorios de Git y permitieron que los desarrolladores aprendieran poco a poco a trabajar con Snyk. Poco después, Snyk se convirtió en un paso obligatorio del proceso de incorporación de desarrolladores. Estos comenzaron a analizar el código con Snyk en sus IDE y se involucraron más en las prácticas de seguridad. Así sentó el equipo de Peerzada las bases de su enfoque centrado en los desarrolladores. El siguiente paso fue agregar un complemento de Snyk a sus pipelines de desarrollo para aplicar la automatización de DevSecOps.

En cuanto a los beneficios que hemos obtenido… tenemos llamadas periódicas con Snyk, cada dos semanas, en las que conversamos con sus arquitectos de soluciones. Nos proporcionan datos y nos ayudan a entender cuánto dinero hemos ahorrado al calcular las horas de trabajo que habría llevado corregir estas vulnerabilidades sin Snyk. Eso es muy importante, una comprobación de la realidad para los clientes. También nos proporcionan una lista de los desarrolladores que analizan líneas de código en sus IDE y, con esos datos, podemos identificar a los referentes de seguridad entre los desarrolladores.

En la estrategia serverless-first de Neiman Marcus, se abstraen distintas capas y cada vez se delegan más responsabilidades de seguridad en la nube. Sin embargo, el código de las aplicaciones y las bibliotecas siguen en contenedores, y es necesario protegerlos. Por eso, el equipo de Peerzada se centró en conectar la administración de la postura de seguridad en la nube con la seguridad de las aplicaciones, y en permitir que los desarrolladores integraran la seguridad en su trabajo en lugar de dejarla para después.

Lecciones aprendidas al crear una estrategia de seguridad centrada en los desarrolladores

Peerzada destacó los siguientes puntos como las lecciones más importantes de su experiencia.

1. Para la seguridad en la nube, comienza con una higiene cibernética básica que incluya controles de administración de accesos, los cuales ayudan a crear una arquitectura de confianza cero.

2. No recopiles información ante la que no puedas actuar. Algunas empresas usan diversas herramientas que generan muchas alertas. Pero debes realizar evaluaciones contextuales basadas en el riesgo. Hay muchos peces en el mar: tienes que ir por los tiburones.

3. Debes tratar la seguridad en la nube de manera diferente a la seguridad de la infraestructura local. Requiere otro enfoque. En tu recorrido hacia la seguridad en la nube, no tengas miedo de usar herramientas de código abierto.

4. Conecta los silos de administración de la postura de seguridad en la nube y seguridad de las aplicaciones, y trátalos como una sola entidad. Lo que hace Snyk con un motor de políticas unificado es excelente. Si tratas estos silos como una sola entidad, tendrás un marco sólido de ciberseguridad.

¡Agradecemos a Omar Peerzada por compartir su historia con nosotros en AWS re:Invent! Nos encantan las historias sobre cómo Snyk ha ayudado a las organizaciones a darles a los desarrolladores las herramientas para integrar la seguridad en su flujo de trabajo.