Gestión de vulnerabilidades en ayuntamientos: cómo contratar escaneos, pentesting y remediación

La gestión de vulnerabilidades en ayuntamientos no debería reducirse a ejecutar un escáner una vez al año y entregar un PDF con cientos de hallazgos. Una entidad pública necesita saber qué activos están expuestos, qué vulnerabilidades representan un riesgo real, quién debe corregirlas y en qué plazo, además de comprobar después que la remediación ha sido efectiva.

Este enfoque es especialmente importante cuando conviven sede electrónica, gestor de expedientes, aplicaciones web, servidores, VPN, servicios cloud, APIs, equipos de usuario y software desarrollado a medida. Cada componente cambia con el tiempo y puede incorporar nuevas vulnerabilidades aunque no haya sufrido una modificación funcional visible.

La contratación debe alinearse con el Esquema Nacional de Seguridad, con las guías y recomendaciones del CCN-CERT y con la estrategia de adecuación al ENS del ayuntamiento. El objetivo es convertir el descubrimiento técnico en un proceso continuo de reducción de riesgo.

Qué es la gestión de vulnerabilidades

Es el ciclo mediante el que una organización identifica activos, detecta debilidades, las prioriza, asigna responsables, corrige, verifica y vuelve a evaluar.

La diferencia respecto a un escaneo puntual está en la continuidad y en la responsabilidad. Un listado sin seguimiento no garantiza que el riesgo disminuya.

El servicio debe integrarse con mantenimiento, desarrollo y ciberseguridad operativa.

Inventario de activos

No se puede evaluar lo que no está identificado. El proyecto debería partir de un inventario de IP, dominios, servidores, aplicaciones, dispositivos, bases de datos, servicios cloud, repositorios y componentes expuestos.

Una auditoría tecnológica municipal ayuda a localizar activos olvidados y dependencias de terceros.

El inventario debe indicar propietario, criticidad, entorno y proveedor responsable.

Superficie de ataque externa

Dominios, subdominios, VPN, portales, servicios publicados y direcciones IP accesibles desde Internet forman parte de la superficie externa.

El servicio puede realizar descubrimiento periódico para detectar exposiciones nuevas o sistemas que permanecieron publicados después de una migración.

Los activos desconocidos suelen ser especialmente peligrosos porque quedan fuera de los ciclos normales de parcheado.

Superficie interna

También deben revisarse servidores, equipos, servicios de red y aplicaciones que no están expuestos directamente a Internet.

Una intrusión inicial puede utilizar vulnerabilidades internas para ampliar privilegios o desplazarse entre sistemas.

La evaluación debe adaptarse a la segmentación y criticidad de la red municipal.

CVE y fuentes de vulnerabilidades

Los identificadores CVE permiten referenciar vulnerabilidades conocidas en productos y componentes.

El proveedor debe utilizar fuentes actualizadas y relacionar los hallazgos con las versiones realmente instaladas.

No todos los CVE publicados afectan necesariamente a la configuración concreta del ayuntamiento, por lo que se necesita validación.

CVSS no es suficiente para priorizar

La puntuación CVSS aporta una referencia técnica, pero no refleja por sí sola el riesgo del entorno.

Una vulnerabilidad media en un sistema expuesto y crítico puede requerir más urgencia que una vulnerabilidad alta en un servidor aislado sin datos sensibles.

La priorización debe combinar severidad, exposición, explotación conocida, criticidad y controles compensatorios.

Explotación activa

Cuando existe evidencia de explotación real de una vulnerabilidad, la prioridad puede aumentar de forma significativa.

El servicio debería incorporar inteligencia de amenazas y alertar cuando un activo municipal está afectado por una debilidad utilizada activamente.

La ciberseguridad gestionada con SOC y SIEM puede complementar esta detección y vigilar indicadores relacionados.

Escaneos autenticados

Los escaneos autenticados permiten revisar el interior del sistema con credenciales controladas y detectar versiones, parches y configuraciones que un análisis externo no ve.

Las cuentas utilizadas deben tener privilegios mínimos y tratarse como credenciales técnicas sensibles.

El pliego debe definir dónde se almacenan y cómo se rotan.

Escaneos no autenticados

Simulan lo que puede observar un atacante sin credenciales. Son útiles para conocer exposición y servicios accesibles.

Ambos enfoques son complementarios y responden a preguntas diferentes.

El proveedor debe explicar qué cobertura aporta cada modalidad.

Periodicidad

La frecuencia depende de criticidad y velocidad de cambio. Algunos activos pueden revisarse continuamente y otros de forma mensual o trimestral.

También debería ejecutarse un análisis después de cambios relevantes, nuevas publicaciones o incidentes.

Una única auditoría anual deja periodos demasiado largos sin visibilidad en sistemas dinámicos.

Aplicaciones web

Las aplicaciones web requieren pruebas sobre autenticación, sesiones, permisos, entradas, configuración, dependencias y lógica.

Un escáner automático puede detectar problemas comunes, pero no siempre identifica fallos de autorización o lógica de negocio.

