Buscar este blog

martes, 8 de noviembre de 2011

¿Cuál es el objetivo?

En días recientes, en una actividad académica, un compañero me interrogaba con emoción (como quien tiene una primicia) sobre la posibilidad de que una organización diseñara, implementara y certificara un modelo de seguridad de la información en cuestión de meses (dos para ser más exactos).
Al oír la interrogante plantee mi negativa de forma rápida, sintiendo un poco de culpa ya que no permití terminar el relato.
Posteriormente mi compañero terminaba su historia, comentándome que en un evento reciente una organización planteo como caso de éxito, exactamente lo cuestionado. Como ingeniero, comenté con incredulidad: ¡sin ver no creer!, y le pedí información de evidencia del mencionado evento.
La expectativa fue grande esperando la información para corroborar dicho anuncio, y así fue: Un caso de éxito en el cual se había implementado y certificado una organización en ISO 27001 en tan solo dos meses.
Luego de darle vueltas a la presentación (en la cual no encontré estrategia alguna para tan increíble logro) y de recordar un cuestionamiento similar en una lista de correo de seguridad, decidí escribir mi opinión (siempre con el ánimo de construir). Opinión no sobre el tema del tiempo de implementación y certificación (ya que para esto se necesitaría información como: alcance del modelo, ubicación geográfica, cultura organizacional y algunas respuestas más), que desde luego, si es plateado formalmente por una organización, merece toda mi credibilidad; sino en algo más de fondo que me parece más interesante y al cual se le puede extraer un tinte académico.
Esto es: ¿Cuál es el objetivo de un modelo de seguridad de la información?, esta pregunta es mi principal caballito de batalla hace un tiempo; ya que siento que en algunas ocasiones este norte se ha perdido. No es extraño hoy en día ver modelos de seguridad, sobre todo el descrito por la norma ISO/IEC 27001:2005[1], guiados desde un punto de vista meramente operativo[2] y basados casi en su totalidad por el afán de una documentación ejemplar dejando a un lado la pregunta básica: ¿funciona?; y ni hablar del objetivo último de un modelo de esta índole: La continuidad del negocio[3].
Ahora, a este objetivo final, debemos adicionar su esencia: Habilitar el negocio (entre otras mediante el apoyo de los objetivos estratégicos del negocio, ¡no operativos!), generar valor al mismo y por  ende a los stakeholders, asegurar los procesos, mejorar continuamente y lo mejor de todo: debemos medirlo y demostrar que estamos logrando éstos objetivos[4].
Así detallando lo anterior un poco más, ¿Cuáles serías los objetivos, y cuáles no, de algunas de las principales actividades de un modelo de seguridad de la información como es el de la norma ISO/IEC 27001:2005?, mirémoslo de manera resumida:

Política de Seguridad de la Información:
·         El no objetivo: No es un objetivo tener un documento, llamado política; ni un libro gordo de Petete con ciento cincuenta páginas de políticas de segundo y tercer nivel, para llenar un ítem de una lista de chequeo de implementación. He llegado a presenciar posiciones tan erradas, desde mi perspectiva desde luego, que es más importante la forma y el nombre de este documento que su mismo contenido, implementación y validación de cumplimiento; incluso llegando a pretender que una empresa cambie toda su estructura documental por un aspecto de forma en éste documento.  

·         El objetivo: El objetivo de la política es plantear el norte del modelo de seguridad y los objetivos del mismo, y ésto se debe poder demostrar. Así, y ya que un modelo de seguridad debe su vida a la empresa[5] (ya que no se concibe su existencia sin el negocio que lo necesita), este documento debe estar alineado con las políticas de la organización y los objetivos deben apoyar de manera clara los objetivos estratégicos de la misma. En conclusión, las políticas retóricas planteadas a través de formas encontradas en internet, donde se plantea “una garantía de seguridad universal”, no sirven; primero porque no desarrollan objetivamente algo y segundo porque no se ha entrado a analizar lo que necesita la empresa a la luz de su esencia de negocio y su visión. En este punto, aunque está dicho entre líneas, quiero recalcar lo siguiente porque lo considero importante: La política del modelo de seguridad, no es la política de tecnología de la información, y mucho menos la política de seguridad informática que maneja éste mismo proceso, ya que este es sólo un proceso en los cuales el modelo de seguridad tiene injerencia (esta sería una de las muchas razones que existen).

Gestión de Activos y Riesgos
·         El no objetivo: No es misterio para implementadores de este modelo, que estas actividades son actividades que demandan un tiempo considerable. Pero el objetivo de esta actividad no es tener formatos y formatos con cantidades impresionantes de información, ni tener una metodología en particular. Peor aún, a diferencia de lo planteado en muchos escenarios donde le dan una importancia titánica a estas actividades, no son el objetivo de un modelo de seguridad. Estas actividades son un medio, no el fin. Son las herramientas principales para la toma de decisiones en los modelos de seguridad, pero el trabajo apenas inicia.  En ocasiones, algunos encargados de modelos al ser cuestionados por esta actividad, despliegan una cantidad de información que le daría envidia a la mismísima enciclopedia Larousse; pero a las preguntas: ¿y bueno, que has realizado con esta información?, ¿Qué decisiones se han tomado con esto?, ¿Cómo has protegido estos activos?, ¿Cuáles son los activos más críticos?, ¿cómo has minimizado los niveles de riegos?, ¿cómo has manejado el costo-beneficio a la hora de implementar los controles o medidas?, ¿el modelo ha protegido los activos de acuerdo a lo requerido por los procesos?; no hay más que una mirada al techo.

