Qué Es una Auditoría de Ciberseguridad y Cómo Se Hace

A diferencia de lo que se piensa, una auditoría de ciberseguridad no debe confundirse con una prueba de intrusión o prueba de penetración, que es solo uno de sus componentes.

Más abajo verás el resultado de auditar dos máquinas de nuestro laboratorio: qué aspecto tiene una prueba de auditoría, qué encuentra y qué se hace con lo que encuentra.

Los objetivos de quien ataca van del dinero al espionaje industrial, pasando por la defensa de ideologías religiosas o geopolíticas. La auditoría de seguridad informática es la forma sistemática de saber por dónde entrarían esos atacantes.

Qué es una auditoría de ciberseguridad

Una auditoría de ciberseguridad (auditoría de seguridad informática) consiste en una evaluación exhaustiva y metódica de tu sistema de información. El objetivo es identificar las vulnerabilidades y los riesgos potenciales en materia de seguridad.

Es como un chequeo completo de tu sistema: dónde están las debilidades y cómo reforzar su resistencia.

Una auditoría de ciberseguridad puede adoptar varias formas, cada una con su utilidad y su metodología. Cada situación es diferente y puede requerir un ángulo de ataque y análisis específico.

Para realizar su análisis, los auditores se basan en guías, referencias, buenas prácticas, o directamente en normas o leyes.

El trabajo de fondo de un auditor es, por lo tanto, confrontar una situación, una configuración, una arquitectura o un fragmento de código con uno de estos elementos, y constatar si hay o no conformidad.

Por ejemplo, una de las recomendaciones clave de estándares internacionales como la norma ISO/IEC 27001 (Anexo A, control A.6.3) es “capacitar al personal en la seguridad de los sistemas de información”.

Los auditores intentarán entonces averiguar y demostrar que así es. Si no lo es, recordarán esa directiva y proporcionarán recomendaciones más detalladas, exponiendo la importancia de la formación de los equipos y los riesgos concretos para la entidad cuando no se realiza.

En una auditoría, todo debe basarse en hechos para evitar cualquier ambigüedad. Se habla entonces de prueba de auditoría.

Puede tratarse de notas tomadas durante una entrevista oral, de un registro de configuración, de un extracto de documentación o de un registro técnico: la prueba del éxito de un ataque, un fragmento de código, la salida de una herramienta.

Estas son las tres razones principales que hacen que las auditorías sean indispensables.

Proteger y cumplir

Las auditorías periódicas identifican las debilidades del sistema de información y permiten corregirlas antes de que las exploten.

Además, numerosas regulaciones imponen requisitos estrictos en materia de seguridad de datos, y las auditorías ayudan a las organizaciones a mantener ese cumplimiento legal.

Hay un segundo efecto. Los auditores de ciberseguridad, gracias a su conocimiento de los riesgos y las técnicas de ataque más recientes, desempeñan un papel educativo importante.

Ayudan a los equipos internos a comprender los riesgos que pesan sobre su sistema de información y demuestran concretamente cómo diferentes debilidades podrían ser explotadas.

Optimización y mejora continua

Las conclusiones de una auditoría de ciberseguridad ayudan a identificar las inversiones prioritarias en materia de seguridad. Sirven para orientar el presupuesto asignado a la ciberseguridad, pero también controlar si las decisiones pasadas fueron eficaces.

Además, permiten una supervisión y una mejora continua de las medidas de seguridad. Ayudan a identificar las nuevas vulnerabilidades que puedan aparecer con la evolución del sistema de información y las nuevas técnicas de ataque, y a ajustar las estrategias en consecuencia.

Permite comprobar con regularidad que el sistema mantiene su nivel de resistencia pese a los cambios y al uso diario.

Imagen y confianza en la organización

Las auditorías de seguridad también desempeñan un papel en el fortalecimiento de la confianza de los socios de una organización, sean clientes o proveedores. Demuestran de forma tangible que la organización se toma en serio la seguridad de los datos e implementa medidas para protegerlos.

Esta demostración de seriedad es a veces incluso un requisito previo para establecer asociaciones estratégicas o finalizar operaciones de adquisición, especialmente cuando se prevé una interconexión de los sistemas de información.

Finalmente, al prevenir los ciberataques y el robo de datos, las auditorías contribuyen directamente a proteger la reputación de la organización, evitando los daños financieros y de imagen asociados a incidentes de seguridad.

Auditoría interna o externa

El análisis puede ser realizado internamente por tus propios equipos, o externamente por expertos especializados. Cada enfoque tiene sus ventajas.

Una perspectiva externa aporta a menudo una visión nueva y experiencia acumulada en otros entornos. El auditor externo no arrastra los supuestos de la casa, y eso es precisamente lo que se le paga.

La auditoría interna de ciberseguridad tiene otras ventajas: el equipo conoce el negocio, puede repetirla con más frecuencia y no exige un proceso de contratación cada vez. En algunos casos específicos, además, la lista de proveedores posibles se reduce mucho porque el trabajo exige ciertas autorizaciones, y muchas organizaciones optan por equipos de seguridad internos y especializados.

En la práctica, ambas conviven. La interna sostiene el pulso continuo y la externa aporta el corte de realidad cada cierto tiempo.

Antes de contratar nada hay una diferencia que importa: el auditor externo mira desde fuera, y eso pesa sobre todo en la fase de reevaluación de riesgos.

Tipos de auditoría de ciberseguridad

Como se indicó antes, una auditoría puede adoptar varias formas —a veces denominadas alcances de auditoría— que pueden ser más o menos técnicas y tener metodologías o ángulos de análisis diferentes.

Los tipos de auditoría de ciberseguridad son complementarios entre sí: cada uno aporta una confirmación, una invalidación o información adicional respecto a los resultados de otro.

