Auditoría de red corporativa: cómo se hace y qué revela
Etapas de una auditoría de red en una PYME: inventario, documentación, análisis de tráfico, seguridad, performance y plan de remediación.
Auditoría de red corporativa: cómo se hace y qué revela
La mayoría de las PYMEs no tienen documentación actualizada de su propia red. Cuando algo se rompe, alguien que ya no trabaja ahí tenía la clave del switch principal. Una auditoría de red es el ejercicio de hacer visible lo que está ahí, evaluar cómo está y proponer qué corregir.
Este post describe cómo se hace una auditoría seria y qué tipo de hallazgos suele generar.
Qué es y qué no es una auditoría de red
Wikipedia define network audit como “un análisis sistemático de la red de una organización para evaluar su salud, performance y seguridad” (fuente).
Lo que es:
- Inventario de equipos, enlaces, IPs, servicios.
- Análisis de configuración vs. mejores prácticas.
- Medición de performance real.
- Identificación de riesgos de seguridad.
- Recomendaciones priorizadas con estimación de esfuerzo.
Lo que no es:
- Un pentest (eso es otro entregable).
- Una imposición de marca o de proveedor.
- Una “venta de servicios” disfrazada.
Una auditoría termina con un informe; el cliente decide qué hace con él.
Marco de referencia
Para que la auditoría sea reproducible y defendible, conviene apoyarse en marcos públicos:
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (fuente). Marca metodologías para revisión técnica de seguridad.
- NIST Cybersecurity Framework — categorías Identify / Protect / Detect / Respond / Recover.
- OWASP — para servicios web expuestos (fuente).
- ISO/IEC 27001 — gobernanza de seguridad.
No hace falta certificarse en ninguno; se usan como checklist conceptual.
Etapas de la auditoría
1. Kickoff y alcance
- Quién pidió la auditoría y por qué.
- Qué entra y qué no (LAN principal, sucursales, OT, cámaras, IoT, cloud).
- Ventanas autorizadas para escaneos activos.
- Contactos de emergencia y horario.
- Acuerdo escrito (NDA, autorización de acceso, ROE — Rules of Engagement).
Sin este documento, no se hace nada. Escanear una red sin autorización por escrito es delito en la mayoría de jurisdicciones.
2. Descubrimiento pasivo
Antes de tocar nada, se observa. Wireshark (guía oficial) en un puerto espejo del switch principal durante 1-2 horas revela:
- DHCP: cuántos clientes, distribución de OUIs (Apple, Samsung, IoT…).
- Broadcast/multicast: protocolos en uso (mDNS, NetBIOS, SSDP).
- DNS: dominios consultados, presencia de DNS interno.
- Tráfico inesperado: equipos hablando con destinos extraños, posibles malwares.
Esta etapa no genera ruido y suele rendir las primeras sorpresas.
3. Descubrimiento activo
Con autorización, se escanea:
- nmap sobre los rangos definidos para detectar hosts vivos y puertos abiertos.
- arp-scan para validar mapeos MAC↔IP.
- Identificación de equipos críticos: servidores, controladores, NVRs, impresoras (las impresoras suelen ser de las cosas más vulnerables que hay en una red).
Salida: inventario con hostname, IP, MAC, fabricante, sistema operativo estimado, servicios expuestos.
4. Revisión de configuración
Se accede (con credenciales del cliente) a los equipos clave:
- Routers / firewalls: ACLs, NAT, VPN, logs, versión de firmware, contraseñas.
- Switches: VLANs, STP, port security, gestión out-of-band.
- APs Wi-Fi: SSIDs, encriptación (descartar WPA2-Personal compartida, idealmente WPA3 + 802.1X), aislación cliente, VLANs por SSID.
- Servidores: parches, servicios, usuarios privilegiados.
- DNS / DHCP: integridad y backups.
Hallazgos típicos: equipos con firmware de 5 años atrás, contraseñas por defecto, VLANs mal segmentadas, accesos administrativos expuestos a internet.
5. Performance
- Mediciones de latencia / jitter / packet loss internas (entre VLANs, hacia internet, hacia cloud).
- Test de throughput (iperf3) en los puntos críticos.
- Análisis de utilización de enlaces (si hay SNMP / NetFlow disponible, mucho mejor).
- Calidad Wi-Fi (heatmap si el cliente lo amerita).
6. Seguridad
Sobre el inventario y la configuración:
- Servicios expuestos a internet que no deberían estarlo (RDP, SMB, MySQL, ESXi).
- Equipos con CVEs conocidas no parchadas.
- Cuentas de servicio con privilegios excesivos.
- Falta de MFA en accesos críticos.
- Logs no centralizados o sin retención.
- Backups no probados (un backup que nunca se restauró es Schrödinger).
7. Documentación entregable
- Diagrama lógico (VLANs, ruteo, firewalls).
- Diagrama físico (rack, switches, fibras, postería si aplica).
- Inventario completo en hoja de cálculo.
- Lista de hallazgos clasificados por severidad (crítico / alto / medio / bajo).
- Plan de remediación priorizado.
Hallazgos típicos en una PYME argentina
Datos de relevamientos profesionales (anonimizados, frecuencias aproximadas observadas en el sector):
- Contraseñas por defecto en al menos un equipo: muy frecuente.
- Una sola red Wi-Fi sin segregación invitados/empleados/IoT: muy frecuente.
- Sin documentación de red actualizada: prácticamente la regla.
- Backups que nunca se probaron: muy frecuente.
- Cámaras IP expuestas a internet (puerto 80/8080 abierto): frecuente.
- Firmware de routers/switches sin actualizar por más de 2 años: muy frecuente.
- VPN configurada con IPSec PSK débil: frecuente.
- RDP expuesto a internet directo (sin VPN ni jump host): frecuente.
- DNS interno sin redundancia: frecuente.
(Estas frecuencias se desprenden de la práctica del sector y no de un estudio formal.)
Plan de remediación
Un buen plan no dice solo “qué arreglar”; dice en qué orden, con qué esfuerzo y con qué riesgo si no se hace.
| Severidad | Ejemplo de hallazgo | Esfuerzo típico | Riesgo si no se hace |
|---|---|---|---|
| Crítico | RDP de servidor expuesto a internet | < 1 día | Compromiso casi seguro en semanas |
| Alto | Backup sin probarse | 1-3 días | Pérdida de datos en evento |
| Alto | Firmware desactualizado en firewall | 1 día | Explotación de CVE conocida |
| Medio | Sin segregación VLAN cámaras | 2-5 días | Movimiento lateral |
| Medio | Wi-Fi sin VLAN para invitados | 1 día | Acceso a recursos internos |
| Bajo | Logs sin centralizar | 3-7 días | Forense difícil ante incidente |
El plan se revisa con el cliente y se acuerda quién ejecuta cada item, con fechas.
Errores frecuentes de quien encarga una auditoría
”Necesitamos algo rápido para el seguro”
Una auditoría que dura un día y entrega un PDF de tres páginas no es auditoría: es un certificado de cortesía. Sirve para tildar un casillero, no para mejorar la red.
”No tenemos tiempo para la entrevista de scoping”
Si el alcance no se define bien, la auditoría termina midiendo lo que no importa o esquivando lo que sí. Una hora de scoping ahorra dos semanas de trabajo desviado.
”Queremos que haga todo el auditor también”
Se mezcla auditor y operador. Lo correcto es: el auditor identifica y prioriza, y otro equipo (interno o externo, pero distinto) ejecuta la remediación. Mantiene la objetividad de la próxima auditoría.
Conclusión
Una auditoría de red bien hecha cuesta entre el equivalente a unos pocos sueldos de IT junior y produce, sistemáticamente, hallazgos que justifican el costo en pocas semanas: vulnerabilidades críticas tapadas antes de un incidente, capacidad ociosa identificada, planes de upgrade priorizados con datos.
Lo importante es entrar con una metodología seria (NIST 800-115 como base, OWASP para lo expuesto, herramientas estándar) y salir con documentación que el cliente pueda usar incluso si no contrata al mismo proveedor para la remediación. Esa es la prueba de que fue una auditoría y no una venta.
