24 febrero 2014

El Desafío O-ISM3

La mayor parte de los profesionales de seguridad de la información, especialmente consultores y aquellos que tienen certificaciones de seguridad que no nombraré, así como numerosos estándares consideran que los conceptos de Confidencialidad, Integridad y Disponibilidad resumen adecuadamente los objetivos fundamentales de la seguridad de la información. Estos conceptos se utilizan en auditorias, análisis de riesgos, gestión y desarrollo de nuevos estándares. Ahora bien, estos conceptos presentan varios problemas que están sin resolver: 
  • Son incompletos. Hay quien complementa los tres conceptos mencionados con otros como. Posesion, Utilidad, Riesgo, Autenticación, Autorización, Auditoría, No-Repudio y Accountability. Esto implica que según qué cóctel de complemento haya elegido la persona o empresa que realiza una tarea relacionada con seguridad de la información, esta se realizará de una forma distinta (llamo a esto una variabilidad elevada). Puede que alguien no considere esto un problema. Pensar que según el médico que me toque me van a diagnosticar algo distinto, y que según el arquitecto que me toque, el edificio donde vivo durará cien años o se caerá mañana, no me parece una situación deseable. Cuando algo es realmente importante, es necesario que el trabajo se realice de la forma más consistente posible. 
  • Son ambiguos. Muchos profesionales e incluso estandares dan definiciones ligeramente distintas de Confidencialidad, Integridad y Disponibilidad. Esto aumenta la variabilidad, lo que no es deseable. 
  • No están definidos operacionalmente. Una definición operacional define un concepto mediante el proceso que se utiliza para medirlo, sin intentar definir su esencia. Al no ser definiciones operacionales, no es posible definir otros conceptos útiles como Amenazas, Incidentes, Vulnerabilidad o Debilidad en términos de Confidencialidad, Integridad y Disponibilidad, lo que incrementa la variabilidad. He visto numerosos debates en los que profesionales con años de experiencia no conseguían llegar a una acuerdo acerca de qué es un Incidente o una Vulnerabilidad. Me pregunto como puedes gestionar algo si ni siquiera lo puedes definir. Y no, una defnicion personal que sobre la que no hay un acuerdo amplio, no es válida. 
  • No tienen unidades de medida. Esto impide de forma cuantitativa la seguridad de la información. Sin medidas cuantitativas es imposible la optimización de recursos. 
El uso de conceptos ambiguos, incompletos y que no están definidos operacionalmente crea una serie de problemas para la gestión de la seguridad de la información. La comunicación entre especialistas y el negocio es difícil. Demostrar el valor que aporta al negocio la seguridad de la información es difícil. En general nos complican la vida más que nos la simplifican. Se desperdicia tiempo, se invierte donde no tiene sentido invertir, y se deja de invertir donde se debería.

Llevo varios años hablando en artículos y presentaciones sobre esto, recientemente en la NoConName y en la reunión de la ISACA Madrid, pero quizá está crítica no tiene sentido o no tiene valor, porque no he escuchado comentarios apoyándola.

Creo que las necesidades de seguridad de un negocio no tienen porque coincidir con las marcadas por ningún estándar de cumplimiento. Mis opiniones sobre el cumplimiento normativo mejor las expresaré en otra ocasión.

Inspirado por el James Randi Foundation Challenge, que ofrece un millón de dólares a quien pruebe tener capacidades paranormales, he decidido crear el Desafío O-ISM3. Con este desafío pretendo demostrar, mediante un caso práctico, que confidencialidad, integridad y disponibilidad no son imprescindibles, y de hecho ni siquiera son necesarias para entender las necesidades de seguridad de una organización.

Afortunadamente existe una alternativa, que es la utilización de conceptos definidos operacionalmente, que no son ambiguos, no son incompletos y tienen unidades de medida Estos conceptos son los "objetivos de seguridad" de O-ISM3, un estándar que vengo promoviendo desde hace años.

Os animo a difundir estas ideas, entrar en el debate y participar en el Desafío O-ISM3.

Contribución gracias a Vicente Aceituno

5 comments :

holis dijo...

Jolines y el milloncito esta ahi?. Teclado en ingles y no encuentro los acentos.

prubio dijo...

Hola,
un análisis de CIA no sirve para gestionar los riesgos. Por supuesto que estos tres vectores (C-I-A) son ambiguos, incompletos, etc.... pero es que no deben servir para nada más que para apoyar al propietario de la información en la decisión de cuán importante es su importancia (su criticidad, por ejemplo en términos de impacto en el negocio).
Gestionar el riesgo además de identificar el CIA añade la necesidad de detectar amenazas y vulnerabilidades, revisar incidentes, escenarios, lecciones aprendidas, conocer normas y estándares, ciclos adecuados de desarollo/mantenimiento, .... y un poco de lo que se da en llamar "expert judgement" o "consultoría" (con todo lo incompleto, ambiguo y difuso del término ;-)

rvasquezgt dijo...

Al fin encuentro una comunidad donde no se evangeliza la C.I.A. la cual lo repito muchas veces en mis cuentas de medios sociales, seguridad no es medir el riesgo, no es un conjunto de normas que disminuyen el riesgo y me toca pelear en mi pais para que la gente cambie eso pero al final pierdo ante grandes "nombres" que promueven el C.I.A. voy a explorar el O-ISM3, saludos desde Guatemala!

