Estimados amigos de Inseguros !!!

Ya sabes lo que tienes mal. ¿Cuánto tiempo llevas sin corregirlo?

Hay algo que me sigue sorprendiendo después de tantos años trabajando en ciberseguridad.

Las empresas invierten dinero en auditorías.

Contratan pentesting.

Implantan herramientas de gestión de vulnerabilidades.

Realizan revisiones de Microsoft 365, Azure y Active Directory.

Y reciben informes perfectamente elaborados.

Con sus hallazgos.

Sus evidencias.

Sus niveles de riesgo.

Y sus recomendaciones.

Todo estupendo.

Pero entonces llega una pregunta que me encanta hacer.

¿Cuántos de esos problemas habéis corregido?

Y aquí empieza el silencio.

Bueno, es que hemos tenido mucho trabajo.

Estamos esperando a actualizar los servidores.

El proveedor tiene que revisar el firewall.

No hemos podido modificar los permisos porque hay aplicaciones que dependen de ellos.

Y eso que encontramos en Active Directory… mejor no tocarlo porque lleva quince años funcionando.

¡MARAVILLOSO!

Tenemos identificados los problemas.

Sabemos cuáles son peligrosos.

Tenemos recomendaciones para solucionarlos.

Y seguimos exactamente igual.

O peor.

Porque mientras nosotros acumulamos informes, los atacantes siguen trabajando.

Y ahora, además, cuentan con herramientas de inteligencia artificial que pueden acelerar determinadas fases del reconocimiento, el análisis y la preparación de ataques.

Por eso hoy quiero hablar de algo que considero imprescindible.

La remediación y el hardening de nuestros sistemas.

O, dicho de otra manera:

Dejar de hablar de lo que tenemos mal y empezar a solucionarlo.

1. El verdadero problema no siempre es encontrar vulnerabilidades

Voy a empezar con una reflexión.

Hace años tenía bastante sentido dedicar buena parte de nuestro esfuerzo a descubrir qué estaba mal en los sistemas.

No disponíamos de la misma cantidad de herramientas, plataformas ni información que tenemos actualmente.

Pero hoy podemos utilizar soluciones capaces de analizar cientos o miles de activos.

Microsoft Defender for Cloud.

Microsoft Defender Vulnerability Management.

OpenVAS.

Nessus.

Wazuh.

Y muchas otras herramientas que permiten obtener información sobre configuraciones, versiones, vulnerabilidades y exposición.

Todo esto es muy útil.

Pero también genera un problema.

Cada vez tenemos más capacidad para descubrir lo que está mal que para corregirlo.

Imaginemos una empresa que recibe un informe con 150 hallazgos.

Treinta son de severidad alta.

Otros tantos son configuraciones mejorables.

Y algunos requieren proyectos de cierta complejidad.

¿Quién va a solucionarlos?

El responsable de informática.

El mismo que tiene que atender a los usuarios, mantener la infraestructura, gestionar proveedores y garantizar que todo siga funcionando.

Y, claro, las semanas pasan.

Aparecen nuevas incidencias.

Se incorporan aplicaciones.

Llegan otros proyectos.

Y las vulnerabilidades siguen pendientes.

No necesitamos solamente mejorar nuestra capacidad para encontrar problemas. Necesitamos mejorar nuestra capacidad para resolverlos.

Y aquí es donde entra nuestro servicio de Remediación y Hardening para empresas.

No para sustituir al equipo IT.

Sino para ayudarle a convertir esas recomendaciones en cambios concretos y verificables.

2. Remediación y hardening no son exactamente lo mismo

Vamos a aclarar dos conceptos.

Porque a menudo utilizamos ambos términos de manera conjunta.

Remediación significa corregir o tratar una debilidad de seguridad identificada.

Por ejemplo:

• Eliminar privilegios administrativos innecesarios.
• Actualizar un servicio vulnerable.
• Corregir una configuración insegura.
• Restringir el acceso a un sistema expuesto.
• Revocar credenciales o accesos que ya no deberían existir.
• Implantar un control que estaba ausente.

Hardening, o bastionado, consiste en configurar y fortalecer sistemas para reducir su superficie de ataque y limitar los riesgos asociados a configuraciones innecesarias o inseguras.

Por ejemplo:

• Deshabilitar servicios que no necesitamos.
• Aplicar configuraciones seguras de autenticación.
• Restringir protocolos heredados.
• Configurar correctamente firewalls.
• Proteger cuentas privilegiadas.
• Implantar líneas base de seguridad.
• Mejorar la protección de servidores y estaciones de trabajo.