La prueba de intrusión

Es sin duda el tipo de auditoría más conocido, hasta el punto de que a veces ocupa su lugar y su definición. La prueba de intrusión (o prueba de penetración, traducción torpe de pentest) consiste en que los auditores se pongan en el lugar de un atacante y adopten su mentalidad, sus objetivos y sus herramientas.

Su objetivo es introducirse en el sistema de información a partir de una posición determinada —que puede ser Internet, una proximidad física, la red wifi, una sala de reuniones— y luego progresar, comprometer cuentas, sistemas y datos.

Aunque la prueba de intrusión a menudo designa el ataque a un sistema de información completo, también puede limitarse a un recurso o a algunos componentes: un sitio web, un ERP, un entorno en la nube.

Este enfoque es el más claro: confirma objetivamente que un sistema es vulnerable y expone paso a paso las debilidades explotadas y los posibles impactos.

Para llevar a cabo este proceso, que en circunstancias normales sería totalmente ilegal, los auditores disponen de una autorización específica del auditado.

El objetivo principal es inventariar las debilidades del perímetro auditado. Un segundo objetivo puede ser comprometer una cuenta de administrador del dominio, u otro tipo de acceso privilegiado, ya que esta posee las claves de todos los sistemas y permite “hacerlo todo” en el sistema de información.

Así se demuestra que un compromiso completo es posible gracias a la concatenación de algunas de las vulnerabilidades descubiertas.

También se pueden definir objetivos más específicos y precisos que los auditores intentarán alcanzar. Por ejemplo: “obtener los detalles del último contrato firmado con nuestro cliente”, “leer los correos electrónicos de nuestro director general”, “tener acceso a las nóminas”.

El hecho de alcanzar o no estos objetivos permitirá al auditado evaluar la solidez de los mecanismos de seguridad implementados para protegerlos.

Para ello, los auditores detectarán varias debilidades o vulnerabilidades y las explotarán de forma encadenada para dibujar un camino de compromiso completo, a veces llamado escenario de ataque.

En el marco de esta identificación de debilidades o de incumplimiento de las buenas prácticas, se realizan una serie de análisis y mapeos para obtener la mayor cantidad de información posible.

Se podrá elaborar, por ejemplo, la lista de usuarios con contraseñas débiles, los sistemas que no tienen la obligación de firmar los intercambios SMBv1 o los servicios FTP accesibles sin autenticación. También se deben realizar numerosos controles en Active Directory, sus objetos y sus relaciones.

Algunas herramientas y recursos utilizados en las pruebas de intrusión:

• Nmap: para el análisis y el mapeo de la red
• Metasploit: framework de explotación y automatización de ataques
• Exegol: paquete de herramientas en forma de contenedor Docker
• Burp Suite: proxy local, para la interceptación, el análisis, la modificación y la repetición de las solicitudes web
• BloodHound: herramienta de análisis de las debilidades de Active Directory y las rutas de ataque
• OWASP Testing Guide: repositorio de pruebas para aplicaciones web
• MITRE ATT&CK: repositorio de técnicas de ataque

Durante una prueba de intrusión se distinguen tres tipos de enfoques, que pueden combinarse. Se diferencian por el nivel de información proporcionado a los auditores para realizar sus pruebas.

• Enfoque “caja negra”: se acerca más a un ataque real. No se proporciona ninguna información a los auditores antes del inicio de las pruebas. Deben descubrir y explotar las vulnerabilidades sin conocimiento previo del sistema. Es el enfoque más realista para simular un ciberataque, pero también puede ser el más largo y costoso.
• Enfoque “caja gris”: los auditores reciben cierta información sobre el sistema, pero no toda. El nivel de detalle depende de los objetivos específicos de la auditoría y del objetivo probado. Este método simula una situación en la que un atacante ya habría obtenido un acceso limitado —por ejemplo, al haber comprometido una cuenta de usuario estándar o al tener acceso a algunas partes no públicas de la infraestructura—. Su ventaja es que prueba la resistencia del sistema ante un atacante que ya superó una primera línea de defensa, sin dejar de ser más realista que un enfoque completo de caja blanca. Un caso típico: se dispone de una cuenta de becario válida en Active Directory y de un puesto de usuario.
• Enfoque “caja blanca”: proporciona a los auditores la máxima información sobre el sistema objetivo: código fuente, credenciales de administrador, documentación técnica. Este método detecta vulnerabilidades que podrían pasar desapercibidas sin un conocimiento profundo del sistema. Es particularmente eficaz para detectar fallos complejos o problemas de configuración que requieren una comprensión precisa de la arquitectura. También resuelve el problema del tiempo acotado de una auditoría, donde la caja negra se queda corta.

Aunque pueda parecer el aspecto más atractivo del trabajo de auditor, la prueba de intrusión no es necesariamente su actividad principal.

Algunos auditores se especializan en la realización de auditorías organizativas o físicas y, aunque comprendan los desafíos y objetivos, no serán necesariamente expertos técnicos capaces de realizar pruebas de intrusión. Lo contrario también es cierto.

El trabajo de auditor está compuesto en realidad por varias funciones, que uno puede tener o no según sus experiencias y aptitudes, sin hablar de las numerosas funciones normativas y tecnológicas.

La auditoría de arquitectura

La auditoría de arquitectura es un alcance que no debe pasarse por alto para evaluar el diseño general de tu sistema de información. No se trata solo de verificar los componentes individuales, sino de comprender cómo interactúan y se integran para formar un todo coherente y seguro.

Consiste en la revisión de la arquitectura —en el sentido de redes y subredes—, de los cortafuegos y de los mecanismos de control y filtrado de flujos, de los sistemas de copia de seguridad, de actualización, de registro, de administración y de todos los componentes que tienen un impacto en la seguridad.

