Preguntas de entrevista de CompTIA Security+

En la práctica, no. AES-128 ya exige unos 2^128 de esfuerzo para romperse por fuerza bruta — totalmente inviable — así que AES-256 no te hace realmente más seguro frente a la fuerza bruta; sobre todo añade margen (reserva poscuántica, cumplimiento). Ambos están estandarizados y sin romper. Tu modo (GCM), el manejo de nonces y la gestión de claves importan mucho más que 128 frente a 256. «AES-256 es el doble de seguro» es la idea errónea.

No. El antivirus es una señal, no una prueba. Omite ataques sin archivo y en memoria, muestras nuevas u ofuscadas, el abuso de herramientas legítimas (living-off-the-land) y los rootkits diseñados para ocultarse de él. La ausencia de prueba no es prueba de ausencia — la garantía real proviene de la telemetría EDR, el análisis forense de memoria, el análisis conductual y la caza de IOC. Tratar un análisis antivirus limpio como prueba de un sistema limpio es un error clásico de respuesta a incidentes.

No. Las tres categorías de factores de autenticación son algo que sabes (contraseña/PIN), algo que tienes (token/teléfono) y algo que eres (biometría). Una huella dactilar o un escaneo facial es «algo que eres», un rasgo físico medido. La trampa: la biometría no es un secreto y no puede rotarse — si la plantilla de tu huella se filtra, no puedes cambiar tu huella. Por eso la biometría funciona mejor como un factor, que a menudo desbloquea una clave local, y no como sustituto autónomo de la contraseña.

No se descifra — los hashes criptográficos son funciones unidireccionales sin inversa. «Crackear» un hash significa adivinar entradas candidatas, hashear cada una y comparar (diccionario, fuerza bruta, rainbow tables), que es justo por lo que se usan hashes lentos y salados para las contraseñas. No hay ninguna clave que «descifre» un hash. Si algo se puede descifrar, fue cifrado, no hasheado — y Base64 es codificación reversible, no hash.

No. El archivo de prueba EICAR es una cadena ASCII deliberadamente inofensiva de 68 bytes que todos los fabricantes de antivirus acuerdan detectar, para verificar con seguridad la detección y las alertas sin tocar malware real. Una detección significa que tu antivirus funciona — no que estés infectado. No es un virus y no hace nada si se ejecuta. Confundir una detección de prueba EICAR con una infección real es una trampa común al inicio de carrera.

En gran medida no. El nombre de host de destino se envía en claro en la extensión SNI del ClientHello de TLS, y tu consulta DNS suele revelarlo también, de modo que un ISP o una red pueden ver QUÉ sitio visitas incluso por HTTPS — solo que no pueden leer la ruta ni el contenido. El ClientHello cifrado (ECH) y el DNS-over-HTTPS pueden cerrar esta brecha, pero no son universales. «HTTPS lo oculta todo» es la idea equivocada.

No. TLS/HTTPS asegura los datos en tránsito entre cliente y servidor; una vez recibidos, la aplicación los descifra y los maneja en texto plano, y luego se almacenan según cómo esté configurada la base de datos. Proteger los datos en reposo es un asunto aparte — cifrado de disco/columna, un KMS y control de acceso. Confundir «usamos HTTPS» con «nuestros datos almacenados están cifrados» es una idea errónea común y peligrosa.

No. HTTPS cifra el canal para que los atacantes no puedan leer ni manipular el tráfico en tránsito, pero la entrada maliciosa llega, se descifra y la procesa tu aplicación igual que antes. La inyección SQL y el XSS son fallos de la capa de aplicación que se corrigen con consultas parametrizadas y codificación de salida, no con cifrado de transporte. El error supone que el cifrado sanea el contenido — no lo hace; el atacante simplemente envía la carga por la conexión HTTPS.

No. Una MAC la asigna el fabricante (OUI más identificador del dispositivo) y va «grabada», pero prácticamente todos los sistemas operativos permiten sobrescribirla por software (macchanger, ip link set address). Por tanto las direcciones MAC son suplantables y no deben usarse para autenticación — el filtrado MAC es débil, y los teléfonos ya aleatorizan la MAC por privacidad. «Permanente y única» es la idea equivocada.

No. La MFA sube mucho el listón, pero los factores OTP y push son phisheables: los kits de adversario en el medio (p. ej. Evilginx) retransmiten el inicio de sesión y el código en tiempo real, y la fatiga MFA / push-bombing empujan al usuario a aprobar. Los códigos capturados son reutilizables dentro de su corta ventana. El error es «MFA = imposible de phishear»; lo que importa es el tipo de factor. La MFA resistente al phishing — passkeys FIDO2/WebAuthn ligados al origen del sitio — es lo que realmente lo derrota.

No. El NAT (y el PAT) asigna direcciones privadas a una IP pública y, como efecto secundario, descarta las conexiones entrantes no solicitadas porque no existe ninguna correspondencia para ellas. Eso no es una política de seguridad — no hay inspección, ni reglas, ni registro — y la travesía de NAT, el hole punching y el C2 iniciado en salida pasan sin problema. El NAT es una herramienta de direccionamiento; aun así necesitas un cortafuegos real. «NAT = cortafuegos» es la idea equivocada.

No por sí solo. Muchos sistemas mantienen válidas las sesiones existentes y los tokens ya emitidos tras un cambio de contraseña — tokens de actualización OAuth, «contraseñas de aplicación», claves de API y cookies persistentes — así que un atacante con una sesión activa puede permanecer dentro. La respuesta correcta es cambiar la contraseña Y invalidar todas las sesiones y tokens, revocar las credenciales de aplicación y auditar los dispositivos MFA y los ajustes de recuperación. Creer que un restablecimiento solo expulsa al atacante es un error clásico de respuesta a incidentes.

No. POST simplemente lleva los parámetros en el cuerpo de la petición en vez de en la URL; ese cuerpo va en texto plano y es totalmente visible para quien pueda ver el tráfico, salvo que se use HTTPS. POST es preferible para acciones que cambian el estado y mantiene los parámetros fuera de URL, registros e historial, pero no aporta confidencialidad por sí mismo. El error confunde «no está en la URL» con «cifrado» — solo TLS cifra los datos de cualquiera de los dos métodos en tránsito.

No. La mayoría de las intrusiones reales establecen persistencia (servicios, tareas programadas, claves de inicio, implantes) que sobrevive a un reinicio, así que el atacante simplemente vuelve. Peor aún, apagar borra las pruebas volátiles — procesos en ejecución, conexiones de red, malware en memoria y claves de cifrado — que necesitas para acotar el incidente. Lo correcto es contener aislando el host mientras se preserva la memoria, y luego investigar. Reiniciar o apagar como «solución» es un instinto dañino.

No. Una sal es un valor aleatorio único almacenado justo al lado del hash; su función es lograr que contraseñas idénticas produzcan hashes distintos y anular las rainbow tables precalculadas — no permanecer en secreto. Es normal que un atacante que roba la base obtenga también las sales. Lo que protege de verdad las contraseñas es un hash lento y salado (bcrypt, scrypt, Argon2). Una «pimienta» secreta opcional y separada es un concepto diferente.

Pregunta trampa: no existe un único puerto de traceroute. El traceroute clásico de Unix envía datagramas UDP a puertos altos e improbables a partir de 33434 aproximadamente, con un TTL creciente; el tracert de Windows usa en cambio ICMP Echo. Funciona leyendo los mensajes ICMP Time Exceeded que devuelven los routers al expirar el TTL, no apuntando a un puerto reservado. Y el propio ICMP no tiene puertos.

El almacenamiento de contraseñas necesita un hash deliberadamente lento, salado y con alto coste de memoria — bcrypt, scrypt o Argon2 — para que crackear hashes robados sea costoso y las rainbow tables no apliquen. Un hash rápido como SHA-256 se fuerza por fuerza bruta trivialmente a gran escala; el cifrado reversible implica que una sola compromisión de clave expone todas las contraseñas a la vez; y el texto plano es indefendible por muy cerrada que esté la base de datos. Elija Argon2id (o bcrypt) con un factor de coste ajustado y un salt único por usuario.

