— Ciberseguridad
Defensiva, autorizada, ética
Uso el conocimiento ofensivo con un solo propósito — fortificar y auditar mis propios sistemas.
Metodología de pruebas de penetración, análisis de vulnerabilidades e ingeniería inversa, aplicados estrictamente dentro de límites autorizados. El trabajo es defensivo: encontrar la ruta antes que un atacante real, y cerrarla.
Todo en esta página es defensivo. Las técnicas ofensivas existen solo para fortificar y auditar — aplicadas contra infraestructura que poseo, dentro de un límite autorizado, ético y legal.
Trabajo la ciberseguridad con la profundidad de un especialista en seguridad: metodología de pruebas de penetración, análisis de vulnerabilidades, ingeniería inversa, seguridad de redes y protocolos, criptografía aplicada, modelado de amenazas, y endurecimiento de Linux para entornos de misión crítica. El conjunto de habilidades se solapa con lo que un atacante sabe — que es exactamente por lo que soy explícito sobre cómo se usa.
Se usa para defender. Realizo pruebas de seguridad autorizadas contra mis propios sistemas e infraestructura de agentes para encontrar primero las debilidades alcanzables y cerrarlas antes de que puedan explotarse. Aquí no hay trabajo adversarial, ni pruebas de sistemas que no poseo, ni herramientas ofensivas desarrolladas o distribuidas.
Dicho claramente: la metodología es la misma que usaría un atacante, el objetivo es siempre el mío, la autorización es siempre explícita, y la salida es siempre una vulnerabilidad cerrada. Ese límite no es una nota al pie de este trabajo — es el trabajo.
cada sistema diseñado en capas, para que ningún fallo único exponga el conjunto
todas las pruebas de penetración se acotan a infraestructura que poseo y estoy autorizado a probar
vulnerabilidades encontradas y cerradas en autoauditoría, por delante de cualquier adversario real
cada técnica aplicada dentro de un límite autorizado, ético y documentado
Cuatro habilidades que se solapan, una intención defensiva.
Estas son las disciplinas que trabajo a la profundidad de un especialista. Cada una se presenta tal como se aplica realmente — dentro de un alcance autorizado, contra mi propia infraestructura, para endurecerla.
Metodología, aplicada a mi propio perímetro
Ejecuto pruebas de penetración del modo en que se realiza un compromiso estructurado: alcance, reconocimiento, enumeración, explotación controlada de un hallazgo, y un informe escrito que termina en una corrección. La diferencia respecto a un compromiso externo es que el alcance es siempre infraestructura que poseo y a la que me he autorizado a probar.
El objetivo nunca es demostrar que puedo entrar. Es encontrar la ruta que tomaría un atacante real, documentarla, y cerrarla antes de que nadie más la recorra.
- Alcance, reconocimiento, enumeración, explotación controlada, informe
- Objetivos limitados a mis propios sistemas e infraestructura de agentes
- Cada hallazgo termina en una vulnerabilidad cerrada, no en un trofeo
Leer un sistema en busca de dónde cede
El análisis de vulnerabilidades es la mitad poco glamorosa del trabajo: enumerar versiones, configuraciones, servicios expuestos y relaciones de confianza, y luego razonar sobre qué combinación se convierte en una debilidad real y alcanzable en lugar de teórica.
Trato un CVE como una hipótesis, no como un veredicto. La pregunta es si es alcanzable en mi configuración real, y cuál es el radio de impacto si lo es — no si un escáner lo marcó.
- Enumeración de servicios, versiones y configuraciones
- Razonamiento de alcanzabilidad y radio de impacto por encima de la salida cruda del escáner
- Hallazgos clasificados por explotabilidad en el despliegue real
Entender un binario para defenderme de él
La ingeniería inversa, en un contexto autorizado, es como entiendo lo que un binario realmente hace — una pieza de malware en un sandbox, un componente cerrado en mi propio stack, un protocolo sin especificación publicada. El análisis estático y dinámico responde preguntas que la documentación no puede.
La salida es defensiva: una firma, una regla de endurecimiento, la comprensión de una técnica de ataque que me permite detectarla o bloquearla. No desarrollo ni distribuyo herramientas ofensivas.
- Análisis estático y dinámico en entornos aislados
- Aplicado a la comprensión de malware y al análisis de protocolos
- La salida es detección y endurecimiento, nunca herramientas ofensivas
Usar las primitivas correctamente, no inventarlas
La criptografía aplicada consiste sobre todo en no cometer los errores bien conocidos: elegir primitivas verificadas, usar cifrado autenticado, gestionar claves y nonces correctamente, y resistir la tentación de inventar mi propio esquema. La parte difícil es la integración, no el algoritmo.
Razono también sobre los modelos de amenaza frente a la criptografía — qué ve un atacante, qué puede reproducir, qué expone realmente una clave comprometida — para que las garantías coincidan con las afirmaciones.
- Primitivas verificadas y cifrado autenticado por defecto
- Gestión disciplinada de claves, nonces y secretos
- Garantías acordes con un modelo de amenaza explícito
Ningún control único carga con todo el sistema.
Arquitectura en capas para entornos de misión crítica
Diseño asumiendo que cada capa puede fallar — para que un fallo no exponga todo lo que hay detrás.
La defensa en profundidad es la arquitectura a la que recurro por defecto para entornos de misión crítica. En lugar de un solo perímetro fuerte, el sistema se construye en capas concéntricas — perímetro, host, proceso, contenedor, datos, identidad, detección — cada una imponiendo de forma independiente el mínimo privilegio.
El supuesto subyacente es que cualquier capa única puede ser sorteada. La pregunta de diseño nunca es si un control se sostendrá para siempre, sino qué alcanza un atacante si no lo hace. El diagrama traza eso: una compromisión en un anillo aún encuentra el siguiente.
- Capas concéntricas, cada una imponiendo el mínimo privilegio
- Diseñado para que un sorteo no exponga el conjunto
- La detección envuelve las capas como comprobación final
- Por defecto para entornos de misión crítica
Las capas — qué impone cada una
- Perímetro
- Segmentación de red, firewall, minimización de la superficie expuesta
- Host
- Endurecimiento de Linux — parámetros del kernel, sysctl, servicios minimizados
- Proceso
- Sandboxing de systemd, descarte de capacidades, aislamiento de namespaces
- Contenedor
- Fronteras de aislamiento, mínimo privilegio, raíces de solo lectura
- Datos
- Criptografía aplicada en reposo y en tránsito, gestión de secretos
- Identidad
- Mínimo privilegio, credenciales acotadas, sin secretos de larga vida en el código
- Detección
- Registro, comprobaciones de integridad, autoauditoría contra las capas anteriores
Decidir contra qué me defiendo, antes de decidir cómo.
Un control elegido sin un modelo de amenaza es una conjetura. Antes de endurecer nada, trabajo sobre quién es el adversario, qué quiere, hasta dónde puede llegar, y qué expone realmente una compromisión exitosa. Ese modelo es lo que convierte una lista genérica en una defensa acorde a una amenaza real.
También es donde el conocimiento ofensivo se gana su lugar defensivamente: pensar como el atacante es cómo encuentro la ruta que vale la pena cerrar primero. El diagrama de abajo es la forma de ese razonamiento — activo y adversario de un lado, superficie y radio de impacto del otro, resolviéndose en un control concreto.
Adversario, activo, superficie, control
Un modelo de amenaza es un mapa desde quién podría atacar hasta qué cierra la ruta.
Cada rama del modelo empieza con un adversario y un activo que querría, recorre la superficie que los conecta, y termina en el control que rompe el enlace. Escribirlo hace visibles los supuestos — y un supuesto que deja de sostenerse silenciosamente es cómo fallan la mayoría de las defensas.
Mantengo el modelo vivo en lugar de único: cada hallazgo de una autoauditoría lo realimenta, y cada control se resuelve en una capa y una prueba.
- El adversario y el activo nombran la amenaza
- La superficie de ataque los conecta
- Cada rama se resuelve en un control por capas
- Los hallazgos realimentan el modelo
Quién es el adversario
Empiezo cada modelo de amenaza nombrando contra quién me defiendo — escaneo oportunista, un atacante dirigido o un error interno — porque los controles difieren para cada uno.
Qué buscan
Identificar los activos que importan — credenciales, infraestructura de agentes, datos — enfoca la defensa en lo que un atacante realmente perseguiría.
Hasta dónde pueden llegar
Mapear la superficie de ataque real, no la supuesta: qué está expuesto, qué es de confianza, y en qué encadenan las relaciones de confianza.
Cuál es el radio de impacto
Para cada debilidad alcanzable, razonar sobre lo que una compromisión exitosa expone realmente — y usar eso para clasificar el trabajo.
Dónde están los supuestos
Escribir los supuestos de los que depende un control, porque un supuesto que deja de sostenerse silenciosamente es cómo fallan la mayoría de las defensas.
Qué lo cierra
Cada entrada del modelo se resuelve en un control concreto en una capa específica, y una prueba que demuestra que el control funciona.
El host, reducido a lo que realmente necesita.
Kernel · sysctl · systemd · contenedores · secretos
El endurecimiento es resta — cada servicio, capacidad y privilegio que el sistema no necesita se elimina.
En Linux el trabajo es concreto: parámetros conservadores del kernel, protecciones de red y memoria de sysctl, sandboxing de unidades systemd, aislamiento de contenedores, y gestión disciplinada de secretos. Cada capa elimina algo que un atacante podría usar de otro modo.
systemd en particular hace mucho trabajo silencioso — NoNewPrivileges, ProtectSystem, capacidades descartadas y sistemas de archivos con namespaces convierten un servicio ordinario en uno confinado. Los contenedores añaden una segunda frontera de aislamiento con mínimo privilegio, imágenes mínimas. El stack de abajo se lee de abajo arriba, del kernel a los secretos.
- Parámetros del kernel y protecciones de sysctl, documentados
- Sandboxing de systemd — capacidades descartadas, sistema de archivos confinado
- Aislamiento de contenedores con mínimo privilegio, imágenes mínimas
- Secretos fuera del código y los logs, acotados y rotados
Stack de endurecimiento — control por capa
- Kernel
- Parámetros conservadores, reducción de la superficie de ataque
- sysctl
- Protecciones de red y memoria ajustadas y documentadas
- Unidades systemd
- Directivas de sandboxing — NoNewPrivileges, ProtectSystem, conjuntos de capacidades
- Aislamiento de contenedores
- Namespaces, mínimo privilegio, imágenes mínimas
- Gestión de secretos
- Secretos fuera del código y los logs, acotados y rotados
- Copias de seguridad
- Cambios reversibles, copias con marca de tiempo antes de cualquier modificación
- Validación
- Cada control verificado por una prueba real, no asumido
El endurecimiento es sobre todo resta. La forma más fiable de defender un servicio es eliminar todo lo que no necesita antes de que un atacante le encuentre un uso.
La metodología, ejecutada de principio a fin en mi propio perímetro.
Realizo pruebas de seguridad autorizadas contra mi propia infraestructura con una cadencia regular — la misma metodología que usa un compromiso externo, acotada a sistemas que poseo.
BlackArch Linux es la plataforma que opero a nivel fluido para esto. Es una distribución construida para pruebas de seguridad, y la uso para autoauditoría autorizada y pruebas de penetración controladas de mis propios sistemas e infraestructura de agentes — nunca contra nada que no posea o no esté autorizado a probar.
La secuencia es deliberada y acotada: autorizar y acotar por escrito, luego reconocimiento, enumeración, una explotación controlada que va justo lo suficiente para probar que un hallazgo es alcanzable, un informe escrito, y una remediación que se vuelve a probar hasta que la ruta ya no existe. El paso de explotación es el que exige disciplina — lo suficiente para probar el riesgo, nunca más.
Prueba de penetración autorizada — del alcance a volver a probar
- 01 Autorizar y acotar Definir exactamente cuáles de mis sistemas están en alcance, y las reglas de la prueba, por escrito.
- 02 Reconocimiento Mapear la superficie expuesta real — servicios, versiones, relaciones de confianza.
- 03 Enumeración Catalogar configuraciones y debilidades alcanzables contra esa superficie.
- 04 Explotación controlada Validar un hallazgo en aislamiento, lo suficiente para probar la alcanzabilidad, no más.
- 05 Informe Documentar la ruta, el impacto y la remediación precisa.
- 06 Remediar y volver a probar Cerrar la vulnerabilidad, luego volver a ejecutar para confirmar que la ruta ya no existe.
BlackArch Linux · alcance autorizado
Un conjunto de herramientas construido para la ofensiva, apuntado solo a mis propios sistemas.
La fluidez con una distribución de pruebas de seguridad como BlackArch importa porque las herramientas son afiladas; la responsabilidad está en hacia dónde se apuntan. Para mí esa es una respuesta fija — mi propia infraestructura, con la autorización establecida antes de que nada se ejecute.
Ejecutar esto con una cadencia significa que las debilidades salen a la luz en mi propio informe antes de salir en el de otra persona. Ese es el valor completo de hacerlo: prefiero encontrar la ruta yo mismo, según mi calendario, a que la encuentren por mí.
- BlackArch operado a nivel fluido para pruebas autorizadas
- Alcance fijado a mis propios sistemas e infraestructura de agentes
- Ejecutado con una cadencia regular, no una sola vez
- Hallazgos cerrados antes de que puedan explotarse
Encontrar la ruta antes que un adversario real.
La razón por la que todo este conocimiento ofensivo existe en mi trabajo es el bucle que alimenta: modelar la amenaza, probar mis propios sistemas con esa metodología, encontrar las debilidades alcanzables, endurecer la capa correcta, y verificar la corrección antes de cerrarla. Luego el resultado vuelve al modelo y el bucle corre de nuevo.
Es un ciclo continuo en lugar de un proyecto con final. Los sistemas cambian, las dependencias cambian, y un control que se sostuvo el trimestre pasado puede no sostenerse hoy — así que la auditoría es recurrente por diseño. El diagrama es ese bucle, dibujado como el ciclo que es.
Modelar → probar → encontrar → endurecer → verificar
Un bucle cerrado, ejecutado con una cadencia, para que la defensa nunca se vuelva obsoleta.
Cada paso por el bucle es pequeño y específico: una amenaza reconsiderada, una prueba autorizada, una debilidad encontrada, una capa endurecida, una corrección verificada. La disciplina está en ejecutarlo regularmente en lugar de esperar a que un incidente lo fuerce.
Como el bucle se cierra — verificar realimenta el modelo — nada queda afirmado. Un control solo se considera hecho una vez que una nueva prueba demuestra que la ruta que debía cerrar realmente ya no existe.
- Continuo, no único
- Cada paso cierra una debilidad verificada
- La verificación realimenta el modelo de amenaza
- Recurrente por diseño conforme los sistemas cambian
El ciclo de autoauditoría
- 01 Modelar la amenaza Decidir contra quién me defiendo y qué querrían de este sistema.
- 02 Probar mis propios sistemas Ejecutar pruebas autorizadas contra mi propia infraestructura con la metodología ofensiva.
- 03 Encontrar antes que ellos Sacar a la luz las debilidades alcanzables por delante de cualquier adversario real.
- 04 Endurecer la capa Aplicar la corrección en la capa correcta del stack de defensa en profundidad.
- 05 Verificar la corrección Volver a probar para demostrar que la debilidad está cerrada, luego realimentar el modelo.
Asegurar lo que se mueve entre sistemas.
La seguridad de red y protocolos y la criptografía aplicada son las partes de la defensa que viajan — protegiendo datos y confianza conforme cruzan entre sistemas en lugar de dentro de uno.
En el lado de la red el trabajo es la segmentación, minimizar la superficie expuesta, y razonar sobre debilidades a nivel de protocolo — qué puede ver, reproducir o inyectar un observador en la ruta. Un protocolo solo es tan confiable como los supuestos que hace sobre la red subyacente, así que modelo esa red como hostil por defecto.
En el lado de la criptografía la disciplina es usar primitivas verificadas correctamente: cifrado autenticado, manejo cuidadoso de claves y nonces, y secretos fuera del código y los logs. No invento esquemas; los fallos en criptografía aplicada casi siempre vienen de la integración y la gestión de claves, no del algoritmo. Ambas áreas se resuelven en la misma pregunta del modelo de amenaza — qué ve realmente un atacante, y qué expone una sola compromisión.
Red hostil por defecto
No confiar en nada sobre la ruta; proteger la carga útil y las claves.
Trato la red entre sistemas como hostil — observable, reproducible, modificable — y diseño para que ese supuesto no rompa nada. La segmentación limita lo que un punto de apoyo alcanza; el cifrado autenticado protege la carga útil; la gestión disciplinada de claves limita lo que una sola compromisión expone.
La seguridad de protocolos es donde estos se encuentran: la criptografía solo entrega sus garantías si el protocolo a su alrededor no las deshace. Eso es un ejercicio de modelado de amenazas tanto como uno criptográfico.
- Segmentación de red y superficie expuesta minimizada
- Razonamiento a nivel de protocolo sobre observar, reproducir, inyectar
- Cifrado autenticado con primitivas verificadas
- Gestión de claves, nonces y secretos como trabajo de primera clase
La defensa como práctica recurrente, no una configuración única.
Modelar, probar, encontrar, endurecer, verificar — el mismo ciclo, ejecutado regularmente contra mi propia infraestructura para que la defensa siga el ritmo de los sistemas que protege.
Leído en secuencia, el trabajo es una práctica recurrente en lugar de un estado terminado. Comienza con un modelo de amenaza, ejecuta autoauditoría autorizada contra mis propios sistemas, saca a la luz las debilidades alcanzables, cierra cada una en la capa correcta del stack de defensa en profundidad, y vuelve a probar antes de dar nada por hecho.
Lo que atraviesa todo ello es el límite con el que empecé: metodología ofensiva, autorizada y ética, apuntada solo a infraestructura que poseo, usada con el único propósito de fortificarla antes de que un adversario real tenga la oportunidad.
- Modelar Primero el modelado de amenazas Antes de elegir un control, decido quién es el adversario, qué quiere y hasta dónde puede llegar — para que la defensa coincida con una amenaza real en lugar de una lista genérica.
- Probar Autoauditoría autorizada Usando metodología de pruebas de penetración y BlackArch Linux, ejecuto pruebas de seguridad autorizadas contra mi propia infraestructura y sistemas de agentes con una cadencia regular.
- Encontrar Vulnerabilidades sacadas a la luz Las debilidades alcanzables se encuentran y documentan del mismo modo en que un compromiso externo las documentaría — ruta, impacto, remediación.
- Endurecer Cerradas en la capa correcta Cada hallazgo se corrige en la capa correcta del stack de defensa en profundidad: kernel, sysctl, systemd, contenedor, datos o identidad.
- Verificar Vuelto a probar, luego realimentado La corrección se vuelve a probar para demostrar que la ruta ya no existe, y el resultado realimenta el modelo de amenaza para el siguiente ciclo.
Los principios bajo la defensa.
Los sistemas cambian y los controles específicos cambian con ellos; los principios no. Estas son las reglas que aplico ya sea que el trabajo sea una pasada de endurecimiento, una prueba de penetración autorizada, un modelo de amenaza o una integración criptográfica — la parte que mantiene la práctica defensiva, autorizada y repetible.
Autorizado, o no ocurre
La técnica ofensiva solo se aplica dentro de un límite autorizado, contra sistemas que poseo. Aquí no hay trabajo adversarial — la metodología existe para fortificar y auditar.
La defensa es el propósito
Las pruebas de penetración, el análisis de vulnerabilidades y la ingeniería inversa son medios para un único fin: cerrar la ruta antes de que un atacante real la encuentre.
Capas, no un muro
Asumo que cualquier control único puede fallar, así que los sistemas se construyen de modo que un fallo no exponga el conjunto. La defensa en profundidad es lo predeterminado, no una mejora.
Reversible y documentado
Cada cambio se respalda antes de hacerse y se documenta después, para que un paso de endurecimiento pueda auditarse y revertirse tan limpiamente como se aplicó.
Verificar, nunca asumir
Un control no está hecho hasta que una prueba real demuestra que se sostiene. El resultado de un escáner, un flag de configuración y una defensa funcional son tres cosas distintas.
Mínimo privilegio, en todas partes
Procesos, contenedores y credenciales obtienen lo mínimo que necesitan. Acotado, de corta vida y revocable supera a conveniente cada vez.
La metodología es la de un atacante. El objetivo es siempre el mío, la autorización siempre explícita, y la salida siempre una vulnerabilidad cerrada. Ese límite es el trabajo.
Open to the right work
Si necesitas un sistema que asuma que será atacado y esté construido para resistir de todos modos, ese es el trabajo que hago.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.