0.1 · Principios: los invariantes que todo presupone

11 min de lectura · fundamentos / principios / cia / modelo-amenazas / arquitectura / defensa-en-profundidad · ⎙ PDF

Panorama: la Parte que se lee primero y se escribió última#

Las otras nueve Partes de este manual recorren la seguridad como un edificio: la explotación y el red team, el Active Directory, el reconocimiento, la defensa azul y el forense, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano y, transversal a todo, la inteligencia artificial. Cada una toma un piso y lo trabaja a fondo. Esta Parte 0 es distinta: no es un piso más, es el cimiento. Por eso ocupa el número cero y se lee primero, antes que cualquier otra cosa. Y sin embargo se escribió al final, después de todas las demás, porque solo desde el final se puede ver el edificio completo y señalar con precisión sobre qué se paró cada piso. Ese doble lugar —primero en el orden de lectura, último en el de escritura— le da a la Parte 0 una capacidad que ninguna otra tiene: puede nombrar los invariantes que las otras nueve Partes dieron por supuestos sin detenerse a enunciarlos, porque están ocupadas atacando y defendiendo.

Un ejemplo aclara qué significa «invariante». Cuando la Parte 3 explicó que toda inyección es romper la frontera entre los datos y el código de un intérprete, presupuso que existe una diferencia entre datos y código y que mantenerla separada es un valor. Cuando la Parte 4 mostró el modelo de tiers del Active Directory, presupuso que el privilegio se otorga en la mínima cantidad necesaria. Cuando la Parte 5 construyó la detección por capas, presupuso que ninguna barrera individual es infalible y que hay que apilarlas. Ninguna de esas Partes se detuvo a defender el principio: lo usó. Este capítulo, y la Parte que abre, hacen lo contrario: se detienen en el principio, lo enuncian, y muestran que las técnicas del manual son sus aplicaciones. No enseña a atacar ni a defender —para eso están las otras nueve Partes—; enseña por qué lo que enseñaron funciona.

La tesis que sostiene la Parte entera se puede decir en una frase, y conviene fijarla desde el arranque: la seguridad no es un producto que se compra ni una suma de herramientas que se instalan; es una propiedad que emerge de aplicar con disciplina un puñado de principios a cada capa del sistema. El firewall, el EDR, el gestor de identidades son instrumentos; la seguridad es lo que aparece —o no— según cómo se los componga bajo esos principios. De ahí la famosa formulación de Bruce Schneier: «la seguridad es un proceso, no un producto». Un producto se termina; un proceso se sostiene. El resto de este capítulo desarma ese «puñado de principios» en sus piezas.

El objetivo: la tríada CIA y su extensión#

Antes de los principios de diseño está el objetivo que persiguen. Toda la disciplina, por debajo de su jerga, protege tres propiedades de la información, conocidas por sus iniciales en inglés como la tríada CIA.

La confidencialidad (confidentiality) es la garantía de que la información solo es accesible para quien está autorizado a verla. Su enemigo es la divulgación no autorizada, y casi todo lo que el manual llamó credential access, exfiltración o cifrado juega en este eje. La integridad (integrity) es la garantía de que la información no fue alterada de forma no autorizada, y de que quien dice haberla producido efectivamente la produjo. Su enemigo es la manipulación —desde la modificación de un registro hasta la forja de un ticket de Kerberos—, y es el eje que sostiene la confianza en cualquier dato. La disponibilidad (availability) es la garantía de que la información y los servicios están accesibles cuando se los necesita. Su enemigo es la interrupción, desde un ataque de denegación de servicio hasta un ransomware que cifra lo que debería estar disponible.