Son trabajos relacionados.

De hecho, una remediación puede requerir actuaciones de hardening.

Pero quiero dejar algo claro.

El hardening no consiste en ejecutar un script que deshabilita cincuenta servicios y cruzar los dedos.

Tenemos que conocer el sistema.

Comprender sus dependencias.

Definir qué queremos mejorar.

Y comprobar que las modificaciones no provocan problemas operativos.

Porque conseguir que un servidor sea muy seguro a base de impedir que funcione tampoco parece una solución demasiado interesante.

3. No todas las vulnerabilidades se corrigen instalando un parche

Otra confusión habitual.

Cuando hablamos de remediación, algunas personas piensan inmediatamente en actualizaciones.

Y, por supuesto, debemos mantener nuestros sistemas correctamente actualizados.

Pero muchas de las debilidades importantes de una infraestructura no dependen de una versión vulnerable.

Dependen de cómo hemos configurado los sistemas.

Imaginemos una empresa con Windows Server completamente actualizado.

Active Directory funcionando correctamente.

Y todos los parches instalados.

Perfecto.

Pero determinados usuarios disponen de permisos excesivos.

Existen cuentas de servicio con privilegios que no necesitan.

Y algunas delegaciones permiten modificar objetos críticos.

¿Qué parche de Microsoft instalamos para solucionar eso?

Ninguno.

Tenemos que revisar los permisos.

Comprender las dependencias.

Modificar las delegaciones.

Y comprobar que el resultado es correcto.

Lo mismo sucede en Azure.

Podemos disponer de todos nuestros recursos actualizados y mantener identidades con permisos excesivos sobre las suscripciones.

O permitir accesos innecesarios a recursos de almacenamiento.

O tener aplicaciones con privilegios que nunca deberían haberse concedido.

La ciberseguridad no se arregla únicamente actualizando software.

Muchas veces requiere comprender cómo está construida nuestra infraestructura.

Y modificar decisiones que tomamos hace años.

4. Active Directory y Entra ID: corregir los privilegios que nunca deberíamos haber concedido

Vamos con uno de mis terrenos favoritos.

Microsoft Active Directory y Entra ID.

Porque las identidades siguen siendo fundamentales para la seguridad de nuestras empresas.

Y aquí encontramos muchas oportunidades de mejora.

Imaginemos que durante una auditoría detectamos que un usuario dispone de privilegios administrativos innecesarios.

Parece sencillo.

Le retiramos los permisos y asunto solucionado.

Pero cuando intentamos hacerlo descubrimos que una aplicación depende de esa cuenta.

O que el usuario realiza determinadas tareas que nadie ha documentado.

O que los permisos se concedieron mediante una delegación heredada de hace varios años.

Ahora tenemos que trabajar.

No basta con eliminar una pertenencia a un grupo.

Necesitamos comprender por qué se concedió ese permiso.

Qué operaciones dependen de él.

Y cómo podemos sustituirlo por una configuración más segura.

Entre las actuaciones que podemos realizar encontramos:

Revisión de cuentas privilegiadas.

Reducir privilegios innecesarios y separar identidades administrativas.

Corrección de delegaciones.

Eliminar permisos excesivos y revisar las relaciones entre objetos.

Protección de cuentas de servicio.

Analizar qué necesitan realmente y cómo gestionamos sus credenciales.

Mejora de la autenticación.

Fortalecer los mecanismos de acceso y reducir dependencias de configuraciones heredadas.

Implantación de modelos de administración segura.

Separar cuentas, estaciones y sistemas críticos mediante principios como el modelo de Tiers.

Revisión de Entra ID.

Corregir asignaciones de roles, permisos de aplicaciones y configuraciones de acceso.

Y hay algo importante.

Una corrección debe eliminar o reducir el camino de ataque que hemos identificado.

No basta con cambiar una configuración y considerar que el trabajo ha terminado.

Necesitamos volver a comprobar las relaciones y los permisos efectivos.

En SeguridadSi podemos trabajar estas actuaciones como parte de nuestro servicio de remediación o después de una Auditoría de Active Directory y Entra ID.

Y si eres administrador de sistemas y quieres aprender cómo proteger este tipo de entornos, puedes consultar nuestro Curso de Seguridad de Active Directory, donde trabajamos herramientas, configuraciones, hardening y técnicas ofensivas y defensivas reales.

