1. INTRODUCCIÓN

La seguridad en redes comprende el conjunto de principios, arquitecturas, controles técnicos y procedimientos organizativos destinados a proteger las comunicaciones, los servicios conectados y los activos que dependen de ellos. No se limita a instalar un cortafuegos en la salida a Internet. Una red moderna integra puestos de usuario, servidores, centros de proceso de datos, servicios en nube, enlaces entre sedes, redes inalámbricas, dispositivos móviles, equipos de Internet de las cosas, sistemas de terceros y múltiples canales de acceso remoto. Cada uno de estos elementos introduce identidades, rutas, protocolos y relaciones de confianza que deben gobernarse durante todo su ciclo de vida.

En una organización sanitaria, la seguridad de red tiene una trascendencia especial. La confidencialidad protege datos clínicos y administrativos especialmente sensibles; la integridad evita que resultados, prescripciones, citas o parámetros de configuración sean alterados; y la disponibilidad permite que las aplicaciones asistenciales y los dispositivos conectados sigan prestando servicio cuando el profesional los necesita. Una política excesivamente restrictiva que impida el trabajo clínico tampoco sería adecuada: la seguridad debe reducir el riesgo sin destruir la utilidad del sistema. Por ello, el diseño exige equilibrar protección, continuidad asistencial, rendimiento, usabilidad, trazabilidad y coste.

El enfoque correcto es sistémico. Primero se identifican activos, amenazas, vulnerabilidades, dependencias y posibles impactos. Después se definen zonas de seguridad y flujos autorizados, se aplican controles preventivos, se despliegan mecanismos de detección y respuesta, y se revisa continuamente su eficacia. Esta secuencia materializa la defensa en profundidad: ningún control se considera infalible y cada capa limita el daño cuando falla la anterior.

Este tema estudia los fundamentos de la seguridad en redes; las principales familias de ataques; la defensa mediante segmentación, cortafuegos, sistemas de detección y prevención de intrusiones, control de acceso a la red y técnicas criptográficas; los protocolos de comunicación segura; la arquitectura Zero Trust; y las medidas específicas para Wi-Fi, dispositivos móviles y redes celulares. Finalmente se aterrizan estos conceptos en el contexto de una Administración pública sanitaria sometida al Esquema Nacional de Seguridad y a exigencias elevadas de disponibilidad y trazabilidad.

2. FUNDAMENTOS, OBJETIVOS Y GESTIÓN DEL RIESGO

2.1. Propiedades de seguridad

La tríada clásica está formada por confidencialidad, integridad y disponibilidad. La confidencialidad impide que la información sea conocida por sujetos no autorizados; se apoya en el cifrado, el control de acceso, la clasificación de la información y la minimización de exposición. La integridad garantiza que datos, mensajes, configuraciones y programas no se modifiquen de forma no autorizada; se protege mediante códigos de autenticación de mensaje, firmas digitales, controles de cambios, registros de auditoría y mecanismos de detección de alteraciones. La disponibilidad persigue que recursos y servicios estén accesibles en el momento requerido; necesita redundancia, protección frente a denegación de servicio, capacidad suficiente, copias de seguridad, continuidad y recuperación.

A estas propiedades se añaden la autenticidad, que permite confiar en la identidad de una entidad o en el origen de un dato; la trazabilidad, que vincula acciones con sujetos y momentos concretos; y el no repudio, que aporta evidencias para dificultar que una parte niegue una actuación. En la práctica, autenticación, autorización y auditoría forman el modelo AAA: se verifica quién solicita acceso, se decide qué puede hacer y se registra lo realizado.

2.2. Activos, amenazas, vulnerabilidades y riesgo

Un activo es cualquier elemento con valor: información, servicio, aplicación, equipo, enlace, identidad, certificado, configuración o conocimiento. Una amenaza es una causa potencial de incidente, como un atacante, un error humano, un fallo eléctrico o una avería. Una vulnerabilidad es una debilidad explotable, por ejemplo una contraseña reutilizada, un firmware sin soporte, una regla de cortafuegos demasiado amplia o un protocolo inseguro. El riesgo combina la probabilidad de materialización y el impacto esperado sobre los activos.

La evaluación de riesgos evita aplicar controles por moda. Un escáner de vulnerabilidades puede detectar una versión antigua, pero la priorización debe considerar si el servicio está expuesto, si existe explotación conocida, qué privilegios obtiene el atacante, qué información procesa y qué controles compensatorios están activos. Del mismo modo, un enlace cifrado no elimina el riesgo si el terminal está comprometido, las claves se gestionan mal o el servidor autoriza operaciones excesivas.

2.3. Principios de diseño seguro

• Mínimo privilegio: cada identidad, proceso o dispositivo recibe solo los permisos imprescindibles y durante el tiempo necesario.
• Denegación por defecto: lo no autorizado expresamente se rechaza. Es preferible definir flujos permitidos que intentar enumerar todo lo peligroso.
• Separación de funciones: las operaciones críticas requieren responsabilidades diferenciadas para reducir fraude y error.
• Economía de mecanismo: los controles deben ser comprensibles, mantenibles y verificables; la complejidad innecesaria genera fallos.
• Defensa en profundidad: se superponen barreras independientes o parcialmente independientes.
• Fallo seguro: ante error, el sistema debe conservar la postura más segura compatible con la continuidad necesaria.
• Seguridad desde el diseño y por defecto: las decisiones de arquitectura se toman antes del despliegue y las configuraciones iniciales no exponen funciones innecesarias.

2.4. Defensa en profundidad y confianza explícita

La defensa en profundidad no significa duplicar indiscriminadamente herramientas. Cada capa debe cubrir una hipótesis de fallo distinta. Por ejemplo, la segmentación limita el movimiento lateral aunque una estación sea comprometida; el EDR detecta comportamiento malicioso aunque el tráfico esté cifrado; y la autenticación multifactor reduce el impacto del robo de una contraseña. La arquitectura debe documentar qué riesgo trata cada control, quién lo administra, qué evidencia genera y cómo se valida.

3. TIPOS DE ATAQUES CONTRA REDES

3.1. Ataques pasivos y activos

Los ataques pasivos buscan obtener información sin modificar apreciablemente el sistema. Incluyen la captura de tráfico, el análisis de metadatos, la observación de patrones y la inferencia de relaciones entre equipos. Son difíciles de detectar porque el adversario puede limitarse a escuchar. El cifrado extremo a extremo reduce el contenido visible, pero no siempre oculta direcciones, tamaños, tiempos o volumen de las comunicaciones.

