Ayer conversaba con mi equipo sobre el nuevo proyecto X. El nuevo proyecto X era la implementación de una innovadora herramienta de detección de intrusos que además permitía automatizar el proceso de respuesta ante ataques a un costo inferior a las alternativas. Creo que con esa descripción mis colegas defensores o del equipo azul (#BlueTeam) ya saben que esto había que hacerlo ya.
Mientras veíamos las implicaciones de esta interesante herramienta nos dimos cuenta que teníamos que definir cuáles serían los equipos involucrados en este proyecto. Entonces le pido a mi equipo que saquemos el inventario de equipos involucrados de nuestra CMDB. Después de todo, recientemente hicimos un gran esfuerzo por registrar todos nuestros activos en la CMDB con el propósito de ser utilizada en situaciones como esta.
Con mucha sorpresa me entero que mi equipo ha regresado a mantener la mayoría del inventario en una hoja de Excel y que la famosa CMDB no está siendo actualizada automáticamente ni tampoco utilizada como fuente única de inventario de los activos bajo nuestra responsabilidad.
En ese momento descubrimos que teníamos una deuda técnica que podíamos pagar ya o simplemente dejarla pendiente para atender el nuevo proyecto que nos prometía toda una serie de beneficios. El concepto de deuda técnica tiene una definición bastante aceptada del mundo del desarrollo de software que puede ser encontrada en Wikipedia. Yo la defino como aquellas cosas que tú sabes debes hacer para entregar un producto o sistema de calidad pero que decides no hacer en el nombre de ahorrar tiempo aunque luego esa decisión te cueste corregir en mucho más tiempo y esfuerzo que lo que habría tomado hacerlo en el momento que fue descubierta.
Decidimos que esta deuda técnica no podíamos dejarla seguir acumulando intereses. Que tenemos que identificar dónde fallamos luego de la puesta de producción de un proyecto que tenía el objetivo que salir de archivos excel individuales y pasar a una base de datos compartida de nuestros activos.
Y es que este caso de deuda técnica es especialmente importante en un SOC (centro de operaciones de seguridad) que forma parte de un Programa de Seguridad de Información. Los dos primeros controles del CIS Top 20 corresponden a la creación de inventarios y controles de los activos de hardware y software respectivamente. Esto es así porque contactar con un correcto inventario es clave para saber qué debe ser protegido.
En mi caso el lugar para almacenar esa información es la CMDB pero ese no es el único lugar. Otros sistemas que pueden tener tu listado de activos y sus relaciones pueden ser:
- software de mesa de ayuda
- software de monitoreo
- software de escaneo de vulnerabilidades o cualquier otro sistema de seguridad como antivirus
En resumen, amigos y amigas defensores, quisiera compartir estas lecciones:
1. Antes de implementar la nueva herramienta que promete resolver muchos problemas asegúrate de que tienes lo básico funcionando bien y dentro de un proceso de mejora contínua que busca encontrar esas oportunidades de mejoras normales que se dan en la vida de cualquier proceso o tecnología. Échale un ojo nuevamente a los controles básicos de CIS.
2. La deuda técnica se acumula a intereses muy altos que luego hay que pagar. No la dejes crecer o por lo menos diseña dentro de tus programas de gestión periodos para la atención de la deuda técnica. Recomiendo por ejemplo revisar la deuda técnica semestralmente para evitar que crezca demasiado.
3. Cualquier programa de seguridad está basado en inventarios automáticamente actualizados. Desde ya te diré que en esto la perfección no existe y no dejes de buscar la mejora continua.
Si tienes comentarios sobre el tema o ejemplos por favor no dudes en dejarme tus comentarios aquí o en Twitter
Comments