En este artículo se analiza qué cambió en la saga de estándares ISO 27002 respecto de la continuidad de negocio.
Introducción
En este artículo se aborda el posible solape entre 2 disciplinas bastante relacionadas entre sí, aunque cada una con su área específica: la seguridad de la información y la continuidad de negocio. En particular, se analiza el grado en que los 2 estándares de referencia (ISO 27001 e ISO 22301) están, o no, solapados.
En un artículo aparte trataré las áreas de confluencia de ambos mundos y cómo puede llevarse a cabo la implantación de ambos estándares sin caer en redundancias innecesarias.
La razón de escribir este artículo se debe a que, en no pocas ocasiones, me han manifestado cosas como:
- “Si tengo un SGSI certificado, entonces ya tengo continuidad de negocio”
- “Para que una organización cumpla con los controles del capítulo 17 de la ISO 27002, basta con que tenga hecho un BIA y disponga de un DRP”
Las anteriores afirmaciones son, en mi opinión, incorrectas y se deben a diversas razones, entre las cuales, principalmente, se cuentan las siguientes:
- Entendimiento incorrecto o limitado de en qué consiste realmente la continuidad de negocio.
- El cambio que han tenido las normas ISO 27001/27002 al respecto.
La primera de estas causas es bastante habitual, ya que, a diferencia de otros países en los que la continuidad de negocio está muy extendida, en España hay muy pocos sectores, el financiero básicamente, que requieran su implantación. No pretendo, ni podría, solucionar esa carencia en un único artículo, aunque sí animo a consultar las excelentes publicaciones que sobre la materia se encuentran en este foro.
En cuanto a la segunda de las causas, analicemos primero el tratamiento que sobre la continuidad de negocio se ha venido haciendo desde las distintas versiones de los estándares ISO 27001 e ISO 27002, y cómo lo ahí plasmado se sigue arrastrando hasta la fecha, aunque lo que se pide ahora haya cambiado bastante.
Primero, retrocedamos unos años.
Antecedentes
La actual norma ISO 27002 data de 2013 en su versión en inglés, pero proviene de una larga estirpe de normas, algunas ya ISO, pero otras eran las venerables BS7799, la primera de 1999.
Pues bien, en todas ellas, llegando hasta la ISO 27002 de 2005, había un conjunto de controles de continuidad de negocio mediante los cuales se venía a requerir que la organización implantase algo parecido a una gestión de la continuidad de negocio. Por ejemplo, se solicitaba que:
- La organización contase con un marco de gestión completo de la continuidad
- Que se llevase a cabo análisis de impacto y también de riesgos
- Que se escribiesen planes de continuidad
- Que éstos se probasen regularmente
Así que los auditores, a la hora de verificar si estos controles estaban aplicados, solicitaban, por ejemplo, los BIAs, un Plan de contingencia y evidencias de que se hubiera probado en alguna ocasión.
No obstante, y es una opinión particular, los requisitos de continuidad de negocio plasmados en la 27002 eran un tanto confusos e incompletos.
Estas carencias venían suplidas por otras normas, en aquel entonces en formato de “British Standard” (las BS 25999-1/2), que sirvieron en gran medida de base para un nuevo estándar internacional de continuidad de negocio, la ISO 22301 de 2012.
Así que cuando tocó revisar la ISO 27002, ya no tenía sentido venir a solicitar lo mismo que ya se pedía en otra norma, por lo que su versión de 2013 introdujo cambios relevantes.
Situación actual
¿Y qué es lo que cambió? Al fin y al cabo, dirán muchos, se sigue pidiendo que haya continuidad de negocio, o eso es lo que parece, ¿no?. Lo cierto es que la cosa ha dado un giro interesante.
Vayamos al requisito de la propia norma: la sección 17.1, establece como objetivo que “la continuidad de la seguridad de la información debería formar parte de los sistemas de gestión de continuidad de negocio de la organización”.
Concretando un poquito más, se indica en el control 17.1.1 que “la organización debería determinar sus necesidades de seguridad de la información y de continuidad para la gestión de seguridad de la información en situaciones adversas, por ejemplo, durante una crisis o desastre”.
Pongamos un ejemplo: imaginemos el caso de un banco que decide abordar la continuidad de negocio, empezando por identificar las funciones de negocio a priori importantes para, a continuación, llevar a cabo los correspondientes BIAs. Supongamos que dentro de esas funciones están las áreas de Inversiones, atención al cliente, gestión hipotecaria, anti-fraude, etc.
Es más, el banco tiene una estrategia de contingencia perfectamente definida y, en caso de indisponibilidad de su sede central, dispone de unas oficinas alternativas a las que mover al personal esencial de esas funciones de negocio, con la infraestructura, comunicaciones y sistemas necesarios para recuperar la operativa en cuestión de unas pocas horas.
Sin embargo, este banco tiene desplegado un SIEM que monitoriza constantemente su infraestructura y operaciones, y un equipo de personas que atienden incidentes de seguridad internos y externos en régimen de 24×7, aparte de administrar y operar la infraestructura de seguridad (cortafuegos, AV, IPS, etc.). Este personal no tiene una ubicación alternativa asignada en las oficinas de contingencia, por no mencionar que tampoco están redundados algunos de los elementos de seguridad.
Como a veces pasa, estas tareas “TIC” no se han considerado, a priori, importantes, y no han sido analizadas, aunque lo cierto es que, de haberse hecho habrían visto que eran imprescindibles y que, por cuestiones operativas y de cumplimiento, el banco no puede funcionar sin el SIEM y sin el servicio de gestión de incidentes y gestión de la seguridad, ya que podrían dispararse los niveles de fraude, entre otras consecuencias indeseables.
Pues bien, esta organización no estaría cumpliendo con lo estipulado en la ISO 27002, porque no se ha hecho la pregunta elemental: “¿Qué impacto tendría que se interrumpieran las tareas del área de seguridad de la información?”.
No estamos diciendo que, necesariamente, haya que poner a la función de la seguridad de la información a la misma altura que la más crítica de las actividades de la organización, sino que debe ser incluida en el análisis, se deben definir estrategias capaces de cumplir con el RTO y RPO de dicha función, debe haber planes que aborden su recuperación, y debe formar parte del programa de pruebas de los preparativos de contingencia.
Así que, la cosa es bastante sencilla: para ver si una empresa cumple con los controles de la sección 17.1 de la ISO 27002:2013, miremos si se incluye la función de seguridad de la información dentro del listado de áreas organizativas a las que aplica la continuidad de negocio, aunque sólo sea para que lleguen a la conclusión de que, en caso de contingencia, pueden estar varios días sin el personal o sin las actividades y servicios que presta (que ya me resultaría extraño).