Los ataques activos alteran el flujo normal: inyectan, modifican, eliminan o repiten mensajes; suplantan identidades; explotan vulnerabilidades; degradan servicios o toman control de equipos. Pueden generar señales observables, aunque un atacante avanzado intenta imitar el comportamiento legítimo y borrar evidencias.

3.2. Reconocimiento y descubrimiento

El reconocimiento recopila información para preparar fases posteriores. Puede ser externo, mediante fuentes públicas, consultas DNS, análisis de certificados o exploración de rangos; e interno, cuando una cuenta o equipo comprometido enumera hosts, servicios, rutas, usuarios y relaciones de confianza. El escaneo de puertos identifica servicios accesibles; la detección de versiones intenta asociarlos con vulnerabilidades; y el mapeo de red busca entender zonas y caminos de administración.

La defensa combina reducción de exposición, filtrado, inventario actualizado, detección de barridos, limitación de respuestas innecesarias y engaño controlado. No obstante, ocultar banners o bloquear ICMP no sustituye al parcheado: la seguridad por oscuridad solo aporta fricción adicional.

3.3. Suplantación, intermediación y secuestro de sesión

La suplantación puede afectar a direcciones IP, MAC, ARP, DNS, correo, puntos de acceso o identidades de aplicación. En una LAN, el envenenamiento ARP intenta asociar la dirección IP de otra máquina con la MAC del atacante, posibilitando intermediación o interrupción. El DNS spoofing entrega respuestas falsas para redirigir al usuario. Un punto de acceso malicioso puede imitar el nombre de una red legítima y atraer conexiones.

En un ataque man-in-the-middle el adversario se sitúa entre extremos y pretende observar o modificar la comunicación sin ser detectado. TLS con validación correcta del certificado y del nombre del servidor impide que la simple posesión de la clave pública permita descifrar el tráfico. Para romper la confianza, el atacante necesitaría comprometer claves, conseguir un certificado aceptado indebidamente, instalar una autoridad de certificación maliciosa, explotar una implementación o controlar un extremo.

El secuestro de sesión aprovecha identificadores robados, cookies, tokens o fallos de control de estado. El replay reutiliza mensajes válidos capturados previamente; se mitiga con números de secuencia, marcas temporales, nonces y protocolos que autentican el contexto completo.

3.4. Denegación de servicio

Un ataque DoS pretende agotar ancho de banda, tablas de estado, conexiones, memoria, CPU, hilos o recursos de aplicación. En DDoS, múltiples orígenes coordinados —frecuentemente una botnet— distribuyen el ataque, dificultando el filtrado por dirección. Los ataques volumétricos saturan enlaces; los de protocolo explotan el tratamiento de estados, como inundaciones SYN; y los de capa de aplicación producen solicitudes aparentemente válidas pero costosas.

Los ataques de reflexión y amplificación envían solicitudes con origen falsificado a servicios que responden con un volumen mayor hacia la víctima. DNS, NTP u otros protocolos UDP mal configurados han sido utilizados históricamente. La defensa requiere cooperación del proveedor, filtrado de origen, servicios autoritativos correctamente configurados, limitación de tasa, distribución de capacidad, protección especializada y planes de contingencia.

Los ataques de baja tasa, como Slowloris o R.U.D.Y., intentan mantener muchas conexiones abiertas enviando datos muy lentamente. Consumen recursos con poco caudal y pueden confundirse con clientes lentos. Se mitigan con límites de tiempo, tamaño y concurrencia; proxies inversos; balanceadores; y servidores preparados para gestionar conexiones asíncronas.

3.5. Explotación, malware y movimiento lateral

La explotación de vulnerabilidades puede permitir ejecución remota de código, elevación de privilegios, acceso a memoria, evasión de autenticación o manipulación de servicios. Los fallos de desbordamiento, inyección, deserialización, autenticación y configuración insegura se combinan a menudo con credenciales obtenidas por phishing o reutilización de contraseñas.

El malware incluye troyanos, gusanos, spyware, ransomware, puertas traseras y herramientas de control remoto. Un gusano se propaga aprovechando servicios vulnerables; el ransomware cifra y, con frecuencia, exfiltra información antes de extorsionar; una puerta trasera mantiene acceso persistente. Una vez dentro, el adversario realiza movimiento lateral, busca cuentas privilegiadas, accede a repositorios y trata de alcanzar sistemas de mayor valor.

3.6. Cadena de suministro, nube, IoT y enrutamiento

La cadena de suministro amplía el riesgo a fabricantes, bibliotecas, actualizaciones, prestadores y canales de distribución. Una actualización firmada por una infraestructura comprometida puede atravesar controles tradicionales porque procede de una fuente confiable. Las mitigaciones incluyen evaluación de proveedores, inventario de componentes, verificación de firmas, segregación de entornos de construcción, listas de materiales de software y monitorización de comportamientos posteriores a la instalación.

Los dispositivos IoT y equipos especializados suelen presentar ciclos de soporte largos, credenciales por defecto, servicios innecesarios o capacidad limitada para agentes de seguridad. Deben aislarse, inventariarse y administrarse mediante pasarelas y reglas específicas. En Internet, los incidentes de BGP pueden desviar prefijos por error o ataque; la validación de origen de rutas mediante RPKI y la coordinación con operadores reducen parte del riesgo.

4. ARQUITECTURA SEGURA, SEGMENTACIÓN Y DEFENSA EN PROFUNDIDAD

4.1. Zonas de seguridad y flujos

La segmentación divide la infraestructura en zonas con niveles de confianza, funciones y requisitos diferentes. El objetivo no es crear VLAN por razones meramente organizativas, sino reducir la superficie de ataque, controlar los flujos y limitar la propagación. Una zona puede agrupar puestos corporativos, servidores de aplicación, bases de datos, administración, dispositivos médicos, invitados, desarrollo, copias de seguridad o servicios publicados. Entre zonas se interponen controles que aplican política y registran comunicaciones.

El diseño comienza con una matriz de flujos: origen, destino, protocolo, puerto, sentido, propietario, finalidad, criticidad y justificación. Las reglas se derivan de necesidades reales y se revisan cuando cambia el servicio. Las aperturas amplias del tipo “cualquier origen a cualquier destino” dificultan la trazabilidad y convierten una vulnerabilidad local en un incidente transversal.

4.2. Segmentación física, lógica y microsegmentación

La separación física ofrece aislamiento fuerte, pero aumenta coste y complejidad. La segmentación lógica utiliza VLAN, VRF, ACL, cortafuegos internos, políticas de red definidas por software o mecanismos de nube. Una VLAN separa dominios de difusión, pero por sí sola no garantiza seguridad: el tráfico entre VLAN debe atravesar un punto de control correctamente configurado.

