ISO 27001/BS 25999 documents, presentation decks and implementation guidelines


Free_Downloads
 
Newsletter
 
Sign up to our free Newsletter and as bonus you'll receive my tips on how to launch an information security and business continuity project.
 
 
 
 
 

Recent Posts

 
    

UPCOMING WEBINARS

    

 
ISO 27001 & BS 25999-2: Why is it better to implement them together?

    

Wednesday
May 23, 2012

    Register_now_green
    

 
Risk Management Part 1: Risk assessment methodology and risk assessment process

Monday
May 21, 2012

    Register_now_green
 
 
 
 

Recuperación ante desastres vs. Continuidad del negocio

ByDejan Kosutic on November 04, 2010

¿Alguna vez le ha sucedido que su gerente le asigne la responsabilidad de implementar la continuidad del negocio simplemente porque usted es parte del departamento de TI? ¿Por qué se identifica continuidad del negocio con tecnología de la información?

Probablemente porque la continuidad del negocio tiene sus orígenes en la recuperación ante desastres, y la recuperación ante desastres básicamente se trata de tecnología de la información. Veinte o treinta ańos atrás, la continuidad del negocio no existía conceptualmente, pero sí la recuperación ante desastres: la principal preocupación era cómo salvar los datos si se producía un desastre. En ese momento, era muy común comprar equipos costosos y colocarlos en una ubicación remota para que todos los datos importantes de una organización estuvieran resguardados si, por ejemplo, se produjera un terremoto. No sólo resguardados sino también que los datos se procesarían más o menos con la misma capacidad que si estuvieran en la ubicación principal.

Pero después de un tiempo se hizo evidente… ¿para qué servirían los datos si no existieran operaciones comerciales en las cuales utilizarlos? Así fue como surgió la idea de la continuidad del negocio: su objetivo es permitir que el negocio siga funcionando, aún en caso de una interrupción importante.

Definiciones

Veamos las definiciones: continuidad del negocio es la “capacidad estratégica y táctica de la organización para planificar y responder ante los incidentes e interrupciones del negocio con el fin de permitir la continuidad de las actividades comerciales en un nivel aceptable previamente definido” (BS 25999-2:2007); mientras que recuperación ante desastres se refiere “al proceso, políticas y procedimientos relacionados con preparar la recuperación o continuación de la infraestructura tecnológica crítica de una organización después de un desastre natural o producido por el hombre” (Wikipedia.org).

Como puede ver en las definiciones, en la recuperación ante desastres el énfasis se encuentra en la tecnología, mientras que para la continuidad del negocio son las actividades comerciales. Por lo tanto, la primera es parte de la segunda; la puede considerar como uno de los principales facilitadores de las actividades comerciales, o como la parte tecnológica de la continuidad del negocio.

Sin embargo, es posible que usted haya notado algo más: la definición de continuidad del negocio está tomada de la norma BS 25999-2, la principal norma sobre gestión de continuidad del negocio, mientras que la definición de recuperación ante desastres está extraída de Wikipedia. En realidad, “continuidad del negocio” es un término oficial reconocido por las normas, mientras “recuperación ante desastres” no.

Importancia de la implementación

Entonces, ¿por qué no es una buena idea que un departamento de TI implemente la continuidad del negocio para toda la organización? Porque la continuidad del negocio es principalmente un asunto comercial, no un tema de TI. Si el departamento de TI implementara la continuidad del negocio para toda la organización, no podría definir la criticidad de las actividades comerciales ni de la información. Además, es un interrogante ver si lograría el compromiso de las partes comerciales de la organización.

La mejor forma de organizar la implementación de la continuidad del negocio es que el sector comercial lidere el proyecto; de esta forma lograría mayor concienciación y aceptación de todos los sectores de la organización. El departamento de TI debe cumplir su función en ese proyecto, una función clave, preparando los planes de recuperación ante desastres.

También puede dar un vistazo a nuestro webinar Fundamentos de BS 25999-2 – Parte 1: Análisis del impacto en el negocio (es un curso de capacitación disponible para la venta).


Controles del Anexo A de la norma ISO 27001

ByDejan Kosutic on October 20, 2010

El Anexo A de la norma ISO 27001 es, probablemente, el anexo más nombrado de todas las normas de gestión. ¿Por qué se habla tanto sobre él? ¿Por qué a veces es controvertido?

Si usted ya ha leído el Anexo A, ha observado que allí se enumeran 133 controles de seguridad. En ese caso, ¿para qué se usa la parte principal de la norma?

Objetivo

El Anexo A contiene los siguientes puntos (a veces denominados como dominios del Anexo A de la norma ISO 27001):

  • A.5 Política de seguridad
  • A.6 Organización de la seguridad de la información
  • A.7 Gestión de activos
  • A.8 Seguridad relacionada con el personal
  • A.9 Seguridad física y del entorno
  • A.10 Gestión de comunicaciones y operaciones
  • A.11 Control de acceso
  • A.12 Adquisición, desarrollo y mantenimiento de los sistemas de la información
  • A.13 Gestión de los incidentes de seguridad de la información
  • A.14 Gestión de la continuidad del negocio
  • A.15 Cumplimiento

Como ya se ha mencionado, el Anexo A contiene 133 controles que, como se puede observar por los nombres de los puntos, no se centran solamente en tecnologías de la información; también incluyen seguridad física, protección legal, gestión de recursos humanos, asuntos organizacionales, etc.