El objetivo es asegurarse de que la arquitectura es sólida y capaz de resistir las amenazas potenciales, pero también de bloquear, o incluso detectar, a un atacante.

Los auditores suelen utilizar la documentación interna y los diagramas para visualizar la arquitectura e identificar los puntos débiles. Esta revisión documental se complementa con entrevistas orales con las personas responsables del sistema de información: administradores de sistemas y de redes, responsable de seguridad de la información, dirección de TI.

En este sentido, la auditoría de arquitectura se combina muy bien con la prueba de intrusión, que a menudo permite confirmar o refutar la composición arquitectónica tal como se define en la documentación o se evalúa durante las entrevistas.

Ocurre con frecuencia que un cortafuegos entre dos zonas está mal configurado y permite el paso de flujos que deberían estar bloqueados. La revisión de la documentación de arquitectura puede dar la impresión de una situación controlada y segura, mientras que la prueba de intrusión revela una realidad diferente.

La auditoría de código

La auditoría de código consiste en examinar el código fuente de una aplicación, un sitio web o una aplicación móvil para identificar las posibles vulnerabilidades, los errores de programación y el incumplimiento de las buenas prácticas de desarrollo.

A menudo se habla de “caja blanca”, porque se le entregan a los auditores todos los secretos de la aplicación.

Este tipo de auditoría suele combinarse con una prueba de intrusión, que valida las debilidades descubiertas a través de ataques concretos.

A menudo se trata de un ejercicio difícil, ya que una vulnerabilidad evidente en un fragmento de código debe colocarse en su contexto de ejecución. Los controles de seguridad sobre una entrada de usuario pueden realizarse antes o después del código que se está analizando en ese momento.

Los auditores utilizan herramientas de análisis estático y dinámico para detectar fallos de seguridad.

Las de análisis estático recorren el código en busca de patrones conocidos de vulnerabilidades, como funciones inseguras, inyecciones SQL, desbordamientos de búfer y fallos de tipo cross-site scripting (XSS). Las de análisis dinámico no leen el código: ejercitan la aplicación en ejecución para ver cómo responde.

Los resultados de estas herramientas se analizan y se completan con el trabajo manual del auditor, que añade los controles relativos al aspecto de negocio del código analizado.

Herramientas habituales en una auditoría de código:

• SonarQube: para el análisis estático
• Checkmarx: para el análisis de código fuente
• Aura: auditoría de seguridad e introspección de código

La auditoría de configuración

La auditoría de configuración tiene como objetivo verificar que los sistemas y las aplicaciones están configurados de forma segura, de conformidad con las buenas prácticas. Esto incluye la verificación de los parámetros de seguridad, los permisos de acceso, las configuraciones de red y las políticas de gestión de usuarios.

Por dar algunos ejemplos, se puede incluir en una auditoría un alcance de configuración dirigido a la base Windows de los servidores, a un sistema cliente Windows, o a la imagen maestra que permite implementar todos los servidores Linux.

También puede incluir los cortafuegos, que poseen funciones y parámetros específicos para cada fabricante, los hipervisores, así como las soluciones de aplicación —por ejemplo Office 365 y sus numerosos parámetros de seguridad, o GLPI—. En resumen, todo lo que contiene una configuración de seguridad.

La auditoría de configuración suele aparecer como un alcance complementario a otras auditorías. A menudo se habla de defensa en profundidad, porque las debilidades detectadas rara vez son muy impactantes tomadas una a una y constituyen más bien desviaciones de las guías de buenas prácticas.

Sin embargo, la acumulación de estas desviaciones abre la puerta a vulnerabilidades más importantes o puede facilitar la ejecución de algunos ataques muy concretos. Por esta razón no hay que descuidar la configuración de seguridad de los componentes, aunque individualmente puedan parecer accesorios.

Para ser más concretos, durante el análisis de una base de sistema Windows se verifican puntos concretos, siempre contra el repositorio de referencia que se haya fijado para la auditoría.

Por ejemplo: que cada sistema tiene un límite de bloqueo automático de la pantalla tras cierto tiempo de inactividad, que la política de contraseñas obliga a introducir una contraseña de 14 caracteres, que la IPv6 está desactivada si no se utiliza, que la firma de los intercambios SMB es obligatoria o que el tamaño de los registros de eventos está por encima de un cierto valor.

Para que te hagas una idea del número de parámetros que hay que verificar, ten en cuenta que la guía CIS para las buenas prácticas de Windows Server 2022 contiene cientos de puntos de control, repartidos en perfiles de nivel 1 y nivel 2.

La primera edición, la que puedes descargar debajo, superaba las mil páginas. El benchmark se revisa de forma continua, así que antes de auditar conviene comprobar en el sitio del Center for Internet Security cuál es la edición vigente.

Descargar el extracto del benchmark CIS para Windows Server 2022 (PDF)

Los auditores utilizan herramientas de recopilación y análisis automatizadas para detectar configuraciones inseguras. También pueden realizar pruebas manuales para verificar que las configuraciones cumplen con las buenas prácticas y las políticas de seguridad de la organización.

La tarea suele ser ardua, ya que existen repositorios que a veces se contradicen, así como numerosas tecnologías o versiones de una misma tecnología. Las herramientas de recopilación que funcionan en un Windows 10 no funcionarán exactamente igual en un Windows Server 2022 o 2016, y no funcionarán en absoluto en un cortafuegos o una versión UNIX exótica.

En cualquier caso, y dada la complejidad de la tarea, a menudo se opta por un proceso de muestreo que consiste en tomar una muestra representativa de los componentes. Por lo general, un defecto de configuración detectado en un sistema se encontrará en todos los sistemas del mismo tipo dentro de una organización.

