Casa de Moneda desplegó GuardDuty Malware Scan y Disaster Recovery Service de AWS para reforzar la postura de sus servidores on-premises.

Por Alejandro Conde, Administrador IT, Casa de Moneda S.E.,

Leandro Pampín, Administrador IT, Casa de Moneda S.E.,

Miguel Ángel López, Jefe de Área de Infraestrctura Digital Casa de Moneda S.E.,

Emiliano Axelirud, Gerente de Innovación y Producto , Casa de Moneda S.E.,

Federico Ramos Napoli, Gerente General de Negocios Digitales, Casa de Moneda S.E.,

y Cristina Chiarelli, CISO, Casa de Moneda S.E.

Casa de Moneda (CMA) es una Sociedad del Estado argentina especializada en la impresión de billetes y acuñación de monedas de curso legal, fabricación de especies valoradas, instrumentos de control, documentos de seguridad, diseño y desarrollo de software y procesos de digitalización. Fundada en 1875, cuenta con más de 148 años de experiencia en la provisión de esta clase de productos y servicios, los cuales tienen la seguridad como eje transversal a todos ellos.

El equipo de negocios digitales de CMA tiene la misión de desarrollar herramientas para resolver todo tipo de necesidades relacionadas con el manejo seguro de datos e información en el sector público de nuestro país. Nuestro equipo multidisciplinario aporta un enfoque holístico en el desarrollo, implementación y acompañamiento de las soluciones digitales acompañando a nuestros clientes durante todo el ciclo de vida del producto.

A lo largo de 2023, nuestros equipos exploraron alternativas para reforzar la postura y resiliencia de los servidores alojados en nuestro centro de datos. Necesitábamos implementar un esquema resiliente de recuperación de desastres que además permitiese incorporar capacidades de identificación y mitigación de amenazas de seguridad, como por ejemplo ataques de ransomware y amenazas generadas por archivos contaminados con malware. Asimismo, buscábamos una solución de bajo riesgo, que nos permita desplegar estas capacidades de manera no-invasiva para la operación de tecnología y sin necesidad de tener que comprar e integrar costosas soluciones de mercado.

Desafíos en la detección de malware on-premises

Con el objetivo de cumplir de forma eficiente los objetivos propuestos el proyecto fue estructurado en torno a las siguientes premisas:

Baja barrera de entrada: buscamos una solución de bajo riesgo financiero, que nos permita evitar comprar licencias (por ejemplo, licencias de software) y evitar pagos por adelantado. En este sentido, el modelo de pago por uso (pay as you go) permite a nuestros equipos probar diferentes combinaciones escalables, descartar rápidamente las que no nos resulten útiles, y así acelerar nuestros procesos de innovación.
Baja tendencia a la obsolescencia y mantenimiento acotado: evitar las soluciones tradicionales que requieren actualizaciones frecuentes para mantener al día su capacidad de detección de malware era un punto fundamental. Frecuentemente, esto requiere tareas de actualización manual o instalación de software en ventanas de baja actividad de negocio para evitar interferir con la normal operación de los sistemas.
Continuidad operativa: dentro de los objetivos, contar con una solución altamente confiable y a la vez no invasiva resultaba clave ya que esta debía ser desplegada en nuestro parque de servidores productivos sin que disrumpa la normal operación de los servicios de negocio de CMA.

A partir de ello, logramos establecer un Plan de recuperación ante desastres (DRP) que nos brinda un buen equilibro entre bajos costos y performance, es decir, Recovery Point Objective (RPO) tendiendo a cero y Recovery Time Objective (RTO) medido en minutos. Asimismo, capacidades de inmutabilidad y restauración de los datos apoyada en un repositorio elástico de información.

Arquitectura de alto nivel de la solución

Para resolver estos desafíos, trabajamos en conjunto con los equipos de Arquitectura de Soluciones, Servicios Profesionales (ProServe), y Enterprise Support de AWS para desarrollar una solución de código abierto que nos permita incorporar capacidades de detección de malware y recuperación ante desastres en nuestros servidores on-premises.

En la figura 1 podemos ver un diagrama de arquitectura de alto nivel. En esencia, esta solución permite combinar las capacidades de AWS Elastic Disaster Recovery (DRS), Amazon GuardDuty y AWS Security Hub como veremos a continuación:

