El análisis de riesgos de IT no nació para combatir malware o ataques por Internet, sino que su origen está en un problema mucho más antiguos, que es cómo permitir que varias personas compartieran un ordenador sin que pudieran acceder a los secretos de los demás.
La historia comienza en Estados Unidos, durante la Guerra Fría, cuando un ordenador no era un dispositivo personal, sino una máquina de varios millones de dólares instalada en una sala especial.
Santa Mónica, 1967
Hasta comienzos de los años sesenta, la seguridad informática era principalmente física, de forma que los equipos se protegían cerrando las instalaciones, vigilando al personal y controlando las tarjetas perforadas, las cintas magnéticas y los documentos impresos.
El problema cambió con los sistemas de tiempo compartido, que permitían que numerosos usuarios trabajaran simultáneamente mediante terminales, incluso desde edificios diferentes.
En junio de 1967, el Departamento de Defensa de Estados Unidos pidió a la Advanced Research Projects Agency, ARPA, que estudiara cómo proteger información clasificada en estos nuevos sistemas multiusuario. La tarea llegó a Robert W. Taylor, director de la Information Processing Techniques Office de ARPA, una figura que también tendría un papel relevante en los antecedentes de ARPANET.
En octubre de ese año se formó una comisión bajo la autoridad del Defense Science Board con Willis H. Ware, ingeniero de RAND Corporation, con sede en Santa Mónica, California. Participaron especialistas de la NSA, la CIA, el MIT, IBM, Lockheed, MITRE y otras instituciones, al frente.
El resultado fue Security Controls for Computer Systems, conocido como Ware Report y publicado en febrero de 1970 para el Departamento de Defensa, si bien fue clasificado como confidencial y no se publico hasta el 10 de octubre de 1975.
Lo curioso es que el documento no se limitaba al software, pues hablaba de empleados desleales, errores, terminales remotos, líneas de comunicación, registros de actividad, procedimientos administrativos y responsables de seguridad. También reconocía que era prácticamente imposible calcular con precisión la probabilidad de que un sistema fuera comprometido, es decir, la disciplina nació sabiendo que sus cifras serían inciertas.
Bedford, 1972
El siguiente gran paso ocurrió en Hanscom Field, Bedford, Massachusetts, donde la Electronic Systems Division de la Fuerza Aérea estadounidense encargó un estudio sobre el futuro de la seguridad informática.
El responsable fue James P. Anderson, consultor cuya empresa estaba situada en Fort Washington, Pensilvania. El proyecto se desarrolló entre el 2 de febrero y el 1 de septiembre de 1972 y se publicó en octubre como Computer Security Technology Planning Study.
Anderson ayudó a consolidar una diferencia esencial entre el riesgo tecnológico convencional y el riesgo de seguridad, pues un disco duro puede fallar accidentalmente, pero un atacante observa las defensas, busca errores y cambia de estrategia. El riesgo informático no dependía solamente de la fiabilidad de las máquinas, sino también de las capacidades y motivaciones de un adversario.
El informe introdujo además el concepto de reference monitor, un mecanismo que debía controlar todos los accesos entre usuarios y recursos, una idea que influiría posteriormente en los modelos de sistemas seguros desarrollados para el Departamento de Defensa.
Cambridge, 1975
Mientras los militares estudiaban amenazas, en Project MAC del Massachusetts Institute of Technology, en Cambridge, se trabajaba en Multics, uno de los sistemas operativos multiusuario más ambiciosos de la época.
Dos investigadores del MIT, Jerome H. Saltzer y Michael D. Schroeder, reunieron muchas de las lecciones aprendidas en el artículo The Protection of Information in Computer Systems, cuya versión definitiva apareció en septiembre de 1975 en Proceedings of the IEEE.
De allí proceden principios todavía utilizados como es el mínimo privilegio, la separación de privilegios y la simplicidad del diseño, demostrando que la seguridad debía diseñarse desde la arquitectura del sistema y no añadirse al final como un conjunto de controles externos.
Washington, 1979
El salto desde la ingeniería de seguridad hasta el análisis formal de riesgo ocurrió en la Administración pública estadounidense.
En 1978, la Office of Management and Budget publicó la Circular A-71, que exigía a las agencias federales analizar los riesgos de sus sistemas automatizados. Sin embargo, no existía una metodología común, por lo que fue el National Bureau of Standards —actual NIST— quien adaptó entonces el trabajo de Robert H. Courtney Jr., especialista de IBM.
El 1 de agosto de 1979 se publicó en Washington FIPS 65, Guideline for Automatic Data Processing Risk Analysis, uno de los primeros documentos gubernamentales dedicados expresamente a convertir el riesgo informático en una decisión económica.
El método estimaba dos elementos que siguen siendo el esqueleto actual, el daño provocado por un incidente y la frecuencia con la que podía ocurrir. De ambos se obtenía la exposición anual a pérdidas de forma que, si una interrupción costaba 100.000 dólares y se esperaba una vez cada diez años, el riesgo anual estimado era de 10.000.
La cifra permitía comparar la pérdida esperada con el coste de una salvaguarda, si bien FIPS 65 admitía que los datos eran aproximados y recomendaba trabajar con órdenes de magnitud. Aun así, muchas organizaciones interpretaron sus resultados con una precisión que las estimaciones originales no justificaban.
Así nació una paradoja que aún acompaña a la ciberseguridad que es que necesitamos números para decidir, pero los números se construyen con información incompleta.
Reino Unido, 1985
Europa no se limitó a copiar el modelo estadounidense, pues en el Reino Unido la preocupación procedía de la expansión de los sistemas informáticos dentro de la Administración pública.
En 1985, la Central Computer and Telecommunications Agency, conocida como CCTA, publicó la primera versión de CRAMM, que dividía el análisis en tres tareas, como valorar los activos, estudiar amenazas y vulnerabilidades, y seleccionar contramedidas. Su gran novedad era la sistematización, en la que el analista ya no partía de una página en blanco, pues disponía de cuestionarios, catálogos de amenazas, escalas de impacto y una herramienta informática.
El método también introdujo otra curiosa paradoja, que es que el software hacía que el análisis pareciera objetivo y científico, aunque muchas respuestas continuaban dependiendo del juicio de entrevistados y consultores.
Japón, 1985
En Asia no existió un equivalente directo al Ware Report y además el desarrollo fue menos militar, pues estuvo más relacionado con la gestión empresarial, la calidad industrial y la auditoría.
En enero de 1985, el Ministerio japonés de Comercio Internacional e Industria estableció los primeros System Audit Standards, cuyo propósito era evaluar de forma independiente si los sistemas informáticos eran seguros, fiables, eficientes y útiles para la dirección.
Esta aproximación era distinta de la estadounidense, pues en lugar de preguntar únicamente cuánto podía perderse, el modelo japonés preguntaba si el sistema estaba adecuadamente controlado y contribuía a los objetivos de la empresa. Es decir, el riesgo aparecía ligado a la auditoría, la gobernanza y la mejora continua.
Conclusion
Desde sus orígenes, el análisis de riesgos de IT ha evolucionado desde la protección de grandes ordenadores e información clasificada hasta la gestión de riesgos que afectan a organizaciones, infraestructuras y cadenas de suministro completas.
Han cambiado las tecnologías, las amenazas y las metodologías, se han incorporando estándares, escenarios de ataque, inteligencia de amenazas y análisis cuantitativos, pero sin embargo, las preguntas esenciales siguen siendo las mismas que es qué puede ocurrir, qué impacto tendría y qué nivel de riesgo estamos dispuestos a aceptar.
Así, el análisis de riesgos ha dejado de ser una técnica para proteger máquinas y se ha convertido en una herramienta fundamental para la toma de decisiones y la resiliencia digital.