• Author / Uploaded
• Jeisson Silva

• Categories
• Continuidad del negocio
• Seguridad de información
• Planificación
• Gestión de recursos humanos
• Información

Citation preview

SEGURIDAD- ISO 27001 vs ISO 27002 Recopilación realizada por Ms. Ing. Jairo E. Márquez D. En este documento se hace un compendio general sobre la seguridad informática, enfocada en particular sobre las normas ISO 27001 e ISO 27002, en la que se explica su complementariedad a la hora de fijar las políticas de seguridad. Las diferentes caras de la seguridad1 La infraestructura de seguridad es una mescolanza dinámica de tecnologías, procedimientos y personas, todo sincronizado. La seguridad es esencial. Nadie discute. Podría tomar hasta el extremo lógico absoluto y ofrecer a sus clientes una palmadita, así como cuando el Departamento de Seguridad entra por la puerta de su empresa. Usted podría desconectar todos los equipos a través de su red de Internet para eliminar las amenazas de ser hackeado o contraer un virus o algún tipo de malware. También podría alistarse para quedarse sin su negocio, porque esto sería lo más factible. Para funcionar como una organización, debe estar abierto a sus clientes y abierto al mundo. Eso es lo que hace llegar a ese delicado equilibrio de la seguridad y la apertura un desafío tan profundo. Si se asegura demasiado puede bloquear el negocio, y dejar las puertas abiertas atraen al malware y cientos de problemas. Encontrar ese equilibrio y la mezcla de los elementos de seguridad correcta es un reto, y es por ello que se necesita de elementos relacionados con la tecnología como un firewall, software antivirus, gestión de identidades y controles de acceso. Hoy en día, la infraestructura de seguridad de la organización suele ser bastante compleja. No sólo se bloquean los sistemas de escritorio y portátiles, sino también cualquier dispositivo móvil conectado a la red. Después se traslada a la nube y todos los problemas de seguridad que esto conlleva. Mientras que mover los datos a la nube puede de hecho aumentar la postura de seguridad, trae numerosas cuestiones sobre el acceso a los datos, el control y la propiedad. Las tecnologías que componen la seguridad y que giran en torno a la organización son tan buenas como las personas que los operan. Así como se afina la infraestructura de seguridad, se debe asegurar que el personal de la empresa está completamente a tono con los procesos de seguridad. 1

Artículo tomado de Newsletter seguridad Latinoamérica. Microsoft. Edición de septiembre 2013.

Muchos elementos se combinan para hacer un negocio. Hay tecnología, procedimientos de seguridad y, lo más importante, la gente que mantiene el negocio funcionando sin problemas. Estos son los ingredientes esenciales para mantener la empresa abierta e interactiva, pero un elemento importante dentro de todo este engranaje, son el manejo de los datos confidenciales. Seguridad de información - ISO 270012 Los detalles que conforman el cuerpo de esta norma, se podrían agrupar en tres grandes líneas:  SGSI (Sistema de Gestión de la Seguridad de la Información)  ISMS (Information Security Managemet System)  Valoración de riegos (Risk Assesment) De esas tres grandes líneas, por ser una presentación de la norma, se continuó con las generalidades y se hizo bastante hincapié en el concepto de SGSI (o ISMS), por considerarse a este tema el que más necesitaba ser explicado inicialmente, pues es lo que verdaderamente hace del estándar un “Sistema completo de Gestión de la Seguridad”. Tal vez la conclusión más importante de este texto es que “Se puede prever, que la certificación ISO-27001, será casi una obligación de cualquier empresa que desee competir en el mercado en el corto plazo”.

Los primeros pasos para la implementación de esta norma son: - Definir el ámbito y política del SGSI. - Proceso de análisis y valoración de riesgos (Evaluación de Riesgos). - Selección, tratamiento e implementación de Controles.

2

Seguridad De Información ISO 27001. Consultado el 6 de septiembre de 2013. http://es.slideshare.net/skyburn/savedfiles?s_title=seguridad-de-informacin-iso-27001&user_login=1k2a3s

Sobre el tema de Análisis de Riesgo, no se desea profundizar, pues la norma deja abierto el camino a la aplicación de cualquier tipo de metodología, siempre y cuando la misma sea metódica y completa, es decir satisfaga todos los aspectos que se mencionan en ella. Existen varios tipos de metodologías, de las más empleadas sean MAGERIT y COBIT, aunque es posible la aplicación de procedimientos propietarios o particulares, si presenta rigurosidad en los pasos y resultados. Lo que es necesario recalcar aquí es que los controles serán seleccionados e implementados de acuerdo a los requerimientos identificados por la valoración del riesgo y los procesos de tratamiento del riesgo. Es decir, que de esta actividad surgirá la primera decisión acerca de los controles que se deberán abordar. La preparación y planificación de SGSI, desencadena en una serie de controles (o mediciones) a considerar y documentar, que son uno de los aspectos fundamentales del SGSI (junto con la Valoración de riesgo). Cada uno de ellos se encuentra en estrecha relación a todo lo que especifica la norma ISO/IEC

17799:2005 en los puntos 5 al 15, y tal vez estos sean el máximo detalle de afinidad entre ambos estándares. La evaluación de cada uno de ellos debe quedar claramente documentada, y muy especialmente la de los controles que se consideren excluidos de la misma. “Desconcepto”: Al escuchar la palabra “Control”, automáticamente viene a la mente la idea de alarma, hito, evento, medición, monitorización, etc.; se piensa en algo muy técnico o acción. En el caso de este estándar, el concepto de “Control”, es mucho más que eso, pues abarca todo el conjunto de acciones, documentos, medidas a adoptar, procedimientos, medidas técnicas, etc.

Un “control” es lo que permite garantizar que cada aspecto, que se valoró con un cierto riesgo, queda cubierto y auditable ¿Cómo?

De muchas formas posibles

El estándar especifica en su “Anexo A” el listado completo de cada uno de ellos, en la que define el objetivo y lo describe brevemente. Cabe aclarar que el anexo A proporciona una buena base de referencia, no siendo exhaustivo, por lo tanto se pueden seleccionar más aún. Es decir, estos 133 controles (hoy) son los mínimos que se deberán aplicar, o justificar su no aplicación, pero esto no da por completa la aplicación de la norma si dentro del proceso de análisis de riesgos aparecen aspectos que quedan sin cubrir por algún tipo de control. Por lo tanto, si a través de la evaluación de riesgos se determina que es necesaria la creación de nuevos controles, la implantación del SGSI impondrá la inclusión de los mismos, sino seguramente el ciclo no estará cerrado y presentará huecos claramente identificables. Los controles que el anexo A de esta norma propone quedan agrupados y numerados de la siguiente forma: A.5 Política de seguridad. A.6 Organización de la información de seguridad. A.7 Administración de recursos. A.8 Seguridad de los recursos humanos. A.9 Seguridad física y del entorno. A.10 Administración de las comunicaciones y operaciones. A.11 Control de accesos. A.12 Adquisición de sistemas de información, desarrollo y mantenimiento. A.13 Administración de los incidentes de seguridad. A.14 Administración de la continuidad de negocio. A.15 Cumplimiento (legales, de estándares, técnicas y auditorías).

1. Desarrollo de los controles: En este ítem, se respeta la puntuación que la norma le asigna a cada uno de los controles. A.5 Política de seguridad: Este grupo está constituido por dos controles y es justamente el primer caso que se puede poner de manifiesto sobre el mencionado “Desconcepto” sobre lo que se piensa que es un control, pues aquí se puede apreciar claramente la complejidad que representa el diseño, planificación, preparación, implementación y revisiones de una Política de Seguridad (la revisión es justamente el segundo control que propone). La Política de Seguridad, en esencia se pude dividir en dos documentos:  Política de seguridad (Nivel político o estratégico de la organización): Es la mayor línea rectora, la alta dirección. Define las grandes líneas a seguir y el nivel de compromiso de la dirección con ellas.  Plan de Seguridad (Nivel de planeamiento o táctico): Define el “Cómo”. Es decir, baja a un nivel más de detalle, para dar inicio al conjunto de acciones o líneas rectoras que se deberán cumplir. Algo sobre lo que generalmente no se suele reflexionar o remarcar es que: Una “Política de Seguridad” bien planteada, diseñada, y desarrollada cubre la gran mayoría de los aspectos que hacen falta para un verdadero SGSI.

