Gestión ITILizada de vulnerabilidades

Existen multitud de referencias para la gestión de la seguridad. No obstante, dicha gestión acaba quedando traducida, habitualmente, a dos ámbitos complementarios: gestión de riesgos + gestión de incidentes de seguridad. Una simplificación que en la mayor parte de las organizaciones puede resultar suficiente, pero que a veces se pude quedar un poco corta. ¿Cómo aplica ese planteamiento para la gestión de vulnerabilidades?

El modelo de gestión de riesgos "clásico" es un modelo estático. Analizamos los riesgos una vez, y no revisamos el análisis hasta pasado un ciclo completo del proceso (normalmente, anual). Sin embargo, la gestión de vulnerabilidades es algo mucho más dinámico. De ocurrencia puntual, pero que al cabo de un mes en general tendremos que aplicar. Un ciclo excesivamente corto para el análisis de riesgos.

El modelo ITIL de gestión de incidentes aplicado a las vulnerabilidades tiene algunas dificultades. Para empezar no encaja con el planteamiento clásico (ITIL) de resolución de incidentes igual a restablecimiento del servicio, ya que no hay servicio degradado. Una vulnerabilidad no afecta al SLA del servicio, al menos no directamente. No obstante, los principios de la gestión de problemas sí que parecen encajar con la gestión que requieren las vulnerabilidades. ¿Cuál podría ser el detonante para este proceso?

Otros modelos de referencia tampoco terminan de encajar. Todos los que tienen implantados sistemas de gestión conocen la sistemática aplicable a las acciones preventivas, pero... ¿Es suficientemente ágil ese planteamiento para ser aplicado en relación a las vulnerabilidades técnicas? Teniendo en cuenta que ambas metodologías de gestión suelen quedar en manos de departamentos diferentes, tampoco parece una solución óptima.

Mi propuesta para la gestión de vulnerabilidades es hacer uso del proceso ITIL v3 de Gestión de Eventos. Este es un proceso en general infrautilizado, que se suele limitar a la monitorización de sistemas. Sin embargo, es un proceso que puede dar mucho más de si, tanto desde el punto de vista de la correlación de logs como desde el punto de vista de la gestión de vulnerabilidades.

Para empezar, la gestión de eventos es un proceso "interno" de un departamento TIC. Tiene vocación preventiva, y dos de sus principales salidas van hacia la gestión de problemas y la gestión de cambios. Por lo tanto, entre el propio proceso y aquellos con los que se relaciona se puede cubrir el ciclo completo de gestión de la vulnerabilidad:

• Aparición --> Detección y Notificación --> Registro --> Análisis --> Aplicación de WorkAround --> Análisis de causa --> Parcheo --> Cierre

Además, desde el punto de vista de proceso con uso intensivo de soluciones tecnológicas, la gestión de eventos puede ser un proceso muy apropiado para ser revalorizado desde el punto de vista de la seguridad. Por un lado, es el proceso más apropiado para la introducción de soluciones de correlación de logs y SIEM. Por otro lado, también es una tentación la introducción de soluciones de auditoría automatizada de red, que refuercen el apartado de gestión de vulnerabilidades y se integren con las herramientas de gestión de incidentes y problemas.

En definitiva, la gestión de vulnerabilidades es un proceso peculiar, para el que los modelos de gestión más habituales no terminan de encajar, pero que puede encontrar en los procesos de ITIL v3 el formato más apropiado para introducirse de forma nativa en los procesos de operación TIC de cualquier organización.

A vosotros, qué os parece la propuesta? ¿Qué ventajas e inconvenientes le veis? Estaré encantado de leer vuestros comentarios.

Publicada la nueva ISO 22301:2012

El pasado 15 de Mayo se llevó a cabo la publicación oficial de la nueva ISO 22301:2012, el esperado estándar que recoge los requisitos que debe cumplir un sistema de gestión de la continuidad del negocio. Esta norma, que viene a ser la evolución internacional de las normas BS 25999 -2:2007 / UNE 71599-1:2010, determina los requisitos que debe cumplir cualquier organización que quiera desarrollar un sistema capaz de gestionar de manera eficaz incidentes "graves" capaces de poner en riesgo su continuidad operativa.

La norma desarrolla, a lo largo de 7 apartados (aparte de los clásicos de introducción, referencias y terminología), los requisitos que debe cumplir un SGCN (Sistema de Gestión de la Continuidad del Negocio) en cada uno de sus ámbitos (contexto de la organización -alcance-, liderazgo -responsabilidades de la dirección-, planificación, soporte -designación de recursos-, operación, evaluación y mejora). Contiene todos los elementos de cualquier Sistema de Gestión ISO, aunque se echa de menos una mejor alineación con el marco de referencia desarrollado por ISO para los sistemas de gestión, al que sí se aproximan otras normas más veteranas.

