Introducción:
Esta fórmula es omnipresente en los discursos sobre la seguridad de los sistemas de información. Se encuentra en las formaciones, las documentaciones y las recomendaciones operativas, en particular cuando se trata de filtrado de red y configuración de cortafuegos.
Expresa una intención legítima: reducir la superficie de exposición limitando estrictamente lo que es accesible. Empleada como marco metodológico, tiene sentido. Pero su alcance real se sobrestima con frecuencia.
Porque, detrás del enunciado, lo implícito es engañoso.
La fórmula sugiere que un sistema rigurosamente configurado podría alcanzar una forma de fiabilidad completa. Que cerrando todo lo que no está explícitamente abierto, se controlaría íntegramente su comportamiento.
En un universo ideal, donde el software estuviera libre de defectos, este razonamiento se sostendría. Pero ese universo no existe.
La ilusión del control total:
Todo lo que no está autorizado está prohibido es una máxima familiar para los arquitectos de red y los administradores a cargo de los cortafuegos. Y su uso está justificado.
Define una postura defensiva esencial: el deny by default.
Pero una postura no es una garantía.
Un cortafuegos no gobierna un sistema. Aplica reglas sobre flujos conocidos: puertos, protocolos, direcciones, estados de sesión. Opera en una capa determinada, con una visión necesariamente parcial.
Ahora bien, un sistema informático moderno supera ampliamente ese perímetro.
La complejidad como generador de incertidumbre:
Cuanto más voluminoso es un software, mayor es la probabilidad de errores. Es un hecho estadístico, confirmado por la experiencia.
Ni las pruebas unitarias, ni las revisiones de código, ni los métodos formales, ni la integración continua han permitido jamás erradicar totalmente los bugs.
Y el código aplicativo no es más que un piso.
El compilador puede producir sus propias anomalías. Las bibliotecas de terceros introducen comportamientos no anticipados. El sistema operativo es una pila de capas históricas, ajustadas, corregidas, a veces eludidas.
Más abajo todavía, el propio hardware no está exento de defectos, como han ilustrado Spectre, Meltdown, Rowhammer y otros.
Cada capa añadida amplía el espacio de los estados posibles. Y con él, la extensión de lo que escapa al conocimiento.
La escala de complejidad de un chip informático es desmesurada.
Un esquema para ilustrarlo:
El eje vertical no es un simple aumento de la “dificultad”.
Abajo: complejidad de escala → Muchas combinaciones, pero un sistema cerrado, bien definido. Las reglas son fijas. El espacio es inmenso pero estable.
Arriba: complejidad sistémica → El problema cambia de naturaleza. Interacciones cruzadas, restricciones contradictorias, efectos emergentes. El sistema reacciona a la solución que se intenta imponer.
El paso del juego formal al emplazamiento de las celdas de un chip marca un cambio de escala pero sobre todo un cambio de naturaleza del problema. Allí donde el ajedrez o el Go evolucionan en espacios inmensos pero cerrados, el emplazamiento de celdas en un chip se enfrenta a un espacio de búsqueda astronómico, que supera las 10^90000 configuraciones posibles, modelado por restricciones físicas, temporales y tecnológicas interdependientes; longitud de los hilos, timing, consumo, ruido, densidad, encaminabilidad, disipación térmica, etc. Esta explosión combinatoria no es solo cuantitativa: cada decisión local modifica el equilibrio global del sistema, haciendo toda exploración exhaustiva irrealista y toda noción de solución óptima absoluta inaplicable. Ya no se busca una respuesta correcta, sino un compromiso aceptable en un espacio continuamente deformado por la realidad material del chip.
Sin contar los efectos cuánticos que pueden surgir a estas escalas (entre 45 y 50 nanómetros).
¡No nos falta, por tanto, incertidumbre en un sistema informático!
Observación: En el futuro, quizás la IA nos ayude a colocar de manera óptima los componentes de un chip… Mejor de lo que nosotros podríamos hacerlo.
El dominio de lo conocido y el dominio de lo desconocido:
Es aquí donde aparece una confusión persistente: la que existe entre seguridad y fiabilidad.
La seguridad se inscribe en el dominio de lo conocido. Trata escenarios identificados, modelizables, verificables.
- Un disco se avería → implementación de un RAID.
- Una alimentación defectuosa → redundancia.
Estos eventos son previsibles, cuantificables, integrables en modelos de riesgo. La seguridad pertenece a la ingeniería y a la probabilidad.
La fiabilidad comienza allí donde esta lógica alcanza sus límites.
La fiabilidad: gestionar lo que no ha sido anticipado:
La fiabilidad concierne a lo imprevisto. Lo que no ha sido probado. Lo que no ha sido aún descubierto.
- Una vulnerabilidad latente desde hace años.
- Una interacción inesperada entre componentes que sin embargo son conformes.
- Un comportamiento emergente surgido de una combinación de estados juzgada imposible.
Ningún actor serio puede afirmar que un sistema complejo ha sido exhaustivamente probado. Ninguna garantía existe en cuanto a la ausencia de vulnerabilidades desconocidas.
En este campo, no hay reglas absolutas. Solo principios: limitación de impacto, contención, resiliencia.
Por qué el «prohibir todo por defecto» es insuficiente:
Afirmar todo lo que no está autorizado está prohibido equivale a suponer que:
- lo que está autorizado está necesariamente bajo control,
- y que todo comportamiento peligroso toma una vía no autorizada.
Estas hipótesis no se sostienen frente a la realidad.
Las vulnerabilidades explotables utilizan casi siempre vías legítimas:
- un puerto abierto,
- un servicio esperado,
- una funcionalidad prevista,
- un flujo conforme.
El problema no es la apertura. El problema es lo que se ignora de lo que circula a través de esa apertura.
Hacia un enfoque más lúcido: la fiabilidad cibernética:
El término ciberseguridad se ha convertido en una palabra comodín. Tranquiliza, simplifica, da la ilusión de un perímetro plenamente controlable.
Sin embargo, enmascara una realidad más incómoda: los sistemas informáticos pertenecen tanto a la fiabilidad como a la seguridad.
Y es mucho más prudente hablar de fiabilidad cibernética.
Hablar de fiabilidad cibernética no es un ejercicio de pesimismo. Es reconocer que:
- todo sistema expuesto es activamente explorado,
- toda superficie de ataque está viva y evoluciona,
- toda protección es, por naturaleza, temporal.
- y que, a pesar de algunos, la cuestión no es saber si entrarán sino cuándo entrarán. Sí, entran. Tarde o temprano. El combate es interminable.
La defensa no consiste únicamente en impedir. También implica observar, comprender, detectar, reaccionar y sobre todo aprender.
En resumen. La seguridad protege. La fiabilidad comprende, vigila y gobierna.
Conclusión:
Todo lo que no está autorizado está prohibido sigue siendo un punto de partida pertinente. Pero nunca será una finalidad. Ni mucho menos.
La madurez consiste menos en creer que todas las puertas están cerradas que en comprender lo que sucede cuando una puerta cede, o cuando un rodeo explota una debilidad ignorada.
Y sobre todo, en aceptar que existe siempre una falla que no se había identificado.
En este contexto, y por razones que desarrollaré en otro artículo dedicado, el recurso al open source, frente a los modelos closed source, constituye una barrera adicional en materia de fiabilidad informática. No como una promesa absoluta, sino como una palanca de transparencia, auditabilidad y comprensión del comportamiento del software frente a lo desconocido. A mis ojos, una de las defensas más racionales de las que disponemos es ciertamente el Open Source y toda la filosofía que de él se deriva.