Se trata de lo que proponen las siguientes RFCs (Request For Comments). Política de seguridad (RFC – 2196 Site Security Handbook) y también la anterior (RFC-1244, que si bien queda obsoleta por la primera es muy ilustrativa) ambas, planten una metodología muy eficiente de feedback partiendo desde el plano más alto de la Organización hasta llegar al nivel de detalle, para comparar nuevamente las decisiones tomadas y reingresar las conclusiones al sistema evaluando los resultados y modificando las deficiencias. Se trata de un ciclo permanente y sin fin cuya característica fundamental es la constancia y la actualización de conocimientos. Esta recomendación plantea los siguientes pasos:

Política de Seguridad (RFC 1244)

Análisis de riesgo

Grado de exposición

Plan de seguridad (semejante a Certificación ISO)

Plan de contingencia La política es el marco estratégico de la Organización, es el más alto nivel. El análisis de riesgo y el grado de exposición determinan el impacto que puede producir los distintos niveles de clasificación de la información que se posee. Una vez determinado estos conceptos, se pasa al Cómo que es el Plan de Seguridad, el cual, si bien en esta RFC no está directamente relacionado con las normas ISO, se mencionan en este texto por la similitud en la elaboración de procedimientos para cada actividad que se implementa, y porque se reitera, su metodología como tal.

A.6 Organización de la información de seguridad: Este segundo grupo de controles abarca once de ellos y se subdivide en:  Organización Interna: Compromiso de la Dirección, coordinaciones, responsabilidades, autorizaciones, acuerdos de confidencialidad, contactos con autoridades y grupos de interés en temas de seguridad, revisiones independientes.  Partes externas: Riesgos relacionados con terceros, gobierno de la seguridad respecto a clientes y socios de negocio. Lo más importante a destacar de este grupo son dos cosas fundamentales que abarcan a ambos subgrupos: - Organizar y Mantener actualizada la cadena de contactos (internos y externos), con el mayor detalle posible (Personas, responsabilidades, activos, necesidades, acuerdos, riesgos, etc.). - Derechos y obligaciones de cualquiera de los involucrados.

En este grupo de controles, lo ideal es diseñar e implementar una base de datos, que permita, la alta, baja y/o modificación de cualquiera de estos campos. La redacción de la documentación inicial de responsables: derechos y obligaciones (para personal interno y ajeno) y el conjunto de medidas a adoptar con cada uno de ellos. Una vez lanzado este punto de partida, se debe documentar la metodología de actualización, auditoria y periodicidad de informes de la misma.

A.7 Administración de recursos: Este grupo cubre cinco controles y también se encuentra subdividido en:  Responsabilidad en los recursos: Inventario y propietario de los recursos, empleo aceptable de los mismos.  Clasificación de la información: Guías de clasificación y Denominación, identificación y tratamiento de la información. Este grupo es eminentemente procedimental y no aporta nada al aspecto ya conocido en seguridad de la información, en cuanto a que todo recurso debe estar perfectamente inventariado con el máximo detalle posible, que se debe documentar el “uso adecuado de los recursos” y que toda la información deberá ser tratada de acuerdo a su nivel. También se puede encontrar en Internet varias referencias a la clasificación de la información por niveles. Vale mencionar el problema que se suele encontrar en la gran mayoría de las empresas que cuentan con un parque informático considerable, sobre el cual, se les dificulta mucho el poder mantener actualizado su sistema de inventario. El primer comentario, es que este aspecto debe abordarse “sí o sí”, pues es imposible pensar en seguridad, si no se sabe fehacientemente lo que se posee y cada elemento que queda desactualizado o no se lo ha inventariado aún, es un hueco concreto en la seguridad de todo el sistema, y de hecho suelen ser las mayores y más frecuentes puertas de entrada, pues están al margen de la infraestructura de seguridad. El segundo comentario, es que se aprecia que las mejores metodologías a seguir para esta actividad, son las que permiten mantener “vivo” el estado de la red y por medio de ellas inventariar lo que se “escucha”. Esta metodología lo que propone es, hacer un empleo lógico y completo de los elementos de red o seguridad (IDSs, Firewalls, Routers, sniffers, etc.) y aprovechar su actividad cotidiana de escucha y tratamiento de tramas para mantener “vivo” el estado de la red. Es decir, nadie mejor que ellos saben qué direcciones de la “Home Net” se encuentran activas y cuáles no, por lo tanto, aprovechar esta funcionalidad para almacenar y enviar estos datos a un repositorio adecuado, el cual será el responsable de mantener el inventario correspondiente.

A.8 Seguridad de los recursos humanos: Este grupo cubre nueve controles y también se encuentra subdividido en:  Antes del empleo: Responsabilidades y roles, verificaciones curriculares, términos y condiciones de empleo.  Durante el empleo: Administración de responsabilidades, preparación, educación y entrenamiento en seguridad de la información, medidas disciplinarias.  Finalización o cambio de empleo: Finalización de responsabilidades, devolución de recursos, revocación de derechos. Con base en lo anterior, se debe partir por la redacción de la documentación necesaria para la contratación de personal y la revocación de sus contratos (por solicitud, cambio o despido). En la misma deberán quedar bien claras las acciones a seguir para los diferentes perfiles de la organización, basados en la responsabilidad de manejo de información que tenga ese puesto. Como se pueda apreciar, tanto la contratación como el cese de un puesto, es una actividad conjunta de estas dos áreas, y cada paso deberá ser coordinado, según la documentación confeccionada, para que no se pueda pasar por alto ningún detalle, pues son justamente estas pequeñas omisiones de las que luego resulta el haber quedado con alta dependencia técnica de personas cuyo perfil es peligroso, o que al tiempo de haberse ido, mantiene accesos o permisos que no se debieran (casos muy comunes). Tanto el inicio como el cese de cualquier tipo de actividad relacionada con personal responsable de manejo de información de la organización, son actividades muy fáciles de registrar, pues no dejan de ser un conjunto de acciones secuenciales muy conocidas que se deben seguir “a raja tabla” y que paso a paso deben ser realizadas y controladas. Se trata simplemente de ¡ESCRIBIRLO! (y por supuesto de cumplirlo), esto forma parte de las pequeñas cosas que cuestan poco y valen mucho ¿Por qué será que no se hacen? En cuanto a formación, para dar cumplimiento al estándar, no solo es necesario dar cursos. Hace falta contar con un “Plan de formación”. La formación en seguridad de la información, no puede ser una actividad aperiódica y determinada por el deseo o el dinero en un momento dado, tiene que ser tratada como cualquier otra actividad de la organización, es decir se debe plantear: -

Meta a la que se desea llegar. Determinación de los diferentes perfiles de conocimiento. Forma de acceder al conocimiento. Objetivos de la formación.

-

Metodología a seguir. Planificación y asignación de recursos. Confección del plan de formación. Implementación del plan. Medición de resultados. Mejoras.

Si se siguen estos pasos, se llegará a la meta, pero no solo a través de la impartición de uno o varios cursos o la distribución de documentos de obligada lectura, sino con un conjunto de acciones que hará que se complementen e integren en todo el SGSI como una parte más, generando concienciación y adhesión con el mismo.