Figura 1: arquitectura de alto nivel de la solución desplegada por CMA.

AWS Elastic Disaster Recovery (DRS) es un servicio diseñado para ayudar a organizaciones a implementar un esquema de mitigación de desastres. Con el uso de DRS, podemos minimizar el tiempo de downtime y la pérdida de datos con una recuperación rápida, obteniendo valores bajos de RPO (del orden de segundos) y RTO en minutos.

Asimismo, ejecuta de forma periódica toma de snapshots de los discos de las cargas de trabajo on-premises que luego pueden ser utilizados como puntos de recuperación en el tiempo dentro de la ventana de retención definida por el cliente (hasta 365 días). Por ejemplo, si se determina que la instancia fue infectada el día domingo a las 8pm, es posible recuperar el servidor a partir de una instantánea no contaminada previa al incidente.

Hacia la izquierda de la figura 1, podemos ver que DRS permite que los servidores on-premises repliquen continuamente sus volúmenes en la cuenta de AWS de la organización (centro). Sobre estos volúmenes de datos replicados podemos usar Amazon GuardDuty para detectar amenazas de malware basadas en archivos.

Amazon GuardDuty (o simplemente GuardDuty) es un servicio de monitoreo de seguridad que analiza y procesa datos obtenidos de una cantidad de fuentes de información, como logs de flujos de VPC, DNS, o diferentes tipos de archivos de logs. GuardDuty incorpora también una función de protección contra malware que nos permite detectar la presencia de archivos potencialmente maliciosos escaneando los volúmenes de EBS (en este caso, volúmenes EBS continuamente actualizados por DRS).

De esta forma, cuando GuardDuty detecta que los datos de los servidores on-premises (que se encuentran replicados en AWS) contienen malware, genera un evento o finding para alertar a nuestro SOC (Security Operations Center) en SecurityHub (a la derecha del diagrama).

AWS Security Hub es un servicio de administración de la postura de seguridad en la nube (CSPM, por sus siglas que en inglés significan cloud security posture management) que realiza revisiones de las prácticas recomendadas de seguridad, agrega alertas y permite la corrección automatizada.

Así, los descubrimientos de amenazas de malware son publicados en nuestra consola de SecurityHub, permitiendo a nuestro SOC generar alertas y realizar las mitigaciones necesarias.

Recorrido de la solución

Hagamos un recorrido de alto nivel sobre cómo podemos usar la solución para un hipotético proceso de identificación. Comencemos en la consola de DRS, donde podemos ver el listado de servidores on-premises que se encuentran replicando continuamente sus datos:

Figura 2: vista de DRS source servers en Elastic Disaster Recovery.

Supongamos ahora que la solución se encuentra configurada para realizar análisis de malware sobre este grupo de servidores con una frecuencia diaria. Cuando el proceso de análisis de malware de GuardDuty detecta una amenaza, genera un finding que se envía a SecurityHub.

La solución utiliza Amazon EventBridge para enriquecer este finding con información adicional que permite al operador del SOC identificar rápidamente el nombre del servidor on-premises comprometido con archivos de malware. Amazon EventBridge (o simplemente EventBridge) es un servicio serverless que facilita el desarrollo de aplicaciones basadas en eventos e interconectar componentes de arquitectura a partir de los mismos.

En este caso, la solución despliega una regla de EventBridge que permite capturar eventos específicos generados por GuardDuty cuando detecta malware, y enriquece dicho descubrimiento o finding con la información del servidor on-prem conteniendo malware. En la figura 3 podemos ver cómo se ve uno de estos findings en la consola de administración.

Como puede verse en la figura 3, nuestro equipo de SOC usa la consola de SecurityHub para revisar detalles de los findings de malware, que incluyen el nombre del servidor on-prem y el path a los ficheros que contienen malware dentro del sistema de archivos.

La solución cuenta además con capacidad de almacenar reportes en Amazon S3, el servicio de almacenamiento de objetos de AWS. Esto puede ser muy útil, por ejemplo, para llevar un registro en el tiempo del estado de un determinado servidor luego de aplicar el proceso de remediación, o para identificar el momento en el cual se generó un descubrimiento de malware para un determinado servidor.