Porque para corregir bien una ruta de ataque, primero hay que comprender cómo funciona.

5. Azure y Microsoft 365: tenemos que corregir lo que realmente estamos exponiendo

Ahora nos vamos a la nube.

Y aquí sucede algo especialmente interesante.

La infraestructura puede cambiar muchísimo más rápido que nuestros procedimientos de seguridad.

Se crean recursos.

Se modifican permisos.

Se incorporan aplicaciones.

Se conceden accesos a proveedores.

Y se despliegan nuevos servicios.

Todo perfectamente normal.

Pero ¿quién revisa que esas modificaciones sigan cumpliendo nuestros requisitos de seguridad?

Imaginemos una suscripción de Azure donde diferentes usuarios pueden crear recursos de computación.

Quizás algunos necesitan esos permisos.

Pero otros no.

Y, en determinados escenarios, una identidad comprometida podría utilizarlos para desplegar recursos no autorizados.

Con consecuencias técnicas y económicas.

La remediación podría implicar:

• Reducir asignaciones RBAC.
• Revisar quién puede conceder nuevos permisos.
• Limitar capacidades de despliegue cuando corresponda.
• Aplicar políticas de Azure.
• Mejorar registros y alertas.
• Revisar identidades de aplicaciones.
• Corregir configuraciones de exposición.
• Fortalecer controles sobre almacenamiento y secretos.

Y en Microsoft 365 podemos encontrarnos con otros problemas.

Sitios de SharePoint con permisos demasiado amplios.

Invitados que ya no necesitan acceso.

Aplicaciones empresariales con consentimientos excesivos.

Políticas de acceso condicional que no cubren determinados escenarios.

O configuraciones de seguridad que deben reforzarse.

Pero cuidado: cambiar una política en producción puede afectar a cientos o miles de usuarios.

Por eso necesitamos planificar.

Comprobar dependencias.

Utilizar grupos piloto cuando sea adecuado.

Y establecer mecanismos de recuperación.

No queremos solucionar un problema de seguridad creando uno de disponibilidad.

En nuestro servicio de Auditoría de Azure y Microsoft 365 analizamos este tipo de configuraciones.

Y mediante remediación podemos ayudar a corregirlas.

Porque una recomendación como aplicar el principio de mínimo privilegio está muy bien.

Pero alguien tiene que sentarse, revisar las asignaciones reales y realizar los cambios.

6. Servidores y estaciones: el hardening tiene que llegar a producción

Vamos ahora con Windows, Linux y los endpoints.

Aquí tenemos otro clásico.

Un equipo realiza una auditoría y recomienda aplicar medidas de bastionado.

Perfecto.

Pero después hay que convertir esas recomendaciones en configuraciones.

Y hacerlo sin romper las aplicaciones.

Podemos trabajar, por ejemplo, con:

• Políticas de seguridad.
• Servicios y protocolos innecesarios.
• Configuraciones de firewall.
• Protección de credenciales.
• Restricciones sobre ejecución.
• Configuración de EDR.
• Gestión de actualizaciones.
• Permisos locales.
• Registros y auditoría.
• Líneas base de seguridad.

Para Windows podemos apoyarnos en referencias como las Microsoft Security Baselines.

Y también utilizar los CIS Benchmarks para diferentes sistemas y tecnologías.

Pero quiero insistir en algo.

Una baseline no es una receta mágica que podamos aplicar idénticamente a todos los servidores.

Un controlador de dominio.

Un servidor SQL.

Un servidor web.

Y una estación de trabajo.

No tienen las mismas necesidades.

Por ejemplo, podemos tener una configuración recomendada para reducir determinados riesgos, pero descubrir que una aplicación heredada necesita temporalmente un protocolo o comportamiento concreto.

¿Qué hacemos?

¿Ignoramos el problema?

¿Deshabilitamos el servicio y dejamos de funcionar?

Pues ninguna de las dos cosas sin evaluar alternativas.

Tenemos que analizar el riesgo, comprender las dependencias, definir medidas de mitigación y establecer un plan realista.

En ocasiones podremos corregir inmediatamente.

En otras necesitaremos una transición.

Y en determinadas circunstancias el negocio tendrá que aceptar formalmente un riesgo residual.

La seguridad profesional también consiste en saber qué podemos cambiar, qué no y cómo reducir el riesgo mientras tanto.