En cuanto a las guías y soportes, los CIS Benchmark del Center for Internet Security son la referencia en la materia. Este organismo proporciona gratuitamente, y mantiene gracias a su comunidad, cientos de guías sobre un gran número de tecnologías.

La auditoría organizativa

Menos conocida, pero igual de importante, la auditoría organizativa se centra en los aspectos humanos, procedimentales y de gestión de la seguridad de la información.

A diferencia de las auditorías técnicas, que se centran en los sistemas y las infraestructuras, la auditoría organizativa evalúa las políticas, los procesos, los procedimientos y las prácticas de gestión de la seguridad dentro de una organización. Estos elementos suelen ser la fuente de numerosos errores, negligencias y debilidades persistentes.

Los objetivos de la auditoría organizativa son los siguientes:

• Evaluar el cumplimiento de las políticas y las regulaciones: cumplimiento de las políticas internas de seguridad y de las regulaciones externas aplicables.
• Identificar las lagunas en los procesos: detección de las debilidades en los procesos de gestión de la seguridad, como la gestión de incidentes, la gestión de accesos o la concienciación.
• Evaluar la cultura de la seguridad: examinar la concienciación y la formación de los empleados, así como su adhesión a las políticas de seguridad.
• Verificar la gobernanza de la seguridad: evaluar la estructura de gobernanza, incluidos los roles y las responsabilidades de los actores.

Durante una auditoría organizativa se verifican muchos puntos: la existencia y la actualización de las políticas de seguridad, los procesos de gestión de incidentes, la formación y sensibilización de los empleados, la gestión de accesos e identidades, los planes de continuidad de actividad y de recuperación tras un desastre, o el cumplimiento de las regulaciones aplicables.

Por lo general, la auditoría organizativa se lleva a cabo de la misma manera que la auditoría de arquitectura. La revisión documental es la primera etapa, en la que los auditores examinan las políticas, los procedimientos, los informes de incidentes, los planes de continuidad y los registros de formación.

A continuación se realizan entrevistas con los responsables de seguridad, los responsables de negocio, los empleados y otras partes interesadas, para comprender las prácticas reales e identificar las desviaciones respecto a las políticas.

Por último, las prácticas de la organización se comparan con las buenas prácticas del sector y las normas internacionales.

Los repositorios más utilizados en este alcance son la norma ISO 27001 para los sistemas de gestión de la seguridad de la información, el Reglamento General de Protección de Datos y la directiva europea sobre la seguridad de las redes y los sistemas de información, hoy en su segunda versión.

La auditoría organizativa es, por lo tanto, un complemento de las auditorías técnicas, ya que permite asegurarse de que se tienen en cuenta los aspectos humanos y de gestión. Sus conclusiones y recomendaciones suelen aplicarse a largo plazo a nivel de toda la empresa.

Y los demás…

No hemos repasado ni de lejos todos los tipos de auditoría que existen en ciberseguridad. Según las necesidades y los perímetros, pueden adoptar numerosas formas.

Entre ellas, las auditorías específicas para la nube, el IoT (Internet of Things), los sistemas industriales, la seguridad física, las auditorías orientadas a las amenazas (Red Team) y las orientadas a la detección (Purple Team), o las campañas de phishing.

Para obtener más información sobre las auditorías Red Team y Purple Team, que se centran en las capacidades de detección de las herramientas y los equipos de seguridad y supervisión, te dejamos este artículo dedicado:

Lectura recomendada: Red Team vs Blue Team vs Purple Team: Lo que Necesitas Saber

Cómo se ve por dentro una auditoría de configuración

Hasta aquí la teoría. Vamos a bajarla a dos máquinas de laboratorio.

Montamos en nuestro laboratorio dos máquinas virtuales recién instaladas, sin endurecer y sin tocar ninguna directiva: un Windows 11 Pro 24H2 (compilación 26100) y un Ubuntu 24.04. Después les pasamos por encima los controles que acabamos de describir.

Nada de lo que sigue es un ejemplo construido. Van las órdenes que ejecutamos y los valores que devolvieron, para que puedas reproducirlo en tu propio equipo.

Cinco áreas de control en un Windows 11 sin endurecer

Los cinco puntos que citamos más arriba como ejemplo —bloqueo de pantalla, longitud de contraseña, IPv6, firma SMB y tamaño de los registros— se comprueban desde PowerShell con privilegios de administrador. Estas son las órdenes, una por área:

# Bloqueo automático de pantalla
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name InactivityTimeoutSecs -ErrorAction SilentlyContinue | Select-Object InactivityTimeoutSecs

# Política de contraseñas y bloqueo de cuenta
net accounts

# IPv6 por adaptador
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, Enabled

# Firma SMB y SMBv1
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature, EnableSMB1Protocol
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

# Tamaño de los registros de eventos
Get-WinEvent -ListLog Security, System, Application | Select-Object LogName, MaximumSizeInBytes, IsEnabled

Esas cinco áreas se desglosan en nueve comprobaciones. Esto es lo que devolvió la máquina:

La primera comprobación es la más instructiva de las nueve.

La consulta al registro no devuelve nada, y por eso en la tabla aparece como (sin valor). No falló: es que la directiva sencillamente no existe en ese equipo.

Esa es una de las cosas que más cuesta ver en una auditoría. Un valor incorrecto salta a la vista; una directiva ausente no salta, hay que ir a buscarla.

El de la política de contraseñas es el que debería quitarte el sueño. Longitud mínima cero, sin historial. En un equipo que exige cambiar la contraseña cada 42 días pero no impide volver a poner la misma, el vencimiento no protege de nada.

Y luego está la firma SMB, que pasa. Obligatoria en cliente y servidor, y SMBv1 desactivado, sin que nadie haya tocado nada.

