Día 1 · Conceptos y controles de seguridad

El examen en una tabla

El Security+ V8 (código SY0-801) sale el 17 de noviembre de 2026 y reemplaza al SY0-701. Es una certificación de defensa: le preguntan cómo reconocer un ataque, cómo frenarlo y cómo responder.

Defensa en profundidad

Ningún control es perfecto. La defensa en profundidad (defense in depth) pone varias capas distintas, para que cuando una falle la siguiente siga protegiendo. Piense en el servidor de Nube Volcán:

1. Una cerradura y una bitácora de gafetes en la sala de servidores (capa física).
2. Un firewall que solo deja pasar lo necesario (capa de red).
3. Cuentas individuales, contraseñas fuertes y autenticación multifactor (capa de identidad).
4. Permisos mínimos sobre los archivos (capa del sistema).
5. Cifrado de los datos sensibles (capa de datos).
6. Registros revisados y alertas (capa de detección).
7. Políticas y capacitación del personal (capa humana).

Si un atacante adivina una contraseña, todavía le falta el segundo factor; si lo consigue, la cuenta no tiene privilegios; si llega a los datos, están cifrados; y en cada paso queda registro. Cuando el examen le describe varias capas de controles diferentes trabajando juntas, la respuesta es «defensa en profundidad» (también llamada layered security).

La tríada CIA

Todo en seguridad protege alguna de estas tres propiedades. En inglés se la llama CIA (confidentiality, integrity, availability), y no tiene nada que ver con la agencia.

Hay una forma útil de recordarla al revés: lo opuesto de CIA es DAD: divulgación (disclosure) rompe la confidencialidad, alteración (alteration) rompe la integridad y destrucción o denegación (destruction/denial) rompe la disponibilidad.

No repudio

El no repudio (non-repudiation) es poder demostrar que una persona hizo algo, de forma que no lo pueda negar después. Combina dos cosas: que el mensaje o la acción no se alteró (integridad) y que se sabe con certeza quién lo originó (autenticación del origen).

• Firmas digitales: si un contrato está firmado con la llave privada de Andrea, solo ella pudo firmarlo, y cualquier cambio posterior invalida la firma. Es el ejemplo clásico del examen; lo vemos a fondo el día 2.
• Registros con identidad individual: si cada persona entra con su propia cuenta y los registros están protegidos contra cambios, el registro prueba quién ejecutó cada comando.

Lo que destruye el no repudio son las cuentas compartidas. Si cinco técnicos usan la cuenta soporte con la misma contraseña, el registro dice «soporte detuvo el servidor web», pero nadie puede probar cuál de los cinco fue. Por eso las políticas exigen cuentas individuales.

AAA: autenticación, autorización y registro

El marco AAA ordena el acceso en tres pasos, siempre en este orden:

Antes de autenticar hay un paso previo, la identificación: decir quién es (escribir el usuario). La autenticación es demostrarlo. Los factores de autenticación son:

• Algo que usted sabe (something you know): contraseña, PIN.
• Algo que usted tiene (something you have): teléfono con una aplicación de códigos, llave de seguridad, tarjeta inteligente.
• Algo que usted es (something you are): huella, rostro, iris.
• Algún lugar donde usted está (somewhere you are): ubicación o red de origen.

La autenticación multifactor (MFA) combina factores de tipos distintos. Una contraseña y un PIN son dos cosas que usted sabe: eso no es MFA.

AAA no es solo para personas. Los sistemas también se autentican: un servidor presenta un certificado, un dispositivo se identifica ante la red antes de recibir acceso, una aplicación usa una cuenta de servicio con permisos acotados. En redes, los servidores AAA más conocidos son RADIUS (UDP 1812 y 1813; cifra solo la contraseña) y TACACS+ (TCP 49; cifra todo el contenido y separa las tres A, muy usado para administrar equipos de red).

En Linux, el registro está en /var/log/auth.log (familia Debian) o /var/log/secure (familia Red Hat). Una línea de sudo se ve así:

Oct 15 08:15:40 academia sudo: practicante : TTY=pts/1 ; PWD=/home/practicante ; USER=root ; COMMAND=/usr/bin/cat /srv/nomina/planilla-2026.csv

Ahí están las tres A juntas: el usuario se autenticó, sudo lo autorizó y el registro dejó constancia de qué hizo. Contar esas líneas por usuario es una revisión de registros básica:

$ grep 'COMMAND=' /var/log/auth.log | awk '{print $6}' | sort | uniq -c | sort -rn
      3 practicante
      2 soporte

Mínimo privilegio

El principio de mínimo privilegio (least privilege) dice que cada persona, proceso o sistema recibe solo los permisos necesarios para su trabajo, y solo durante el tiempo que los necesita. Un practicante que revisa tiquetes no necesita sudo; una cuenta de respaldos no necesita una shell interactiva; un servidor web no necesita escribir en su propio código.

Va de la mano con dos ideas que el examen usa como sinónimos parciales:

• Necesidad de saber (need to know): aunque tenga el nivel de autorización, solo ve la información que su tarea requiere.
• Separación de funciones (separation of duties): una tarea crítica se divide entre dos personas para que ninguna pueda cometer un fraude sola (quien aprueba un pago no es quien lo ejecuta).

El mínimo privilegio reduce el daño de todo: de un error, de una cuenta robada y de un programa malicioso que corre con los permisos del usuario que lo abrió.

Zero Trust

El modelo tradicional era un castillo con foso: todo lo que estaba dentro de la red de la empresa era confiable. El problema es que un atacante que entra (con una contraseña robada o un equipo infectado) hereda esa confianza y se mueve a gusto. Zero Trust elimina la confianza implícita: nunca confíe, verifique siempre. Estar dentro de la red no le da nada.

Sus principios:

• Verificar explícitamente cada solicitud: identidad, estado del dispositivo, ubicación, hora, sensibilidad del recurso.
• Mínimo privilegio, con acceso justo a tiempo (just-in-time) cuando se pueda.
• Asumir que ya hay una brecha: segmentar para que un compromiso no se extienda, y monitorear todo.
• Evaluación continua: la decisión no se toma una vez al iniciar sesión, se revisa durante toda la sesión.

Plano de control y plano de datos

La arquitectura de Zero Trust del documento NIST SP 800-207 se describe en dos planos. El temario del V8 ya no enumera sus piezas una por una (habla de «principios de Zero Trust» y, en el dominio 3, de autenticación de usuarios, gestión de dispositivos y control de acceso a aplicaciones), pero este es el vocabulario con que se plantean esas preguntas. El plano de control decide; el plano de datos ejecuta la decisión y transporta el tráfico.

En un servidor pequeño, una aplicación concreta de estas ideas es dejar de confiar en «cualquiera que llegue al puerto 22»: el SSH solo se acepta desde la red de administración y todo lo demás se niega por defecto. No es Zero Trust completo, pero reduce la zona de confianza implícita, y es lo que va a hacer en el laboratorio.

Seguridad física

Un control lógico perfecto no sirve si alguien se lleva el disco. Los controles físicos que el examen espera que reconozca:

Los registros de gafetes son evidencia: un acceso a la sala de servidores a las 3 a. m., o varios intentos denegados seguidos con el mismo gafete, son señales que se investigan. En el laboratorio va a revisar uno.

Tecnologías de engaño

Las tecnologías de engaño y disrupción (deception and disruption technology) ponen cebos que ningún usuario legítimo tiene motivo para tocar. Si alguien los toca, es casi seguro un atacante, y la alerta tiene muy pocos falsos positivos.

Las tecnologías de engaño son controles detectivos: no impiden el ataque, lo hacen visible temprano. Las técnicas de disrupción agregan obstáculos: respuestas falsas, puertos que parecen abiertos, tráfico señuelo que hace perder tiempo al atacante.

Categorías de controles

Un control es cualquier medida que reduce un riesgo. El examen los clasifica de dos formas a la vez: por categoría (cómo se implementa) y por tipo (qué efecto tiene). Primero las categorías:

La diferencia entre gerencial y operativo es la que más cuesta: la gerencia decide y documenta (la política de contraseñas), las personas ejecutan (el técnico que revisa cada mañana que los respaldos terminaron).

Tipos de controles

La matriz: un control tiene categoría y tipo

Cada control se ubica en una casilla de esta matriz. Ejemplos para cada combinación:

Análisis de brechas

Un análisis de brechas (gap analysis) compara el estado actual con el estado deseado. El estado deseado sale de una política interna, de una norma (ISO/IEC 27001, el marco de ciberseguridad del NIST, los controles CIS) o de un requisito de un cliente. El resultado es la lista de lo que falta, y de ahí sale un plan con prioridades, responsables y fechas.

1. Elegir la referencia: qué norma o política se va a usar.
2. Levantar el estado actual: inventario de controles, entrevistas, revisión de configuraciones y de evidencia.
3. Comparar control por control y anotar cada diferencia.
4. Priorizar las brechas según el riesgo y proponer cómo cerrarlas.

Con dos listas de texto, la comparación se puede hacer en la terminal:

$ while read c; do grep -qxF "$c" implementados.txt || echo "$c"; done < requeridos.txt
MFA para accesos administrativos
Registro centralizado (SIEM)

El ciclo recorre cada control requerido; grep -qxF busca la línea exacta (-x) como texto literal (-F) y en silencio (-q); si no la encuentra, || imprime el control que falta. El mismo resultado se obtiene ordenando las dos listas y usando diff.

Cómo se ve todo junto en una auditoría

Una auditoría inicial recorre los conceptos de hoy con preguntas concretas:

Su turno

En el laboratorio tiene el servidor de aplicaciones de Nube Volcán y los archivos de evidencia que le dejó Andrea en ~/auditoria. Cada tarea es un hallazgo de la auditoría: se marca sola cuando la cumple. Si se traba, pida una pista; si algo sale mal, el botón Reiniciar le devuelve el servidor como estaba. Y fíjese en algo mientras trabaja: cada cosa que corrige es un control con una categoría y un tipo. Al final los va a clasificar.