A.9 Seguridad física y del entorno: Este grupo cubre trece controles y también se encuentra subdividido en:  Áreas de seguridad: Seguridad física y perimetral, control físico de entradas, seguridad de locales edificios y recursos, protección contra amenazas externas y del entorno, el trabajo en áreas de seguridad, accesos públicos, áreas de entrega y carga.  Seguridad de elementos: Ubicación y protección de equipos, elementos de soporte a los equipos, seguridad en el cableado, mantenimiento de equipos, seguridad en el equipamiento fuera de la organización, seguridad en la redistribución o reutilización de equipamiento, borrado de información y/o software. Uno de los mejores resultados que se pueden obtener en la organización de una infraestructura de seguridad de la información, está en plantearla siempre por niveles. Tal vez no sea necesario hacerlo con el detalle de los siete niveles del modelo ISO/OSI, pero sí por lo menos de acuerdo al modelo TCP/IP que algunos consideran de cuatro (Integrando físico y enlace) y otros de cinco niveles. Se debe considerar separadamente el nivel físico con el de enlace, pues presentan vulnerabilidades muy diferentes. Si se presenta entonces el modelo de cinco niveles, se puede organizar una estructura de seguridad contemplando medidas y acciones por cada uno de ellos, dentro de las cuales se puede plantear, por ejemplo, lo siguiente:  Aplicación: Todo tipo de aplicaciones.  Transporte: Control de puertos UDP y TCP.

 Red: Medidas a nivel protocolo IP (Internet Protocol) ICMP (Internet Control Message Protocol), túneles de nivel 3.

e

 Enlace: Medidas de segmentación a nivel direccionamiento MAC, tablas estáticas y fijas en switchs, control de ataques ARP, control de broadcast 3 y multicast4 a nivel enlace, en el caso WiFi: verificación y control de enlace y puntos de acceso, 802.X (Varios), empleo de túneles de nivel 2, etc.  Físico: Instalaciones, locales, seguridad perimetral, CPDs5, gabinetes de comunicaciones, control de acceso físico, conductos de comunicaciones, cables, fibras ópticas, radio enlaces, centrales telefónicas (Tema a desarrollar en este punto). Para el caso físico, es conveniente también separar todas ellas, por lo menos en los siguientes documentos: - Documentación de control de accesos y seguridad perimetral general, áreas de acceso y entrega de materiales y documentación, zonas públicas, internas y restringidas, responsabilidades y obligaciones del personal de seguridad física. - Documentación de CPDs: Parámetros de diseño estándar de un CPD, medidas de protección y alarmas contra incendios/humo, caídas de tensión, inundaciones, control de climatización (Refrigeración y ventilación), sistemas vigilancia y control de accesos, limpieza, etc. - Documentación y planos de instalaciones, canales de comunicaciones, cableado, enlaces de radio, ópticos u otros, antenas, certificación de los mismos, etc. - Empleo correcto del material informático y de comunicaciones a nivel físico: Se debe desarrollar aquí cuales son las medidas de seguridad física que se debe tener en cuenta sobre los mismos (Ubicación, acceso al mismo, tensión eléctrica, conexiones físicas y hardware permitido y prohibido, manipulación de elementos, etc.). No se incluye aquí lo referido a seguridad lógica.

3

Broadcast, difusión en español, es una forma de transmisión de información donde un nodo emisor envía información a una multitud de nodos receptores de manera simultánea, sin necesidad de reproducir la misma transmisión nodo por nodo. 4

Es el envío de la información en múltiples redes a múltiples destinos simultáneamente. Antes del envío de la información, deben establecerse una serie de parámetros. Para poder recibirla, es necesario establecer lo que se denomina "grupo multicast". Ese grupo multicast tiene asociado una dirección de internet. 5

Se denomina centro de procesamiento de datos (CPD) a aquella ubicación donde se concentran los recursos necesarios para el procesamiento de la información de una organización. Dichos recursos consisten esencialmente en unas dependencias debidamente acondicionadas, computadoras y redes de comunicaciones.

- Seguridad física en el almacenamiento y transporte de material informático y de comunicaciones: Zonas y medidas de almacenamiento, metodología a seguir para el ingreso y egreso de este material, consideraciones particulares para el transporte del mismo (dentro y fuera de la organización), personal autorizado a recibir, entregar o recuperación de información que es motivo de otro tipo de procedimientos y normativa. - Documentación de baja, redistribución o recalificación de elementos: Procedimientos y conjunto de medidas a seguir ante cualquier cambio en el estado de un elemento de Hardware (Reubicación, cambio de rol, venta, alquiler, baja, destrucción, compartición con terceros, incorporación de nuevos módulos, etc.). 2. Conclusiones  Como se aprecia, el concepto de “Control”, no es el convencional que se puede tener al respecto. Se lo debe considerar como un conjunto de medidas, acciones y/o documentos que permiten cubrir y auditar cierto riesgo.  Una “Política de Seguridad” bien planteada, diseñada, y desarrollada cubre la gran mayoría de los aspectos que hacen falta para un verdadero SGSI. Es recomendable subdividirla en un Plan y en una Política de seguridad.  Organizar: Responsables, obligaciones, derechos, acuerdos, etc. (Base de datos y documentación que la sustente).  Recursos: Responsables de los mismos y clasificación de la información que contienen. LOPD, LSSI. Inventario “VIVO” (Consejo: aprovechar al máximo los elementos de Red y Seguridad, para eso están).  Recursos humanos: Coordinar y sincronizar el trabajo de ambas gerencias (RRHH y Seguridad). Tres momentos fundamentales: Inicio – durante (Plan de formación) y Cese.  Documentar y procedimentar los pasos que “tácitamente” se siguen. Seguridad física: Mentalidad de “Niveles TCP/IP” para dividir bien las tareas.

ISO 27001 vs ISO 27002 'By' Dejan Kosutic el 13 de septiembre 2010 Si viaja a través de la ISO 27001 y la ISO 27002, se habrá dado cuenta que la ISO 27002 es mucho más detallada y precisa ¿cuál es la finalidad de la norma ISO 27001, entonces? En primer lugar, no se puede obtener la certificación según la norma ISO 27002, ya que no es una norma de gestión. ¿Qué significa una norma de gestión? Significa que tal norma define cómo ejecutar un sistema, y en caso de ISO 27001, define el sistema de gestión de seguridad de la información (SGSI) por lo tanto, la certificación según la norma ISO 27001 es posible.

Este sistema de gestión significa que la seguridad de la información debe ser planificada, ejecutada, supervisada, revisada y mejorada. Esto significa que la gestión tiene sus responsabilidades distintas, que los objetivos deben ser

establecidos, medidos y revisados, que las auditorías internas se deben realizar y así sucesivamente. Todos esos elementos se definen en la norma ISO 27001, pero no en la norma ISO 27002. Los controles de la norma ISO 27002 se llaman igual en el Anexo A de la norma ISO 27001 - por ejemplo, en el control 6.1.6 ISO 27002 es el nombre de contacto con las autoridades, mientras que en la ISO 27001 es A.6.1.6 contacto con las autoridades. Sin embargo, la diferencia está en el nivel de detalle - en promedio, ISO 27002 explica un control en una página entera, mientras que la ISO 27001 dedica sólo una frase para cada control. Por último, la diferencia es que la ISO 27002 no hace una distinción entre los controles aplicables a una organización en particular, y los que no lo son. Por otro lado, la norma ISO 27001 prescribe una evaluación del riesgo para ser realizado con el fin de identificar, para cada control si se requiere para disminuir los riesgos, y si lo es, en qué medida se debe aplicar. La pregunta es: ¿por qué es que existen esas dos normas por separado, por qué no se les ha unido, que reúne a los aspectos positivos de ambas normas? La respuesta es la usabilidad - si fuera una sola norma, sería demasiado complejo y demasiado grande para el uso práctico. Cada norma de la serie ISO 27000 está diseñada con un cierto enfoque - si se quiere construir los cimientos de la seguridad de la información en una organización, y diseñar su marco, se debe utilizar la norma ISO 27001, si desea implementar controles, debería usar ISO 27002, si se desea llevar a cabo la evaluación de riesgos y el tratamiento del riesgo, se debe utilizar la norma ISO 27005, etc. Para concluir, se puede decir que sin los datos facilitados en la norma ISO 27002, los controles definidos en el Anexo A de la norma ISO 27001 no podrían aplicarse, sin embargo, sin el marco de gestión de la norma ISO 27001, ISO 27002 se quedaría sólo un esfuerzo aislado de algunas informaciones entusiastas de la seguridad, sin la aceptación de la alta dirección y, por tanto, sin impacto real en la organización.