Héctor dijo...

Hola, muy interesante el tema y disculpen pero para mí los conceptos están claros, creo que el gran desafío es como aplicarlos.

Los términos Posesión, Utilidad y Riesgos están asociados más al proceso de Gestión de Riesgos que a la evaluación de atributos de seguridad de la información. Posesión: está referido al propietario del activo y se define cuando se elabora el Inventario de activos de TI, antes de realizar la evaluación de sus riesgos y sus controles mitigantes, Utilidad: como foco de la seguridad de la información es fundamental identificar el uso del dato y en base a esto determinar la sensibilidad/criticidad del impacto a los procesos de negocio ante un eventual incidente que pudiere ocurrir sobre el dato.

Los conceptos de autenticación, autorización, no-repudio, auditoría y accountability pueden asociarse a los conceptos de C-I-D. Autenticación y Autorización son controles que están referidos con el atributo de confidencialidad de la información, de hecho una debilidad en un esquema de autenticación y/o autorización presentará un impacto sobre la confidencialidad de la información. El control de No-repudio también es un mitigante para preservar la integridad y/o confidencialidad de la información, ya que evita que el emisor o el receptor nieguen la transmisión de un mensaje. Auditoría (o que un sistema genere un log y que “alguien lo revise”) y Accountability (rendición de cuentas) son controles detectivos sobre posibles incidentes que atenten a la C-I-D de la información.

A mí los términos C-I-D me resultan precisos teniendo en cuenta las definiciones de la norma de la ISO 27001:2005, luego pueden existir tantas diferencias como las que se quieran asignar. Igualmente es más importante que significa para uno mismo y como esté significado se llega a consensuar con las partes interesadas de la organización (Gestión de Riesgos, Seguridad de la Información, Sistemas y Propietarios de activos como mínimo).

En general los modelos no tienen unidades de medida, porque son de aplicación amplia para distintos tipos de negocio (financiero, industrial, etc.). Igualmente existen algunos ejemplos de métricas en Cobit 4.1 y en ISO 27004 que uno puede ampliar. Por supuesto, más allá de las métricas que permiten determinar estatus de los controles inherentes a la seguridad, también deberían considerarse las métricas sobre los requisitos que regulan el negocio y las condiciones de seguridad establecidas en la demanda de nuevos procesos de negocio con la solución de TI relacionada.


También es cierto que no están definidas las métricas operacionales que uno debe aplicar y este es el desafío. Para la gestión de la seguridad (por no decir el gobierno) uno debería definir las metas/objetivos a lograr y con qué indicadores/métricas sustentarlos. Aquí aparecen en juego los KGI/KPI Indicadores claves de objetivo/desempeño para saber cuál es la brecha sobre el objetivo deseado.

Creo que ya pasó la época en que no existía un acuerdo de lo que significa incidente y vulnerabilidad. Para simplificar, un incidente de seguridad podría definirse como cualquier hecho o evento que se estima que podría afectar a la seguridad personal o de información y vulnerabilidad son puntos débiles que permiten la materialización de una
amenaza. El punto es que se deben realizar relevamientos para determinar cuáles son los aspectos débiles, pero por dónde comienzo?, por los activos que sustentan los procesos y datos más críticos.

Finalmente considero que no es el médico o el arquitecto que le toca sino el que se elige; y si no tengo la posibilidad de elegirlo trataré de adaptarlo a mi necesidad. En definitiva, en este sentido uno es el cliente y debo satisfacerme como tal. De hecho no existen panaceas, pero si los conceptos C-I-D son definiciones básicas para tomar y adecuarlas a nuestro necesidad; o en otros términos bajar lo escrito a la tierra.

titoclasi dijo...

Héctor, totalmente de acuerdo contigo.
Ya sólo falta que legisladores y el resto de entidades que por una u otra razón imponen a las empresas cumplimientos normativos anticuados e ineficaces desde el punto de vista de la seguridad se den cuenta de lo que dices.
Aún estoy por ver una auditoría oficial (no hablo de las voluntarias tipo ISO 27000) en la que se vigile y audite que la empresa esté centrada en llevar la seguridad con un método de gestión de riesgos adecuado, centrado en un buen análisis de amenazas, vulnerabilidades e impactos (que no son iguales para cada empresa) y que persiga la implantación de medidas de mitigación priorizadas por el valor en el negocio del proceso analizado.
En su lugar se suele valorar el nivel de seguridad atendiendo exclusivamente al nivel de implantación de medidas de seguridad que en muchos casos, per se, son obsoletas y/o ineficaces y distraen tiempo y recursos que impiden llegar al objetivo anterior.
Me hace mucha gracia cuando en las auditorías te preguntan ¿tiene usted antivirus en sus equipos? (la pregunta hasta ofende, pues claro, incluso a pesar de su ineficacia real los tengo) y sin embargo nunca te preguntan ¿a pensado usted como evitar qué el fichero x, dada su importancia para la empresa, acabe en Internet enviado desde un cliente troyanizado? ¿qué haría usted llegado el caso?.
Por cierto, cuando preguntan por los antivirus siempre me quedo esperando las siguientes preguntas: ¿cómo y con qué frecuencia los actualiza? ¿qué hace cuando se detecta un virus?,...
cri, cri, cri ...