Figura 4: reporte de análisis de malware de servidores on prem.

Recuperación y mitigación con DRS

Si bien el proceso de recuperación y mitigación de amenazas es un tema amplio que se encuentra fuera del alcance de este artículo, a continuación, y a modo de ejemplo veremos que AWS DRS puede usarse para recuperación ante un evento de ransomware.

Como se puede ver en la figura 5, este servicio puede usarse para lanzar versiones desbloqueadas (no-encriptadas) de los servidores, gracias a que posee capacidades de recuperación de tipo point-in-time, permitiendo al operador seleccionar un determinado snapshot del repositorio histórico gestionado por DRS (puede ir hasta 365 días atrás en el tiempo).

Figura 5: selección del instante de tiempo del snapshot de un servidor on-prem.

Gracias a esta capacidad, por ejemplo es posible realizar análisis forense seleccionando una versión del historial de snapshots y generar una instancia EC2 a partir de un snapshot comprometido en un ambiente completamente aislado.

El proceso de preparación y lanzamiento de la instancia en AWS demora unos minutos (recovery job). En la consola de DRS podemos hacer un seguimiento del mismo. Al cabo de unos minutos en proceso se verá en DRS de la siguiente manera:

Figura 6: proceso de restauración completado exitosamente por DRS.

A partir de este momento, el servidor se encuentra completamente restaurado en AWS. Para verificar la ausencia de malware podemos ejecutar una nueva corrida de GuardDuty malware scan, apuntándolo a esta instancia recuperada.

Figura 7: vista del servidor restaurado en Amazon EC2.

Para información más detallada sobre cómo instalar y utilizar la solución, sugerimos visitar el sitio de GitHub donde se encuentra la documentación y el repositorio con el código fuente de esta solución.

Vea también Protecting against ransomware (ebook) y AWS Blueprint for ransomware Defense. Consulte también la documentación de Amazon GuardDuty para una descripción completa de tipos de finding de protección contra malware.

Resultados

Los equipos responsables de la gestión de la infraestructura Cloud y on-premises de CMA implementaron la solución de GitHub en Agosto de 2023 sobre un grupo inicial de 5 servidores on-prem y desde entonces está funcionando plenamente en servidores de producción que dan soporte a la operación de negocios de CMA. A pocos días de comenzar a trabajar, nuestro SOC ya se encontraba monitoreando potenciales amenazas sobre los servidores on-premises.

Nuestros servidores del centro de datos ahora cuentan con capacidades de recuperación ante desastres, análisis y mitigación de amenazas de malware basada en archivos. Las capacidades de identificación de malware de Amazon GuardDuty garantizan una detección de amenazas rápida y precisa. Por otro lado, la integración con SecurityHub permite una pronta detección de los riesgos asociados con este tipo de amenazas.

El esquema de replicación de DRS es liviano y diseñado específicamente para no ser invasivo: típicamente, utiliza menos de 5% de CPU y consume unos 250 MB de RAM. Esta característica nos permitió un rápido despliegue del esquema de recuperación ante desastres en ambientes productivos alojados en el centro de datos.

La combinación de DRS con GuardDuty nos permite reforzar la postura de seguridad y la operación de soporte al negocio: la posibilidad de contar con almacenamiento elástico prácticamente ilimitado (a través de DRS) nos brinda la posibilidad de contar con un repositorio histórico de snapshots inmutables. Ante un potencial ataque de ransomware, podemos restaurar rápidamente el servidor y seleccionar el snapshot no comprometido en la línea de tiempo. Asimismo, podemos poner a prueba estos procesos de manera rutinaria, para preparar proactivamente a nuestros equipos.

Próximos pasos

La implementación satisfactoria de esta solución en nuestro centro de datos nos permitió desarrollar las capacidades necesarias y el entendimiento que necesitamos en los equipos para encarar una nueva etapa en la materia. El objetivo actual consiste en consolidar las habilidades del equipo de cara a escalar la provisión del servicio para nuestros distintos clientes en el ámbito del Sector Público. Los parámetros de eficiencia y escalabilidad del proyecto permitirán a estos alcanzar un elevado estándar en materia de gestión de la seguridad de la información, sin la necesidad de comprometer demasiados recursos ni adquirir licencias onerosas.