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
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.
2 comentarios:
Interesante reflexión, no obstante quizá en ocasiones caemos en mapear las buenas prácticas e intentamos encajar en algún sitio nuestros procesos.
Yo creo que los estándares están para interpretarlos y/o adaptarlos a nuestras necesidades.
Por ejemplo y siguiendo tu caso, en la segunda fase: Detección y notificación, me cuesta creer que tengo que pasar por aquí y el registro para el análisis, ya que este determinará muchas cosas, ¿aplica? ¿que criticidad tiene?
....todo este análisis de riesgos debe ser ejecutado por un analista de seguridad apoyado en la gestión de riesgos internos, por ejemplo realizando un CVSS donde pueda ajustar el impacto de la vulnerabilidad en base al CIA rating que tiene su activo afectado dentro de la organización.
Como todo proceso hay que buscar ser eficiente y para ello puedes usar grupos de activos, niveles de riesgo comunes, etc; de esta forma podemos ser más ágiles en este proceso que aunque ITIL, Cobit o la ISO 27001 diga lo que diga al final las reglas del juego tienen que ser aceptadas por el negocio (apetito de riesgo), comunicadas y consensuadas con los administradores (custodios) y ponerlas en marcha.
Un saludo,
Hola, Gonzalo,
Las dos primeras fases del ciclo de vida de la vulnerabilidad son requisito "per se", ya que tiene que nacer (aparición) y que alguien la descubra (detección) para que se pueda empezar a gestionar. Y por supuesto, para que nosotros la gestionemos alguien debe notificarlo (el propio descubridor, cualquier suscripción a un servicio de advisory, etc.). Por lo tanto, la gestión que hagamos de cualquier vulnerabilidad, en relación a nuestra organización, comienza por el registro.
Con el post no quiero decir que deba ser el proceso de gestión de eventos quien gestione el ciclo completo de la vulnerabilidad, sino que es un proceso muy apropiado para la detección / notificación / registro, y que además enlaza con los procesos que se pueden encargar de la gestión de las fases posteriores.
Por otro lado, un error muy habitual es ligar procesos a grupos concretos de personas, cuando deben ser dos visiones independientes. Nadie dice que en la gestión de problemas (o de eventos) no deba participar personal del "área de seguridad", ni tampoco que ése "área" sólo pueda desarrollar el proceso de seguridad. No deberíamos confundir (ni ligar) la estructura orgánica (organigrama) de una organización con la funcional (procesos).
El objetivo del post es proponer a empresas que utilicen ITIL como modelo de gestión por procesos (que cada vez son más) la forma de encajar la seguridad dentro de esos procesos, ya que ITIL tiene una definición de la seguridad (y una forma de resolverla) excesivamente limitada, para mi gusto. Eso no quiere decir que no pueda haber otros modelos, sino que el propuesto por ITIL es perfectamente válido para implementarlo (incluso sin necesidad de "adaptaciones", ya que los conceptos subyacentes son directamente aplicables desde el punto de vista de la seguridad).
Publicar un comentario