SSLv3, TLS 1.0 y RC4 están rotos u obsoletos y permiten ataques de downgrade y descifrado, así que desactívelos y exija TLS 1.2 o 1.3 con suites de cifrado fuertes y con forward secrecy, aceptando la rara pérdida de clientes muy antiguos. Dejarlos activos por compatibilidad mantiene la debilidad explotable. Añadir un segundo certificado o pasar a uno autofirmado no elimina los protocolos débiles, y el autofirmado daña la confianza sin arreglar la criptografía.

Urgencia, autoridad y omitir la verificación son presión de ingeniería social de manual dirigida a una cuenta de alto valor. El agente debe seguir el proceso de verificación de identidad definido antes de restablecer nada, y escalar si no puede satisfacerse. Restablecer a demanda, usar una «pregunta de seguridad» adivinable como el color favorito, o enviar por correo la nueva contraseña al llamante entregan todos el control de la cuenta del directivo a un atacante.

Como los firewalls evalúan las reglas de arriba abajo, una regla any/any amplia cerca de la parte superior cortocircuita todas las reglas inferiores y permite todo el tráfico — el firewall deja en la práctica de aplicar nada. Reemplácela por reglas explícitas de mínimo privilegio para los flujos realmente necesarios, ordenadas para que los permisos y denegaciones específicos surtan efecto, terminando en una denegación por defecto. Llamarla eficiente es erróneo, moverla al final aún puede ocultar la denegación por defecto, y renombrarla no cambia nada de lo que permite.

LSASS almacena credenciales y secretos en caché, así que un proceso inesperado leyendo su memoria es el sello del robo de credenciales (por ejemplo, un volcado de tipo mimikatz). Tría el proceso ofensor y su padre, aísla el host para detener el movimiento lateral, y rota las credenciales que pudieron capturarse — incluidas las cuentas privilegiadas y de servicio. No tiene nada que ver con el renderizado gráfico ni el espacio en disco, e ignorarlo como normal puede llevar a un compromiso de todo el dominio. Los distractores de apariencia inocua son justo cómo los analistas pasan por alto una intrusión activa.

Word generando un proceso hijo justo después de habilitar las macros es un patrón clásico de acceso inicial por documento malicioso. Aísla el host para limitar la propagación, captura las pruebas volátiles, e investiga el proceso generado, su actividad de red y cualquier persistencia. Pedir al usuario que cierre el archivo o reparar Office no aborda una carga útil en ejecución que quizá ya corrió. No hacer nada porque el archivo llegó por correo es al revés — el correo es justamente el vector de entrega de este ataque. Contén primero, luego investiga.

El software legítimo rara vez ejecuta PowerShell desde %TEMP% mediante una tarea programada recién creada — es una técnica común de persistencia y ejecución. Examina la definición de la tarea, el script invocado, el proceso creador y la cronología, contén el host y barre el entorno en busca del mismo patrón. Las actualizaciones no se ven así, confiar ciegamente en las tareas programadas ignora una TTP conocida, y borrar System32 rompe el sistema operativo sin hacer nada contra la amenaza. Las tres primeras opciones reflejan un criterio peligrosamente débil.

Los puertos de administración abiertos a todo Internet se escanean y atacan por fuerza bruta en minutos, así que la solución es reducir la superficie de ataque: restringe el ingreso del security group a CIDR de administración conocidos o VPN, o elimina por completo el tráfico entrante usando un bastión o SSM Session Manager. Mover SSH a un puerto no estándar es seguridad por oscuridad que los escáneres vencen de forma trivial. Una contraseña más fuerte no reduce la superficie expuesta ni detiene el credential stuffing. Confiar en un firewall de host ignora la superficie de ataque que el security group anuncia abiertamente a Internet.

Una RCE sin autenticar en un servidor expuesto a Internet es de nivel emergencia: reduce la ventana de exposición con un despliegue probado, por etapas o gradual, y añade controles compensatorios (restringir el acceso, reglas WAF) mientras tanto. Esperar a la ventana trimestral deja un agujero explotable como un gusano abierto durante semanas. Parchear a ciegas en producción en horario laboral sin pruebas arriesga una caída y un rollback chapucero. Confiar en el firewall perimetral no sirve de nada — el servicio ya está expuesto y el exploit no necesita credenciales.

Trata cualquier secreto subido como quemado: revócalo y rótalo primero, porque los bots rastrean los commits públicos en segundos, luego revisa CloudTrail en busca de abusos y purga el secreto del historial. Borrar el commit no sirve de nada — la clave ya está clonada, bifurcada y cacheada por terceros. Hacer el repo privado deja una clave ya filtrada y activa en manos de los atacantes. Añadir el archivo al .gitignore no cambia nada para un secreto ya commiteado.

Los datos sensibles nunca deberían llegar a los registros: redacta o enmascara en el origen primero para detener la hemorragia, luego remedia los registros históricos y restringe el acceso. PCI DSS prohíbe almacenar así los PAN completos y los CVV, y las contraseñas nunca deberían registrarse. Unos registros «internos» siguen siendo un objetivo de primer orden. Cifrar o restringir el acceso al almacén sigue dejando secretos en texto plano en los registros, accesibles para cualquiera con permiso de lectura — copias de seguridad, pipelines de SIEM y administradores los ven todos.

Valida antes de escalar. Las VPN corporativas, los proxies en la nube (CASB o IP de servicio de M365) y los operadores móviles producen rutinariamente falsos «viajes imposibles»; comprueba las IP de salida, el resultado MFA y el dispositivo/user-agent antes de actuar. Bloquear en cada disparo causa fatiga de alertas y erosiona la confianza de los usuarios en el SOC. Asumir que siempre es un falso positivo deja pasar una apropiación de cuenta real. Escribir al jefe es lento y no es un control — los registros responden más rápido y con más fiabilidad.

Asume que la contraseña ya está comprometida: fuerza un restablecimiento Y revoca las sesiones y tokens activos de la cuenta, porque un reset por sí solo no expulsa a un atacante que ya posee una sesión viva o un token de actualización. Luego caza inicios de sesión anómalos, solicitudes MFA, reglas de buzón y concesiones OAuth de la ventana de exposición. Borrar el correo o decirle al usuario que cambie la contraseña «la próxima vez» deja la cuenta abierta de par en par. Un análisis antivirus aborda el malware del endpoint, no las credenciales robadas en la nube.

Tría por impacto y alcanzabilidad: el volcado de credenciales (firma de mimikatz) en un controlador de dominio es un evento sobre las joyas de la corona que puede llevar a la compromisión total del dominio, así que trabájalo primero. El escaneo de puertos externo ya fue bloqueado por el IDS, la extensión de navegador no aprobada es de baja gravedad, y un certificado TLS caducado en una máquina de prueba interna es informativo. La habilidad central del SOC es priorizar por radio de impacto y probabilidad de escalada, no por la antigüedad ni por lo «ruidosa» que sea la alerta.

La IA ayuda al SOC triando y deduplicando alertas, resumiendo incidentes, enriqueciendo contexto, redactando detecciones y acelerando la incorporación de analistas, reduciendo la fatiga y el tiempo de permanencia. Los riesgos: conclusiones alucinadas o erróneas con seguridad, sesgo de automatización donde los analistas dejan de verificar, prompt injection mediante datos de logs o alertas controlados por el atacante, fuga de datos sensibles a modelos de terceros, y adversarios que usan las mismas herramientas. Mantén un humano en el bucle, verifica las salidas y aísla las entradas no confiables.

La prompt injection directa es cuando un usuario escribe instrucciones adversarias directamente en el prompt para anular el system prompt o las reglas de seguridad. La prompt injection indirecta esconde instrucciones maliciosas dentro de contenido externo que el modelo ingiere después —una página web, un correo, un PDF o un documento RAG—, de modo que el ataque se dispara sin que la víctima lo escriba. La inyección indirecta es el mayor riesgo porque el atacante y la víctima son personas distintas, y la carga útil llega en datos en los que la app confía implícitamente.

