INTRODUCCIN A LA NORMA ISO 27001

CUL ES EL CICLO PHVA?

El ciclo PHVA es, bsicamente un concepto desarrollado hace unos 60 aos por un famoso gur consultor y
gestin de la calidad se llama William Edwards Deming. En esencia, se dice lo siguiente:

Antes de comenzar la aplicacin de cualquier cosa, usted debe saber exactamente lo que realmente
necesita, y exactamente qu es lo que quiere lograr (objetivos) - este es la fase PLANEAR.
Una vez que sepa lo que quiere lograr, se puede empezar a aplicar la seguridad de su informacin,
continuidad del negocio, los procedimientos de calidad, o lo que sea que se centra la norma ISO , sta es
la fase HACER.
Sin embargo, todo el esfuerzo no se detiene aqu, adicionalmente se desea saber si se ha logrado lo que
se ha planeado, por lo que se necesita supervisar el sistema y medir si se alcanzaron los objetivos sta
es la fase VERIFICAR.
Por ltimo, si se da cuenta que el resultado no corresponde a lo que se ha planeado, se realizan las
correcciones y modificaciones necesarias. Por otro lado, se toman las decisiones y acciones pertinentes
para mejorar continuamente el desarrollo de los procesos. sta fase corresponde al ACTUAR.

Aunque este concepto fue desarrollado para la gestin de calidad, muy pronto se dio cuenta de que se puede
aplicar a cualquier tipo de gestin, incluida la gestin de seguridad de la informacin o la gestin de la
continuidad del negocio.
Por lo tanto, hoy en da este concepto es tan dominante en la gestin que est prcticamente en todas
partes, en todos los estndares de gestin ISO, en cada marco de gestin, en toda teora. Se ha vuelto tan
importante que es imposible evitarlo.
Que es un sistema de gestin de seguridad de la informacin SGSI)?
Parte del sistema de gestin global, basada en un enfoque hacia los riesgos globales de un negocio, cuyo fin
es establecer, implementar, operar. Hacer seguimiento, revisar, mantener y mejorar la seguridad de la
informacin.

Autor: Dejan Kosutic

FAMILIA ISO 27000

ISO 27000 : vocabulario estndar para el SGSI.

ISO 27001 : especifica los requisitos para la implantacin del SGSI.
ISO 27002 : cdigo de buenas prcticas para la gestin de seguridad de la informacin.
ISO 27003 : directrices para la implementacin del SGSI.
ISO 27004 : mtricas para la gestin de seguridad de la informacin.
ISO 27005 : gestin de riesgos en seguridad de la informacin.
ISO 27006 : requisitos para acreditacin de organizaciones que proporcionan certificacin de SGSI.
ISO 27007 : Es una gua para auditar al SGSI.
ISO 27008 : Directrices para los auditores sobre los controles de seguridad de la informacin
ISO27035 : actividades de: deteccin, reporte y evaluacin de incidentes de seguridad y sus
vulnerabilidades.

UNA INTRODUCCIN A LA NORMA ISO/IEC 27001:2013

ISO 27001 es una norma internacional publicada por la Organizacin Internacional de Normalizacin (ISO), y
describe cmo administrar seguridad de la informacin en una empresa. La ltima revisin de esta norma fue
publicada en 2013, y su ttulo completo es ahora la norma ISO / IEC 27001: 2013. La primera revisin de la
norma se public en 2005, y fue desarrollado en base a la norma britnica BS 7799-2.
Fue escrita por los mejores expertos del mundo en el campo de la seguridad de la informacin y proporciona
metodologa para la implementacin de la gestin de seguridad de la informacin en una
organizacin. Tambin permite a las empresas para obtener la certificacin, lo que significa que un organismo
de certificacin independiente ha confirmado que una organizacin ha implementado seguridad de la
informacin de acuerdo a la ISO 27001.
La norma ISO 27001:2013 especifica los requisitos para establecer, implantar, poner en funcionamiento,
controlar, revisar, mantener y mejorar un SGSI documentado dentro del contexto global de los riesgos de
negocio de la organizacin.

Autor: Dejan Kosutic

BASES DE LA SEGURIDAD INFORMTICA

Fiabilidad

Existe una frase que se ha hecho famosa dentro del mundo de la seguridad. Eugene Spafford, profesor de ciencias
informticas en la Universidad Purdue (Indiana, EEUU) y experto en seguridad de datos, dijo que el nico sistema
seguro es aquel que est apagado y desconectado, enterrado en un refugio de cemento, rodeado por gas venenoso y
custodiado por guardianes bien pagados y muy bien armados. An as, yo no apostara mi vida por l.
Hablar de seguridad informtica en trminos absolutos es imposible y por ese motivo se habla mas bien de fiabilidad del
sistema, que, en realidad es una relajacin del primer trmino.
Definimos la Fiabilidad como la probabilidad de que un sistema se comporte tal y como se espera de l. En general, un
sistema ser seguro o fiable si podemos garantizar tres aspectos:
Confidencialidad: acceso a la informacin solo mediante autorizacin y de forma controlada.
Integridad: modificacin de la informacin solo mediante autorizacin.
Disponibilidad: la informacin del sistema debe permanecer accesible mediante autorizacin.

Existe otra propiedad de los sistemas que es la Confiabilidad, entendida como nivel de calidad del servicio que se ofrece.
Pero esta propiedad, que hace referencia a la disponibilidad, estara al mismo nivel que la seguridad. En nuestro caso
mantenemos la Disponibilidad como un aspecto de la seguridad.