·         El objetivo: Blindar a los procesos protegiendo sus activos, llevando a un nivel aceptado por la organización, los niveles de riesgo.  Creo que es claro, saber cuáles son los activos de los procesos, cuáles de estos son críticos, quienes son sus dueños[6], valorarlos para así tratarlos de acuerdo a su importancia para el proceso y para la empresa. Tener certeza que los activos de los procesos se están protegiendo de acuerdo a lo necesario, ¡ni un poco más ni un poco menos!. Creo que el objetivo llega a ser tan difuso para algunas organizaciones que se crean indicadores de gestión sobre la realización o no del inventario de activos y del análisis de riesgos por parte de los procesos, cuando lo que se debe medir es el nivel de seguridad (asociado también al nivel de inseguridad[7]) de los activos y sus procesos dueños.

Proceso de Gestión de Incidentes:
·         El no objetivo: Este es uno de mis favoritos (el segundo para ser precisos, ya les hablaré del primero)  ya que es uno de los que he encontrado los mayores problemas en la claridad del objetivo. El objetivo final no es tener un proceso documentando, incluso ni implementado. El objetivo no es llevar estadísticas de cuantos incidentes se presentaron en un lapso de tiempo, ni tener un comité de gestión de incidentes, ni hacer presentaciones a la gerencia o a los procesos dueños de los activos sobre los incidentes.  He conocido este tipo de procesos en los cuales toda la documentación es llevada de forma rigurosa, tanto del proceso, como de cada una de las actividades e incidentes sucedidos; muy bien por ellos, pero nuevamente a la pregunta: ¿Qué has hecho con esta información?, ¿se han implementado medidas para que estos incidentes no se vuelvan a presentar?, así esto me parece un saludo a la bandera.

·         El objetivo: detectar y contener los incidentes de seguridad; analizarlos y lo más importante: ¡tomar medidas para que los incidentes no vuelvan a ocurrir!, éste es el verdadero objetivo. Éste proceso es uno de los procesos principales para retroalimentar el modelo y demostrar que está funcionando; que pudieron existir errores, incidentes, pero se tomaron medidas para que no vuelvan a ocurrir. Respuestas como las siguientes no deben presentarse en un proceso de gestión de incidentes efectivo:

A: La red no estuvo disponible por cuatro días la semana anterior.
B: ¿Eso no sucedió también hace un mes?
A: Ahhh  ¡pero era un gusano diferente!
O tal vez,
A: Tuvimos hoy el ingreso de una persona no autorizada a las instalaciones por la puerta la principal”
B: Pero eso ya había sucedido.
A: nooooo, ¡el semestre pasado fue por la puerta número dos!

Proceso de Sensibilización de Seguridad de la Información:
·         El no objetivo: Capacitar o sensibilizar. En este instante muchos lectores dirán, este tipo está loco, ¿entonces qué es?, ¿hacer pan? Este es mi favorito número uno, porque esto lo veo no sólo en modelos de seguridad, sino en el diario vivir. Veo entes gastando (no invirtiendo) grandes sumas de dinero en campañas de sensibilización, y plantean su éxito con indicadores como: el cubrimiento: “hemos llegado a dos millones y medio de personas”; monto gastado: “esta administración invirtió tantos millones de pesos en campañas de sensibilización contra el…..”; recordación: “es una campaña que ha sido recordada por muchas generaciones” y a mi pregunta: ¿las personas cambiaron su comportamiento?, ¿quedaron realmente sensibilizadas?, otra mirada al cielo.

·         El objetivo: Evitar que los riesgos sobre los activos, que tienen vulnerabilidades relacionadas con los recursos humanos se materialicen. ¿Cómo se logra esto?,  logrando un cambio en el comportamiento de las personas, no sometiéndolas a capacitaciones y actividades de sensibilización interminables, he ahí el meollo del asunto. Hay que implementar acciones que garanticen un cambio en el comportamiento, y ésto es lo que hay que medir. A los niveles estratégicos de la empresa no le interesan el número de capacitaciones, ni la cantidad de personas en un proceso de sensibilización o el dinero gastado en ésto, lo importante es: si las personas se están comportando como queremos o necesitamos que se comporten respecto a la seguridad.


Lo anterior fue un pequeño resumen de algunas actividades de un modelo de seguridad como el de la norma ISO/IEC 27001 (y algunos más), que desarrollo para plantear mi punto de vista. Así considero que la falencia puede estar en que no tenemos claro el objetivo de estos modelos, y en muchas implementaciones se peca en darle la máxima importancia al aspecto documental, dejando a un lado el cumplimiento de los objetivos, entre estos el apoyo al negocio; perspectiva que debemos mejorar tanto implementadores como auditores.


[1] Esta misma impresión la he desarrollado con sistemas de gestión similares a la 27001:9001, 14001, 18001,  etc.
[2] Sin una estrategia clara y mucho menos orientada por el negocio.
[3] Continuidad del negocio vista desde la perspectiva de la seguridad de los procesos y sus activos.
[4] Esto puede sonar muy teórico pero es totalmente realizable; lo ampliaré en un artículo próximo.
[5] Entiéndase también como el core del negocio.
[6] Dueños de acuerdo a la norma ISO/IEC 27001.2005
[7] Concepto planteado en: Inseguridad informática: Un concepto dual en seguridad informática. Jeimy J. Cano. http://www.acis.org.co/fileadmin/inseg-inf.pdf

4 comentarios:

  1. Richard, excelente post. ¿Hay forma de seguir el blog vía RSS?

    ResponderEliminar
  2. ¿qué más viejo?, sabes que ni idea, no sé si se puede, voy a mirar. Saludos.

    ResponderEliminar
  3. Ingeniero muy interesante su aporte, espero no nos haya olvidado en el proceso de elaboración del modelo!!!

    ResponderEliminar
  4. Quisiera poder aprender mediante estas normas ISO mas formas de mejorar la seguridad y aplicarla.

    ResponderEliminar