No es casualidad: la documentación de Microsoft sobre la firma SMB recoge que las ediciones Pro, Enterprise y Education de Windows 11 24H2 exigen firma SMB entrante y saliente de fábrica. La edición Home no.

Un Ubuntu recién instalado puntúa 55

En el lado Linux usamos Lynis, una herramienta libre de auditoría y endurecimiento de sistemas UNIX. Una sola orden recorre el sistema y devuelve un informe:

sudo lynis audit system --quick

Tras 262 comprobaciones sobre un Ubuntu 24.04 sin endurecer, el resultado fue un índice de endurecimiento de 55, con 2 advertencias y 52 sugerencias.

Las dos advertencias, que la herramienta coloca en primer lugar, son de paquetes: no encuentra un repositorio de seguridad configurado (PKGS-7388) y detecta paquetes vulnerables (PKGS-7392).

Cada hallazgo trae su identificador de control y su referencia consultable. Eso permite rastrear cada resultado hasta el control que lo motiva.

Debajo, entre las 52 sugerencias, aparece lo interesante:

• Seis desviaciones distintas en la configuración de SSH (SSH-7408), todas del mismo servicio: reenvío TCP habilitado, tres comprobaciones de cliente vivo en vez de dos, nivel de registro poco detallado, seis intentos de autenticación permitidos, diez sesiones simultáneas y el puerto por defecto sin cambiar.
• Cuatro protocolos de red poco habituales activos sin que nadie los haya pedido: dccp, sctp, rds y tipc (NETW-3200).
• Caducidad mínima y máxima de contraseñas sin configurar, y umask por defecto más permisivo de lo recomendable (AUTH-9286, AUTH-9328).
• Sin contraseña en el gestor de arranque, lo que permite alterar la configuración de inicio (BOOT-5122).

El bloque de SSH es el ejemplo perfecto de lo que decíamos sobre la defensa en profundidad. Ninguna de las seis desviaciones es crítica por separado. Las seis juntas, en un servicio expuesto, son otra cosa.

Y como en Windows, no todo falla: la herramienta detecta cortafuegos activo. Lo que no encuentra es un analizador de malware.

Qué se sobrevalora y qué se subestima

Los dos sistemas, medidos el mismo día, cuentan la misma historia.

El hallazgo estrella ya estaba resuelto. SMBv1 y la firma SMB llevan años siendo el titular de todo informe y de toda charla. En la máquina que medimos vienen bien de fábrica, y según la documentación de Microsoft eso vale para todas las ediciones Pro, Enterprise y Education de esa versión. Se sigue reportando como noticia un control que el sistema operativo cerró solo.

Lo que abre la puerta está en el pie de página. Una longitud mínima de contraseña en cero no tiene identificador con nombre propio, ni sale en las noticias. Cae en el apartado de configuración, junto a otras cuarenta líneas, y nadie lo lee.

En Ubuntu pasa exactamente lo mismo. Las dos advertencias que la herramienta pone arriba del todo son de parcheo, el clásico de siempre. Las seis desviaciones de SSH, el umask permisivo y la caducidad sin configurar quedan enterradas entre 52 sugerencias que casi nadie termina de leer.

Lee el informe de abajo hacia arriba, al menos una vez.

Fases de una auditoría de ciberseguridad, paso a paso

Si te preguntas cómo realizar una auditoría de ciberseguridad, el proceso pasa por siete fases que no deben descuidarse, ya que se corre el riesgo de hacer un mal uso del presupuesto y de no alcanzar los objetivos fijados.

#1. Definir la necesidad

Antes de comenzar la auditoría es necesario definir claramente la necesidad. Realizar una auditoría puede responder a una necesidad reglamentaria, orientar mejor el presupuesto de seguridad, ver si un sistema es lo suficientemente robusto como para pasar a producción, o hacer un inventario.

La definición de esta necesidad permitirá normalmente comenzar a definir el perímetro de la auditoría.

#2. Dibujar el perímetro de la auditoría

También es importante saber enmarcar bien el perímetro, teniendo en cuenta que la auditoría será tanto más costosa cuanto mayor sea.

Para ello, una de las mejores herramientas sigue siendo el análisis de riesgos. Por un lado pone de manifiesto los principales eventos temidos de un perímetro técnico o de una organización entera —”¿qué es lo que más temo?”—; por otro, define los componentes críticos y sus relaciones técnicas u organizativas.

Para las auditorías técnicas hay que recordar además la noción de superficie de ataque, compuesta por el conjunto de puntos de entrada e intercambio de un sistema con el exterior.

Esta superficie de ataque se convertirá, según los tipos de auditoría, en escenarios simulados en pruebas de intrusión, definiendo al mismo tiempo los requisitos necesarios. Pero también en puntos de atención particulares durante la auditoría del código fuente —entrada de usuario, autenticación— o de la configuración, priorizando el sistema más expuesto.

Un componente evidente de la superficie de ataque son las direcciones IP públicas de los servidores que exponen servicios en Internet estando alojados en el sistema de información. Se piensa en particular en el sitio web de presentación o el correo web.

Pero no hay que descuidar la navegación de los usuarios, los correos electrónicos, e incluso las llaves USB o los terminales móviles que envían y reciben datos con el exterior estando conectados al sistema. Estos componentes también deben considerarse en el perímetro.

En resumen, antes de traer a un equipo de expertos hay que saber por qué se desea realizar una auditoría y qué se teme particularmente en caso de un ciberataque.

Una vez definido este perímetro, hay que determinar qué tipos de auditoría evalúan mejor su seguridad. Algunos perímetros solo requieren auditorías técnicas, mientras que otros, más complejos y con más implicación humana, deben incluir un alcance organizativo.