Por lo tanto, puede considerar al Anexo A como una especie de catálogo de medidas de seguridad para utilizar durante el proceso de tratamiento: una vez que identifica riesgos no aceptables en la evaluación de riesgos, el Anexo A le ayudará a escoger los controles adecuados para disminuir esos riesgos. Y le asegura no olvidar ningún control importante.

El Anexo A es donde se juntan las normas ISO 27001 e ISO 27002. Los controles de la norma ISO 27002 tienen los mismos nombres que en el Anexo A de la norma ISO 27001; pero la diferencia se encuentra en el nivel de detalle: la ISO 27001 sólo proporciona una breve descripción de un control, mientras que la ISO 27002 ofrece lineamientos detallados sobre cómo implementar el control.

Desventajas

Si usted piensa que, por lo mencionado hasta ahora, el Anexo A es la herramienta perfecta de implementación para su proyecto de seguridad de la información, no sea tan optimista. También cuenta con algunas cosas que no tienen sentido. Por ejemplo, algunos controles definen casi los mismos temas, generando, a veces, confusión; como, por ejemplo, los puntos A.9.2.6 (Eliminación segura o re-uso del equipo) y A.10.7.2 (Eliminación de medios). Por otro lado, algunos temas, como relaciones con terceros, están dispersos en varios puntos del Anexo A; por ejemplo, puede encontrar este tema en los puntos A.6.2 (Entidades externas), A.8 (Seguridad relacionada con el personal) y A.10.2 (Gestión de entrega de servicios de terceros) y en el control A.12.5.5 (Desarrollo de outsourced software). Esto hace que, en ocasiones, el Anexo A sea difícil de usar como herramienta de implementación.

Pero esas no son las únicas ambigüedades. En algunos de los controles, el Anexo A menciona políticas y procedimientos y, sin embargo, no requiere que tengan que ser documentados. Puede parecer gracioso, pero la norma requiere políticas o procedimientos escritos solamente donde aparece la palabra “documentado”. Cuando se analiza todo el Anexo A, se observa que menciona la palabra “documentado” en sólo 6 controles (A.5.1.1, A.7.1.3, A.8.1.1, A.10.1.1, A.11.1.1, A.15.1.1); eso significa que usted puede implementar todos los demás controles sin documentarlos.

Sin embargo, no debe abusar de esta flexibilidad del Anexo A. Cuanto más grande es la organización, mayor cantidad de documentos debe generar para garantizar que todo el mundo es consciente de (y cumple con) sus procedimientos de seguridad. Por otro lado, debe tener mucho cuidado de no excederse con la documentación, ya que si es excesiva, nadie la tendrá en cuenta.

Relación con la parte principal de la norma ISO 27001

La parte principal de la norma, o más precisamente los puntos obligatorios 4 a 8, contienen la parte de gestión de la norma y establecen el ciclo PDCA (las fases de Planificación-Implementación-Verificación-Mantenimiento), incluyendo evaluación y tratamiento de riesgos, control de documentación, control de registros, provisión de recursos, auditoría interna, revisión por parte de la dirección, medidas correctivas y preventivas, etc.

Como se mencionó anteriormente, el proceso de evaluación y tratamiento de riesgos es la principal conexión entre los puntos 4 a 8 y los controles del Anexo A: le ayudará a decidir si son necesarios, o no, aplicar controles específicos del Anexo A para disminuir los riesgos.

Esto significa que los puntos 4 a 8 y el Anexo A no pueden existir uno sin el otro: la evaluación de riesgos no tiene sentido si no hay controles para disminuir los riesgos, y la única forma de determinar la aplicabilidad de los controles es a través de la evaluación de riesgos.

En mi opinión, este enfoque sobre los riesgos y sobre la flexibilidad de aplicar controles de seguridad de acuerdo con lo que usted considera adecuado, son los mejores aspectos de la norma ISO 27001. Sólo tiene que asegurarse de aprovecharlos completamente.

También puede dar un vistazo a nuestro webinar Fundamentos de ISO 27001 – Parte 3: Resumen del Anexo A (es un curso de capacitación disponible para la venta).


¿Cómo abordar a quienes no creen en la GCN?

ByDejan Kosutic on October 05, 2010

¿Alguna vez ha escuchado algo como “eso no se puede hacer”, “no tiene sentido” o “sería inútil si se produjera una catástrofe”? Si ya ha implementado la gestión de la continuidad del negocio, probablemente sí. Obviamente, estas actitudes no aportan nada a su proyecto; por eso, aquí le presentamos algunas sugerencias sobre cómo tratar con este tipo de personas.

“Si se produjera una catástrofe, no podríamos hacer nada”

Probablemente, ésta sea la más habitual. Está bien, es posible que tengan razón; a menos que usted haya preparado la estrategia de continuidad del negocio y los planes de continuidad del negocio realmente tomando en cuenta todos los posibles escenarios. Si lo hizo de esta forma, puede explicarles que ha preparado una ubicación alternativa que se encuentra suficientemente alejada para resistir cualquier tipo de desastre, que ha generado copias de seguridad de los datos, que hay un reemplazo para cualquier empleado de la empresa, que ya cuenta con proveedores alternativos para todos los servicios críticos, etc.

“Si se desata una guerra nuclear, no servirá de nada”

Bueno, a menos que usted sea un proveedor militar, no tendría importancia, ¿verdad? Básicamente, ante este tipo de escenarios catastróficos, probablemente su negocio ya no tendría ningún sentido.