La microsegmentación aplica políticas a cargas o identidades concretas, incluso dentro de una misma zona. Puede basarse en etiquetas, grupos de seguridad, agentes de host o redes virtuales. Es especialmente útil en centros de datos y nubes, donde el tráfico este-oeste entre servidores puede superar al tráfico norte-sur hacia Internet. Su dificultad reside en descubrir dependencias sin interrumpir aplicaciones; suele desplegarse observando primero, modelando flujos y pasando después a modo de bloqueo.

4.3. DMZ y publicación de servicios

Una zona desmilitarizada alberga servicios accesibles desde redes menos confiables sin exponer directamente la red interna. Un proxy inverso, un WAF, una pasarela de correo o un servidor de transferencia pueden situarse en la DMZ. El acceso desde la DMZ hacia sistemas internos debe ser mínimo y específico; por ejemplo, un frontal web no debería poder administrar la base de datos ni iniciar conexiones arbitrarias hacia puestos de usuario.

4.4. Plano de gestión y acceso administrativo

El plano de gestión merece una protección superior porque permite cambiar configuraciones, leer registros y controlar dispositivos. Debe separarse del tráfico de usuario, requerir autenticación fuerte, restringirse a estaciones de administración, utilizar protocolos seguros y registrar las sesiones. Las interfaces web o SSH de routers y cortafuegos no deben exponerse a Internet salvo que exista una necesidad excepcional y controles adicionales.

Las redes de administración fuera de banda permiten gestionar equipos aunque falle el plano de datos, pero también crean un camino privilegiado que debe protegerse. Las credenciales compartidas deben evitarse; es preferible usar identidades nominativas, bastiones, gestión de acceso privilegiado, aprobación temporal y rotación de secretos.

4.5. Resiliencia y diversidad

La alta disponibilidad requiere eliminar puntos únicos de fallo: pares de cortafuegos, enlaces redundantes, rutas alternativas, balanceo y alimentación protegida. Sin embargo, duplicar componentes con la misma configuración defectuosa no aporta seguridad frente a errores lógicos. La resiliencia combina redundancia, diversidad razonable, pruebas de conmutación, copias de configuración y procedimientos de recuperación.

5. CORTAFUEGOS Y PASARELAS DE SEGURIDAD

5.1. Concepto y funciones

Un cortafuegos controla el flujo de tráfico entre redes o hosts con posturas de seguridad diferentes. Evalúa paquetes y conexiones frente a una política y decide permitir, rechazar, descartar, traducir, registrar o redirigir. Puede implantarse como equipo físico, máquina virtual, función nativa de nube, software de host o servicio gestionado. Su eficacia depende tanto de las capacidades del producto como de la calidad de las reglas, la visibilidad, el mantenimiento y la integración operativa.

El cortafuegos no “sabe” por sí mismo qué tráfico es legítimo. La organización debe convertir requisitos de negocio y seguridad en reglas verificables. La política debe incluir tráfico entrante, saliente y lateral; administración; servicios publicados; resolución de nombres; sincronización horaria; actualizaciones; copias; monitorización; y comunicaciones de terceros.

5.2. Tipos de cortafuegos

El término NGFW describe cortafuegos con inspección profunda, identificación de aplicaciones independientemente del puerto, integración con identidades, filtrado de contenidos y funciones de prevención de intrusiones. No existe una frontera normativa única: las capacidades concretas deben evaluarse en el producto y la arquitectura.

5.3. Reglas, objetos y política

Las reglas se procesan normalmente en orden, por lo que una regla amplia puede ocultar otras más específicas. Las buenas prácticas incluyen denegación por defecto, objetos con nombres significativos, comentarios y propietario, separación de administración, caducidad de aperturas temporales, revisión de reglas no utilizadas y comprobación de reglas redundantes o sombreadas. La política de salida también es importante: limitar conexiones salientes dificulta mando y control, exfiltración y uso de resolutores o túneles no autorizados.

Ejemplo conceptual de matriz de regla
Origen: zona-aplicacion
Destino: servicio-base-datos
Servicio: protocolo y puerto estrictamente requeridos
Acción: permitir
Registro: inicio y cierre de sesión, según capacidad
Propietario: responsable del servicio
Caducidad/revisión: fecha definida

La traducción de direcciones NAT no es un control de seguridad equivalente a un cortafuegos. Puede ocultar direccionamiento interno y limitar conexiones entrantes no asociadas, pero no autentica usuarios, no valida aplicaciones y no reemplaza una política explícita.

5.4. Inspección de TLS

El cifrado protege frente a observadores, pero también reduce la visibilidad de dispositivos intermedios. La inspección TLS empresarial establece dos sesiones: una entre cliente y pasarela y otra entre pasarela y servidor. Para que el cliente no muestre un error, debe confiar en una autoridad de certificación controlada por la organización, que emite certificados dinámicos para la inspección. Esta técnica permite analizar contenido, pero introduce riesgos de privacidad, custodia de claves, compatibilidad, degradación criptográfica y concentración de confianza.

Las aplicaciones con certificate pinning, autenticación mutua o protocolos no compatibles pueden fallar. Deben definirse exclusiones justificadas, protegerse rigurosamente la clave de la CA de inspección y evitar que la pasarela negocie parámetros más débiles que los extremos. También se debe informar y gobernar el tratamiento de datos conforme a la normativa y la finalidad legítima.

5.5. WAF, proxy, filtrado DNS y otras pasarelas

Un WAF protege aplicaciones HTTP frente a patrones y comportamientos de capa de aplicación. No sustituye al cortafuegos de red ni corrige código vulnerable; actúa como control compensatorio y fuente de telemetría. Los proxies web controlan navegación y pueden aplicar reputación, categorías, autenticación y aislamiento. El filtrado DNS bloquea dominios conocidos o políticas de resolución, pero debe evitar falsos positivos y contemplar resoluciones cifradas no autorizadas.

5.6. Operación y validación

La gestión incluye copia de configuraciones, control de cambios, separación entre desarrollo y producción, actualización de firmas y software, pruebas de alta disponibilidad, revisión de capacidad y análisis de registros. Una regla aprobada debe validarse desde el origen real y comprobar que no abre caminos adicionales. Las revisiones periódicas deben retirar reglas huérfanas de proyectos finalizados.

6. DETECCIÓN Y PREVENCIÓN DE INTRUSIONES

6.1. IDS, IPS y objetivos

