Modelos para la gestion de incidentes de seguridad

A raíz de unos comentarios en relación al último post sobre incidentes de seguridad se me ha ocurrido extender un poco más mi respuesta en forma de post. La idea es, sencillamente, presentar un par de modelos que pueden ser utilizados para la gestión de incidentes de seguridad.

El primero de ellos, como sugieren en los citados comentarios, es seguir el modelo de gestión de problemas de ITIL para llevar a cabo la gestión de incidentes de seguridad. En dicho modelo se habla de monitorizar y ejecutar revisiones preventivas en busca de problemas, que en el ámbito de los incidentes de seguridad se podrían asimilar a las auditorías (técnicas de seguridad y la monitorización de los sistemas de seguridad, pudiendo llegar a considerar incluso las consolas SIM. Por otra parte, ya dentro de la gestión reactiva, la gestión de problemas en sí misma habla de registrar los problemas, diagnosticarlos, identificar las causas del mismo (convirtiendo el problema en un error conocido), definir la solución más apropiada y generar la RFC (petición de cambio) correspondiente. Si sustituimos el término problema por el de incidente de seguridad, el modelo de gestión es perfectamente válido.

El segundo de los modelos que se suele utilizar para la gestión de incidentes de seguridad es el correspondiente a la gestión de no conformidades y acciones correctivas asociadas. Podemos sustituir el incumplimiento de las normas y/o procedimientos establecidos (la no conformidad) por la ruptura de las condiciones de seguridad establecidas (el incidente de seguridad), y a partir de ahí seguir la sistemática de registro y análisis estándar para las no conformidades aplicada al mismo. A partir de la no conformidad se definirán alas cciones correctivas necesarias para resolver la no conformidad, que en nuestro caso supondría identificar las acciones a acometer para solucionar la causa del incidente de seguridad.

Como se puede ver, ambos modelos son equivalentes, y perfectamente válidos para la gestión de incidentes de seguridad. No obstante, tienen algunos matices que no está de más tener en cuenta, por si las moscas.

En primer lugar, la gestión de problemas según ITIL tiene un carácter técnico. Esto supone que los incidentes de seguridad asociados a las personas (y muchos del ámbito de la confidencialidad lo son) van a tener dificultades para ajustarse al modelo. Por otra parte, también es necesario tener en cuenta que la gestión de problemas requiere de la gestión de incidentes y la gestión de cambios y versiones para completar el ciclo de gestión, ya que los incidentes de seguridad requieren tanto de la corrección instantánea de la situación que provoca el incidente (gestión de incidentes) como de la aplicación efectiva de la corrección (gestión de cambios y versiones) para poder considerar que el incidente de seguridad está cerrado. Y por último es necesario considerar, dentro de la gestión de cambios, que el carácter eminentemente operativo que subyace en este proceso puede ser insuficiente para tratar determinados incidentes de seguridad cuyas causas y/o consecuencias puedan llegar a ser de carácter estratégico.

El segundo modelo es complementario al anterior. Es un modelo de caracter más estratégico, de modo que tienen mayor cabida situaciones de carácter menos técnico u operativo, pero al mismo tiempo es un modelo mucho más vago y menos detallado. Tiene la ventaja de que, al exigir la participación activa de la dirección, las decisiones que se adopten van a contar con su "bendición", lo que desde el punto de vista de recursos y prioridades puede ser importante. No obstante, si restringimos el modelo a la gestión de no conformidades y acciones correctivas también sería un modelo incompleto, y para terminar de completarlo deberíamos considerar también ltanto a gestión de acciones preventivas (en relación a las debilidades de seguridad) como la realización de auditorías y el seguimiento de indicadores y cuadros de mando que exige cualquier sistema de gestión normalizado, de modo que también queden contemplado en el modelo el apartado preventivo de la gestión de incidentes de seguridad.

En definitiva, lo importante es que cada organización desarrolle su propia sistemática de gestión de incidentes de seguridad y que, independientemente del modelo que elija (alguno de estos dos o cualquier otro) sea un modelo completo, que contemple todos los apartados necesarios para una gestión efectiva de los incidentes de seguirdad.