“No tiene sentido”

Sencillamente, rece para que nunca tenga que utilizar la continuidad del negocio. Aún sin mencionar los más que conocidos ejemplos como el 11/9 o el Huracán Katrina, basta preguntar ¿alguna vez ha sufrido un apagón eléctrico? ¿O se le rompió el servidor? ¿O tal vez un ordenador que contenía datos importantes? ¿Escuchó alguna vez que un edificio se haya incendiado íntegramente? Es suficiente leer los titulares de los periódicos para comprender que esas cosas le suceden a cualquiera.

“Lo haremos solamente para cumplir con el auditor”

Prioridad incorrecta. Si lo hace correctamente, se protegerá a usted mismo y, como consecuencia, su auditor estará satisfecho.

“No podemos prever todos los incidentes”

Es verdad. Al menos al principio. Pero si realiza correctamente la evaluación de riesgos, si consulta diversas publicaciones y recursos y controla periódicamente la evaluación, es posible que, con el tiempo, pueda tomar en cuenta todos los riesgos posibles. Una vez que sepa cuáles son, puede preparar la respuesta.

“Ante un caso de emergencia, la gente pensará primero en cuidar a sus familias, no el negocio”

También es verdad. En el caso de un terremoto, ¿quién no llamaría primero a su familia para verificar si se encuentra a salvo? Pero si planifica detenidamente quién se puede ir a su casa después de ocurrido un incidente y quién debe quedarse para resolver la situación, y si se ocupa de las familias de los empleados que se deben quedar (por ej., asignando esta tarea a otros empleados), tal vez le pueda haber encontrado una solución a este problema.

“Las personas reaccionan irracionalmente en situaciones de crisis”

Completamente cierto. Pero si capacita a sus empleados (y proveedores o socios) periódicamente, y practica los planes de continuidad del negocio, se habituarán a situaciones estresantes y, probablemente, responderán en la forma correcta si se produjera una situación de este tipo.

Si ya ha implementado proyectos similares, sabrá que la concienciación es importante. Si sus compañeros de trabajo no son conscientes del objetivo de este tipo de proyectos, a usted le resultará muy difícil llevar adelante la implementación. Por no decir que podría fracasar el proyecto entero. Es por ello que debe evaluar el hecho de generar conciencia con anticipación.

También puede dar un vistazo a nuestro webinar Fundamentos de BS 25999-2 – Parte 2: Estrategia de continuidad del negocio (es un curso de capacitación disponible para la venta).


Lista de apoyo para implementación de ISO 27001

ByDejan Kosutic on September 28, 2010

Si usted está empezando a implementar la norma ISO 27001, probablemente esté buscando una forma sencilla para hacerlo. Permítame desilusionarlo: no existe una forma sencilla para lograrlo. Sin embargo, intentaré facilitarle el trabajo. Este es un listado de dieciséis pasos que deberá seguir si desea obtener la certificación ISO 27001:

1. Obtener el apoyo de la dirección

Esto puede parecer un tanto obvio y, generalmente, no es tomado con la seriedad que merece. Pero, de acuerdo con mi experiencia, es el principal motivo en el fracaso de los proyectos para la implementación de la norma ISO 27001 ya que la dirección no destina suficientes recursos humanos para que trabajen en el proyecto ni suficiente dinero. (Lea Cuatro beneficios clave de la implementación de la norma ISO 27001 para presentarle el tema a la dirección)

2. Tomarlo como un proyecto

Como ya se ha dicho, la implementación de la norma ISO 27001 es un tema complejo que involucra diversas actividades, a muchas personas y puede demandar varios meses (o más de un año). Si no define claramente qué es lo que se hará, quién lo hará y en qué período de tiempo (por ej., aplicar la gestión del proyecto), es probable que nunca termine el trabajo.

3. Definir el alcance

Si se trata de una gran organización, probablemente tenga sentido implementar la norma ISO 27001 solamente en una parte de la misma, reduciendo significativamente de esta forma, los riesgos del proyecto. (Problemas para definir el alcance de la norma ISO 27001)

4. Redactar una Política de SGSI

La Política de SGSI es el documento más importante en su SGSI: no debe ser demasiado detallado pero debe definir algunos temas básicos sobre la seguridad de la información en su organización. Pero ¿cuál es su objetivo si no es minucioso? El objetivo es que la dirección defina qué desea lograr y cómo controlarlo. (Política de Seguridad de la Información: ¿qué nivel de detalle debería tener?)

5. Definir la metodología de Evaluación de riesgos

La evaluación de riesgos es la tarea más compleja del proyecto para la norma ISO 27001; su objetivo es definir las reglas para identificar los activos, las vulnerabilidades, las amenazas, las consecuencias y las probabilidades, como también definir el nivel aceptable de riesgo. Si esas reglas no están definidas claramente, usted podría encontrarse en una situación en la que obtendría resultados inservibles. (Consejos sobre la evaluación de riesgos para empresas pequeñas)

6. Realizar la evaluación y el tratamiento de riesgos

Aquí, usted tiene que implementar lo que definió en el paso anterior. En organizaciones más grandes puede demandar varios meses, por lo tanto, debe coordinar esta tarea con mucho cuidado. Lo importante es obtener una visión integral de los peligros sobre la información de su organización.

El objetivo del proceso de tratamiento de riesgos es reducir los riesgos no aceptables (generalmente se hace planificando el uso de controles del Anexo A).