Confidencialidad
En general el trmino 'confidencial' hace referencia a "Que se hace o se dice en confianza o con seguridad recproca
entre dos o ms personas." (http://buscon.rae.es)
En trminos de seguridad de la informacin, la confidencialidad hace referencia a la necesidad de ocultar o mantener
secreto sobre determinada informacin o recursos.
El objetivo de la confidencialidad es, entonces, prevenir la divulgacin no autorizada de la informacin. En general,
cualquier empresa pblica o privada y de cualquier mbito de actuacin requiere que cierta informacin no sea accedida
por diferentes motivos. Uno de los ejemplos mas tpicos es el del ejrcito de un pas. Adems, es sabido que los logros
mas importantes en materia de seguridad siempre van ligados a temas estratgicos militares.
Por otra parte, determinadas empresas a menudo desarrollan diseos que deben proteger de sus competidores. La
sostenibilidad de la empresa as como su posicionamiento en el mercado pueden depender de forma directa de la
implementacin de estos diseos y, por ese motivo, deben protegerlos mediante mecanismos de control de acceso que
aseguren la confidencialidad de esas informaciones.
Un ejemplo tpico de mecanismo que garantice la confidencialidad es la Criptografa, cuyo objetivo es cifrar o encriptar
los datos para que resulten incomprensibles a aquellos usuarios que no disponen de los permisos suficientes.
Pero, incluso en esta circunstancia, existe un dato sensible que hay que proteger y es la clave de encriptacin. Esta clave
es necesaria para que el usuario adecuado pueda descifrar la informacin recibida y en funcin del tipo de mecanismo de
encriptacin utilizado, la clave puede/debe viajar por la red, pudiendo ser capturada mediante herramientas diseadas
para ello. Si se produce esta situacin, la confidencialidad de la operacin realizada (sea bancaria, administrativa o de
cualquier tipo) queda comprometida.

Autor: Dejan Kosutic

Integridad

En general, el trmino 'integridad' hace referencia a una cualidad de 'ntegro' e indica "Que no carece de ninguna de sus
partes." y relativo a personas "Recta, proba, intachable.".
En trminos de seguridad de la informacin, la integridad hace referencia a la fidelidad de la informacin o recursos, y
normalmente se expresa en lo referente a prevenir el cambio impropio o desautorizado.
El objetivo de la integridad es, entonces, prevenir modificaciones no autorizadas de la informacin.
La integridad hace referencia a:
la integridad de los datos (el volumen de la informacin)
la integridad del origen (la fuente de los datos, llamada autenticacin)
Es importante hacer hincapi en la integridad del origen, ya que puede afectar a su exactitud, credibilidad y confianza
que las personas ponen en la informacin.
A menudo ocurre que al hablar de integridad de la informacin no se da en estos dos aspectos.
Por ejemplo, cuando un peridico difunde una informacin cuya fuente no es correcta, podemos decir que se mantiene la
integridad de la informacin ya que se difunde por medio impreso, pero sin embargo, al ser la fuente de esa informacin
errnea no se est manteniendo la integridad del origen, ya que la fuente no es correcta.

Disponibilidad

En general, el trmino 'disponibilidad' hace referencia a una cualidad de 'disponible' y dicho de una cosa "Que se puede
disponer libremente de ella o que est lista para usarse o utilizarse."
En trminos de seguridad de la informacin, la disponibilidad hace referencia a que la informacin del sistema debe
permanecer accesible a elementos autorizados.
El objetivo de la disponibilidad es, entonces, prevenir interrupciones no autorizadas/controladas de los recursos
informticos.
En trminos de seguridad informtica un sistema est disponible cuando su diseo e implementacin permite
deliberadamente negar el acceso a datos o servicios determinados. Es decir, un sistema es disponible si permite no
estar disponible.
Y un sistema 'no disponible' es tan malo como no tener sistema. No sirve.
Como resumen de las bases de la seguridad informtica que hemos comentado, podemos decir que la seguridad
consiste en mantener el equilibrio adecuado entre estos tres factores. No tiene sentido conseguir la confidencialidad para
un archivo si es a costa de que ni tan siquiera el usuario administrador pueda acceder a l, ya que se est negando la
disponibilidad.
Dependiendo del entorno de trabajo y sus necesidades se puede dar prioridad a un aspecto de la seguridad o a otro. En
ambientes militares suele ser siempre prioritaria la confidencialidad de la informacin frente a la disponibilidad. Aunque
alguien pueda acceder a ella o incluso pueda eliminarla no podr conocer su contenido y reponer dicha informacin ser
tan sencillo como recuperar una copia de seguridad (si las cosas se estn haciendo bien).
En ambientes bancarios es prioritaria siempre la integridad de la informacin frente a la confidencialidad o disponibilidad.
Se considera menos daino que un usuario pueda leer el saldo de otro usuario a que pueda modificarlo.

Autor: Dejan Kosutic

27001 ISO ha convertido en el ms popular estndar de seguridad de la informacin en todo el mundo y

muchas empresas se han certificado - aqu se puede ver el nmero de certificados en el ltimo par de aos:

Fuente: La encuesta ISO del sistema de gestin certificaciones estndares

ENFOQUE DE LA NORMA ISO 27001

El enfoque de la norma ISO 27001 es la proteccin de la confidencialidad, integridad y disponibilidad de la
informacin de una empresa. Esto se hace mediante la bsqueda de lo que podra suceder, problemas
potenciales de la informacin (es decir, la evaluacin de riesgos), y luego la definicin de lo que hay que
hacer para evitar este tipo de problemas ocurra (es decir, la mitigacin de riesgos o el tratamiento del
riesgo). Por lo tanto, la filosofa principal de la norma ISO 27001 se basa en la gestin de riesgos: averiguar
dnde estn los riesgos, y luego tratar sistemticamente.
Las salvaguardias (o controles) que se van a implementar son por lo general en forma de medidas,
procedimientos e implementacin tcnica (por ejemplo, software y equipo). Sin embargo, en la mayora de los
casos las compaas ya tienen todo el hardware y el software en su lugar, pero los estn utilizando de una
manera no segura - por lo tanto, la mayor parte de la implementacin ISO 27001 ser sobre la configuracin
de las reglas de organizacin (es decir, escribir documentos) que sean necesarios a fin de evitar las brechas
de seguridad.
Puesto que tal aplicacin requerir mltiples polticas, procedimientos, personas, activos, etc., para ser
administrado, la ISO 27001 ha descrito cmo encajar todos estos elementos en el sistema de gestin de
seguridad de la informacin (SGSI).
Por lo tanto, la gestin de seguridad de la informacin no es slo alrededor de la seguridad de TI (es decir, los
cortafuegos, antivirus, etc.) - tambin se trata de procesos de gestin, proteccin legal, la gestin de los
recursos humanos, la proteccin fsica, etc.

Autor: Dejan Kosutic

POR QU ES BUENA LA NORMA ISO 27001 PARA UNA EMPRESA?