Las tres están en tensión permanente, y esa tensión es la primera lección de arquitectura. Cifrar todo con claves que nadie puede recuperar maximiza la confidencialidad y destruye la disponibilidad. Replicar los datos en cien lugares maximiza la disponibilidad y multiplica por cien la superficie de confidencialidad. La seguridad no es maximizar las tres —es imposible— sino balancearlas según el valor de lo que se protege. Un modelo más fino, propuesto por Donn Parker, extiende la tríada a seis elementos, agregando la posesión o control (tener el dato aunque no se lo pueda leer —el disco cifrado robado sigue siendo una brecha de posesión—), la autenticidad (que el origen declarado sea el real, distinta de la integridad del contenido) y la utilidad (que el dato siga sirviendo para su fin —una copia de respaldo cifrada con una clave perdida conserva la confidencialidad y pierde la utilidad—). La hexada Parkeriana es útil porque nombra brechas que la tríada clásica deja fuera; para la mayoría de los casos, sin embargo, pensar en CIA alcanza.

Los ocho principios de diseño: el canon de Saltzer y Schroeder#

Si la tríada CIA es el objetivo, la pregunta siguiente es cómo se diseña un sistema para alcanzarlo. La mejor respuesta la dieron Jerome Saltzer y Michael Schroeder en 1975, en un artículo cuyos ocho principios de diseño no envejecieron en medio siglo. Son el canon de la ingeniería de seguridad, y cada uno reaparece, sin nombre, a lo largo de todo el manual.

La economía de mecanismo (economy of mechanism) sostiene que el diseño de seguridad debe ser lo más simple y pequeño posible, porque lo que no se puede entender no se puede auditar, y lo complejo esconde defectos. Es la razón por la que un control simple bien puesto vence a uno sofisticado mal entendido. Los valores por defecto seguros (fail-safe defaults) exigen que, ante la duda o el error, el sistema deniegue en vez de permitir: la lista de acceso se construye enumerando lo permitido y rechazando todo lo demás, no al revés. La falla que abre un camino autenticado cuando una excepción se traga silenciosamente es exactamente la violación de este principio. La mediación completa (complete mediation) obliga a verificar la autorización en cada acceso, no solo la primera vez: cachear la decisión de «este usuario puede» y no revalidarla es la grieta que explotan tanto los controles de acceso rotos de la web como, elevado a arquitectura, el modelo de zero trust.

El diseño abierto (open design) afirma que la seguridad no debe depender de que el atacante ignore cómo funciona el mecanismo, sino solo de que ignore la clave. Es el principio de Kerckhoffs aplicado a todo el sistema, y la razón por la que la seguridad por oscuridad —esconder una URL, ofuscar un algoritmo— es un espejismo. La separación de privilegio (separation of privilege) pide que las operaciones sensibles requieran más de una condición: dos llaves para el misil, autenticación multifactor para la cuenta crítica. El mínimo privilegio (least privilege) —quizá el más citado— exige que cada componente y cada usuario operen con la menor autoridad necesaria para su función y nada más; es el principio que el modelo de tiers del Active Directory hace cumplir y que el credential dumping castiga cuando se lo ignora. El mecanismo común mínimo (least common mechanism) desaconseja compartir recursos entre componentes con distinto nivel de confianza, porque lo compartido es un canal y una superficie. Y la aceptabilidad psicológica (psychological acceptability) —el más olvidado y el más importante— recuerda que un control que los usuarios no pueden usar cómodamente será eludido, y un control eludido no protege: la seguridad tiene que ser usable o no es. Es el puente directo con el factor humano, y la razón por la que el mejor control técnico fracasa si le pide a la persona algo que no puede sostener.

Los hilos conductores del manual#

Sobre ese canon clásico, las nueve Partes tejieron un conjunto de hilos conductores más específicos, que conviene reunir aquí porque son los principios que el manual efectivamente usó una y otra vez.

Separar los datos del código. Es la tesis única detrás de familias enteras de vulnerabilidades. Un intérprete —una base de datos, un shell, un navegador, un modelo de lenguaje— recibe en un mismo canal las instrucciones que debe ejecutar y los datos que debe procesar; si no mantiene una frontera infranqueable entre ambos, el atacante disfraza sus instrucciones de datos y toma el control. La inyección es esa falla en los intérpretes clásicos, y la inyección de instrucciones (prompt injection) que la Parte 9 estudió es la misma falla un nivel más arriba, en el intérprete más nuevo. El principio invariante es: los datos nunca deben poder convertirse en instrucciones.