Por eso en SeguridadSi trabajamos con medidas de hardening adaptadas a cada entorno.

Y si quieres aprender a implantar controles de este tipo, tenemos el Curso de Controles CIS v8.1.

Trabajamos los 18 controles, sus 153 salvaguardas y cómo llevar esas recomendaciones a sistemas y configuraciones reales.

7. Redes y firewalls: las reglas antiguas también necesitan una limpieza

Vamos con otra situación que seguro que muchos conocéis.

Un firewall que lleva años funcionando.

Decenas o cientos de reglas.

Objetos de red.

Excepciones temporales.

Accesos concedidos a proveedores.

Y configuraciones que nadie recuerda por qué se crearon.

Todo funciona.

Pero ¿estamos seguros de que todo eso sigue siendo necesario?

Imaginemos una regla creada hace cuatro años para permitir que un proveedor accediera a determinados servidores.

El proyecto terminó.

El proveedor cambió.

Pero la regla sigue activa.

O una configuración que permite comunicaciones entre segmentos de red que hoy deberían encontrarse separados.

No necesitamos una vulnerabilidad espectacular para tener un problema.

A veces basta con una regla demasiado permisiva.

La remediación puede incluir:

• Revisar las reglas de firewall.
• Eliminar accesos innecesarios.
• Restringir servicios administrativos.
• Mejorar la segmentación.
• Revisar servicios expuestos.
• Corregir configuraciones de VPN.
• Actualizar dispositivos y firmware.
• Fortalecer protocolos de gestión.

Pero aquí hay que tener especial cuidado.

Modificar una ACL o una política de firewall puede interrumpir comunicaciones de las que dependen aplicaciones críticas.

Por eso necesitamos analizar tráfico, dependencias y ventanas de mantenimiento.

Y comprobar el resultado después del cambio.

No quiero cerrar una regla y descubrir tres horas después que hemos dejado sin servicio al ERP.

Quiero reducir exposición.

Pero manteniendo la operativa necesaria.

Ese equilibrio es fundamental.

8. Backups y resiliencia: corregir también significa asegurarnos de que podemos recuperarnos

Vamos ahora con una de las áreas que considero más importantes.

Las copias de seguridad.

Muchas empresas tienen sistemas de backup.

Realizan copias diariamente.

Reciben correos indicando que el trabajo ha terminado correctamente.

Y están tranquilas.

Pero quiero hacer una pregunta.

¿Cuándo fue la última vez que recuperasteis realmente un sistema crítico?

No me refiero a comprobar que existe un archivo de backup.

Me refiero a restaurar.

Arrancar.

Comprobar.

Y confirmar que podemos recuperar el servicio dentro de los tiempos que necesita el negocio.

Porque una empresa puede tener veinte trabajos de copia funcionando y seguir sin estar preparada para recuperarse de un incidente importante.

En remediación y hardening también podemos trabajar sobre:

• Protección de las credenciales de backup.
• Separación de privilegios.
• Aislamiento de repositorios.
• Copias inmutables cuando la tecnología lo permita.
• Protección frente a borrado no autorizado.
• Supervisión de los trabajos.
• Pruebas de restauración.
• Procedimientos de recuperación.
• Configuraciones de acceso a las plataformas de backup.

Y quiero destacar algo.

No basta con proteger los servidores si dejamos que un atacante pueda eliminar todas nuestras copias utilizando una cuenta administrativa comprometida.

Necesitamos pensar en la resiliencia como una parte esencial de la seguridad.

Y eso implica medidas técnicas y procedimientos operativos.

Porque cuando llega un incidente serio, no queremos descubrir por primera vez cómo funciona nuestra estrategia de recuperación.

9. Detección y monitorización: tener un SIEM no significa detectar ataques

Ahora vamos con la monitorización.

Una empresa tiene Microsoft Sentinel.

O Wazuh.

O cualquier otra plataforma SIEM.

Perfecto.

Pero ¿está recogiendo los datos adecuados?

¿Tenemos configuradas las reglas necesarias?

¿Los eventos importantes generan alertas?

¿Sabemos quién debe investigarlas?

Porque podemos tener un sistema precioso.

Con dashboards.

Con gráficos.

Con alertas.

Y seguir sin detectar determinados comportamientos relevantes.

Pensemos en un ejemplo.

Durante una auditoría descubrimos que nadie está monitorizando los cambios en determinados grupos administrativos de Active Directory.