Hay 4 beneficios de negocio esenciales que una empresa puede lograr con la aplicacin de esta norma de
seguridad de la informacin:
Cumplen los requisitos legales - hay ms y ms leyes, regulaciones y requisitos contractuales relacionados con
la seguridad de la informacin, y la buena noticia es que la mayora de ellos se pueden resolver mediante la
aplicacin de la norma ISO 27001 - esta norma le da la metodologa perfecta para cumplir con todos ellos .
Lograr una ventaja de comercializacin - si su empresa se certific y sus competidores no lo hacen, es posible
que tenga una ventaja sobre ellos a los ojos de los clientes que son sensibles acerca de mantener su
informacin segura.
Menores costos - la filosofa principal de la norma ISO 27001 es prevenir incidentes de seguridad - y cada
incidente, grande o pequea, cuesta dinero. Por lo tanto, mediante la prevencin de ellos, su empresa va a
ahorrar un montn de dinero. Y lo mejor de todo - la inversin en la norma ISO 27001 es mucho ms pequea
que el ahorro de costes que va a lograr.
Una mejor organizacin - por lo general, las empresas de rpido crecimiento no tienen el tiempo para parar y
definir sus procesos y procedimientos - como consecuencia, muy a menudo los empleados no saben lo que
hay que hacer, cundo y por quin. La implementacin de la norma ISO 27001 ayuda a resolver este tipo de
situaciones, ya que anima a las empresas que escriban sus procesos principales (incluso los que no estn
relacionados con la seguridad), lo que les permite reducir el tiempo perdido de sus empleados.

DNDE ENCAJA LA GESTIN DE SEGURIDAD DE LA INFORMACIN EN UNA EMPRESA

Esencialmente, seguridad de la informacin es parte de la gestin global de los riesgos en una empresa, con
reas que se superponen con la seguridad ciberntica, la gestin de la continuidad del negocio y la gestin de
TI:

Autor: Dejan Kosutic

ESTRUCTURA ISO 27001

ISO / IEC 27001 se divide en 11 secciones, ms el Anexo A. 114 controles (salvaguardias) colocados
en 14 secciones (secciones A.5 a A.18).

Secciones de 0 a 3 son de introduccin (y no son obligatorios para la implementacin),

las secciones 4 a 10 son obligatorios - lo que significa que todos sus requisitos se deben implementar
en una organizacin si quiere ser compatible con el estndar.

Controles del Anexo A slo debe implementarse si se declara como aplicable en la Declaracin de
aplicabilidad.

Autor: Dejan Kosutic

Seccin 0: Introduccin Explica el propsito de la norma ISO 27001 y su compatibilidad con otras normas de gestin.
Seccin 1: Objeto y campo de aplicacin
Explica que esta norma es aplicable a cualquier tipo de organizacin.
Seccin 2: Referencias normativas
Se refiere a la norma ISO / IEC 27000 como estndar en el que se dan los trminos y definiciones.
Seccin 3: Trminos y definiciones
De nuevo, se refiere a la norma ISO / IEC 27000.
Seccin 4: Contexto de la organizacin
Esta seccin es parte de la fase del planear en el ciclo PHVA y define los requisitos para la comprensin
de los problemas externos e internos, las partes interesadas y sus necesidades, y la definicin del
alcance del SGSI.
Seccin 5: Liderazgo
Esta seccin es parte de la fase del planear en el ciclo PHVA y define las responsabilidades de alta
direccin, el establecimiento de las funciones y responsabilidades, y los contenidos de la poltica de
seguridad de la informacin de nivel superior.
Se establecen las responsabilidades y compromisos de la Alta Direccin respecto al Sistema de Gestin
de Seguridad de la Informacin y entre otros aspectos, la necesidad de que la Alta Direccin establezca
una poltica de seguridad de la informacin adecuada al propsito de la organizacin, aseguren la
asignacin de los recursos para el SGSI y que las responsabilidades y roles pertinentes a la seguridad de
la informacin se asignen y comuniquen.
Seccin 6: Planificacin
Esta seccin es parte de la fase del planear en el ciclo PHVA y define los requisitos para la evaluacin, el
tratamiento del riesgo, Declaracin de aplicabilidad, el plan de tratamiento de riesgos, y el establecimiento
de los objetivos de seguridad de la informacin.
Seccin 7: Apoyo
Esta seccin es parte de la fase de planear en el ciclo PHVA y define los requisitos para la disponibilidad
de los recursos, las competencias, la sensibilizacin, la comunicacin y el control de documentos y
registros.
Seccin 8: Operacin
Esta seccin es parte de la fase Hacer en el ciclo PHVA y define la aplicacin de la evaluacin del riesgo
y el tratamiento, as como los controles y otros procesos necesarios para alcanzar los objetivos de
seguridad de la informacin.
Seccin 9: Evaluacin del desempeo
Esta seccin es parte de la fase de verificar en el ciclo PHVA y define los requisitos para el seguimiento,
medicin, anlisis, evaluacin, auditora interna y revisin por la direccin.
Seccin 10: Mejora
Esta seccin es parte de la fase de Actuar en el ciclo PHVA y define los requisitos para las no
conformidades, correcciones, acciones correctivas y de mejora continua.
Anexo A
Este anexo se ofrece un catlogo de 114 controles (salvaguardias) colocados en 14 secciones (secciones
A.5 a A.18).

Autor: Dejan Kosutic

CMO SE ESTRUCTURAN LOS CONTROLES, Y EL PROPSITO DE CADA UNA DE LAS 14

SECCIONES DEL ANEXO A:

A.5 Las polticas de seguridad de la informacin - controles sobre cmo las polticas estn escritas y
revisadas
A.6 Organizacin de seguridad de la informacin - los controles sobre cmo se asignan las
responsabilidades; Tambin incluye los mandos de los dispositivos mviles y el teletrabajo.
A.7 la seguridad de los recursos humanos - los controles previos al empleo, durante y despus del
empleo
A.8 La gestin de activos - controles relacionados con el inventario de los activos y de uso aceptable,
tambin para la clasificacin de la informacin y manejo de medios.
A.9 Control de acceso - controles para la poltica de control de acceso, gestin de acceso de usuario,
sistema y control de acceso a las aplicaciones y responsabilidades de los usuarios
A.10 Criptografa - controles relacionados con el cifrado y gestin de claves
A.11 fsica y la seguridad del medio ambiente - los controles que definen las reas de seguridad,
controles de entrada, proteccin contra las amenazas, la seguridad de equipos, eliminacin segura,
clara y de escritorio de poltica claro de la pantalla, etc.
A.12 Operacional de seguridad - un montn de controles relacionados con la gestin de la produccin
de TI: gestin del cambio, gestin de la capacidad, el malware, copia de seguridad, supervisin,
instalacin, vulnerabilidades, etc.
A.13 Comunicaciones de seguridad - controles relacionados con la seguridad de la red, la
segregacin, los servicios de red, la transferencia de informacin, mensajera, etc.
Sistema A.14 adquisicin, desarrollo y mantenimiento - controles que definen los requisitos de
seguridad y la seguridad en los procesos de desarrollo y de apoyo
A.15 Relaciones con los proveedores - controles sobre qu incluir en los acuerdos, y cmo supervisar
los proveedores
A.16 informacin gestin de incidentes de seguridad - controles para informar sobre los eventos y
debilidades, la definicin de responsabilidades, procedimientos de respuesta, y la recogida de pruebas
A.17 aspectos de informacin de seguridad de la gestin de la continuidad del negocio - los
controles que requieren la planificacin de la continuidad del negocio, los procedimientos, la verificacin
y revisin, y la redundancia de TI
A.18 Cumplimiento - controles que exigen la identificacin de las leyes y reglamentos aplicables,
proteccin de la propiedad intelectual, la proteccin de datos personales, y las revisiones de seguridad
de la informacin

La mejor manera de entender el Anexo A es pensar en un catlogo de 114 controles de seguridad de donde
puede elegir los que son aplicables a su empresa.

RELACIN CON LA PARTE PRINCIPAL DE LA NORMA ISO 27001

Por lo tanto, no todos estos controles son obligatorios 114 - una empresa puede elegir por s mismo que
controla en su caso, y despus deber ponerlas en prctica (en la mayora de los casos, al menos el 90% de
los controles son aplicables); el resto se declara como no aplicables. Por ejemplo, el control de desarrollo
contratado externamente A.14.2.7 se puede marcar como no aplicable si una empresa no externaliza el
desarrollo de software. El principal criterio para la seleccin de los controles es a travs de la gestin de
riesgos, que se define en los puntos 6 y 8 de la parte principal de la norma ISO 27001.
Adems, la clusula 5 de la parte principal de la norma ISO 27001 requiere que se determinar
responsabilidades para la gestin de esos controles, y la clusula 9 se requiere para medir si los controles han
cumplido su propsito. Por ltimo, la clusula 10 requiere que usted para arreglar todo lo que est mal con
esos controles, y para asegurarse de que lograr los objetivos de seguridad de la informacin con los controles.

RELACIN CON LA NORMA ISO 27002

Autor: Dejan Kosutic

La verdad es que el Anexo A de la norma ISO 27001 no da demasiados detalles acerca de cada control. Por
lo general hay una frase para cada control, lo que le da una idea de lo que necesita para alcanzar, pero no
cmo hacerlo. Este es el propsito de la norma ISO 27002 - tiene exactamente la misma estructura que la
norma ISO 27001 Anexo A.

ISO 27001 vs ISO 27002

La norma ISO 27002 es mucho ms detallada, mucho ms precisas , cul es el propsito de la norma ISO
27001, entonces?
En primer lugar, no se puede obtener la certificacin segn la norma ISO 27002, ya que no es una norma de
gestin. Qu significa un estndar de gestin? Esto significa que dicha norma define cmo funciona un
sistema, y en el caso de la norma ISO 27001, se define el sistema de gestin de seguridad de la informacin
(SGSI) -, por lo tanto, la certificacin segn la norma ISO 27001 es posible.
Este sistema de gestin de seguridad de la informacin significa que debe ser planificado, implementado,
supervisado, revisado y mejorado. Esto significa que la gestin tiene sus responsabilidades distintas, que se
deben establecer objetivos, medidos y revisados, que las auditoras internas deben llevarse a cabo 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 corresponden a los mismos del Anexo A de la norma ISO 27001 - por
ejemplo, en la norma ISO 27002 el control 6.1.3 corresponde a el nombre de contacto con las autoridades, en
la norma ISO 27001 tambin se llama igual A.6.1.3 contacto con las autoridades. Sin embargo, la diferencia
est en el nivel de detalle - en promedio, ISO 27002 explica un control en una pgina entera, mientras que la
ISO 27001 dedica slo una frase para cada control.
La pregunta es: por qu es la existencia de estas dos normas por separado, por qu no se les ha fusionado,
para integrar los aspectos positivos de ambos estndares? La respuesta es la usabilidad - si se trataba de un
nico estndar, sera demasiado complejo y demasiado grande para su uso prctico.
Todas las normas de la serie ISO 27000 est diseado con un cierto enfoque - si usted quiere construir los
cimientos de la seguridad de la informacin en su organizacin, y disear su marco, se debe utilizar la norma
ISO 27001; si se desea implementar controles, se debe utilizar la norma ISO 27002, si se desea llevar a cabo
la evaluacin y tratamiento de riesgos, se debe utilizar la norma ISO 27005, etc.
Para concluir, se puede decir que sin los detalles proporcionados en la norma ISO 27002, los controles
definidos en el anexo A de la norma ISO 27001 no se podran ejecutar; Sin embargo, sin el marco de gestin
de la norma ISO 27001, ISO 27002 seguir siendo simplemente un esfuerzo aislado de unos pocos
entusiastas de la seguridad de la informacin, sin la aceptacin por parte de la alta direccin y por lo tanto sin
impacto real en la organizacin.

LA IMPORTANCIA DE LA DECLARACIN DE APLICABILIDAD PARA LA NORMA ISO 27001