En este paso, se debe redactar un Informe sobre la evaluación de riesgos que documente todos los pasos tomados durante el proceso de evaluación y tratamiento de riesgos. También es necesario conseguir la aprobación de los riesgos residuales; ya sea en un documento separado o como parte de la Declaración de aplicabilidad.

7. Redactar la Declaración de aplicabilidad

Luego de finalizar su proceso de tratamiento de riesgos, sabrá exactamente qué controles del Anexo necesita (hay un total de 133 controles pero, probablemente, no los necesite a todos). El objetivo de este documento (generalmente denominado DdA) es enumerar todos los controles, definir cuáles son aplicables y cuáles no, definir los motivos de esa decisión, los objetivos que se lograrán con los controles y describir cómo se implementarán.

La Declaración de aplicabilidad también es el documento más apropiado para obtener la autorización de la dirección para implementar el SGSI.

8. Redactar el Plan de tratamiento del riesgo

Justo cuando pensaba que había resuelto todos los documentos relacionados con el riesgo, aquí aparece otro. El objetivo del Plan de tratamiento del riesgo es definir claramente cómo se implementarán los controles de la DdA, quién lo hará, cuándo, con qué presupuesto, etc. Este documento es, en realidad, un plan de implementación enfocado sobre sus controles; sin el cual, usted no podría coordinar los pasos siguientes del proyecto.

9. Determinar cómo medir la eficacia de los controles

Otra tarea que, generalmente, es subestimada. El tema aquí es, si usted no puede medir lo que ha hecho, ¿cómo puede estar seguro de que ha logrado el objetivo? Por lo tanto, asegúrese de determinar cómo medirá el logro de los objetivos establecidos tanto para todo el SGSI como para cada control aplicable de la Declaración de aplicabilidad.

10. Implementación de controles y procedimientos obligatorios

Es más fácil decirlo que hacerlo. Aquí es cuando debe implementar los cuatro procedimientos obligatorios y los controles correspondientes del Anexo A.

Esta es, habitualmente, la tarea más riesgosa de su proyecto ya que, generalmente, implica la aplicación de nuevas tecnologías pero, sobre todo, la implementación de nuevas conductas en su organización. Muchas veces las nuevas políticas y procedimientos son necesarios (en el sentido que el cambio es necesario) y las personas, generalmente, se resisten al cambio; es por ello que la siguiente tarea (capacitación y concienciación) es vital para prevenir ese riesgo.

11. Implementar programas de capacitación y concienciación

Si quiere que sus empleados implementen todas las nuevas políticas y procedimientos, primero debe explicarles por qué son necesarios y debe capacitarlos para que puedan actuar según lo esperado. La falta de estas actividades es el segundo motivo principal por el fracaso del proyecto para la implementación de la norma ISO 27001.

12. Hacer funcionar el SGSI

Esta es la parte en que ISO 27001 se transforma en una rutina diaria dentro de su organización. La palabra más importante aquí es: “registros”. A los auditores les encantan los registros; sin registros le resultará muy difícil probar que una actividad se haya realizado realmente. Pero, ante todo, los registros deberían ayudarle. Con ellos, usted puede supervisar qué está sucediendo, sabrá realmente si sus empleados (y proveedores) están realizando sus tareas según lo requerido.

13. Supervisión del SGSI

¿Qué está sucediendo en su SGSI? ¿Cuántos incidentes tiene? ¿De qué tipo? ¿Todos los procedimientos se efectúan correctamente?

Aquí es donde se cruzan los objetivos de los controles con la metodología de medición; debe verificar si los resultados que obtiene cumplen con lo que se estableció en los objetivos. Si no se cumplen, es evidente que algo está mal y debe aplicar medidas correctivas y/o preventivas.

14. Auditoría interna

Muchas veces las personas no son conscientes de que están haciendo algo mal (por otro lado, a veces sí lo saben pero no quieren que nadie lo descubra). Pero no ser consciente de los problemas existentes o potenciales puede dañar a su organización, por eso debe realizar auditorías internas para descubrir este tipo de cosas. Lo importante aquí no es activar medidas disciplinarias, sino aplicar medidas correctivas y/o preventivas. (Dilemas con los auditores internos de las normas ISO 27001 y BS 25999-2)

15. Revisión por parte de la dirección

La dirección no tiene que configurar el cortafuegos, pero sí debe saber qué está sucediendo en el SGSI; es decir, si todo el mundo ejecutó sus tareas, si el SGSI obtiene los resultados deseados, etc. En base a estos aspectos, la dirección debe tomar algunas decisiones importantes.

16. Medidas correctivas y preventivas

El objetivo del sistema de gestión es garantizar que todo lo que está mal (las denominadas “no conformidades”) sea corregido o, con algo de suerte, evitado. Por lo tanto, la norma ISO 27001 requiere que las medidas correctivas y preventivas se apliquen sistemáticamente; es decir, que se identifique la raíz de una no conformidad y se solucione y se controle.

Tal vez, este artículo haya aclarado qué es necesario hacer. Aunque implementar la norma ISO 27001 no sea una tarea sencilla, no necesariamente tiene que ser tan complicado. Solamente debe planificar detalladamente cada paso, y no se preocupe… obtendrá su certificado.

Aquí puede descargar el diagrama del proceso de implementación de la norma ISO 27001 que muestra todos estos pasos junto con la documentación requerida.