El manejo inseguro de salidas es confiar en lo que el modelo devuelve y pasarlo a un sistema aguas abajo sin validación ni codificación. Como la salida del modelo es influenciable por el atacante, renderizarla como HTML en bruto causa XSS, pasarla a un recuperador de URL causa SSRF, y pasarla a un shell o una consulta SQL causa inyección de comandos o SQL. La solución es tratar la salida del modelo exactamente como entrada de usuario no confiable: codificación de salida sensible al contexto, listas de permitidos, saneamiento y parametrización antes de que llegue a cualquier sink.

Un jailbreak ataca el alineamiento de seguridad del modelo: engaña al modelo para que produzca contenido que el proveedor intentó prohibir, como instrucciones dañinas. La prompt injection ataca la jerarquía de instrucciones de la aplicación: anula el system prompt del desarrollador o secuestra el comportamiento del modelo dentro de una app, a menudo mediante datos no confiables. Los jailbreaks atacan el modelo; la prompt injection ataca el sistema circundante. Se solapan, pero el objetivo y el límite de confianza que cruzan son distintos.

Las apps LLM filtran datos de varias formas: el modelo memoriza y regurgita datos sensibles de entrenamiento o fine-tuning, el system prompt (que puede guardar secretos o lógica) se extrae, los documentos RAG recuperados exponen datos que el usuario no debería ver, y el contexto de un usuario o sesión se mezcla con otro. La prevención implica minimización de datos antes del entrenamiento, nunca poner secretos en los prompts, aplicar autorización por usuario en la recuperación, filtrado de salidas y redacción de PII, y aislamiento por inquilino.

El credential stuffing reproduce pares usuario:contraseña conocidos de brechas de terceros, apostando a la reutilización de contraseñas: alta tasa de éxito por intento, a menudo repartido entre muchas IP y dispositivos para parecer humano. El password spraying prueba una o dos contraseñas comunes (como Winter2026!) en muchas cuentas para mantenerse bajo los umbrales de bloqueo. El stuffing explota la reutilización; el spraying explota contraseñas compartidas débiles. La MFA derrota a ambos.

La Cyber Kill Chain modela una intrusión como siete etapas secuenciales: reconocimiento, armamentización, entrega, explotación, instalación, comando y control (C2) y acciones sobre objetivos. Los defensores asignan detecciones y controles a cada etapa; como las etapas son secuenciales, romper un solo eslabón —bloquear el correo de phishing, matar el C2— interrumpe todo el ataque. Empuja a detectar pronto en vez de solo en la brecha final.

La exfiltración por DNS codifica datos robados en consultas DNS (p. ej. etiquetas de subdominio largas enviadas a un servidor autoritativo controlado por el atacante), abusando de que el DNS casi siempre está permitido en salida y a menudo sin monitorizar. Detéctala con anomalías: volumen de consultas inusualmente alto a un dominio, subdominios largos / de alta entropía, muchos subdominios únicos por dominio padre, abuso de registros TXT/NULL y consultas a dominios recién registrados o raros.

El antivirus tradicional coteja archivos contra firmas de malware conocido y los bloquea o pone en cuarentena: bueno contra amenazas conocidas, débil ante ataques nuevos o sin archivo. El EDR registra de forma continua el comportamiento del endpoint (procesos, red, registro, memoria), usa analítica de comportamiento para detectar actividad sospechosa y permite a los respondedores investigar, cazar y contener o revertir de forma remota. El AV es prevención por firma; el EDR añade visibilidad, detección y respuesta.

El modelo clásico es PICERL: Preparación, Identificación (detección), Contención, Erradicación, Recuperación y Lecciones aprendidas. El NIST lo agrupa como Preparación; Detección y análisis; Contención, erradicación y recuperación; y Actividad posterior al incidente. El orden importa porque debes delimitar y contener antes de erradicar, y solo recuperas una vez eliminada la amenaza, o reinfectas. Es un bucle, no una línea: las lecciones aprendidas realimentan la preparación.

Un IOC es un artefacto forense de que algo malicioso ya ocurrió: un hash de archivo malicioso, una IP o dominio de C2, una clave de registro conocida como dañina. Un IOA es una señal de comportamiento de un ataque que se desarrolla, independientemente de las herramientas concretas, p. ej. un documento de Word que lanza PowerShell y luego sale a Internet. Los IOC son reactivos y fáciles de evadir cambiando un hash; los IOA capturan la intención y sobreviven a los cambios de herramienta.

La persistencia es cómo el malware sobrevive a reinicios y cierres de sesión. Los básicos en Windows son las claves Run/RunOnce del registro (HKLM y HKCU), las tareas programadas y los servicios de Windows, además de las carpetas de inicio, las suscripciones a eventos WMI y el secuestro de DLL. Los cazas con autoruns/Sysinternals, Sysmon y los registros de eventos, buscando binarios sin firmar, rutas extrañas como %AppData% y entradas creadas justo tras el compromiso inicial.

El orden de volatilidad clasifica la evidencia según lo rápido que se desvanece, para recopilar primero lo más frágil. A grandes rasgos: registros/caché de CPU, luego RAM y estado en ejecución (procesos, conexiones de red, ARP), luego archivos temporales/swap, luego disco, luego registro y datos de monitorización remotos y, por último, soportes de archivo y copias de seguridad. También trabajas sobre copias forenses, las hasheas y mantienes una cadena de custodia para que la evidencia siga siendo admisible.

En Windows, los hashes de cuentas locales (NTLM) viven en la subárbol SAM en C:\Windows\System32\config\SAM, protegido mientras el SO está en marcha; las credenciales vivas residen en la memoria de LSASS, y los hashes de dominio están en NTDS.dit en un controlador de dominio. En Linux, los hashes están en /etc/shadow (legible solo por root), mientras que /etc/passwd guarda los metadatos de la cuenta. Los atacantes los roban para crackear contraseñas sin conexión o hacer pass-the-hash.

La inyección de procesos ejecuta el código del atacante dentro del espacio de memoria de un proceso legítimo para que la actividad se mezcle y herede la confianza de ese proceso. Las técnicas clásicas incluyen la inyección de DLL (CreateRemoteThread + LoadLibrary), el process hollowing (lanzar un proceso benigno suspendido, desmapearlo, escribir código malicioso) y la inyección APC. Los defensores la detectan con hooks de API del EDR, relaciones padre/hijo o regiones de memoria anómalas (RWX, memoria ejecutable sin respaldo en archivo) y eventos CreateRemoteThread de Sysmon.

El ransomware es malware que cifra (y cada vez más exfiltra) datos y luego exige pago. En un caso activo: aislar los hosts afectados de la red sin apagarlos si puedes preservar la memoria, identificar el alcance, el paciente cero y la cepa, preservar la evidencia, encontrar y expulsar el punto de apoyo y cualquier puerta trasera, y luego restaurar desde copias offline reconocidas como limpias. Pagar es un último recurso y nunca garantiza la recuperación.

SPF publica qué IP pueden enviar correo en nombre de un dominio. DKIM añade una firma criptográfica para que el receptor verifique que el mensaje no fue alterado y proviene del dominio. DMARC liga los resultados de SPF/DKIM al encabezado From: visible mediante la «alineación», indica a los receptores qué hacer ante un fallo (none/quarantine/reject) y envía informes. SPF y DKIM por sí solos no protegen el From que ve el usuario; DMARC es lo que lo impone.

El análisis estático examina una muestra sin ejecutarla —hashes, cadenas, imports, encabezados y desensamblado—, así que es seguro y de cobertura completa, pero lo derrotan el empaquetado y la ofuscación. El análisis dinámico detona la muestra en un sandbox aislado y observa el comportamiento real —archivos, registro, procesos, red—, lo que atraviesa la ofuscación pero solo revela lo que se ejecuta en esa sesión y puede ser evadido por malware consciente del sandbox. Los analistas combinan ambos.