Un IDS analiza eventos y genera alertas sobre actividad sospechosa. Un IPS se sitúa en línea o dispone de capacidad de respuesta para bloquear, descartar, reiniciar conexiones o modificar políticas. La diferencia no es el método de detección, sino la posibilidad y el modo de actuar. Un mismo motor puede operar inicialmente en modo detección y pasar a prevención cuando las firmas y umbrales se han ajustado.

Bloquear automáticamente aumenta la capacidad de respuesta, pero también el impacto de un falso positivo. En servicios críticos es habitual aplicar prevención a firmas de alta confianza y mantener en alerta aquellas que necesitan contexto. Las respuestas deben ser reversibles, auditables y coordinadas con el equipo de operación.

6.2. Fuentes y tipos

• NIDS/NIPS: analiza tráfico de segmentos de red mediante puertos espejo, TAP o inserción en línea.
• HIDS/HIPS: observa procesos, archivos, llamadas, registros y conexiones de un host.
• WIDS/WIPS: vigila el espectro y las redes inalámbricas, detectando puntos de acceso no autorizados, suplantación o ataques de gestión.
• NDR: combina telemetría, análisis de comportamiento y respuesta sobre tráfico de red, con atención al movimiento lateral.
• EDR/XDR: amplía la detección y respuesta en endpoints y correlaciona, según producto, múltiples dominios.

6.3. Métodos de detección

La detección moderna suele combinar métodos. Una firma puede identificar una explotación conocida; una anomalía puede revelar transferencia inusual; y la correlación con identidad y criticidad permite priorizar el incidente. El aprendizaje automático no elimina la necesidad de datos de calidad, ajuste y revisión humana.

6.4. Colocación de sensores y tráfico cifrado

Los sensores deben situarse donde observen flujos relevantes: perímetro, DMZ, enlaces entre zonas, centros de datos, salida de usuarios y redes inalámbricas. La duplicación de tráfico puede provocar alertas repetidas; la sobrecarga puede causar pérdida de paquetes. En entornos virtuales y nube, la visibilidad exige telemetría de conmutadores virtuales, agentes o funciones nativas.

El tráfico cifrado limita la inspección de contenido, pero conserva metadatos útiles: destinos, certificados, tamaños, frecuencia, duración y comportamiento. Se puede analizar antes del cifrado en el endpoint, después de la terminación TLS en un proxy o mediante registros de aplicación. La inspección no debe convertirse en una excepción generalizada a la confidencialidad.

6.5. Falsos positivos, falsos negativos y calidad

Un falso positivo consume tiempo y puede interrumpir servicios; un falso negativo deja pasar un ataque. La calidad se mejora con contexto de activos, criticidad, vulnerabilidades, inteligencia de amenazas, perfiles de usuario y pruebas controladas. Los indicadores de rendimiento deben medir cobertura, tiempo de detección, tiempo de respuesta, precisión, volumen gestionable y casos sin telemetría.

6.6. SIEM, SOAR y correlación

Un SIEM centraliza, normaliza y correlaciona registros de cortafuegos, sistemas, aplicaciones, identidad, nube y dispositivos. El SOAR automatiza flujos de enriquecimiento y respuesta, por ejemplo consultar reputación, aislar un equipo o abrir una incidencia. La automatización debe usar controles de seguridad, aprobaciones y límites para no amplificar un error.

Secuencia de correlación conceptual
1. Inicio de sesión desde contexto anómalo
2. Enumeración de recursos internos
3. Uso de privilegio elevado
4. Transferencia de datos inusual
5. Conexión a destino de riesgo
Resultado: incidente priorizado por cadena de evidencias

7. CONTROL DE ACCESOS, IDENTIDAD Y NAC

7.1. Identificación, autenticación, autorización y auditoría

La identidad digital representa a personas, dispositivos, aplicaciones y servicios. La autenticación verifica una pretensión de identidad mediante credenciales; la autorización decide acciones permitidas; y la auditoría registra el uso. Las cuentas de servicio y las identidades de máquina son tan importantes como las humanas: un certificado, token o secreto comprometido puede dar acceso automatizado a numerosos recursos.

La gestión del ciclo de vida incluye alta, modificación, revisión y baja. Los permisos deben ajustarse cuando cambia la función y revocarse sin demora al terminar la relación. Las cuentas inactivas, huérfanas o compartidas son un riesgo porque conservan acceso sin responsabilidad clara.

7.2. Factores y autenticación multifactor

Los factores se clasifican en conocimiento —algo que se sabe—, posesión —algo que se tiene— e inherencia —algo que se es—. La autenticación multifactor combina factores independientes. Dos contraseñas no son dos factores; contraseña y código generado por un autenticador sí pueden serlo. Los métodos resistentes al phishing, basados en criptografía y vinculados al origen, ofrecen mayor protección que códigos que el usuario puede entregar a una página fraudulenta.

NIST SP 800-63B-4 organiza requisitos por niveles de garantía del autenticador y destaca la resistencia al phishing en los niveles superiores. En una organización, la elección debe considerar riesgo, recuperación, accesibilidad, soporte y protección frente a robo de sesión. MFA no compensa una autorización excesiva ni evita que un malware opere después del inicio de sesión.

7.3. Modelos DAC, MAC, RBAC y ABAC

RBAC simplifica la asignación cuando los permisos siguen funciones estables. ABAC permite decisiones como autorizar a un profesional de una unidad, desde un dispositivo conforme, durante una guardia y para un tipo de dato concreto. Ambos pueden combinarse. La política debe ser comprensible y verificable para evitar autorizaciones contradictorias.

7.4. Gestión de acceso privilegiado

Las cuentas administrativas requieren controles reforzados: separación de cuenta normal y privilegiada, MFA, bastión, grabación de sesión, custodia de secretos, rotación, acceso justo a tiempo y aprobación. El modelo just enough administration limita comandos o recursos concretos. Los privilegios permanentes amplían el impacto de una credencial comprometida.

7.5. Network Access Control

NAC decide si un dispositivo puede conectarse y qué acceso recibe. Puede verificar identidad, tipo de equipo, certificado, versión, cifrado, estado de protección y cumplimiento de políticas. Según el resultado, asigna VLAN, rol, lista de control, acceso de remediación o cuarentena. La evaluación debe contemplar equipos sin agente, dispositivos médicos y otros elementos especializados.

IEEE 802.1X define control de acceso basado en puerto. Intervienen el supplicant del dispositivo, el authenticator —conmutador o punto de acceso— y el servidor de autenticación, normalmente mediante RADIUS. EAP transporta métodos de autenticación; EAP-TLS utiliza certificados y proporciona autenticación robusta cuando se administra correctamente la PKI.

7.6. RADIUS y TACACS+