Diferencias y similitudes entre ISO 27001 e ISO 27002

ByDejan Kosutic on September 13, 2010

Si se ha topado con las normas ISO 27001 y ISO 27002, probablemente haya notado que la ISO 27002 es mucho más detallada y mucho más precisa. Entonces, ¿cuál es el objetivo de la ISO 27001?

Ante todo, no es posible obtener la certificación ISO 27002 porque no es una norma de gestión. ¿Qué significa una norma de gestión? Significa que este tipo de norma define cómo ejecutar un sistema; y en el caso de la ISO 27001, esta norma define el sistema de gestión de seguridad de la información (SGSI). Por lo tanto, la certificación en ISO 27001 sí es posible.

Este sistema de gestión significa que la seguridad de la información debe ser planificada, implementada, supervisada, revisada y mejorada. Significa que la gestión tiene sus responsabilidades específicas, que se deben establecer, medir y revisar objetivos, que se deben realizar auditorías internas, etc. Todos esos elementos están establecidos en la ISO 27001, pero no en la ISO 27002.

Los controles de la norma ISO 27002 tienen la misma denominación que los indicados en el Anexo A de la ISO 27001; por ejemplo, en la ISO 27002 el control 6.1.6 se denomina Contacto con autoridades, mientras que en la ISO 27001 es el A.6.1.6 Contacto con autoridades. Pero la diferencia radica en el nivel de detalle; en general, la ISO 27002 explica un control en toda una página, mientras que la ISO 27001 sólo le dedica una oración a cada uno.

Por último, la diferencia está en que la ISO 27002 no distingue entre los controles que son aplicables a una organización determinada y los que no lo son. Por otro lado, la ISO 27001 exige la realización de una evaluación de riesgos sobre cada control para identificar si es necesario disminuir los riesgos y, en caso que sea necesario, hasta qué punto deben aplicarse.

La pregunta es: ¿Por qué existen ambas normas en forma separada, por que no han sido integradas utilizando los aspectos positivos de cada una? La respuesta está en la utilidad: si fuera una única norma, sería demasiado compleja y larga como para que sea práctica.

Cada norma de la serie ISO 27001 está diseñada con un enfoque preciso: si desea crear la estructura de la seguridad de la información en su organización y definir su encuadre, debería usar la ISO 27001; si desea implementar controles, debería usar la ISO 27002; si desea realizar la evaluación y tratamiento de riesgos, debería usar la ISO 27005; etc.

Para finalizar, se podría decir que sin la descripción proporcionada por la ISO 27002, los controles definidos en el Anexo A de la ISO 27001 no se podrían implementar. Sin embargo, sin el marco de gestión de la ISO 27001, la ISO 27002 sería simplemente un esfuerzo aislado de unos pocos apasionados por la seguridad de la información, sin la aceptación de la alta dirección y, por lo tanto, sin efectos reales sobre la organización.

También puede dar un vistazo a nuestro webinar Fundamentos de ISO 27001 – Parte 3: Resumen del Anexo A (es un curso de capacitación disponible para la venta).


Cuatro beneficios clave de la implementación de la norma ISO 27001

ByDejan Kosutic on July 21, 2010

¿Alguna vez ha intentado convencer a los directores de su empresa de que financien la implementación de la seguridad de la información? Si lo ha hecho, probablemente sepa qué se siente: le preguntarán cuánto cuesta y, si les parece muy caro, le dirán que no.

En realidad, no debería culparlos; después de todo, su principal responsabilidad es la rentabilidad de la empresa. Esto quiere decir que cada decisión que tomen se basará en la relación entre inversión y beneficio; o, para expresarlo en el lenguaje de gestión, tendrá en cuenta el ROI (rendimiento de la inversión).

Esto significa que debe hacer un trabajo previo antes de proponer una inversión de este tipo: piense detenidamente cómo presentar los beneficios utilizando un idioma que los directivos comprendan y apoyen.

Intentaré ayudarle. Los beneficios de la seguridad de la información, especialmente la implementación de la norma ISO 27001, son muchos. Pero, por experiencia, creo que estos cuatro son los más importantes:

1. Cumplimiento

Puede resultar extraño mencionar este beneficio en primer lugar, pero, generalmente, es el que demuestra el “rendimiento de la inversión” más rápidamente. Si una organización debe cumplir con diversas normas sobre protección de datos, privacidad y control de TI (especialmente si se trata de una organización financiera, de salud o gubernamental), la norma ISO 27001 puede aportar la metodología que permita hacerlo de la manera más eficiente.

2. Ventaja de comercialización

En un mercado cada vez más competitivo, a veces es muy difícil encontrar algo que lo diferencie ante la percepción de sus clientes. La norma ISO 27001 puede ser un verdadero punto a favor, especialmente si usted administra información sensible de sus clientes.

3. Disminución de gastos

Generalmente, se considera a la seguridad de la información como un costo sin una ganancia financiera evidente. Sin embargo, hay una ganancia financiera si usted disminuye los gastos ocasionados por incidentes. Probablemente sí se produzcan en su empresa interrupciones de servicio o esporádicos filtrados de datos, o tengan empleados descontentos. O ex empleados descontentos.

La verdad es que aún no existe una metodología ni tecnología que pueda calcular cuánto dinero se puede ahorrar si evita ese tipo de incidentes. Pero siempre es oportuno alertar a la dirección sobre estos casos.