La importancia de la Declaracin de aplicabilidad (a veces conocida como (DdA) generalmente es
subestimada, como el Manual de calidad en la norma ISO 9001, ya que se trata del documento principal que
define cmo usted implementar una gran parte de su sistema de seguridad de la informacin.
De hecho, la Declaracin de aplicabilidad es el nexo principal entre la evaluacin y el tratamiento del riesgo y
la implementacin de su sistema de seguridad de la informacin.
El objetivo de este documento es definir cules de los 114 controles (medidas de seguridad) sugeridos en el
Anexo A de la norma ISO 27001 son los que usted implementar y, para los controles que correspondan,
cmo se realizar su implementacin.

POR QU ES NECESARIA?
Autor: Dejan Kosutic

Ahora bien, por qu es necesario este documento cuando usted ya ha realizado el Informe sobe la
evaluacin de riesgos, que tambin es obligatorio y que tambin define los controles necesarios? Estos son
los motivos:
Ante todo, durante el tratamiento de riesgos usted identific los controles que deban implementarse porque
primero identific los riesgos que eran necesario disminuir. Sin embargo, en la DdA usted tambin identific
los controles necesarios por otras razones; por ejemplo, por motivos legales, por requisitos contractuales,
por otros procesos, etc.
Segundo, el Informe sobre la evaluacin de riesgos puede resultar bastante largo: algunas organizaciones
pueden identificar algunos miles de riesgos (a veces, an ms); por eso, un documento de estas
caractersticas no resulta realmente til en el uso operativo diario. En cambio, la Declaracin de
aplicabilidad es bastante breve ya que tiene 114 filas (cada una representa un control); esto permite que
pueda ser presentada ante la gerencia y que pueda ser actualizada.
Tercero, y ms importante, la DdA se debe documentar si cada control aplicable ya est implementado o
no. Una estrategia efectiva, y que la mayora de los auditores buscar, tambin es describir cmo se
implementa cada control aplicable; por ejemplo, haciendo referencia a un documento (poltica,
procedimiento, instrucciones de funcionamiento, etc.) o detallando brevemente el procedimiento vigente o
el equipo que se utiliza.
De hecho, si solicita la certificacin ISO 27001, el auditor de certificacin tomar su Declaracin de
aplicabilidad y recorrer su empresa verificando si ha implementado los controles de la forma en que lo ha
detallado en su DdA. Es el principal documento que utilizan para realizar la auditora presencial.
Muy pocas empresas se dan cuenta de que redactando una buena Declaracin de aplicabilidad pueden
disminuir la cantidad de otros documentos; por ejemplo, si desea documentar un determinado control, pero
la descripcin del procedimiento para ese control resultara demasiado breve, lo puede incluir en la DdA.
De esta forma, estara evitando redactar otro documento.

POR QU ES TIL
Basados en la experiencia, se puede afirmar que la mayora de las empresas que implementan el sistema de
gestin de seguridad de la informacin de acuerdo con la norma ISO 27001 dedican mucho ms tiempo en
redactar este documento que lo que haban previsto. El motivo es que deben pensar cmo implementarn sus
controles: Comprarn nuevos equipos? Modificarn el procedimiento? Contratarn un nuevo empleado?
Estas son decisiones bastante importantes (y, a veces, costosas), por ello no sorprende que requiera mucho
tiempo tomarlas. Lo bueno acerca de la DdA es que obliga a las organizaciones a hacer las cosas de forma
sistemtica.
Por lo tanto, no se debera tomar este documento simplemente como uno de esos documentos innecesarios
que no tienen una utilidad real. Piense que es la principal declaracin en la que usted define lo que desea
hacer con su seguridad de la informacin. Si est redactado correctamente, la DdA es un resumen perfecto
acerca de por qu se debe hacer, cmo se debe hacer y de lo que se debe hacer en seguridad de la
informacin.

Autor: Dejan Kosutic

Diagrama para la Clusula 6.1.3: Tratamiento de los riesgos de seguridad de la informacin. ISO/IEC 27001:2013

DOCUMENTACIN OBLIGATORIA
Qu documentos y registros son necesarios?
La siguiente lista detalla la cantidad mnima de documentos y registros requeridos por la Revisin 2013 de la
norma ISO/IEC 27001:
Documentos*

Captulo de ISO 27001:2013

Alcance del SGSI

4.3

Polticas y objetivos de seguridad de la informacin

5.2, 6.2

Metodologa de evaluacin y tratamiento de riesgos

6.1.2

Declaracin de aplicabilidad

6.1.3 d)

Plan de tratamiento del riesgo

6.1.3 e), 6.2

Informe de evaluacin de riesgos

8.2

Definicin de funciones y responsabilidades de seguridad

A.7.1.2, A.13.2.4

Inventario de activos

A.8.1.1

Uso aceptable de los activos

A.8.1.3

Poltica de control de acceso

A.9.1.1

Procedimientos operativos para gestin de TI

A.12.1.1

Principios de ingeniera para sistema seguro

A.14.2.5

Autor: Dejan Kosutic

Poltica de seguridad para proveedores

A.15.1.1

Procedimiento para gestin de incidentes

A.16.1.5

Procedimientos de la continuidad del negocio

A.17.1.2

Requisitos legales, normativos y contractuales

A.18.1.1

Registros*

Captulo de ISO 27001:2013

Registros de capacitacin, habilidades, experiencia y calificaciones

7.2

Resultados de supervisin y medicin

9.1

Programa de auditora interna

9.2

Resultados de las auditoras internas

9.2

Resultados de la revisin por parte de la direccin

9.3

Resultados de acciones correctivas

10.1

Registros sobre actividades de los usuarios, excepciones y eventos

de seguridad.

A.12.4.1, A.12.4.3

*Se pueden excluir los controles del Anexo A si una organizacin determina que no existen riesgos ni otros
requisitos que podran demandar la implementacin de un control.
Esta no es, de ninguna forma, una lista definitiva de documentos y registros que se pueden utilizar durante la
implementacin de ISO 27001; la norma permite que se agregue cualquier otro documento que pueda mejorar
el nivel de seguridad de la informacin.
DOCUMENTOS NO OBLIGATORIOS DE USO FRECUENTE
Los siguientes son otros documentos que se utilizan habitualmente:
Documentos

Captulo de ISO 27001:2013

Procedimiento para control de documentos

7.5

Controles para gestin de registros

7.5

Procedimiento para auditora interna

9.2

Procedimiento para medidas correctivas

10.1

Poltica Trae tu propio dispositivo (BYOD)

A.6.2.1

Poltica sobre dispositivos mviles y tele-trabajo

A.6.2.1

Poltica de clasificacin de la informacin

