Skip to main content

Deuda técnica (technical debt) en el SOC

What technical debt looks like : ProgrammerHumor

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.

Consejos para optimizar su CMDB. La industria de TI ha evolucionando… | by  Pepe Gonzalez | Medium

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.

Dealing with Heavy Debt – What You Need to Know

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

Aún contando con escaneos periódicos y actualizaciones automáticas del inventario llevarlo a un 100% de cobertura es imposible en cualquier ambiente laboral normal.  De todas formas debemos apuntar contar con esos inventarios para poder defender correctamente a nuestras organizaciones.

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

Popular posts from this blog

Simulacros de escritorio de ataques - tabletop exercises

Se conoce como  Tabletop Exercise  al proceso de convocar a todos los que estarían involucrado en un incidente de seguridad y ante un escenario ficticio preguntarles cómo reaccionarían.  En este artículo lo traduciré a Simulacro de Escritorio, no sé si es la mejor traducción, pero iré con eso.   Trataré de darles luces sobre lo que debe incluir un Simulacro de Escritorio de ataques en base a lo que he aprendido al ser facilitador en múltiples simulacros. El objetivo principal de un Simulacro de Escritorio es preparar mejor a la organización que lo realiza para un incidente que afecte la seguridad de su información o sistemas.  Estos simulacros deben ser realizados por lo menos anualmente como parte de los procesos de Gestión de Incidentes y Plan Continuidad de Negocios. Recomiendo realizar simulacros para los principales riesgos que enfrentan sus organizaciones.  Por lo menos para estos incidentes de seguridad deben hacer un simulacro: ...

Creando tu SOC - Monitoreo de Seguridad - Parte 1 de n

El SOC (Security Operations Centers) puede significar cosas diferentes para diferentes organizaciones.  Entre las opciones tenemos: 1. La gente, procesos y tecnología responsables de los procesos de Gestión de Monitoreo de Seguridad y Gestión de Incidentes dentro de un Programa de Seguridad .  2. El grupo responsable de la seguridad física (cámaras de vigilancia, guardias de seguridad, control de acceso físico) 3. El grupo responsable por dar atención inmediata dentro de un centro de operaciones de soporte técnico. Para efectos de este artículo, la definición que usaremos es la primera . En el proceso de monitoreo de seguridad se realizan las siguientes actividades: 1. La identificación y colección de las bitácoras de los eventos dentro de la infraestructura que son de interés para proteger a los sistemas. 2. La creación y gestión de procedimiento de monitoreo de dichos eventos. 3. La entrega de eventos de seguridad comprabados como incidentes al proceso de Gestión de Inciden...

Creando tu Programa de Seguridad - Parte 1 de 2

 En la publicación sobre Seguridad Básica  te hablé de los controles básicos que debes tener implementados en un proceso de mejora continua antes de empezar a trabajar en un Programa de Seguridad.  Este artículo asumirá que lograste hacer algo y que ahora consideras necesario dar el siguiente paso.   Antes de preparar tu Programa de Seguridad, definamos ciertas cosas: 1. Programa: conjunto de procesos realizados buscando un objetivo común. 2. Procesos: conjunto de actividades estrechamente relacionadas que tienen en común herramientas, métricas y KPIs. Te recomiendo que tu Programa de Seguridad tenga los siguientes procesos: 1. Gestión de Vulnerabilidades y Actualizaciones 2. Gestión de Riesgos 3. Gestión de Monitoreo de Seguridad   4. Gestión de Incidentes de Seguridad 5. Gestión de Auditoría y Cumplimiento 6. Operaciones de Seguridad  7. Seguridad de Desarrollos 8. Concienciación y Educación en Seguridad 9. Seguridad de  Proveedores o Caden...