La auditoría web para ayuntamientos puede complementarse con pruebas técnicas específicas de seguridad.

Sede electrónica

La sede es un servicio especialmente sensible porque concentra identificación, trámites y documentos.

La sede electrónica municipal debe revisarse junto con sus componentes, proveedores e integraciones.

Las pruebas deben coordinarse para no afectar a ciudadanía ni a procesos en producción.

APIs

Las APIs pueden exponer datos o funciones aunque la interfaz principal sea segura.

La guía sobre integración de sistemas municipales y APIs muestra la importancia de autenticación, permisos, rate limits y trazabilidad.

El pentesting debe revisar endpoints, controles de acceso y exposición de información.

Software a medida

Las aplicaciones propias requieren revisar código, dependencias, secretos y configuración de despliegue.

La contratación de software a medida debería incluir obligaciones de corrección y actualización.

El servicio de vulnerabilidades debe coordinar hallazgos con el equipo que mantiene el código.

Dependencias y cadena de suministro

Frameworks, librerías, imágenes y paquetes de terceros pueden introducir vulnerabilidades.

Conviene mantener un inventario de componentes y automatizar alertas cuando aparecen nuevas debilidades conocidas.

Los proyectos modernos deberían incorporar esta revisión dentro del ciclo de desarrollo y no solo al final.

Cloud

Los servicios cloud requieren revisar configuraciones, identidades, redes, almacenamiento y componentes gestionados.

La migración a la nube en ayuntamientos debe incorporar controles de seguridad y responsabilidad compartida.

Una mala configuración puede generar riesgo aunque el software utilizado esté actualizado.

Endpoints y servidores

Equipos de usuario y servidores necesitan control de parches, software instalado y versiones sin soporte.

El inventario debe identificar excepciones y sistemas que no pueden actualizarse inmediatamente.

En esos casos se necesitan medidas compensatorias y una hoja de ruta de sustitución.

Equipos sin soporte

Un sistema operativo o producto fuera de soporte representa un riesgo estructural.

El informe debe diferenciar entre vulnerabilidades corregibles mediante parche y riesgos que exigen migración o sustitución.

Una oficina técnica de transformación digital puede incorporar esas actuaciones a la cartera tecnológica.

Pentesting

El test de penetración busca validar de forma controlada si determinadas debilidades pueden explotarse y hasta dónde podría llegar un atacante.

No sustituye a la gestión continua de vulnerabilidades. Es una prueba más profunda y normalmente acotada a un alcance concreto.

El pliego debe definir objetivos, fechas, restricciones y reglas de enfrentamiento.

Black box, grey box y white box

En un ejercicio black box el equipo parte con información limitada; grey box dispone de cierta información o credenciales; white box cuenta con mayor conocimiento técnico.

Cada modalidad permite evaluar aspectos distintos.

La elección debe relacionarse con el objetivo, no con una preferencia comercial.

Pentesting de aplicaciones

Las pruebas pueden revisar autenticación, autorización, gestión de sesiones, subida de archivos, inyecciones y lógica de negocio.

Los resultados deben incluir evidencia reproducible y una recomendación de corrección.

Las pruebas peligrosas deben coordinarse para evitar pérdida de datos o interrupciones.

Pentesting de infraestructura

Puede abarcar exposición externa, servicios de red, segmentación, sistemas internos y movimientos laterales controlados.

El alcance debe indicar rangos, sistemas excluidos y ventanas de ejecución.

La entidad debe conocer qué acciones están autorizadas y cuáles no.

Ingeniería social

Las campañas de phishing simulado pueden formar parte de un programa de seguridad, pero necesitan objetivos, comunicación y tratamiento responsable de resultados.

No deberían utilizarse para señalar individualmente a empleados, sino para identificar necesidades de formación y mejorar controles.

La seguridad del correo merece además un proyecto específico sobre autenticación de dominios y protección frente a suplantación.

Informe de hallazgos

El informe debe separar resumen ejecutivo y detalle técnico. Cada vulnerabilidad necesita activo, evidencia, riesgo, recomendación y responsable propuesto.

También conviene indicar si existe explotación pública y qué prioridad tiene.

Un listado exportado directamente del escáner sin contexto aporta poco valor operativo.

Backlog de remediación

Los hallazgos deben convertirse en tareas con responsable, fecha y estado.

Puede utilizarse una herramienta de tickets o un cuadro de mando común.

El objetivo es que ninguna vulnerabilidad crítica desaparezca dentro de un PDF archivado.

SLA de corrección

El contrato puede definir plazos por severidad y exposición.

Las excepciones deben documentarse, justificar riesgo residual y establecer una fecha de revisión.

La gestión del mantenimiento de software municipal puede incorporar estos SLA en la operación cotidiana.

Retesting

Después de corregir es necesario verificar. El retesting confirma que el hallazgo se ha cerrado y que la solución no ha introducido un problema nuevo.

La evidencia de cierre debe quedar vinculada al hallazgo original.