A.8.2.1, A.8.2.2, A.8.2.3

Poltica de claves

A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.3

Poltica de eliminacin y destruccin

A.8.3.2, A.11.2.7

Procedimiento para trabajo en reas seguras

A.11.1.5

Poltica de pantalla y escritorio limpio

A.11.2.9

Poltica de gestin de cambio

A.12.1.2, A.14.2.4

Autor: Dejan Kosutic

Poltica de creacin de copias de seguridad

A.12.3.1

Poltica de transferencia de la informacin

A.13.2.1, A.13.2.2, A.13.2.3

Anlisis del impacto en el negocio

A.17.1.1

Plan de prueba y verificacin

A.17.1.3

Plan de mantenimiento y revisin

A.17.1.3

Estrategia de la continuidad del negocio

A.17.2.1

CMO ESTRUCTURAR LOS DOCUMENTOS Y REGISTROS MS COMUNES

Alcance del SGSI
Este documento es, habitualmente, bastante corto y se redacta al inicio de la implementacin de ISO 27001.
En general, se trata de un documento independiente, aunque puede ser unificado con una poltica de
seguridad de la informacin.
Polticas y objetivos de seguridad de la informacin
La poltica de seguridad de la informacin generalmente es un documento breve y de alto nivel que detalla el
principal objetivo del SGSI. Los objetivos para el SGSI, en general, se presentan como un documento
independiente, pero tambin pueden ser unificados en la poltica de seguridad de la informacin.
Contrariamente a la revisin 2005 de ISO 27001, ya no se necesitan ambas polticas (Poltica del SGSI y
Poltica de seguridad de la informacin); solo hace falta una poltica de seguridad de la informacin.
Metodologa e informes de evaluacin y tratamiento de riesgos
La metodologa de evaluacin y tratamiento del riesgo es, habitualmente, un documento de 4 a 5 pginas y
debe ser redactado antes que se realice la evaluacin y el tratamiento de riesgos. El informe de evaluacin y
tratamiento de riesgos debe ser redactado una vez que se realiz la evaluacin y el tratamiento de riesgos, y
all se resumen todos los resultados.
Declaracin de aplicabilidad
La Declaracin de aplicabilidad (o DdA) se redacta en base a los resultados del tratamiento del riesgo; es un
documento clave dentro del SGSI porque describe no slo qu controles del Anexo A son aplicables, sino
tambin cmo se implementarn y su estado actual. Tambin debera considerar a la Declaracin de
aplicabilidad como un documento que describe el perfil de seguridad de su empresa.
Plan de tratamiento del riesgo
Este es, bsicamente, un plan de accin sobre cmo implementar los diversos controles definidos por la DdA.
Este documento se desarrolla en funcin de la Declaracin de aplicabilidad y se utiliza y actualiza activamente
a lo largo de toda la implementacin del SGSI. A veces se puede fusionar con el Plan del proyecto.
Funciones y responsabilidades de seguridad
El mejor mtodo es describir estas funciones y responsabilidades en todas las polticas y procedimientos de la
forma ms precisa posible. Evite expresiones como "debera hacerlo"; en cambio, utilice algo como "el Jefe de
seguridad realizar xyz todos los lunes a las zxy horas". Algunas empresas prefieren detallar las funciones y
responsabilidades de seguridad en sus descripciones del trabajo; sin embargo, esto puede generar mucho
papelero.

Autor: Dejan Kosutic

Las funciones y responsabilidades de seguridad para terceros se definen a travs de contratos.

Inventario de activos
Si no contaba con un inventario de este tipo antes del proyecto ISO 27001, la mejor forma de hacerlo es
directamente a partir del resultado de la evaluacin de riesgos ya que all, de todos modos, se tienen que
identificar todos los activos y sus propietarios; entonces, simplemente puede copiar el resultado desde ese
instrumento.
Uso aceptable de los activos
Habitualmente, este documento se confecciona bajo la forma de una poltica y puede cubrir un amplio rango
de temas porque la norma no define muy bien este control. Probablemente, la mejor forma de encararlo es la
siguiente: (1) djelo para el final de la implementacin de su SGSI y (2) todas las reas y controles que no
haya cubierto con otros documentos y que involucran a todos los empleados, inclyalos en esta poltica.
Poltica de control de acceso
En este documento usted puede cubrir slo la parte comercial de la aprobacin de acceso a determinada
informacin y sistemas, o tambin puede incluir el aspecto tcnico del control de acceso. Adems, puede
optar por definir reglas para acceso lgico nicamente o tambin para acceso fsico. Debera redactar este
documento solamente despus de finalizado su proceso de evaluacin y tratamiento de riesgos.
Procedimientos operativos para gestin de TI
Puede crear este procedimiento como un nico documento o como una serie de polticas y procedimientos; si
se trata de una empresa pequea, debera tener menor cantidad de documentos. Normalmente, aqu puede
abarcar todas las reas de las secciones A.12 y A.13: gestin de cambios, servicios de terceros, copias de
seguridad, seguridad de red, cdigos maliciosos, eliminacin y destruccin, transferencia de informacin,
supervisin del sistema, etc. Este documento se debera redactar solamente una vez que finalice su proceso
de evaluacin y tratamiento de riesgos.
Principios de ingeniera para sistema seguro
Este es un nuevo control en ISO 27001:2013 y requiere que se documenten los principios de ingeniera de
seguridad bajo la forma de un procedimiento o norma y que se defina cmo incorporar tcnicas de seguridad
en todas las capas de arquitectura: negocio, datos, aplicaciones y tecnologa. Estos principios pueden incluir
validacin de datos de entrada, depuracin, tcnicas para autenticacin, controles de sesin segura, etc.
Poltica de seguridad para proveedores
Este tambin es un control nuevo en ISO 27001:2013, y una poltica de este tipo puede abarcar un amplio
rango de controles: cmo se realiza la seleccin de potenciales contratistas, cmo se ejecuta la evaluacin de
riesgos de un proveedor, qu clusulas incluir en el contrato, cmo supervisar el cumplimiento de clusulas
contractuales de seguridad, cmo modificar el contrato, cmo cerrar el acceso una vez cancelado el contrato,
etc.
Procedimiento para gestin de incidentes
Este es un procedimiento importante que define cmo se informan, clasifican y manejan las debilidades,
eventos e incidentes de seguridad. Este procedimiento tambin define cmo aprender de los incidentes de
seguridad de la informacin para que se puedan evitar en el futuro. Un procedimiento de esta clase tambin
puede invocar al plan de continuidad del negocio si un incidente ha ocasionado una interrupcin prolongada.
Procedimientos de la continuidad del negocio