Un honeypot es un sistema o servicio señuelo sin uso de negocio legítimo, expuesto deliberadamente para atraer atacantes. Como nada benigno debería tocarlo nunca, cualquier interacción es una alerta de alta confianza. Los honeypots de baja interacción emulan servicios de forma barata; los de alta interacción son sistemas reales que rinden inteligencia más rica pero conllevan más riesgo. Los honeytokens son la misma idea aplicada a credenciales, archivos o registros falsos. Valor: detección temprana, pocos falsos positivos e inteligencia de amenazas.

El registro Security es primario: 4624 inicio de sesión correcto (con tipo de inicio), 4625 inicio fallido, 4634/4647 cierre de sesión, 4672 privilegios especiales asignados, 4720 cuenta creada, 4688 creación de procesos (con línea de comandos si está habilitada) y 4768/4769 Kerberos. Añade 7045 instalación de servicio (registro System), 4698 tarea programada creada y el registro de bloques de script de PowerShell (4104). El tipo de inicio de sesión y la auditoría de líneas de comandos son lo que hace útiles estos registros.

El cifrado en tránsito (TLS) protege los datos que se mueven por la red frente a la escucha y la manipulación; aplica TLS en todas partes y rechaza el texto plano. El cifrado en reposo protege los datos almacenados en discos y copias de seguridad, normalmente mediante claves gestionadas por KMS usando cifrado por sobre. Ambos son controles básicos, pero ninguno detiene una solicitud autorizada pero maliciosa — el servicio descifra de forma transparente para los llamantes válidos — así que el control de acceso sigue siendo lo más importante.

Un usuario es una identidad de larga duración con credenciales permanentes; un rol es una identidad sin credenciales permanentes que cualquier principal de confianza puede asumir para obtener tokens de corta duración; una política es el documento JSON que concede permisos, adjunto a cualquiera de los dos. El privilegio mínimo significa preferir roles a usuarios, acotar las políticas a acciones y recursos específicos, y conceder solo lo que una tarea necesita — y luego revisar y depurar con el tiempo.

Los security groups son cortafuegos con estado adjuntos a instancias/ENI: solo tienen reglas de permitir, y el tráfico de retorno de un flujo permitido se autoriza automáticamente. Las network ACL son filtros sin estado en el límite de la subred: tienen reglas ordenadas de permitir y denegar, y debes permitir explícitamente el tráfico de retorno en los puertos efímeros. Los security groups son el control principal; las NACL añaden barreras gruesas a nivel de subred, como bloquear un rango de IP.

El proveedor asegura la nube en sí — centros de datos físicos, hardware, el hipervisor y los servicios gestionados que ejecuta. Tú aseguras lo que pones en la nube — tus datos, identidades, configuraciones, el parcheo del SO cuando corresponda, y los controles de acceso. La línea exacta se desplaza: con IaaS eres dueño desde el SO hacia arriba, con SaaS eres dueño sobre todo de los datos y el acceso.

RSA es un algoritmo asimétrico usado para cifrar datos o crear firmas digitales con un par de claves. Diffie-Hellman es un protocolo de acuerdo de claves que permite a dos partes derivar un secreto compartido sobre un canal público sin transmitirlo nunca. Resuelven problemas distintos: RSA prueba identidad y puede envolver claves; DH negocia una clave de sesión, y su variante efímera ofrece confidencialidad hacia adelante.

Una firma digital es el hash de un mensaje transformado con la clave privada del firmante. El verificador recalcula el hash, aplica la clave pública del firmante y comprueba que coinciden. Como solo el firmante posee la clave privada, una firma válida prueba que el mensaje proviene de él (autenticidad), no fue alterado (integridad) y que no puede negarlo de forma creíble (no repudio).

Un HMAC es un código de autenticación de mensajes con clave: aplica un hash al mensaje junto con una clave secreta mediante una construcción anidada (hash interno y externo con rellenos derivados de la clave). Prueba tanto la integridad (el mensaje no fue alterado) como la autenticidad (proviene de alguien que posee la clave). Un hash simple no prueba ninguna de las dos, ya que cualquiera puede recalcularlo; HMAC además resiste ataques de extensión de longitud.

Un JWT tiene tres partes en base64url —cabecera, carga útil (reclamaciones) y firma— unidas por puntos. El servidor firma la cabecera y la carga útil con un secreto o una clave privada, y verifica esa firma en cada solicitud para confiar en las reclamaciones sin estado de sesión en el servidor. Errores: aceptar alg=none, la confusión de claves de RS256 a HS256, no validar expiración/emisor/audiencia, poner secretos en la carga útil legible, y la falta de una vía de revocación.

Kerberos depende de un centro de distribución de claves (KDC) de confianza. El cliente se autentica una vez ante el servidor de autenticación y obtiene un ticket de concesión de tickets (TGT) cifrado con la clave del KDC. Para alcanzar un servicio, presenta el TGT al servicio de concesión de tickets y recibe un ticket de servicio cifrado con la clave de ese servicio. El servicio lo descifra y confía en él. Las contraseñas nunca atraviesan la red, y los tickets tienen tiempo limitado.

La aplicación redirige al usuario al servidor de autorización para iniciar sesión y dar consentimiento. El servidor redirige de vuelta con un código de autorización de corta duración. El backend de la aplicación intercambia luego ese código (más su secreto de cliente) en el endpoint de token por un token de acceso, sobre un canal trasero de servidor a servidor. Esto mantiene los tokens fuera del navegador/la URL. Los clientes públicos añaden PKCE para vincular el código al solicitante original.

Almacena las contraseñas usando una función de hashing de contraseñas deliberadamente lenta, salada y adaptativa —bcrypt, scrypt o Argon2— nunca un hash rápido de propósito general como SHA-256 o MD5. Los hashes rápidos están hechos para la velocidad, así que atacantes con GPU pueden probar miles de millones de intentos por segundo contra una base de datos filtrada. Los hashes lentos tienen un factor de trabajo ajustable (y un coste de memoria) que hace cada intento caro, manteniendo la fuerza bruta impracticable incluso tras una filtración.

Perfect Forward Secrecy (PFS) significa que cada sesión deriva una clave única de un intercambio de claves efímero que se descarta después. Si un atacante roba más tarde la clave privada de largo plazo del servidor, aún no puede descifrar el tráfico capturado previamente, porque esa clave nunca se usó para derivar las claves de sesión. Se logra con Diffie-Hellman efímero (DHE/ECDHE).

Una sal es un valor aleatorio único generado por usuario y combinado con la contraseña antes del hashing. Garantiza que contraseñas idénticas produzcan hashes diferentes y vuelve inútiles los ataques precalculados como las tablas arcoíris, ya que el atacante necesitaría una tabla distinta por sal. Las sales se almacenan junto al hash. Una pimienta es un valor secreto adicional, el mismo para todos los usuarios, guardado por separado (por ejemplo, en la configuración de la app o un HSM) para que una filtración de la base de datos sola no baste.

El SSO centraliza la autenticación en un proveedor de identidad (IdP). Cuando un usuario visita un proveedor de servicio (la app), la app redirige al IdP; el usuario inicia sesión una vez, y el IdP devuelve una aserción o token firmado que avala su identidad. SAML lo lleva como una aserción XML firmada; OIDC lo lleva como un token de identidad JSON firmado montado sobre OAuth 2.0. La app confía en la firma del IdP en lugar de manejar las contraseñas ella misma.

TOTP (contraseña de un solo uso basada en tiempo) combina un secreto compartido, establecido en el registro, con la hora actual dividida en ventanas fijas (normalmente 30 segundos). Ejecuta HMAC sobre el contador del paso de tiempo con el secreto, luego trunca el resultado a un código de 6 dígitos. Tanto la app como el servidor tienen el mismo secreto y reloj, así que calculan independientemente el mismo código, sin necesidad de llamada de red. El código rota en cada ventana.