RADIUS se utiliza ampliamente para acceso a red y concentra autenticación, autorización y contabilidad. TACACS+ se asocia con frecuencia a administración de dispositivos y permite separar funciones de AAA con granularidad de comandos, aunque su despliegue debe proteger el transporte según la solución y los estándares aplicables. No deben confundirse con mecanismos de cifrado de datos de usuario.

8. SEGURIDAD EN REDES INALÁMBRICAS

8.1. Riesgos propios del medio radio

En una red cableada el atacante suele necesitar acceso físico o lógico a la infraestructura; en Wi-Fi puede recibir señales fuera del edificio. El medio compartido facilita escucha, interferencia, suplantación y ataques contra tramas de gestión. La cobertura debe diseñarse para prestar servicio, no para confiar en que las paredes actúan como control de seguridad.

Las amenazas incluyen puntos de acceso no autorizados, evil twin, robo de credenciales en portales falsos, ataques de desautenticación, claves compartidas divulgadas, configuraciones WPS inseguras, clientes que se conectan automáticamente y dispositivos que exponen redes personales.

8.2. WEP, WPA2 y WPA3

WEP es inseguro y no debe utilizarse. WPA2 consolidó el uso de AES-CCMP en redes modernas; en modo personal comparte una contraseña y en modo Enterprise utiliza 802.1X/EAP. WPA3-Personal emplea SAE para mejorar la resistencia frente a ataques fuera de línea sobre la contraseña. WPA3-Enterprise mantiene autenticación empresarial y ofrece perfiles de mayor seguridad según la certificación y el entorno.

Las tramas de gestión protegidas, asociadas a IEEE 802.11w e integradas en revisiones posteriores de 802.11, reducen determinados ataques de falsificación de desautenticación y desasociación. No impiden interferencias de radio ni todos los ataques de disponibilidad.

8.3. Diseño empresarial

Una WLAN corporativa debe separar al menos usuarios internos, invitados y dispositivos especializados. La red de invitados no debe convertirse en una puerta hacia sistemas internos; necesita aislamiento de clientes, salida controlada y condiciones de uso. La red corporativa debe preferir autenticación individual, certificados y asignación dinámica de política. Las claves precompartidas comunes dificultan la revocación y la trazabilidad.

El servidor y el cliente deben validar correctamente los certificados en EAP. Si el usuario acepta cualquier certificado de servidor, un punto de acceso malicioso podría capturar credenciales o provocar una autenticación degradada. La configuración administrada del perfil Wi-Fi evita que cada usuario decida parámetros críticos.

8.4. Detección y operación

La vigilancia inalámbrica identifica AP desconocidos, SSID suplantados, cambios de canal, interferencias y estaciones anómalas. Debe combinarse con inventario y localización física: un AP detectado puede ser corporativo, vecino o malicioso. El análisis de espectro ayuda a diferenciar problemas de seguridad de interferencias no Wi-Fi.

9. TÉCNICAS CRIPTOGRÁFICAS Y GESTIÓN DE CLAVES

9.1. Servicios criptográficos

La criptografía aporta confidencialidad, integridad, autenticación y firma, pero cada mecanismo resuelve propiedades diferentes. Cifrar no demuestra por sí solo quién originó el mensaje; una función hash sin clave no autentica; y una firma digital no oculta el contenido. Los protocolos combinan primitivas para obtener un canal seguro.

9.2. Cifrado simétrico

En el cifrado simétrico, emisor y receptor comparten una clave secreta. Es eficiente y adecuado para grandes volúmenes, pero exige distribuir y proteger claves. AES, normalizado en FIPS 197, opera con bloques de 128 bits y claves de 128, 192 o 256 bits. La actualización editorial de FIPS 197 de 2023 no modificó técnicamente el algoritmo.

El modo de operación es tan importante como el algoritmo. Los modos AEAD, como AES-GCM o ChaCha20-Poly1305, cifran y autentican datos y metadatos asociados. Reutilizar un nonce cuando el modo exige unicidad puede destruir la seguridad. ECB revela patrones y no es adecuado para proteger mensajes estructurados. CBC necesita autenticación separada y una implementación cuidadosa.

9.3. Criptografía asimétrica

La criptografía de clave pública utiliza un par relacionado: una clave pública distribuible y una clave privada que debe permanecer bajo control del titular. RSA puede emplearse en cifrado y firma según el esquema, aunque en protocolos modernos se usa con frecuencia para autenticación mediante firma. La criptografía de curva elíptica ofrece seguridad comparable con claves más pequeñas y se usa en acuerdos de clave y firmas.

El acuerdo Diffie-Hellman permite derivar un secreto compartido sobre un canal inseguro. Las variantes efímeras aportan secreto hacia adelante: si la clave de autenticación se compromete en el futuro, las sesiones pasadas no se descifran automáticamente. El acuerdo de clave debe estar autenticado para evitar intermediación.

9.4. Funciones hash, HMAC y contraseñas

Una función hash criptográfica produce un resumen de longitud fija y debe resistir preimagen, segunda preimagen y colisiones. SHA-2 y SHA-3 son familias vigentes; MD5 y SHA-1 no deben usarse para firmas o integridad criptográfica debido a colisiones. CRC detecta errores accidentales, pero no es un hash criptográfico.

HMAC combina una función hash con una clave para autenticar mensajes. Para almacenar contraseñas no basta con aplicar SHA-256 una vez: deben utilizarse funciones de derivación lentas y parametrizables, como Argon2id, scrypt, bcrypt o PBKDF2 según política y plataforma, con sal única y coste adecuado. El objetivo es encarecer cada intento de fuerza bruta.

9.5. Firmas digitales y PKI

Una firma se genera con la clave privada y se verifica con la pública. Aporta integridad y autenticidad del firmante cuando la clave y su identidad están vinculadas de forma fiable. Una PKI gestiona certificados, autoridades de certificación, autoridades de registro, repositorios, revocación y políticas. El certificado no “cifra Internet”; vincula una clave pública con una identidad bajo las condiciones de una autoridad.

La validación comprueba cadena de confianza, vigencia, uso permitido, nombre, firma y estado de revocación mediante CRL u OCSP cuando proceda. Un certificado válido criptográficamente puede ser inadecuado si el nombre no coincide o el uso de clave no autoriza la finalidad.

9.6. Gestión del ciclo de vida de claves

Las claves deben generarse con entropía suficiente, almacenarse en contenedores protegidos, distribuirse por canales adecuados, rotarse, revocarse, archivarse o destruirse según su función. Los HSM y servicios de gestión de claves reducen la exposición de claves maestras y permiten separación de funciones. Las copias de seguridad de claves de cifrado son necesarias para recuperar datos; las claves de firma requieren controles que eviten su uso no autorizado.