Autor: Dejan Kosutic

Generalmente se trata de planes de continuidad del negocio, planes de respuesta ante incidentes, planes de
recuperacin para el sector comercial de la organizacin y planes de recuperacin ante desastres (planes de
recuperacin para infraestructura de TI). Estos procedimientos se describen con mayor detalle en la norma
ISO 22301, la principal norma internacional para continuidad del negocio.
Requisitos legales, normativos y contractuales
Este listado debe confeccionarse en la etapa ms temprana posible del proyecto porque muchos documentos
tendrn que ser desarrollados de acuerdo a estos datos. Este listado debe incluir no slo las
responsabilidades para el cumplimiento de determinados requerimientos, sino tambin los plazos.
Registros de capacitacin, habilidades, experiencia y calificaciones
Es el departamento de recursos humanos el que generalmente se encarga de llevar estos registros. Si usted
no tiene un sector de este tipo, cualquier persona que habitualmente se encargue de los registros de los
empleados debera ser quien realice este trabajo. Bsicamente, sera suficiente una carpeta en la que se
encuentren todos los documentos.
Resultados de supervisin y medicin
La forma ms sencilla de describir cmo se miden los controles es a travs de polticas y procedimientos que
definan a cada control. En general, esta descripcin puede ser realizada al final de cada documento, y cada
descripcin tiene que definir los tipos de ICD (indicadores clave de desempeo) que es necesario medir para
cada control o grupo de controles.
Una vez que se estableci este mtodo de control, usted debe realizar la medicin en funcin de dicho
mtodo. Es importante reportar los resultados de esta medicin en forma regular a las personas que estn a
cargo su evaluacin.
Programa de auditora interna
El programa de auditora interna no es ms que un plan anual para realizar las auditoras; para las empresas
ms pequeas, puede tratarse solamente de una auditora, mientras que para las organizaciones ms
grandes puede ser una serie de, por ejemplo, 20 auditoras internas. Este programa debe definir quin
realizar las auditoras, los mtodos que se utilizarn, los criterios que se aplicarn, etc.
Resultados de las auditoras internas
Un auditor interno debe generar un informe de auditora, que incluye los resultados de la auditora
(observaciones y medidas correctivas). Este informe debe ser confeccionado dentro de un par de das luego
de realizada la auditora interna. En algunos casos, el auditor interno tendr que verificar si todas las medidas
correctivas se aplicaron segn lo esperado.
Resultados de la revisin por parte de la direccin
Estos registros se presentan, normalmente, bajo la forma de actas de reunin y deben incluir todo el material
tratado durante la reunin de la direccin, como tambin todas las decisiones que se tomaron. Estas actas
pueden ser en papel o en formato digital.
Resultados de acciones correctivas
Generalmente, estos son incluidos en los formularios para medidas correctivas (FMC). Sin embargo, es
mucho mejor agregar estos registros en alguna aplicacin que ya est en uso en la organizacin; por ejemplo,

Autor: Dejan Kosutic

la Mesa de ayuda, porque las medidas correctivas no son ms que listas de actividades a realizar con
responsabilidades, tareas y plazos bien definidos.
Registros sobre actividades de los usuarios, excepciones y eventos de seguridad
Habitualmente se llevan de dos formas: (1) en formato digital, generados en forma automtica o
semiautomtica como registros de diversas TI y de otros sistemas, y (2) en papel, donde cada registro se
hace manualmente.
Procedimiento para control de documentos
En general, este es un procedimiento independiente, de 2 o 3 pginas de extensin. Si usted ya implement
alguna otra norma como ISO 9001, ISO 14001, ISO 22301 o similar, puede
utilizar el mismo procedimiento para todos estos sistemas de gestin. A veces es mejor redactar este
procedimiento como el primer documento de un proyecto.
Controles para gestin de registros
La forma ms sencilla es redactar el control de registros en cada poltica o procedimiento (u otro documento)
que requiera la generacin de un registro. Estos controles, normalmente son incluidos hacia el final de cada
documento y se confeccionan bajo el formato de una tabla que detalla dnde se archiva el registro, quin tiene
acceso, cmo se protege, por cunto tiempo se archiva, etc.
Procedimiento para auditora interna
Habitualmente este es un procedimiento independiente que puede tener entre 2 y 3 pginas y que tiene que
ser redactado antes que comience la auditora interna. En cuanto al procedimiento para control de
documentos, un procedimiento para auditora interna puede ser utilizado para cualquier sistema de gestin.
Procedimiento para medidas correctivas
Este procedimiento no debera exceder las 2 o 3 pginas y puede ser confeccionado al final del proyecto de
implementacin, aunque es mejor hacerlo antes para que los empleados puedan familiarizarse con l.
LA LGICA BSICA DE LA NORMA ISO 27001: CMO FUNCIONA LA SEGURIDAD DE LA
INFORMACIN?
Autor: Dejan Kosutic
Al hablar con alguien nuevo de la norma ISO 27001 , muy a menudo me encuentro con el mismo problema:
esta persona cree que la norma describir en detalle todo lo que tiene que hacer - por ejemplo, la frecuencia
con la que se necesita para realizar la copia de seguridad, a qu distancia de su sitio de recuperacin de
desastres debe ser, o lo que es peor, que tipo de tecnologa que deben utilizar para la proteccin de red o
cmo tienen que configurar el router.
Aqu est la mala noticia: la ISO 27001 no prescribe estas cosas; funciona de una manera completamente
diferente. Este es el por qu

Por qu es la ISO 27001 no prescriptiva?

Imaginemos que la norma prescribe que es necesario realizar una copia de seguridad cada 24 horas - esto es
la medida correcta para usted? Podra ser, pero cranme, muchas empresas hoy en da se encuentran este
insuficientes - la velocidad de cambio de sus datos es tan rpido que lo que necesitan hacer copia de
seguridad sino es en tiempo real, por lo menos cada hora. Por otro lado, todava hay algunas empresas que