El escaneo de IaC analiza estáticamente definiciones de Terraform, CloudFormation, Kubernetes y similares contra una política para detectar configuraciones erróneas — buckets S3 públicos, grupos de seguridad abiertos, cifrado ausente — antes de que se aprovisionen. Como la misma plantilla aprovisiona muchos recursos, corregirla una vez evita la deriva repetida, y detectarlo antes de aplicar es mucho más barato que remediar recursos cloud en producción. Las herramientas incluyen Checkov, tfsec y KICS, idealmente aplicadas como barreras de policy-as-code.

El SAST lee el código fuente sin ejecutarlo y encuentra pronto fallos como los puntos de inyección, pero con muchos falsos positivos. El DAST ataca la aplicación en ejecución desde fuera, sin visibilidad del código, y encuentra problemas realmente explotables pero tarde y con cobertura superficial. El IAST instrumenta la aplicación en ejecución para correlacionar el comportamiento en runtime con el código, obteniendo resultados precisos con contexto del código, pero necesita una aplicación ejercitada y soporte de un agente.

Un SBOM es un inventario legible por máquina de cada componente, biblioteca y dependencia de un software, con versiones e idealmente hashes. Importa porque cuando aparece una nueva vulnerabilidad, puedes consultar tus SBOM para responder al instante a «¿estamos afectados y dónde?» en lugar de improvisar. Los dos estándares dominantes son SPDX y CycloneDX, y los SBOM son cada vez más exigidos por la normativa y las compras.

El cliente y el servidor acuerdan un secreto compartido en un solo viaje de ida y vuelta usando Diffie-Hellman efímero (ECDHE). El ClientHello lleva los grupos compatibles y un key share; el servidor responde con su key share y su certificado, ambas partes derivan las mismas claves, y los datos de aplicación fluyen de inmediato, con confidencialidad hacia adelante por defecto.

La tríada CIA son los tres objetivos centrales de la seguridad de la información: confidencialidad (solo las partes autorizadas pueden leer los datos), integridad (los datos no se alteran sin autorización) y disponibilidad (los usuarios autorizados pueden acceder a los sistemas cuando los necesitan). Casi todo control se relaciona con uno o varios de estos objetivos.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Asume que ningún control es perfecto — por ejemplo, combinando firewall, segmentación de red, protección de endpoints, MFA, mínimo privilegio y cifrado en lugar de confiar solo en el perímetro.

La codificación (como Base64) es un cambio de formato reversible sin secreto — no es seguridad. El cifrado es reversible con una clave y protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de longitud fija, usado para comprobaciones de integridad y almacenamiento de contraseñas, y no puede revertirse para obtener la entrada.

Un IDS (sistema de detección de intrusiones) monitoriza el tráfico y genera alertas pero no bloquea — suele estar fuera de banda. Un IPS (sistema de prevención de intrusiones) se sitúa en línea en la ruta del tráfico y puede descartar o bloquear activamente el tráfico malicioso. El IPS previene, pero un falso positivo puede romper tráfico legítimo.

El mínimo privilegio significa que cada usuario, proceso y servicio recibe solo el acceso mínimo necesario para su tarea, y nada más. Limita el radio de impacto de una cuenta comprometida, reduce el riesgo de amenaza interna y disminuye la superficie de ataque. Se aplica mediante acceso basado en roles, revisiones de acceso periódicas y elevación justo a tiempo.

La MFA exige dos o más factores de autenticación de categorías diferentes — algo que sabes (contraseña), algo que tienes (teléfono/token), algo que eres (biometría). Ayuda porque un atacante que roba un factor, como una contraseña, aún no puede iniciar sesión sin los demás. La MFA resistente al phishing como FIDO2 es la más fuerte.

El phishing es ingeniería social que engaña a las personas para que revelen credenciales, envíen dinero o ejecuten malware, normalmente mediante correos o sitios falsos. La defensa es por capas: filtrado y autenticación de correo (SPF/DKIM/DMARC), MFA para limitar el daño de credenciales robadas, formación de concienciación y una forma sencilla de reportar mensajes sospechosos.

El cifrado simétrico usa una única clave secreta compartida para cifrar y descifrar y es rápido, pero ambas partes ya deben compartir la clave. El asimétrico usa un par de claves pública/privada, resolviendo el problema de distribución de claves pero más lentamente. Protocolos reales como TLS usan criptografía asimétrica para intercambiar una clave simétrica y luego cambian a simétrica para el grueso de los datos.

TCP está orientado a conexión y es fiable: usa un handshake de tres vías, garantiza la entrega ordenada y retransmite los paquetes perdidos. UDP es sin conexión y rápido, sin garantías de entrega, orden ni congestión. Usa TCP para la exactitud (web, correo, transferencia de archivos) y UDP para tráfico sensible a la velocidad (DNS, VoIP, streaming, videojuegos).

Una vulnerabilidad es una debilidad (software sin parchear). Una amenaza es un actor o evento que podría explotarla (un grupo de ransomware). El riesgo es la combinación de la probabilidad de que una amenaza explote una vulnerabilidad y el impacto si lo hace. Riesgo = amenaza x vulnerabilidad x impacto, y es lo que realmente se prioriza.

Un firewall controla el tráfico entre zonas de red permitiéndolo o denegándolo según reglas. Un firewall sin estado evalúa cada paquete de forma aislada frente a las reglas; un firewall con estado rastrea el estado de las conexiones para permitir el tráfico de retorno de las sesiones que autorizó. Los firewalls de nueva generación añaden conocimiento de la capa de aplicación.

Un día cero es una vulnerabilidad que el fabricante aún no conoce (o no ha parcheado), por lo que los defensores han tenido «cero días» para arreglarla. Como no existe parche, la defensa se apoya en controles por capas, detección por comportamiento, segmentación, mínimo privilegio y respuesta rápida a incidentes en lugar de una firma.

Ninguno. ARP es un protocolo de capa 2 (capa de enlace) que se encapsula directamente en una trama Ethernet, no dentro de un paquete IP. Como nunca viaja sobre IP, no puede usar TCP ni UDP, que son transportes de capa 4 que requieren IP por debajo. La función de ARP es resolver una dirección IP conocida a la dirección MAC correspondiente en el mismo segmento de red local.

Comprime primero y luego cifra. Un buen cifrado produce una salida estadísticamente indistinguible de lo aleatorio, así que el texto cifrado no tiene patrones que comprimir: comprimir después es inútil. La advertencia importante: comprimir juntos datos secretos y datos controlados por el atacante antes de cifrar puede filtrar información a través de la longitud del texto cifrado, que es exactamente lo que hacen los ataques CRIME y BREACH.

Porque «eliminar» normalmente no borra los datos. Quita los metadatos del sistema de archivos (el puntero/la entrada de directorio) y marca los bloques como libres, pero los bytes originales permanecen en el disco hasta que el sistema operativo reutiliza esos bloques para nuevos datos. Hasta que ocurre esa sobrescritura, las herramientas forenses pueden extraer el contenido directamente.

La codificación transforma los datos a otro formato por compatibilidad y es totalmente reversible por cualquiera sin clave (p. ej. Base64, codificación de URL): no aporta confidencialidad. El cifrado solo es reversible con una clave y es lo que aporta confidencialidad. El hashing es una función unidireccional: no puedes recuperar la entrada a partir de la salida, por lo que sirve para comprobaciones de integridad y almacenamiento de contraseñas (con sal y una KDF lenta).

Desde un punto de vista puramente de seguridad, un falso negativo suele ser peor: significa que un ataque real pasó sin detectarse, así que no hay respuesta, ni contención, y la brecha puede permanecer latente sin descubrirse. Pero los falsos positivos no son inofensivos: en grandes volúmenes provocan fatiga de alertas, donde los analistas empiezan a ignorar las alertas y se les escapa la real. La respuesta correcta nombra el compromiso, no solo un ganador.