La defensa en profundidad. Ningún control es infalible, así que la seguridad no se apuesta a una sola barrera sino a una sucesión de barreras independientes, de modo que la falla de una no comprometa el todo. El programa de detección de la Parte 5 es defensa en profundidad hecha práctica: telemetría en el host y en la red, detección por firma y por comportamiento, cacería sobre lo que se escapó. El corolario operativo es assume breach —diseñar suponiendo que el perímetro ya cayó—, que es defensa en profundidad tomada en serio.

La frontera de confianza. Todo sistema tiene puntos donde algo confiable recibe algo no confiable: la entrada del usuario, la respuesta de un servicio externo, el documento que un agente lee. Esas fronteras son donde vive la seguridad, porque son donde hay que validar. El error recurrente —el que reaparece con cada tecnología nueva— es dejar de validar en la frontera que se dio por interna cuando ya no lo es; la vulnerabilidad, como observó la Parte 3 y reprisó la Parte 9, vive en la frontera que se dejó de mirar. De ahí se derivan dos hilos más: no confiar en la entrada (toda entrada es hostil hasta que se la valida) y verificar la procedencia (un dato, un binario, un modelo valen lo que vale la cadena que los produjo —la firma, el hash, el certificado son procedencia verificable—).

El humano ante lo irreversible. El último hilo es de gobierno, no de mecanismo. Cuanto más se automatiza —y la Parte 9 mostró hasta dónde llega la automatización con IA—, más importa reservar la decisión irreversible para un humano que la supervise. La supervisión humana (human-in-the-loop) no es un residuo de sistemas inmaduros: es el reconocimiento de que la máquina propaga el error a la misma velocidad con la que ejecuta el acierto, y que hay acciones —borrar, aislar, pagar, publicar— cuyo costo de equivocarse justifica el freno.

El mapa de la Parte#

Los principios de este capítulo no flotan en el aire: gobiernan capas concretas del sistema, y cada capa es un capítulo de la Parte. La Parte 0 asciende desde el axioma hasta el sistema completo y termina en la síntesis del manual entero.

flowchart TB
  P["0.1 los principios\nCIA · Saltzer-Schroeder · los hilos del manual"]
  P --> R["0.2 redes\nel modelo de capas como superficie"]
  P --> S["0.3 sistemas operativos\nprivilegio · procesos · aislamiento"]
  P --> C["0.4 criptografía\nconfianza matemática y sus límites"]
  R --> A["0.5 arquitectura\nmodelar la amenaza · confiar con criterio"]
  S --> A
  C --> A
  A --> F["0.6 síntesis\nel manual en una idea"]

El capítulo 0.2 toma el sustrato de conectividad: la pila de protocolos y por qué cada capa confía en la de abajo, la segmentación como control y la red plana como pecado original. El 0.3 toma el sustrato de ejecución: la frontera entre el núcleo y el usuario, el privilegio como la abstracción central que el sistema operativo administra y que la escalada explota. El 0.4 toma el sustrato de confianza verificable: qué garantiza y qué no la criptografía, y dónde falla —casi nunca en el algoritmo, casi siempre en la implementación y la gestión de claves—. El 0.5 muestra cómo se componen esos tres sustratos en un sistema defendible: el modelado de amenazas, la superficie de ataque y la frontera de confianza convertida en artefacto de diseño. Y el 0.6 cierra la Parte y el manual entero destilando las diez Partes en una sola idea.

Esa es la arquitectura de la Parte que cierra el libro: primero los axiomas, después el sustrato que gobiernan, después la composición defendible, y al final la vuelta a la idea única. Se lee primero porque es el cimiento; se escribió último porque solo el edificio terminado revela sobre qué se paró.

