En los últimos años, los clientes nos han pedido que apoyemos y validemos los planes de migración para trasladar las infraestructuras existentes compatibles con PCI DSS a los proveedores de alojamiento en nube. De hecho, hemos visto que el número de estas solicitudes ha aumentado de pequeños clientes a clientes empresariales de Advantio y queremos compartir con usted nuestros puntos de vista sobre el proceso de migración.

Hoy en día, todos los principales actores del cloud hosting se están centrando cada vez más en proporcionar instalaciones de seguridad a sus clientes. AWS asegura que aquellos clientes que están sujetos a estándares de seguridad como PCI DSS terminan con un impacto mínimo al migrar sus instalaciones internas y seguras al alojamiento en la nube. Hoy en día, el mantenimiento de la seguridad es una de sus principales prioridades. Esta es una buena noticia para los profesionales de la seguridad. Probablemente no dudaríamos en incluir el alojamiento en nube como una alternativa segura para proteger la confidencialidad de los datos y cumplir con los estándares de seguridad, ¿está de acuerdo?

En este artículo, quiero sumergirme en el típico viaje de migración al alojamiento en nube de una infraestructura compatible con PCI DSS. Y, compartiré mi perspectiva como consultor de seguridad, socio tecnológico y Director Técnico de Advantio. Amazon Web Services (AWS) será el ejemplo de uso ya que tiende a ser la opción preferida de nuestros clientes (no dude en contactarnos si desea discutir otra opción).

Antes de empezar, definamos la viabilidad en este contexto. El alojamiento en nube de infraestructuras compatibles con PCI DSS puede no ser aplicable a instalaciones complejas, proporcionando servicios básicos y críticos como la adquisición o emisión para grandes instituciones financieras y, en general, cuando se utilizan tecnologías informáticas complejas. El costo de migrar este tipo de ambientes no justificará el esfuerzo todavía. En cambio, este artículo se aplica a las infraestructuras de servicios web como el comercio electrónico, las plataformas de pago, etc.

Responsabilidades compartidas del PCI DSS

El propósito de este artículo no es explorar las razones por las que se ha pasado de una solución de alojamiento interno a un servicio como AWS. Sin embargo, quiero destacar la importancia de conocer sus responsabilidades PCI DSS que seguirán siendo aplicables a su empresa incluso después de la externalización a un servicio como AWS. Esto es importante para evitar sorpresas durante una auditoría de cumplimiento.

AWS hace un muy buen trabajo respetando sus deberes de PCI DSS. Ofrecen una matriz de responsabilidades bastante clara en la que se analizan todos y cada uno de los requisitos del estándar tanto desde la perspectiva del consumidor como desde la perspectiva de AWS como proveedor de hosting.

Ningún proyecto de migración debería comenzar sin una cuidadosa consideración de dicha matriz de responsabilidades. Le permitirá mejorar su informe de análisis de impacto. Además, a medida que comienza, también es un buen momento para contratar a su QSA para obtener todo el apoyo que necesita para una migración sin problemas.

Fase 1 - Los Diagramas

Puede sonar básico, pero lo primero que pedimos a nuestros clientes al inicio de un proyecto de migración a AWS es que nos muestren los diagramas de red basados en sus futuras infraestructuras basadas en AWS.

La mayoría de las veces, mostramos diagramas preexistentes como los analizados durante la última auditoría y aplicables a las redes alojadas internamente.

La razón por la que pedimos una visión de futuro es que el proceso de migración es en realidad una oportunidad excepcional para mejorar la red. Además, es posible que descubra restricciones estructurales que desencadenen cambios desatendidos en el diseño de la red; cambios que, en última instancia, pueden incluso afectar al flujo de datos y a su confidencialidad, así como a su integridad. Así que, al diseñar un diagrama de red de la visión futura, se mostrará que la capa de red de AWS tendrá que funcionar para incluir cualquier cambio o mejora que pueda crear un beneficio en comparación con su solución actual.

En el diagrama, debe considerar la escalabilidad, los procesos de copia de seguridad y la gestión de la infraestructura, entre otras cosas.

Ventajas adicionales: ¡La persona responsable de la implementación del proyecto de migración aprobará definitivamente una visión clara!

Sus flujos de datos deben ser analizados a continuación y, en consecuencia, cualquier diagrama de flujo de datos debe ser evaluado para asegurarse de que no se necesita ninguna personalización, refactorización o esfuerzo adicional debido a la próxima migración.

Esta primera fase es algo que debería aplicarse a cualquier infraestructura de nueva creación diseñada directamente en la nube de cara al futuro.

Fase 2 - Políticas de seguridad

Es fundamental garantizar que existan estructuras claras en términos de diseño y configuración de los servicios básicos de AWS que apoyen las funciones de seguridad.

Los servicios básicos como el IAM, el VPC y sus subservicios integrados y, en última instancia, los grupos de seguridad, son características que determinarán muchos aspectos de la calidad futura de una infraestructura AWS.

El análisis de cada una de las mejores prácticas individuales va más allá del alcance de este artículo, sin embargo, creemos que es obligatorio destacar la importancia de educar a su equipo a través de un conjunto completo de documentación oficial y asegurarse de que se tomen las mejores medidas para la seguridad, la auditoría, la escalabilidad y el mantenimiento.