La criptografía falla a menudo por gestión, no por matemática: secretos en código, certificados caducados, claves compartidas entre entornos, permisos excesivos o algoritmos heredados. La agilidad criptográfica permite sustituir algoritmos y claves sin rediseñar todo el sistema.

9.7. Transición poscuántica

NIST publicó en 2024 FIPS 203 para ML-KEM, FIPS 204 para ML-DSA y FIPS 205 para firmas hash sin estado. Esto no convierte en insegura de inmediato toda criptografía clásica, pero obliga a inventariar dónde se usan RSA, Diffie-Hellman y curvas elípticas, valorar la vida útil de la información y preparar migraciones. El riesgo “capturar ahora y descifrar después” afecta a datos que deben permanecer confidenciales durante muchos años.

10. PROTOCOLOS DE COMUNICACIÓN SEGURA Y VPN

10.1. TLS

TLS protege protocolos de aplicación frente a escucha, alteración y falsificación. Se sitúa conceptualmente entre la aplicación y el transporte. El handshake negocia versión y algoritmos, autentica normalmente al servidor mediante certificado, puede autenticar al cliente y deriva claves simétricas de sesión. Después, el protocolo de registros protege los datos con cifrado autenticado.

TLS 1.0 y 1.1 están deprecados por RFC 8996. TLS 1.3 se definió en RFC 8446 y constituye la referencia fundamental para la versión 1.3; RFC 9325 reúne recomendaciones de uso seguro de TLS y DTLS. En sistemas heredados puede mantenerse TLS 1.2 bajo perfiles restrictivos cuando exista una necesidad de compatibilidad justificada, pero los diseños nuevos deben evitar protocolos y suites obsoletos y seguir las recomendaciones criptográficas vigentes de la organización.

TLS 1.3 elimina suites antiguas, utiliza AEAD y favorece acuerdos efímeros. La modalidad 0-RTT reduce latencia en reanudación, pero los datos tempranos pueden ser reproducibles; las operaciones no idempotentes requieren cautela. La seguridad depende de validar el nombre y la cadena, proteger claves privadas y configurar versiones y algoritmos.

10.2. IPsec e IKEv2

IPsec proporciona servicios de seguridad en la capa IP para IPv4 e IPv6. La arquitectura de RFC 4301 utiliza asociaciones de seguridad y políticas que deciden qué tráfico se descarta, se deja pasar o se protege. ESP, definido en RFC 4303, puede aportar confidencialidad, integridad y autenticación; AH ofrece autenticación e integridad, pero su uso es menos común y presenta dificultades con NAT.

IKEv2, RFC 7296 y actualizaciones, negocia asociaciones, algoritmos, claves y autenticación. IPsec puede operar en modo transporte, protegiendo la carga IP entre hosts, o en modo túnel, encapsulando el paquete original, habitual en VPN de red a red o acceso remoto. La política debe definir selectores, rutas, DNS, autenticación, renovación y comportamiento ante caída.

10.3. SSH

SSH ofrece inicio de sesión remoto y otros servicios seguros sobre una red insegura. RFC 4253 define el transporte y ha sido actualizado por RFC posteriores para algoritmos modernos. SSH negocia intercambio de claves, clave de host, cifrado e integridad. La clave de host permite detectar que el servidor ha cambiado; aceptar ciegamente una huella nueva elimina esa protección.

La administración debe preferir autenticación robusta, desactivar algoritmos obsoletos, limitar usuarios y orígenes, proteger claves privadas y registrar accesos. Los túneles SSH son útiles, pero pueden eludir controles si se permiten sin gobierno.

10.4. DNSSEC, DoT y DoH

DNSSEC firma datos DNS para que el resolutor valide autenticidad e integridad; no cifra las consultas. DNS over TLS y DNS over HTTPS cifran el transporte entre cliente y resolutor, pero no garantizan que la respuesta sea correcta si no existe validación adecuada. La organización debe decidir resolutores autorizados, registro, privacidad y filtrado, evitando que clientes usen servicios externos que eludan la política.

10.5. VPN frente a ZTNA

Una VPN crea conectividad protegida a una red o conjunto de rutas. ZTNA publica acceso a aplicaciones concretas basándose en identidad y contexto, sin exponer necesariamente toda la red. No son excluyentes: una organización puede conservar VPN para administración o protocolos no adaptados y usar ZTNA para aplicaciones. La selección depende de requisitos, no de una sustitución automática.

11. ARQUITECTURA ZERO TRUST, ZTNA Y SASE

11.1. Principios de Zero Trust

Zero Trust elimina la confianza implícita basada únicamente en ubicación de red, propiedad del equipo o pertenencia organizativa. NIST SP 800-207 centra la protección en recursos: cada solicitud se evalúa explícitamente, el acceso se limita por sesión y recurso, y la decisión incorpora identidad, estado del dispositivo, comportamiento, sensibilidad y contexto. Se asume que puede existir compromiso y se reduce el radio de impacto.

“Nunca confiar, verificar siempre” es una síntesis útil, pero no significa desconfiar arbitrariamente ni autenticar al usuario cada segundo. Significa que la confianza es calculada, limitada, revisable y respaldada por evidencias. La experiencia puede ser transparente cuando se emplean señales continuas y autenticadores adecuados.

11.2. Componentes lógicos

En el modelo NIST, el policy engine toma decisiones, el policy administrator establece o revoca el camino de comunicación y el policy enforcement point aplica la decisión. Las fuentes de información incluyen identidad, inventario, postura, inteligencia de amenazas, registros y políticas. La separación lógica no obliga a productos distintos.

11.3. Microsegmentación y acceso por aplicación

La microsegmentación reduce el movimiento lateral y ZTNA concede conectividad a aplicaciones concretas. La política debe evitar que el acceso a una aplicación implique descubrir otras redes. Los conectores de aplicación pueden iniciar conexiones salientes hacia el servicio de acceso, reduciendo exposición entrante. Aun así, la arquitectura debe proteger el plano de control, los conectores y las identidades de servicio.

11.4. SASE y SSE

SASE es un modelo arquitectónico que converge conectividad WAN y funciones de seguridad distribuidas desde servicios cercanos al usuario. Suele integrar SD-WAN, ZTNA, pasarela web segura, CASB y cortafuegos como servicio. SSE agrupa principalmente las funciones de seguridad sin la parte completa de conectividad WAN. No son estándares de protocolo y su alcance varía entre proveedores.

11.5. Implantación gradual