Autor: Dejan Kosutic

encontrara la copia de seguridad una vez al da con demasiada frecuencia - su tasa de cambio es an muy
lento, por lo que realizar copia de seguridad tan a menudo pueden ser excesivos.
El punto es - si esta norma es para adaptarse a cualquier tipo de una empresa, entonces este enfoque
prescriptivo no es posible. Por lo tanto, es simplemente imposible no slo para definir la frecuencia de copia
de seguridad, sino tambin la tecnologa a utilizar, cmo configurar cada dispositivo, etc.
Por cierto, esta percepcin de que la ISO 27001 prescribir todo es el mayor generador de mitos sobre la
norma ISO 27001.

La gestin de riesgos es la idea central de la norma ISO 27001

Por lo tanto, puede que se pregunte, "Por qu necesitara un estndar que no me dice nada en concreto?"
Debido a que la norma ISO 27001 proporciona un marco para que usted decida sobre la proteccin
adecuada. De la misma manera, por ejemplo, no se puede copiar una campaa de marketing de otra empresa
para su propio, este mismo principio es vlido para la seguridad de la informacin - que necesita para
adaptarlo a sus necesidades especficas.
Y la forma en la norma ISO 27001 dice que usted pueda lograr este traje hecho a medida es llevar a cabo la
evaluacin y tratamiento de riesgos. Esto no es ms que una descripcin sistemtica de las cosas malas que
pueden suceder a usted (que evalan los riesgos), y luego decidir qu medidas de seguridad para poner en
prctica para evitar que esas cosas malas sucedan (tratamiento de los riesgos).
La idea aqu es que usted debe aplicar slo aquellas salvaguardas (controles) que se requieren debido a los
riesgos, no los que alguien piensa que son de fantasa; pero, esta lgica tambin significa que se debe
implementar todos los controles que son necesarios debido a los riesgos, y que no se puede excluir algunos
simplemente porque no les gustan.

ISO 27001 EVALUACIN DEL RIESGO Y EL TRATAMIENTO - 6 PASOS BSICOS

1. metodologa de evaluacin del Riesgo
Este es el primer paso en su viaje a travs de la gestin de riesgos. Es necesario definir reglas sobre cmo se
va a realizar la gestin del riesgo porque quiere toda su organizacin para hacerlo de la misma manera - el
mayor problema con la evaluacin del riesgo ocurre si las diferentes partes de la organizacin realizan de una
manera diferente. Por lo tanto, es necesario definir si desea que la evaluacin cualitativa o cuantitativa del
riesgo, que escala que va a utilizar para la evaluacin cualitativa, lo que ser el nivel aceptable de riesgo, etc.
2. aplicacin de evaluacin del Riesgo
Una vez que conozca las reglas, puede empezar a averiguar qu problemas potenciales podran pasar a ti es necesario enumerar todos sus activos, a continuacin, las amenazas y las vulnerabilidades relacionadas
con esos activos, evaluar el impacto y la probabilidad para cada combinacin de activos / amenazas /
vulnerabilidades y finalmente calcular el nivel de riesgo.
En mi experiencia, las empresas suelen ser conscientes de slo el 30% de sus riesgos. Por lo tanto, es
probable que encuentre este tipo de ejercicio muy revelador - cuando haya terminado usted comenzar a
apreciar el esfuerzo que ha hecho.
3. la implementacin del tratamiento del Riesgo
Por supuesto, no todos los riesgos son creados iguales - usted tiene que centrarse en los ms importantes,
los llamados "riesgos inaceptables".
Hay cuatro opciones que se pueden elegir para mitigar cada riesgo inaceptable:
Aplicar los controles de seguridad del anexo A para disminuir los riesgos
Transferir el riesgo a otra parte - por ejemplo, a una compaa de seguros con la compra de una pliza
de seguro.

Autor: Dejan Kosutic

Evitar el riesgo al detener una actividad que es demasiado arriesgado, o por hacerlo de una manera
completamente diferente.
Aceptar el riesgo - si, por ejemplo, el costo para mitigar ese riesgo sera mayor que el dao en s.
Esto es donde tiene que ser creativo - cmo disminuir los riesgos con una inversin mnima. Sera el
ms fcil si su presupuesto es ilimitado, pero eso nunca va a suceder. Y debo decirle que,
lamentablemente, su gestin es correcto - es posible lograr el mismo resultado con menos dinero slo tiene que encontrar la manera.

4. Informe de Evaluacin de Riesgos ISMS

A diferencia de los pasos anteriores, ste es bastante aburrido - que necesita para documentar todo lo que
has hecho hasta ahora. No slo por los auditores, pero es posible que desee comprobar usted mismo estos
resultados en un ao o dos.
5. Declaracin de aplicabilidad
En este documento se demuestra realmente el perfil de seguridad de su empresa - en base a los resultados
del tratamiento del riesgo que necesita para enumerar todos los controles que haya implementado, por la que
ellos han puesto en prctica y cmo. Este documento tambin es muy importante debido a que el auditor de
certificacin lo usar como la directriz principal de la auditora.
.
6. Plan de tratamiento del riesgo
Este es el paso donde hay que pasar de la teora a la prctica. Vamos a ser francos - todo hasta ahora a todo
este trabajo de gestin del riesgo era puramente terico, pero ahora es el momento de mostrar algunos
resultados concretos.
Este es el propsito del plan de tratamiento del riesgo - para definir exactamente que va a poner en prctica
cada control, en el que periodo de tiempo, con lo que el presupuesto, etc. yo preferira llamar a este "Plan de
Implementacin 'documento o' plan de accin ', pero vamos a seguir a la terminologa utilizada en la norma
ISO 27001.
Una vez que usted ha escrito este documento, es crucial para obtener su aprobacin de la administracin, ya
que llevar tiempo y esfuerzo (y dinero) para poner en prctica todos los controles que usted ha planeado
aqu considerable. Y sin su compromiso no se va a ninguna de ellas.
Y eso es todo - usted ha comenzado su viaje de no saber cmo configurar su seguridad de la informacin de
todo el camino de tener una imagen muy clara de lo que necesita para poner en prctica. El punto es - ISO
27001 obliga a hacer este viaje de una manera sistemtica.

Autor: Dejan Kosutic