Cuando me presenté (¡y pasé!) mi examen Certified Information Systems Auditor (CISA) en 2005, una de las declaraciones clave de tareas fue “Evaluar la adecuación de las disposiciones de respaldo y recuperación para garantizar la reanudación del procesamiento normal de la información en el un evento de una interrupción a corto plazo y/o la necesidad de volver a ejecutar o reiniciar un proceso.1 “Cuando llegué a actualizar el Manual de revisión de CISA para las prácticas laborales de 2016, una tarea equivalente decía” Evaluar la continuidad y resilencia de TI “(copias de seguridad/restauraciones, plan de recuperación ante desastres [DRP]) para determinar si se controlan eficazmente y continúan respaldando los objetivos de la organización”.2 Aunque la redacción ha cambiado, el mensaje de ISACA es claro: la copia de seguridad y la recuperación siguen siendo controles clave.
Esto me parece interesante ya que, debido a las mejoras tecnológicas, especialmente la virtualización y la nube, los auditores de TI a menudo reciben retrocesos cuando buscan seguridad en la continuidad y resilencia de TI. Entonces, ¿cómo debería responder un auditor de TI cuando se presenta con estas soluciones tecnológicas más nuevas? En esta columna, Tommie Singleton abogó previamente por los principios de respaldo y recuperación.3 Creo que vale la pena revisar estos principios, considerando los cambios en la tecnología.
Principio de respaldo 1—Realizar copias de seguridad periódicas
El principio para las copias de seguridad de datos regulares es respaldar datos diariamente. Esa copia de seguridad podría ser para medios (por ejemplo, cinta o disco duro externo), o podría ser a una ubicación remota a través de la nube (es decir, Internet). Si una empresa realiza una copia de seguridad de los medios, este principio recomienda que las copias de seguridad se realicen en diferentes medios para realizar copias de seguridad al final de la semana y al final del mes (este conjunto de copias de seguridad diarias, semanales y mensuales se conoce como “abuelo-padre-hijo”).4
Creo que todos podemos estar de acuerdo en que con la replicación de máquina virtual (VM), la primera oración en esta sección debería terminar con “al menos diariamente”. De hecho, con la replicación de VM puede crear una copia exacta de la VM en un host de repuesto y mantenga esta copia sincronizada con la máquina virtual original. Por lo tanto, el principio de (al menos) copias de seguridad diarias sigue en pie.
Sin embargo, la replicación sola puede, en ciertas circunstancias, aumentar el riesgo. Si la VM o los datos están corruptos de alguna manera, esta corrupción se replicará automáticamente en la (s) otra (s) máquina (s). Por lo tanto, tiene mucho sentido mantener copias de seguridad de VM por separado. Como no podemos estar seguros de cuándo se puede descubrir una corrupción de datos, también tiene sentido mantener copias de seguridad de abuelo-padre-hijo.
Una palabra de advertencia: el administrador de las copias de seguridad de la VM no debería tener acceso a Internet esto expondría las copias de seguridad al ransomware. Todos esos usuarios deberían tener una segunda cuenta sin privilegios que no tenga acceso a las VM, pero tiene acceso a Internet para solucionar problemas.
Principio de respaldo 2—Prueba de la confiabilidad del proceso de respaldo
La siguiente preocupación es si el proceso de respaldo es confiable. Por lo tanto, al usar una nueva metodología o tecnología de respaldo, la administración debe proporcionar un medio para probar los datos posteriormente para garantizar que el proceso realmente esté registrando todos los datos en el dispositivo de respaldo de destino.5
Es una práctica generalizada hacer copias de seguridad de máquinas virtuales enteras, pero es posible excluir datos para reducir el tamaño de la copia de seguridad o réplica de VM y disminuir la carga en la red. Este principio, por lo tanto, sigue en pie, ya que un auditor de TI aún debe validar lo que se está respaldando. Además, dado que existe un riesgo de corrupción durante el proceso de copia de seguridad, un auditor de TI debe garantizar que se realice periódicamente un chequeo de salud. Esto generalmente significa programar una verificación de redundancia cíclica (CRC) para los metadatos y una comprobación de comprobación para los bloques de datos de VM en el archivo de copia de seguridad para verificar su integridad. La comprobación de estado proporciona la garantía de que el punto de restauración es constante y de que será posible restaurar los datos.
Principio de respaldo 3—Uso de almacenamiento seguro
Otra preocupación es dónde se almacena la copia de seguridad. Si se almacena en el sitio, y si la entidad sufre un evento pandémico como un incendio, el evento destruiría los datos operativos y de respaldo. Por lo tanto, el principio de respaldo para el almacenamiento es usar una ubicación que se encuentre a una distancia segura de la ubicación de la entidad. La nube proporciona automáticamente este elemento.6
Este principio, obviamente, sigue en pie y, sí, la nube proporciona automáticamente este elemento. Sin embargo, también existe un elemento de riesgo cuando el proveedor de la nube u otros terceros que comparten la nube puedan acceder a la información empresarial sensible a la nube. Por lo tanto, es vital garantizar que las máquinas virtuales respaldadas en la nube estén encriptadas. El tipo de encriptación, los procedimientos de gestión de claves, etc., deberían, por supuesto, ser verificados.7
Principio de respaldo 4—Realizar restauraciones de prueba
Además, la gerencia debe proporcionar una prueba para restaurar la copia de seguridad al menos una vez al año. Esa prueba debe documentarse, incluso si solo es una captura de pantalla que muestra los datos restaurados.8
Ah, la prueba de restauración! Por alguna razón, muchos departamentos de TI simplemente no ven el valor. Cualquiera que sea un auditor de TI ha escuchado una, sino varias variaciones de “Restauraciones de prueba no son necesarias porque usamos clustering/tenemos una solución de failover/usamos replicación de VM/usamos red de área de almacenamiento (SAN) replicación/uso log envío y, por lo tanto, simplemente no restauraríamos de esa manera”.
Sin embargo, ya se ha observado que la replicación puede aumentar el riesgo de pérdida de datos si los datos se corrompen y/o se sabotean. Dependiendo de la configuración, lo mismo puede decirse de cada una de las soluciones anteriores. De todos modos, restaurar desde una copia de seguridad simplemente proporciona una opción adicional en un escenario de desastre real. Por lo tanto, tiene sentido realizar restauraciones de prueba para garantizar que se realicen copias de seguridad de los datos correctos, que los datos sean, de hecho, recuperables y que la empresa sepa cómo restaurarlos. Este principio sigue en pie.
Principio de recuperación 1—Identificar y clasificar aplicaciones críticas
Los principios de desarrollo de un plan de continuidad del negocio/plan de recuperación de desastres (BCP/DRP)9 incluyen un paso para identificar las aplicaciones críticas y clasificarlas en importancia de las operaciones. Esta lista se vuelve estratégicamente valiosa si alguna vez se necesita para proporcionar al equipo de recuperación un modelo de cómo restaurar el software de aplicación.10
En una columna anterior, defendí la categorización de aplicaciones en términos de confidencialidad, integridad y disponibilidad.11 La categorización de disponibilidad sugerida proporciona la lista de aplicaciones críticas clasificadas y es necesaria independientemente de la tecnología utilizada para restaurar las aplicaciones. Por lo tanto, este principio sigue en pie.
Sin embargo, la lista de aplicaciones debe ajustarse para considerar las interfaces de aplicaciones y los flujos de datos. Por ejemplo, la aplicación A puede ser más crítica para el negocio que las aplicaciones B y C, pero puede requerir datos de la aplicación C, que, por lo tanto, debe restaurarse primero. Además, varias aplicaciones pueden compartir una sola máquina virtual. Si las aplicaciones comparten una VM, una empresa puede restaurar una aplicación de menor prioridad junto con una aplicación de alta prioridad.
Principio de recuperación 2—Crear un equipo de recuperación con roles y responsabilidades
Otro principio, y la necesidad obvia, es crear un equipo de recuperación. El equipo debe incluir todas los roles y funciones necesarias para restaurar de manera rápida y completa las operaciones de la computadora. Debe haber un documento que identifique a los miembros del equipo, sus respectivos roles y los pasos que cada uno tomaría para restaurar las operaciones.12
Aún se requiere que un equipo realice la recuperación real, por lo que este principio sigue vigente. Mi preocupación con las tecnologías virtuales y/o en la nube es que la recuperación se deja al equipo de operaciones de TI responsable de las máquinas virtuales. Creo que todavía es vital confirmar el punto de recuperación, que todas las transacciones esperadas están presentes y que todas las interfaces se ejecutan correctamente, todas las cuales aún requieren la entrada de expertos en aplicaciones y usuarios comerciales.
Principio de recuperación 3—Proporcionar una copia de seguridad para todos los componentes esenciales de las operaciones computacionales
El corazón de un BCP/DRP es proporcionar un medio de respaldo para proporcionar los componentes esenciales de las operaciones computacionales. El sitio debe incluir un edificio, electricidad, muebles y otras necesidades básicas para albergar las operaciones computacionales. Por lo general, el sitio sigue el mismo principio que el almacenamiento de datos de respaldo, ya que se encuentra a una distancia segura de las instalaciones de la entidad, pero no demasiado lejos para llegar de manera oportuna si es necesario para recuperar las operaciones.13
Independientemente de la tecnología, este principio sigue en pie. La nube puede negar la necesidad de que una empresa tenga su propio centro de datos secundario físico, pero aún debe haber una ubicación para que el personal acceda a los servicios restaurados. Por ejemplo, este artículo está almacenado en un OneDrive de Microsoft y lo estoy accediendo desde mi oficina en casa. Si mi casa y mi computadora portátil fueron destruidas (¡perecerán!), Necesitaría una nueva ubicación desde la cual acceder al artículo.
Principio de recuperación 4—Proporcionar pruebas regulares y efectivas del plan
Los principios de respaldo y recuperación sugieren que el paso más importante es proporcionar una prueba completa del BCP/DRP en un intervalo regular para garantizar que realmente funcione y para mejorar el plan a fin de que sea más eficiente y efectivo.14
No cabe duda de que las máquinas virtuales y la nube pueden automatizar en gran medida la recuperación de aplicaciones a la vez que mejoran los tiempos de recuperación y los puntos de recuperación. Sin embargo, en una situación de desastre todavía hay una gran necesidad de acciones y operaciones humanas. Esta es la definición misma de un proceso15 y, cuando existen procesos, es necesario confirmar que producen los resultados deseados. La única forma de hacerlo es realizar pruebas y documentar regularmente los resultados de BCP/DRP. Por lo tanto, este principio todavía está en pie. Además, independientemente de la tecnología en uso, el BCP/DRP siempre se puede mejorar. Las pruebas permiten esto al mismo tiempo que le permiten al auditor de TI brindar seguridad.
Conclusión
Esta columna podría haber sido titulada “Lo que todo auditor de TI debe saber sobre respaldo y recuperación”. Las tecnologías innovadoras como las VM y la nube ayudan a la eficiencia y efectividad de los planes de respaldo y recuperación, pero no reemplazan la necesidad de planificar, documentar, o probar y probar nuevamente. Las tecnologías aún dependen en gran medida de la intervención humana y, si ese es el caso, la garantía solo se puede proporcionar mediante la aplicación de buenos principios para la copia de seguridad y la recuperación.
Notas finales
1 ISACA, CISA Review Manual 2005, USA, 2004
2 ISACA, CISA Review Manual 26th Edition, USA, 2016
3 Singleton, T.; “What Every IT Auditor Should Know About Backup and Recovery,” ISACA Journal, vol. 6, 2011, www.isaca.org/resources/isaca-journal/issues
4 Ibid.
5 Ibid.
6 Ibid.
7 ISACA, Assessing Cryptographic Systems, USA, 2017
8 Op cit, Singleton
9 Business continuity plans and disaster recovery plans are different and separate processes, but in this article, they will be referred to as one unit.
10 Op cit, Singleton
11 Cooke, I.; “Doing More With Less,” ISACA Journal, vol. 5, 2017, www.isaca.org/resources/isaca-journal/issues
12 Op cit, Singleton
13 Ibid.
14 Ibid.
15 Merriam Webster defines “process” as “(a) series of actions or operations conducing to an end.” www.merriam-webster.com/dictionary/process
Ian Cooke, CISA, CGEIT, CRISC, COBIT Assessor and Implementer, CFE, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt
Es el gerente de auditoría de TI del grupo An Post (la oficina de correos irlandesa con sede en Dublín, Irlanda) y tiene 30 años de experiencia en todos los aspectos de los sistemas de información. Cooke ha trabajado en varios comités de ISACA® y es miembro actual del Grupo de Trabajo de Desarrollo de Ítems de Examen CGEIT de ISACA. Es el líder de la comunidad para las bases de datos de Oracle, las bases de datos de SQL Server y las discusiones sobre herramientas y técnicas de auditoría en el Centro de conocimiento de ISACA. Cooke respaldó la actualización del Manual de Revisión de CISA para las prácticas laborales de 2016 y fue un experto en la materia para los Cursos de Revisión en Línea CISA y CRISC de ISACA. Recibió el Premio John W. Lainhart IV del Conocimiento común del 2017 por sus contribuciones al desarrollo y la mejora de las publicaciones de ISACA y los módulos de capacitación de certificación. Agradece los comentarios o sugerencias de artículos por correo electrónico (Ian_J_Cooke@hotmail.com), Twitter (@COOKEI), o sobre el tema Herramientas y técnicas de auditoría en el Centro de conocimiento de ISACA. Las opiniones expresadas son suyas y no representan necesariamente las opiniones de An Post.