Cómo obtener la certificación según la norma ISO 27001? 'By' Dejan Kosutic el 15 de febrero 2010 Si se aplica a la ISO 27001 desde hace mucho tiempo y ha invertido mucho en la educación, consultoría e implementación de los diversos controles. Ahora viene el auditor de una entidad de certificación - ¿va a pasar la certificación? Este tipo de ansiedad es normal - nunca se puede saber si el SGSI (sistema de gestión de la seguridad de información) tiene todo lo que el organismo de

certificación está pidiendo. Pero, ¿qué es exactamente lo que el auditor estará buscando?

En primer lugar, el auditor llevará a cabo la auditoría de nivel 1, también llamada la "revisión de documentos" - en esta auditoría, el auditor buscará el alcance documentado, la política del SGSI y los objetivos, descripción de la metodología de evaluación de riesgos, el Informe de Evaluación de Riesgos, el Estado de Aplicabilidad, plan de tratamiento de riesgos, los procedimientos de control de

documentos, acciones correctivas y preventivas, y de la auditoría interna. Usted también tendrá que documentar algunos de los controles del Anexo A (sólo si ha hallado aplicable en la Declaración de aplicabilidad) - inventario de activos (A.7.1.1), uso aceptable de los activos (A.7.1.3), funciones y responsabilidades de los empleados, contratistas y usuarios de terceras partes (A.8.1.1), términos y condiciones de empleo (A.8.1.3), los procedimientos para la operación de las instalaciones de procesamiento de información (A.10.1.1), control de acceso política (A.11.1.1), y la identificación de la legislación aplicable (A.15.1.1). Además, necesitará registros de por lo menos una auditoría interna y revisión por la dirección. Si alguno de estos elementos falta, esto significa que usted no está listo para la etapa 2 de la auditoría. Por supuesto, usted podría tener muchos más documentos si lo considera necesario - la lista de arriba es el requisito mínimo. Etapa 2 de la auditoría también se llama la "auditoría principal", y por lo general sigue un par de semanas después de la etapa 1 de la auditoría. En esta fiscalización, el foco no estará en la documentación, pero si la organización, la cual estará gestionando los recursos y procesos conforme a la ISO 27001. En otras palabras, el auditor comprobará si la SGSI realmente se ha materializado en la organización, o es sólo letra muerta. El auditor comprobará esto a través de la observación, entrevistas a sus empleados, pero sobre todo por el control de sus registros. Los registros obligatorios son la educación, la formación, las habilidades, la experiencia y las calificaciones (5.2.2), la auditoría interna (6), la gestión de revisión (7.1), correctiva (8.2) y las acciones preventivas (8.3), sin embargo, el auditor espera ver muchos más registros como resultado de la realización de los procedimientos. Se debe tener cuidado en este punto - cualquier auditor experimentado se dará cuenta de inmediato si alguna parte del SGSI es artificial, y se están haciendo con el fin único de auditoría. Bien, sabiendo todo esto, pero aún pasó - el auditor encontró incumplimiento grave y le dijo que no se emite el certificado ISO 27001. ¿Es este el fin del mundo? Por supuesto que no. El proceso es el siguiente - el auditor hará constar los resultados (incluyendo el incumplimiento grave) en el informe de auditoría, y le dará la fecha límite hasta la cual se debe resolver la no conformidad (generalmente 90 días). Su trabajo es tomar las medidas correctivas apropiadas, pero hay que tener cuidado - esta acción debe resolver la causa de la no conformidad, si el auditor no puede aceptar lo que ha hecho. Una vez que esté seguro de que se tome la acción correcta, se tiene que notificar al auditor y enviar la evidencia de lo que se ha hecho. En la mayoría de los casos, si se ha hecho el trabajo a fondo, el auditor aceptará su acción correctiva y procederá a la emisión del certificado.

Con lo anteriormente expuesto, siguiendo los lineamientos establecidos, la empresa será certificada ISO / IEC 27001. (Tenga cuidado sin embargo - el certificado tiene una validez de sólo tres años, y puede ser suspendido durante ese período, si el organismo de certificación identifica otro incumplimiento grave de las visitas de vigilancia.)

ISO 27001 checklist aplicación 'By' Dejan Kosutic el 28 de septiembre 2010 Si usted está comenzando a implementar la norma ISO 27001 (Ver anexo 1), es probable que esté buscando una manera fácil de certificarse, para ello se debe seguir los siguientes pasos: 1. Obtener apoyo a la gestión Éste puede parecer bastante obvio, y generalmente no se toma suficientemente en serio, y es por estas la razón por la que los proyectos de la ISO 27001 no son avalados. (Lea Cuatro beneficios clave de la implantación de la ISO 27001 (ver anexo 2) para obtener ideas de cómo presentar el caso a la dirección.) 2. Tratarlo como un proyecto

La implementación ISO 27001 es un tema complejo que involucra diversas actividades, mucha gente, que dura varios meses (o más de un año). Si no se define claramente lo que hay que hacer, quién lo va a hacer y en qué marco (es decir, se aplica la gestión de proyectos) el tiempo, puede ser que también no termine el trabajo nunca. 3. Definir el alcance Si es una organización más grande, probablemente tenga sentido implementar la norma ISO 27001 solamente en una parte de ella, lo que disminuye significativamente el riesgo del proyecto. (Problemas con la definición del alcance de la norma ISO 27001). Ver anexo 3. 4. Escribir una Política de SGSI La Política de SGSI es el documento de más alto nivel - no debe ser muy detallada, pero debe definir algunos temas básicos para la seguridad de la información en la organización. Pero ¿cuál es su objetivo si no se detalla? El propósito es que la dirección debe definir lo que quiere lograr y cómo controlarlo. (Información de la política de seguridad - el grado de detalle que debería ser). Ver anexo 4. 5. Definir la metodología de evaluación de riesgos La evaluación de riesgos es la tarea más compleja en el proyecto ISO 27001 - el punto es definir las normas para la identificación de los activos, vulnerabilidades, amenazas, impactos y probabilidades, y para definir el nivel de riesgo aceptable. Si las reglas no están claramente definidas, puede que se encuentre en una situación en la que se obtienen resultados que no sirvan de mucho. (Consejos de evaluación de riesgos para las empresas más pequeñas). Ver anexo 5. 6. Realizar la evaluación del riesgo y el tratamiento del riesgo Aquí se tiene que poner en práctica lo que ha definido en el paso anterior - que podría tomar varios meses para organizaciones más grandes, por lo que debe coordinar este esfuerzo con mucho cuidado. El objetivo es obtener un panorama completo de los peligros para la información de la organización. El propósito del proceso de tratamiento de riesgos es reducir los riesgos que no son aceptables - esto se suele hacer mediante la planificación de usar los controles del anexo A. En esta etapa, un informe de evaluación de riesgos tiene que ser por escrito, que documenta todas las medidas tomadas durante la evaluación de riesgos y el proceso de tratamiento del mismo. También se debe obtener la aprobación de los

