ISO 27004
La nueva norma, oficialmente denominada "Information technology -- Security
techniques -- Information security management -- Measurement" viene a sofocar uno de los grandes abismos que existen en el proceso de construcción de un SGSI. Ya he
comentado muchas veces que certificarse con ISO 27001 es establecer que las cosas se vigilan dentro de un marco de gestión y que existen procesos de mejora continua sobre el funcionamiento de las medidas de seguridad. Sin embargo, gestionar bien no implica tener buena seguridad. Obviamente ayuda mucho tener un marco de gestión y revisión continua pero es sólo una condición necesaria, no suficiente.
Esta nueva norma establece criterios para la medición del estado de la seguridad. Es aquí donde los datos y las evidencias deben poner al SGSI en su sitio. Es cuando los resultados nos proporcionan información sobre cual es la situación real de las medidas y si están o no funcionando de acuerdo a los objetivos planteados. Por eso es tan importante la publicación de esa norma. Es la única manera de valorar si tanta gestión de la seguridad está sirviendo para algo, y esos hechos avalados por resultados y datos concretos que se están midiendo.
Por tanto, un SGSI certificado y todo que no logre unos buenos resultados en sus indicadores será solo un adorno, dado que habrá una bonita gestión pero con ello no se estará logrando satisfacer los objetivos planteados.
Estas reflexiones ya las plantee de forma más extensa en el post SGSI virtuales en su momento. Os resumo lo que en aquel momento comentaba respecto a las métricas.
La medición debe servir para cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la
gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más hostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué
indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.
Estableciendo el rumbo de un SGSI
Como complemento a lo dicho en él, hay unas sencillas reglas que debe cumplir una buena métrica:
Ser objetivas:Debe aportar un criterio de recogida de datos medible y objetivo, que
no dependa de valoraciones subjetivas.
Ser fáciles de obtener:Los datos sencillos, simples de calcular y poco costosos de
recoger son buenos candidatos a ser métricas. Al respecto, lo más sencillo es recurrir a datos proporcionados por herramientas o procesados de forma automatizada.
Expresables de forma numérica o porcentual. No deben estar basados en
etiquetas cualitativas tales como "alto", "medio" o "bajo".
Expresable usando algún tipo de unidad de medida: Siempre deben estar
vinculadas a algo tangible basado en escalas como el tiempo, número de defectos, a cuantías económicas.
Significativas: Toda buena métrica debe ser significativa, debe ser relevante para el
hecho o circunstancia que se desea medir y debe aportar criterio. Una métrica que no aporta información no es una buena métrica y debe ser desechada.
Patricia Vanaclocha, de S2 Grupo tiene dos entradas excelentes que describen
perfectamente la problemática que se plantea cuando uno se embarca en esto de construir un SGSI. Podéis leerlas en
Errores comunes en la Implantación de un SGSI
Implantar un Sistema de Gestión de Seguridad de la información se está convirtiendo cada vez más en un objetivo para los departamentos TIC de las empresas. Los que nos dedicamos a hacer consultoría para la implantación de esos SGSI vamos poco a poco viendo que los problemas que nos encontramos en un cliente se repiten, al menos parcialmente, en el siguiente, y que los clientes asumen erróneamente afirmaciones para nada ciertas lo que hace que cuando se tropiezan con la realidad, haya alguna sorpresa.
Plantearé hoy tres de los errores más comunes asumidos por algunas de las empresas que deciden implantar un SGSI:
„CONTRATO A UNA CONSULTORA Y ELLOS LO HACEN TODO‟
Esta suposición no es válida en la implantación de ningún Sistema de Gestión, pero menos si cabe en un SGSI. Como en cualquier proyecto de similares características, es imprescindible la colaboración de muchos miembros de la plantilla de la empresa para arrancar y llevar a buen puerto el diseño y la implantación de un Sistema de Gestión que trata de protegerla información crítica para el negocio, ya que hay muchos departamentos y perfiles que trabajan a diario con esa información que se busca proteger; al fin y al cabo, son ellos los que mejor conocen la organización. Por ello, para que la empresa consultora pueda hacer un buen análisis de riesgos va a requerir colaboración por parte del cliente para identificar los riesgos, analizarlos y valorarlos, seleccionar las opciones para su tratamiento, y para implantar el plan de tratamiento de riesgos con el que se pretende mitigar el nivel de riesgo detectado. Tampoco hay que dejar de lado que la organización ya dispondrá en muchas
ocasiones de controles de seguridad que en ocasiones serán suficientes, y en otras será necesario ampliar.
Si bien los consultores deben invertir muchas horas en darle forma el sistema, la organización debe invertir bastantes horas en proporcionarles la información que necesitan para hacer un buen diseño y en ejecutar las tareas que se identifiquen como necesarias para llevar a cabo su implantación. Hay casos en los que también se contrata a la consultora externa la implantación de los controles seleccionados pero suelen ser los menos, así que en la mayoría de los casos es la organización la que debe ir implantando la lista de controles seleccionados y no implantados inicialmente. Esta lista puede ser muy corta pero también muy larga, depende de la situación de partida de la organización desde el punto de vista de la seguridad. Sin embargo, antes de pasar al siguiente error, tampoco es bueno pecar de
pesimista: no hay que olvidar que la implantación de un SGSI en ocasiones (no siempre) no es otra cosa que la documentación y procedimentación de controles, tareas, rutinas, formas de trabajar que la organización ya conoce, en definitiva, la formalización de un sistema de gestión con el que hace tiempo que “se siente a gusto”. Dicho de otra forma, y aunque les parezca obvio, el trabajo que tendrá que abordar la empresa en el momento de la implantación del SGSI será inversamente
proporcional al trabajo que hasta ese momento haya realizado en la gestión de su seguridad. En ocasiones ese esfuerzo será significativo, y en otras, más bien poco. „ESTE PROYECTO SÓLO CONCIERNE AL ÁREA TIC‟
Otro gran y común error. Ya que como hemos comentado, se trata de proteger la información crítica para el negocio, en el proyecto se deben ver involucradas
personas de muchas áreas: Departamento TIC (por su puesto) pero también RR.HH, Departamento financiero, Departamento legal, Departamento de Marketing y todos aquellos que trabajan con esa información crítica para el negocio que se va a proteger. Todos deben ser conscientes de qué papel juegan ellos en el SGSI
implantado, cómo de crítica es para el negocio la información con la que trabajan a diario y de qué modo debe cambiar su forma de manejarla para garantizar que se encuentra debidamente protegida. Por supuesto, se les debe preguntar, explicar y escuchar, antes de decidir los controles que se van a implantar y que les va a afectar, ya que de lo contrario se corre el riesgo de que perciban las nuevas normativas o políticas que se van a definir en materia por ejemplo de contraseñas, control de acceso, destrucción de información, uso del correo electrónico, instalación de software, etc, como un mero capricho del área TIC a las que no encuentran ningún sentido y que simplemente perciben como muy engorrosas.
„SE VAN LOS AUDITORES Y YA HEMOS TERMINADO‟
Normalmente, cuando se van los auditores también se van los consultores externos y eso significa que la empresa se queda con su certificado y „sola ante el peligro‟; en unas organizaciones, eso supondrá que ha llegado la hora de la verdad: de
comprobar cómo de bien planteado está el SGSI y de ver si es operativo. En otras, ese „peligro‟ no será tal; la obtención del certificado no significará otra cosa que el premio y la aprobación externa de un sistema de gestión de la seguridad que la organización ya había asumido como propio, como ventajoso y positivo para su negocio antes siquiera de plantearse la obtención del sello de una entidad acreditada.
Obviamente, siempre será responsabilidad de los consultores haberse asegurado de que el SGSI diseñado, bien a partir de un sistema de gestión ya en funcionamiento, bien a partir de la nada, es adecuado para la empresa en la que se ha implantado. Eso significa que debe ser fácilmente operable, acorde al tamaño de la organización, de su presupuesto y de los recursos que se pueden asignar a su mantenimiento. Muchas veces, cuando se parte de una organización casi „virgen‟ en la gestión de la
seguridad de la información, se puede pecar de querer diseñar un super-SGSI, sin tener en cuenta que tras el proceso de implantación, las personas que se han visto involucradas recuperan sus tareas diarias, y la prioridad del SGSI baja unos cuantos niveles respecto a estas otras tareas. Obviamente la existencia de un SGSI en una organización sin una gestión de la seguridad previa requerirá un esfuerzo: mantener al día su inventario de activos, hacer un seguimiento de las no conformidades, obtener los datos para medir la eficacia de los procesos, analizar la información que de ellos se desprende, mantener al día los documentos y registros, es decir, ejecutar todas las tareas que implica un SGSI. En cualquier caso, el reto de lograr un SGSI bien diseñado será lograr que, cuando no lo están ya, los procesos que conlleva se integren de manera lo más transparente posible en el funcionamiento de la
organización. A veces, este es casi el punto de partida; en otros casos, la meta está un poco más lejana.
Con esta entrada no pretendo desanimar a nadie, ni mucho menos, sólo señalar aspectos obvios: que la implantación, y sobre todo el mantenimiento de un SGSI es una tarea continua, del día a día, en la que se deben involucrar a varias personas de la organización, se le debe dotar de los recursos y presupuesto necesario, y que debe contar con el apoyo de la alta dirección para tener garantizado su éxito. Nada, desde luego, diferente de lo que cualquiera podría esperar de un sistema de gestión, sea cual sea.
Cosas a tener en cuenta en la implantación de un SGSI Cosas a tener en cuenta en la implantación de un SGSI Patricia Vanaclocha, 21 mayo 2009 |
Ya comentamos en otro post que, como empresa consultora que implanta SGSIs en sus clientes, hemos detectado que en muchas ocasiones el cliente tiene opiniones preconcebidas sobre el proceso de implantación que no se ajustan a la realidad. También es cierto que, además de esos conceptos previos, hay problemas con los que una se encuentra durante el proceso de implantación, y para los que hace falta cierta „mano izquierda‟. A los lectores que hayan implantado o participado en la implantación de un Sistema de Gestión de Seguridad de la Información, bien en la parte de cliente, bien en la de consultoría, seguro que no les descubrimos
demasiadas cosas nuevas (y en algunos casos es posible que se reconozcan en la entrada), pero al resto quizás les resulte de mayor utilidad. Dicho esto, pasemos a esos “problemillas”…
1. Cuesta hacer entender a los técnicos que el SGSI “va con ellos” y que no es algo del Responsable del Sistema o del Director de Área.
Normalmente, la decisión de implantar un Sistema de Gestión de Seguridad de la Información la toma el Director del área TIC, el Gerente de la organización, o algún cargo de la alta dirección. Cuando esta decisión llega al departamento de
informática o área TI, es importante explicarles claramente el por qué de esa decisión, las ventajas que se esperan conseguir con este proyecto, cómo se van a
simplificar muchas de las tareas de su área una vez implantado el sistema, etc. De lo contrario los técnicos verán este proyecto como un nuevo „capricho‟ del jefe que decide lo que se hace y a ellos les toca hacer el trabajo extra.
2. Es difícil conseguir que perfiles eminentemente técnicos vean la utilidad de medir para mejorar
Como he comentado en el punto anterior, si no se explican y difunden las ventajas que va a aportar el nuevo Sistema de Gestión, es fácil que la gente sea reacia a cambios que para ellos sólo suponen un carga extra de trabajo. A nadie se le escapa que normalmente los compañeros con perfiles técnicos no son muy amigos de realizar tareas de gestión, a las que suelen clasificar como un rollo y ven como simple papeleo (yo misma he sido técnico de comunicaciones durante varios años y sé de lo que hablo).
Una de las cosas que por nuestra experiencia cuesta más de hacer entender, es el hecho de que como todo Sistema de Gestión que se apoya en un ciclo de mejora continua (PDCA), es vital medir para poder observar cómo las cosas mejoran a medida que el sistema va madurando. En este tema es importante que tanto desde la Dirección de la organización como por parte de la empresa consultora, se haga un esfuerzo extra en inculcar a los técnicos que participen en el proyecto las ventajas que supone saber que, por ejemplo, ahora se resuelven las incidencias de seguridad en 2 minutos menos de media que el mes pasado, pero que sin embargo hay que hacer un esfuerzo extra en mejorar el proceso de copias de respaldo ya que se han incrementado el número de fallos en un 10%.
Si no medimos, trabajamos en base a sensaciones, y las decisiones tomadas sin la información necesaria es fácil que conduzcan a equivocaciones.
3. Es costoso involucrar a Áreas como Recursos Humanos, Departamento Legal, Administración, Comercial, etc., en un proyecto liderado por el Departamento TIC y que ven como ajeno a ellos
Si no fuese suficiente con las reticencias de los perfiles técnicos, otra de las particularidades de un Sistema de Gestión de Seguridad de la Información, es el hecho de que como su nombre indica, lo que persigue es proteger la Información Crítica para el negocio de la organización, y garantizar la continuidad de dicho negocio en caso de catástrofe.
Evidentemente, toda la información crítica para el negocio no está necesariamente „en manos‟ del área TI. En la mayoría de los empresas, no sólo muchos
departamentos tienen sus propias aplicaciones que se muestran reticentes a
abandonar, sino que aun hoy hay mucha documentación que se maneja y/o archiva en formato papel, algo que también hay que tener en cuenta para que quede
debidamente protegida (algo que en cualquier caso la LOPD ya obliga a cumplir en relación con los datos de carácter personal). El caso paradigmático es el
Departamento de Administración o Comercial, que suelen trabajar con facturas, ofertas y otros documentos en formato papel que contienen información de mucho valor para la competencia… ¿Qué pasaría si un comercial perdiera el plan
estratégico comercial de su empresa? ¿Y si el departamento de administración trabaja con una aplicación instalada en un único PC, fuera de la política de copias de la organización, y la aplicación de facturación se corrompiera?
Además de estos departamentos, también es necesario que participen en el proyecto de forma activa miembros del área de RR.HH, por los múltiples controles que les
afectan y el papel vital que tienen en el SGSI: CV-screening de las nuevas incorporaciones, formación en materia de seguridad según la labor que van a desempeñar, medición de la eficacia de las acciones formativas que reciban los empleados en materia de seguridad, mantenimiento del registro de la educación-formación-experiencia y habilidades de los miembros de la plantilla, etc. No es que todo esto deba suponer ningún esfuerzo extra para cualquier departamento de RR.HH medianamente organizado, pero como en cualquier nueva iniciativa, hay que darle forma a estas tareas y formalizarlas.
Por último, uno de los dominios de control que incluye la ISO 27002 es el de conformidad legal, y ahí es dónde entra en juego el departamento legal (si existe). Es imprescindible cumplir con la legislación vigente en materia de seguridad de la información, y en particular con la LOPD, que suele ser la legislación “a vigilar” en este ámbito (pero no la única).
Estos departamentos que he nombrado son sólo ejemplos que se repiten en muchas empresas, aunque el abanico de departamentos a involucrar puede ser mayor o menor según la información que manejen y la forma en la que la intercambien o almacenen. Al final del cuento, a lo que voy es que igual que un Sistema de Calidad involucra prácticamente a toda la organización, un Sistema de Gestión de Seguridad de la Información es equivalente, a pesar de que “Seguridad de la Información” a muchos les haga pensar que es cosa del personal de informática.
4. Si la dirección no apoya el proyecto activamente desde el principio y es consciente de que debe asignar ciertos recursos internos para la definición e implantación del sistema, el proyecto está condenado al fracaso
Después de pasar por prácticamente toda la organización, llegamos al “jefe”: Dirección. La afirmación previa no es particular para un Sistema de Gestión de Seguridad de la información, sino que es válida para la implantación de cualquier Sistema de Gestión. Al respecto, debe quedar claro que al menos el 80% de las tareas necesarias para formalizar un SGSI ya las realizan la mayoría de empresas que tengan un área TI medianamente organizada, pero esto no quita que durante la fase de definición del SGSI se deba dedicar algo de tiempo extra a revisar, mejorar y en muchos casos documentar las metodologías de trabajo del área, y en los casos en los que se detecten desviaciones respecto a lo establecido por la norma se decida cómo abordar estas nuevas tareas y se registre. Como es obvio, esto requiere una dedicación de personal, un coste, que dirección debe estar dispuesta a asumir si quiere llevar a buen término el proyecto (como suele ser el caso).
Para acabar con la entrada, soy consciente de que el tono de esta entrada puede ser algo “catastrófico” y desalentador; parece que tengamos en contra a los técnicos de informática, a los departamentos no técnicos y casi hasta a Dirección, que quiere un SGSI “sin gastarse un duro”. Nada más lejos de la realidad; en proyectos en los que he participado, la implicación de dirección ha sido total tanto en recursos como en motivación, y los departamentos mencionados, después de ciertas reticencias iniciales habituales en cualquier proyecto de esta magnitud que se abarque en una organización, se han prestado a colaborar casi sin problemas. En definitiva, ninguno de los aspectos comentados anteriormente son insalvables, siempre que se cuente con algo de „mano izquierda‟, ganas y una buena gestión. Con esta entrada (y la anterior) simplemente intento poner de manifiesto algunos de esos problemas e
inconvenientes que hay que tener en cuenta, a pesar de que en algunas organizaciones ni siquiera asomen la cabeza.
Dicho todo esto, les emplazo a que estén atentos a la publicación del próximo post relacionado con esta temática (Implantación de SGSIs) ya que en él, después de la visión algo “negativa” que hemos tenido en esta y la anterior entrada, describiré las ventajas que aporta este sistema de gestión y que como podrán comprobar, son innumerables.
Conforme vayan siendo publicadas, iré comentando algunas otras normas que van a empezar a ir viendo la luz como extensión del marco ISO 27000 relativo a la seguridad de la información. Los proyectos en proceso y publicados por el Subcomité 27 se pueden consultar en el siguiente enlace.
El pasado mes de diciembre vió la luz la norma ISO 27011:2008 que es un desarrollo del marco de controles ISO 27002 diseñado específicamente para el sector de las telecomunicaciones. El título de esta nueva norma es Information technology - Security techniques - Information security management guidelines for telecommunications organizations based on ISO/IEC 27002. ISO 27011:2008 como la norma ISO 27799:2008 desarrollada para el sector sanitario son
extensiones de la norma ISO 27002:2005 contemplada como un catálogo básico de controles que puede ser utilizado para implantar un SGSI. Tal como establece la norma ISO 27001:2005, a la hora de seleccionar controles se pueden elegir aquellos que figuran como Anexo A y que se
corresponden con ISO 27002 o bien aquellos controles que la organización entienda que pueden ser interesantes o de aplicación. Por tanto, vamos a ir viendo aparecer normas de seguridad que son extensiones a medida de los diferentes sectores que están intentando establecer un conjunto de medidas de seguridad acordes con sus necesidades específicas.
SGSI virtuales
Publicado por Javier Cao Avellaneda
La proliferación de subvenciones y la motivación que proporciona el coleccionar certificaciones a nivel de organizaciones está generando un pequeño "boom" dentro del mundillo de la seguridad de la información y en concreto, la certificación bajo la norma ISO 27001:2005.
Esto que en teoría es viento favorable y debería generar cada vez más concienciación y producir mejoras en la gestión puede entrar en un círculo vicioso nada deseable. Por parte de las consultoras siempre se comenta que lograr la certificación es el premio al buen trabajo y el esfuerzo realizado en materia de seguridad. Sin embargo, se empieza ya a detectar una tendencia algo más peligrosa que es cuando el esfuerzo se dirige
exclusivamente a lograr la medalla tratando de pasar la auditoría de certificación de cualquier forma, aun cuando ello no suponga disponer de una verdadera "gestión de la seguridad de la información".
Quiero comentar qué cosas son imprescindibles para que una organización tenga un SGSI real, y no uno virtual y certificado.
Primero: Es necesario tener claro cuales son nuestros objetivos de seguridad. Cada
organización tiene un por qué en relación a sus necesidades de seguridad. Esta información se obtiene en la fase de análisis de riesgos, donde por cada proceso debemos pensar qué consecuencias puede tener la inseguridad. De esta forma hallamos qué es lo que tiene valor para la organización, atendiendo a requisitos de disponibilidad, integridad y confidencialidad. Obtener estos requisitos es también el por qué es necesario hacer el análisis de riesgos.
Segundo: Definir los objetivos que el SGSI debe perseguir. Una vez que acaba la
fase de análisis de riesgos, conocemos cuales son los peligros potenciales que podrían generar mucho daño a la organización y por tanto, tenemos identificados todos aquellos eventos que bajo ningún concepto queremos que sucedan. El SGSI debe ser valorado y revisado al menos anualmente, para verificar que todo el esfuerzo que se está realizando en la materia se está logrando rentabilizar. Este concepto significa para el caso del SGSI que las medidas de seguridad funcionan y que los incidentes no visitan nuestra organización. Para ayudarnos en estas
cuestiones es para lo que deben establecerse los objetivos del SGSI y sus
correspondientes indicadores. ¿Cuantos son necesarios? Personalmente creo que los suficientes para valorar si todas las directrices dadas en la "Política de seguridad" se están cumpliendo. Cuantos más sensores del estado de la seguridad mejor, siempre que su gestión y mantenimiento sea algo llevable. A más información, más criterio para tomar decisiones. Los indicadores son una parte muy importante en el proceso de feedback que todo SGSI realiza para ajustarte a los objetivos planteados.
Tercero: Realizar el despliegue de medidas de seguridad para gestionar los riesgos
y ejecutar el plan de tratamiento de riesgos que se haya planteado. Esta norma en esencia tiene como estrategia base de seguridad la prevención. El mérito de un buen SGSI es que evita daños. Por tanto, pervertir este funcionamiento elimina la esencia del beneficio que la gestión de la seguridad debe proporcionar a la organización. ¿Qué significa esto? Pues que no hay que hacer las cosas para superar la
certificación sino para mitigar riesgos. Tengo la sensación de que muchos
procedimientos se escriben para que queden bonitos el día de la auditoría pero en el fondo no está detrás la búsqueda de un buen mecanismo de eliminación de
vulnerabilidades. El SGSI debe prevenir o detectar lo más tempranamente posible. De lo contrario, los daños se producen y aunque luego en la fase de revisión del sistema se pueden producir ajustes, el impacto ya se ha producido y la revisión sólo sirve para intentar no caer dos veces en la misma piedra.
Cuarto: Gestionar y monitorizar el funcionamiento de las medidas de seguridad.
Una vez que el sistema está en marcha, la gestión de incidentes y de no
conformidades son el nuevo pilar en el que se basa el SGSI. La mejora continua crea un proceso de retroalimentación que realiza los ajustes necesarios al
funcionamiento establecido en base a detectar fallos que generan o bien acciones correctoras o bien acciones preventivas o bien sugerencias de mejora. El
mantenimiento del SGSI se basará en solucionar las pegas del día a día y en la revisión del sistema que se realiza cada vuelta del ciclo donde se valoran también los resultados obtenidos en el seguimiento de indicadores y cumplimiento de objetivos.
Quinto: Formación y concienciación en la materia. Como me apunta "Deincógnito"
en los comentarios, la formación de las personas que vayan a gestionar el SGSI sobre esta disciplina de la seguridad de la información es esencial. Dificilmente se puede gestionar "algo" sobre lo que se desconoce su funcionamiento, conceptos y criterios. Además de esta formación de las personas que operan el SGSI, es
necesario que los actores principales de la protección, los usuarios del sistema estén entrenados para que la protección sea una cosa de todos.
Dicho esto, voy a tratar de identificar los sintomas principales de un "SGSI virtual".
Los objetivos de seguridad no son proporcionados por la Dirección: Nadie sabe
mejor lo que se juega que quién es dueño del negocio. Por tanto, de cara a establecer los objetivos, deben surgir de dentro para solucionar los potenciales problemas que más daño podrían producir a la organización que se quiere certificar. Las
consultoras en estos aspectos podemos asesorar pero no decidir. No es lo mismo plantear opciones en relación a objetivos en forma de propuestas que deben seleccionarse que darlos por escrito como si fueran ya decisiones definitivas.
La metodología de análisis y gestión del riesgo no se entiende por parte de la Organización: Esta situación es un auténtico cáncer para un SGSI. Esta fase es el
corazón del SGSI dado que es donde se realiza el diagnóstico de situación. Un mal diagnóstico implica un mal tratamiento y unos malos resultados. Por eso es
importante que este proceso sea realizado por parte de profesionales adecuadamente formados y con criterio y conocimientos de "seguridad de la información". Es la barrera de entrada que existe para profesionales dedicados actualmente a otras certificaciones de sistemas de gestión y que algunos no parecen percibir. Ponerse a realizar un plan de tratamientos de riesgos sin haber leido al menos la norma ISO 27002 me parece muy osado y sobre todo, poco profesional pero allá cada
Por otro lado, la dinámica utilizada por la Organización para ir realizando el diagnóstico de sus deficiencias y necesidades debe ser sencilla de gestionar por parte de la Organización y en la medida de lo posible, para estas tareas deben ser autónomos. Es cierto que en el inicio de todo proyecto de construcción de un SGSI muchas empresas se ven sobrepasadas dado que son muchos conceptos específicos sobre esta materia. Pero cuando el SGSI empieza a funcionar y da su primera vuelta, la Organización debe poder seguir con el ciclo de mejora continua y debe afrontar la primera revisión del análisis de riesgos con suficientes armas como para poder ajustar todos aquellos matices y aspectos que fallaran o pasaran ignorados en la primera fase. En este sentido, también detecto una peligrosa tendencia que ya he comentado alguna vez. Hay consultoras que no entienden la verdadera importancia del análisis y gestión del riesgo y se lanzan a inventar su propia metodología. No critico que esto se haga, pero si alguien se lanza, que lo haga bien. ¿Qué significa? Al menos la metodología debe cumplir con los puntos especificados por la norma 27001 y debe generar resultados razonables y repetibles. Para ello por suerte, ya disponemos de ISO 27005 que deja asentados ciertos conceptos base que toda metodología debe contemplar. Como organización, para plantearse si la metodología es buena o no el mejor diagnóstico es seleccionar un control y
preguntarse por qué es necesario. Algo como esto qué hago qué sentido tiene. Si la metodología es robusta, debe identificar esa medida dónde debe aplicarse, en base a qué tengo que hacerla (gestiona un riesgo, satisface un requisito legal o es un objetivo de negocio), en qué situación se encuentra y a qué situación debo acabar llevándola, y por último, cómo valoro que está funcionando y ayuda al
cumplimiento de los objetivos del SGSI.
No existen tareas de seguridad: Esto de la certificación 27001 y disponer de la
medalla de la seguridad es muy bonito pero el premio hay que sudarlo. Otro síntoma de un SGSI virtual es que no se definen las tareas que por seguridad deben ir
realizándose a diario para evitar, detectar o remediar las incidencias que se van produciendo. Antes ya dije que la estrategia de la norma es siempre que sea posible la prevención o detección temprana. Para ello, es necesario que existan ciertas rutinas que proporcionen datos que sirvan para valorar nuestra situación, sensores o termómetros que nos avisen de cómo están funcionando nuestros sistemas de información y de cuándo pueden estar produciéndose situaciones potencialmente peligrosas. Esto obedece a la famosa frase de Lord Kelvin "si no puedes medirlo, no puedes mejorarlo" para la que Google ahora tiene un nuevo enunciado "Si puedes medirlo, puedes mejorarlo".La seguridad se debe basar fundamentalmente en la monitorización constante. Como toda área de control, es necesario vigilar que las cosas están en orden. Para ello, los mecanismos de seguridad deben servir para detectar, prevenir o predecir potenciales peligros de manera que podamos estar reaccionando al posible incidente antes de que este ocurra. Con esta filosofía de trabajo o bien somos capaces de hacer que la amenaza no nos afecte o bien
disminuimos mucho su daño si la reacción arranca de forma muy temprana. No es necesario caer dos veces en la misma piedra para saber que si hay un obstáculo y no lo esquivamos, podemos caer. Por tanto, el SGSI se fundamenta en un despliegue de
termómetros de seguridad distribuidos por toda la organización de manera que cuando se superan ciertos niveles salten alarmas que nos pongan manos a la obra a trabajar. Es todo lo contrario de lo que se venía haciendo hasta ahora en seguridad: apagar fuegos.
Los indicadores de seguridad son irrelevantes: La medición debe servir para
cuestionarnos continuamente en base a logs, datos y registros si las medidas de seguridad están funcionando bien. Hemos visto que es esencial establecer unos objetivos relevantes para la seguridad de la organización. Pues igual de crítico es establecer un buen conjunto de indicadores que sirvan para evidenciar que las cosas funcionan y podemos dormir tranquilos. Esta información, desde la perspectiva de la gestión, es la más crítica dado que es la base de la retroalimentación del sistema, los datos que se utilizan para hacer ajustes. Por tanto, debemos disponer de sensores de diferente naturaleza y con diferentes objetivos: medir la evolución de la
ejecución del plan, valorar el rendimiento y funcionamiento de las medidas de seguridad, vigilar el entorno por si se vuelve más ostil y es necesario modificar la valoración de las amenazas, etc. Cuando se audita, al revisar el análisis de riesgos, mirar qué objetivos tiene el SGSI y en qué indicadores se basa ya te puedes hacer una idea de si tienes delante un SGSI real o virtual. ¿Por qué? Muy sencillo, si la información utilizada por las actividades de gestión es mala, la propia gestión es mala. Si las decisiones no están enfocando los verdaderos problemas y no se está vigilando lo que es importante, el ciclo PDCA da vueltas pero no aporta valor a la Organización. Tener un SGSI dando vueltas de mejora continua produce beneficios pero si quien tiene el timón del barco no sabe dónde tiene que ir, dificilmente podrá lograr llegar a puerto. Serán las incidencias que se vayan registrando las que nos pongan de manifiesto estos hechos pero de nuevo se reacciona en base a fallos, y esa no es la idea principal.
Toda esta reflexión sólo tiene un motivo que es hacer ver que tener una organización certificada bajo ISO 27001 no va a servir de nada si no creemos en la necesidad de gestionar bien la seguridad de la información. Cuando uno se certifica en ISO 9001, se esfuerza por lograr la "calidad de sus servicios/productos". De no lograrlo es posible que la
satisfacción del cliente no mejore y los resultados de la empresa no crezcan. Estas situaciones se controlan puesto que las cifras de resultados se vigilan continuamente de forma que cualquier fallo en la "calidad" puede ser identificado y se pueden realizar rápidamente ajustes.
Pues cuando uno se certifica en ISO 27001 se esfuerza por lograr la "seguridad de la información" de sus procesos productivos. De no lograrlo puede suceder que se presente una amenaza importante y que la organización no supere el incidente, y por tanto, la empresa no sobreviva. La seguridad sólo es vigilada por el SGSI de forma que no hay una segunda oportunidad para hacerlo bien. Si el incidente se presenta y falla por ejemplo el plan de continuidad de negocio, podremos tener unos magníficos procedimientos que no servían para nada y lucir nuestro maravilloso "sello 27001" pero la información de la empresa habrá desaparecido para siempre.
El hombre es un animal inteligente que no debe caer dos veces en la misma piedra. Debería ser suficiente con aprender de los demás pero no tener que sufrirlo en las propias carnes para reaccionar.
Cuando trabajaba en Madrid, hice varios cursos de Microsoft y seguridad en la Torre Windsor. Era un edificio gigante con 8 ascensores que se llenaban hasta arriba en las horas puntas. Me pregunto de las más de trescientas empresas cuantas superaron aquel incidente. Al menos he podido encontrar dos que si hicieron bien los deberes pero ¿2 de 200 es un buen ratio?.
Dada la edad de este blog, aquellos acontecimentos fueron ya comentados en su momento y las reflexiones sobre lo que ocurrió, lo que se perdió, los que hicieron bien las cosas y lo que debería hacerse ya han sido publicados.
Tal día como hoy, mi director de proyecto de fin de carrera me ofrecía participar en un proyecto piloto de la Universidad relacionado con el "Análisis de los riesgos de seguridad de la Información" para la Dirección General de Informática de la Comunidad Autónoma de la Región de Murcia.
Aquella oferta de trabajo era mi primera actividad profesional tras la finalización de la carrera y me puso entre las manos la versión 1.0 de MAGERIT junto con el software desarrollado por Sema Group para dar soporte a la metodología. El año 1999 fue, en temas de seguridad, bastante movidito. Todo el mundo iba como loco con las pruebas para superar el año 2000. Algunas aplicaciones de gestión económica empezaban la migración hacia el Euro. Además, en verano de ese año se publica el R.D. 994/1999 con las medidas de seguridad para los sistemas automatizados de tratamiento de datos de carácter personal. Aunque este post no pretende ser un resumen de batallas de un abuelo cebolletas, recuerdo que las primeras referencias por aquel entonces en "gestión de la seguridad" venían
establecidas por las Guias NIST y los libros conocidos como Rainbow Series de la NSA, en concreto el famoso libro naranja.
En aquel momento, los criterios de seguridad de la información americanos eran la referencia aunque ya empezaba a ser famosa la norma BS-7799 con las buenas prácticas para la gestión de la seguridad de la información.
Recuerdo que había dos visiones enfrentadas donde por un lado, los americanos establecían sus criterios propios para todo lo suyo y por otro, se hablaba de gestión de la seguridad de
la información en base al cumplimiento de buenas prácticas. Este mismo choque de enfoques se producía en los criterios de certificación de productos de seguridad, donde los americanos defendían los TCSEC y los europeos los criterios ITSEC. Finalmente ambos criterios acabaron unificados bajo los "Common Criteria" o ISO 15408.
Al finalizar el proyecto con Magerit no tuve más opción que desplazarme a Madrid para seguir currando con esa nueva y apasionante disciplina conocida como "análisis de riesgos de la seguridad de la información". Por suerte, tuve la oportunidad de entrar en la empresa Innosec, una empresa dedicada a seguridad informática donde Gustavo San Felipe, hoy CISO de Acens apostó por un profesional con experiencia en análisis de riesgos dado que eso del diseño de la seguridad basado en el análisis de riesgos lo veía como algo esencial en el futuro. Era la época de la venta masiva de firewalls, de los primeros antivirus
perimetrales y del inicio de las redes privadas virtuales. Y en medio de tanto cacharro estaba yo por allí purulando y dando el follón respecto a lo importante que era escribir políticas de seguridad y el cumplimiento de la LOPD. Fruto de aquella época son dos artículos en la revista SIC sobre "análisis de riesgos" e ISO 15408.
Posteriormente Innosec fue adquirida por el Grupo Satec y pasé a formar parte del departamento de seguridad. Allí más de lo mismo. Empresa muy tecnológica que vendía tanto productos como instalación y configuración de equipamiento de seguridad pero que me tenía como recurso dedicado a los temas burocráticos de la seguridad, el papeleo inutil que eran las políticas, normas y procedimientos. Recuerdo intensamente las discusiones en las comidas sobre la importancia del análisis de riesgos para el diseño de las necesidades de seguridad aunque era un entorno muy técnico que no podía entender como podía haber cosas más importantes que un buen firewall o antivirus. Incluso muchas veces cuando me ponía radical y comentaba que algún día las empresas se certificarían en seguridad igual que se hacía para la calidad con ISO 9000, me veían como el freaky de las políticas y normas de seguridad que nunca sirven para nada.
De aquella época, muy a mi pesar, me llevé puestas también algunas certificaciones de producto (CCSA de CheckPoint, TSCE de TrendMicro, MCP de Microsoft). Todo esto transcurrió entre el año 2000 a 2004. En materia de gestión de la seguridad de la
información, ya estaba publicada ISO 17799:2000 y era una verdadera referencia respecto a qué era necesario considerar cuando se hablaba de "gestión de la seguridad de la
información". Una vez cansado de hacer ofertas sobre diseño de políticas de seguridad y análisis de riesgos y tras finalizar un proyecto de diagnóstico del cumplimiento de la LOPD para un servicio de salud de una comunidad autónoma, decido que tenía que ejercer y bajar a la arena de los proyectos concretos relacionados con lo mio (gestión de la seguridad de la información) y un compañero de curso de seguridad me ofrece la oportunidad de dar un paso hacia Murcia y me bajo a Almería a trabajar para una empresa de servicios de una Entidad Financiera que tenía también un área de consultoría de seguridad de la
información. El primer trabajo en esta nueva empresa consistió en la realización de un análisis diferencial contra ISO 17799:2000 y el desarrollo de una política corporativa de seguridad que sirviera de marco normativo para un conjunto de normas y procedimientos concretos. En esta empresa también tuve que currar bastante en materia de LOPD dado que la parte de medidas de seguridad intentábamos cubrirla como actividades integradas dentro de ISO 17799:2000 de la época. También, casi al final de esta época, se publica UNE 71502:2004 y me toca entrar ya de lleno en los sistemas de gestión de la seguridad de la información. Estuve impartiendo un cursos sobre UNE 71502 y la importancia de esto que
ahora se podía certificar y que era la "gestión de la seguridad de la información". Todo esto transcurrió entre el año 2004 a comienzos del 2007. La verdad es que la publicación de ISO 27001:2005 nos pilló por sorpresa a todos, incluido AENOR. Se hablaba de una futura norma internacional certificable pero lo que en aquel momento se conocía es que cada país trabajaría con su propia norma dentro de su esquema interno de certificación para
posteriormente hacer una norma común e internacional certificable. BS tenía su 17799-2, Aenor su UNE 71502 y otros países las suyas. Sin embargo, en 2005 se publica ISO 27001 que deja claro que debido a la importancia y las necesidades de normativa en esta materia, la norma internacional no podía esperar al 2008 que era para cuando se esperaba. Esto en España ha tenido como consecuencia los guisaguisados de los certificados UNE 71502 e ISO 27001 conviviendo un tiempo, hasta que se ha elaborado ya la UNE-ISO/IEC 27001:2007.
Finalmente (la historia ya está acabando), a mediados del 2006 me vuelvo a casa a trabajar en la consultora Firma, Proyectos y Formación S. L. dedicada en aquel momento a
"protección de datos" que con mi incorporación, abre el área de "seguridad de la
información". Y desde entonces hasta ahora, todos los proyectos han estado relacionados o bien con partes de un SGSI (sobre todo el análisis de riesgos, estudios diferenciales ISO 27002 o el desarrollo de marcos normativos de seguridad de la información) o bien con la construcción e implantación de SGSI, siendo actualmente la referencia más importante la lograda hace un par de años por la Consejería de Agricultura de la Región de Murcia, primera Administración Pública que logró una certificación acreditada bajo esquema UKAS.
Espero que este breve repaso a estos diez años de trayectoria profesional hayan servido para pintar unas breves trazas de cómo ha ido evolucionando esto de la "gestión de la seguridad de la información" hasta alcanzar ya su cuota de relevancia dentro de las organizaciones.
Solo espero y deseo que el ansia y la motivación que supone "certificarse bajo ISO 27001" no acabe prostituyendo a la propia seguridad de la información. Montar la documentación necesaria para establecer un sistema de gestión de lo que sea es fácil (Sólo son necesarios los procedimientos generales que establece todo SG) pero gestionar un SGSI requiere de conocimientos de seguridad de la información (si no sabes de aquello que quieres gestionar, dificilmente podrás controlarlo). En próximos días escribiré un post sobre "SGSI enfermos desde el diseño" que extracta unas primeras impresiones/conclusiones basadas en mis experiencias de estas últimas semanas auditando como auditor interno a varias empresas que han montado su propio SGSI. Mis impresiones no son buenas aunque aquí la principal responsabilidad la tienen las entidades de certificación respecto a su criterio para otorgar o no una certificación. Yo, como auditor/consultor percibo que las nuevas versiones de ISO 27001:2005 tienen que establecer de forma más contundente requisitos formales respecto a:
Criterios para que una metodología de análisis de riesgos sea correcta, fiable y completa.
Unos mínimos criterios sobre la gestión de la eficacia que hay que hacer para conocer qué y cuanto hay que medir.
Una nueva versión de la ISO 27002:2005 que incorpore nuevos objetivos de control y aglutine o agrupe controles dado que hay áreas que tienen relativamente pocos controles y otras que disponen de demasiados.
Por lo que estoy encontrándome al auditar, las cosas más comunes son:
Metodologías de análisis de riesgos que suponen lo mismo que sacar el dedo y decidir al azar los principales problemas de seguridad.
SGSI sin objetivos de seguridad o con unos indicadores que no sirven para nada para evaluar el cumplimiento de objetivos
Hacer el análisis de riesgos de forma exhaustiva y detallada pero no volverlo a mirar más ni siquiera para elaborar el plan de tratamiento de riesgos
Y estoy seguro que luego muchas empresas lucirán con esplendor su magnífico sello "ISO 27001". De todas formas, aquí creo que es tonto autoengañarse y que el tiempo podrá a todo el mundo en su sitio. Quien gestione bien la seguridad evitará o detectará incidentes y no tendrá problemas reales con impactos reales. Aquellos que tengan un SG-SGSI (un sistema de gestión para engañar al sistema de gestión de la seguridad de la información) tendrá unos indicadores preciosos, unos procedimentos cojonudos pero andarán todo el día apagando fuegos y perdiendo datos, cuando no siendo multados por incumplir la LOPD. En este segundo caso, el sello no servirá para nada, dado que los incidentes seguirán
produciéndose de igual manera y por tanto, no se beneficiarán de lo que supone una
verdadera "gestión de la seguridad de la información". No saldrán de la cultura apagafuegos que tradicionalmente venía utilizándose en esta materia y para la que el SGSI se supone que es el mejor antídoto.
Ya está en modo borrador la nueva ISO 27033 que es la revisión de la ISO/IEC 18028-1:2006 destinada a la seguridad de redes de comunicaciones. Y por lo que se anuncia en ISO27001security.com parece que va muy avanzado el proceso de revisión. ISO 27033 pretende ser un complemento exhaustivo para todos los aspectos relacionados con la
seguridad en redes que vienen definidos en ISO 27002. Por ahora ya se encuentran en proceso los siguientes documentos:
ISO/IEC 27033-1: Guidelines for network security (FCD)
ISO/IEC 27033-2: Guidelines for the design and implementation of network security (WD)
ISO/IEC 27033-3: Reference networking scenarios -- Risks, design techniques and control issues (WD)
ISO/IEC 27033-4: Securing communications between networks using security gateways -- Risks, design techniques and control issues (NP)
ISO/IEC 27033-5: Securing Virtual Private Networks -- Risks, design techniques and control issues (NP)
ISO/IEC 27033-6: IP convergence (NP)
A continuación voy a listar el conjunto de normas publicadas o en proceso de elaboración de la serie ISO 27000 a fecha 10 de diciembre de 2008. Estos resultados son fruto de una consulta a la Web de ISO.org en relación al área de trabajo del Subcomité 27 del JTC 1 - IT Security techniques.
El estado de las normas se codifica en base a unos acrónimos que ISO tiene identificados y que son:
1.PWI = Preliminary Work Item - initial feasibility and scoping activities
3.WD = Working Draft (1st WD, 2nd WD etc.) - development phase
4.CD = Committee Draft (1st CD, 2nd CD etc.)- quality control phase
5.FCD = Final Committee Draft - ready for final approval.
6.DIS = Draft International Standard - nearly there. Stage 40.
7.FDIS = Final Draft or Distribution International Standard - just about ready to publish. Stage 50.
8.IS = International Standard - published. Stage 60.
9. Under revisión. Stage 90.
Como podréis comprobar en la siguiente relación de normas, hay bastantes ya en el Stage 40 y 50 lo que indica que pronto pueden ver la luz. La situación actual del marco
internacional de normas ISO 27000 es: ISO/IEC FCD 27000.
Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary. Stage:40.99
ISO/IEC 27001:2005.
Information technology -- Security techniques -- Information security management systems -- Requirements. Stage:60.60
ISO/IEC 27002:2005
Information technology -- Security techniques -- Code of practice for information security management. Stage:90.92
ISO/IEC FCD 27003
Information technology -- Information security management system implementation guidance. Stage:40.20
ISO/IEC FCD 27004.2
Information technology Security techniques Information security management -- Measurement. Stage:40.20
ISO/IEC 27005:2008
Information technology -- Security techniques -- Information security risk management. Stage:60.60
ISO/IEC 27006:2007
Information technology -- Security techniques -- Requirements for bodies providing audit and certification of information security management systems. Stage:60.60
ISO/IEC WD 27007
Guidelines for Information security management systems auditing. Stage:20.60
ISO/IEC FDIS 27011
Information technology -- Information security management guidelines for telecommunications organizations based on ISO/IEC 27002. Stage:50.60
ISO/IEC NP 27012
Information technology - Security techniques -- ISM guidelines for e-government services. Stage:10.99
ISO/IEC NP 27032
Guidelines for cybersecurity. Stage:10.99
ISO/IEC NP 27033
Information technology -- IT Network security.Stage:10.99
ISO/IEC CD 27033-1
Information technology -- Security techniques -- IT network security -- Part 1: Guidelines for network security. Stage:30.60
ISO/IEC WD 27033-2
Information technology -- Security techniques -- IT network security -- Part 2: Guidelines for the design and implementation of network security. Stage:20.60
ISO/IEC WD 27033-3
Information technology -- Security techniques -- IT network security -- Part 3: Reference networking scenarios -- Risks, design techniques and control issues. Stage:20.60
ISO/IEC NP 27033-4
Information technology -- Security techniques -- IT network security -- Part 4: Securing communications between networks using security gateways - Risks, design techniques and control issues. Stage:10.99
ISO/IEC NP 27033-5
Information technology -- Security techniques -- IT network security -- Part 5: Securing Remote Access - Risks, design techniques and control issues. Stage:10.99
ISO/IEC NP 27033-6
Information technology -- Security techniques -- IT network security -- Part 6: Securing communications across networks using Virtual Private Networks (VPNs) -- Risks, design techniques and control issues. Stage:10.99
ISO/IEC NP 27033-7
Information technology -- Security techniques -- IT network security -- Part 7: Guidelines for securing (specific networking technology topic heading(s) to be inserted3) -- Risks, design techniques and control issues. Stage:10.99
ISO/IEC NP 27034
Guidelines for application security. Stage:10.99
ISO/IEC NP 27037
Information technology - Security techniques -- on Information security
management: Sector to sector interworking and communications for industry and government . Stage:10.99
El detalle de los diferentes escalones dentro de cada nivel o stage lo podéis consultar en Stages ISO.
Ya he comentado alguna vez que la serie 27000 va a servir como marco normativo para todo lo relacionado con la seguridad de la información.
Pues bien, hemos de recibir una nueva norma de este marco, "ISO 27799:2008 Health informatics -- Information security management in health using ISO/IEC 27002". He dado con ella gracias a ISO 27002.es
Tal como aparece en la Web de ISO, su resumen es:
ISO 27799:2008 defines guidelines to support the interpretation and implementation in health informatics of ISO/IEC 27002 and is a companion to that standard.
ISO 27799:2008 specifies a set of detailed controls for managing health information
security and provides health information security best practice guidelines. By implementing this International Standard, healthcare organizations and other custodians of health
information will be able to ensure a minimum requisite level of security that is appropriate to their organization's circumstances and that will maintain the confidentiality, integrity and availability of personal health information.
ISO 27799:2008 applies to health information in all its aspects; whatever form the information takes (words and numbers, sound recordings, drawings, video and medical images), whatever means are used to store it (printing or writing on paper or electronic storage) and whatever means are used to transmit it (by hand, via fax, over computer networks or by post), as the information must always be appropriately protected.
Su estructura es:
Alcance
Referencias (Normativas)
Terminología
Simbología
Seguridad de la información sanitaria
Objetivos; Seguridad en el gobierno de la información; Infomación sanitara a proteger; Amenazas y vulnerabilidades
Plan de acción práctico para implantar ISO 17799/27002
Taxonomía; Acuerdo de la dirección; establecimiento, operación, mantenimiento y mejora de un SGSI; Planning; Doing; Checking, Auditing
Implicaciones sanitarias de ISO 17799/27002
Política de seguridad de la información; Organización; gestión de activos; RRHH; Fisicos; Comunicaciones; Accesos; Adquisición; Gestión de Incidentes;
Continuidad de negocio; Cumplimiento legal
Annex A: Amenazas
Annex B: Tareas y documentación de un SGSI
Annex C: Beneficios potenciales y atributos de herramientas
Annex D: Estándares relacionados
La norma tiene stage 60.60 (Publicada) con fecha de 12 de Junio de 2008. Podéis adquirirla en ISO 27799:2008 - Health informatics -- Information security management in health using ISO/IEC 27002
Estos movimientos serán también continuos en años próximos dado que es intención de ISO extender la norma ISO 27002 con contenidos específicos en aquellos sectores que plantean una problemática especial.
Publicado por Javier Cao Avellaneda
Vía ISO27002.es he podido dar con la Web
Open Directory - Computers: Security: Policy: Sample Policies que contiene un buen catálogo de documentos sobre políticas de seguridad.
En Guía para la elaboración del marco normativo de Seguridad ISO 27002 ya comenté las diferencias entre Política, Norma y Procedimiento aunque en ingles el término "policy" suele tener un carácter más general. Es habitual encontrar "policies" para todo, aunque muchas veces estos documentos tienen el objetivo de establecer regulaciones y por tanto deberían entenderse como normas.
Aumenta esta confusión además que en la norma ISO 27002 aparezca como control en el punto 5.1.1. la famosa "política de seguridad de la información".
En cualquier caso, el catálogo de documentación contiene una buena recopilación de diferentes enfoques a la hora de establecer un marco normativo, lo que suele venir bien cuando se anda intentando escribir estas cosas.
Como reflexión final, todo documento que intenta ser una política, norma o procedimiento tiene que tener un objetivo base "Que pueda ser algo cumplible".No se trata por tanto de hacer algo que quede bien o que sea completo, sino algo que sea real, asumible y cumplido por el área regulada.
La subcontratación del riesgo
Publicado por Javier Cao AvellanedaTenía pendiente desde hace unos días elaborar esta entrada. Tras unos comentarios en relación al post de Joseba Enjuto sobre la caracterización de los Servicios TI, quería hablar sobre la " subcontratación del riesgo". Lo primero que quiero justificar es el titulo. La gestión del riesgo sólo permite cuatro decisiones posibles:
Aceptarlo Evitarlo Reducirlo o
Transferirlo a un tercero
En general, se suele entender por transferencia del riesgo cuando éste se tiene identificado y se decide que un externo sea quien lo gestione a cambio de cierta contraprestación:
habitualmente puede ser la externalización de servicios, la contratación de seguros, etc. Es habitual, como bien apuntaban en los comentarios de "Seguridad y Gestión" que el término para definir este proceso sea la "externalización del riesgo" pero ahora voy a justificar un poco por qué prefiero no llamarlo así. Yo concibo la idea de la externalización de un riesgo cuando una Organización identifica claramente qué necesita y establece una relación contractual de prestación de servicios que permite al cliente quedarse tranquilo respecto a cómo va a gestionar el tercero ese riesgo. Para ello, evidentemente, los servicios prestados
por el tercero deberían poder acreditar ciertas garantías respecto a la seguridad con la que van a ser proporcionados. La existencia de unos adecuados "Acuerdos de nivel de servicio" ( o su término en ingles Service Level Agreement, SLA) centrados exclusivamente bajo la perspectiva de la seguridad podrían ser suficiente garantía. La Organización que traslada el riesgo sabe que en caso de problemas, podrá arremeter contractualmente contra la empresa a la que transfiere el riesgo siendo recompensada adecuadamente en caso de una gestión no adecuada de ese riesgo. Para ello, aparece el control 6.2.3 de la norma ISO 27002 que indica que "Los acuerdos que comporten el acceso de terceros a recursos de
tratamiento de información de la Organización deben basarse en un contrato formal que tenga o se refiera a todos los requisitos de seguridad que cumplan las políticas y normas de seguridad de la Organización."
Si atendemos a la guía de implantación de la norma, que es la forma más completa de implantar el control, este tipo de ANS o SLA de seguridad deben cubrir cosas como:
1.-La política sobre seguridad de la información del tercero.
2.-Los controles para asegurar la protección de los activos que el tercero tiene implantado, incluyendo:
o procedimientos para proteger los activos de la organización, incluida la información, el software y el hardware.
o cualquier control o mecanismo de protección física requeridos. o controles para asegurar la protección contra el software malicioso
o procedimientos para determinar si ha ocurrido algún incremento del riesgo de los activos, por ejemplo, pérdida o modificación de información, software o hardware;
o controles para asegurar la recuperación o destrucción de la información y los activos, al terminar el contrato o en algún momento acordado dentro del periodo de vigencia del contrato;
o la confidencialidad, integridad, disponibilidad, y cualquier otra propiedad importante de los activos
o restricciones en la copia o revelación de la información; junto con la utilización de acuerdos de confidencialidad
3.- Una clara estructura de los informes y de los formatos de informe acordados. 4.- Un proceso especificado y claro de la gestión del cambio.
5.- Disposiciones para informe, notificación e investigación de los incidentes de seguridad de la información e infracciones de seguridad, así como violaciones de los requisitos establecidos en el acuerdo.
6.- Una descripción del producto o servicio que se va a proporcionar, y una descripción de la información que se hará accesible, con su clasificación de seguridad.
7.- El nivel objetivo de servicio y los niveles de servicio inaceptables.
8.- La definición de los criterios de verificación del comportamiento, su control e informe.
9.- El derecho a controlar, y revocar, cualquier actividad relacionada con los activos de la organización.
10.- El derecho de auditar las responsabilidades definidas en el acuerdo, teniéndose que llevar a cabo tales auditorías por una tercera parte, y de enumerar las
11.- El establecimiento de un procedimiento de escalado para la resolución de los problemas.
12.- Requisitos de continuidad de servicio, incluyendo las medidas de disponibilidad y fiabilidad, de acuerdo con las prioridades de negocio de la organización.
13.- Las responsabilidades respectivas de las partes del contrato.
14.- Las responsabilidades con respecto a temas legales y como se garantiza que se cumplen los requisitos legales, por ejemplo legislación de protección de datos, teniendo en cuenta sobre todo los distintos sistemas legales nacionales si el contrato implica la cooperación con organizaciones de otros países.
15.- Etc.
El primer problema con el que nos solemos encontrar en las Organizaciones es que se externalizan servicios pero no se definen, desde la perspectiva de la seguridad, en qué condiciones se transfiere el riesgo. Llegado a estas alturas del texto, cabe pensar si realmente conocéis a alguna empresa que "externalice su riesgo" o si en general todas "subcontratan servicios de riesgo" entendiendo por esto segundo, un término menos formalizado de dar a un tercero un riesgo. Quiero destacar que el riesgo SI se puede
transferir, pero no así la responsabilidad. Por tanto, que las cosas no estén bien definidas, explícitamente documentadas y contractualmente reflejadas solo hace que perdamos "control" sobre nuestro riesgo que además, no vamos a gestionar nosotros mismos.
Dependerá de cómo entienda e interprete ese tercero el riesgo que asume al prestar el servicio el tipo de garantías que pudiera proporcionarnos en caso de un incidente de seguridad. Y lo que me parece más preocupante es que la "externalización de servicios TI" está muy de moda y si bien tenemos normas como ISO 20000 o ITIL que definen bien cómo debe hacerse este proceso y cómo deben establecerse los SLA y ANS, es importante que los aspectos relacionados con la seguridad queden perfectamente definidos. Es cierto que para los servicios TI el factor más importante a considerar suele ser la disponibilidad, pero debemos contemplar qué ocurriría si la naturaleza del incidente o error afecta a la integridad o confidencialidad de nuestra información.
Toda externalización supone pérdida de control si no se establecen mecanismos de regulación y seguimiento que permitan aportar evidencias, por parte del externo, de estar haciendo las cosas bien. A esta problemática general, todavía cabría añadir la complejidad que surge cuando se manejan cadenas de subcontratación. Si la empresa A transfiere un servicio a la empresa B, que a su vez utiliza a las subcontratas C y D para proporcionar el servicio final al cliente A. Si estos eslabones de subcontratación no están claramente identificados y bien atados, la empresa A puede ver comprometida su seguridad y no tener muy claro cuál ha podido ser la cadena de fallos y por tanto, la cadena de
responsabilidades.
Y decía al principio que los acontecimientos siempre nos ponen de manifiesto estas reflexiones por el incidente este fin de semana en los hospitales madrileños. El titular de "El País" que se hace eco de la noticia es Siete hospitales se quedan seis horas sin sistema informático. Cuando hacemos el análisis de riesgos y estamos en la fase de valoración de activos, siempre usamos una escala denominada "laboral" donde precisamente se tiene en consideración si un incidente de seguridad puede costar "vidas humanas". Normalmente nuestros entrevistados suelen hacer alguna broma al respecto, pero es cierto que en ciertos
"modelos de negocio", los servicios TI son críticos pudiendo causar la muerte de personas. Además, el proceso de digitalización que tantos beneficios genera y que tan bien venden nuestros políticos en relación a la atención sanitaria, tiene requisitos de seguridad que requieren hacer las cosas bien desde el principio. Sin entrar a valorar en concreto estos hechos, dado que no tenemos información suficiente que pudiera servir para valorar técnicamente que ha fallado, las evidencias son un cese de servicios de seis horas, algo posiblemente "intolerable" para un sector sanitario donde mucha información se requiere "en tiempo real". Merece la pena destacar frases como "La caída del programa la provocó una bajada de tensión eléctrica en la zona de Tres Cantos, donde está el centro tecnológico que aloja el servidor central de los nuevos hospitales". ¿Un sólo servidor para un activo
de información tan crítico? ¿Ningún plan de contingencia para recuperarse frente a una situación así en menos de una hora? El blog APISCAM parece proporcionar más información sobre lo sucedido, aunque quizás con una versión menos imparcial
(seguramente muy justificada). Parece que toda la gestión informática hospitalaria está subcontratada y en los diferentes pliegos y concursos se habían contemplado requisitos respecto a la continuidad de servicio.
De los hechos se deduce, al menos, un fallo grave en el plan de continuidad de negocio o planes parciales de contingencia. En sistemas de información como los del entorno hospitalario, con cada vez más dependencia de la tecnología para obtener información relativa al diagnóstico, hablamos de sistemas críticos que requieren información en tiempo real ("Fue el servicio de urgencias el que más sufrió las consecuencias de las demoras. "Tenemos que ir corriendo de un lado para otro para llevar historias, análisis...", explicaba ayer una enfermera de este departamento del hospital de Vallecas").
Quizás en el pliego las condiciones del servicio pudieran estar bien contempladas, pero para nada se ha garantizado la correcta supervisión de la ejecución del mismo y el adecuado cumplimiento del ACUERDO DE NIVEL DE SERVICIO. Además se suma que el supuesto Plan de Contingencias o de Continuidad de Negocio no ha funcionado, dado que la parada de seis horas es excesivo tiempo en el entorno hospitalario si se hubiera hecho el correspondiente BIA (Bussines Impact Analysis). Y por último y como reflexión final, quisiera destacar que el nuevo Reglamento de desarrollo de la Ley 15/1999 de Protección de Datos, ha incluido importantes y significativas reformas en torno a la figura del
"encargado de tratamiento", que desde la perspectiva de la seguridad van en la línea de mejorar el control y la externalización del riesgo sobre los terceros.
Artículo 20. Relaciones entre el responsable y el encargado del tratamiento. 1. El
acceso a los datos por parte de un encargado del tratamiento que resulte necesario para la prestación de un servicio al responsable no se considerará comunicación de datos, siempre y cuando se cumpla lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre y en el presente capítulo. El servicio prestado por el encargado del tratamiento podrá tener o no carácter remunerado y ser temporal o indefinido. No obstante, se considerará que existe comunicación de datos cuando el acceso tenga por objeto el establecimiento de un nuevo vínculo entre quien accede a los datos y el afectado. 2. Cuando el responsable del
tratamiento contrate la prestación de un servicio que comporte un tratamiento de datos personales sometido a lo dispuesto en este capítulo deberá velar por que el encargado del tratamiento reuna las garantías para el cumplimiento de lo dispuesto en este
Reglamento. 3. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato al que se refiere el apartado 2 del artículo 12 de la Ley Orgánica 15/1999, de 13 de diciembre, será