Los informes periódicos deberían diferenciar vulnerabilidades abiertas, cerradas y reabiertas.

Excepciones y riesgo aceptado

Puede haber casos donde una vulnerabilidad no pueda resolverse de inmediato por dependencia de un fabricante o sistema legado.

La entidad necesita documentar la excepción, controles compensatorios y responsable de aceptar el riesgo.

Las excepciones no deberían renovarse automáticamente sin revisión.

Integración con SOC

Una vulnerabilidad crítica conocida puede generar nuevas reglas de detección mientras se prepara el parche.

El SOC municipal puede priorizar eventos sobre activos afectados.

Esta coordinación reduce la separación entre prevención, detección y respuesta.

Backups antes de cambios críticos

Algunos parches y actualizaciones implican riesgo operativo. La estrategia debe coordinarse con copias de seguridad y disaster recovery.

Debe existir posibilidad de reversión cuando el cambio pueda afectar a un servicio crítico.

La seguridad no debe provocar indisponibilidad por una actualización mal planificada.

MFA y cuentas administrativas

Muchas remediaciones requieren acceso privilegiado. Las cuentas utilizadas deben protegerse con MFA y gestión de identidades.

También conviene registrar quién ejecutó cada cambio y desde qué cuenta.

El principio de mínimo privilegio debe mantenerse durante las tareas técnicas.

Métricas del servicio

Algunos indicadores útiles son activos cubiertos, vulnerabilidades críticas abiertas, tiempo medio de remediación, porcentaje de retesting y sistemas fuera de soporte.

También puede medirse recurrencia de hallazgos y cumplimiento de SLA.

Las métricas deben ayudar a tomar decisiones, no generar volumen de reporting.

Cuadro de mando

Un panel puede mostrar riesgo por activo, unidad, proveedor o tecnología.

La entidad debería poder identificar rápidamente qué vulnerabilidades requieren una decisión.

El histórico permite comprobar si la exposición mejora o empeora con el tiempo.

Onboarding

La puesta en marcha debe validar inventario, credenciales de escaneo, ventanas, contactos y sistemas excluidos.

También conviene realizar una línea base inicial.

El resultado debe quedar documentado para comparar ciclos posteriores.

Cómo preparar el pliego

El pliego debe definir alcance, activos, periodicidad, escaneos, pentesting, fuentes de información, SLA, retesting, reporting, soporte y responsabilidades de remediación.

La guía de pliego técnico municipal ayuda a convertir estos elementos en obligaciones verificables.

También debe diferenciar claramente detección, asesoramiento y ejecución de correcciones.

Criterios técnicos de adjudicación

Puede valorarse metodología de priorización, cobertura, herramientas, calidad de evidencias, retesting, integración con tickets y capacidad de remediación.

La propuesta debe explicar cómo reducirá riesgo, no solo cuántos escaneos realizará.

También es importante valorar la transferencia de conocimiento al equipo municipal.

Qué puede aportar BlackHold Consulting

Cuando los hallazgos afectan a aplicaciones, APIs o automatizaciones, la corrección necesita capacidad técnica. BlackHold Consulting trabaja en digitalización e integración de procesos, automatización de procesos, automatización administrativa y gestión documental automatizada.

También dispone de capacidades en procesos tecnológicos complejos, consultoría tecnológica, agentes e integraciones y servicios de automatización. Estas capacidades pueden aplicarse a remediaciones, integraciones, actualizaciones y mejoras derivadas de auditorías mediante el procedimiento contractual correspondiente.

Checklist antes de contratar gestión de vulnerabilidades

Inventario

¿Se conocen todos los activos y responsables?

Cobertura

¿Se revisan superficie externa, interna, cloud y aplicaciones?

Priorización

¿Se considera riesgo real y no solo CVSS?

Pentesting

¿Está definido alcance y reglas de prueba?

Remediación

¿Cada hallazgo tendrá responsable y plazo?

Retesting

¿Se verificará el cierre?

Reporting

¿Existe cuadro de mando y seguimiento?

Integración

¿SOC, mantenimiento y desarrollo compartirán información?

Preguntas frecuentes

Conclusión

La gestión de vulnerabilidades municipal debe cerrar el ciclo completo: descubrir, priorizar, corregir y verificar. Un escáner que genera informes sin responsables ni plazos no reduce por sí mismo la exposición.

El ayuntamiento necesita combinar inventario, pruebas automáticas, pentesting, inteligencia de amenazas y coordinación con los equipos que mantienen cada sistema.

Un servicio bien contratado permite transformar cientos de hallazgos técnicos en un backlog controlado, medible y orientado a disminuir el riesgo real sobre servicios públicos y datos municipales. El programa debe revisarse de forma continua.

La gestión de riesgo técnico no se limita a vulnerabilidades de infraestructura: la adopción de IA introduce sus propios riesgos, como las respuestas incorrectas que un modelo puede generar con total naturalidad. BlackHold Consulting explica cómo detectar y mitigar este riesgo en el sector privado.

Fotografía: Antoni Shkraba / Pexels.