Referencias#

J. H. Saltzer y M. D. Schroeder, The Protection of Information in Computer Systems (1975): el artículo fundacional con los ocho principios de diseño de seguridad. Sigue siendo el canon medio siglo después.
Donn B. Parker, Fighting Computer Crime (1998): la extensión de la tríada CIA a la hexada (posesión, autenticidad, utilidad).
Bruce Schneier, Secrets and Lies (2000): la tesis de la seguridad como proceso y no como producto.
La reunión de los hilos conductores del manual (separar datos de código, defensa en profundidad, frontera de confianza, no confiar en la entrada, verificar procedencia, humano ante lo irreversible) es enriquecimiento propio: cada uno se aplicó a lo largo del libro —la separación de datos y código en la inyección y la seguridad de la IA, el mínimo privilegio en el Active Directory, la defensa en profundidad en la detección, la aceptabilidad psicológica en el factor humano— y aquí se los nombra por primera vez como principios. Se desarrollan por capa en 0.2, 0.3, 0.4 y 0.5, y se destilan en la síntesis final.

Mencionado en

0.2 · Redes: el modelo de capas como superficieEl sustrato de conectividad sobre el que se apoyan casi todas las técnicas del manual. Explica la pila TCP/IP como un modelo de capas donde cada nivel confía en el de abajo sin poder verificarlo —y por qué esa confianza no ganada es, a la vez, lo que hace funcionar Internet y lo que la vuelve atacable—. Recorre la encapsulación, el direccionamiento y el enrutamiento, el sistema de nombres de dominio (DNS) como una infraestructura de confianza tan indispensable como frágil, y los mecanismos que dibujan fronteras dentro de la red: NAT, cortafuegos y, sobre todo, la segmentación, cuyo opuesto —la red plana— es el pecado original que convierte un único punto de acceso en el compromiso de todo. Distingue el tráfico norte-sur (que cruza el perímetro) del este-oeste (que se mueve dentro), explica a alto nivel cómo el protocolo TLS levanta un canal cifrado y autenticado sobre un transporte que no lo es, y cierra con el filtrado de salida (egress filtering) como el control que le quita al atacante la vía de retorno. No rehace los ataques de red de las Partes 2, 3 y 4: nombra el modelo que esos ataques presuponen.
0.3 · Sistemas operativos: privilegio, procesos y aislamientoEl sustrato de ejecución sobre el que corre todo lo demás. El sistema operativo tiene una sola misión de seguridad: administrar el privilegio y hacer cumplir el aislamiento, de modo que un programa no pueda hacer lo que no le corresponde ni tocar lo que no es suyo. Este capítulo explica la frontera primaria —la que separa el núcleo (kernel), que manda sobre el hardware, del espacio de usuario, donde corren los programas— y por qué esa frontera es la línea que la escalada de privilegios busca cruzar. Recorre el modelo de privilegio de Windows (los identificadores de seguridad, los tokens de acceso, los niveles de integridad, el control de cuentas de usuario y el papel central del proceso que custodia las credenciales, LSASS) y el de Linux (usuarios y grupos, los bits de permiso, el conjunto de capabilities que fragmenta el poder de root, el bit setuid, los espacios de nombres que aíslan contenedores y la interfaz de llamadas al sistema como la puerta entre el usuario y el núcleo). El hilo que une todo es el privilegio como la abstracción central: comprenderlo es comprender por qué la escalada, el volcado de credenciales y la evasión son variaciones de un mismo movimiento —conseguir más autoridad de la otorgada, o esconderse de quien la vigila—. No rehace el volcado de credenciales de la Parte 4 ni la escalada de la Parte 3: nombra la arquitectura de privilegio que ambos presuponen.
0.4 · Criptografía: confianza matemática y sus límitesEl sustrato de confianza verificable. La criptografía es la única herramienta de la seguridad que apoya sus garantías en la matemática y no en la vigilancia: bien usada, permite confiar en la confidencialidad, la integridad y el origen de un dato sin tener que custodiar el canal por el que viaja. Este capítulo ordena sus tres primitivas —el cifrado simétrico (una clave compartida, rápido, para el grueso de los datos), el cifrado asimétrico (un par de claves pública y privada, que resuelve el problema de acordar secretos con desconocidos) y las funciones de hash (huellas de tamaño fijo que garantizan integridad, no confidencialidad)— y combate el error de categoría más común y más caro: confundir cifrar, codificar y hashear. Sobre esas primitivas levanta las construcciones que el resto del manual dio por sentadas: las funciones de derivación de claves con sal que deciden si un hash de contraseña resiste o cae, la firma digital y la infraestructura de clave pública (PKI) que sostiene tanto TLS como la autenticación por certificados del Active Directory, y Kerberos como criptografía aplicada donde la diferencia entre un algoritmo viejo y uno moderno decide si un ticket se puede crackear. Cierra con la lección de arquitectura: la criptografía casi nunca falla en el algoritmo; falla en la implementación y en la gestión de las claves. No rehace Kerberos ni AD CS: da el fundamento matemático que ambos presuponen.
0.5 · Arquitectura de seguridad: modelar la amenaza y confiar con criterioEl capítulo que compone los tres sustratos anteriores —la red, el sistema operativo y la criptografía— en un sistema que se puede defender. La seguridad no se agrega al final como una capa de pintura: se diseña, y diseñarla empieza por una pregunta que casi nadie hace a tiempo, ¿contra qué, exactamente, estamos defendiéndonos? El modelado de amenazas (con STRIDE como marco de referencia) es la disciplina de hacerse esa pregunta de forma estructurada, sobre un dibujo del sistema, antes de que el atacante la haga por uno. De ahí salen los dos conceptos que organizan todo el capítulo: la superficie de ataque, que hay que ver para poder reducir, y la frontera de confianza, que deja de ser un accidente para convertirse en un artefacto de diseño explícito —la línea, dibujada a propósito, donde algo confiable recibe algo que no lo es y por lo tanto hay que validar—. El capítulo muestra cómo el modelo de perímetro tradicional —duro por fuera, blando por dentro— fracasó, y cómo el zero trust lo reemplaza aplicando a toda la red el principio de mediación completa: nunca confiar por ubicación, verificar en cada acceso, con la identidad convertida en el nuevo perímetro. Cierra con el diseño seguro por defecto como la forma de no repetir el error. No rehace la gobernanza de la Parte 7 ni el detalle operativo del zero trust: da el marco de diseño que la gobernanza dirige.
0.6 · Síntesis: el manual en una ideaEl capítulo que cierra la Parte 0 y, con ella, el manual entero. Después de recorrer diez Partes —la explotación, el Active Directory, el reconocimiento, la defensa azul, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial y estos fundamentos— la pregunta que queda es la más difícil y la más importante: ¿cuál es el hilo único que atraviesa todo? Este capítulo lo responde destilando las diez Partes en una sola idea. Muestra que las técnicas cambian —cambia el intérprete que se inyecta, cambia el protocolo que se abusa, cambia la superficie que aparece con cada tecnología nueva— pero los principios no: separar los datos del código, otorgar el mínimo privilegio, apilar la defensa en profundidad, reconocer que el humano es una superficie y que la máquina cambia la escala pero no los fundamentos, todo bajo una gobernanza que lo ejerce y una inteligencia que lo orienta. Recapitula la travesía como un solo movimiento y llega a la tesis que corona el libro: la seguridad no es un producto que se compra ni una técnica que se domina, sino una propiedad que se cultiva —un puñado de invariantes aplicados con disciplina a cada capa, sostenidos en el tiempo—. Y cierra volviendo al principio: esta Parte se lee primera porque es el cimiento, pero se escribió última porque solo desde el edificio terminado se ve sobre qué se paró cada piso.