4. Ordenamiento de su negocio

Probablemente, éste sea el beneficio más subestimado; pero si su empresa ha tenido un crecimiento continuo durante los últimos años, es posible que tenga problemas para determinar quién decide qué cosas, quién es responsable de determinados activos de la información, quién debe autorizar el acceso a los sistemas de información, etc.

La norma ISO 27001 es especialmente útil para resolver estas cuestiones: le obligará a definir de forma muy precisa tanto las responsabilidades como las obligaciones y, de esta forma, ayudará a reforzar su organización interna.

Para finalizar, la norma ISO 27001 puede aportar muchos beneficios, además de ser sólo otro certificado colgado en su pared. En la mayoría de los casos, si usted presenta esos beneficios de forma clara, los directores comenzarán a prestarle atención.

También puede dar un vistazo a nuestro webinar Responsabilidades en la gestión de ISO 27001 y BS 25999-2: ¿Qué tiene que saber la dirección? (es un curso de capacitación disponible para la venta).


Problemas para definir el alcance de la norma ISO 27001

ByDejan Kosutic on June 29, 2010

Probablemente, usted ya sabía que el primer paso en la implementación de la norma ISO 27001 era la definición del alcance. Lo que tal vez no sabía era que este paso, aunque parezca sencillo a primera vista, a veces le puede ocasionar bastantes problemas. Por ejemplo, muchas compañías tratan de disminuir sus costos de implementación acotando el alcance, pero, generalmente, se encuentran con que ese alcance termina siendo un dolor de cabeza.

Entonces, ¿dónde está el problema?

El problema que se presenta cuando el alcance de la ISO 27001 no abarca a toda la organización es que el Sistema de Gestión de Seguridad de la Información (SGSI) tiene que interactuar con el mundo “exterior”. En ese contexto, el mundo exterior no son sólo los clientes, socios, proveedores, etc., sino también los departamentos de la organización que no están dentro del alcance definido. Puede parecer gracioso, pero un departamento que no está incluido en el alcance debe ser tratado de la misma forma que un proveedor externo.

Por ejemplo, si decide que sólo el departamento de TI esté dentro del alcance, y este departamento utiliza los servicios del sector Compras, el departamento de TI debe realizar la evaluación de riesgos sobre el sector Compras para identificar si existe algún riesgo para la información de la que es responsable el departamento de TI. Además, ambas áreas deben firmar acuerdos de términos y condiciones por los servicios brindados.

¿Por qué es necesario este gasto operativo? Póngase en el lugar del organismo de certificación: debe certificar que, dentro del alcance definido, usted puede administrar la información de forma segura, pero no puede verificar ninguno de los otros departamentos que están fuera del alcance. La única forma de manejar una situación de este tipo es tratando a esos departamentos como si fueran compañías externas. (Aclaración: a los auditores de certificación no les gusta un alcance acotado.)

Pero este no es todo el problema. A veces, un alcance muy acotado directamente no es posible porque no hay interacción con el mundo exterior. Por ejemplo, si los empleados de áreas que se encuentran dentro y fuera del alcance trabajan en la misma habitación, un alcance de este tipo es muy poco factible. Si ambos empleados utilizan la misma red local (sin división) y tienen acceso a diversos servicios de red, un alcance definido de esta forma, definitivamente, no es posible; no hay forma de que usted pueda controlar el flujo de información solamente dentro del ámbito del alcance que ha definido.

El punto aquí es que, a veces, resulta imposible acotar el alcance de su SGSI y, en la mayoría de los casos, le ocasionará costos operativos innecesarios. Por lo tanto, lo que inicialmente no parecía una buena idea podría ser, después de todo, la solución óptima: intente extender el alcance a toda la organización. Como regla general: si su organización tiene no más de unos pocos cientos de empleados y una o unas pocas ubicaciones, lo mejor sería que el SGSI cubra a toda la organización.

En cambio, si realmente no es posible incluir a toda la organización dentro del alcance de su SGSI, intente acotarlo a una unidad de la organización que sea suficientemente independiente. Intente resolver las relaciones con otras unidades que se encuentran afuera del alcance determinando sus servicios mediante documentos internos (políticas, procedimientos, etc.) que podrían utilizarse como “acuerdos”; de esta forma, podría documentar las obligaciones de esas unidades de la organización de una forma que sea útil para las actividades diarias.

Ahí lo tiene, ha resuelto el primer paso en la implementación de la norma ISO 27001.

También puede dar un vistazo a nuestro tutorial en vídeo Cómo definir y documentar el alcance del SGSI según ISO 27001 (es un vídeo comercial disponible para la venta).


Cinco consejos para realizar con éxito un Análisis de impactos en el negocio

ByDejan Kosutic on June 10, 2010

Probablemente se ha preguntado por qué tiene que realizar un análisis de impactos en el negocio (AIN) una vez que ya ha sido realizada la evaluación de riesgos. Ya identificó todos los riesgos, ¿verdad? Ya le demandó bastante tiempo analizar su empresa, entonces ¿por qué hacer otro análisis?

Bien, el objetivo del AIN es diferente. Para la continuidad del negocio todo tiene que ver con el tiempo; no importa que usted pueda recuperar sus actividades comerciales si no lo logra en un tiempo razonable. “Razonable” es lo que tiene que determinar el AIN. Su principal objetivo es encontrar cuál es el objetivo de tiempo de recuperación para cada actividad crítica de la organización.