Aunque no deja de ser una buena noticia, le sigo viendo un problema de base. ¿Podemos hablar de continuidad de negocio cuando sólo nos centramos en gestionar riesgos operativos? ¿Qué ocurre con otro tipo de riesgos (financieros, de mercado, regulatorios) que también son parte del negocio? Desde mi punto de vista, creo que el alcance de esta norma es, en sí mismo, su principal hándicap: demasiado grande para las consultoras de TI (que son principalmente las que han impulsado los SGCN hasta la fecha) y demasiado pequeño para las empresas de consultoría estratégica, que centran su actividad en otro tipo de riesgos. Pero los que realmente tienen que asumir los principios de este nuevo estándar son las empresas en general. ¿Cómo lo acogerán? ¿Verán claras sus ventajas? ¿O seguirán sin tenerlo claro? Lo veremos con el paso del tiempo...

Seguridad, Transparencia y ENS

Hace casi dos años que en este mismo blog hablaba del borrador de la Ley de Transparencia. Desde entonces esta Ley ha sufrido muchos cambios, incluyendo varios borradores y un cambio de gobierno, hasta llegar a la situación actual (aunque en este momento el texto todavía no está actualizado con la última versión). Un anteproyecto de Ley que ha suscitado bastante polémica, y que probablemente lo siga haciendo durante su tramitación.

No obstante, mi objetivo en este post no es criticar el contenido del anteproyecto, sino analizar la estrecha relación entre Seguridad y Transparencia, y ver las consecuencias prácticas que puede tener esta Ley.

Por un lado, tenemos que tener en cuenta que el concepto de "transparencia" es precisamente el complementario al de "confidencialidad". Estamos hablando de lo mismo desde el punto de vista contrario. Por lo tanto, es necesario tener en cuenta que es una Ley que regula, en ciertos aspectos, la seguridad de la información de las Administraciones Públicas (os suena a algo relacionado con el ENS?).

Además, el concepto de transparencia también tiene cierta relación con la necesidad de garantizar la autenticidad de dicha información publicada, su integridad o su disponibilidad (aspectos que, de hecho, cobran mayor importancia cuanto más se deba permitir el acceso a dicha información).

Si profundizamos en la citada Ley, podemos ver cómo hace referencia a la información que debe ser pública (artículos 3 - 6 y 9), la que debe ser "publicable", con ciertas restricciones en su publicación (artículos 10-13) y la que no debe ser publicada (artículo 9). Establece, por tanto, 3 niveles de clasificación desde el punto de vista de la confidencialidad de la información, que podemos entender como 3 escalones de confidencialidad (podemos hablar de confidencialidad Baja/Media/alta?).

Bajo este punto de vista, creo que la relación con el Esquema Nacional de Seguridad es obvia. Estamos frente a una regulación con caracter de Ley, y que por tanto puede incluir este tipo de directrices (por lo que tengo entendido, el ENS, por ser un Real Decreto, y por tanto de inferior rango, no podía). Sin embargo, echo de menos alguna relación más específica con dicha regulación, y sobre todo una mejor explicación de los tipos de información que deben ser clasificados en cada uno de los ámbitos. Soy consciente de cierta deformación profesional a la hora de estructurar contenidos (un ingeniero suele tener la mente más cuadriculada que un jurista), pero... No hubiera sido conveniente establecer una "tabla" un poco más clara de los diferentes tipos de información que puede tener una Administración Pública y la clasificación asociada en cada caso? Y lo que es más importante... Será el texto actual una referencia válida para su utilización práctica por parte de quienes tienen que clasificar cada información? No lo tengo nada claro...

Securmatica 2012

La semana pasada estuve en el congreso Securmática 2012. No pude asistir al congreso completo, aunque las pinceladas que me llevé creo que pueden ser suficientes para hacer un mini-diagnóstico del sector:

• Se está poniendo de moda el término ciberseguridad, aunque no dejan de ser los mismos conceptos de siempre puestos al día.
• El cumplimiento legal cada vez preocupa más a la empresa privada, que se ve cada vez más presionada pero sigue sin considerar que pueda ser aprovechado como ventaja competitiva.
• Sigue existiendo una pugna filosófica entre los partidarios de la seguridad por oscuridad y los defensores del full-disclosure, que tengo la sospecha que no es tan grave a nivel práctico (una vez que se considera el dinero dentro de la ecuación).
• El precio va a ser un fuerte impulsor de los servicios cloud y el software libre aplicado a la seguridad durante los próximos años... Pero muchos no van a conocer el significado real de lo que están comprando.
• La gestión de vulnerabilidades puede empezar a ser un nicho de negocio en sí mismo, con múltiples variantes y posibilidades.
• Todo el mundo empieza a vender inteligencia en seguridad... y yo no veo mucho más que correlación de eventos.

En definitiva, tengo la sensación de que el sector ha invertido mucho en marketing en los últimos años, reinventando nombres para los principios de toda la vida, pero sin que haya habido un salto diferencial en la evolución real. No obstante, hay que reconocer que los nuevos términos están sirviendo para vender más seguridad a más gente, que en el fondo es el objetivo de todo esto. Por tanto... bienvenido sea el medio, si se acaba consiguiendo el fin.

Y para no perder la ola, yo también aproveché el congreso para estrenar mi nueva cuenta de twitter @JosebaEnjuto. Así que si quieres seguirme... Ahora también estoy en twitter!