Gestión de servicios de ITIL
ITIL tiene mala reputación en los círculos de seguridad, normalmente porque alguien lo ha implementado como un mero trámite burocrático en lugar de como una forma de gestionar bien las TI. Yo no lo enfoco de esa manera. Cuando incorporo las prácticas de ITIL a un entorno, busco aquellos elementos que realmente reducen el riesgo: un proceso de gestión de cambios que detecte una regla de cortafuegos mal configurada antes de su implementación, un proceso de gestión de incidentes que derive un evento de seguridad a la persona adecuada en cuestión de minutos en lugar de horas, y una base de datos de gestión de configuraciones que le indique, con total transparencia, qué se está ejecutando en su red.
Por qué es importante para la seguridad
La mayoría de las brechas de seguridad que he analizado a posteriori se remontan a una deficiencia en los procesos, no a la falta de una herramienta. Un cambio no autorizado se lleva a cabo un viernes por la tarde. Un activo que nadie ha supervisado sigue ejecutando un sistema operativo obsoleto. Un ticket del servicio de asistencia sobre un «inicio de sesión lento» resulta ser el primer indicio de un ataque de «credential stuffing», pero nadie ató cabos porque la gestión de incidentes y la de servicios se encuentran en silos separados. ITIL, si se aplica correctamente, subsana esas deficiencias al ofrecer una forma disciplinada de gestionar los cambios, los incidentes, los problemas y los activos como un único sistema interconectado.
Mi enfoque
Empiezo por analizar lo que ya hace, no lo que un libro de texto dice que debería hacer. La mayoría de las organizaciones cuentan con algún tipo de sistema de control de cambios y gestión de incidentes; la cuestión es si es coherente, si el departamento de seguridad tiene voz y voto, y si los registros que mantiene le servirían realmente de ayuda durante un incidente real o una auditoría. A partir de ahí, le ayudo a reforzar los procesos más importantes —por lo general, la gestión de cambios, la gestión de incidentes y la gestión de la configuración y los activos— y a establecer el vínculo entre las operaciones de TI y el equipo de seguridad, de modo que una interrupción del servicio y un incidente de seguridad se traten como el mismo tipo de problema cuando sea necesario.
No me interesa entregarle un manual de procesos de 40 páginas que acabe en una estantería. Lo que me importa es si su comité asesor de cambios detiene realmente los cambios arriesgados, si su CMDB refleja la realidad y si su equipo es capaz de responder a la pregunta «¿qué cambió justo antes de que esto fallara?» en cuestión de minutos en lugar de días. Ese es el listón.
A quién va dirigido
Este trabajo resulta adecuado para organizaciones que están superando las operaciones de TI ad hoc, empresas que necesitan procesos alineados con ITIL para satisfacer los requisitos de los clientes o de cumplimiento normativo, y equipos de seguridad que están cansados de ser los últimos en enterarse cuando se produce algún cambio en el entorno de producción.
Si su proceso de cambio y su programa de seguridad no están coordinados, merece la pena hablarlo. Póngase en contacto conmigo y explíqueme dónde se encuentra el problema.