Tenemos un hallazgo.

¿Qué hacemos?

Podemos definir qué eventos necesitamos.

Comprobar que los sistemas generan la telemetría.

Configurar su recopilación.

Desarrollar una detección.

Y realizar una prueba autorizada para comprobar que el comportamiento esperado produce la alerta.

Eso también es remediación.

No hemos instalado necesariamente una herramienta nueva.

Hemos conseguido que una capacidad de seguridad funcione mejor.

También podemos mejorar:

• Registros de auditoría.
• Telemetría de endpoints.
• Detecciones sobre identidades.
• Alertas de Azure y Microsoft 365.
• Reglas de correlación.
• Monitorización de cambios críticos.
• Procedimientos de investigación.

Y algo que considero esencial.

Una corrección relacionada con detección no está terminada simplemente porque hayamos creado una regla.

Necesitamos probarla.

Generar un escenario controlado.

Comprobar que llegan los registros.

Y verificar que la alerta puede ser investigada.

Porque la seguridad no es una cuestión de tener configuraciones bonitas.

Es una cuestión de que los controles funcionen.

10. ¿Cómo decidimos qué corregir primero?

Llegamos a una de las preguntas más importantes.

Porque ya sabemos que no podemos hacerlo todo al mismo tiempo.

Imaginemos que tenemos 80 acciones pendientes.

Algunas requieren cambios relativamente sencillos.

Otras necesitan actualizar sistemas.

Y otras pueden convertirse en proyectos de varios meses.

¿Qué hacemos?

No creo que sea suficiente con ordenar los hallazgos por CVSS.

Necesitamos considerar varios factores.

Impacto.

¿Qué consecuencias tendría que alguien aprovechase el problema?

Exposición.

¿El sistema está accesible desde Internet, desde redes internas o únicamente para determinados usuarios?

Explotabilidad y amenazas conocidas.

¿Existen evidencias de explotación activa o condiciones que faciliten el abuso?

Criticidad del activo.

¿De qué procesos de negocio depende?

Complejidad de la corrección.

¿Qué esfuerzo técnico necesitamos?

Dependencias.

¿Hay otras actuaciones que debemos completar antes?

Y, por supuesto, debemos considerar las medidas compensatorias disponibles.

Porque una vulnerabilidad importante sobre un sistema crítico no siempre puede corregirse inmediatamente mediante una actualización.

Quizás necesitemos restringir temporalmente el acceso.

Aplicar reglas adicionales.

Reducir privilegios.

O aislar determinados servicios mientras preparamos una solución definitiva.

Lo importante es no confundir una mitigación temporal con una remediación definitiva.

Ambas pueden ser necesarias.

Pero debemos documentar qué hemos hecho y qué riesgo sigue pendiente.

Y aquí es donde un Plan Director de Ciberseguridad puede ayudarnos a conectar las actuaciones con una planificación más amplia.

Aunque no necesitamos esperar a terminar todo un Plan Director para resolver un riesgo urgente.

11. Cómo debería funcionar un proyecto de remediación

Vamos ahora con la metodología.

Porque no quiero que parezca que remediar consiste en entrar en los sistemas y empezar a cambiar configuraciones.

Especialmente cuando hablamos de entornos empresariales.

En SeguridadSi planteamos un proceso estructurado en cuatro fases.

Fase 1. Convertir los hallazgos en acciones

Lo primero es revisar la información disponible.

Auditorías anteriores.

Informes.

Evidencias.

Configuraciones.

Y necesidades actuales.

No siempre será necesario repetir una auditoría completa.

Pero sí comprobar que los hallazgos siguen siendo válidos y entender su contexto.

Después convertimos cada problema en una actuación concreta.

Por ejemplo:

Se han identificado permisos administrativos excesivos.

Estupendo.

Pero ¿qué cuentas están afectadas?

¿Qué permisos necesitamos retirar?

¿Quién es responsable del sistema?

¿Qué aplicaciones dependen de ellos?

¿Cómo comprobaremos el resultado?

Ahora sí tenemos algo sobre lo que trabajar.

Fase 2. Diseñar el cambio

Aquí tenemos que planificar.

¿Qué vamos a modificar?

¿Quién lo hará?

¿Qué impacto podría tener?

¿Necesitamos una ventana de mantenimiento?

¿Cómo validaremos el funcionamiento?

¿Disponemos de una alternativa para revertir el cambio?

Y algo importante.

¿Quién autoriza la modificación?