riesgos residuales - ya sea como un documento separado, o como parte de la Declaración de aplicabilidad. 7. Escriba la Declaración de aplicabilidad Una vez que termine el proceso de tratamiento de riesgos, sabrá exactamente qué controles del Anexo necesita (hay un total de 133 controles, pero es probable que no necesitarían todos ellos). El propósito de este documento (denominado con frecuencia como SOA= Arquitectura Orientada a Servicios) es enumerar todos los controles y definir cuáles son aplicables y cuáles no, y las razones de tal decisión, los objetivos a alcanzar con los controles y una descripción de la forma en que se aplican. La declaración de aplicabilidad también es el documento más adecuado para obtener autorización de la dirección para la implementación de SGSI.

Ejemplo del problema de ausencia de un SGSI en una organización. 6 8. Escriba el Plan de Tratamiento de Riesgos Consiste en definir exactamente cómo se llevarán a cabo los controles de SOA, que va a hacer, cuándo, con qué presupuesto, etc. Este documento es en realidad un plan de aplicación se centró en los controles, sin la cual no sería capaz de coordinar nuevas medidas en el proyecto. 6

NA

9. Definir la forma de medir la efectividad de los controles Otra tarea que se suele subestimar. El punto aquí es - si no se puede medir lo que se ha hecho, ¿cómo puede estar seguro de que han cumplido el propósito? Por lo tanto, se debe asegurar definir cómo se va a medir el cumplimiento de los objetivos que ha establecido tanto para todo el SGSI, y para cada control aplicable en la Declaración de aplicabilidad. 10. Implementar los controles y procedimientos obligatorios Más fácil decirlo que hacerlo. Aquí es donde se tiene que poner en práctica los cuatro procedimientos obligatorios (Ver anexo 6) y los controles aplicables del Anexo A. Esta suele ser la tarea más arriesgada del proyecto, que por lo general significa la aplicación de las nuevas tecnologías, y sobre todo la aplicación de nuevos comportamientos dentro de la organización. A menudo, se necesitan nuevas políticas y procedimientos (lo que significa que el cambio es necesario), y la gente por lo general se resiste al cambio, es por eso que la siguiente tarea (capacitación y concienciación) es crucial para evitar ese riesgo. 11. Implementar programas de capacitación y sensibilización Si quiere que el personal ponga en práctica las nuevas políticas y procedimientos, primero tiene que explicarles por qué son necesarias, y entrenarlos para que sean paces de funcionar como se espera. La ausencia de estas actividades es la segunda razón más común para el fracaso del proyecto ISO 27001. 12. Operar el SGSI Esta es la parte donde la ISO 27001 se convierte en una rutina diaria de la organización. La palabra clave aquí es: "registros". Sin registros resultará muy difícil probar que una actividad realmente se ha hecho. Los registros ayudan a controlar lo que está sucediendo en la empresa, en realidad se sabe con certeza si los empleados (y proveedores) están realizando sus tareas según lo necesario. 13. Supervisar el SGSI ¿Qué está sucediendo en el SGSI? ¿Cuántos incidentes tiene, de qué tipo? ¿Son todos los procedimientos llevados a cabo correctamente? Aquí es donde los objetivos de los controles y la metodología de medición vienen juntos – se tiene que comprobar si los resultados que se obtengan, cumplen con lo establecido en los objetivos. Si no es así, se sabe que algo está mal - hay que realizar acciones correctivas y/o preventivas.

14. Auditoría interna Muy a menudo las personas no son conscientes que están haciendo algo mal (pero no quieren que nadie se entere de ello). Se debe ser consciente de los problemas existentes o potenciales que pueden dañar la organización, por lo cual se tiene que llevar a cabo la auditoría interna con el fin de averiguar cómo van las cosas. El punto aquí no es la de iniciar acciones disciplinarias, sino más bien tomar acciones correctivas y/o preventivas. (Dilemas con ISO 27001 y BS 25999-2 auditores internos). Ver anexo 6. 15. Revisión de gestión La administración no tiene que configurar el firewall, pero debe saber lo que está sucediendo en el SGSI, es decir, si todo el mundo lleva a cabo sus deberes, si el SGSI está logrando los resultados deseados, etc. Basándose en esto, la gerencia debe tomar algunas decisiones cruciales. 16. Las acciones correctivas y preventivas El objetivo del sistema de gestión es asegurar que todo lo que está mal (los llamados "no conformidades") sea corregido. Por lo tanto, la norma ISO 27001 requiere que las acciones correctivas y preventivas se lleven a cabo de forma sistemática, lo que significa que la causa de una inconformidad se debe identificar, luego resolver y verificar. Existen diagramas del proceso de implementación de la norma ISO 27001 que muestra todos estos pasos junto con la documentación requerida.

Anexo 1 Gestión de la seguridad de la información La norma ISO 27001 define cómo organizar la seguridad de la información en cualquier tipo de organización, con o sin fines de lucro, privada o pública, pequeña o grande. Es posible afirmar que esta norma constituye la base para la gestión de la seguridad de la información. La ISO 27001 es para la seguridad de la información lo mismo que la ISO 9001 es para la calidad: es una norma redactada por los mejores especialistas del mundo en el campo de seguridad de la información y su objetivo es proporcionar una metodología para la implementación de la seguridad de la información en una organización. También permite que una organización sea certificada, lo cual significa que una entidad de certificación independiente ha confirmado que la seguridad de la información se ha implementado en esa organización de la mejor forma posible. A raíz de la importancia de la norma ISO 27001, muchas legislaturas han tomado esta norma como base para confeccionar las diferentes normativas en el campo de la protección de datos personales, protección de información confidencial, protección de sistemas de información, gestión de riesgos operativos en instituciones financieras, etc. Cuatro fases del sistema de gestión de seguridad de la información La norma ISO 27001 determina cómo gestionar la seguridad de la información a través de un sistema de gestión de seguridad de la información. Un sistema de gestión de este tipo, igual que las normas ISO 9001 o ISO 14001, está formado por cuatro fases que se deben implementar en forma constante para reducir al mínimo los riesgos sobre confidencialidad, integridad y disponibilidad de la información. Las fases son las siguientes: 

 



La Fase de planificación: esta fase sirve para planificar la organización básica y establecer los objetivos de la seguridad de la información y para escoger los controles adecuados de seguridad (la norma contiene un catálogo de 133 posibles controles). La Fase de implementación: esta fase implica la realización de todo lo planificado en la fase anterior. La Fase de revisión: el objetivo de esta fase es monitorear el funcionamiento del SGSI mediante diversos “canales” y verificar si los resultados cumplen los objetivos establecidos. La Fase de mantenimiento y mejora: el objetivo de esta fase es mejorar todos los incumplimientos detectados en la fase anterior.

El ciclo de estas cuatro fases nunca termina, todas las actividades deben ser implementadas cíclicamente para mantener la eficacia del SGSI. Documentos de ISO 27001 La norma ISO 27001 requiere los siguientes documentos:         

Alcance del SGSI; Política del SGSI; Procedimientos para control de documentación, auditorías procedimientos para medidas correctivas y preventivas; Todos los demás documentos, según los controles aplicables; Metodología de evaluación de riesgos; Informe de evaluación de riesgos; Declaración de aplicabilidad; Plan de tratamiento del riesgo; Registros.

internas

y

La cantidad y exactitud de la documentación depende del tamaño y de las exigencias de seguridad de la organización; esto significa que una docena de documentos serán suficientes para una pequeña organización, mientras que las

organizaciones grandes y complejas tendrán varios cientos de documentos en su SGSI. La Fase de planificación Esta fase está formada por los siguientes pasos:          

Determinación del alcance del SGSI; Redacción de una Política de SGSI; Identificación de la metodología para evaluar los riesgos y determinar los criterios para la aceptabilidad de riesgos; Identificación de activos, vulnerabilidades y amenazas; Evaluación de la magnitud de los riesgos; Identificación y evaluación de opciones para el tratamiento de riesgos; Selección de controles para el tratamiento de riesgos; Aprobación de la gerencia para los riesgos residuales; Aprobación de la gerencia para la implementación del SGSI; Redacción de una declaración de aplicabilidad que detalle todos los controles aplicables, que determine cuáles ya han sido implementados y cuáles no son aplicables.