Esta clase de análisis generalmente se toma muy ligeramente; la empresa, a menudo, no es consciente de que los malos resultados pueden generar gastos innecesarios o pueden crear una estrategia inadecuada de continuidad del negocio, aunque también se subestiman los esfuerzos necesarios para realizar un AIN.

Por lo tanto, estos son algunos consejos que harán que su análisis de impactos en el negocio sea más efectivo:

Tómelo como un (mini) proyecto. Defina quién será la persona responsable de su implementación y qué autoridad tendrá, defina el alcance, los objetivos y el período de tiempo.

Haga las tareas, prepare un buen cuestionario. Un cuestionario bien estructurado le ahorrará mucho tiempo y hará que los resultados sean más precisos. Las normas BS 25999-1 y BS 25999-2 le proporcionarán una noción bastante amplia de qué debe contener; entre otras cosas, usted tiene que identificar los impactos producidos por las interrupciones y tiene que determinar cómo estos impactos varían en el tiempo, identificar los recursos necesarios para la recuperación, etc. Una buena práctica es utilizar tanto preguntas cualitativas como cuantitativas para identificar los impactos.

Defina un criterio claro. Si sus entrevistados tienen que responder preguntas asignando valores, por ejemplo, de 1 a 5, asegúrese de explicar con exactitud qué significa cada una de estas cinco puntuaciones. No es extraño que el mismo evento sea evaluado como catastrófico por los empleados de menor nivel mientras que la alta gerencia evalúa su impacto como moderado.

Recolecte los datos a través de la interacción personal. Los mejores resultados se obtienen cuando alguien experto en continuidad del negocio realiza una entrevista con la persona responsable de una actividad crítica. De esa forma se clarifican muchas preguntas sin responder y se logran respuestas equilibradas. Si no es posible realizar las entrevistas, al menos organice un taller de trabajo con todos los participantes para que ellos puedan aclarar todas las dudas que tengan. Es decir, no les envíe simplemente los cuestionarios y les llame la atención si no se los devuelven a tiempo.

Determina los objetivos de tiempo de recuperación sólo después de que haya identificado todas las interdependencias. Por ejemplo, a través del cuestionario usted puede llegar a la conclusión de que para una actividad crítica “A” el período máximo tolerable de interrupción es de 2 días; sin embargo, el período máximo tolerable de interrupción para la actividad crítica “B” es 1 día y no se puede recuperar sin la ayuda de la actividad crítica “A”. Esto significa que el objetivo de tiempo de recuperación  para “A” será de 1 día en lugar de 2 días.

De acuerdo a mi experiencia, los resultados del AIN muchas veces son impensados; generalmente el objetivo de tiempo de recuperación es mayor de lo que se pensaba inicialmente y el AIN revela las dependencias de algunos recursos que se transforman, en realidad, en un punto único de falla. Pero lo mejor de todo, es que el análisis de impactos en el negocio es la forma más efectiva de hacer pensar a la gente sobre lo inesperado; generando esta concienciación, usted aumenta las posibilidades de supervivencia de su empresa.

También puede dar un vistazo a nuestro webinar Fundamentos de BS 25999-2 – Parte 1: Análisis del impacto en el negocio (es un curso de capacitación disponible para la venta).


Política de Seguridad de la Información: ¿qué nivel de detalle debería tener?

ByDejan Kosutic on May 26, 2010

Muy a menudo observo políticas de seguridad de la información redactadas en forma muy detallada y que intentan abarcar absolutamente todo, desde los objetivos estratégicos hasta cuántos dígitos numéricos debería contener una contraseña. El único problema con este tipo de políticas es que cuentan con 50 o más páginas y, en realidad, nadie las toma seriamente. Generalmente terminan siendo documentos artificiales cuyo único objetivo es satisfacer al auditor.

Pero, ¿por qué son tan difíciles de implementar ese tipo de políticas? Porque son demasiado ambiciosas; tratan de cubrir demasiados temas y están dirigidas a un amplio círculo de gente.

Por eso mismo es que la ISO 27001, la norma líder en seguridad de la información, define diferentes niveles de políticas de seguridad de la información:

  • Políticas de alto nivel (como la Política del sistema de gestión de seguridad de la información): estas políticas generalmente definen la intención, los objetivos y demás aspectos estratégicos.
  • Políticas detalladas: este tipo de políticas generalmente describe detalladamente un área específica de la seguridad de la información, con responsabilidades definidas, etc.

La norma ISO 27001 requiere que la Política de gestión de la seguridad de la información (SGSI), al ser el documento más importante, contenga lo siguiente: el marco para establecer objetivos, tomando en cuenta los diferentes requisitos y obligaciones, la alineación con la realidad de la organización respecto de la gestión estratégica del riesgo y el establecimiento de criterios de evaluación. Una política de estas características, en realidad, debería ser muy corta (tal vez una o dos páginas) porque tiene como objetivo principal que la alta gerencia puede controlar su SGSI.

Por otro lado, las políticas detalladas deben estar orientadas al uso operativo y enfocadas en un campo más acotado de actividades de seguridad. Algunos ejemplos de este tipo de políticas son: Política de clasificación, Política sobre el uso aceptado de los activos de información, Política de creación de copias de seguridad, Política de control de acceso, Política de contraseñas, Política de escritorio y pantalla despejados, Política de uso de redes, Política sobre equipos móviles, Política sobre el uso de controles criptográficos, etc. Nota: la norma ISO 27001 no requiere la implementación ni la documentación de todas estas políticas porque la decisión de si corresponden dichos controles, y con qué alcance, depende de los resultados de la evaluación de riesgos.