Los proveedores externos capaces de realizar estas auditorías pueden normalmente ayudarte a definir mejor los tipos pertinentes en función del perímetro y de la necesidad.

#3. Elegir al proveedor o definir el equipo auditor

Si la auditoría va a ser externa, hay que elegir al proveedor que mejor se ajuste a tus necesidades y a tu presupuesto, con los matices sobre autorizaciones que ya vimos más arriba. Si va a ser interna, esta fase consiste en definir quién la ejecuta y con qué dedicación.

#4. Definir y preparar los prerrequisitos

Cada tipo de auditoría requiere elementos diferentes para poder llevarse a cabo. Puede ser un simple nombre de dominio (prueba de intrusión externa con un componente OSINT), un puerto de red (prueba de intrusión interna), un acceso al servidor (configuración) o al código fuente.

Las auditorías organizativas y de arquitectura utilizarán la documentación del sistema de información, así como la disponibilidad de los diferentes responsables y equipos técnicos.

Todos estos elementos deben definirse con el equipo de auditoría y también dependerán del perímetro. Lo importante es que, en primer lugar, se definan y se enumeren claramente de acuerdo con el equipo auditor. A continuación se ponen a su disposición, para que nada de lo que hay que comprobar se quede fuera por falta de acceso.

Ejemplos de prerrequisitos, sin orden particular y combinando todo tipo de auditorías:

• Inventario de activos informáticos
• Lista de aplicaciones críticas
• Mapeo de la red
• Acceso a un puerto de red
• Cuentas en Active Directory o en una aplicación web
• Identificación de datos sensibles
• Definición de roles profesionales
• Documentación técnica
• Políticas de seguridad existentes
• Historial de incidentes
• Informes de auditorías anteriores

Esta fase consiste, por lo tanto, en recopilar y preparar todos los datos pertinentes sobre tu sistema informático.

#5. Ejecutar la auditoría

Con los prerrequisitos entregados, el equipo auditor ejecuta los alcances acordados. Es la fase en la que se recogen las pruebas de auditoría: las salidas de herramienta, los extractos de configuración y las notas de entrevista que después sostienen cada hallazgo.

Cuando el parque es homogéneo se trabaja por muestreo, como vimos en la auditoría de configuración: un defecto detectado en un sistema suele estar en todos los del mismo tipo.

#6. (Re)evaluar los riesgos y las prioridades

Tras la ejecución de la auditoría obtendrás un informe detallado de las observaciones y los descubrimientos de los auditores.

El informe contendrá métricas que permiten evaluar la criticidad de una debilidad o de un incumplimiento: la gravedad, la dificultad y la probabilidad de explotación para una vulnerabilidad técnica, una puntuación CVSS, más una prioridad y la facilidad de corrección.

Aquí es donde pesa la distancia del auditor externo. Rara vez conoce la composición exacta de tu equipo, su experiencia, su disponibilidad ni el presupuesto de cada uno.

A veces, además, algunas debilidades pueden atenuarse —o amplificarse— mediante medidas técnicas u organizativas de componentes que quedaron fuera del perímetro inicial. Por lo tanto, siempre es necesario revisar las métricas de las vulnerabilidades y confirmarlas o reevaluarlas a la luz de la información de la que dispones.

Una recomendación puede resultar más sencilla o más compleja de implementar gracias a —o debido a— un elemento que el auditor externo no conocía.

Esta fase es importante porque permite asegurar o corregir el plan de acción y la criticidad de algunas vulnerabilidades, que luego podrán tratarse de forma más eficaz.

#7. Realizar un seguimiento regular de las vulnerabilidades

Esta fase es sin duda la más larga. Consiste en realizar un seguimiento regular de las vulnerabilidades y los incumplimientos, así como en definir a las personas o equipos responsables de su corrección.

Sin ese seguimiento no hay forma de saber qué se corrigió ni qué mejoró entre una auditoría y la siguiente.

A menudo, un simple cuadro es suficiente para realizar este seguimiento. Lo complicado es implementar las recomendaciones.

Este es ese cuadro, con algunos hallazgos de nuestro Ubuntu de laboratorio, en una versión reducida de la hoja con la que se trabaja:

Fíjate en la tercera columna: la gravedad es nuestra, no la de la herramienta. Eso es exactamente lo que pedía la fase anterior. La herramienta no sabe si esa máquina está expuesta a Internet o vive en una red aislada, y esa diferencia cambia por completo la prioridad de las seis desviaciones de SSH.

Tras una auditoría, algunas recomendaciones son fáciles de implementar: activar una opción de seguridad sin riesgo de efectos secundarios, o algo que se despliega desde un componente central de gestión.

Otras son mucho más largas y fastidiosas. Las que requieren una modificación de la organización o de la arquitectura de red, las que exigen la compra de material costoso, o las que implican operaciones de migración complejas.

Algunos informes de auditoría podrán servir de plan de acción durante meses y años, de ahí la importancia de un seguimiento regular y con fechas.

Buena parte de las recomendaciones de una auditoría no se implementa nunca.

No es por falta de capacidad técnica. Es porque nadie es dueño del hallazgo. Cuando una recomendación no tiene un responsable con nombre y una fecha, se convierte en una línea de un documento que nadie vuelve a abrir.

A eso se suma el motivo más común y el menos confesado: la convicción de que a nosotros no nos va a pasar. Se asume el riesgo sin decidirlo, simplemente no actuando.

Por eso la columna de responsable de ese cuadro importa tanto como la de gravedad. Sin ella, el resto es documentación.

En la práctica, muchas auditorías se ejecutan pero no se interpretan.

Se pasan las herramientas, se recogen los hallazgos y se entrega el informe, pero nadie se sienta a pensar qué significan esos hallazgos en distintos escenarios: si esa máquina se expone mañana, si ese usuario cambia de rol, si ese servicio pasa a producción.

