Esta es la segunda parte de una serie de cinco entradas sobre ResOps (operaciones de resiliencia). Para leer la primera parte, consulta«¿Qué es ResOps y por qué es necesario para la ciberresiliencia?»?». No te pierdas la próxima entrada, en la que se abordará la fase de control de ResOps. También puedes descargar la guía completa:«ResOps: una guía para ejecutivos»«».
Puntos clave
- La visibilidad es la base de ResOps (operaciones de resiliencia): saber qué es lo más importante, saber cómo está protegido y saber en qué medida se puede recuperar.
- El concepto de «empresa mínima viable» (MVC) define los servicios esenciales que una organización necesita para seguir funcionando.
- Los servicios críticos deben contar con responsables designados y con umbrales de impacto definidos por la empresa.
- El mapeo de dependencias ayuda a determinar de qué elementos deben depender los servicios críticos para funcionar y recuperarse.
- Un servicio crítico solo es recuperable en la medida en que lo sean sus dependencias.
El reto de las adicciones
Antes de poder planificar Recovery, es necesario saber qué es lo más importante. Y esa respuesta no siempre es tan obvia como parece.
Por eso, la visibilidad es fundamental para ResOps. Antes de que los equipos diseñen estrategias de Recovery o comprueben si funcionan, necesitan una visión compartida de lo que la organización debe mantener en funcionamiento o restablecer en primer lugar, así como de todo aquello de lo que dependen esos servicios críticos.
Parece sencillo, pero en la práctica a menudo pone de manifiesto algunas lagunas incómodas:
- Un servicio que la empresa considera fundamental puede depender de una aplicación a la que se presta mucha menos atención.
- Una aplicación en la nube puede depender de un único proveedor de identidades.
- Un servicio aparentemente autónomo puede compartir infraestructura con docenas de otros.
ResOps ayuda a poner de manifiesto esas conexiones antes de que se produzca una interrupción.
¿Qué es la «empresa mínima viable» (MVC)?
La mayoría de las organizaciones pueden enumerar sus sistemas más importantes. La cosa se complica cuando se pregunta cuáles son aquellos sin los que la empresa, sencillamente, no puede funcionar.
Plantea esta pregunta:Si esta noche lo perdiéramos todo, ¿qué tendría que volver a funcionar primero?
Responder a esa pregunta ayuda a definir tu MVC: la versión más reducida de la organización capaz de atender a los clientes, generar ingresos y cumplir con sus obligaciones legales, normativas, de seguridad o relacionadas con su misión más urgentes.
No se trata de calificar todas las aplicaciones importantes como críticas, sino de establecer prioridades en función de los resultados empresariales.
Los responsables tecnológicos no pueden tomar esa decisión por sí solos. Los responsables de negocio, los responsables tecnológicos y los equipos jurídicos y de cumplimiento normativo deben ponerse de acuerdo sobre qué servicios son verdaderamente críticos y cuáles serían las consecuencias si dichos servicios no estuvieran disponibles o se viera mermada su calidad.
Cada servicio crítico también debe tener asignado un responsable de negocio. Esa responsabilidad ayuda a vincular las decisiones técnicas de Recovery con las personas que comprenden lo que supone una interrupción para los clientes, los ingresos, las operaciones y las obligaciones.
¿Cuánta interrupción es demasiada?
Una vez que se sabe cuáles son los servicios más importantes, la siguiente pregunta es:¿Cuánta interrupción puede soportar la empresa?
En ResOps, cada servicio crítico tiene un umbral de tolerancia al impacto definido por la empresa. Ese umbral describe cuánto tiempo de inactividad, corrupción de datos, deterioro del rendimiento, resultados incorrectos o dependencia de soluciones manuales puede soportar la empresa antes de que el perjuicio se vuelva inaceptable.
Pensemos en una plataforma de pagos que está en línea, pero que solo procesa el 20 % de su volumen habitual de transacciones. Técnicamente, está en funcionamiento. Pero desde el punto de vista empresarial, podría considerarse un fallo.
Por eso, las tolerancias de impacto deben reflejar el resultado empresarial, y no limitarse a indicar si un sistema está activo o inactivo. Dependiendo del servicio, esto podría incluir el impacto en los ingresos por hora, los umbrales de transacciones, los niveles de servicio al cliente o las obligaciones normativas.
Los umbrales exactos variarán en función de la organización. Lo importante es dejar claras las prioridades y revisarlas a medida que evoluciona el negocio.
Cómo el análisis de dependencias puede poner de manifiesto obstáculos para la Recovery
Definir un servicio crítico te indica qué es lo que habrá que recuperar. El mapeo de dependencias te indica —con gran detalle— de qué depende ese servicio crítico para funcionar y para que se produzca la Recovery.
Los servicios críticos rara vez funcionan de forma aislada. Pueden depender de sistemas de identidad y acceso, bases de datos, redes, infraestructura en la nube, aplicaciones SaaS, API de terceros, infraestructura compartida, personas y otros servicios internos.
Algunas de estas dependencias son evidentes. Otras no lo son. Ahí es donde los planes de Recovery pueden fallar. Un servicio de nivel 0 puede depender de un sistema de nivel inferior que nadie considera crítico. Varias aplicaciones pueden depender del mismo proveedor de identidad. Un servicio que se cree que es autónomo puede compartir infraestructura con otras cargas de trabajo. Un servicio de terceros puede encontrarse directamente en la ruta de Recovery, aunque su organización tenga poco control sobre él.
Centrarse únicamente en los servicios críticos puede ocultar estos puntos débiles. Trazar la cadena de dependencias los pone de manifiesto. La designación de nivel 0 tiene poco sentido si el servicio depende de un sistema de menor prioridad que no se puede recuperar a tiempo.
Comprender la cadena completa de dependencias es un requisito previo para que los equipos puedan identificar dónde podrían producirse fallos antes de que una interrupción ponga de manifiesto la brecha.
¿Por qué es necesaria la visibilidad antes de Recovery?
La visibilidad no consiste en crear el mapa tecnológico más detallado posible. Se trata de saber qué es lo más importante, qué puede soportar la empresa y dónde las dependencias podrían poner en riesgo la recuperación.
Con esta perspectiva, los equipos pueden centrar los esfuerzos de Recovery en lo que realmente importa. Pero antes de poder reforzar o probar Recovery, necesitas tener una idea clara de lo que intentas recuperar y de lo que se necesita para lograrlo.
Más información sobre ResOps
Commvault ha publicado«ResOps: Una guía para ejecutivos» con el fin de ofrecer a los CISO, CIO y responsables de TI un marco práctico en materia de seguridad, resiliencia y gestión de Risk para implementar ResOps en sus organizaciones.
Los responsables aprenderán a identificar los servicios más importantes, a validar la Readiness para la recuperación mediante pruebas reales y a comprobar continuamente la resiliencia. Como resultado, las organizaciones podrán establecer un modelo operativo único que aúne a los responsables de seguridad, infraestructura, operaciones de TI y del negocio en torno a una capacidad de recuperación basada en pruebas.
Preguntas frecuentes
P: ¿Qué significa «visibilidad» en ResOps?
R:La visibilidad consiste en comprender qué servicios son críticos para el negocio, cuánta interrupción puede tolerar cada uno y de qué elementos depende cada servicio para funcionar y recuperarse.
P: ¿Qué es una «empresa mínima viable» (MVC)?
R:La MVC es la unidad más pequeña de una organización capaz de atender a los clientes, generar ingresos y cumplir con sus obligaciones legales, normativas, de seguridad o relacionadas con su misión más urgentes. Es un componente fundamental para comprender y poner en práctica ResOps, ya que ayuda a priorizar qué se debe proteger y recuperar, y en qué orden.
P: ¿En qué se diferencia la tolerancia al impacto del objetivo de tiempo de recuperación (RTO)?
R: La tolerancia al impacto describe el nivel de interrupción que la empresa puede soportar antes de que el perjuicio resulte inaceptable. Puede incluir la corrupción de datos, el deterioro del rendimiento, resultados incorrectos, la capacidad de realizar transacciones y soluciones manuales alternativas. El RTO es un objetivo de planificación de la recuperación centrado en el tiempo, más que en el impacto en la productividad o en la misión.
P: ¿Qué debe incluirse en el mapeo de dependencias?
R: El mapeo de dependencias identifica lo que necesita un servicio crítico para funcionar y recuperarse, incluyendo aplicaciones, datos, infraestructura, sistemas de identidad, servicios en la nube y SaaS, terceros, personas y otros servicios internos.P: ¿Con qué frecuencia deben revisarse los servicios críticos y las instalaciones? R:Revísalos periódicamente y cuando se produzcan cambios significativos en el negocio o la tecnología. Las nuevas prioridades, aplicaciones, proveedores, integraciones o sistemas de IA pueden modificar la ruta de Recovery. Michael Thelanderes director sénior de marketing de productos en Commvault.