Filtrado. Un puerto filtrado descarta el paquete en silencio, así que el escáner no obtiene respuesta y debe esperar un tiempo de espera: no aprende nada sobre si el host siquiera existe, y el escaneo se ralentiza drásticamente. Un puerto cerrado devuelve un RST de TCP, que confirma que el host está vivo y respondiendo, entregando gratis al atacante valor de reconocimiento.

No. El candado significa que el transporte está cifrado y que el certificado es válido para ese dominio: no dice nada sobre si el operador es honesto o el contenido es malicioso. Los certificados gratuitos y automatizados hacen que los sitios de phishing y malware casi siempre tengan también un candado perfectamente válido. HTTPS protege el canal, no el destino.

No por sí solo. HTTPS previene el MITM solo cuando la validación del certificado se exige estrictamente y el cliente llega al sitio por HTTPS desde el principio. Si una CA fraudulenta es de confianza (proxy corporativo, raíz instalada por malware), si el usuario pasa por alto las advertencias de certificado, o si el SSL stripping degrada la conexión a HTTP antes de que arranque TLS, un atacante todavía puede situarse en el medio.

HTTPS no es un protocolo propio: es HTTP normal corriendo dentro de un túnel TLS cifrado. SSL es el nombre antiguo: SSL 2.0/3.0 son los predecesores obsoletos e inseguros de TLS, que los reemplazó (de TLS 1.0 a 1.3). Cuando la gente dice «certificado SSL» o «SSL», casi siempre se refiere en realidad a TLS.

Porque son rápidos. MD5 y SHA-256 están diseñados para la velocidad, que es exactamente lo contrario de lo que se necesita para las contraseñas: un atacante que roba los hashes puede calcular miles de millones de intentos por segundo en una GPU. La solución es una función de derivación de clave deliberadamente lenta y dura en memoria —bcrypt, scrypt o Argon2— combinada con una sal por usuario y un factor de trabajo ajustable.

Pregunta trampa: ping no usa ningún puerto. Funciona sobre ICMP, un protocolo de capa 3 que se sitúa directamente encima de IP. Los puertos solo existen en protocolos de capa 4 como TCP y UDP, así que ICMP (y por tanto ping) no tiene ninguno. ICMP usa en su lugar campos de tipo y código, p. ej. Echo Request tipo 8 y Echo Reply tipo 0.

Tres. El cliente envía un SYN, el servidor responde con un SYN-ACK combinado (un paquete que a la vez confirma el SYN del cliente y envía el propio SYN del servidor), y el cliente termina con un ACK. El truco es que SYN-ACK es un único paquete, no dos, así que el total es tres, exactamente lo que nombra «tres vías».

Trata la concienciación como un cambio de comportamiento, no como una casilla anual. Hazla basada en roles (un desarrollador necesita contenido distinto al de finanzas), continua en lugar de una presentación una vez al año, y anclada en riesgos reales como el phishing, la ingeniería social y el manejo de datos. Refuérzala con simulaciones de phishing, recordatorios en el momento oportuno y canales de notificación claros. Mide resultados — tasa de notificación de phishing, tasa de clics, tiempo hasta notificar — no solo los porcentajes de finalización. Construye una cultura en la que la gente notifique sus errores sin miedo, porque el miedo suprime la notificación.

El moderno NIST SP 800-63B prioriza la longitud sobre la complejidad: permitir frases de contraseña largas (al menos 8, admitir 64+), aceptar todos los caracteres incluidos los espacios, y no imponer reglas de composición como «una mayúscula, un símbolo». Filtrar las contraseñas nuevas contra listas de contraseñas filtradas, eliminar la expiración periódica obligatoria (rotar solo ante evidencia de compromiso), y descartar las «preguntas de seguridad» basadas en conocimiento. El objetivo: reglas que resistan ataques reales en vez de empujar a los usuarios hacia patrones predecibles.

PAM controla y monitoriza las cuentas que pueden causar más daño: administradores de dominio, root, cuentas de servicio. Custodia y rota sus credenciales para que ningún secreto se comparta ni quede embebido, intermedia las sesiones para que los administradores nunca vean la contraseña en claro, graba lo que hacen los usuarios privilegiados, y concede idealmente la elevación justo a tiempo en vez de acceso permanente. El objetivo es reducir el radio de impacto de las cuentas que más codician los atacantes.

Se clasifica según para qué está construido el ejemplar, observado a partir de su comportamiento y capacidades. Un dropper transporta y escribe una carga útil en disco; un loader recupera o inyecta la siguiente etapa, a menudo solo en memoria; un RAT da a un operador control remoto interactivo; un wiper destruye datos o registros de arranque sin intención de recuperación; el ransomware cifra archivos y exige un pago. Los ejemplares reales suelen combinar roles — un loader que despliega un RAT — así que se describe la cadena de capacidades en lugar de forzar una sola etiqueta, y se asigna cada comportamiento a técnicas ATT&CK.

El beaconing de mando y control es el implante llamando periódicamente a casa en busca de instrucciones. Se reconoce por llamadas salientes regulares y de bajo volumen a un intervalo aproximadamente fijo — a menudo con jitter para no parecer mecánico — hacia un pequeño conjunto de destinos, con frecuencia sobre HTTP/HTTPS o DNS con cargas útiles codificadas o cifradas y un User-Agent o patrón de URI distintivo. Se extraen los indicadores estáticamente sacando dominios, IPs, URIs y claves de las cadenas y bloques de configuración, y dinámicamente detonando el ejemplar contra una red falsa y capturando las llamadas reales, luego se asigna el comportamiento a ATT&CK y se alimentan los IOC en la detección.

El empaquetado comprime o cifra la carga útil real y le antepone un stub que la desempaqueta en memoria en tiempo de ejecución; la ofuscación transforma el código o los datos para resistir la lectura y las firmas. El empaquetado se detecta por una entropía de sección alta cercana a 8,0, una tabla de imports diminuta o solo de stub, nombres de sección inusuales o escribibles-ejecutables como UPX0, un punto de entrada fuera de .text, un gran tamaño virtual frente a un pequeño tamaño en bruto, y detectores como Detect It Easy o PEiD. Ninguno de estos es concluyente por sí solo, así que los analistas ponderan varias señales juntas y confirman observando el desempaquetado en tiempo de ejecución.

Un archivo PE empieza con la cabecera DOS y su puntero e_lfanew a las cabeceras PE/NT, que contienen el File Header y el Optional Header (punto de entrada, image base, subsistema). Está dividido en secciones — .text para el código, .data, .rdata, .rsrc para los recursos — cada una con una dirección virtual y un tamaño en bruto. Durante el triaje se lee la tabla de imports en busca de API sospechosas, la tabla de secciones por nombres extraños y entropía alta que insinúan empaquetado, el timestamp y el rich header, los recursos incrustados y cualquier firma digital. Las discrepancias entre estos elementos dicen mucho antes incluso de ejecutar el archivo.

Un laboratorio seguro aísla el malware de cualquier cosa que pudiera dañar. Ejecutas las muestras en VMs desechables sobre un hipervisor, tomas snapshots limpios para poder revertir tras cada detonación, y cortas el acceso real a la red usando una red host-only con una internet simulada (INetSim o FakeNet) o un segmento aislado (air-gap). Separas la máquina de análisis de una pasarela controlada, nunca analizas en tu host de uso diario, te endureces frente al VM-escape, manejas las muestras como zips protegidos con contraseña, y mantienes las herramientas e indicadores fuera de la VM de detonación. El objetivo es observar el comportamiento real garantizando que la muestra no pueda alcanzar producción ni internet.

Las herramientas estáticas leen la muestra en reposo: PEStudio, CFF Explorer y pefile para cabeceras e imports, FLOSS y strings para el texto embebido, capa para el mapeo de capacidades, y Ghidra o IDA para el desensamblado. Las herramientas dinámicas la observan ejecutarse dentro de una VM aislada: Procmon y Process Hacker para la actividad del host, Wireshark e INetSim o FakeNet para la red falseada, Regshot para los diffs de antes/después, y x64dbg para el stepping controlado. El flujo de trabajo es triar estáticamente, detonar dinámicamente, y luego volver al desensamblador para rellenar los huecos de comportamiento.