Las guías presentan la interpretación como una fase más del proceso. En la realidad es la primera que se salta cuando aprieta el calendario, y es justo la que convierte una lista de hallazgos en una decisión.

El informe de auditoría de ciberseguridad: qué debe contener

La realización de una auditoría concluye con la redacción de un informe que recoge los detalles, las métricas y el resumen de los elementos detectados: los puntos positivos, los negativos y el detalle técnico de cada vulnerabilidad encontrada.

El informe también contiene elementos que permiten evaluar la gravedad de una vulnerabilidad, el nivel de seguridad global, una estimación de la urgencia de aplicación de las recomendaciones, así como los detalles de lo que se debe implementar para corregir cada vulnerabilidad.

Es el entregable por el que estás pagando, así que hay que saber qué exigir antes de firmar nada. Un informe de auditoría de ciberseguridad razonable contiene, como mínimo:

• Resumen ejecutivo. Una página, sin jerga, para quien toma las decisiones de presupuesto y no va a leer el resto.
• Objetivo y alcance. Qué se auditó y, sobre todo, qué quedó fuera: esa delimitación dice hasta dónde llega el informe.
• Criterios de referencia. Contra qué se comparó: una norma, un benchmark, una política interna. Es lo que convierte una observación en un hallazgo de conformidad.
• Equipo auditor y fechas. Quién lo hizo y cuándo. Un informe sin fecha de ejecución no vale nada seis meses después.
• Metodología. Qué enfoque y qué herramientas se usaron, y con qué nivel de información se trabajó.
• Hallazgos con evidencias. Cada hallazgo con su prueba: la captura, la salida de la herramienta, el extracto de configuración. Un hallazgo sin evidencia es una opinión.
• Valoración de cada hallazgo. Gravedad, dificultad de explotación y facilidad de corrección, con el criterio de puntuación declarado.
• Recomendaciones y plan de acción. Qué hacer, en qué orden y con qué esfuerzo estimado.
• Anexos. Salidas completas, listados y todo lo que no cabe en el cuerpo.

Los equipos que entregan informes con frecuencia se apoyan en generadores como PwnDoc, que imponen esa estructura desde la plantilla.

Dos cosas se pactan de antemano. La primera, el plazo de entrega del informe, que suele olvidarse en el contrato y luego se estira.

La segunda, si el informe incluye una declaración del grado de cumplimiento respecto al criterio de referencia. No todas las auditorías la incluyen, y para quien necesita demostrar conformidad ante un tercero, esa declaración es justamente lo que va a pedir.

Normativa de auditoría de ciberseguridad y marcos de referencia

Este es el terreno que más se mueve. Lo tratamos aquí desde un solo ángulo: qué relación tiene cada marco con la auditoría y qué te va a tocar demostrar.

Qué pide cada marco

ISO/IEC 27001 es la norma internacional para los sistemas de gestión de la seguridad de la información, y la referencia más citada en auditorías organizativas. La versión vigente es la de 2022, con una enmienda posterior sobre acción climática.

El periodo de transición desde la versión anterior terminó el 31 de octubre de 2025, según el documento obligatorio IAF MD 26.

Los certificados emitidos contra la versión de 2013 dejaron de ser válidos a partir del 1 de noviembre de 2025. Si un proveedor te enseña uno, ya caducó.

A su lado conviven ISO/IEC 27002, que desarrolla los controles; ISO/IEC 27007, guía específica para auditar sistemas de gestión de la seguridad de la información; e ISO 19011, la guía general de auditoría de sistemas de gestión.

Su cuarta edición se publicó el 27 de mayo de 2026. Al ser una norma de directrices y no de requisitos, no tiene periodo de transición: aplica desde su publicación.

NIST Cybersecurity Framework 2.0, publicado en febrero de 2024, es la alternativa estadounidense y es de uso libre. Su gran cambio respecto a la versión anterior fue añadir la función de gobernanza, que es justo la que las auditorías organizativas miran primero.

NIS2, cuyo estado de transposición sigue publicando la Comisión Europea, es la directiva europea sobre seguridad de las redes y los sistemas de información. Su alcance, sus plazos y a quién obliga los desarrollamos en la guía completa de la directiva NIS2; aquí solo interesa qué obliga a comprobar. Obliga a las entidades esenciales e importantes a mantener medidas de gestión de riesgos y a notificar incidentes.

Aquí hay que deshacer un malentendido muy extendido: NIS2 no impone una auditoría externa obligatoria genérica. Exige medidas y controles apropiados, y capacidad de demostrarlos. La auditoría es el camino habitual para demostrarlo, no una obligación literal del texto.

Su plazo de transposición venció en octubre de 2024 y sigue incompleto en varios Estados miembros. La Comisión abrió procedimientos de infracción y en julio de 2026 llevó ante el Tribunal de Justicia a España, Irlanda, Francia y Países Bajos, entre otros.

Traducido a la práctica: la obligación concreta depende de la ley nacional que la transponga, y en varios países esa ley aún se estaba tramitando.

DORA aplica a entidades financieras europeas desde enero de 2025. Exige un marco de gestión de riesgos de tecnologías de la información, pruebas de resiliencia operativa digital y supervisión de los proveedores tecnológicos.

Para ciertas entidades incluye pruebas de penetración guiadas por amenazas. Si trabajas en el sector financiero, es el marco que más directamente convierte la auditoría técnica en obligación.

El Reglamento de Ciberresiliencia afecta a fabricantes, importadores y distribuidores de productos con elementos digitales. Entró en vigor en diciembre de 2024, su capítulo cuarto se aplica desde junio de 2026, y las obligaciones de notificación de vulnerabilidades e incidentes explotados arrancan el 11 de septiembre de 2026. La aplicación plena llega en diciembre de 2027.

