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) e
ICMP (Internet Control Message Protocol), túneles de nivel 3.

 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 internas y
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.

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.