Una regla YARA tiene un bloque meta, una sección strings (patrones de texto, hex o regex, con comodines y saltos) y una condición que combina esas coincidencias con lógica booleana y de conteo. Una regla eficaz se apoya en algo duradero y distintivo — un stub de código único, un nombre de mutex, un marcador de configuración o una combinación de imports inusual — en lugar de valores que un atacante cambia trivialmente como un solo hash o una cadena genérica. Se equilibra la especificidad frente a los falsos positivos, se prueba contra un corpus limpio y se documenta la regla para que otros confíen en ella y la mantengan.

La divulgación coordinada de vulnerabilidades es un proceso en el que un investigador reporta un fallo en privado al fabricante, ambas partes acuerdan la remediación y un plazo, y los detalles se publican solo cuando hay un parche disponible (o vence el plazo acordado). Equilibra dar tiempo a los defensores para parchear con el derecho del público a saber. Un fichero security.txt y una política clara hacen que reportar sea sin fricciones; los programas de bug bounty añaden recompensas estructuradas encima.

El DFIR sigue un proceso disciplinado: identificación (confirmar y delimitar el incidente), adquisición (preservar pruebas siguiendo el orden de volatilidad, con imágenes forenses y hashes), análisis (línea de tiempo, causa raíz, alcance del compromiso) e informe (hallazgos para audiencias técnicas y legales). La cadena de custodia documenta quién manipuló cada artefacto y cuándo, para que la prueba se sostenga si alguna vez llega a un tribunal. Preservar antes de remediar.

ATT&CK es una base de conocimiento de tácticas reales del adversario (el porqué), técnicas (el cómo) y procedimientos. La usas para mapear tus detecciones existentes sobre la matriz, identificar brechas de cobertura y priorizar las técnicas usadas por los actores que realmente atacan tu sector. Ofrece un lenguaje común entre CTI, ingeniería de detección e IR, convirtiendo «¿estamos seguros?» en un mapa de cobertura concreto y medible, impulsado por el comportamiento real del adversario.

El purple teaming es colaborativo en lugar de adversarial: el lado rojo ejecuta TTP específicos y acordados (a menudo asociados a MITRE ATT&CK) mientras el lado azul observa su telemetría en tiempo real para confirmar si cada técnica se registra, alerta y es detectable. Mides la cobertura de detección técnica por técnica, ajustas detecciones y cierras brechas de inmediato, y luego vuelves a probar. El entregable es una detección mejorada y medible — no una lista de quién «ganó».

La gestión de vulnerabilidades es un ciclo continuo: descubrir activos y vulnerabilidades (escaneo, inventario de activos), priorizar por riesgo real (CVSS más explotabilidad, exposición y criticidad de los activos — marcos como EPSS y SSVC ayudan), remediar o mitigar, verificar la corrección e informar sobre tendencias y SLA. El escaneo es la parte fácil; la disciplina está en priorizar y cerrar el ciclo para que el riesgo realmente baje con el tiempo.

SSH usa TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS el 53 (UDP y TCP), RDP TCP 3389 y SMB TCP 445. Conocer los puertos bien conocidos te permite leer la salida de un escaneo, escribir reglas de cortafuegos y triar alertas con rapidez — un servicio en su puerto esperado frente a uno inesperado es una señal inmediata.

Un resolutor stub pide un nombre a un resolutor recursivo. Si no está en caché, el resolutor recursivo recorre la jerarquía: consulta un servidor raíz (que apunta al TLD), el servidor TLD (que apunta a los servidores autoritativos del dominio) y finalmente el servidor autoritativo, que tiene el registro real. La respuesta se cachea por el camino según su TTL. El DNS usa el puerto 53 — UDP para la mayoría de las consultas, TCP para las grandes.

Un proxy directo se sitúa delante de los clientes y hace peticiones salientes en su nombre — para control de salida, filtrado, cacheo y anonimato. Un proxy inverso se sitúa delante de los servidores y recibe peticiones entrantes en su nombre — para balanceo de carga, terminación TLS, cacheo y como fachada de seguridad para un WAF. La dirección a la que mira, lado cliente o lado servidor, es la distinción clave.

Traceroute descubre los routers entre tú y un destino explotando el campo TTL. Envía paquetes con TTL=1, luego 2, luego 3, y así sucesivamente. Cada router decrementa el TTL; cuando el TTL llega a cero, ese router descarta el paquete y devuelve un mensaje ICMP Time Exceeded, revelando su dirección. Al ir subiendo el TTL, traceroute mapea cada salto en orden hasta alcanzar el destino.

NAT (Network Address Translation) reescribe la IP de origen o destino a medida que los paquetes cruzan una frontera, normalmente mapeando direcciones internas privadas a públicas. PAT (Port Address Translation, o NAT overload) lo amplía traduciendo también los puertos, permitiendo que muchos hosts internos compartan una sola IP pública — cada flujo distinguido por su puerto. PAT es lo que usan los routers domésticos y de oficina para poner toda una LAN tras una sola dirección.

El modelo OSI divide la red en siete capas, cada una añadiendo una responsabilidad: Física (bits en el cable), Enlace de datos (tramas y direccionamiento MAC), Red (enrutamiento IP), Transporte (TCP/UDP, puertos, fiabilidad), Sesión (gestión de conexiones), Presentación (codificación, cifrado, compresión) y Aplicación (protocolos como HTTP). Cada capa envuelve a la de encima a medida que los datos bajan por la pila.

Una subred es una subdivisión lógica de una red IP. La máscara de subred marca qué bits de una dirección IP son la porción de red y cuáles la porción de host — por ejemplo, /24 (255.255.255.0) significa que los primeros 24 bits identifican la red y los últimos 8 identifican los hosts. La subdivisión controla cómo se enruta el tráfico y permite segmentar una red en dominios de difusión más pequeños.

TCP abre una conexión en tres pasos. El cliente envía un SYN con un número de secuencia inicial, el servidor responde con SYN-ACK (confirmando el número del cliente y enviando el suyo), y el cliente devuelve un ACK. Tras este intercambio ambos lados han acordado los números de secuencia de inicio y la conexión queda establecida para una entrega de bytes fiable y ordenada.

TCP está orientado a la conexión: negocia, numera bytes, retransmite las pérdidas y controla la congestión, dando una entrega fiable y ordenada a costa de latencia y sobrecarga. UDP no tiene conexión y funciona como disparar-y-olvidar — sin negociación, sin retransmisión, sin orden. Usa TCP cuando importa la corrección (web, correo, transferencia de archivos) y UDP cuando importa más la velocidad que la perfección (DNS, VoIP, juegos, vídeo).

El modelo TCP/IP tiene cuatro capas — Enlace, Internet, Transporte y Aplicación — y describe cómo funciona la Internet real. OSI tiene siete. Se corresponden de cerca: la capa de Aplicación de TCP/IP absorbe las capas de Aplicación, Presentación y Sesión de OSI; su capa de Enlace combina las capas Física y de Enlace de datos de OSI. OSI es la mejor referencia para enseñar y resolver problemas; TCP/IP es la suite de protocolos realmente implementada.

Una VLAN (LAN virtual) particiona lógicamente un switch físico en dominios de difusión de capa 2 separados, de modo que dispositivos en VLAN distintas no pueden alcanzarse directamente aun en el mismo hardware. Se rotula con una etiqueta 802.1Q en los enlaces troncales. El valor de seguridad es la segmentación: aislar el tráfico de usuarios, servidores, invitados e IoT limita el alcance de la difusión y el movimiento lateral, forzando el tráfico entre VLAN a pasar por un router o cortafuegos donde se aplica la política.

