Plan de recuparación ante desastres (DRP), Cómo garantizar la rápida recuperaciuón de tu entorno OT
Gorka Alcorta Ruiz de Alegría
Consultor de comunicaciones industriales
Cibcom Technologies, S.L.
1. RESUMEN
Cada vez tenemos más elementos complejos en nuestras plantas de producción, muchos de ellos incluyen programación y tecnología del ámbito IT, por ello es necesario incluir dichos dispositivos OT en nuestro Plan de Recuperación ante Desastres, vamos a ver cómo planificarlo y qué herramientas tenemos para automatizarlo y hacerlo más eficiente, en este caso con el software Octoplant de AMDT.
2. CONTENIDO
El Plan de Continuidad de Negocio está formado por un conjunto de planes de actuación, planes de emergencia, planes financieros, planes de comunicación y planes de contingencias destinados a mitigar el impacto provocado por la concreción de determinados riesgos sobre la información y los procesos de negocio de una compañía. El Plan de Recuperación ante Desastres en una parte del mismo, hoy vamos a hablar de él y ampliar su alcance ya conocido en el mundo IT (Tecnologías de la Información) al mundo OT (Tecnología Operacional).
Según la definición formal, el Plan de Recuperación ante Desastres o DRP (Disaster Recovery Plan), como lo denominaremos en adelante, es un documento creado por una empresa en el que se detallan las instrucciones a realizar cuando surja un incidente sin planificar: apagón, cortes de actividad, ataque por vulnerabilidad de seguridad, secuestros y otros siniestros.
Siempre pueden darse estas circunstancias de forma natural: inundaciones o movimientos sísmicos, casual: averías, incendios, colapsos de infraestructuras o intencionados: sabotajes o ciberataques y otro tipo de eventos que pueden provocar el malfuncionamiento o parada de nuestros sistemas.
El DRP contiene una estrategia de minimización de daños ante un desastre sobre un activo que tenga la empresa: bases de datos, servidores, etc. La idea que se persigue es la reanudación de la actividad o de la normalidad en el plazo más breve posible. En este artículo vamos a centrarnos en el DRP en entornos OT pero y veremos diferentes elementos que no coinciden con el entorno IT, es decir incluiremos sistemas SCADA, sistemas MES, PLCs, Robots y cualquier elemento programable del entorno de planta.
Vamos a tratar 3 aspectos fundamentales del DRP, primero que cosas tenemos que tener en cuenta a la hora de elaborarlo, segundo qué normativa / directiva /ley nos obliga a tenerlo preparado y por última parte veremos una herramienta, Octoplant, que nos ayuda a automatizar parte de ese DRP con backups automatizados del entorno OT, algo que en el mundo IT ya lleva años implantado por múltiples softwares.
2.1. Cómo elaborar un DPR
Las claves para establecer un plan sólido de recuperación ante desastres de TI consisten en:
- Alinearlo con el plan de continuidad de negocio. Así se concentran los esfuerzos en los sistemas o aplicaciones que se consideran críticos para el negocio. Para unas empresas pueden ser los sistemas de producción y para otras, la página web o el CRM.
- Evaluación de riesgos. Permite identificar los niveles de riesgo inaceptables para la organización, además de los puntos únicos de fallo a los que se enfrenta.
- Llevar a cabo un análisis de impacto de negocio (BIA). Tiene como principal objetivo identificar las necesidades de la organización en términos de recuperación, sobre todo en aquellos servicios que consideramos imprescindibles para el funcionamiento de la empresa.
- Desarrollar las medidas para recuperación para los servicios y aplicaciones prioritarios, de manera que se puedan poner en práctica los mecanismos para volver a la operación normal lo antes posible.
- Realizar pruebas. Debemos programar pruebas periódicas (desde revisar una lista de verificación o parar completamente los sistemas para verificar que podemos recuperarlos, o transferirlos a sistemas alternativos) que nos confirmen la continuidad en caso de desastre.
- Actualizar y mejorar el plan. En base a lo aprendido por la experiencia tanto real cómo en las pruebas realizadas y también a la evaluación de nuevos riesgos debemos mejorar de manera continua nuestro plan.
- Formación y capacitación los encargados de ponerlo en marcha, concienciar y difundir el plan. Debemos designar a los responsables de realizar el plan, capacitarlos para realizar sus funciones y concienciar a toda la plantilla para minimizar los riesgos.
2.2. Quién nos obliga a tener un DPR
Aunque parezca lógico contar con él, tristemente muchas empresas no tienen definido un plan de continuidad de negocio y mucho menos un DPR para su parte OT, la lógica nos dice que por el propio bien de la empresa deberíamos tener uno, Por si aún fuera necesario convencernos, vamos a hablar de donde nos lo exigen o recomiendan:
- Extracto de la directiva NIS2, (UE) 2022/2555, que este próximo 18 de octubre de 2024 se transpondrá como Real Decreto Ley.
"2. Las medidas a que se hace referencia en el apartado 1 se fundamentarán en un enfoque basado en todos los peligros que tenga por objeto proteger los sistemas de redes y de información y el entorno físico de dichos sistemas frente a incidentes, e incluirán al menos los siguientes elementos:
a) las políticas de seguridad de los sistemas de información y análisis de riesgos;
b) la gestión de incidentes;
c) la continuidad de las actividades, como la gestión de copias de seguridad y la recuperación en caso de catástrofe, y la gestión de crisis;"
- Guía sobre Controles de Seguridad en Sistemas OT del Ministerio del Interior
- RECOMENDACIÓN DE MEDIDAS BÁSICAS DE SEGURIDAD
Finalmente, los accesos remotos a la infraestructura deben de ser monitorizados y registrados, de manera que puedan ser auditados en un futuro.
19- Plan de respuesta ante incidentes. Resulta esencial que los activos/instalaciones estén preparados ante tal eventualidad, a fin de minimizar su impacto y recuperar el nivel habitual de funcionamiento en el menor tiempo posible. Dada la imposibilidad de prever cada posible tipo de incidente, los planes se centran en la gestión del mismo, garantizando que el personal esté concienciado sobre la problemática de la ciberseguridad, formado para identificar fallos en planta como consecuencia de posibles fallos y/o sabotajes en los SCI. El personal se involucra activamente en el diseño, elaboración y pruebas de los ciberincidentes, estableciendo comunicaciones fluidas y la asignación clara de responsabilidades. Resulta fundamental ensayar los planes para someterlos a prueba y que todo el personal involucrado se familiarice con ellos.
20- Capacidades de copia de seguridad y restauración. La recuperación tras un incidente de seguridad, un fallo de hardware o software o tm problema de corrupción de datos, pueden requerir la restauración total o parcial de uno o varios dispositivos o del sistema en su conjunto.
- Norma IATF 16949:2016
- Real Decreto 43/2021, de 26 de enero, por el que se desarrolla el Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información. Este hace referencia a la NIS1, en vigor para infraestructuras críticas.
2.3. Copia de seguridad de elementos OT
Cómo ya sabemos el “papel” lo aguanta todo y podemos realizar las copias de seguridad de los programas y dispositivos así cómo mantener su historial de forma manual registrándolo en un documento.
La cosa se complica cuando vamos añadiendo variables: gran número de dispositivos, modificaciones realizadas por personal interno y externo, trabajo en turnos de relevo, modificaciones a pie de máquina causadas por “emergencias” productivas. En resumen, puede hacerse imposible mantener las versiones actuales de los proyectos, copias de seguridad.
Vamos a aplicar la metodología de las 5 W (Quién, qué, cuándo, dónde, por qué) aplicada a la gestión de cambios y copias de seguridad para ver si nuestro sistema funciona:
Si no podemos responder a estas 5 preguntas con seguridad necesitamos automatizar nuestro proceso y para ello vamos a hablar de la herramienta Octoplant de AUVESY.
¿En qué consiste?
Es un software que nos permite por un lado trabajar como lo haríamos con cualquier gestor documental, pero tratando programas de dispositivos, nos permite realizar backups de los dispositivos de planta y además nos permite generar documentación referente a la trazabilidad del proyecto.
¿De qué elementos estamos hablando?
Hablando de los dispositivos presentes en planta, siempre que estén accesibles desde el servidor podrán ser objeto de backup.
¿Cómo trabaja?
Cómo en casi todos los nuevos sistemas la mayor complicación es mentalizar al personal en la nueva metodología de trabajo, voy a simplificar el proceso de trabajo en 4 pasos.
- Cargamos nuestros proyectos en el servidor de Octoplant como versión inicial.
- Cuando se va a trabajar sobre el proyecto se descarga del servidor a local, se modifica y si fuera necesario se carga en el dispositivo (PLC, CNC, …) al finalizar se vuelve a subir al servidor como nueva versión con los comentarios pertinentes.
- En el momento en que lo hayamos programado el sistema se conectará al dispositivo de planta y capturará un backup del proyecto cargado en el dispositivo.
- Dicho backup se comparará con el backup previo y con la última versión del proyecto mostrando el resultado de dicha comparación y si así lo programamos notificándolo al responsable del proyecto para que determine cómo actuar.
De esta manera combinando la gestión de versiones con los backups automatizados podremos controlar los cambios en dicho dispositivo y en caso de ser necesario, bien por avería de algún componente de las máquinas, por ejemplo, un PLC, o bien por un ataque malintencionado tendremos siempre disponible la versión que debemos de cargar al dispositivo para volver a recuperar la producción lo antes posible.
3. REFERENCIAS
- INCIBE, Publicación: ¿Ya tienes tu Plan de Recuperación ante Desastres? DIRECTIVA (UE) 2022/2555 DEL PARLAMENTO EUROPEO Y DEL CONSEJO de 14 de diciembre de 2022.
- IATF 16949:2016
- BOLETÍN OFICIAL DEL ESTADO