La Fase de implementación Esta fase incluye las siguientes actividades: 

      

Redacción de un plan de tratamiento del riesgo que describe quién, cómo, cuándo y con qué presupuesto se deberían implementar los controles correspondientes; Implementación de un plan de tratamiento del riesgo; Implementación de los controles de seguridad correspondientes; Determinación de cómo medir la eficacia de los controles; Realización de programas de concienciación y capacitación de empleados; Gestión del funcionamiento normal del SGSI; Gestión de los recursos del SGSI; Implementación de procedimientos para detectar y gestionar incidentes de seguridad.

La Fase de verificación Esta fase incluye lo siguiente: 

 

Implementación de procedimientos y demás controles de supervisión y control para determinar cualquier violación, procesamiento incorrecto de datos, si las actividades de seguridad se desarrollan de acuerdo a lo previsto, etc.; Revisiones periódicas de la eficacia del SGSI; Medición la eficacia de los controles;

    

Revisión periódica de la evaluación de riesgos; Auditorías internas planificadas; Revisiones por parte de la dirección para asegurar el funcionamiento del SGSI y para identificar oportunidades de mejoras; Actualización de los planes de seguridad para tener en cuenta otras actividades de supervisión y revisión; Mantenimiento de registros de actividades e incidentes que puedan afectar la eficacia del SGSI.

La fase de mantenimiento y mejora Esta fase incluye lo siguiente:    

Implementación en el SGSI de las mejoras identificadas; Toma de medidas correctivas y preventivas y aplicación de experiencias de seguridad propias y de terceros; Comunicación de actividades y mejoras a todos los grupos de interés; Asegurar que las mejoras cumplan los objetivos previstos.

Otras normas relacionadas con seguridad de la información Además de la ISO 27001 (antiguamente BS 7799-2), la norma ISO 27002 (antiguamente ISO 17799) es una norma “auxiliar” que proporciona más información sobre cómo implementar los controles de seguridad especificados en la ISO 27001. Otras normas que también pueden resultar útiles son la ISO 27005, que describe los procedimientos de evaluación de riesgos con mayor profundidad, y la BS 25999-2, que proporciona una descripción detallada de la gestión de la continuidad del negocio. Conceptos básicos de la BS 25999-2 Una norma líder sobre continuidad del negocio La BS 25999-2 es una norma británica emitida en 2007 que rápidamente se ha convertido en la principal norma para gestión de la continuidad del negocio; aunque se trata de una norma nacional británica, se utiliza también en muchos otros países y se predice que pronto será aceptada como una norma internacional (ISO 22301). Igual que las normas ISO 27001, ISO 9001, ISO 14001 y otras normas que definen los sistemas de gestión, la BS 25999-2 también define un sistema de gestión de la continuidad del negocio que contiene las mismas cuatro fases de gestión: planificación, implementación, revisión y supervisión; y por último, mejora.

El objetivo de estas cuatro fases es que el sistema se actualice y mejore permanentemente para que sea útil si se produjera un desastre. Los siguientes son algunos de los procedimientos y documentos más importantes requeridos por la BS 25999-2:       

Alcance del SGCN: identificación precisa de la parte de la organización en la cual se aplica la gestión de la continuidad del negocio; Política de GCN: definición de objetivos, responsabilidades, etc.; Gestión de recursos humanos; Análisis de impactos en el negocio y evaluación de riesgos; Definición de estrategia de continuidad del negocio; Planes de continuidad del negocio; Mantenimiento de planes y sistemas; mejoras.

Gestión de recursos humanos La norma establece la necesidad de determinar los conocimientos y habilidades necesarias, de identificar los cursos de capacitación adecuados, de realizar dichos cursos, de verificar si los conocimientos y habilidades requeridas se han logrado y si es necesario llevar registros La BS 25999-2 también exige la realización de programas de concienciación y también la comunicación de la importancia de la gestión de la continuidad del negocio a los empleados. Análisis de impactos en el negocio y evaluación de riesgos El análisis de impactos en el negocio se encarga de actividades importantes de la organización, define el período máximo tolerable de interrupción, la interdependencia de acciones individuales, determina qué actividades son críticas, analiza los acuerdos existentes con proveedores y socios y, finalmente, establece el objetivo de tiempo de recuperación. La evaluación de riesgos se efectúa para establecer qué desastres y demás interrupciones en las actividades comerciales podrían producirse y cuáles serían sus consecuencias; pero también para determinar qué vulnerabilidades y amenazas podrían llevar a esas interrupciones comerciales. En base a una evaluación de este tipo, la organización determina cómo reducir la probabilidad de riesgos y cómo se mitigarían en el caso que se produjeran. Definición de la estrategia de continuidad del negocio Una estrategia se refiere a definir cómo una organización se recuperará ante el caso de un desastre. La estrategia se determina en base a los resultados de los análisis de la evaluación de riesgos y de impactos en el negocio, y generalmente

contempla ubicaciones alternativas, opciones para recuperación de datos, recuperación de recursos humanos, comunicaciones, equipamiento, gestión de proveedores y socios, etc. Plan de continuidad del negocio El plan de continuidad del negocio incluye planes de respuesta a los incidentes, procedimientos de activación para el plan de continuidad del negocio, como también planes de recuperación para actividades críticas; todos estos planes se redactan en base a la estrategia de continuidad del negocio. Un plan de respuesta a los incidentes debe especificar cómo determinar tipos de incidentes, canales de comunicación, tipo de respuesta, responsabilidad, etc. Los planes de recuperación deben especificar roles y responsabilidades, pasos claves para la recuperación, ubicaciones, recursos que se utilizarán y dónde se ubicarán, prioridades, cómo actuar cuando finaliza la recuperación, etc. Mantenimiento de planes y sistemas; mejoras La norma establece lo siguiente:    

Ejercitar y probar regularmente los planes para familiarizar al personal con los planes y para verificar su actualización; Realizar auditorías internas periódicas; Revisiones por parte de la dirección para asegurarse de que el SGSI funciona y para realizar las mejoras correspondientes; Tomar medidas preventivas y correctivas para mejorar no sólo los planes sino también otros elementos del sistema.

Documentación La norma BS 25999-2 requiere los siguientes documentos:         

El alcance de GCN; La política de GCN; Responsabilidades específicas para la GCN; Procedimientos para gestionar documentos y registros y para medidas correctivas y preventivas; Metodología para el análisis de impactos en el negocio y resultados del análisis; Metodología de evaluación de riesgos; Estrategia de continuidad del negocio; Plan de continuidad del negocio que incluya planes de respuesta a los incidentes y planes de recuperación; Registros.

El volumen de documentación depende de la cantidad de actividades críticas de una organización: una organización con pocas actividades críticas también tendrá poco volumen de documentación relacionada con el análisis de impactos en el negocio, la evaluación de riesgos y los planes de continuidad del negocio; mientras que la documentación de organizaciones más grandes será mucho más extensiva. Otras normas relacionadas Además de la norma BS 25999-2, la BS 25999-1 es una norma “auxiliar” que proporciona más información sobre cómo implementar partes específicas de la BS 25999-2. Otras normas útiles son la ISO 27001, que coloca la continuidad del negocio en un contexto más amplio de seguridad de la información, y la ISO 27005, que ofrece una descripción detallada del proceso de evaluación de riesgos.

