Nota de estudio: Este tema es el núcleo de la seguridad informática. Conecta directamente con las preguntas Q2 (MFA), Q6 (cortafuegos), Q7 (malware), Q9 (permisos NTFS) y Q10 (redes seguras) del examen de la Politécnica. Sin entender criptografía no se puede entender HTTPS, VPN, firma digital, certificados SSL, ni por qué las contraseñas se almacenan con hash y sal.
La criptografía es la ciencia que estudia técnicas para proteger la información transformándola de manera que sea ilegible para quien no tenga autorización. Deriva del griego kryptos (oculto) y graphia (escritura).
En informática, la criptografía proporciona cuatro servicios de seguridad fundamentales:
| Servicio | Definición | Sin criptografía |
|---|---|---|
| Confidencialidad | Solo el destinatario autorizado puede leer el mensaje | Cualquiera que intercepte la comunicación puede leerla |
| Integridad | El mensaje no ha sido alterado en tránsito | Un atacante podría modificar los datos sin que nadie lo detecte |
| Autenticación | Verificar la identidad del emisor | No se puede confiar en que el interlocutor es quien dice ser |
| No repudio | El emisor no puede negar haber enviado el mensaje | Alguien puede negar haber firmado un contrato digital |
Terminología básica:
- Texto en claro (plaintext): datos originales, legibles.
- Texto cifrado (ciphertext): datos transformados, ilegibles sin la clave.
- Cifrado (encryption): proceso de transformar plaintext en ciphertext.
- Descifrado (decryption): proceso inverso.
- Clave (key): parámetro secreto que controla el cifrado/descifrado.
- Algoritmo criptográfico (cipher): la función matemática que realiza la transformación.
- Criptoanálisis: ciencia de intentar romper sistemas criptográficos.
Principio de Kerckhoffs (1883): la seguridad de un sistema criptográfico debe depender únicamente del secreto de la clave, nunca del secreto del algoritmo. El algoritmo puede ser público; la clave debe ser secreta. Los algoritmos modernos (AES, RSA, SHA-256) son completamente públicos y analizados por la comunidad científica mundial.
Analogía: una caja fuerte cuyo diseño es público (todos saben cómo funciona el mecanismo) pero cuya combinación es secreta. El fabricante puede mostrar los planos; lo que protege es la combinación específica.
En la criptografía simétrica, la misma clave se usa tanto para cifrar como para descifrar. Ambas partes deben conocer y mantener en secreto esa clave.
Emisor Receptor
│ │
│ Texto claro │
│ ↓ │
│ [CIFRADO con clave K] │
│ ↓ │
│ Texto cifrado ──────────────► │
│ │ [DESCIFRADO con clave K]
│ │ ↓
│ │ Texto claro
Cifrado en bloque (block cipher): divide el mensaje en bloques de tamaño fijo (p.ej. 128 bits) y cifra cada bloque.
Cifrado en flujo (stream cipher): genera un flujo pseudoaleatorio de bits (keystream) que se combina con el mensaje bit a bit mediante XOR.
| Modo | Nombre | Características | Uso |
|---|---|---|---|
| ECB | Electronic Codebook | Cada bloque cifrado independientemente. Inseguro: bloques iguales → ciphertext igual (revela patrones) | Nunca usar |
| CBC | Cipher Block Chaining | Cada bloque se combina con el anterior antes de cifrar. Requiere IV (vector de inicialización) | Cifrado de disco, TLS antiguo |
| CTR | Counter Mode | Convierte el bloque en cifrado de flujo usando un contador. Paralelizable | TLS moderno |
| GCM | Galois/Counter Mode | CTR + autenticación integrada (AEAD). Detecta manipulación del ciphertext | TLS 1.3, AES-GCM |
Por qué GCM es el estándar actual: proporciona confidencialidad (cifrado) e integridad (autenticación) en una sola operación. AES-128-GCM y AES-256-GCM son los conjuntos de cifrado preferidos en TLS 1.3.
El gran problema de la criptografía simétrica: ¿cómo comparten la clave de forma segura dos partes que nunca se han visto? Si el canal no es seguro, un atacante puede interceptar la clave. Este problema se soluciona con la criptografía asimétrica y el protocolo Diffie-Hellman.
Ventajas:
- Velocidad: entre 100 y 10.000 veces más rápida que la criptografía asimétrica. AES puede cifrar a varios GB/s en hardware moderno.
- Eficiencia: poco overhead computacional.
- Adecuada para grandes volúmenes de datos: cifrado de disco, streaming cifrado.
Inconvenientes:
- Problema de distribución de claves: compartir la clave de forma segura es difícil.
- Escalabilidad: en un grupo de N personas, se necesitan N×(N-1)/2 claves distintas. Para 1000 personas: ~500.000 claves.
- No proporciona no repudio: cualquiera de los dos extremos podría haber generado el mensaje.
La criptografía asimétrica resuelve el problema de distribución de claves mediante pares de claves matemáticamente relacionadas:
La relación matemática garantiza: lo que se cifra con una solo puede descifrarse con la otra del mismo par. Aunque conozcas la clave pública, es computacionalmente imposible derivar la clave privada.
Uso 1: Cifrado / Confidencialidad
Emisor (tiene la clave pública de Bob) Bob (tiene su clave privada)
│ │
│ Cifra con clave pública de Bob ──────► │
│ │ Descifra con su clave privada
│ │ (SOLO Bob puede descifrar)
Uso 2: Firma digital / Autenticación e integridad
Alice (tiene su clave privada) Receptor (tiene la clave pública de Alice)
│ │
│ Firma con su clave PRIVADA ──────────► │
│ │ Verifica con clave PÚBLICA de Alice
│ │ (cualquiera puede verificar,
│ │ pero solo Alice pudo firmar)
RSA (Rivest–Shamir–Adleman, 1977):
Su seguridad se basa en la dificultad de factorizar números enteros muy grandes en sus factores primos.
ECC (Elliptic Curve Cryptography):
Basada en la estructura algebraica de curvas elípticas sobre cuerpos finitos. Su seguridad se basa en el Problema del Logaritmo Discreto en curvas elípticas (ECDLP).
La ventaja clave: ECC proporciona el mismo nivel de seguridad que RSA con claves mucho más pequeñas:
| Nivel de seguridad | RSA | ECC |
|---|---|---|
| 80 bits | 1024 bits | 160 bits |
| 112 bits | 2048 bits | 224 bits |
| 128 bits | 3072 bits | 256 bits |
| 192 bits | 7680 bits | 384 bits |
| 256 bits | 15360 bits | 512 bits |
Una clave ECC-256 equivale en seguridad a RSA-3072. Esto significa operaciones más rápidas, menor tamaño de certificados y es ideal para dispositivos con recursos limitados (IoT, tarjetas inteligentes, móviles).
Curvas más usadas:
- P-256 (prime256v1 / secp256r1): curva del NIST, muy usada en TLS y certificados.
- Curve25519: diseñada por Daniel Bernstein. Muy eficiente, sin parámetros sospechosos. Usada en WireGuard, Signal, SSH moderno.
- P-384, P-521: para mayor seguridad (gobierno, militar).
Diffie-Hellman (DH) y ECDH:
Protocolo que permite a dos partes establecer una clave secreta compartida a través de un canal público, sin haberla intercambiado previamente.
Alice Bob
Genera secreto privado a Genera secreto privado b
Calcula: A = g^a mod p Calcula: B = g^b mod p
Envía A públicamente ─────────► Recibe A
Recibe B ◄───────────────────── Envía B públicamente
Calcula: K = B^a mod p Calcula: K = A^b mod p
K = (g^b)^a = g^(ab) K = (g^a)^b = g^(ab)
¡Ambos obtienen la misma K sin haberla enviado!
Un atacante que intercepta A y B no puede calcular K sin conocer a o b, porque el problema del logaritmo discreto es computacionalmente inviable.
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): variante de DH usando curvas elípticas con claves efímeras (nuevas en cada sesión). Es el mecanismo de intercambio de claves en TLS 1.3 y proporciona Perfect Forward Secrecy.
Perfect Forward Secrecy (PFS): si un atacante graba el tráfico cifrado de hoy y en el futuro consigue la clave privada del servidor, NO puede descifrar el tráfico pasado porque las claves de sesión eran efímeras y ya no existen. TLS 1.3 exige PFS obligatoriamente.
Ventajas:
- Resuelve el problema de distribución de claves.
- Proporciona no repudio.
- Escalabilidad: N personas necesitan N pares de claves (no N² como en simétrico).
- Base de toda la infraestructura PKI y certificados digitales.
Inconvenientes:
- Entre 100 y 10.000 veces más lenta que la criptografía simétrica.
- No apta para cifrar grandes volúmenes de datos directamente.
- Seguridad condicionada al secreto de la clave privada.
En la práctica, ningún sistema usa exclusivamente un solo tipo de criptografía. Se usa un esquema híbrido:
1. [Asimétrico] Se genera una clave de sesión aleatoria (simétrica, ej. AES-256)
2. [Asimétrico] La clave de sesión se cifra con la clave pública del receptor (RSA/ECDH)
3. [Simétrico] Los datos se cifran con la clave de sesión (AES-GCM)
4. Se envían: {clave de sesión cifrada} + {datos cifrados}
5. [Asimétrico] El receptor descifra la clave de sesión con su clave privada
6. [Simétrico] El receptor descifra los datos con la clave de sesión
HTTPS/TLS usa exactamente este esquema: RSA o ECDH para el intercambio de clave + AES-GCM para el cifrado de los datos.
Una función hash criptográfica transforma una entrada de cualquier tamaño en una salida de tamaño fijo (el "digest" o "resumen"), con las siguientes propiedades:
hash("Hola mundo") = a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b
hash("hola mundo") = d5fdde47e9c2a7e62a7389fd8d32485e9f9b3e81dbe44da7
← un carácter diferente → hash completamente distinto
| Algoritmo | Tamaño del hash | Estado | Uso |
|---|---|---|---|
| MD5 | 128 bits (32 hex) | Roto, no usar | Solo checksums no criptográficos |
| SHA-1 | 160 bits (40 hex) | Roto (2017, Google SHAttered) | Obsoleto. Deprecado en certificados SSL desde 2017 |
| SHA-256 | 256 bits (64 hex) | Seguro | Bitcoin, certificados TLS, firmado de código, contraseñas |
| SHA-384 | 384 bits (96 hex) | Seguro | TLS 1.3, documentos gubernamentales |
| SHA-512 | 512 bits (128 hex) | Seguro | Almacenamiento de contraseñas en Linux (/etc/shadow) |
| SHA-3 | Variable | Seguro | Alternativa a SHA-2 con diseño diferente (keccak) |
| bcrypt | 184 bits + sal | Seguro, deliberadamente lento | Almacenamiento de contraseñas |
| Argon2 | Variable | Seguro, resistente a GPU | El mejor para contraseñas hoy (ganador PHC 2015) |
| BLAKE3 | 256 bits | Seguro, muy rápido | Checksums de alta velocidad |
1. Almacenamiento seguro de contraseñas:
Las contraseñas nunca se almacenan en texto plano ni cifradas. Se almacena su hash.
Problema con el hash simple: si dos usuarios tienen la misma contraseña, tienen el mismo hash. Un atacante con una tabla de hashes precalculados (rainbow table) puede invertir millones de hashes instantáneamente.
Solución: sal (salt): valor aleatorio único generado por usuario que se concatena a la contraseña antes de hashear:
hash("password123") = 5baa61... ← siempre el mismo, tabla rainbow útil
hash("password123" + "x7Kq2mP9") = a3f8d1... ← diferente para cada usuario
hash("password123" + "9nL4rT2v") = b7e2c9... ← aunque misma contraseña
En Linux, /etc/shadow almacena el formato $algoritmo$sal$hash:
$6$x7Kq2mP9$[hash] → SHA-512 ($6$) con sal x7Kq2mP9
$2b$12$[sal+hash] → bcrypt con 12 rondas de cost factor
$argon2id$...$[sal+hash] → Argon2id
bcrypt y Argon2 son especialmente resistentes porque son intencionalmente lentos (ajustable mediante factor de coste). Verificar una contraseña tarda ~100 ms, aceptable para el usuario. Pero para un atacante intentando 1 millón de contraseñas: 100.000 segundos (>27 horas) vs fracciones de segundo con SHA-256 simple.
Argon2 también requiere mucha RAM, lo que dificulta los ataques con GPU o ASIC especializados.
2. Integridad de datos y verificación de ficheros:
sha256sum ubuntu-22.04.iso
# Comparar con el hash oficial en la web para verificar que el ISO
# no fue alterado (corrupción o ataque man-in-the-middle)
3. Firma digital (en combinación con clave asimétrica):
En lugar de firmar el mensaje completo (lento con RSA), se firma el hash del mensaje:
Firma = Cifrar_con_clave_privada( hash(mensaje) )
Verificación: hash(mensaje) == Descifrar_con_clave_pública(Firma)
4. HMAC (Hash-based Message Authentication Code):
Combina una función hash con una clave secreta para proporcionar autenticación de integridad. Verifica que el mensaje proviene de alguien que conoce la clave y que no ha sido modificado.
HMAC = hash(clave || mensaje) (simplificado)
5. Blockchain: cada bloque contiene el hash del bloque anterior, formando una cadena donde modificar un bloque requiere recalcular todos los bloques siguientes.
La firma digital es el mecanismo criptográfico que proporciona autenticación, integridad y no repudio a documentos o mensajes digitales. Es el equivalente digital de la firma manuscrita, pero con garantías matemáticas mucho más fuertes.
═══════════ FIRMA ═══════════
Documento original
│
▼
hash(documento) ← SHA-256, SHA-384...
│
▼
Cifrar hash con ──► FIRMA DIGITAL
clave PRIVADA del firmante
Enviar: [Documento] + [Firma digital] + [Certificado del firmante]
═══════════ VERIFICACIÓN ═══════════
Receptor:
1. hash_recibido = Descifrar_con_clave_PÚBLICA_del_firmante(Firma digital)
2. hash_calculado = hash(Documento recibido)
3. Si hash_recibido == hash_calculado → Firma VÁLIDA
Si son distintos → Documento alterado O firma falsa
Diferencia crítica firma digital vs firma manuscrita: la firma manuscrita es siempre la misma independientemente del documento. La firma digital es diferente para cada documento (depende del hash del contenido). Copiar la firma de un documento a otro es imposible porque los hashes son diferentes.
| Algoritmo | Base matemática | Tamaño de firma | Estado |
|---|---|---|---|
| RSA-PKCS#1 | Factorización de enteros | 256 bytes (2048 bits) | Seguro, ubicuo |
| RSA-PSS | Factorización (probabilístico) | 256 bytes | Más seguro que PKCS#1, preferido |
| ECDSA | Curvas elípticas (DLP) | 64 bytes (P-256) | Seguro, eficiente |
| EdDSA (Ed25519) | Curvas de Edwards | 64 bytes | Moderno, muy seguro y rápido |
| DSA | Logaritmo discreto | 40-60 bytes | Obsoleto |
Ed25519 es el estándar moderno recomendado para SSH keys, tokens de autenticación y firmas en general.
La criptografía de clave pública tiene un problema práctico fundamental: ¿cómo sé que la clave pública que me están dando realmente pertenece a quien dice ser?
Ataque Man-in-the-Middle (MitM):
Alice quiere comunicarse con "banco.com"
│
│ intercepta la comunicación
▼
[ATACANTE]
│
▼ presenta su propia clave pública haciéndose pasar por banco.com
Alice cifra datos con la clave del ATACANTE (cree que es de banco.com)
El ATACANTE descifra, lee/modifica, y reencripta con la clave real de banco.com
banco.com responde al ATACANTE, que hace lo mismo en sentido inverso
Alice y banco.com creen hablar directamente, pero el ATACANTE ve todo
La solución son los certificados digitales: documentos que vinculan una clave pública con la identidad de su propietario, firmados por una tercera parte de confianza.
El estándar X.509 define el formato de los certificados digitales. Es el estándar de facto para certificados en TLS/SSL, firma de código, email seguro, etc.
Un certificado X.509 contiene:
┌─────────────────────────────────────────────────────┐
│ CERTIFICADO X.509 v3 │
├─────────────────────────────────────────────────────┤
│ Versión: 3 │
│ Número de serie: 0A:1B:2C:3D:... (único en la CA) │
│ Algoritmo de firma: sha256WithRSAEncryption │
├─────────────────────────────────────────────────────┤
│ Emisor (Issuer): │
│ CN=DigiCert TLS RSA SHA256 2020 CA1 │
│ O=DigiCert Inc │
│ C=US │
├─────────────────────────────────────────────────────┤
│ Validez: │
│ Válido desde: 2024-01-15 00:00:00 │
│ Válido hasta: 2025-01-14 23:59:59 │
├─────────────────────────────────────────────────────┤
│ Sujeto (Subject): │
│ CN=www.banco.com │
│ O=Banco Ejemplo S.A. │
│ L=Madrid │
│ C=ES │
├─────────────────────────────────────────────────────┤
│ Clave pública del sujeto: │
│ Algoritmo: RSA 2048 bits │
│ Valor: [clave pública en formato DER] │
├─────────────────────────────────────────────────────┤
│ Extensiones: │
│ Subject Alternative Names (SAN): │
│ DNS: www.banco.com │
│ DNS: banco.com │
│ DNS: m.banco.com │
│ Key Usage: Digital Signature, Key Encipherment │
│ Extended Key Usage: TLS Web Server Authentication │
│ CRL Distribution Points: http://crl.digicert.com/ │
│ Authority Information Access: │
│ OCSP: http://ocsp.digicert.com │
│ CA Issuers: http://cacerts.digicert.com/... │
│ Basic Constraints: CA:FALSE │
├─────────────────────────────────────────────────────┤
│ FIRMA DE LA CA: │
│ [Firma digital de DigiCert sobre todo lo anterior] │
└─────────────────────────────────────────────────────┘
¿Qué garantiza la firma de la CA? Que la CA verificó que la entidad propietaria del dominio banco.com es Banco Ejemplo S.A. y que la clave pública incluida les pertenece. Si el certificado fuera falsificado, la firma de la CA no coincidiría y el navegador lo rechazaría.
| Tipo | Validación | Tiempo emisión | Costo | Indicador en navegador |
|---|---|---|---|---|
| DV (Domain Validation) | Solo verifica que controlas el dominio | Minutos | Bajo (~0-50€/año) | Candado verde, sin nombre empresa |
| OV (Organization Validation) | Verifica dominio + existencia legal de la organización | Días | Medio (~100-300€/año) | Candado verde, organización visible en certificado |
| EV (Extended Validation) | Verificación exhaustiva: dominio + organización + dirección física + estado legal | Semanas | Alto (~300-1000€/año) | Antiguamente barra verde con nombre empresa |
¿Por qué Let's Encrypt es gratuito? Emite solo certificados DV, automatizados completamente mediante el protocolo ACME. No verifica identidad de la organización, solo control del dominio.
Subject Alternative Names (SAN): lista de dominios que cubre el certificado. Un certificado wildcard *.banco.com cubre todos los subdominios de primer nivel pero no los de nivel dos.
Key Usage y Extended Key Usage:
- Digital Signature: firma de datos.
- Key Encipherment: cifrado de clave de sesión (servidores TLS con RSA).
- Key Agreement: intercambio de claves (servidores TLS con ECDH).
- TLS Web Server Authentication: el certificado puede autenticar un servidor HTTPS.
- TLS Web Client Authentication: autenticación de cliente (certificados de cliente).
- Code Signing: firma de ejecutables y código.
- Email Protection: S/MIME para email seguro.
Basic Constraints: si CA:TRUE, este certificado es de una CA y puede firmar otros certificados. Si CA:FALSE, es un certificado de entidad final que no puede firmar certificados.
Certificados de servidor (TLS/SSL):
Permiten a los clientes verificar que están hablando con el servidor legítimo. Usados en HTTPS, FTPS, SMTPS, etc.
Certificados de cliente:
Permiten al servidor verificar la identidad del cliente. Autenticación mutua (mTLS: mutual TLS). Muy usado en VPNs corporativas, APIs entre servicios internos, acceso a sistemas críticos.
Certificados de firma de código (Code Signing):
Garantizan que un ejecutable fue producido por el firmante y no ha sido modificado. Windows muestra una advertencia al ejecutar código sin firma.
Certificados de email (S/MIME):
Permiten firmar y cifrar emails. El receptor puede verificar que el email viene del remitente legítimo y no ha sido alterado.
Certificados de CA (Certification Authority):
Tienen Basic Constraints: CA:TRUE. Los certificados raíz (Root CA) están autofirmados y vienen preinstalados en el SO y navegadores.
Certificados personales / DNI electrónico:
Emitidos a personas físicas por CAs reconocidas oficialmente. En España: FNMT (Fábrica Nacional de Moneda y Timbre) o el DNI electrónico emitido por la Policía. Permiten identificarse digitalmente ante la administración pública y firmar documentos con valor legal.
Un certificado puede quedar inválido antes de su fecha de expiración (clave privada comprometida, error de emisión, cese de actividad). Existen dos mecanismos para comprobarlo:
CRL (Certificate Revocation List):
Lista firmada digitalmente que la CA publica periódicamente con los números de serie de los certificados revocados. El cliente descarga la lista y comprueba si el certificado en cuestión aparece.
- Ventaja: simple.
- Inconveniente: puede crecer mucho, no es en tiempo real (actualización periódica).
OCSP (Online Certificate Status Protocol):
El cliente consulta en tiempo real a un servidor OCSP de la CA si un certificado concreto sigue siendo válido.
- Ventaja: respuesta en tiempo real, más eficiente que descargar toda la CRL.
- Inconveniente: depende de la disponibilidad del servidor OCSP.
OCSP Stapling: el propio servidor web incluye ("adjunta") en el handshake TLS una respuesta OCSP firmada recientemente por la CA. Evita que el cliente tenga que consultar al servidor OCSP por separado, mejorando la privacidad y el rendimiento.
Una PKI (Public Key Infrastructure — Infraestructura de Clave Pública) es el conjunto de hardware, software, políticas, procedimientos y estándares necesarios para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales.
La PKI es lo que hace que HTTPS funcione de forma automática en millones de webs. Cuando tu navegador se conecta a https://banco.com, automáticamente verifica el certificado del banco contra la PKI sin que el usuario haga nada.
La CA es el componente central de la PKI. Es la entidad de confianza que:
- Verifica la identidad de quien solicita un certificado.
- Emite certificados firmando digitalmente su contenido con su clave privada.
- Mantiene y publica la lista de certificados revocados (CRL).
- Publica su propia clave pública para que todos puedan verificar sus firmas.
La seguridad de toda la PKI depende de la seguridad de la CA. Si la clave privada de la CA es comprometida, todos los certificados que emitió son potencialmente falsificables. Las CAs raíz almacenan sus claves en HSMs (Hardware Security Modules) certificados, en instalaciones físicamente seguras, con procedimientos de multi-persona (se necesitan varias personas simultáneamente para acceder a la clave).
Ejemplo histórico: en 2011, DigiNotar (CA holandesa) fue comprometida. Atacantes emitieron certificados fraudulentos para Google.com, Gmail.com y muchos otros dominios, permitiendo ataques MitM a usuarios iraníes. DigiNotar fue eliminada de todos los almacenes de confianza y quebró en semanas.
Entidad intermediaria que realiza la verificación de identidad de los solicitantes de certificados antes de aprobar la emisión. La CA delega la verificación a la RA pero se reserva la firma. En muchas PKIs pequeñas, CA y RA están integradas.
Entidad que responde a las consultas sobre el estado de un certificado (OCSP). Puede estar integrada en la CA o ser un componente independiente para distribuir la carga de consultas.
Base de datos o directorio LDAP donde se publican los certificados emitidos y las CRLs. Permite a cualquier entidad descargar certificados públicos y comprobar su estado de revocación.
Servicio que acredita que un documento o firma existía en un momento determinado. Emite un sello de tiempo (timestamp) firmado digitalmente que incluye el hash del documento y el instante temporal verificado. Esencial para la validez a largo plazo de documentos firmados (cuando el certificado del firmante ha expirado, el sello de tiempo demuestra que la firma fue válida en el momento de realizarla).
Las PKIs se organizan en una jerarquía de confianza:
┌─────────────────┐
│ ROOT CA │ ← Autofirmada. Máxima confianza.
│ (raíz) │ Clave privada offline o en HSM.
└────────┬────────┘
│ firma los certificados de las CAs intermedias
┌─────────────┴──────────────┐
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ CA Intermedia 1 │ │ CA Intermedia 2 │
│ (Sub-CA) │ │ (Sub-CA) │
└────────┬─────────┘ └────────┬─────────┘
│ firma certificados finales │
┌─────┴──────┐ ┌─────┴──────┐
▼ ▼ ▼ ▼
Cert. Cert. Cert. Cert.
servidor cliente servidor código
¿Por qué una jerarquía y no una sola CA raíz?
- Seguridad: la Root CA puede mantenerse offline. Solo se usa para firmar certificados de CAs intermedias, reduciendo la exposición de su clave privada.
- Escalabilidad: diferentes CAs intermedias para diferentes propósitos o regiones.
- Revocación limitada: si se compromete una CA intermedia, solo se revocan sus certificados, no toda la jerarquía.
Cadena de certificados (certificate chain):
Para validar un certificado de servidor, el cliente verifica toda la cadena:
Certificado del servidor → firmado por CA Intermedia
CA Intermedia → firmada por Root CA
Root CA → autofirmada (confiada por el SO/navegador)
Si cualquier eslabón de la cadena falla (expirado, revocado, firma inválida), la validación falla.
El trust store es la colección de certificados raíz (Root CA) en los que el SO o navegador confía de forma predeterminada. Viene preinstalado con el SO o el navegador.
certmgr.msc o mediante GPO en entornos de dominio./etc/ssl/certs/ o paquete ca-certificates. Las aplicaciones pueden usar NSS (Mozilla) o el almacén del sistema.En entornos corporativos, los administradores añaden el certificado raíz de la CA corporativa al trust store de todos los equipos mediante GPO (Windows) o gestión de configuración (Ansible, Puppet en Linux). Esto permite que los certificados emitidos por la CA corporativa sean confiados automáticamente.
| Característica | PKI Pública (ej. DigiCert) | PKI Corporativa (ej. Microsoft AD CS) |
|---|---|---|
| Ámbito | Internet, cualquier cliente | Interna, clientes en el dominio |
| Trust store | Incluida por defecto en SOs | Hay que distribuirla manualmente o por GPO |
| Coste | De pago (DV gratis con Let's Encrypt) | Gratuita una vez implantada |
| Validación | Verificada por tercero | Gestionada internamente |
| Uso típico | Webs públicas, correo externo | VPN, WiFi 802.1X, mTLS interno, correo interno firmado |
TLS es el protocolo que proporciona comunicaciones seguras sobre una red. Es el sucesor de SSL (ya obsoleto y vulnerable). Cuando ves https:// en el navegador, estás usando TLS.
Versiones:
| Versión | Estado | Notas |
|---|---|---|
| SSL 2.0 | Roto, prohibido | Vulnerabilidades críticas |
| SSL 3.0 | Roto, prohibido | Vulnerable a POODLE |
| TLS 1.0 | Deprecado (2020) | Vulnerable a BEAST, POODLE |
| TLS 1.1 | Deprecado (2020) | Mejoras menores sobre 1.0 |
| TLS 1.2 | Aceptable | Ampliamente usado, seguro si bien configurado |
| TLS 1.3 | Recomendado | Más rápido, PFS obligatorio, eliminó algoritmos débiles |
Cliente Servidor
│ │
│── ClientHello ─────────────────────────►│
│ (versiones TLS soportadas, │
│ cipher suites, clave pública ECDHE) │
│ │
│◄─ ServerHello ───────────────────────────│
│ (versión elegida, cipher suite, │
│ clave pública ECDHE del servidor, │
│ certificado del servidor, │
│ datos cifrados ya desde aquí) │
│ │
│ [Ambos calculan la clave de sesión │
│ con ECDHE: K = g^(ab) mod p] │
│ │
│── Finished ──────────────────────────────►│ (cifrado con K)
│ │
│◄─ Finished ──────────────────────────────│ (cifrado con K)
│ │
│════════ DATOS CIFRADOS CON AES-GCM ══════│
En TLS 1.3, el handshake es 1-RTT (1 Round Trip Time) vs 2-RTT de TLS 1.2, lo que reduce la latencia. Además existe 0-RTT para reconexiones (con las implicaciones de seguridad que conlleva).
Una cipher suite es una combinación de algoritmos criptográficos que define cómo se realiza el intercambio de claves, la autenticación, el cifrado y la integridad en una sesión TLS.
Formato TLS 1.2: TLS_[Intercambio]_[Autenticación]_WITH_[Cifrado]_[Hash]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│ │ │ │
│ │ │ └─ Hash para HMAC: SHA-384
│ │ └─── Cifrado simétrico: AES-256-GCM
│ └────────────── Autenticación: RSA (certificado del servidor)
└──────────────────── Intercambio de claves: ECDHE (con PFS)
TLS 1.3 simplifica esto: solo 5 cipher suites, todas con PFS, y elimina algoritmos obsoletos (RC4, 3DES, SHA-1, RSA para intercambio de claves):
TLS_AES_256_GCM_SHA384 ← Preferida
TLS_CHACHA20_POLY1305_SHA256 ← Alternativa (donde no hay AES hardware)
TLS_AES_128_GCM_SHA256
Técnica en la que la aplicación (normalmente móvil) almacena el hash del certificado o de la clave pública del servidor esperado. Si el servidor presenta un certificado diferente (aunque sea válido y firmado por una CA de confianza), la conexión se rechaza. Protege contra CAs comprometidas. Ejemplo: las apps bancarias usan certificate pinning para evitar ataques MitM aunque el atacante tenga un certificado válido de otra CA.
Autenticación (AuthN): proceso de verificar que alguien o algo es quien dice ser. Responde a la pregunta: ¿Quién eres?
Autorización (AuthZ): proceso de determinar qué acciones o recursos puede acceder una entidad ya autenticada. Responde a: ¿Qué puedes hacer?
Auditoría / Accounting: registro de las acciones realizadas por las entidades autenticadas. Responde a: ¿Qué hiciste?
Mnemotecnia AAA: Authentication, Authorization, Accounting. Marco de seguridad completo (usado en RADIUS, TACACS+).
Los factores de autenticación se clasifican en tres categorías:
| Factor | Categoría | Ejemplos | Riesgo principal |
|---|---|---|---|
| Algo que sabes | Conocimiento | Contraseña, PIN, pregunta secreta | Robo, phishing, fuerza bruta |
| Algo que tienes | Posesión | Token hardware, tarjeta inteligente, móvil (TOTP) | Pérdida, robo físico |
| Algo que eres | Inherencia (biometría) | Huella dactilar, iris, reconocimiento facial, voz | No revocable si comprometido, falsos positivos/negativos |
Factores adicionales:
- Dónde estás (ubicación): dirección IP, geolocalización, red corporativa.
- Cuándo actúas (comportamiento): hora de acceso, patrones de uso (autenticación continua).
La MFA requiere verificar la identidad mediante dos o más factores de categorías distintas. Dos contraseñas son doble factor de conocimiento, pero no son MFA.
¿Por qué es efectiva? Un atacante que robe la contraseña (factor 1) todavía necesita el segundo factor (físico o biométrico) para acceder. La probabilidad de que ambos factores sean comprometidos simultáneamente es exponencialmente menor.
Contraseña de un solo uso, válida una sola vez. Evita el riesgo de reutilización de contraseñas robadas.
HOTP (HMAC-based OTP) — RFC 4226:
OTP = truncate( HMAC-SHA1(clave_secreta, contador) )
TOTP (Time-Based OTP) — RFC 6238:
OTP = truncate( HMAC-SHA1(clave_secreta, floor(tiempo_unix / 30)) )
SMS OTP:
Código enviado por SMS. Desaconsejado por el NIST (NIST SP 800-63B) por:
- SIM swapping: el atacante convence al operador de transferir el número a una SIM suya.
- Interceptación de SS7 (protocolo de señalización telefónica con vulnerabilidades conocidas).
- Phishing.
FIDO2 es el estándar moderno de autenticación sin contraseña (o como segundo factor). Compuesto por:
- WebAuthn: API web para autenticación fuerte en navegadores.
- CTAP (Client to Authenticator Protocol): protocolo de comunicación con el autenticador (llave hardware).
Funcionamiento:
1. El servidor envía un "challenge" aleatorio al cliente.
2. El autenticador (llave hardware o biométrico del dispositivo) firma el challenge
con la clave privada del usuario (almacenada de forma segura en el autenticador).
3. El servidor verifica la firma con la clave pública registrada previamente.
Ventajas sobre TOTP:
- Resistente a phishing: la clave privada nunca sale del autenticador. La firma incluye el origen (dominio), por lo que una firma válida para banco.com no sirve para banco-fake.com.
- Sin secretos compartidos en el servidor: el servidor solo almacena la clave pública.
- Sin necesidad de introducir códigos: la interacción es una pulsación de botón o biometría.
Dispositivos FIDO2: YubiKey, Google Titan Key, passkeys en móviles y ordenadores modernos (Windows Hello, Face ID, Touch ID integrados con FIDO2).
a) Segunda contraseña fija:
- No es MFA real (dos factores de la misma categoría: conocimiento + conocimiento).
- Mismo riesgo que la primera contraseña: phishing, fuerza bruta, reutilización.
- Solo aumenta levemente la seguridad.
- Valoración: enfoque incorrecto. No se considera MFA.
b) Segunda contraseña dinámica TOTP:
- Sí es MFA: algo que sabes (contraseña) + algo que tienes (dispositivo con app TOTP).
- Mucho más segura que la opción a).
- Inconvenientes: susceptible a phishing en tiempo real si el atacante actúa rápido. Requiere que el usuario tenga el dispositivo móvil disponible.
- Valoración: enfoque correcto. Es el MFA más común hoy en día. Implementación estándar y bien documentada.
c) Acceso solo desde portátiles corporativos + biometría (sin contraseña):
- Factor 1: algo que tienes (portátil corporativo específico, identificado por certificado de cliente o MAC address controlada).
- Factor 2: algo que eres (huella dactilar).
- Es MFA: posesión + inherencia.
- Ventajas: muy alta seguridad si los portátiles están correctamente gestionados. No se pueden robar contraseñas porque no las hay.
- Inconvenientes: las huellas dactilares no se pueden cambiar si se comprometen. Dependencia total del hardware corporativo (¿qué pasa si el empleado trabaja desde otro equipo?). Mayor coste de implantación.
- Valoración: enfoque correcto y muy seguro para entornos de alta sensibilidad. Requiere mayor inversión en gestión de dispositivos. La biometría como único sustituto de contraseña es aceptable si el hardware está bien protegido.
Protocolo para acceder y mantener servicios de directorio distribuidos. Permite consultar y modificar información sobre usuarios, grupos, equipos, etc.
cn=usuario,ou=empleados,dc=empresa,dc=com.Servicio de directorio de Microsoft basado en LDAP + Kerberos. Gestiona identidades y accesos en entornos Windows corporativos. Elementos clave:
- Dominio: unidad administrativa principal.
- Forest: conjunto de dominios con relación de confianza.
- GPO (Group Policy Object): políticas que se aplican a usuarios o equipos del dominio (configuración de seguridad, software, restricciones).
- DC (Domain Controller): servidor que autentica a los usuarios del dominio.
Protocolo de autenticación de red basado en tickets. Diseñado para que los usuarios demuestren su identidad a los servicios sin enviar contraseñas por la red.
1. Cliente → AS (Authentication Server): solicita TGT con su contraseña hasheada.
2. AS → Cliente: TGT (Ticket Granting Ticket) cifrado con la clave del KDC.
3. Cliente → TGS (Ticket Granting Server): presenta TGT, solicita acceso a un servicio.
4. TGS → Cliente: Service Ticket cifrado con la clave del servicio destino.
5. Cliente → Servicio: presenta Service Ticket. El servicio lo descifra y autentica al cliente.
Ventajas: las contraseñas nunca viajan por la red. Single Sign-On (SSO): con un solo login se accede a todos los servicios del dominio.
Vulnerabilidades conocidas: Pass-the-Ticket, Golden Ticket (si se compromete la cuenta krbtgt del KDC), Kerberoasting (solicitar tickets para cuentas de servicio y atacarlos offline).
Protocolo AAA (Authentication, Authorization, Accounting) para acceso a red. Muy usado en:
- Autenticación WiFi empresarial (802.1X): los usuarios se autentican contra el servidor RADIUS antes de acceder a la red WiFi.
- VPN: autenticación de usuarios en concentradores VPN.
- Acceso a dispositivos de red (switches, routers vía TACACS+).
Cliente WiFi → [Solicitud de acceso] → Access Point → [RADIUS Request] → Servidor RADIUS
│
Consulta AD/LDAP
│
Cliente WiFi ← [Acceso permitido] ← Access Point ← [RADIUS Accept/Reject] ←────────┘
Estándar XML para intercambiar datos de autenticación y autorización entre un Identity Provider (IdP) y un Service Provider (SP). Permite SSO (Single Sign-On) en entornos web federados.
Usuario → SP (recurso protegido) → redirección al IdP
Usuario → IdP (autentica al usuario) → genera aserción SAML firmada
IdP → SP con aserción SAML → el SP verifica la firma y concede acceso
OAuth 2.0: framework de autorización (no autenticación) que permite a una aplicación acceder a recursos en nombre del usuario sin compartir credenciales. Ejemplo: "Iniciar sesión con Google" para que una app acceda a tu Google Drive.
Flujo simplificado (Authorization Code Flow):
1. App → Servidor de autorización (Google): solicita permiso para acceder a Drive.
2. Usuario → Google: se autentica y aprueba el permiso.
3. Google → App: código de autorización.
4. App → Google: intercambia código por Access Token.
5. App → Google Drive API: accede con el Access Token.
OpenID Connect (OIDC): capa de autenticación sobre OAuth 2.0. Añade un ID Token (JWT) que contiene información sobre el usuario autenticado. Permite SSO en aplicaciones web modernas.
El propietario del recurso decide quién puede acceder a él y con qué permisos. Modelo implementado en sistemas de archivos tradicionales (Unix, NTFS). Flexible pero puede ser inseguro si los usuarios otorgan permisos de forma irresponsable.
El sistema operativo o el administrador establece políticas de seguridad que ni siquiera el propietario puede anular. Basado en etiquetas de seguridad (niveles de clasificación: Secreto, Confidencial, Público) y compartimentos.
Los permisos se asignan a roles (funciones laborales), no directamente a usuarios. Los usuarios se asignan a roles según sus responsabilidades.
Usuario → Roles → Permisos → Recursos
Juan → [Contable] → [Leer facturas, Generar informes] → BD_Financiera
María → [Admin] → [Leer/Escribir/Borrar todo] → Todos los sistemas
Pedro → [Técnico TI] → [Acceder a logs, reiniciar VMs] → Plataforma virtualización
Ventajas: gestión simplificada (cambiar permisos del rol afecta a todos los usuarios del rol), separación de funciones, principio de mínimo privilegio.
Los permisos se evalúan dinámicamente en función de atributos del usuario, del recurso y del entorno.
Regla: PERMITIR acceso SI:
- usuario.departamento == "RRHH"
- recurso.clasificacion == "Confidencial-RRHH"
- entorno.hora ENTRE 08:00 Y 20:00
- entorno.red == "RedCorporativa"
Más flexible y granular que RBAC, pero más complejo de gestionar. Usado en entornos cloud (AWS IAM policies, por ejemplo).
Cada entidad (usuario, proceso, servicio) debe tener únicamente los permisos mínimos necesarios para realizar sus funciones legítimas, y nada más. Es uno de los principios fundamentales de seguridad.
Aplicaciones prácticas:
- Un servidor web no debe ejecutarse como root.
- Un empleado de soporte técnico no necesita acceso a datos financieros.
- Una aplicación solo debe poder leer la base de datos que necesita, no escribir en otras.
- Las cuentas de administración deben usarse solo cuando sea necesario (no como cuenta de uso diario).
Ninguna persona debe tener control completo sobre un proceso crítico de principio a fin. Ejemplo: quien aprueba pagos no puede ser quien los ejecute; quien crea usuarios no puede asignarse permisos a sí mismo.
Activo (Asset): cualquier elemento con valor para la organización que debe protegerse. Datos, sistemas, infraestructura, reputación, personas.
Vulnerabilidad: debilidad o fallo en un sistema que puede ser explotado. Puede ser técnica (bug en software), de configuración (contraseñas por defecto) o humana (empleado sin formación).
Amenaza (Threat): circunstancia o evento con potencial para causar daño explotando una vulnerabilidad. Puede ser intencional (atacante externo, empleado malicioso) o no intencional (error humano, desastre natural).
Riesgo: probabilidad de que una amenaza explote una vulnerabilidad multiplicada por el impacto resultante.
Riesgo = Probabilidad × Impacto
Exploit: código o técnica que aprovecha una vulnerabilidad específica para causar un efecto no deseado.
CVE (Common Vulnerabilities and Exposures): sistema de identificación pública de vulnerabilidades conocidas. Formato: CVE-AÑO-NÚMERO (ej. CVE-2021-44228 — Log4Shell).
CVSS (Common Vulnerability Scoring System): sistema de puntuación de la severidad de vulnerabilidades. Escala 0-10. Tiene en cuenta vector de ataque, complejidad, privilegios requeridos, interacción del usuario, impacto en confidencialidad/integridad/disponibilidad.
Zero-day (0-day): vulnerabilidad que no ha sido divulgada públicamente ni tiene parche disponible. El fabricante tiene "cero días" para haberla corregido. Extremadamente peligrosas porque no hay defensa directa.
Código malicioso que se adjunta a archivos o programas legítimos y se replica cuando el archivo infectado es ejecutado. Requiere intervención humana para propagarse (ejecutar el archivo).
Funcionamiento: el virus inserta su código en el ejecutable huésped. Cuando el usuario ejecuta el programa legítimo, el código del virus también se ejecuta, realiza su acción maliciosa y puede infectar otros archivos.
Tipos:
- Virus de archivo: infecta ejecutables (.exe, .com).
- Virus de sector de arranque (MBR): infecta el sector de arranque del disco, se carga antes del SO.
- Virus de macro: infecta documentos Office que contienen macros (VBA). Muy comunes en ataques por email con documentos adjuntos.
- Virus polimórfico: cambia su firma (código) en cada infección para evadir la detección por antivirus basados en firmas.
- Virus metamórfico: reescribe completamente su código en cada infección.
Daño: corrupción de archivos, robo de información, instalación de backdoors, borrado de datos.
Malware que se replica de forma autónoma a través de redes sin necesitar adjuntarse a archivos ni intervención humana.
Diferencia clave con virus: el gusano se propaga solo, sin necesitar que el usuario ejecute nada. Explota vulnerabilidades de red o servicios para propagarse.
Ejemplos históricos:
- Morris Worm (1988): primer gusano de Internet. Explotó vulnerabilidades en Unix. Causó la primera condena por delito informático en EE.UU.
- Code Red (2001): explotó vulnerabilidad en IIS de Microsoft. Infectó 359.000 máquinas en 14 horas.
- WannaCry (2017): ransomware con capacidad de gusano. Explotó EternalBlue (vulnerabilidad SMB de Windows). Infectó +200.000 equipos en 150 países en horas, incluyendo el NHS británico.
Daño: consumo de ancho de banda, saturación de redes, instalación de backdoors, descarga de otros malware.
Malware disfrazado de software legítimo o útil. No se replica por sí mismo. El usuario lo instala voluntariamente creyendo que es otra cosa.
Tipos:
- RAT (Remote Access Trojan): proporciona acceso remoto completo al atacante. Ejemplo: njRAT, DarkComet.
- Backdoor: abre una puerta trasera en el sistema para acceso posterior del atacante.
- Dropper/Downloader: su función es descargar e instalar otros malware una vez ejecutado.
- Banker Trojan: especializado en robar credenciales bancarias. Intercepta transacciones, realiza web injects, roba OTPs.
- Infostealer: roba credenciales, cookies de sesión, datos del portapapeles, capturas de pantalla.
Vectores de distribución: adjuntos de email, software pirata, actualizaciones falsas, descargas drive-by.
Malware que cifra los archivos del sistema y exige un rescate (generalmente en criptomonedas) para proporcionar la clave de descifrado.
Funcionamiento técnico:
1. Infección (phishing, exploit, RDP expuesto...)
2. Movimiento lateral: se propaga por la red buscando sistemas accesibles.
3. Reconocimiento: identifica archivos valiosos, deshabilita backups, extrae datos (para doble extorsión).
4. Cifrado: genera clave AES aleatoria por fichero, cifra los ficheros,
cifra la clave AES con la clave pública RSA del atacante.
5. Eliminación de copias sombra (VSS), backups locales.
6. Nota de rescate: instrucciones para pagar (Tor, Bitcoin).
Doble extorsión: además de cifrar, el atacante exfiltra datos antes de cifrar. Si la víctima no paga, amenaza con publicar los datos robados.
Ejemplos: WannaCry, NotPetya (2017, daños >10.000M$), REvil, LockBit, Ryuk, Conti.
Respuesta ante ransomware (Pregunta 7b del examen):
1. Aislar inmediatamente los sistemas afectados de la red para evitar propagación.
2. No pagar el rescate (no garantiza recuperación, financia futuros ataques, puede ser ilegal).
3. Identificar el ransomware (puede haber herramientas de descifrado gratuitas en nomoreransom.org).
4. Restaurar desde copias de seguridad limpias y verificadas (previas a la infección).
5. Notificar a las autoridades (INCIBE en España, AEPD si hay datos personales afectados — obligatorio en <72h bajo RGPD).
6. Análisis forense para identificar el vector de entrada y cerrar la vulnerabilidad.
7. Revisar y mejorar las medidas de seguridad para prevenir futuros ataques.
Spyware: recopila información del usuario (actividad, credenciales, pulsaciones de teclado) sin su conocimiento.
Keylogger: registra todas las pulsaciones del teclado. Puede ser software (proceso en segundo plano) o hardware (dispositivo físico entre teclado y PC).
Adware: muestra publicidad no deseada. Generalmente no malicioso per se, pero puede ser vector de otros malware.
Rootkit: malware que obtiene acceso privilegiado al sistema (nivel kernel) y se oculta de las herramientas de detección. Extremadamente difícil de detectar y eliminar. Puede persistir aunque se reinstale el SO si infecta el firmware.
Bootkit: rootkit que infecta el sector de arranque (MBR/UEFI), cargándose antes del SO y el antivirus.
Fileless malware: malware que no escribe archivos en disco. Opera en memoria, usa herramientas legítimas del SO (PowerShell, WMI, cmd). Muy difícil de detectar por antivirus tradicionales basados en análisis de archivos.
Botnet: red de equipos infectados (bots/zombies) controlados remotamente por un atacante (C2 — Command & Control). Usada para spam masivo, DDoS, minería de criptomonedas, distribución de otros malware.
Fuerza bruta (Brute Force): probar todas las combinaciones posibles de contraseña hasta encontrar la correcta. Efectivo contra contraseñas cortas. Contramedidas: lockout de cuenta, captcha, MFA, contraseñas largas.
Ataque de diccionario (Dictionary Attack): probar palabras comunes, contraseñas filtradas, variaciones conocidas. Más eficiente que fuerza bruta pura. Contramedida: contraseñas largas y complejas no basadas en palabras.
Credential Stuffing: usar listas de credenciales filtradas de otras brechas (usuario + contraseña de una brecha en sitio A para intentar acceder al sitio B). Funciona porque muchos usuarios reutilizan contraseñas. Contramedida: MFA, no reutilizar contraseñas (gestores de contraseñas).
Pass-the-Hash: en entornos Windows, robar el hash NTLM de una contraseña y usarlo directamente para autenticarse sin necesidad de conocer la contraseña en texto plano. Funciona porque el protocolo NTLM acepta el hash como credencial.
DoS (Denial of Service): inundar un servicio con tráfico o solicitudes para hacerlo inaccesible. Un solo origen.
DDoS (Distributed DoS): mismo objetivo pero usando una botnet (miles de equipos) como origen del ataque. Mucho más difícil de bloquear.
Man-in-the-Middle (MitM): el atacante se posiciona entre dos partes que se comunican, interceptando y potencialmente modificando el tráfico. Contramedida: TLS/HTTPS, certificados, HSTS.
ARP Spoofing: el atacante envía respuestas ARP falsas en una red local para asociar su dirección MAC con la IP de otro host (ej. el gateway). Permite ataques MitM en LAN.
DNS Spoofing / DNS Poisoning: corromper la caché de un servidor DNS para que resuelva un dominio legítimo hacia una IP maliciosa. Contramedida: DNSSEC.
Replay Attack: capturar una transmisión legítima (ej. token de autenticación) y retransmitirla para autenticarse. Contramedida: tokens con timestamp, nonces, HTTPS.
Phishing: emails fraudulentos que suplantan organizaciones legítimas para robar credenciales o instalar malware. El vector de ataque más común estadísticamente.
Spear Phishing: phishing dirigido a una persona o organización específica, con información personalizada para aumentar la credibilidad.
Whaling: spear phishing dirigido a altos ejecutivos (CEO, CFO).
Vishing (Voice Phishing): llamadas telefónicas fraudulentas.
Smishing: phishing por SMS.
Baiting: dejar un dispositivo USB con malware en un lugar donde la víctima lo encuentre y lo conecte.
Pretexting: crear una historia falsa (pretexto) para obtener información o acceso. Ejemplo: hacerse pasar por técnico de IT para solicitar credenciales.
Quid pro quo: ofrecer un servicio a cambio de información. Ejemplo: hacerse pasar por soporte técnico y ofrecer ayuda a cambio de credenciales.
Tailgating / Piggybacking: acceder a una zona física restringida siguiendo a alguien autorizado sin identificarse.
El OWASP Top 10 es la lista de las vulnerabilidades más críticas en aplicaciones web:
SQL Injection: el atacante inyecta código SQL en campos de entrada para manipular la base de datos.
-- Input normal: usuario = 'admin', password = 'mipassword'
-- Input malicioso: usuario = 'admin'--', password = 'cualquiera'
-- Query resultante: SELECT * FROM users WHERE user='admin'--' AND pass='...'
-- El '--' comenta el resto: SELECT * FROM users WHERE user='admin'
-- Resultado: acceso sin contraseña
XSS (Cross-Site Scripting): inyección de código JavaScript malicioso en páginas web que se ejecuta en el navegador de otros usuarios.
Un cortafuegos es un sistema (hardware y/o software) que controla el tráfico de red entrante y saliente basándose en reglas de seguridad predefinidas.
Filtrado de paquetes (Packet Filtering):
Examina los paquetes individualmente en base a:
- Dirección IP origen/destino.
- Puerto origen/destino.
- Protocolo (TCP, UDP, ICMP).
Inspección de estado (Stateful Inspection):
Mantiene una tabla de estado de las conexiones activas. Sabe si un paquete pertenece a una conexión ya establecida, lo que permite bloquear paquetes que no corresponden a ninguna conexión legítima. Es el modelo del examen (Pregunta 6).
Proxy / Application Gateway:
Opera a nivel de aplicación (capa 7). Analiza el contenido del tráfico, no solo las cabeceras. Puede hacer inspección profunda de protocolo (ej. bloquear comandos específicos de HTTP).
NGFW (Next-Generation Firewall):
Combina stateful inspection con funcionalidades avanzadas: DPI (Deep Packet Inspection), IPS integrado, identificación de aplicaciones (no solo por puerto), inspección TLS, control por usuario/identidad (integración con AD).
WAF (Web Application Firewall):
Cortafuegos específico para proteger aplicaciones web. Analiza tráfico HTTP/HTTPS. Protege contra SQLi, XSS, CSRF, etc. Puede ser hardware, software o cloud (Cloudflare WAF, AWS WAF).
Las reglas del cortafuegos del examen tienen la estructura:
Acción | IP origen | Máscara origen | IP destino | Máscara destino | Protocolo | Puerto origen | Puerto destino
Convenciones importantes:
- ANY / 0.0.0.0/0: cualquier dirección.
- Las reglas se procesan de forma secuencial: gana la primera regla que coincida.
- Regla por defecto (implícita al final): generalmente DENY ALL (denegar todo lo que no esté explícitamente permitido).
- Para un cortafuegos con inspección de estado, las respuestas de conexiones establecidas se permiten automáticamente, por lo que generalmente no es necesario añadir regla explícita para el tráfico de retorno.
Solución Pregunta 6a — Conexiones web entrantes (HTTP/80 y HTTPS/443) al servidor 139.44.55.23:
ACCEPT | ANY | ANY | 139.44.55.23 | /32 | TCP | ANY | 80
ACCEPT | ANY | ANY | 139.44.55.23 | /32 | TCP | ANY | 443
Solución Pregunta 6b — Conexiones DNS entrantes (UDP/53) al servidor 139.55.44.39:
ACCEPT | ANY | ANY | 139.55.44.39 | /32 | UDP | ANY | 53
ACCEPT | ANY | ANY | 139.55.44.39 | /32 | TCP | ANY | 53
Solución Pregunta 6c — Bloquear tráfico DNS saliente desde DMZ hacia 8.8.8.8, excepto desde 139.55.44.39:
ACCEPT | 139.55.44.39 | /32 | 8.8.8.8 | /32 | UDP | ANY | 53
DENY | 139.44.55.0 | /24 | 8.8.8.8 | /32 | UDP | ANY | 53
Segmento de red intermedio entre la red pública (Internet) y la red privada interna. Los servidores accesibles desde Internet (web, DNS, correo) se colocan en la DMZ.
Internet ──── [Firewall externo] ──── DMZ ──── [Firewall interno] ──── Red interna
(Servidores
públicos)
¿Por qué una DMZ? Si un servidor de la DMZ es comprometido, el atacante accede a la DMZ pero el firewall interno le impide acceder directamente a la red interna con datos sensibles.
IDS (Intrusion Detection System): detecta actividad sospechosa o maliciosa y genera alertas, pero no actúa (no bloquea tráfico). Opera en modo pasivo (copia del tráfico mediante port mirroring).
IPS (Intrusion Prevention System): detecta y bloquea activamente el tráfico malicioso. Opera en línea (inline), el tráfico pasa a través de él.
Métodos de detección:
- Basado en firmas: compara el tráfico contra una base de datos de patrones de ataques conocidos. Rápido y preciso para ataques conocidos; incapaz de detectar ataques nuevos (zero-days).
- Basado en anomalías: establece una línea base del comportamiento normal y alerta cuando se detectan desviaciones. Puede detectar ataques nuevos; genera más falsos positivos.
- Basado en reputación: bloquea IPs o dominios conocidos como maliciosos (threat intelligence feeds).
SIEM (Security Information and Event Management): plataforma que centraliza, correlaciona y analiza logs y eventos de seguridad de múltiples fuentes (firewalls, IDS, servidores, endpoints). Permite detectar patrones de ataque complejos que ningún sistema individual detectaría por separado. Ejemplos: Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM.
Una VPN crea un túnel cifrado sobre una red pública (Internet) que permite comunicarse de forma segura como si se estuviera en una red privada.
Propósitos principales:
- Acceso remoto seguro: empleados que trabajan desde casa acceden a la red corporativa de forma segura.
- Interconexión de sedes (Site-to-Site): conectar oficinas geográficamente separadas a través de Internet como si estuvieran en la misma LAN.
- Privacidad: ocultar el tráfico de Internet del ISP o de redes WiFi públicas no seguras.
- Bypass de restricciones geográficas: acceder a contenido bloqueado en cierta región.
Protocolos VPN:
| Protocolo | Puerto | Cifrado | Características |
|---|---|---|---|
| IPsec | UDP 500/4500 | AES, 3DES | Estándar, muy seguro. Dos modos: Transport (cifra solo payload) y Tunnel (cifra todo el paquete IP). Usado en VPNs corporativas y site-to-site. |
| OpenVPN | TCP 443 / UDP 1194 | OpenSSL (AES) | Open source, muy configurable, difícil de bloquear en TCP 443. |
| WireGuard | UDP 51820 | ChaCha20-Poly1305 | Moderno, muy simple (~4000 líneas de código vs 400.000 de OpenVPN), rápido, PFS por diseño. Integrado en Linux kernel. |
| L2TP/IPsec | UDP 1701 | IPsec | L2TP para el túnel + IPsec para el cifrado. Estándar amplio soporte. |
| SSTP | TCP 443 | TLS | Propietario de Microsoft. Buena integración con Windows. |
| IKEv2/IPsec | UDP 500 | IPsec | Rápido en reconexiones (MOBIKE). Muy bueno para móviles. |
Funcionamiento de un túnel VPN (IPsec en modo Túnel):
Paquete original: [IP src: 10.0.0.1] [IP dst: 10.1.0.5] [Datos]
│
[ENCAPSULADO + CIFRADO por IPsec]
│
Paquete VPN: [IP src: 203.0.113.1] [IP dst: 198.51.100.1] [IPsec header] [Datos cifrados]
└── IP pública del └── IP pública del
cliente VPN servidor VPN/gateway
Split tunneling: configuración VPN donde solo el tráfico hacia la red corporativa va cifrado por el túnel, mientras que el resto (ej. navegación web personal) va directamente a Internet sin pasar por el concentrador VPN.
Una política de contraseñas robusta debe incluir:
Requisitos de complejidad:
- Longitud mínima: 12 caracteres (NIST recomienda priorizar longitud sobre complejidad).
- Mezcla de mayúsculas, minúsculas, números y caracteres especiales.
- Prohibición de contraseñas en listas de contraseñas comprometidas conocidas (haveibeenpwned.com).
Gestión:
- No reutilizar las últimas N contraseñas.
- Cambio periódico (aunque el NIST SP 800-63B recomienda NO forzar cambios periódicos a menos que haya evidencia de compromiso, ya que genera contraseñas predecibles).
- Bloqueo de cuenta tras N intentos fallidos (típicamente 3-5).
- Uso de gestores de contraseñas para contraseñas únicas y aleatorias por servicio.
PAM (Privileged Access Management): gestión y control de cuentas con privilegios elevados (administradores, root, cuentas de servicio). Funcionalidades:
- Bóveda de contraseñas (vault): almacena las credenciales de cuentas privilegiadas. Las contraseñas se rotan automáticamente.
- Just-In-Time (JIT) access: los privilegios se conceden solo cuando son necesarios y por un tiempo limitado.
- Grabación de sesiones: todas las acciones realizadas con cuentas privilegiadas quedan registradas.
- Ejemplos: CyberArk, BeyondTrust, HashiCorp Vault.
SSO (Single Sign-On): el usuario se autentica una sola vez y accede a múltiples aplicaciones sin volver a introducir credenciales. Implementado con Kerberos (entornos Windows), SAML, OIDC.
Copia completa (Full Backup):
Copia de todos los datos del sistema, independientemente de si han cambiado desde la última copia.
- Ventaja: restauración más rápida y simple (solo necesitas el último backup completo).
- Desventaja: mayor tiempo de realización y mayor espacio de almacenamiento. No práctico realizarlo a diario en entornos con grandes volúmenes de datos.
Copia diferencial (Differential Backup):
Copia todos los datos modificados desde la última copia completa.
- Ventaja: restauración más rápida que incremental (solo necesitas la última completa + la última diferencial).
- Desventaja: crece con el tiempo (el sábado incluye todos los cambios de lunes a sábado).
- Para restaurar: última copia completa + última copia diferencial.
Copia incremental (Incremental Backup):
Copia solo los datos modificados desde la última copia (sea completa o incremental).
- Ventaja: más rápida de realizar, ocupa menos espacio por cada backup.
- Desventaja: restauración más lenta y compleja (necesitas la completa + todos los incrementales en orden).
- Para restaurar: última copia completa + todos los incrementales desde entonces.
Lunes: [FULL]
Martes: [DIFF: cambios desde Lunes] | [INCR: cambios desde Lunes]
Miércoles: [DIFF: cambios desde Lunes] | [INCR: cambios desde Martes]
Jueves: [DIFF: cambios desde Lunes] | [INCR: cambios desde Miércoles]
Viernes: [DIFF: cambios desde Lunes] | [INCR: cambios desde Jueves]
Restaurar Viernes:
DIFF: Full Lunes + Diff Viernes (2 backups)
INCR: Full Lunes + Incr Martes + Incr Miércoles + Incr Jueves + Incr Viernes (5 backups)
Esta regla garantiza que ningún fallo único (incendio, inundación, fallo de hardware) destruya todas las copias.
RPO (Recovery Point Objective): cuánto tiempo de datos como máximo se puede perder. Define la frecuencia mínima de las copias de seguridad. Si el RPO es 4 horas, hay que hacer backups al menos cada 4 horas.
RTO (Recovery Time Objective): cuánto tiempo como máximo puede estar el sistema inoperativo antes de que sea inaceptable para el negocio. Define qué tan rápido debe poder restaurarse el servicio.
RPO pequeño = backups frecuentes = mayor coste
RTO pequeño = infraestructura de alta disponibilidad = mayor coste
Último backup Fallo
│ │
──────────────●───────────────────X────────────────────►
│←─────────────────►│←──────────────────►
RPO RTO
(datos perdidos max) (tiempo recuperación max)
Plan y conjunto de procedimientos para restaurar sistemas y datos tras un incidente grave (incendio, inundación, ataque masivo, fallo catastrófico de hardware).
Estrategias de DR:
- Cold Site: instalación con infraestructura básica pero sin equipamiento activo. Hay que instalar y configurar todo desde cero. Bajo coste, alto RTO (días o semanas).
- Warm Site: instalación con equipamiento preinstalado pero no actualizado en tiempo real. RTO de horas a días.
- Hot Site: réplica exacta del entorno de producción, activa en tiempo real o casi real. RTO de minutos. Mayor coste.
- Cloud DR: replicación hacia cloud (AWS, Azure). Pago por uso, escalable, RTO variable según configuración.
NAS (Network-Attached Storage): dispositivo de almacenamiento conectado a la red que proporciona servicios de almacenamiento de archivos a múltiples clientes a través de protocolos estándar de red.
Protocolos: SMB/CIFS (Windows), NFS (Linux/Unix), AFP (macOS), iSCSI (acceso a nivel de bloque).
Características:
- Almacenamiento centralizado accesible desde múltiples equipos.
- Generalmente incluye RAID para tolerancia a fallos.
- Gestión simplificada vía interfaz web.
- Soporte para snapshots, replicación, control de acceso.
Diferencia NAS vs SAN:
| | NAS | SAN |
|---|---|---|
| Protocolo | Archivos (SMB, NFS) | Bloques (Fibre Channel, iSCSI) |
| Acceso | Múltiples clientes simultáneos | Un cliente por LUN (normalmente) |
| Rendimiento | Adecuado para uso general | Alto rendimiento para bases de datos |
| Coste | Bajo-medio | Alto |
| Uso típico | Almacenamiento de ficheros compartidos | Bases de datos, almacenamiento de VMs |
Deduplicación (Pregunta 8d):
Técnica de optimización del almacenamiento que identifica y elimina bloques de datos duplicados, almacenando solo una copia y referencias a ella.
Sin deduplicación:
Archivo A: [Bloque1][Bloque2][Bloque3][Bloque4]
Archivo B: [Bloque1][Bloque5][Bloque3][Bloque6]
Total almacenado: 8 bloques
Con deduplicación:
Almacenado: [Bloque1][Bloque2][Bloque3][Bloque4][Bloque5][Bloque6]
Archivo A → [Ref:1][Ref:2][Ref:3][Ref:4]
Archivo B → [Ref:1][Ref:5][Ref:3][Ref:6]
Total almacenado: 6 bloques (25% de ahorro)
Especialmente útil en backups (muchos archivos similares entre backups consecutivos) y entornos VDI (muchas VMs con el mismo SO base).
| Permiso | Archivos | Directorios |
|---|---|---|
| Lectura (Read) | Ver contenido y atributos del archivo | Listar el contenido del directorio |
| Escritura (Write) | Modificar el archivo, agregar datos | Crear archivos y subdirectorios |
| Ejecución (Execute) | Ejecutar el archivo si es un programa | Atravesar el directorio |
| Modificación (Modify) | Leer + Escribir + Eliminar el archivo | Leer + Escribir + Eliminar contenido |
| Lectura y ejecución (R&X) | Leer + Ejecutar | Listar + Atravesar |
| Control total (Full Control) | Todos los permisos + cambiar permisos + tomar posesión | Todos los permisos + cambiar permisos + tomar posesión |
Permisos heredados: se propagan automáticamente desde el objeto padre (directorio) a los objetos hijos (subdirectorios y archivos). Se muestran en gris en la interfaz de Windows.
Permisos explícitos: asignados directamente al objeto, sin ser heredados del padre. Tienen prioridad sobre los permisos heredados.
Ejemplo:
- Directorio C:\Proyectos tiene permiso de Lectura para el grupo "Usuarios".
- Un subdirectorio C:\Proyectos\Secreto hereda ese permiso de Lectura (heredado).
- Si al usuario "Pedro" se le asigna directamente Control Total en C:\Proyectos\Secreto, ese es un permiso explícito que coexiste con los heredados.
Jerarquía de prioridad:
1. Denegación explícita (más prioritaria).
2. Permiso explícito.
3. Denegación heredada.
4. Permiso heredado.
| Permisos NTFS | Permisos de uso compartido (Share) | |
|---|---|---|
| Aplican | Siempre, sea acceso local o en red | Solo cuando se accede por red (UNC path \servidor\recurso) |
| Granularidad | Muy detallados (6 tipos básicos + permisos especiales) | Solo 3: Lectura, Cambio, Control total |
| Cuando coexisten | Se aplica el permiso más restrictivo resultante de combinar ambos |
Regla práctica: cuando un usuario accede a un recurso compartido por red, Windows aplica primero los permisos de compartición y luego los NTFS. El permiso efectivo es el más restrictivo de los dos.
Ejemplo: si los permisos de compartición son "Control total" para un usuario, pero los permisos NTFS solo le dan "Lectura", el permiso efectivo por red es Lectura (el más restrictivo).
La mayoría de los ataques exitosos explotan vulnerabilidades conocidas y con parche disponible. Un programa de gestión de parches debe:
- Inventariar todos los sistemas y versiones de software.
- Monitorizar boletines de seguridad (CERT, fabricantes).
- Priorizar parcheo según criticidad del sistema y severidad CVSS.
- Probar parches en entorno de pruebas antes de producción.
- Definir SLAs de parcheo: ej. crítico (<72h), alto (<7 días), medio (<30 días).
Antivirus tradicional: detecta malware conocido comparando contra una base de datos de firmas. Reactivo (solo detecta lo que ya se conoce).
EDR (Endpoint Detection and Response): monitoriza continuamente el comportamiento de los endpoints para detectar actividades anómalas, incluso de malware desconocido o fileless. Permite respuesta: aislar el endpoint, terminar procesos, revertir cambios. Ejemplos: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne.
Dividir la red en segmentos mediante VLANs reduce el impacto de un compromiso: si un segmento es infectado (ej. con ransomware), el cortafuegos entre VLANs puede limitar la propagación lateral.
Implementar múltiples capas de seguridad de forma que si una falla, las demás sigan proporcionando protección:
[Capa Perimetral] → Firewall, IPS, WAF, DDoS protection
[Capa de Red] → Segmentación, VLANs, monitorización de tráfico
[Capa de Host] → EDR, antivirus, hardening, actualizaciones
[Capa de Aplicación] → Autenticación fuerte, validación de entradas, OWASP
[Capa de Datos] → Cifrado en reposo y en tránsito, backups, DLP
[Capa Humana] → Formación y concienciación, phishing simulado
Modelo de seguridad basado en el principio "nunca confiar, siempre verificar". Elimina el concepto de red interna como zona de confianza. Aplica autenticación y autorización estrictas para cada solicitud de acceso, independientemente del origen.
Pilares de Zero Trust:
- Verificar explícitamente la identidad en cada acceso (MFA, contexto).
- Usar acceso de mínimo privilegio (JIT, ABAC).
- Asumir siempre que puede haber una brecha (monitorización continua, segmentación).
Log management: recopilar, almacenar y analizar logs de todos los sistemas (firewalls, IDS/IPS, servidores, aplicaciones, endpoints). Los logs son esenciales para la detección de incidentes y el análisis forense posterior.
Alertas: definir reglas que generen alertas cuando se detecten patrones sospechosos:
- Múltiples intentos de login fallidos.
- Acceso fuera del horario habitual.
- Transferencia masiva de datos al exterior.
- Ejecución de herramientas de administración en equipos de usuario.
El factor humano es el eslabón más débil de la cadena de seguridad. El 90% de los ciberataques exitosos comienzan con un ataque de ingeniería social (phishing).
Medidas:
- Formación periódica en ciberseguridad para todos los empleados.
- Simulaciones de phishing para medir la vulnerabilidad real de la organización.
- Procedimientos claros para reportar incidentes sospechosos.
- Política de escritorios limpios (no dejar contraseñas escritas, documentos sensibles a la vista).
| Pregunta del examen | Concepto del tema |
|---|---|
| Q2 — MFA | Factores de autenticación, TOTP, biometría, análisis de enfoques MFA |
| Q5 — VPN | Túneles VPN, protocolos (IPsec, WireGuard, OpenVPN), cifrado híbrido |
| Q6 — Cortafuegos | Stateful inspection, reglas de firewall, DMZ, puertos estándar |
| Q7 — Malware | Tipos de malware, ransomware, respuesta a incidentes |
| Q8 — Almacenamiento | NAS, tipos de backup, RPO/RTO, deduplicación, regla 3-2-1 |
| Q9 — NTFS | Permisos NTFS, herencia, permisos explícitos, NTFS vs Sharing |
Pregunta 1
Una empresa ha detectado que un empleado ha podido acceder a documentos financieros confidenciales que no le corresponden. Al investigar, se comprueba que los permisos NTFS de esa carpeta tenían configurado Control Total para el grupo "Usuarios del Dominio" de forma heredada, pero también había un permiso explícito de Lectura para ese empleado específico.
a) ¿Cuál es el permiso efectivo del empleado sobre esa carpeta? Razone la respuesta según las reglas de prioridad de NTFS.
b) ¿Cómo debería haberse configurado para que solo los miembros del grupo "Contabilidad" tuvieran acceso?
c) ¿Qué diferencia habría si el acceso fuera por red a través de un recurso compartido con permisos de Lectura en el sharing?
Pregunta 2
Una organización quiere implementar MFA para el acceso a su sistema de gestión de RRHH. El director de sistemas propone tres opciones: (A) código SMS enviado al móvil personal del empleado, (B) aplicación TOTP en el móvil corporativo, (C) llave hardware FIDO2.
a) Clasifique cada opción según los factores de autenticación que utiliza y si constituye verdadera MFA combinada con la contraseña.
b) Ordene las tres opciones de menor a mayor seguridad y justifique su respuesta indicando las vulnerabilidades específicas de cada una.
c) ¿Qué opción recomendaría para empleados con acceso a datos especialmente sensibles y por qué?
Pregunta 3
Se va a implementar una PKI corporativa para emitir certificados a los servidores web internos, a los equipos de los empleados (para autenticación WiFi 802.1X) y para la VPN corporativa.
a) Describa la jerarquía PKI que implementaría, justificando por qué no usaría una única CA raíz para emitir todos los certificados directamente.
b) ¿Qué pasos debe seguir para que los certificados emitidos por su CA raíz sean reconocidos como de confianza en todos los equipos Windows del dominio?
c) Explique qué es la revocación de certificados y compare los mecanismos CRL y OCSP, indicando cuándo usaría cada uno.
Pregunta 4
El lunes por la mañana, varios empleados notifican que no pueden abrir sus archivos. En sus pantallas aparece un mensaje indicando que sus archivos han sido cifrados y que deben pagar 50.000 € en Bitcoin en 72 horas para obtener la clave de descifrado. Los archivos tienen extensión .locked.
a) ¿Qué tipo de malware es el responsable? Explique técnicamente cómo funciona el proceso de cifrado de este tipo de malware.
b) Describa los pasos inmediatos que tomaría como administrador de sistemas en las primeras horas tras detectar el incidente.
c) ¿Qué medidas preventivas, de haberlas implantado correctamente con anterioridad, habrían reducido significativamente el impacto de este ataque?
Pregunta 5
Se desea configurar el cortafuegos perimetral (stateful inspection) de una institución para los siguientes requisitos. La red interna es 192.168.1.0/24, la DMZ es 10.10.10.0/24, y el servidor de correo de la DMZ tiene IP 10.10.10.25.
a) Indique las reglas para permitir el tráfico SMTP entrante desde Internet (puerto 25) y SMTPS (puerto 465) únicamente hacia el servidor de correo.
b) Indique las reglas para denegar todo tráfico desde la DMZ hacia la red interna, excepto el tráfico de respuesta DNS (UDP/53) desde el servidor DNS de la DMZ (10.10.10.10) hacia los clientes internos.
c) ¿Por qué en un cortafuegos con inspección de estado no es necesario añadir reglas explícitas para el tráfico de retorno de las conexiones permitidas?
Pregunta 6
Una empresa almacena copias de seguridad de su servidor de ficheros (500 GB de datos totales, con 10 GB de cambios diarios) con la siguiente política: copia completa los domingos, copias diferenciales de lunes a sábado.
a) ¿Cuánto espacio necesita aproximadamente para almacenar una semana completa de backups con esta política?
b) Si el servidor falla el viernes a las 15:00 y el backup diferencial del viernes se realizó a las 02:00, ¿cuál es el RPO efectivo? ¿Qué copias necesitaría para restaurar al estado más reciente posible?
c) Compare esta política diferencial con una política incremental en términos de espacio de almacenamiento y tiempo de restauración.
d) Un nuevo administrador propone eliminar las copias semanales y guardar solo los últimos 3 backups diferenciales para ahorrar espacio. ¿Qué riesgo introduce esta decisión?
Pregunta 7
Una empresa tiene una arquitectura con un servidor web público (HTTPS), un servidor de base de datos interno y una red de empleados. Se detecta que un atacante ha conseguido extraer datos de la base de datos.
a) Explique el ataque de inyección SQL, cómo podría haberse usado para acceder a la base de datos y qué medidas de programación segura lo habrían prevenido.
b) El atacante pudo acceder al servidor web porque este ejecutaba un servicio de terceros desactualizado con una vulnerabilidad CVE-2023-XXXX con CVSS 9.8. ¿Qué proceso de gestión de vulnerabilidades debería haber detectado y resuelto esto antes del ataque?
c) Explique el principio de defensa en profundidad y cómo su correcta aplicación habría podido limitar el daño aunque el servidor web hubiera sido comprometido.
Pregunta 8
Se va a implementar una solución de acceso remoto seguro para los 200 empleados de una empresa que teletrabajan. El equipo de seguridad debate entre usar VPN IPsec y WireGuard.
a) Explique el concepto de Perfect Forward Secrecy (PFS) y por qué es importante en una VPN. ¿Qué protocolo de intercambio de claves lo proporciona?
b) Compare IPsec y WireGuard en términos de complejidad de implementación, rendimiento, seguridad y casos de uso recomendados.
c) Independientemente del protocolo elegido, ¿qué medidas de autenticación adicionales recomendaría para el acceso VPN y por qué?
Pregunta 9
Una empresa procesa datos de tarjetas de crédito y debe cumplir con PCI-DSS. El auditor señala que los datos de tarjetas almacenados en la base de datos están cifrados con AES-128-ECB.
a) ¿Por qué AES-128-ECB es una elección inadecuada para cifrar datos estructurados como números de tarjeta? Explique el problema del modo ECB con un ejemplo.
b) ¿Qué modo de operación de AES recomendaría y por qué? ¿Qué ventaja adicional proporciona AES-GCM respecto a AES-CBC?
c) El sistema almacena las contraseñas de los administradores como SHA-256(contraseña) sin sal. Explique el riesgo específico de esta implementación y qué función de hash debería usarse en su lugar.
Pregunta 10
Una organización quiere establecer un modelo de control de acceso para su nueva plataforma de gestión documental. Tiene los siguientes grupos de usuarios: directivos, empleados, auditores externos, y el sistema de backup automatizado.
a) Compare los modelos DAC, RBAC y ABAC. ¿Cuál o cuáles aplicaría en este escenario y por qué?
b) El auditor externo necesita acceso de solo lectura a los documentos financieros, pero únicamente durante el periodo de auditoría (del 1 al 31 de enero) y solo desde la red corporativa. ¿Qué modelo de control de acceso permite implementar esta regla de forma nativa? Exprese la regla en formato de política.
c) El sistema de backup necesita acceso de lectura a todos los documentos. ¿Qué principio de seguridad aplica al configurar los permisos de esta cuenta, y qué riesgos conlleva no aplicarlo correctamente?