Antes de que el ransomware ponga a prueba sus copias de seguridad, haga usted mismo tres comprobaciones: si alguien puede borrarlas, si una cuenta de administrador robada puede acceder a ellas y cuánto tarda una restauración real en comparación con lo que el negocio puede tolerar.
La guía del NCSC sobre cómo mitigar el malware y el ransomware es contundente. Las copias de seguridad actualizadas son la forma más eficaz de recuperarse de un ataque de ransomware, el ransomware las ataca de forma activa para aumentar la probabilidad de que se pague el rescate, y los atacantes han destruido archivos copiados o han saboteado la recuperación antes de lanzar el ataque. Por tanto, pruebe sus copias de seguridad como lo haría un atacante.
Prueba 1: intente borrar su propia copia de seguridad
Los ejemplos de este artículo usan Amazon S3 Object Lock. Si trabaja con otra tecnología, localice el bloqueo de inmutabilidad o de retención equivalente en su producto de backup. Compruebe que está activado, cuál es el periodo de retención y quién puede acortarlo o eliminarlo. A continuación, intente un borrado permanente como usuario ordinario, como su administrador de backup con más privilegios y como una cuenta que un atacante podría llegar a tomar. Anote quién lo consigue.
En el caso de S3, trabaje en un bucket de pruebas. Object Lock solo funciona en buckets con S3 Versioning activado, así que verifique eso primero. Utilice el modo governance, que AWS describe como una forma de probar los ajustes de retención antes de crear un periodo de retención en modo compliance.
No aplique nunca el modo compliance en el bucket de pruebas. En modo compliance no se puede cambiar el modo de retención ni acortar el periodo, y la única manera de borrar antes de tiempo un objeto bloqueado en modo compliance es eliminar la cuenta de AWS asociada.
Realice estos intentos desde la consola y desde la API o la CLI, y compare los resultados:
| Intento | Resultado documentado |
|---|---|
| Borrado permanente (petición con un ID de versión), por un usuario sin el permiso de bypass | Access Denied, 403 Forbidden |
| Borrado simple (sin ID de versión) | 200 OK, más un delete marker encima |
Borrado desde la consola por un usuario con s3:BypassGovernanceRetention | Se realiza con éxito |
La segunda fila no es un fallo: la versión bloqueada permanece, porque los periodos de retención no impiden que se creen nuevas versiones o delete markers. La tercera fila es la preocupante. La consola de S3 incluye por defecto la cabecera x-amz-bypass-governance-retention:true, de modo que cualquiera que tenga ese permiso puede borrar objetos bloqueados en modo governance con unos pocos clics.
Después, envíe el mismo borrado permanente como ese usuario a través de la API o la CLI sin la cabecera. AWS la exige en cualquier petición que anule el modo governance, por lo que debería devolver Access Denied. Si el borrado se realiza, revise el modo de retención del bucket y los ajustes de bloqueo de la versión del objeto.
A continuación, audite quién puede deshacer el bloqueo
Haga una lista de todas las entidades (principals) cuyas políticas permiten s3:BypassGovernanceRetention, incluidos roles, grupos y políticas inline. Haga lo mismo con s3:PutObjectLegalHold: un legal hold no caduca, y cualquier usuario con ese permiso puede crear y retirar holds libremente.
Retire ambos permisos de las cuentas que un atacante podría llegar a tomar. Para los datos que no puede permitirse perder, valore el modo compliance con un periodo de retención elegido de forma deliberada.
Prueba 2: intente llegar a la copia de seguridad con credenciales equivocadas
El almacenamiento inmutable no sirve de nada si el atacante controla la consola que lo gestiona. Intente iniciar sesión en la consola de backup y en el almacenamiento con un administrador de dominio, una cuenta de operador de backup y un usuario IAM de la nube, y compruebe si cada uno de ellos puede borrar datos o modificar los ajustes de retención.
La guía del NCSC recomienda estas protecciones para las cuentas de backup:
- Privileged Access Workstations y firewalls de hardware que apliquen listas de IP permitidas.
- MFA, con el método de MFA no instalado en el dispositivo que se usa para administrar las copias de seguridad.
- Privileged Access Management, para que los administradores no accedan directamente a los sistemas de backup de alto valor.
Los discos de backup y las memorias USB no deben estar conectados de forma permanente a su red, y los productos de backup deben mantenerse parcheados. Si usa un servicio en la nube, confirme que las versiones anteriores están protegidas frente al borrado inmediato y que puede restaurarlas, ya que los servicios suelen sincronizarse justo después de que sus archivos se sustituyan por copias cifradas.
Prueba 3: restaure algo, con cronómetro
Elija un sistema que el negocio echaría en falta en menos de un día y restáurelo desde la copia de seguridad en un entorno limpio y aislado, para que una infección restaurada no pueda llegar a los sistemas en producción. Anote el tiempo transcurrido, quién hizo qué y cada punto en el que alguien tuvo que buscar una contraseña, una clave de licencia o un documento que reside en los servidores que está restaurando.
Si la restauración falla a mitad de camino, registre el paso, el tiempo transcurrido, la causa y la solución, y reinicie desde ese paso anotando aparte el tiempo restante. Mantenga los pasos idénticos entre ejecuciones para que los resultados sean comparables.
Antes de la recuperación, conecte las copias de seguridad solo a dispositivos limpios conocidos y analícelas en busca de malware antes de restaurar los archivos. Es posible que el ransomware se haya replicado en las copias antes de ser descubierto, por lo que un punto de restauración de apariencia limpia puede no estarlo.
Compare el tiempo medido con lo que el negocio dice que puede tolerar. Obtenga esa cifra del responsable del sistema antes de la prueba, para no ajustar el objetivo al resultado. La recuperación completa tras un ataque de ransomware, si es posible, puede llevar varias semanas, así que considere la cifra de un solo sistema como un mínimo.
Sobre el papel, determine qué ocurre si los sistemas locales y los servidores de backup en la nube quedan inutilizables y hay que reconstruir desde copias de seguridad offline, y cómo mantendría en funcionamiento los servicios críticos del negocio. Compruebe que los playbooks, las listas de verificación y los datos de contacto existen en algún lugar al que pueda acceder sin sus sistemas informáticos. Nuestro servicio de respuesta a incidentes cubre este tipo de ejercicio si desea una visión externa.
Por dónde empezar
- Elija un sistema crítico para el negocio y pregunte a su responsable cuánto tiempo puede estar caído. Anote primero esa cifra.
- Cree un bucket de S3 de pruebas con versionado y Object Lock en modo governance, nunca compliance. Intente un borrado permanente y un borrado simple, y registre las respuestas.
- Repita el borrado permanente como un usuario con
s3:BypassGovernanceRetention, desde la consola y desde la API o la CLI sin la cabecera de bypass. Después, haga una lista de todos los titulares de ese permiso y des3:PutObjectLegalHold, y retírelo a quienes no lo necesiten. - Intente iniciar sesión en la consola de backup con un administrador de dominio, un operador de backup y un usuario IAM de la nube. Donde el acceso haya funcionado, planifique MFA en un dispositivo separado y listas de IP permitidas. Confirme que existe una copia offline, que no está conectada de forma permanente y que se ha restaurado desde ella.
- Restaure el sistema elegido en un entorno aislado a partir de una copia de seguridad analizada, cronometrando cada paso, y compare el resultado con la cifra del paso 1.
- Corrija la mayor carencia y repita las pruebas cada vez que cambie el diseño del backup.