Anexo 2. Cuatro beneficios clave de la implantación de la ISO 27001 'By' Dejan Kosutic el 21 de julio 2010 ¿Alguna vez ha tratado de convencer a las directivas de una empresa para financiar la implementación de seguridad de la información? No es nada fácil, en realidad, no se les debe culpar a ellos - después de todo, su responsabilidad principal es la rentabilidad de la empresa. Eso significa que, cada una de sus decisiones se basa en el equilibrio entre inversión y beneficio, o, para decirlo en el lenguaje de la administración - ROI (retorno de la inversión). Esto significa que se tiene que evaluar cuidadosamente cómo presentar los beneficios, utilizando un lenguaje de gestión comprensible. Los beneficios de la seguridad de la información, en especial la aplicación de la norma ISO 27001 son numerosas. Pero en mi experiencia, las siguientes cuatro son los más importantes: 1. Conformidad Podría parecer extraño a la lista como el primer beneficio, pero a menudo muestra el más rápido "retorno de la inversión" - si una organización debe cumplir con varias normas en materia de protección de datos, la privacidad y el gobierno de TI (en particular si se trata de una financiera, la salud u organización gubernamental), la ISO 27001 puede aportar en la metodología haciendo el proceso más eficiente.

2. Marketing En un mercado cada vez más competitivo, a veces es muy difícil encontrar algo que le diferencie de los ojos de sus clientes. ISO 27001 podría ser de hecho un único punto de venta, sobre todo si se maneja información sensible de los clientes. 3. Reducción de los gastos La Seguridad de la información por lo general se considera como un costo sin beneficio económico evidente. Sin embargo, no es el beneficio económico si reduce sus gastos causados por incidentes. Es probable que tenga interrupción en el servicio o la fuga de datos de vez en cuando por empleados descontentos, o exempleados descontentos. La verdad es que aún no existe una metodología y/o tecnología para calcular la cantidad de dinero que podría ahorrarse por este tipo de incidentes. Pero siempre suena bien si llevan estos casos a la atención de la gerencia. 4. Poner su negocio con el fin Éste es probablemente el más subestimado - si la empresa ha crecido considerablemente en los últimos años, es posible que experimente problemas con la gestión de sus activos de información, autorizar el acceso a los sistemas de información, etc. La ISO 27001 es particularmente buena en solucionar estas cosas - que obligará a definir con precisión tanto las responsabilidades y deberes, y por lo tanto fortalecer la organización interna. Para concluir, la ISO 27001 trae muchos beneficios además de ser sólo otro certificado en la pared.

Responsabilidades en la gestión de ISO 27001 y BS 25999-2: ¿Qué tiene que saber la dirección? ¿Por qué es importante la dirección para las normas ISO 27001 y BS 25999-2? Si la dirección no aporta los recursos, tanto humanos como financieros, los proyectos ISO 27001 o BS 25999-2 fracasarán. Sin embargo, para que la dirección aporte esos recursos, es necesario que se presenten los beneficios y sus responsabilidades; solamente allí comenzarán a aceptar la idea de las normas ISO 27001 o BS 25999-2. Estas normas tienen requisitos muy precisos para los miembros de la dirección: aprobar las políticas de alto nivel, suministrar recursos, tomar decisiones clave,

permitir la auditoría interna, coordinar actividades, realizar reuniones de revisión, etc. Sin embargo, gestionar la seguridad de la información y la continuidad del negocio es mucho más sencillo de lo que parece a primera vista. Todo lo que debe hacer es integrar esas actividades con sus otras actividades habituales de gestión.

Anexo 3. You probably knew that the first step in ISO 27001 implementation is defining the scope. What you probably didn’t know is that this step, although simple at first glance, can sometimes cause you quite a lot of trouble. Namely, a lot of companies are trying to decrease their implementation costs by narrowing the scope, but they often find themselves in a situation where such a scope gives them a headache. So, where is the problem? The problem when the ISO 27001 scope is not the whole organization is that the Information Security Management System (ISMS) must have interfaces to the “outside” world – in that context, the outside world are not only the clients, partners, suppliers etc., but also the organization’s departments that are not within the scope. It may seem funny, but a department which is not within the scope should be treated in the same way as an external supplier. For instance, if you choose that only your IT department is within your scope, and this department is using the services of the purchasing department, the IT department should perform risk assessment of your purchasing department to identify if there are any risks for the information for which the IT department is responsible; moreover, those two departments should sign terms and conditions for the services provided. Why is such an overhead necessary? You have to put yourself in the certification body’s shoes – it must certify that within your scope you are able to handle the information in a secure way, while it cannot check any of your departments outside the scope. The only way to handle such a situation is to treat such departments as if they were external companies. (Please note: certification auditors never like a narrow scope.) This is not where the trouble stops. Sometimes, a narrow scope is simply not possible, because there is no interface with the outside world. For instance, if employees from both within the scope and outside the scope are sitting in the same room, such a scope is hardly feasible; if both the employees within and outside the scope use the same local network (with no segregation) and have the access to various network services, such a scope is definitely not possible – there is no way you would be able to control the information flow only inside the scope. The point here is – narrowing your ISMS scope is sometimes impossible, and in most cases it will bring you unnecessary overhead. Therefore, what initially didn’t seem like a good solution, might be the optimal one after all – try to extend your scope to the whole organization. The rule of the thumb is: if your organization has no more than a few hundred employees, and one or just a few locations, the best thing would be for the ISMS to cover the whole organization.

On the other hand, if you really cannot cover the whole organization with your ISMS scope, try to set it in an organizational unit which is sufficiently independent; try to solve the relationships with other organizational units outside the scope by determining their service through internal documents (policies, procedures etc.) that would serve as “agreements” – in such a way you could document those organizational unit’s obligations in a manner that is usable in daily operations.

Anexo 4. Information security policy – how detailed should it be? 'By 'Dejan Kosutic on May 26, 2010 Quite often I see information security policies written in too much detail, trying to cover everything from strategic objectives to how many numerical digits a password should contain. The only problem with such policies is that they contain 50 or more pages, and – no one is really taking them seriously. They usually end up serving as artificial documents whose sole purpose is to satisfy the auditor. But why are such policies extremely difficult to implement? Because they are too ambitious – they try to cover too many issues, and are intended for a wide circle of people. This is why ISO 27001, the leading information security standard, defines different levels of information security policies:  

High-level policies, such as the Information Security Management System Policy – such high level policies usually define strategic intention, objectives etc. Detailed policies – this kind of policy usually describes a selected area of information security in more detail, with precise responsibilities, etc. ISO 27001 requires that Information Security Management System (ISMS) Policy, as the highest-ranking document contains the following: the framework for setting objectives, taking into account various requirements and obligations, aligns with the organization’s strategic risk management context, and establishes risk evaluation criteria. Such a policy should be actually very short (maybe one or two pages) because it’s main purpose is for top management to be able to control their ISMS. On the other hand, detailed policies should be intended for operational use, and focused on a narrower field of security activities. Examples of such policies are: Classification policy, Policy on acceptable use of information assets, Backup policy, Access control policy, Password policy, Clear desk and clear screen policy, Policy on use of network services, Policy for mobile computing, Policy on the use of cryptographic controls, etc. Note: ISO 27001 does not require all these policies to be implemented and/or documented, because the decision whether such

controls are applicable, and to what extent, depends on the results of risk assessment. Because such policies should prescribe more details, they are usually longer – up to ten pages. If they were much longer than that, it would be very difficult to implement and maintain them.

In other words, information security is too complex an issue to be defined in a single policy – for different aspects of ISMS and different “target groups” there should be different policies. Middle-sized organizations usually build up to fifteen policies for their ISMS. One could argue that this number of policies is nothing but overhead for a company. I would certainly agree if such policies are written only with the certification audit in mind – such policies will bring nothing but more bureaucracy. However, if a policy is written with the intention of decreasing the risks, then it will most probably show its value – if not right away, then probably in two or three years, by decreasing the number of incidents.