Como estas políticas deben incluir más detalles, generalmente son más largas; de hasta 10 páginas. Si fueran mucho más largas, sería muy difícil implementarlas y mantenerlas.

En otras palabras, la seguridad de la información es un tema muy complejo para poder definirlo en una única política: debería haber diferentes políticas sobre los diferentes aspectos del SGSI y para los diferentes “destinatarios”. Las organizaciones medianas, normalmente elaboran hasta quince políticas sobre para su SGSI.

Se podría discutir que esta cantidad de políticas no significa más que gastos operativos para una empresa. Seguramente estaría de acuerdo si tales políticas son redactadas sólo pensando en la auditoría de certificación; de esta forma sólo producirían más burocracia. Sin embargo, si una política es redactada con la intención de disminuir los riesgos, más que seguro demostrará su valor, tal vez no de inmediato sino probablemente en dos o tres años, disminuyendo la cantidad de incidentes.

También puede dar un vistazo a nuestro tutorial en vídeo Cómo redactar la Política del SGSI según ISO 27001 (es un vídeo comercial disponible para la venta).


Procedimientos documentados obligatorios requeridos por la norma ISO 27001

ByDejan Kosutic on May 04, 2010

Tal vez haya escuchado que la norma ISO 27001 requiere de muchos procedimientos, pero esto no es del todo verdadero. En realidad, la norma requiere de sólo cuatro procedimientos documentados: uno para el control de los documentos, uno para las auditorías internas de SGSI, uno para las medidas correctivas y uno para las medidas preventivas. El término “documentado” significa que “el procedimiento está establecido, documentado, implementado y es sostenido” (ISO/IEC 27001, 4.3.1 Nota 1).

Nota: en este artículo del blog no escribiré sobre otros documentos obligatorios como el Alcance del SGSI, la Política de SGSI, la Metodología de evaluación de riesgos, el Informe sobre la evaluación de riesgos, la Declaración de aplicabilidad, el Plan de tratamiento del riesgo, etc.; aquí me centraré solamente en los procedimientos.

El procedimiento para el control de la documentación (procedimiento de gestión de documentación) debe definir quién es el responsable de aprobar y verificar los documentos, cómo identificar los cambios y el estado de revisión, cómo distribuir los documentos, etc. En otras palabras, este procedimiento debe definir cómo funcionará el flujo vital (el flujo de documentos) de la organización.

El procedimiento para auditorías internas tiene que definir las responsabilidades sobre la planificación y realización de auditorías, cómo se informan los resultados y cómo se llevan los registros. Esto significa que las reglas principales para realizar la auditoría deben estar establecidas.

El procedimiento para medidas correctivas debe definir cómo se identifican los incumplimientos y sus causas, cómo se definen e implementan las acciones necesarias, qué registros se llevan y cómo se realiza la revisión de las medidas. El objetivo de este procedimiento es definir cómo cada medida correctiva debería eliminar la causa del incumplimiento para que no ocurra nuevamente.

El procedimiento para las medidas preventivas es casi el mismo que el procedimiento para las medidas correctivas; la única diferencia es que el primero tiene como objetivo eliminar la causa del incumplimiento para que directamente no se produzca. Debido a sus semejanzas, estos dos procedimientos generalmente se unifican en uno solo.

Pero, ¿por qué la norma ISO 27001 requiere procedimientos documentados que no están relacionados con la seguridad de la información mientras que los procedimientos de seguridad no son obligatorios?

La respuesta está en la evaluación de riesgos: la norma ISO 27001 sí le obliga a realizar la evaluación de riesgos, y cuando esta evaluación identifica determinados riesgos inaceptables, la norma requiere la implementación de un control de su Anexo A que disminuirá el o los riesgos. El control puede ser técnico (por ejemplo, un software antivirus para disminuir el riesgo de ataque de un software malicioso), pero también puede ser organizacional: implementar una política o procedimiento (por ejemplo, implementar un procedimiento de respaldo). Por lo tanto, los procedimientos se convierten en obligatorios sólo si la evaluación de riesgos identifica riesgos inaceptables.

Sin embargo, es importante mencionar que, a diferencia de los cuatro procedimientos obligatorios que deben ser documentados, los procedimientos que surgen de los controles del Anexo A no tienen que ser documentados. Depende de la organización evaluar si un procedimiento de este tipo debe documentarse o no.

Puede considerar a los cuatro procedimientos obligatorios como los pilares de su sistema de gestión (junto con la política de seguridad); una vez que están firmemente establecidos, puede comenzar a levantar las paredes de su casa. Esto es evidente cuando usted observa otros sistemas de gestión (los mismos cuatro procedimientos también allí son obligatorios) de las normas ISO 9001 (sistemas de gestión de calidad), ISO 14001 (sistemas de gestión del medio ambiente) y BS 25999-2 (sistemas de continuidad del negocio). De esta forma, usted puede utilizar esos procedimientos como la relación principal entre los diferentes sistemas de gestión si desea desarrollar el denominado “sistema integrado de gestión”.

También puede dar un vistazo a nuestro tutorial en vídeo Cómo redactar el Procedimiento para control de documentos según ISO 27001 e ISO 22301 (es un vídeo comercial disponible para la venta).