La transición comienza con inventario de recursos y flujos, identidad consolidada, MFA, gestión de dispositivos y telemetría. Después se seleccionan casos de uso: acceso remoto a una aplicación, administración privilegiada, terceros o microsegmentación de una zona crítica. Intentar implantar Zero Trust comprando una única plataforma sin corregir identidades y datos conduce a una capa adicional de complejidad.

Las métricas deben observar accesos de privilegio, decisiones denegadas, dispositivos no conformes, movimientos laterales, tiempo de revocación y cobertura de recursos. La disponibilidad del motor de política y de los puntos de aplicación es crítica; una arquitectura de seguridad que bloquea toda la organización por una caída central necesita modos de continuidad controlados.

12. MEDIDAS ESPECÍFICAS PARA COMUNICACIONES MÓVILES

12.1. Superficie de ataque móvil

Un dispositivo móvil concentra comunicaciones, credenciales, cámara, micrófono, localización, aplicaciones y acceso corporativo. Puede perderse, ser robado, conectarse a redes hostiles, instalar aplicaciones maliciosas o quedar sin soporte. Además, combina canales celulares, Wi-Fi, Bluetooth, NFC y USB, cada uno con políticas y amenazas distintas.

Las medidas deben cubrir el ciclo completo: adquisición, alta, configuración, operación, actualización, incidente, reasignación y retirada. NIST SP 800-124 Rev. 2 recomienda gestión centralizada y controles para dispositivos corporativos y personales autorizados.

12.2. MDM, UEM y protección del endpoint

MDM aplica políticas de bloqueo, cifrado, versión, certificados, redes, inventario y borrado remoto. UEM amplía la gestión a diferentes tipos de endpoint. La gestión de aplicaciones controla instalación, permisos, configuración y distribución; la contenedorización separa datos corporativos de personales. Un agente de defensa móvil puede detectar aplicaciones dañinas, redes de riesgo, phishing y compromiso del sistema.

Las políticas deben exigir bloqueo seguro, cifrado del dispositivo, actualización, prohibición o control de root/jailbreak, copia de seguridad autorizada, instalación desde orígenes gestionados y revocación de acceso. El borrado remoto depende de que el terminal reciba la orden; por ello el cifrado y el bloqueo siguen siendo esenciales.

12.3. BYOD, COPE y elección de modelo

BYOD no debe adoptarse solo por ahorro aparente. Deben definirse datos accesibles, requisitos mínimos, consentimiento de gestión, privacidad, soporte, respuesta a pérdida y retirada. El acceso puede limitarse a aplicaciones virtualizadas o contenedores sin almacenar datos clínicos localmente.

12.4. Redes celulares y evolución

GSM de segunda generación autenticaba principalmente al abonado ante la red y presentaba debilidades frente a estaciones base falsas. 3G introdujo autenticación mutua mediante AKA; 4G reforzó la arquitectura y 5G añadió nuevas funciones y separación de dominios. Por tanto, es incorrecto afirmar que la autenticación mutua apareció por primera vez en 5G.

3GPP TS 33.501 define la arquitectura y procedimientos de seguridad del sistema 5G. Entre sus elementos están 5G-AKA y EAP-AKA’, separación de funciones, protección entre redes y mecanismos de privacidad de identidad. El identificador permanente se denomina SUPI; el terminal puede transmitir un SUCI que oculta el SUPI mediante un esquema configurado para que la red doméstica lo recupere. La protección concreta depende del perfil y las reglas 3GPP, por lo que no debe simplificarse como “el SUPI siempre viaja cifrado” sin matices.

12.5. Riesgos de 5G

5G incrementa el uso de virtualización, funciones nativas de nube, API de arquitectura basada en servicios, network slicing y computación en el borde. Esto aporta flexibilidad, pero traslada riesgos de software, orquestación, identidad de servicios, aislamiento y cadena de suministro. Una vulnerabilidad en el plano de gestión puede afectar numerosas funciones virtualizadas.

El slicing necesita aislamiento lógico, política, monitorización y control de recursos; no debe asumirse que una “rebanada” es físicamente independiente. El edge acerca datos y procesamiento, pero distribuye infraestructura y exige gestión coherente de claves, parches y acceso.

12.6. Wi-Fi, Bluetooth, NFC y USB

El terminal debe evitar conexiones automáticas a redes abiertas, validar perfiles corporativos, usar VPN o acceso por aplicación cuando proceda y desactivar interfaces innecesarias. Bluetooth requiere emparejamiento seguro, visibilidad limitada y actualización; NFC tiene corto alcance, pero no elimina ataques de relay; USB puede introducir datos, carga maliciosa o depuración no autorizada.

12.7. Aplicaciones y datos

Las aplicaciones deben solicitar los permisos mínimos, almacenar secretos en almacenes seguros, usar TLS con validación correcta, evitar registrar datos sensibles y proteger sesiones. Los tokens deben ser revocables y de vida limitada. El desarrollo debe contemplar capturas de pantalla, portapapeles, copias en nubes personales, notificaciones y enlaces profundos.

13. OPERACIÓN SEGURA, VULNERABILIDADES E INCIDENTES

13.1. Inventario y configuración segura

No se puede proteger lo que no se conoce. El inventario debe relacionar activos, propietario, ubicación, versión, función, criticidad, dependencias, exposición y soporte. El descubrimiento automático debe reconciliarse con fuentes administrativas para detectar equipos no gestionados. Las configuraciones base reducen servicios, cuentas y protocolos innecesarios y definen parámetros reproducibles.

13.2. Gestión de vulnerabilidades y parcheado

El proceso incluye identificación, validación, priorización, remediación y verificación. La puntuación técnica de una vulnerabilidad no basta: deben considerarse exposición, explotación activa, controles compensatorios e impacto asistencial. En equipos médicos o sistemas heredados donde no es posible parchear de inmediato se aplican aislamiento, listas permitidas, monitorización, restricción de administración y plan de sustitución.

Las pruebas deben evitar indisponibilidad. Un escaneo agresivo puede afectar dispositivos frágiles; se coordinan ventanas, perfiles seguros y responsables. La excepción de parcheado debe documentar riesgo, control compensatorio y fecha de revisión.

13.3. Registros, tiempo y conservación

Los registros deben contener identidad, origen, destino, acción, resultado y tiempo suficiente para reconstruir eventos. La sincronización horaria es esencial para correlacionar sistemas. Los logs críticos se centralizan y protegen contra alteración; el acceso a ellos también se audita. Registrar todo sin capacidad de análisis genera coste y ruido, por lo que se definen casos de uso y retención.

13.4. Respuesta a incidentes