Porque podemos tener toda la razón técnica del mundo.

Pero no podemos entrar en una infraestructura empresarial y modificar sistemas críticos sin coordinación.

Fase 3. Aplicar y acompañar

Ahora llega el momento de ejecutar.

Y aquí existen diferentes modelos.

Podemos realizar directamente las actuaciones técnicas acordadas.

O trabajar con el equipo IT para que sea este quien aplique los cambios.

En determinadas situaciones puede ser preferible que el personal interno ejecute las modificaciones, acompañado por nuestros especialistas.

Por ejemplo, cuando hablamos de aplicaciones críticas, dependencias muy específicas o sistemas con procedimientos operativos estrictos.

No queremos sustituir al departamento IT. Queremos aportarle la especialización que necesita.

Y también aprovechar el trabajo para transferir conocimiento.

Porque la corrección tiene que poder mantenerse en el tiempo.

Fase 4. Verificar y documentar

Y llegamos a una fase que considero fundamental.

Comprobar que lo que hemos cambiado funciona y que el problema se ha corregido o mitigado.

Podemos revisar configuraciones.

Comprobar permisos efectivos.

Volver a ejecutar pruebas autorizadas.

Validar registros.

Verificar controles.

O repetir parcialmente determinados escenarios del pentesting inicial.

Según el problema, necesitaremos unas evidencias u otras.

Pero debemos poder documentar el resultado.

Porque una actuación no debería considerarse cerrada únicamente porque alguien haya marcado una tarea como completada.

Quiero saber que el riesgo se ha reducido realmente.

Y, cuando no sea posible eliminarlo por completo, necesitamos dejar claramente documentado qué sigue pendiente.

12. Una corrección no debería convertirse en otro incidente

Este apartado me parece especialmente importante.

Porque muchas medidas de seguridad implican modificar sistemas que están en producción.

Y los cambios pueden tener consecuencias.

Imaginemos que decidimos endurecer las políticas de autenticación de una aplicación heredada.

Desde el punto de vista de seguridad, la modificación puede estar perfectamente justificada.

Pero si no revisamos las dependencias, quizás dejemos de permitir determinadas conexiones legítimas.

O pensemos en una modificación de reglas de firewall.

O en retirar permisos a una cuenta de servicio.

O en deshabilitar protocolos que siguen siendo utilizados por aplicaciones antiguas.

Aquí necesitamos gestionar los cambios con rigor.

No significa que debamos evitar modificar cualquier sistema.

Significa que debemos hacerlo bien.

Con pruebas previas cuando sea posible.

Con responsables identificados.

Con planes de reversión.

Y con comprobaciones posteriores.

Porque el objetivo es reducir el riesgo.

No sustituir una vulnerabilidad por una caída de producción.

Y cuando un riesgo grave no pueda resolverse inmediatamente por razones operativas, debemos evaluar medidas temporales que reduzcan su exposición hasta poder implantar una solución definitiva.

Esto es parte del trabajo profesional.

No siempre es tan espectacular como realizar una explotación.

Pero muchas veces es bastante más útil para el cliente.

13. ¿Qué debería recibir la empresa después de un proyecto de remediación?

Aquí quiero volver a ponerme en el papel del responsable de IT.

Contratamos un servicio de remediación.

Trabajamos durante varias semanas.

Se realizan cambios.

Y llega el momento de cerrar el proyecto.

¿Qué deberíamos recibir?

Para mí, hay cuatro elementos importantes.

Un plan priorizado de correcciones

Qué problemas se han abordado.

Qué prioridad tenían.

Quién era responsable.

Qué dependencias se identificaron.

Y cuáles siguen pendientes.

Una relación de configuraciones y controles mejorados

Qué actuaciones se han realizado.

Sobre qué sistemas.

Con qué autorización.

Y qué documentación necesitamos conservar.

Evidencias de verificación

Qué hemos comprobado.

Qué resultado hemos obtenido.

Y si las medidas han reducido el riesgo identificado.

Aquí es donde podemos comparar el estado inicial y el posterior.

Una situación clara de los riesgos pendientes

Porque no siempre podemos solucionarlo todo durante un proyecto.

Quizás existen actuaciones que requieren presupuestos adicionales.

O cambios de arquitectura.

O decisiones de dirección.

Esos riesgos deben quedar identificados, con responsables y próximos pasos.

Y, si la empresa lo necesita, podemos establecer un servicio posterior de mentoría o seguimiento recurrente mediante un acuerdo específico.