Es muy probable que los servicios mencionados anteriormente constituyan la columna vertebral de la gestión y autorización de su identidad, su segmentación y firewalling, y la base sobre la que cualquier auditor de seguridad prestará especial atención.

Dependiendo de los diseños seguros aprobados, las políticas y la definición de un plan de implementación y escalabilidad, el siguiente paso es excluir o limitar cualquier necesidad de refactorización o rediseño que pueda tener un impacto en las operaciones y el tiempo de ejecución. 

Fase 3 - Escalabilidad y redundancia de datos

Definitivamente, AWS ha puesto mucho esfuerzo para asegurarse de que los clientes se beneficien de las características innovadoras que soportan la escalabilidad de las arquitecturas web comunes (principalmente horizontales). Y, para proporcionar características que faciliten la disponibilidad y la redundancia de datos.

Esta fase puede solaparse con las discusiones sobre la naturaleza de la lógica de negocio y las tecnologías de alojamiento de aplicaciones, ya que estos son factores que pueden desencadenar decisiones específicas sobre la escalabilidad y la redundancia de datos. AWS ofrece opciones estables para la escalabilidad horizontal automática (gracias a la automatización de OpsWork y/o de la formación de nubes) y también para abordar cuestiones de redundancia de datos (es decir, a través de la multi-zonificación RDS o el versionado S3). Entender la naturaleza exacta de la capa de software y el aprovisionamiento deseado normalmente nos permitiría sugerir un enfoque seguro y estable.

Muchos de nuestros clientes están preocupados por la aplicación de estrategias que dependerían de los servicios de AWS en lugar de limitarse a replicar procesos y flujos de trabajo establecidos desde hace mucho tiempo en sus negocios. Esta es una preocupación natural, ya que las tecnologías comprobadas son reemplazadas por nuevas alternativas.

Aunque a menudo nos hemos encontrado abogando por la confianza en las características de AWS cuando se trata de escalabilidad y disponibilidad, recomendamos dos pasos primero. El primero es asegurar que cada caso de negocio sea analizado individualmente. En segundo lugar, separar cuidadosamente la necesidad de escalabilidad de la de disponibilidad de datos y servicios. Detrás de estos términos, generalmente encontramos una plétora de asuntos y tecnologías individuales. Cada uno con un conjunto diferente de requisitos de seguridad y calidad. El avance correcto depende de cada caso individual, de la experiencia del personal, de sus conocimientos técnicos y de su deseo.

Fase 4 - Migración de datos

En este artículo, hemos omitido la llamada capa de software, que va desde los sistemas operativos hasta el soporte de software y la implementación de aplicaciones. Creemos que no hay mejores prácticas o recomendaciones específicas que se ajusten a esta publicación del blog. Sin embargo, es fundamental evaluar si la estrategia de migración y continuidad funcionaría y protegería de forma segura los activos confidenciales de los consumidores.

Esto debería ocurrir una vez que una puesta en escena o incluso un entorno de producción esté listo para su uso en AWS.

Durante esta fase, recomendamos asegurarse de que los documentos de AWS sobre el tema sean procesados primero. Luego, debe colaborar con su consultor de seguridad para asegurarse de que el proceso no afecte a su cumplimiento existente y, en consecuencia, a la seguridad de los datos que se están migrando.

Este aspecto depende estrictamente de cada caso de negocio individual. A menudo, las migraciones ni siquiera son necesarias ni están planificadas.

Fase 5 - Monitoreo y Operaciones de Seguridad

El paquete de cumplimiento PCI de AWS describe cuidadosamente la responsabilidad del proveedor y de los clientes en términos de monitoreo, mantenimiento y gobierno de la seguridad. Mientras que la seguridad física y algunos otros aspectos serán heredados del estado de cumplimiento de AWS, la mayoría de las actividades seguirán siendo su responsabilidad.

Sus obligaciones seguirán incluyendo:

  • realizar revisiones del rendimiento de firewall
  • pruebas de seguridad recurrentes
  • aplicación de parche
  • gestión y supervisión de amenazas. 

Esto es válido para todos los activos y servicios AWS aplicables que no estén ya cubiertos por el propio proveedor de cumplimiento PCI DSS. Por ejemplo, parcheo de bases de datos RDS o Load Balancers AWS.

Algunos de nuestros clientes tenderían a migrar sus tecnologías SIEM y de monitorización existentes dentro de sus nuevas infraestructuras AWS. Sin embargo, esto puede dar lugar a errores y a complicaciones excesivas de los objetivos. Nuestro papel en Advantio es, por tanto, aconsejar a los clientes para que reconsideren sus herramientas y se aseguren de que se toman las mejores medidas cuando se trata de alojamiento dentro de AWS. Aunque toda la pila (o casi) del SIEM tecnológico podría implementarse utilizando los servicios disponibles de AWS, reconocemos la importancia de confiar en proveedores de confianza o en soluciones probadas. Cuando el alcance se reduce al registro, recopilación de eventos, análisis de tráfico y correlación de datos y alertas, podemos asesorar sobre soluciones sólidas, desde alternativas de bajo presupuesto hasta alternativas expansivas, a veces más invasivas. La recomendación dependería del caso de uso en cuestión y de factores como el presupuesto y las necesidades de las empresas.