La respuesta comprende preparación, detección y análisis, contención, erradicación, recuperación y lecciones aprendidas. La contención puede aislar equipos, bloquear indicadores, revocar credenciales o segmentar servicios. Debe equilibrarse con continuidad: apagar un sistema clínico sin coordinación puede causar más daño que una contención gradual.

Flujo operativo resumido
Alerta → validación → clasificación → contención
       → adquisición de evidencias → erradicación
       → recuperación controlada → vigilancia reforzada
       → informe y mejoras

La preservación de evidencias exige registrar quién recoge qué, cuándo y cómo. Las acciones destructivas deben posponerse cuando sea posible hasta capturar información volátil. El equipo técnico se coordina con responsables de seguridad, protección de datos, continuidad, comunicación y dirección.

13.5. Copias, continuidad y ransomware

Las copias deben estar separadas, protegidas contra modificación, probadas y dimensionadas según objetivos de recuperación. Una copia conectada permanentemente con las mismas credenciales puede ser cifrada por ransomware. La estrategia combina versiones, almacenamiento inmutable o aislado, pruebas de restauración y procedimientos para reconstruir identidades, red y servicios.

13.6. Gestión de proveedores

Los terceros reciben acceso mínimo, temporal, monitorizado y revocable. Los contratos deben definir obligaciones de seguridad, notificación, evidencia, subcontratación, actualización y devolución de datos. El acceso remoto de mantenimiento debe atravesar puntos controlados y no depender de cuentas compartidas o servicios permanentes ocultos.

14. APLICACIÓN EN EL SAS Y EN LA ADMINISTRACIÓN PÚBLICA ANDALUZA

14.1. Particularidades del entorno sanitario

El Servicio Andaluz de Salud opera servicios distribuidos, con alta dependencia de comunicaciones y mezcla de tecnologías corporativas, clínicas y especializadas. La seguridad debe considerar centros con tamaños diferentes, movilidad profesional, sistemas asistenciales, dispositivos médicos, acceso de proveedores y necesidad de continuidad. Las paradas pueden afectar directamente a la atención, por lo que el análisis de impacto y los procedimientos degradados son parte de la arquitectura.

Los datos de salud exigen confidencialidad, pero el acceso debe ser ágil para quien participa legítimamente en la asistencia. La identidad nominativa, los perfiles por función, la trazabilidad y la revisión de accesos son esenciales. La segmentación evita que un incidente en puestos, invitados o equipos especializados alcance automáticamente aplicaciones y datos críticos.

14.2. Esquema Nacional de Seguridad

El Real Decreto 311/2022 regula el Esquema Nacional de Seguridad. Sus principios básicos incluyen seguridad integral, gestión basada en riesgos, prevención, detección, respuesta y conservación, líneas de defensa, vigilancia continua y reevaluación periódica, diferenciación de responsabilidades y proporcionalidad. La categoría del sistema y los niveles de las dimensiones orientan la selección de medidas.

En red, el ENS se traduce en arquitectura documentada, protección de comunicaciones, segregación, autenticación, mínimo privilegio, registro, gestión de vulnerabilidades, continuidad y control de interconexiones. Las guías CCN-STIC proporcionan apoyo técnico para implantar medidas, aunque la solución concreta depende del sistema y el riesgo.

14.3. Trazabilidad y acceso clínico

Las sesiones compartidas o usuarios genéricos dificultan atribuir acciones, investigar incidentes y demostrar cumplimiento. Los terminales de uso compartido pueden mantener rapidez mediante autenticación adecuada, proximidad, tarjetas o mecanismos de sesión, pero la acción debe quedar vinculada al profesional. Los logs deben centralizarse y protegerse.

14.4. Concienciación y cultura

La formación debe adaptarse a funciones: profesionales asistenciales, administración, soporte, desarrollo, sistemas y dirección afrontan riesgos distintos. Debe cubrir phishing, manejo de credenciales, dispositivos extraíbles, notificación temprana, datos sensibles y acceso remoto. Las simulaciones y métricas deben usarse para mejorar, no para culpabilizar.

14.5. Patrón de arquitectura aplicable

Este patrón es conceptual y debe adaptarse a la arquitectura real autorizada. No implica afirmar que todos los centros utilicen exactamente las mismas tecnologías. La decisión correcta se basa en inventario, criticidad, diseño corporativo y políticas vigentes.

15. CONCLUSIONES E IDEAS CLAVE PARA EL REPASO

La seguridad de red protege comunicaciones y servicios mediante capas coordinadas. La tríada CIA se complementa con autenticidad, trazabilidad y no repudio. El riesgo surge de la combinación entre activos, amenazas, vulnerabilidades e impacto; por eso los controles se seleccionan de forma proporcional y se revisan continuamente.

Los ataques pueden ser pasivos o activos y abarcan reconocimiento, suplantación, intermediación, explotación, malware, movimiento lateral y denegación de servicio. DDoS distribuye el ataque entre numerosos orígenes; los ataques lentos como R.U.D.Y. demuestran que la indisponibilidad no siempre requiere gran caudal. El cifrado reduce la escucha, pero no protege un endpoint comprometido ni corrige autorizaciones excesivas.

La segmentación define zonas y flujos mínimos. Los cortafuegos aplican política, pero necesitan reglas gobernadas, administración segura y validación. IDS e IPS detectan o bloquean mediante firmas, anomalías y análisis de protocolos; SIEM y NDR aportan correlación. NAC controla quién y qué se conecta, y 802.1X articula supplicant, authenticator y servidor AAA.

AES y los modos AEAD protegen datos de forma eficiente; RSA, curvas elípticas y otros algoritmos asimétricos soportan autenticación, firma y establecimiento de claves; hash y HMAC resuelven integridad con propiedades distintas. La PKI da confianza a certificados y la gestión de claves determina la seguridad real. La agilidad criptográfica y la transición poscuántica ya forman parte de la planificación.

TLS 1.3, definido en RFC 8446, protege protocolos de aplicación; IPsec opera en la capa IP y utiliza IKEv2 para negociar asociaciones; SSH protege administración remota. Zero Trust elimina confianza implícita por ubicación y decide acceso por recurso, identidad, dispositivo y contexto. ZTNA y SASE son patrones de acceso y convergencia, no sustitutos automáticos de todos los controles existentes.

En movilidad, MDM/UEM, cifrado, aplicaciones gestionadas, parcheado, separación de datos y revocación forman un conjunto. 5G mejora privacidad y arquitectura, pero añade complejidad de software, API, virtualización, slicing y edge. En el SAS, la identidad nominativa, la trazabilidad, la segmentación, el control de terceros, la continuidad y la adecuación al ENS son especialmente relevantes.

16. MAPA CONCEPTUAL