Anexo 5. Risk assessment tips for smaller companies 'By 'Dejan Kosutic on February 22, 2010 I have seen quite a lot of smaller companies (up to 50 employees) trying to apply risk assessment tools as part of their ISO 27001 implementation project. The result is that it usually takes too much time and money with too little effect. First of all, what is actually risk assessment, and what is its purpose? Risk assessment is a process during which an organization should identify information security risks determining their likelihood and impact. Plainly speaking, the organization should recognize all the potential problems with their information, how likely they are to occur and what the consequences might be. The purpose of risk assessment is to find out which controls are needed in order to decrease the risk – selection of controls is called the risk treatment process, and in ISO 27001 they are chosen from Annex A which specifies 133 controls. Risk assessment is carried out by identifying and evaluating assets, vulnerabilities and threats. An asset is anything that has value to the organization – hardware, software, people, infrastructure, data (in various forms and media), suppliers and partners, etc. A vulnerability is a weakness in an asset, process, control,etc., which could be exploited by a threat; a threat is any cause that can inflict damage on a system or organisation. An example of vulnerability is the lack of anti-virus software; a related threat is the computer virus. Knowing all this, if your organization is small, you don’t really need a sophisticated tool to perform the risk assessment. All you need are an Excel spreadsheet, good catalogues of vulnerabilities and threats, and a good risk assessment methodology. The main job is really to evaluate likelihood and impact, and that cannot be done by any tool – it is something your asset owners, with their knowledge of their assets, have to think about. So, where do you get the catalogues and methodology? If you are using the services of a consultant, he/she should provide those; if not, there are a few free catalogues available on the Internet, you just have to do a search on Google. The methodology is not available for free, but you could use ISO 27005 standard (it describes risk assessment & treatment into detail), or you could use some other websites selling the methodology. All this should take considerably less time and money than buying a risk assessment tool and learning how to use it.

A good methodology should contain a method for identifying assets, threats and vulnerabilities, tables for marking the likelihood and impacts, a method for calculating the risk, and define the acceptable level of risk. Catalogues should contain at least 30 vulnerabilities and 30 threats; some contain even a few hundred of each, but that is probably too much for a small company. The process is really not complicated – here are the basic steps for assessment & treatment: 1. define and document the methodology (including the catalogues), distribute it to all asset owners in the organization 2. organize interviews with all the asset owners during which they should identify their assets, and related vulnerabilities and threats; in the second step ask them to evaluate the likelihood and impact if particular risks should occur 3. consolidate the data in a single spreadsheet, calculate the risks and indicate which risks are not acceptable 4. for each risk that is not acceptable, choose one or more controls from Annex A of ISO 27001 – calculate what the new level of risk would be after those controls are implemented To conclude: risk assessment and treatment really are the foundation of information security / ISO 27001, but it does not mean they have to be complicated. You can do it in a simple way, and your common sense is what really counts.

Anexo 6. Mandatory documented procedures required by ISO 27001 'By 'Dejan Kosutic on May 04, 2010 If you heard that ISO 27001 requires many procedures, this is not quite true. The standard actually requires only four documented procedures: a procedure for the control of documents, a procedure for internal ISMS audits, a procedure for corrective action, and a procedure for preventive action. The term “documented” means that “the procedure is established, documented, implemented and maintained” (ISO/IEC 27001, 4.3.1 Note 1).

Note: in this blog post I will not write about other mandatory documents like ISMS Scope, ISMS Policy, Risk Assessment Methodology, Risk Assessment Report, Statement of Applicability, Risk Treatment Plan, etc. – here I focus on procedures only. The procedure for the control of documents (document management procedure) should define who is responsible for approving documents and for reviewing them, how to identify the changes and revision status, how to distribute the documents, etc. In other words, this procedure should define how the organization’s bloodstream (the flow of documents) will function.

The procedure for internal audits must define responsibilities for planning and conducting audits, how audit results are reported, and how the records are maintained. This means that the main rules for conducting the audit must be set. The procedure for corrective action should define how the nonconformity and its cause are identified, how the necessary actions are defined and implemented, what records are taken, and how the review of the actions is performed. The purpose of this procedure is to define how each corrective action should eliminate the cause of the nonconformity so that it wouldn’t occur again. The procedure for preventive action is almost the same as the procedure for corrective action, the difference being that it aims at eliminating the cause of the nonconformity so that it wouldn’t occur in the first place. Because of their similarities, these two procedures are usually merged in one.

But why is it that ISO 27001 requires documented procedures that are not related to information security, while security procedures are not mandatory? The answer is in risk assessment – ISO 27001 does require you to perform risk assessment, and when this risk assessment identifies certain unacceptable risks, then ISO 27001 requires a control from its Annex A to be implemented that will decrease the risk(s). The control can be technical (for instance, anti-virus software

for decreasing the risk of malicious software attack), but could also be organizational – to implement a policy or a procedure (for instance, implement a back-up procedure). Therefore, the procedures are becoming mandatory only if the risk assessment identifies unacceptable risks. One important note though – as opposed to the four mandatory procedures which must be documented, the procedures arising from controls in Annex A do not have to be documented. It is up to the organization to estimate whether such a procedure is to be documented or not. You could consider the four mandatory procedures as the pillars of your management system (together with the security policy) – after they are firmly set in the ground, you can start building the walls of your house. This becomes obvious when you look at other management systems – the same four procedures are mandatory there, too – in ISO 9001 (quality management systems), ISO 14001 (environmental management systems), and BS 25999-2(business continuity management systems). As a consequence, you can use these procedures as the main link between different management systems if you want to develop the so called “integrated management system”.

Dilemmas with ISO 27001 & BS 25999-2 internal auditors 'By 'Dejan Kosutic on March 22, 2010

If this is the first time you have come across the notion of internal auditor, you are probably puzzled – Why would I need another control? Who is going to pay for it? Who should I employ to do it? It is such a waste of time… Well, it doesn’t have to be so bad – besides complying with ISO 27001 & BS 25999-2 standards, internal audits could be quite useful for your other business affairs (whether related to information security & business continuity or not). The point with internal audits is that they should discover problems that would otherwise stay hidden and would therefore harm the business. Let’s be realistic – it is human to make mistakes, so it‘s impossible to have a system with no mistakes; it is however possible to have a system which improves itself and learns from its mistakes. Internal audits are a crucial part of such a system. There are a few ways to perform internal audit: a) Employ a full time internal auditor – this is suitable only for larger organizations who would have enough work for such a person (some types of organizations – e.g. banks – are obliged by law to employ such functions).

b) Employ part time internal auditors – this is the most common situation – the organizations use their own employees to perform internal audits alongside their regular job functions. One important thing to pay attention to: in order to avoid conflict of interest (the auditors cannot audit their own work), there should be at least two internal auditors so that one could audit the regular job of the other. c) Employ internal auditor from outside of the organization – although this is not a person employed in the organization, it is still considered internal audit because the audit is performed by the organization itself, according to its own rules. Usually this is done by a person who is knowledgeable in this field (independent consultant etc.). However, from my experience as an auditor, the sad truth is that most of the organizations perform internal audits just to satisfy the certification body. The result of such internal audits are a few non-conformities which do not get deep into the real problems of information security management system (ISMS) or business continuity management system (BCMS). This is a waste of time – if the companies have invested time of their internal auditors to perform such jobs, they should gain some benefits out of it. But how then to approach internal audits in the right way – here are some thoughts: 1. The management should view the internal audit as one of the best tools to improve the system, not only as a means to get certified. 2. The internal auditor should be qualified – this means he/she must have experience in information security, information technology and auditing techniques. It does not mean that the auditor must be an expert in those fields. 3. The internal audit should be performed in a positive way – the aim should be to improve your system, not to blame the employees for their mistakes. On the positive side, as a certification auditor I did see some organizations performing internal audits in a right way. Although their employees did feel a little uncomfortable about someone checking their activities, very soon they saw the benefits of such approach – problems became transparent, and were resolved rather soon.