El objetivo no es cerrar el proyecto con otro informe enorme.

El objetivo es cerrar el proyecto con los controles mejorados y una visión clara de lo que todavía debemos hacer.

14. No tienes por qué solucionarlo todo tú solo

Quiero detenerme aquí.

Porque creo que este es uno de los mensajes más importantes para los responsables de informática.

Muchas empresas tienen profesionales excelentes.

Gente que conoce perfectamente su infraestructura.

Que sabe cómo funcionan sus aplicaciones.

Que lleva años resolviendo problemas.

Pero eso no significa que tenga tiempo para hacerlo absolutamente todo.

Ni que deba dominar cada especialidad de ciberseguridad.

Un administrador de sistemas puede tener mucha experiencia con Windows Server y Active Directory.

Pero quizás necesita apoyo para revisar determinadas rutas de ataque.

O para implantar un modelo de administración privilegiada.

O para fortalecer una configuración compleja de Azure.

O para mejorar las detecciones de Microsoft Sentinel.

Y aquí aparece una oportunidad.

¿Por qué no contar con un especialista que trabaje a su lado?

No hace falta entregarle toda la infraestructura a un proveedor.

Ni perder el control de las decisiones.

Podemos establecer un modelo donde el equipo IT mantiene la responsabilidad operativa y recibe ayuda especializada para resolver determinados problemas.

También podemos aprovechar esa colaboración para mejorar las capacidades internas.

Explicar las configuraciones.

Documentar los procedimientos.

Revisar las evidencias.

Y ayudar a que el equipo pueda mantener los controles después.

Porque creo que un buen servicio de consultoría debería conseguir dos cosas.

Que la infraestructura termine más segura.

Y que el equipo técnico termine mejor preparado.

Ambas son importantes.

15. ¿Y si la empresa ya tiene ISO 27001, ENS o un Plan Director?

Pues estupendo.

Pero tenemos que conectar los documentos con los sistemas.

Imaginemos que nuestro Plan Director establece la necesidad de reducir los privilegios administrativos.

Perfecto.

¿Hemos realizado los cambios?

O que una auditoría de cumplimiento identifica la ausencia de determinados controles de seguridad.

Bien.

¿Los hemos implantado?

O que una política establece que los sistemas deben seguir configuraciones de bastionado.

Muy bonito.

¿Podemos demostrar que esas configuraciones están realmente aplicadas?

Porque una cosa es definir qué debemos hacer.

Y otra conseguirlo.

El trabajo de remediación y hardening permite transformar muchas de esas necesidades en medidas técnicas verificables.

Por ejemplo, podemos utilizar CIS Benchmarks para definir líneas base de configuración.

O relacionar determinadas actuaciones con los CIS Critical Security Controls.

Pero debemos adaptar esas medidas a la arquitectura real.

Y comprobar que los controles funcionan.

Aquí quiero insistir en algo.

Una empresa no es más segura simplemente porque tenga más documentación.

La documentación puede ayudarnos a gobernar y demostrar qué hacemos.

Pero necesitamos que las medidas lleguen a producción.

Y, sobre todo, que sean sostenibles.

Porque si corregimos una configuración hoy y dentro de tres semanas vuelve a estar como antes, tenemos otro problema.

La seguridad también necesita procesos que eviten que reaparezcan las mismas debilidades.

16. La inteligencia artificial puede acelerar los ataques. Nosotros necesitamos acelerar las correcciones

Volvamos al principio.

La velocidad.

Cada vez disponemos de más herramientas capaces de automatizar tareas ofensivas.

Reconocimiento.

Análisis.

Generación de scripts.

Identificación de posibles caminos de ataque.

Y otras actividades que pueden verse aceleradas mediante inteligencia artificial.

Pero ahora quiero plantear una pregunta.

¿Estamos mejorando con la misma rapidez nuestra capacidad para corregir los problemas conocidos?

Porque aquí existe un riesgo.

Podemos desplegar soluciones avanzadas de detección.

Podemos incorporar IA a nuestro SOC.

Podemos analizar millones de eventos.

Pero si mantenemos durante meses configuraciones peligrosas que ya tenemos identificadas, seguimos acumulando exposición.

Y no todo requiere grandes inversiones.

En ocasiones podemos conseguir mejoras significativas eliminando permisos innecesarios.

Restringiendo servicios.

Corrigiendo configuraciones.