De los tres bloques europeos —NIS2, DORA y este— es el menos conocido, y el que más gente va a descubrir tarde: no aplica a quien opera sistemas, sino a quien fabrica o vende producto.

El Esquema Nacional de Seguridad es el marco español para el sector público y sus proveedores, regulado por el Real Decreto 311/2022. Define categorías de sistemas y auditorías periódicas de conformidad.

PCI DSS aplica a quien procesa datos de tarjetas de pago. La versión vigente es la 4.0.1, y los requisitos que la versión 4.0 marcaba como futuros pasaron a ser obligatorios en marzo de 2025.

SOC 2 no es una norma sino un informe de auditoría emitido por un auditor externo sobre los criterios de servicios de confianza. Es el que suelen pedir los clientes empresariales estadounidenses a sus proveedores de software.

Las guías públicas y gratuitas

Buena parte de las metodologías, guías y listas de verificación que se usan en este terreno es pública y gratuita.

No sustituyen a una auditoría profesional, y no vamos a fingir que sí. Pero permiten hacer una primera pasada, entender qué te van a preguntar y llegar a la reunión con el proveedor sabiendo de qué se habla.

• La guía técnica de ENISA sobre medidas de gestión de riesgos, publicada en junio de 2025, desarrolla los requisitos del reglamento de ejecución de NIS2 con orientación concreta de implementación. Es probablemente el documento gratuito más útil que existe hoy en este terreno, y está en abierto.
• NIST SP 800-70, el programa nacional de listas de verificación para productos de tecnología, reúne guías de configuración segura por producto.
• NIST SP 1347 es la guía rápida de referencias informativas del marco NIST 2.0, útil para mapear controles entre marcos distintos.
• Los objetivos de rendimiento en ciberseguridad de CISA ofrecen un conjunto de prácticas priorizadas, alineadas con el marco NIST, pensadas para organizaciones sin equipo de seguridad dedicado.

A eso se suman los CIS Benchmark que ya mencionamos, y herramientas libres como la que usamos más arriba en el laboratorio. Con eso puedes levantar tu propia línea base antes de que llegue nadie a facturarte por hacerlo.

Qué aplica en Hispanoamérica y qué no

En lo anterior conviven tres cosas distintas: normas internacionales como las ISO, marcos estadounidenses como el de NIST, y normativa europea de obligado cumplimiento.

Conviene separar esta última con todas las letras: el ámbito de aplicación no es el mismo.

No existe en México, Colombia, Chile, Argentina ni Perú una obligación horizontal de auditoría de ciberseguridad comparable a NIS2, ni una obligación sectorial del alcance de DORA. No hay un equivalente que obligue transversalmente a las empresas de un tamaño determinado a auditarse y a notificar incidentes.

Lo que sí hay es normativa sectorial, sobre todo en banca y servicios financieros: los reguladores nacionales imponen ahí sus propios requisitos de seguridad y continuidad.

Y hay legislación de protección de datos personales, que obliga a medidas de seguridad sobre los datos aunque no use la palabra auditoría. Repasamos ese panorama en las leyes que aplican en ciberseguridad.

En la práctica, esto significa dos cosas. Si operas solo en la región, la obligación te llegará por tu regulador sectorial o por tu ley de datos, no por un marco general.

Y si vendes a Europa, o eres proveedor de alguien que opera allí, los marcos europeos te alcanzan por contrato aunque no te alcancen por ley. Es la vía por la que más empresas hispanoamericanas están descubriendo NIS2: no por el boletín oficial, sino por el cuestionario de un cliente.

Cuánto cuesta una auditoría de ciberseguridad

Buscamos un estudio independiente sobre el coste de una auditoría de ciberseguridad y no encontramos ninguno con muestra declarada, metodología pública y sin interés comercial en el resultado.

Los rangos de precios que circulan —esos “entre X y Y euros según el tamaño de la empresa” que aparecen en tantas páginas— provienen, en su inmensa mayoría, de empresas que venden auditorías. No decimos que sean falsos. Decimos que no son un dato independiente, y que se leen sabiendo quién los publica.

Lo que sí podemos decirte es qué mueve el precio, porque eso sale del propio proceso que describimos más arriba:

• El perímetro, que es con diferencia el factor dominante: cada componente añadido al alcance son horas de auditor.
• Los tipos de auditoría incluidos. Una revisión de configuración sobre una muestra representativa no cuesta lo mismo que una prueba de intrusión en caja negra sobre todo el perímetro externo.
• El enfoque. La caja negra puede ser el más largo y costoso, precisamente porque el auditor gasta tiempo en descubrir lo que en caja blanca le habrían entregado.
• Las autorizaciones exigidas al proveedor, que en algunos sectores reducen la lista de candidatos y, con ella, la competencia en precio.

Si conoces un estudio independiente sobre este tema que se nos haya escapado, dínoslo en los comentarios y lo añadimos con su fuente. Preferimos dejar el hueco antes que taparlo con una cifra de nadie.

Preguntas frecuentes

Fuentes

• ISO/IEC 27001:2022 — Information security management systems
• ISO 19011 — Guidelines for auditing management systems
• NIS2 Directive: transposition status — Comisión Europea
• Digital Operational Resilience Act (DORA) — resumen legislativo — EUR-Lex
• Cyber Resilience Act — calendario de aplicación — Comisión Europea
• ENISA — Technical Implementation Guidance on cybersecurity risk-management measures
• NIST Cybersecurity Framework 2.0
• NIST SP 800-70r5 — National Checklist Program for IT Products
• CISA — Cross-Sector Cybersecurity Performance Goals
• Real Decreto 311/2022 — Esquema Nacional de Seguridad
• SMB signing overview — Microsoft Learn