Curso completo ciberseguridad gratis Controles CIS. Control 2.2

Estimados amigos de Inseguros !!!

Seguimos con el capítulo 2 de los CIS, y hoy toca el control 2.2. Este control es de los que parece aburrido, pero en realidad es de los que más te explotan en la cara cuando hay incidente: garantizar que el software autorizado tiene soporte, y que lo que está fuera de soporte lo tienes controlado, documentado y con respuesta.

Porque una cosa es “tengo un inventario de software” (2.1) y otra es que ese inventario sea útil. Útil significa que tú puedas mirar una aplicación y saber si está viva o muerta. Viva: soportada, actualizable, mantenida, con parches. Muerta: fin de vida, sin parches, sin proveedor, o “esto lo instaló alguien en 2014 y no lo ha tocado nadie”. Y el 2.2 te obliga a que, si es autorizada, tenga soporte. Y si no lo tiene, que lo reconozcas y lo trates como un riesgo gestionado, no como un “ya si eso”.

Aquí suele aparecer el caso típico: “necesito esta versión concreta de Java”, “la administración pública me exige este PDF reader”, “esta app solo funciona con Windows 10 tal”, “este plugin solo corre con un navegador viejo”. Y claro, negocio aprieta, y el técnico se lo come. Vale. Pero entonces hay que hacerlo bien: justificar por qué existe ese software, quién lo necesita, qué proceso soporta, y cuál es el plan. No puede ser un “lo tengo porque sí”.

Y luego está el peor escenario, el de industria: máquinas de producción, hardware con software embebido, equipos de corte, CNC, impresoras industriales, o cualquier cosa que viene “con su Windows viejito” y no puedes cambiarlo. En ese caso, el control 2.2 no te dice “arréglalo mañana”, te dice “gestiónalo”. Y gestionar aquí es: documentar el riesgo y poner medidas compensatorias para que eso no sea la puerta de entrada a tu red.

Medidas compensatorias hay muchas, pero la idea es siempre la misma: reducir superficie y aislar. ACLs estrictas, segmentación, firewall delante, reglas férreas, permitir solo lo imprescindible, monitorizar, y si hace falta, virtual patching. Y una de las más prácticas: que ese software legacy no viva en el día a día del usuario. Lo metes en una máquina virtual aislada solo para ese proceso, sin acceso a internet, sin correo, sin navegación, y que el usuario entre ahí solo cuando lo necesita. Así reduces muchísimo la exposición sin pelearte con el “no puedo cambiarlo”.

Lo importante es que cuando llegue una auditoría (o un incidente) tú puedas responder con tranquilidad: sí, tengo software sin soporte en este punto concreto, por este motivo, con esta justificación, con estas medidas, y con este plan. Y si no hay plan porque depende de fabricante o de presupuesto, también: que conste, que esté elevado, que esté en rojo, y que no sea un “se me olvidó”. Muchas veces el objetivo no es “que no exista riesgo”, es que el riesgo no sea una sorpresa.

Y cierro con lo que siempre digo: el 2.2 no es un control técnico de herramienta, es un control de madurez. No hace falta ser el FBI. Hace falta tener inventario, saber qué está soportado, y lo que no, tratarlo como un adulto. Y si quieres aprender a montar esto con mentalidad de empresa, sin humo y aplicado a entornos reales, pásate por www.seguridadsi.com y échale un ojo a los cursos de la academia.

Gracias por leerme !!!