Revisando las identidades.

O activando correctamente controles que ya tenemos disponibles.

Por eso necesitamos establecer un ciclo continuo.

Identificar → Priorizar → Corregir → Comprobar → Mantener.

Y algo importante.

No siempre tendremos capacidad para eliminar todos los riesgos.

Pero sí debemos conocerlos, gestionarlos y reducirlos de forma razonable.

Porque la ciberseguridad no consiste en alcanzar un estado mágico donde nada puede fallar.

Consiste en mejorar constantemente nuestra capacidad para prevenir, detectar, resistir y recuperarnos de los incidentes.

Y todo eso empieza por corregir lo que ya sabemos que está mal.

17. SeguridadSi: no somos únicamente los que encuentran los problemas

En SeguridadSi llevamos más de 25 años trabajando con infraestructuras empresariales, tecnologías Microsoft y ciberseguridad.

Y tenemos algo muy claro.

Una auditoría que termina en un informe puede ser útil. Pero una auditoría que termina en mejoras verificadas aporta mucho más valor.

Por eso, además de nuestros servicios de pentesting, auditoría y consultoría, ofrecemos un servicio específico de Remediación y Hardening para empresas.

Podemos ayudarte a corregir problemas relacionados con:

• Active Directory y Microsoft Entra ID.
• Azure y Microsoft 365.
• Servidores y estaciones de trabajo.
• Redes y firewalls.
• Backups y resiliencia.
• Detección y monitorización.

Pero no queremos llegar a tu empresa y empezar a cambiar configuraciones sin criterio.

Queremos comprender tu situación.

Analizar las prioridades.

Definir las actuaciones.

Trabajar junto a tu equipo.

Y comprobar que los cambios funcionan.

Porque no se trata únicamente de resolver un hallazgo.

Se trata de mejorar tu seguridad.

Y podemos hacerlo mediante proyectos concretos de remediación, acompañamiento técnico o servicios recurrentes de consultoría y mentoría, según las necesidades de tu organización.

Más que un auditor o un proveedor, queremos ser tu socio de ciberseguridad.

¿Tienes vulnerabilidades y configuraciones inseguras pendientes de corregir?

Quizás ya tienes una auditoría.

O varios informes.

O una herramienta que no deja de mostrar problemas.

Y sabes perfectamente que deberías solucionarlos.

Pero no tienes tiempo.

O necesitas apoyo especializado.

O hay modificaciones que prefieres abordar acompañado por alguien con experiencia.

Podemos ayudarte.

Conoce nuestro servicio de Remediación y Hardening para empresas.

Analizamos lo que tienes pendiente, priorizamos las actuaciones y acordamos cómo corregirlas.

Con tu equipo IT.

Con planificación.

Con evidencias.

Y comprobando los resultados.

No necesitas contratarnos para que volvamos a decirte todo lo que tienes mal.

Puedes contratarnos para ayudarte a solucionarlo.

¿Quieres aprender a realizar estas mejoras tú mismo?

Si eres administrador de sistemas, responsable IT o profesional de ciberseguridad, también tenemos formación especializada en nuestra academia.

Te recomiendo especialmente:

Curso de Controles CIS v8.1.

Aprenderás a trabajar con los 18 controles y sus 153 salvaguardas, priorizar las medidas y utilizar referencias como los CIS Benchmarks para fortalecer sistemas.

Curso de Seguridad de Active Directory.

Trabajamos permisos, autenticación, técnicas de ataque, medidas de hardening y herramientas utilizadas para proteger entornos Microsoft.

Curso Modelo Tiers Administrativos para Active Directory.

Un monográfico práctico sobre separación de privilegios, protección del Tier 0 y administración segura.

Y si quieres aprender cómo se identifican y documentan los problemas que posteriormente debemos remediar, también tienes nuestro Curso Profesional de Auditoría de Ciberseguridad.

Todos ellos forman parte de la formación disponible en SeguridadSi.

Porque no basta con conocer los riesgos.

Necesitamos profesionales capaces de corregirlos.

Y termino con una última reflexión.

Si mañana alguien compromete tu empresa aprovechando una configuración que llevas seis meses intentando corregir, el problema no será que nadie te avisó.

El problema será que no conseguimos convertir aquel aviso en una actuación.

Y eso es precisamente lo que tenemos que cambiar.

Menos informes pendientes. Menos excusas. Más seguridad funcionando.

Gracias por leerme.