Una VPN crea un túnel cifrado a nivel de red/SO, de modo que todo el tráfico de un dispositivo se enruta por él y se protege de extremo a extremo — usada para el acceso remoto seguro. Un proxy opera a nivel de aplicación, retransmitiendo tráfico de aplicaciones o protocolos específicos sin cifrarlo necesariamente. Las grandes diferencias son el alcance (todo el dispositivo vs por aplicación) y que una VPN cifra por diseño mientras que muchos proxys no.

Una DMZ (zona desmilitarizada) es un segmento de red situado entre la Internet no confiable y la red interna de confianza, que aloja servicios expuestos al público como servidores web, de correo y DNS. Las reglas del cortafuegos permiten que Internet alcance la DMZ pero restringen estrictamente el acceso de la DMZ a la red interna. El objetivo es la contención: si un servidor público se ve comprometido, el atacante queda atrapado en la zona de amortiguación en lugar de aterrizar dentro de la LAN.

Un escaneo de vulnerabilidades es un inventario automatizado y en amplitud de debilidades potenciales, a menudo con falsos positivos. Una prueba de penetración la dirige un humano: valida los hallazgos, los encadena y demuestra un impacto de negocio real mediante una explotación efectiva.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Ningún control se supone perfecto, así que se apilan medidas preventivas, de detección y de respuesta en las capas de red, host, aplicación y datos.

Reducir la superficie de ataque (eliminar paquetes y servicios sin uso), forzar SSH solo por clave sin inicio de sesión root, mantener el sistema parcheado, ejecutar un cortafuegos de denegación por defecto que exponga solo los puertos necesarios, aplicar privilegios mínimos mediante sudo y permisos de archivos, habilitar auditd y registro centralizado, y añadir monitorización de integridad más un MAC como SELinux o AppArmor.

El cifrado es reversible: con la clave recuperas el texto plano; protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de tamaño fijo que no se puede revertir; verifica integridad e identidad. Las contraseñas deben hashearse con un algoritmo lento y salado como bcrypt o Argon2, nunca cifrarse.

El privilegio mínimo significa que cada usuario, proceso o servicio obtiene solo el acceso mínimo necesario para su tarea, y nada más. Reduce el radio de impacto de cualquier compromiso o error. Se aplica con acceso basado en roles, elevación just-in-time, revisiones de acceso periódicas y la eliminación de derechos de administrador permanentes.

Nunca codifiques secretos en el código fuente ni los subas a git. Guárdalos en un gestor de secretos o bóveda dedicada, inyéctalos en tiempo de ejecución, acota el acceso con privilegios mínimos, rótalos con regularidad y prefiere credenciales dinámicas de corta duración frente a las estáticas persistentes. Audita cada acceso.

Forzar TLS en todas partes, autenticar cada solicitud (p. ej. tokens OAuth2/OIDC) y autorizar por objeto para que los usuarios solo alcancen sus propios datos. Añade validación de entradas, limitación de tasa y cuotas, validación de esquema y registro exhaustivo. El fallo de API más común es la autorización a nivel de objeto rota, así que comprueba la propiedad en cada acceso a un recurso.

El cifrado simétrico usa una sola clave compartida para cifrar y descifrar: es rápido, pero la clave debe compartirse de forma segura. El cifrado asimétrico usa un par de claves pública/privada, resolviendo la distribución de claves pero lentamente. Los sistemas reales usan criptografía asimétrica para intercambiar una clave de sesión simétrica y luego el rápido cifrado simétrico para los datos en masa.

Una PKI es el sistema de CA, certificados y políticas que vincula las claves públicas con las identidades. Para validar un certificado de servidor, un cliente construye una cadena hasta una raíz de confianza, verifica cada firma, comprueba las fechas de validez y el nombre de host, confirma el uso de la clave, y comprueba la revocación mediante CRL u OCSP.

La fatiga de alertas es la desensibilización que aparece cuando los analistas enfrentan demasiadas alertas de bajo valor o falsos positivos, lo que les hace pasar por alto o atender con prisa las reales. Se combate ajustando las reglas ruidosas, priorizando por riesgo, deduplicando y agrupando alertas relacionadas, automatizando el enriquecimiento repetitivo con un SOAR y midiendo la calidad de las alertas, no solo el volumen.

La fuerza bruta apunta a una sola cuenta con muchos intentos de contraseña, por lo que se ven muchos fallos concentrados en un mismo usuario. El password spray lo invierte: una o pocas contraseñas comunes probadas en muchas cuentas, de forma lenta y sigilosa, de modo que cada cuenta solo registra un par de fallos. La señal de detección es la proporción de cuentas frente a fallos y el timing, no el número bruto de fallos.

Casi todo pasa por el DNS, así que los logs de DNS revelan amenazas que otras fuentes pasan por alto: beaconing de command-and-control (llamadas regulares a un dominio), tunneling y exfiltración DNS (alto volumen de subdominios largos y codificados) y dominios generados algorítmicamente (DGA). Se detectan mediante patrones como la regularidad de las consultas, la entropía, los tipos de registro y el volumen, no por una sola resolución sospechosa.

El EDR se centra en el endpoint: registra y responde a la actividad de procesos, archivos y red en los hosts. El XDR extiende esa correlación a varios dominios —endpoint, red, identidad, correo, nube— como una stack integrada de un mismo proveedor. El SIEM es la capa amplia de agregación de logs que ingiere datos de cualquier fuente, incluidas las no de seguridad, para detección, búsqueda y cumplimiento.

Primero entiende por qué la regla se dispara tanto: encuentra el patrón benigno común detrás del ruido. Luego escribe la exclusión más estrecha posible (host, cuenta o comportamiento específico), documenta la justificación y valida que un verdadero positivo seguiría disparándose. Evita supresiones amplias que crean puntos ciegos en silencio.

El movimiento lateral es un atacante que usa un punto de apoyo para alcanzar otros sistemas. Los signos incluyen logons de red inesperados (tipo 3) y RDP (tipo 10), acceso a recursos compartidos admin como C$ y ADMIN$, herramientas de ejecución remota como PsExec, WMI y WinRM, patrones de pass-the-hash, y una cuenta normalmente local que de repente se autentica en muchos hosts.

ATT&CK es una base de conocimiento de tácticas y técnicas adversarias del mundo real. En un SOC mapeas cada regla de detección a las técnicas que cubre, construyes un mapa de cobertura (a menudo con el ATT&CK Navigator) y luego priorizas cerrar las brechas según qué técnicas son más relevantes para tu modelo de amenazas y sobre cuáles no tienes visibilidad alguna.

Examina el correo sin hacer clic: revisa las cabeceras y la autenticación del remitente (SPF/DKIM/DMARC), inspecciona las URL y adjuntos en un sandbox o con herramientas de reputación, y luego mide el alcance: quién más lo recibió, si alguien hizo clic o introdujo credenciales. Según los hallazgos, remedia purgando el correo, bloqueando los indicadores y restableciendo las credenciales expuestas.

Un SIEM ingiere y correlaciona logs de todo el parque para generar alertas: es tu capa de detección y búsqueda. Un SOAR se sitúa aguas abajo y automatiza la respuesta: ejecuta playbooks, enriquece las alertas mediante integraciones y gestiona los casos para que los analistas dediquen menos tiempo a pasos repetitivos.

Confirma que la alerta es real antes de actuar: lee qué se disparó y por qué, luego enriquécela: quién es el usuario, si la IP/geo/dispositivo de origen son esperados, si hay viaje imposible, si hubo fallos previos. Clasifica como verdadero o falso positivo, escala o contén si es real (desactivar la sesión, forzar un restablecimiento de MFA) y documéntalo todo para que el siguiente analista pueda seguir tu razonamiento.

4624 es un logon exitoso, 4625 es un logon fallido y 4688 es una creación de proceso. En una investigación usas 4625 para detectar ataques de credenciales, 4624 (con su tipo de logon y su origen) para confirmar un acceso exitoso y cómo ocurrió, y 4688 para ver qué se ejecutó realmente, idealmente con la auditoría de línea de comandos habilitada.