Hemos observado la creación de una plataforma de monitorización perfectamente fiable y funcional, además del nuevo cliente unificado de recogida de eventos de AWS y de los servicios de monitorización que ya forman parte de la cartera de AWS. Basándonos en la frecuencia con la que el tema ha surgido durante nuestra conversación, también debemos mencionar la detección de intrusos. La abstracción legítima forzada por la virtualización AWS crea una restricción para nuestra capacidad de interceptar y analizar el tráfico de red a niveles más bajos de entrada y salida. Los sistemas de prevención o detección de intrusiones en la red siempre serán objeto de discusión con su QSA. Ellos son el juez final de su cumplimiento y su opinión puede diferir de la de los demás, especialmente en un área donde el consejo usa su famosa y de alguna manera excitante ambigüedad (por ejemplo, el viejo tema de NIDS vs. HIDS). En pocas palabras, hoy en día, una mezcla de características de AWS y herramientas de terceros, desde código abierto hasta licencias comerciales, son absolutamente capaces de permitir a su organización retener el alto nivel de monitoreo al que está acostumbrado, en términos de detección de intrusos y mucho más.

Fase 6 - Pruebas de seguridad

Una plataforma de pruebas en AWS no debe ser diferente de cualquier otro análisis de seguridad. Desde la perspectiva del PCI DSS, y en particular de los requisitos de la sección 11 relativos a las evaluaciones de vulnerabilidad y las pruebas de penetración, es importante mencionar la necesidad de ampliar los ejercicios de pruebas a la configuración y el uso seguro de los distintos servicios AWS.

Las evaluaciones de vulnerabilidades, ya sea las de los activos públicos a través de su proveedor de ASV o las exploraciones internas, no se verán afectadas por el hosting de AWS. Sin embargo, las pruebas de penetración, y en particular las pruebas de segmentación, deben incluir algún conocimiento del probador sobre la infraestructura de AWS con el fin de dar un mejor soporte a los clientes. Los servicios básicos como IAM, VPC y grupos de seguridad, incluso si se proporcionan con documentación sólida del proveedor, suelen formar parte de nuestras revisiones de seguridad, y se sugieren a los clientes como vectores de amenaza que pueden comprometer las propiedades de confidencialidad e integridad.

La Sección 11 del PCI DSS requiere la ejecución de comprobaciones de segmentación recurrentes para garantizar que se preserva la integridad del alcance del programa de cumplimiento y se cumplen los requisitos de seguridad. Combinar el resultado de un análisis directo de la configuración del VPC y de los grupos de seguridad puede beneficiar absolutamente el análisis final si se combina con las actividades de pruebas técnicas realizadas por su personal experto o su proveedor de hacking ético. Una revisión completa y recurrente de los ajustes de su consola AWS aseguraría la adherencia de los diagramas de red y potencialmente también cumpliría con los requisitos de la Sección 1 del PCI DSS en lo que se refiere a la revisión de cortafuegos y enrutadores.

AWS requiere además el registro de las solicitudes de pruebas. Esto es para asegurar que los ejercicios de prueba no activen la monitorización de seguridad transparente de la infraestructura de alojamiento subyacente proporcionada por el propio AWS.

Conclusiones

A lo largo de los años, hemos experimentado que el mercado se ha vuelto cada vez más relajado y propenso a migrar a una instalación de nube. Esto puede atribuirse a la evolución de estas plataformas. Cuando trabajamos con nuestros clientes, llevamos el proceso de migración un paso más allá. Analizamos el ciclo de vida de la infraestructura PCI DSS en la nube y damos soporte a los clientes a través de nuestro conocimiento interno.

Hoy en día, el PCI DSS en AWS es una práctica común. Se proporcionan servicios listos para usar que apoyan a los profesionales de la seguridad y aumentan las posturas de seguridad y el monitoreo.

Nuestro último consejo es que siempre consulte con su socio de seguridad y sus socios tecnológicos. Asegurarán que el impacto de la migración se reduzca al mínimo desde el monitoreo hasta el mantenimiento y las operaciones. Las decisiones que tomen juntos sobre el diseño de la infraestructura de la nube serán fáciles de escalar, supervisar y auditar. Si desea avanzar su negocio con un socio de seguridad de confianza, póngase en contacto con nosotros
.

Francesco Consiglio

Written by Francesco Consiglio

I am the CTO, Senior Security Consultant, and PCI QSA since 2010 at Advantio.

Having executed close to a hundred (and counting) assessments across Europe, Asia, South Africa, and North America, I was able to observe many different implementations of all classic security controls and much more.

Now I spend much of my time with cloud technologies. Being passionate about cloud security and cloud resources management, my research focuses on the implementation of streamlined and scalable processes in the field of Threat Management for cloud-based ecosystems.

At Advantio, I am also part of the ZeroRisk team. Our vision is to make security and compliance simpler for our users.