Ingeniería del caos de la seguridad

Capítulo 1. Resiliencia en software y sistemas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

El mundo se sostiene sobre absurdos, y sin ellos tal vez no ocurriría nada en absoluto.

Fiódor Dostoievski, Los hermanos Karamázov

En nuestra realidad actual, la ciberseguridad es más un arte arcano que una ciencia: una secuencia inescrutable, a menudo insoportable, de rituales performativos para marcar casillas¹ que afirman que has cumplido el requisito reglamentario o normativo apropiado (y a menudo arbitrario). En términos de seguridad de los sistemas, el estado ideal es el de la resiliencia: garantizar que los sistemas puedan funcionar con éxito ahora y en el futuro a pesar de los peligros que acechan en nuestro mundo digital. Para mantener la resiliencia, debemos comprender cómo interactúan todas las máquinas y seres humanos del sistema en pos de un objetivo común y cómo responden a las perturbaciones.² No basta con conocer los entresijos de la ciberseguridad. Debemos comprender la resiliencia del sistema (o la falta de ella) si esperamos protegerlo, lo que implica comprender la dinámica del sistema, como exploraremos en este capítulo. Por eso, a lo largo de este libro, tratamos la seguridad como un subconjunto de la resiliencia.

Este libro es una guía práctica sobre cómo diseñar, construir y operar sistemas más resistentes a los ataques. Daremos prioridad al progreso sobre la perfección. Nos basaremos en las lecciones de otros ámbitos de los sistemas complejos, como la sanidad, la industria aeroespacial, la recuperación ante desastres, la ecología, las infraestructuras urbanas y la psicología; de hecho, el rico discurso sobre la resiliencia en estos otros ámbitos es otra de las razones por las que la resiliencia es la base de la Ingeniería del Caos y la Seguridad (SCE). La "seguridad" es un concepto abstracto y blando que se circunscribe en gran medida al sector de la ciberseguridad (o "infoseguridad"), con apropiaciones ocasionales de conceptos de la seguridad física, la aplicación de la ley y, de forma bastante infame, la guerra. Sin embargo, con resiliencia, hay mucho que podemos aprender de otras disciplinas para que nos ayuden en nuestra búsqueda del funcionamiento seguro de nuestros sistemas, reduciendo la cantidad de trabajo y de "reflexiones" necesarias para que tengamos éxito.

Al cambiar nuestro enfoque de la seguridad a la resiliencia, ganamos un superpoder: invertimos nuestro tiempo, energía y otros recursos en actividades orientadas a los resultados, en lugar de malgastar esos recursos en un trabajo performativo que puede parecer productivo, pero que, en realidad, no protege nuestros sistemas. La resiliencia es importante en cualquier sistema complejo y es especialmente esclarecedora en los sistemas complejos en los que intervienen seres humanos, pues nos inspira a cambiar lo que podamos para prepararnos para el éxito en un futuro incierto. Esta es nuestra visión de los programas de seguridad, que pueden convertirse en programas de resiliencia en el futuro. Si te unes al movimiento SCE, puedes proteger la capacidad de tu organización para prosperar ahora y en el futuro. Todo lo que se requiere para que te unas es una apertura a nuevas perspectivas y nuevas formas de conseguir resultados en materia de seguridad, que es el tema central de este libro.

El SCE trata de descubrir, mediante pruebas experimentales, si nuestros sistemas son resistentes a determinadas condiciones, para que podamos aprender a hacerlos aún más resistentes. El fallo es una condición normal del funcionamiento de los sistemas. La SCE ofrece a las organizaciones un conjunto pragmático de principios y prácticas para descubrir proactivamente fallos desconocidos en sus sistemas, antes de que se manifiesten en problemas de cara al cliente y que afecten a la empresa. Quienes practican la SCE evitan esperar a presenciar pasivamente cómo se rompen las cosas en la producción, pasando de una postura reactiva a una proactiva.

Estos son sólo algunos de los resultados transformadores posibles al adoptar un enfoque de la seguridad de los sistemas basado en la resiliencia a través de la SCE. Antes de embarcarnos en nuestra búsqueda, debemos -como cualquier científico noble- asimilar los conceptos fundamentales que allanarán nuestro camino. ¿Qué es un sistema complejo? ¿Qué es el fracaso? ¿Qué es la resiliencia? ¿Y cómo encaja la SCE? Este capítulo responde a todas esas preguntas. Mucha de la sabiduría popular infosecológica tradicional será puesta en tela de juicio y descartada en favor de lecciones empíricas y duramente adquiridas sobre la resiliencia en todos los ámbitos. Te invitamos, como Neo en Matrix, a liberar tu mente y dar un salto con nosotros al mundo real, donde la resiliencia no es sólo cómo sobrevivimos, sino cómo prosperamos.

¿Qué es un sistema complejo?

Un sistema complejo es un en el que un montón de componentes interactúan entre sí y generan como resultado un comportamiento no lineal. Los seres humanos tratamos con sistemas complejos constantemente, desde las cadenas de suministro mundiales a las economías nacionales, pasando por las ciudades y nuestros propios cuerpos y cerebros. Pero antes de profundizar en los sistemas complejos, probablemente deberíamos entender qué es la complejidad.

La complejidad se define formalmente como un término resumen de las propiedades que surgen de las interrelaciones entre las variables de un sistema.³ A medida que aumentan las capacidades del sistema, las interdependencias entre estas variables se extienden, profundizan y oscurecen. Estas interdependencias pueden provocar un efecto dominó en el que las perturbaciones se difunden de una variable a otras conectadas a ella. Esto se denomina "efecto contagio" y se observa en ámbitos como los mercados financieros,⁴ la psicología,⁵ y, por supuesto, los virus biológicos.⁶ En los sistemas distribuidos, es probable que oigas referirse a este mismo fenómeno como "fallo en cascada" (que exploraremos más a fondo en el Capítulo 3).

¿Qué hace que un sistema sea complejo en la práctica? Bueno, pensemos primero en los sistemas sencillos. Los sistemas lineales son fáciles. Si ocurre algo malo, sólo tienes que asegurarte de que el sistema es lo bastante robusto como para volver a su status quo. Piensa en el Sr. Cabeza de Patata; hay una causa y un efecto claros y directos entre que le enchufes los globos oculares y los globos oculares que residen en su cara. Si en lugar de eso le enchufas la oreja en el hueco del brazo, es fácil volver a la disposición prevista, y este error no causa problemas con los ojos, los pies, el sombrero, la boca o el icónico bigote. La base de la "cabeza" de patata interactúa con los componentes de los apéndices de un modo extremadamente predecible y repetible. Pero los sistemas lineales como el Sr. Cabeza de Patata⁷ se encuentran más en los libros de texto y en hipótesis artificiosas que en el mundo real, que es desordenado. Para adaptar la sabiduría clásica a los sistemas informáticos, "Ningún servicio de software 'perfecto' sobrevive al primer contacto con el tráfico de producción".

¿Dónde divergen más los sistemas complejos y los sistemas lineales? Para responder a esa pregunta, exploremos la naturaleza de los sistemas complejos, incluyendo la variedad, la adaptabilidad y la holística.

La variedad define los sistemas complejos

La variedad es quizás el elemento definitorio de la complejidad; lo que solemos describir como sistemas "complejos" son aquellos con un gran grado de variedad. Los sistemas están repletos de todo tipo de variedad: la variedad de componentes, la variedad de interacciones entre esos componentes y la variedad de resultados potenciales del sistema. Nuestros sistemas informáticos implican muchas variables y componentes -el software (nuestro cerebro), el software, el hardware- y, por tanto, también ofrecen una gran variedad de posibles estados futuros.

Como los sistemas complejos implican un verdadero festival de variables retozando y galopando juntas de formas a menudo poco convencionales, pueden presentar una gran variedad de estados posibles.⁸ La organización de investigación sobre seguridad Jepsen señala que los sistemas distribuidos "tienen un estado lógico que cambia con el tiempo" y todos los tipos de sistemas informáticos complejos no son diferentes. Por eso la predicción se percibe como una distracción extravagante en un paradigma de resiliencia. Con tantos estados futuros posibles dentro del sistema, nunca hay un único camino que conduzca a un resultado concreto.⁹ Y lo que es aún más complicado, realizar la misma secuencia de acciones en el sistema puede dar lugar a resultados diferentes. Llegar del punto A al punto B en un sistema complejo es menos "como vuela el cuervo" y más "como vaga el gato (o hace zoom)".

Los sistemas complejos son adaptativos

Y lo que es más importante, los sistemas complejos son adaptativos; cambian y evolucionan en el tiempo y en el espacio, sobre todo en respuesta a los cambios de su entorno externo. Nuestros sistemas informáticos son sistemas complejos adaptativos y, como a veces olvidan algunos informáticos, son de naturaleza sociotecnológica. Tanto las máquinas como los seres humanos son componentes de nuestros sistemas tecnológicos, ya sean sistemas de producción o sistemas informáticos corporativos. El ecosistema de la ciberseguridad es un sistema adaptativo complejo en sí mismo, formado no sólo por una enorme variedad de máquinas, sino también por desarrolladores, defensores, usuarios finales, reguladores gubernamentales, atacantes patrocinados por el gobierno, organizaciones criminales, auditores e innumerables actores humanos más.

Los sistemas complejos son adaptativos porque el cambio no puede detenerse y, por tanto, no puede evitarse que se produzcan fallos. Un sistema complejo resistente es aquel que puede manejar este fallo con elegancia, adaptando su comportamiento para preservar sus funciones críticas.¹⁰ Comprender las transiciones entre la variedad de posibles estados futuros -cómo se adapta un sistema a los cambios en curso- es clave para entender la resistencia y la seguridad de tu sistema a lo largo del tiempo.

También debemos apreciar cómo los seres humanos son una fuente de fortaleza cuando un sistema se acerca al límite entre el éxito y el fracaso; los seres humanos son, en muchos casos, nuestro mecanismo de adaptación ante condiciones adversas y cambiantes, debido a su tendencia natural a sentir curiosidad por los problemas a los que se enfrentan.¹¹ En la sanidad, por ejemplo, los servicios de urgencias suelen ser frágiles debido a los cambios impulsados por la dirección e impuestos por las presiones financieras y operativas, lo que los hace menos resistentes frente a las "demandas acumulativas o en cascada" que los empujan más allá de su capacidad segura conocida.¹² Por tanto, el sistema de urgencias debe "estirarse" ante las mayores exigencias de su funcionamiento para que los fallos individuales -como las actividades necesarias que caen en saco roto- no se acumulen e inclinen el sistema general hacia el fracaso. ¿Cómo se produce este estiramiento? Los humanos del sistema son los que permiten este estiramiento. Los humanos pueden trabajar más duro, ajustar sus estrategias y buscar recursos adicionales, como pedir ayuda a otros humanos para proporcionar capacidad de adaptación adicional.¹³

La naturaleza holística de los sistemas complejos

La complejidad de un sistema -y su comportamiento- es definida de forma holística; poco puede deducirse del comportamiento de los componentes individuales que lo componen.¹⁴ El pensamiento sistémico no es natural para la mayoría de los seres humanos, y los profesionales de la seguridad no están exentos. La industria de la ciberseguridad ha tendido hacia la componentización, incluso hasta herramientas y entornos específicos. Desgraciadamente, este enfoque basado en componentes restringe tu capacidad de comprender cómo se relaciona tu porción de seguridad con todos los demás componentes, que juntos dan forma al funcionamiento del sistema. Fijarse sólo en un componente es como un estrecho frustro de visión -o, si lo prefieres, como un cuello de cono- que dificulta navegar ágilmente por el mundo. Nancy G. Leveson, catedrática de aeronáutica y astronáutica del MIT, nos advierte de que "un enfoque limitado a las acciones del operador, los fallos de los componentes físicos y la tecnología puede llevar a ignorar algunos de los factores más importantes para prevenir futuros accidentes".¹⁵

Los atacantes perciben la naturaleza holística de los sistemas, aprovechando habitualmente las interrelaciones entre componentes. Buscan cómo las interacciones dentro de un sistema pueden darles ventaja. Todo lo que significa la fase de ataque "movimiento lateral" es aprovechar la conexión entre un componente de un sistema con otros dentro del sistema. Los defensores, sin embargo, conciben tradicionalmente la seguridad en términos de si los componentes individuales son seguros o si las conexiones entre ellos son seguras. La seguridad del statu quo piensa en términos de listas y no de gráficos, mientras que los atacantes piensan en gráficos y no en listas. Hay una escasez de conocimientos de sistemas en la defensa tradicional de la ciberseguridad, que los atacantes están encantados de explotar.

El compromiso de alto perfil de SolarWinds pone bien de manifiesto esta dinámica. El Servicio Ruso de Inteligencia Exterior (SVR) tenía un objetivo concreto en mente: acceder tanto a agencias federales como a empresas de la lista Fortune 500 con fines (presumiblemente) de espionaje. Una forma de conseguirlo era buscar los componentes y subsistemas que estos sistemas objetivo tuvieran en común. La plataforma Orion de SolarWinds, que ofrece monitorización y gestión de infraestructuras, era una herramienta que no sólo utilizaban muchas agencias federales y grandes empresas, sino que también poseía una funcionalidad que le permitía acceder a la infraestructura interna de los clientes. A través de esta lente, los atacantes explotaron las interrelaciones e interacciones en múltiples niveles de abstracción.

Sin embargo, una perspectiva holística de los sistemas no debe limitarse a una tecnología específica. La forma en que las organizaciones utilizan la tecnología también implica factores económicos y sociales, que con demasiada frecuencia son ignorados o pasados por alto por los programas tradicionales de ciberseguridad empresarial. Los factores económicos de una organización incluyen los objetivos de ingresos y beneficios, cómo se estructuran los sistemas de compensación u otras decisiones presupuestarias. Los factores sociales de una organización incluyen sus indicadores clave de rendimiento, las expectativas de rendimiento de los empleados, qué tipo de comportamiento se recompensa o reprende, u otras facetas culturales.

Como industria, tendemos a pensar en las vulnerabilidades como algo que se debe a fallos en el software, pero las vulnerabilidades también se deben a paradigmas de incentivos. Pasamos por alto la vulnerabilidad de incentivar a los empleados para que hagan más trabajo, pero más rápido. Pasamos por alto la vulnerabilidad de dar primas a los que "sí" y a los que dominan los juegos políticos. Estas vulnerabilidades reducen la resistencia de la organización al fracaso igual que los fallos del software, pero rara vez aparecen en nuestros modelos de amenaza. Ocasionalmente, identificaremos a los "empleados descontentos" como una posible amenaza interna, sin explorar los factores que les llevan a estar descontentos.

Estos factores de la "capa 8" (humanos) pueden ser difíciles de distinguir, y mucho menos de influir, en una organización. Pero cuando consideramos cómo se manifiesta el fracaso, debemos tenerlos en cuenta.

¿Qué es el fracaso?

Por fallo se entiende cuando los sistemas -incluidas las personas y los procesos empresariales implicados- no funcionan según lo previsto.¹⁶ Un servicio que no completa la comunicación con otro servicio del que depende contaría como un fracaso. Del mismo modo, podemos considerar un fallo cuando los programas de seguridad no alcanzan los objetivos de seguridad. Hay más fallos posibles en el software de los que podríamos enumerar: el abuso de una API, que da lugar a una fuga de datos de los usuarios que provoca ansiedad y obliga a los usuarios a comprar servicios de monitoreo de crédito; un ataque de denegación de servicio (DoS), que dura lo suficiente como para violar los acuerdos de nivel de servicio (SLA) y provocar devoluciones de ingresos; tareas repetitivas, tediosas y manuales con resultados poco claros, que dan lugar a operadores humanos quemados y resentidos. Y así hasta el infinito.

El fracaso es inevitable y ocurre todo el tiempo. Es una parte normal de vivir y funcionar en un sistema complejo, y nuestras decisiones -acertadas o no- influyen en los resultados. Independientemente del ámbito de la actividad humana, evitar el fracaso por completo sólo es posible evitando la actividad por completo: podríamos evitar los accidentes aéreos no pilotando nunca aviones; evitar las muertes durante la cirugía no sometiéndonos nunca a una cirugía; evitar los accidentes financieros no creando nunca un sistema financiero; o, en el ámbito de la ciberseguridad, evitar el fracaso del software no desplegando nunca el software. Parece una tontería, y lo es, pero cuando aspiramos a una "seguridad perfecta", o cuando el consejo de administración exige que nunca experimentemos un incidente de seguridad, nos estamos predisponiendo (irónicamente) al fracaso. Dado que el objetivo del statu quo de los programas de seguridad es "prevenir incidentes", no es de extrañar que los profesionales se sientan inmersos en una batalla que pierden constantemente.

A pesar de su caracterización común en ciberseguridad, el fracaso de la seguridad nunca es el resultado de un solo factor. Un fallo nunca se debe únicamente a la existencia de una vulnerabilidad o a la desestimación de una sola alerta. El fallo funciona como una sinfonía, con múltiples factores que interactúan juntos en armonías y discordias cambiantes. Por ello, debemos adoptar una perspectiva sistémica cuando tratemos de comprender los fallos de seguridad, ampliando nuestro enfoque para examinar las relaciones entre los componentes en lugar de culpar a una causa singular; esta perspectiva sistémica será el tema central del Capítulo 2.

Cuando pensamos en fallos de seguridad, también tendemos a pensar en situaciones que se producen una vez que los sistemas están implementados y funcionando en producción, como las violaciones de datos. Pero las condiciones del fallo de seguridad se siembran mucho antes. El fallo es el resultado de componentes interrelacionados que se comportan de forma inesperada, lo que puede empezar -y casi siempre empieza- mucho antes, en la forma en que se diseñan y desarrollan los sistemas y en otras actividades que informan sobre el aspecto y el funcionamiento de nuestros sistemas en última instancia.

El fracaso es una oportunidad de aprendizaje. Es una oportunidad de desenmarañar todos los factores que condujeron a un suceso no deseado para comprender cómo su interacción fomentó las condiciones del fallo. Si no comprendes los objetivos, las limitaciones y los incentivos que influyen en un sistema, te costará avanzar para que el sistema sea más resistente a los ataques.

Estresores agudos y crónicos en sistemas complejos

Cuando pensamos en incidentes de seguridad, podemos tender a culpar del incidente a un suceso agudo, como un usuario que hace doble clic en un ejecutable malicioso o un atacante que ejecuta una carga útil de minero criptográfico. En la jerga de la resiliencia, estos sucesos agudos se conocen como estresores de tipo pulso. Los estresores de tipo pulso son entradas negativas al sistema que se producen durante un breve periodo de tiempo, como los huracanes en el contexto de los sistemas ecológicos. Por el contrario, los estresores de tipo pulso son aportaciones negativas que se producen durante periodos de tiempo más largos; en los sistemas ecológicos, esto puede incluir la contaminación, la sobrepesca o el calentamiento de los océanos. Para mayor claridad, a lo largo del libro llamaremos a los estresores de tipo pulso "estresores agudos" y a los de tipo prensa "estresores crónicos".

El problema de centrarse de forma miope en los estresores agudos de cualquier sistema complejo es que esos sucesos no harán que el sistema caiga en modos de fallo por sí solos. El ruido de fondo de los estresores crónicos desgasta la resiliencia del sistema durante un periodo de tiempo más largo, ya sean meses o años, de modo que cuando se produce algún tipo de acontecimiento agudo, el sistema ya no es capaz de absorberlo o recuperarse de él.

¿Qué aspecto tienen los factores estresantes crónicos en la ciberseguridad? Pueden incluir

• Rotación regular de empleados

• Despliegue de herramientas y estanterías

• Incapacidad para actualizar sistemas/software

• Procedimientos inflexibles

• Cinta de correr de mejora y parche

• Deuda tecnológica

• Sesgo de statu quo

• Agotamiento de los empleados

• Lagunas en la documentación

• Señales de alerta de baja calidad

• Mantenimiento continuo de las herramientas

• Relaciones tensas o agriadas en toda la organización

• Automatización atrasada o paradigma de procedimiento manual

• Enfoque en el error humano y juego de culpas

• Mentalidad preventiva

Y los estresores agudos en ciberseguridad pueden incluir:

• Operación ransomware

• Error humano

• Explotación del núcleo

• Nueva vulnerabilidad

• Fusiones, adquisiciones o una salida a bolsa

• Auditoría anual

• Fin de la vida útil de una herramienta crítica

• Interrupción debida a una herramienta de seguridad

• Corte de registro o monitoreo

• Cambio en la norma de cumplimiento

• Lanzamiento de nuevos productos

• Robo de credenciales de administrador de la nube

• Reorganización o cuestiones de personal

• Cambios contractuales (como los ANS)

Aunque la recuperación de los factores estresantes agudos es importante, comprender y manejar los factores estresantes crónicos en tus sistemas garantizará que la recuperación no se vea limitada.

Sorpresas en sistemas complejos

Los sistemas complejos también vienen con el "don" de los acontecimientos repentinos e imprevistos, denominados "sorpresas" en algunos ámbitos. La bióloga evolucionista Lynn Margulis describió elocuentemente el elemento sorpresa como "la revelación de que un determinado fenómeno del entorno había sido, hasta ese momento, malinterpretado".¹⁷ En el ámbito del software, las sorpresas que nos encontramos proceden de los ordenadores y de los humanos. Ambos pueden sorprendernos de distintas maneras, pero tendemos a ser menos indulgentes cuando son los humanos quienes nos sorprenden. Merece la pena explorar ambos tipos de sorpresas porque aceptarlas es clave para mantener la resiliencia en nuestros complejos sistemas de software.

Sorpresas informáticas

Los ordenadores nos sorprenden de una variedad de formas fastidiosas. Los núcleos entran en pánico, los discos duros se bloquean, la concurrencia se distorsiona en puntos muertos, la memoria falla y las redes se desconectan (¡o peor aún, los enlaces de red saltan!). La humanidad está constantemente inundada de sorpresas informáticas.¹⁸ Un reto eterno para la programación es cómo garantizar que un programa se comporte exactamente como pretendía su diseñador.

Cuando nos encontramos con sorpresas informáticas, nuestro instinto (aparte de maldecir al ordenador) es eliminar la posibilidad de que se produzca la misma sorpresa en el futuro. En el caso del hardware, podríamos activar módulos de plataforma de confianza (TPM) en un intento de proteger mejor las claves criptográficas, o podríamos añadir redundancia mediante la implementación de réplicas físicas adicionales de algunos componentes. En cuanto al software, podríamos añadir un escáner de vulnerabilidades a nuestro proceso de desarrollo o establecer un requisito de revisión manual de la seguridad antes de pasar a producción. Si puedes eliminar todos los errores del software antes de que llegue a los entornos de producción, podrás minimizar las sorpresas informáticas, ¿verdad?

Por supuesto, ninguna de estas respuestas -ni ninguna respuesta- erradicará el fenómeno de las sorpresas informáticas. Las sorpresas, como los fallos, son inevitables. Son una característica emergente de los sistemas complejos.

Sin embargo, algunas sorpresas informáticas son bastante dudosas en el contexto de la seguridad. Los atacantes que utilizan software como NetWire, una herramienta pública de administración remota que se vio por primera vez en 2012 y sigue viéndose a finales de 2022, no deberían sorprendernos. La realidad es que la narrativa del "atacante rápido y en constante evolución" es más mitología que realidad (un mito especialmente conveniente para los vendedores de seguridad y los defensores que quieren evitar la rendición de cuentas). Los atacantes evolucionan sólo cuando deben hacerlo porque su estrategia operativa, sus herramientas o su infraestructura ya no proporcionan los resultados deseados; hablaremos de su cálculo en el Capítulo 2.

Consejo

La complejidad añade vivacidad, novedad y significado a nuestras vidas. Sin complejidad, no tendríamos comunidades, economías ni mucho progreso. Si intentamos expulsar toda complejidad de nuestros sistemas sociotécnicos, podemos desterrar las sorpresas adversas a costa de condenar al ostracismo las sorpresas agradables. La innovación y la creatividad que apreciamos a menudo se ven sofocadas por la "racionalización".

¿Cómo podemos, en cambio, fomentar el florecimiento de oportunidades, animar nuestros sistemas en lugar de apagarlos? Debemos mejorar la complejidad en lugar de impedirla¹⁹ preservando las posibilidades y minimizando los trastornos que engendra la complejidad. Mientras tanto, podemos encontrar las oportunidades adecuadas para hacer que las partes de nuestros sistemas sean más lineales -más componentes independientes con una influencia causal más predecible en los resultados- de modo que podamos dedicar más esfuerzo a alimentar la plasticidad. En los capítulos 3 a 7 veremos cómo aprovechar estas oportunidades a lo largo del ciclo de vida de la entrega de software.

Sorpresas humanas

Aunque la mayoría de los niños de guardería comprenden que cometer errores es una parte inevitable de la vida, la industria tradicional de la ciberseguridad parece creer que los errores humanos pueden eliminarse de la existencia. Este pensamiento mágico se manifiesta en estrategias de seguridad del statu quo que son extremadamente frágiles a las sorpresas humanas (lo que a menudo se correlaciona con la fragilidad a las sorpresas informáticas también). Un humano que hace clic en un enlace de un correo electrónico, una actividad que realiza miles de veces al año sin incidentes, debería ser quizás el suceso menos sorprendente de todos. Tampoco es sorprendente que un humano posponga la aplicación de un parche en un servidor porque antes hay que seguir una docena de pasos para la aprobación del cambio. Y, sin embargo, con frecuencia se sigue culpando a ambos sucesos como la causa fundamental de los incidentes de seguridad, como si el fallo estuviera en que el humano exhibe un comportamiento humano muy normal, en lugar de una estrategia de seguridad que elige explícitamente ignorar el comportamiento humano normal.

Los sistemas que mantienen la mayor resistencia a las sorpresas humanas combinan enfoques, reconociendo que no hay "una talla única". Un elemento es diseñar (y perfeccionar continuamente) sistemas que se adapten al ser humano, en lugar de forzar al ser humano a adaptarse al sistema mediante políticas estrictas. Con esta mentalidad, la experiencia del usuario de no es algo que esté bien tener, sino un rasgo fundamental del diseño resistente (que exploraremos en el Capítulo 7). Otro elemento es seguir una estrategia basada en el aprendizaje, en la que los errores son oportunidades para adquirir nuevos conocimientos e informar sobre las mejoras, en lugar de oportunidades para culpar, buscar chivos expiatorios o castigar.

No podemos eliminar lo humano de nuestros sistemas a corto plazo y, por tanto, el elemento humano es relevante para todas las partes de la SCE y para la forma en que alimentamos la resiliencia en nuestros sistemas.

¿Qué es la resiliencia?

La resiliencia es la capacidad de un sistema para adaptar su funcionamiento en respuesta a condiciones cambiantes, de modo que pueda seguir funcionando con éxito. En lugar de intentar evitar el fracaso, la resiliencia nos anima a manejar el fracaso con gracia. Más formalmente, la Academia Nacional de Ciencias define la resiliencia como "la capacidad de prepararse y planificar, absorber, recuperarse y adaptarse con más éxito a acontecimientos adversos".²⁰ En su artículo "Características de la resiliencia", los autores esbozan las cinco características comunes que definen la resiliencia:²¹

1. Funcionalidad crítica

2. Límites de seguridad (umbrales)

3. Interacciones a través del espacio-tiempo

4. Circuitos de retroalimentación y cultura de aprendizaje

5. Flexibilidad y apertura al cambio

Todas estas características -que hemos correlacionado con los ingredientes de nuestra poción de resiliencia a continuación- son relevantes para la SCE y se repetirán como motivo de refuerzo a lo largo del libro. Analicemos cada una de ellas con más detalle.

Receta de poción de resistencia

Reactivos:

1. Leche para definir las funciones críticas del sistema: vierte 2 tazas (16 oz) de tu leche preferida para que sirva como base de tu bebida (se recomienda la leche de nueces de macadamia).

2. Hibisco seco para definir los límites seguros del sistema: busca una flor de hibisco y recoge 3 de sus cálices, la cáscara protectora que rodea el capullo, y sécalos.

3. Granos de cacao para observar las interacciones del sistema a través del espacio-tiempo: fermenta los granos durante algún tiempo y tritúralos hasta obtener 2 cucharadas (32 ml) de cacao en polvo (o pica 3 onzas de chocolate negro si se desea más dulzor).

4. Chiles para bucles de retroalimentación y cultura del aprendizaje: muele esta planta versátil y autopolinizante en 1/4 de cucharadita (1-2 ml) de polvo.

5. Malvavisco para la flexibilidad y la voluntad de cambio: coloca encima 1 malvavisco blandito, tostado a tu gusto.

Combina los cuatro primeros reactivos en un caldero (o cacerola) a fuego medio-alto. Mézclalos con un batidor hasta que la poción esté caliente, pero no hirviendo. Viértela en un frasco (o taza) de tu elección y coloca encima el malvavisco. Remueve con una ramita de canela y bebe a fondo.

Funcionalidad crítica

Si quieres entender la capacidad de recuperación de un sistema, tienes que entender su funcionalidad crítica, especialmente cómo realiza estas operaciones básicas bajo la presión de sucesos perjudiciales. En pocas palabras, no puedes proteger un sistema si no comprendes el propósito que lo define.

Definir la razón de ser del sistema es un requisito esencial para articular la resiliencia de un sistema. El objetivo es identificar la resiliencia de qué, a qué y para quién. Sin este encuadre, nuestra noción de la resiliencia del sistema será abstracta y nuestra estrategia carecerá de rumbo, lo que dificultará priorizar las acciones que puedan ayudarnos a mantener mejor la resiliencia.

Esta afirmación fundacional puede formularse como "la resistencia de <funcionalidad crítica> frente a <escenario adverso> para que <resultado positivo del cliente (u organización)>" .

En el caso de una API bursátil, la afirmación podría ser: "La resistencia de proporcionar cotizaciones bursátiles de alto rendimiento frente a ataques DoS para clientes de servicios financieros que requieren resultados en tiempo real". Para un hospital, el enunciado podría ser "La resistencia de las estaciones de trabajo de la sala de urgencias frente al ransomware para que los trabajadores sanitarios puedan atender adecuadamente a los pacientes". Definir qué es funcionalidad crítica y qué no lo es, te da poder durante una crisis, dándote la opción de sacrificar temporalmente la funcionalidad no crítica para mantener operativa la funcionalidad crítica.

Esto ilustra por qué el statu quo de los equipos de seguridad sentados en un silo de torre de marfil no sirve para la realidad de la resiliencia. Para diseñar, construir y operar sistemas más resistentes a los ataques, necesitas personas que comprendan los objetivos del sistema y cómo funciona. La definición de una persona de las funciones críticas de un sistema será diferente de la de otra. Se hace necesario incluir a partes interesadas con percepciones subjetivas, pero informadas por la experiencia, del sistema. Es decir, los "defensores" deben incluir una mezcla de arquitectos, constructores y operadores para tener éxito en la identificación de las funciones críticas de un sistema y en la comprensión de la resistencia del sistema. El equipo que gestiona la seguridad puede incluso parecerse a un equipo de ingeniería de plataformas -formado por ingenieros de software-, como analizaremos en profundidad en el Capítulo 7.

Límites de seguridad (umbrales)

Nuestro segundo ingrediente de la poción de resiliencia son los límites de seguridad, los umbrales más allá de los cuales el sistema deja de ser resiliente al estrés. Evitaremos profundizar demasiado en la extensa literatura²² sobre umbrales²³ en el contexto de la resiliencia del sistema.²⁴ A efectos de la SCE, lo fundamental que hay que recordar sobre los límites de seguridad es que cualquier sistema puede absorber cambios en las condiciones sólo hasta cierto punto y permanecer dentro de su estado actual y saludable de existencia (el que subyace a nuestras suposiciones sobre el comportamiento del sistema, lo que llamamos "modelos mentales"). Más allá de ese punto, el sistema pasa a un estado de existencia diferente en el que su estructura y comportamiento divergen de nuestras expectativas e intenciones.²⁵

Un ejemplo clásico de límites de seguridad se encuentra en el libro Parque Jurásico.²⁶ Cuando los protagonistas inician su recorrido por el parque, el sistema se encuentra en un estado estable. Los dinosaurios están dentro de sus territorios designados y la primera experiencia sobre raíles devuelve con éxito a los huéspedes al albergue. Pero se acumulan los cambios en las condiciones: el genetista principal rellena las lagunas en las secuencias de ADN de los velocirraptores con ADN de rana, lo que les permite cambiar de sexo y reproducirse; los paisajistas plantan lilas de las Indias Occidentales en el parque, cuyas bayas los estegosaurios confunden con piedras en la molleja, envenenándolas; un programa informático para calcular la población de dinosaurios está diseñado para buscar el recuento esperado (238) en lugar del recuento real (244) para que funcione más rápido; un empleado descontento desactiva las líneas telefónicas y la infraestructura de seguridad del parque para robar embriones, provocando un apagón que inutiliza las vallas eléctricas y los vehículos turísticos; el empleado descontento roba el Jeep de emergencia (con un lanzacohetes en la parte trasera), haciendo inviable que el guarda de caza rescate a los protagonistas ahora varados en el parque. Estos cambios acumulados empujan al parque como sistema más allá de su umbral, llevándolo a un nuevo estado de existencia que puede resumirse como caos del tipo letal en lugar del tipo constructivo que defiende SCE. Y lo que es más importante, una vez traspasado ese umbral, es casi imposible que el parque vuelva a su estado anterior.

Por suerte, con los sistemas informáticos es un poco más fácil volver al comportamiento esperado que volver a meter a los dinosaurios en sus corrales. Pero sólo un poco. La histéresis, la dependencia del estado de un sistema de su historia,²⁷ es una característica común de los sistemas complejos y significa que rara vez existe la posibilidad de volver completamente al estado anterior. Desde la perspectiva de la resiliencia, es mejor evitar pasar estos umbrales en primer lugar si podemos. Hacerlo incluye la evolución continua del propio sistema, de modo que sus límites de seguridad puedan ampliarse para absorber las condiciones cambiantes, que exploraremos más adelante en nuestro debate sobre la flexibilidad y la apertura al cambio.

Si queremos que nuestros sistemas sean resistentes a los ataques, tenemos que identificar los límites de seguridad de nuestro sistema antes de que se superen, un proceso continuo, ya que los límites de seguridad cambian a medida que cambia el propio sistema. Los experimentos de caos de seguridad pueden ayudarnos a determinar la sensibilidad de nuestro sistema a determinadas condiciones y, por tanto, a excavar sus umbrales, tanto ahora como cuando puedan evolucionar con el tiempo. Si conocemos esos límites de seguridad, tendremos más posibilidades de proteger el sistema para que no traspase esos umbrales y caiga en el fallo. A medida que un sistema se acerca a sus límites de funcionamiento seguro, la recuperación sigue siendo posible, pero será más lenta. Comprender los umbrales puede ayudarnos a navegar por el difícil objetivo de optimizar el rendimiento del sistema (¡hay que ir rápido!), preservando al mismo tiempo la capacidad de recuperarse rápidamente.

Consejo

Si realizas experimentos de caos con regularidad -o, mejor aún, continuamente-, los resultados de los experimentos deberían revelar si tus sistemas (desde una perspectiva sociotécnica) parecen estar derivando hacia umbrales que podrían hacerlos menos resistentes ante un impacto repentino. Esta deriva podría indicar la presencia de factores de estrés crónicos, que merece la pena investigar y descubrir para que puedas devolver los sistemas (y el equipo) a una línea de base operativa más saludable. (Hablaremos de la experimentación del caos para evaluar la resiliencia en el Capítulo 2).

Por último, recuerda que los sistemas complejos no son lineales. Lo que puede parecer un cambio menor puede ser la proverbial gota final que empuje al sistema más allá de su umbral de resiliencia. Como afirman elocuentemente los estudiosos de la resiliencia ecológica, "cambios lineales relativamente pequeños en los factores de estrés pueden causar cambios relativamente bruscos y no lineales en los ecosistemas".²⁸ Nunca es un solo factor el que causa el fallo, sino una acumulación que traspasa los límites del funcionamiento seguro del sistema.

Interacciones a través del espacio-tiempo

Dado que los sistemas complejos implican muchos componentes que interactúan entre sí, su resiliencia sólo puede comprenderse a través de la dinámica del sistema en el espacio y el tiempo. A medida que las variables (no las de programación) de tu sistema interactúan, se desarrollarán diferentes comportamientos a lo largo del tiempo y de la topología del sistema. Las facetas temporales de la resiliencia incluyen el momento en que se produce un incidente, así como la duración entre que se produce el incidente y se recupera la funcionalidad del sistema. La faceta espacial es el alcance del impacto del incidente: el estado resultante del sistema a través de sus componentes, funcionalidad y capacidad.

Por ejemplo, al considerar la resistencia de una aplicación orientada al consumidor frente a un ataque distribuido de denegación de servicio (DDoS), uno, algunos o todos los servicios pueden verse afectados. El ataque puede producirse durante las horas de mayor tráfico, cuando tus servidores ya están saturados, o durante las horas de sueño de tus clientes objetivo, cuando tus servidores bostezan con capacidad de sobra. La recuperación a niveles de rendimiento aceptables puede ser de milisegundos o de horas. Una interrupción prolongada en un servicio puede degradar el rendimiento de otros servicios a los que esté conectado. Y una interrupción en todos los servicios puede prolongar el tiempo de recuperación del sistema en su conjunto. Como muestra este ejemplo, el tiempo y el espacio están intrínsecamente entrelazados, y debes tenerlos en cuenta a la hora de evaluar la resistencia.

Aquí hay una advertencia sobre la noción de "tiempo" (aparte del hecho de que la humanidad todavía no entiende lo que es realmente).²⁹ El tiempo hasta la recuperación es una métrica importante (que trataremos en el Capítulo 5), pero como aprendimos en nuestro debate sobre los límites de seguridad, es igualmente importante considerar que puede haber estados alternativos de funcionamiento preferibles. Es decir, recuperar continuamente el equilibrio actual no siempre es deseable si ese equilibrio depende de condiciones de funcionamiento que no se ajustan a la realidad. Como en nuestro ejemplo de los dinosaurios salvajes de Parque Jurásico, a veces simplemente no puedes volver al equilibrio original porque la realidad ha cambiado demasiado.

Bucles de retroalimentación y cultura del aprendizaje

La resiliencia depende de recordar el fracaso y aprender de él. Queremos manejar el fracaso con facilidad y dignidad, en lugar de limitarnos a evitar que se produzca; para ello, debemos aceptar el fracaso como un maestro. Los bucles de retroalimentación, en los que las salidas del sistema se utilizan como entradas en operaciones futuras, son por tanto esenciales para la resiliencia del sistema. Cuando observamos un incidente y recordamos la respuesta del sistema al mismo, podemos utilizarla para informar de los cambios que harán que el sistema sea más resistente a esos incidentes en el futuro. Este proceso de aprendizaje y cambio en respuesta a los sucesos se conoce como adaptación, que hemos introducido anteriormente en el capítulo y que trataremos con más detalle en breve. Por desgracia, a menudo oímos la sabiduría popular de la infoseguridad sobre la rapidez con la que los atacantes se adaptan a las defensas, pero no se habla tanto de cómo apoyar una mayor adaptación en nuestras defensas (fuera de la palabrería sobre la IA). El SCE pretende cambiar esta situación.

La importancia de la memoria operativa para la resiliencia se observa también en otros ámbitos. Por ejemplo, la memoria ecológica, la capacidad del pasado para influir en las respuestas presentes o futuras de un ecosistema,³⁰ implica tanto la memoria informativa como la material. La memoria informativa incluye las respuestas adaptativas, mientras que la memoria material incluye las nuevas estructuras, como semillas o nutrientes, resultantes de una perturbación.³¹

Mantener esta memoria no es trivial, pero la diversidad dentro de un sistema ayuda. Los sistemas socioecológicos que se adaptan mediante la experimentación modular pueden reorganizarse más eficazmente tras una perturbación.³² Cuando la red de variables de un sistema es más diversa y las conexiones entre ellas más modulares, es menos probable que el fallo alcance a todas las funciones de un sistema. Esta capacidad de reorientarse ante un fallo significa que se pierden menos variables y conexiones entre ellas durante una perturbación, lo que conserva más recuerdos del suceso que pueden utilizarse como entradas en los bucles de retroalimentación.

Por ejemplo, la urbanización de Constantinopla tuvo éxito en parte porque la comunidad aprendió de los repetidos asedios a la ciudad (una media de cada medio siglo).³³ Estos repetidos incidentes, escriben los estudiosos de la arqueología y la sostenibilidad urbana, "generaron una diversidad de memorias socioecológicas: los medios por los que el conocimiento, la experiencia y la práctica de cómo gestionar un ecosistema local se almacenaban y transmitían en una comunidad". No fueron sólo los historiadores quienes conservaron estos recuerdos. Múltiples grupos sociales conservaron recuerdos del asedio, lo que condujo a adaptaciones como la descentralización de la producción de alimentos y el transporte en comunidades más pequeñas que tenían menos probabilidades de verse perturbadas por un asedio -conceptualmente similar a una arquitectura modular, orientada a los servicios, que aísla la perturbación debida a un pico de recursos en un componente. De hecho, los muros defensivos se desplazaron para dejar espacio a este nuevo uso agrícola y a los huertos. Estos muros sirvieron como recordatorios visuales de las lecciones aprendidas del asedio y protegieron esos recuerdos para que no se disolvieran con el tiempo.

Como seguiremos subrayando a lo largo del libro, nuestros sistemas informáticos son de naturaleza sociotécnica y, por tanto, el mantenimiento de la memoria por parte de las comunidades es tan esencial para la resiliencia de los sistemas en nuestro mundo como lo fue para Constantinopla. Independientemente de quién ejecute el programa de seguridad en tu organización, debe asegurarse de que lo aprendido de los incidentes no sólo se almacena (y de forma accesible para la comunidad), sino que también se aprovecha de nuevas formas a medida que las condiciones cambian con el tiempo. Todos estamos demasiado familiarizados con el fenómeno de una empresa que sufre una brecha por parte de los atacantes y de repente invierte una montaña de dinero y una oleada de energía en seguridad. Pero, a medida que se desvanece el recuerdo del incidente, también se desvanece esta mayor inversión en seguridad. La realidad no deja de cambiar, pero no experimentar un suceso impactante durante un tiempo puede reducir la necesidad de prepararse para ellos en el futuro.

Una cultura de aprendizaje no sólo se produce después de un incidente. Los bucles de retroalimentación tampoco ocurren una sola vez. El monitoreo de los cambios en las funciones críticas y en las condiciones del sistema es complementario a la conservación de los recuerdos del incidente. Los incidentes -ya sean causados por atacantes o por experimentos de caos de seguridad- pueden proporcionar una forma de entrada sensorial que nos ayude a comprender las relaciones causales dentro de nuestros sistemas (similar a tocar una estufa caliente y recordar que eso provoca "ay"). El monitoreo, el registro y otras formas de detección nos ayudan a comprender, basándonos en esas relaciones causales, si nuestros sistemas se acercan a los límites del funcionamiento seguro. Aunque el comportamiento pasado no es un indicador del comportamiento futuro, la combinación del aprendizaje a partir de los recuerdos, la recopilación de datos sobre el comportamiento del sistema y la realización de experimentos que simulan escenarios de fallo pueden darnos mucha más confianza en que, cuando ocurra lo inevitable, estaremos preparados para ello.

Flexibilidad y apertura al cambio

Por último, mantener la flexibilidad a través del espacio-tiempo es una parte esencial de la resiliencia. Esto se suele denominar "capacidad de adaptación" en la ingeniería de la resiliencia.³⁴ La capacidad de adaptación refleja lo preparado o preparado que está un sistema para el cambio -sus comportamientos, modelos, planes, procedimientos, procesos, prácticas-, de modo que pueda seguir funcionando en un mundo cambiante con factores de estrés, sorpresas y otros caprichos.³⁵ También debemos mantener esta flexibilidad a lo largo del tiempo, lo que puede resultar complicado ante las dinámicas y compensaciones sociales de la organización.³⁶

Como hemos mencionado con las culturas de aprendizaje y los bucles de retroalimentación (y trataremos más en el Capítulo 4), la modularidad de puede favorecer la resiliencia. Mantener el sistema lo suficientemente flexible como para adaptarse en respuesta a los cambios en las condiciones de funcionamiento es un elemento de esto. El sistema debe poder estirarse o extenderse más allá de sus límites de seguridad en el espacio y en el tiempo. (¡Espero que empieces a ver cómo se complementan todos los ingredientes de nuestra poción de resiliencia!) Otra forma de pensar en esto, como dice con agudeza David D. Woods, debemos "estar preparados para que nos sorprendan".

Como siempre, el elemento humano también es conmovedor aquí. Nosotros, como partes interesadas que deseamos mantener la seguridad de nuestros sistemas, también tenemos que estar abiertos al cambio en nosotros mismos (no sólo en nuestras máquinas). Puede que estemos aferrados al statu quo o que no queramos cambiar de rumbo porque ya hemos invertido mucho tiempo y dinero. Quizá algo fue nuestra idea especial que nos valió un ascenso. O quizá nos preocupa que el cambio sea duro. Pero esta resistencia cognitiva erosionará la capacidad de tu sistema para responder y adaptarse a los incidentes. Una buena decisión hace un año puede no serlo hoy; tenemos que estar atentos a cuándo nuestras suposiciones dejan de ser ciertas en función de cómo ha cambiado el mundo que nos rodea.

Nunca hay una sola cosa que afecte a tus sistemas; muchas cosas seguirán sorprendiendo o estresando al sistema, desplazando constantemente sus límites de seguridad. La flexibilidad es la propiedad esencial que permite que un sistema absorba y se adapte a esos acontecimientos sin dejar de mantener su finalidad principal. Nunca cultivaremos un conocimiento completo sobre un sistema, por muchos datos que recojamos. Incluso si pudiéramos, reducir la incertidumbre a cero podría ayudarnos a comprender el estado del sistema en este momento, pero seguiría habiendo mucha ambigüedad sobre cómo afectará un cambio concreto al sistema o qué tipo de política o procedimiento mejoraría la resistencia del sistema a un tipo concreto de ataque. Simplemente, hay demasiados factores e interconexiones en juego.

Dado que vivimos en esta realidad indeterminista, debemos mantener una actitud abierta a la evolución y descartar la rigidez que recomiendan los enfoques de seguridad del statu quo. Sobre la base de los bucles de retroalimentación y la cultura del aprendizaje de los que hemos hablado, debemos seguir aprendiendo sobre nuestros sistemas y rastreando los resultados de nuestros experimentos o los resultados de los incidentes para perfeccionar nuestra comprensión de cómo es un programa de seguridad verdaderamente resistente para nuestros sistemas. Esta adaptación continua nos ayuda a prepararnos mejor para futuras perturbaciones y nos da la confianza de que, independientemente de lo que nos aguarde, está en nuestra mano ajustar nuestras estrategias de respuesta y garantizar que el sistema siga cumpliendo con éxito su función crítica.

¿Qué es la fragilidad?

¿Cómo describimos un sistema que no es resiliente? La respuesta es fragilidad:incapacidad de adaptarse a las sorpresas, de tambalearse ante situaciones nuevas que desafían los supuestos y límites subyacentes.³⁷ La fragilidad representa el colapso precipitado del rendimiento engendrado por los factores de estrés, que empujan al sistema más allá de su capacidad para gestionar las perturbaciones y variaciones con elegancia (es decir, más allá de los límites de funcionamiento seguro del sistema).

La fragilidad puede entenderse mejor a nivel de sistemas. Lo que no queremos en nuestros sistemas complejos y adaptativos es fragilidad. Un sistema frágil es aquel que está en el perímetro de funcionar según lo previsto o caer en el fracaso. El grado de fragilidad de un sistema viene determinado por lo cerca que esté de los límites de la función o el funcionamiento esperados, y por las sorpresas que lo empujen más allá de esos límites hacia el fracaso.

El concepto de fragilidad abarca distintos ámbitos que presentan sistemas complejos, como tu propio cerebro. Si sólo dormiste tres horas la noche anterior, no desayunaste y hay obras justo al otro lado de tu ventana, es probable que estés súper quebradizo ante el estrés. Cuando surja una pequeña perturbación en el trabajo, puede que no seas capaz de responder a ella adecuadamente, aunque normalmente seas capaz de responder con elegancia a factores estresantes aún mayores cuando estás bien descansado, alimentado y en un entorno tranquilo. El agotamiento, el hambre y la intrusión sensorial empujan tu sistema fisiológico hasta (o más allá de) los límites de su funcionamiento seguro, provocando degradaciones del rendimiento y fallos ante acontecimientos estresantes.

La fragilidad es perniciosa porque un sistema puede parecer fiable y, al mismo tiempo, arrastrarse hacia la fragilidad. Pero, al alimentar la curiosidad, podemos apoyar el estudio de cómo se comporta el sistema en cuestión con fragilidad. Si los seres humanos sienten curiosidad por saber cómo funcionan los sistemas de su competencia, pero la retroalimentación del sistema es inaccesible u opaca, esta escasa observabilidad socavará la resistencia y acelerará la fragilidad.³⁸ Podemos estudiar el impacto de la fragilidad realizando experimentos para excavar los límites del sistema y observar cómo se comporta cerca de esos límites cuando se producen sorpresas -visá vis un experimento de caos.

Puesto que la fragilidad nos puede sorprender, debemos recordar que mantener la resiliencia es un proceso activo, que la resiliencia es un verbo.

La resiliencia es un verbo

"Resiliente" o "seguro" es una propiedad emergente de los sistemas, no una propiedad estática.³⁹ Como subconjunto de la resiliencia, la seguridad es algo que un sistema hace, no algo que un sistema tiene. Como tal, la seguridad sólo puede revelarse en el flujo de acontecimientos de la realidad. La resiliencia no sólo representa la capacidad de recuperarse de las amenazas y los factores de estrés, sino también la capacidad de actuar según sea necesario en diversas condiciones y responder adecuadamente tanto a las perturbaciones como a las oportunidades. La resiliencia no consiste únicamente en capear tempestades. También tiene que ver con la innovación: detectar oportunidades para hacer evolucionar tus prácticas y estar aún mejor preparado para la próxima tormenta. La resiliencia debe concebirse como un ciclo proactivo y perpetuo de monitoreo de todo el sistema, anticipándose a las perturbaciones, aprendiendo de los éxitos y los fracasos, y adaptando el sistema a lo largo del tiempo.⁴⁰ Aunque "resiliencia" sería el término más apropiado para captar la naturaleza de acción-verbo de la resiliencia, a lo largo del libro utilizaremos expresiones como "mantener la resiliencia" o "mantener la resiliencia" para mayor claridad.

Del mismo modo, la seguridad es un valor que debemos esforzarnos continuamente por mantener en nuestras organizaciones, en lugar de tratarla como una mercancía, un destino o un estado final esperado. Debemos pensar en términos de ayudar a nuestros sistemas a existir de forma resistente y segura en la caprichosa naturaleza de la producción, en lugar de "añadir seguridad" a los sistemas. Esta perspectiva nos ayuda a comprender cómo se desarrolla el fallo en un sistema, lo que nos permite identificar los puntos en los que este fallo podría haberse detenido o desviado. Esto, en última instancia, nos ayuda a saber qué señales pueden ayudarnos a identificar el fallo antes, continuando el ciclo.

Considerar la seguridad como algo que un sistema hace y no que tiene también te posiciona para anticiparte a las condiciones de fallo que puedan surgir en el futuro. Los investigadores en factores humanos y seguridad de sistemas Richard Cook y Jens Rasmussen señalan en su artículo de la revista "Going Solid" que, a medida que un sistema sigue funcionando a lo largo del tiempo, tiene "tendencia a moverse incrementalmente hacia los límites de las operaciones seguras"⁴¹-esos umbrales de los que hablábamos antes. Los aumentos de productividad debidos a la tecnología rara vez se manifiestan en una reducción de las horas de trabajo o en una nueva capacidad para mejorar la seguridad. Las organizaciones siempre querrán realizar sus actividades con menos gastos y mayor rapidez, y este deseo se manifestará en sus sistemas.

Los sistemas en continua evolución y adaptación proporcionan una seguridad laboral emergente a los responsables de la resiliencia y la seguridad. Si el programa de seguridad puede ayudar a la organización a anticipar nuevos tipos de peligros y oportunidades de fallo a medida que la organización evoluciona sus sistemas, entonces la seguridad adquiere un valor incalculable. Esto es a menudo lo que la ciberseguridad en general cree que hace, pero en realidad tiende a anclar a la organización en el pasado en lugar de mirar hacia delante y labrar un camino seguro hacia adelante. ¿Qué otras percepciones erróneas se cuelan en la conversación común sobre ciberseguridad? A continuación exploraremos otros mitos relacionados con la resiliencia.

Resiliencia: Mito y Realidad

Aristóteles sostenía que, para comprender algo, debemos comprender lo que no es.⁴² Esta sección abordará los mitos y realidades de la resiliencia con el objetivo de ayudarte a ser más resistente al aceite de serpiente que rodea al término.

Mito: Robustez = Resiliencia

Un mito muy extendido es que la resiliencia es la capacidad de un sistema para resistir un choque, como un ataque, y volver a la "normalidad". Esta capacidad se conoce específicamente como robustez en la literatura sobre resiliencia. En el diálogo sobre ciberseguridad solemos ver que la resiliencia se reduce a robustez, sobre todo en un marketing demasiado entusiasta (aunque la ciberseguridad no es el único ámbito afectado por este error). La realidad es que un sistema resiliente no es robusto; es un sistema que puede anticipar situaciones potenciales, observar situaciones en curso, responder cuando se produce una perturbación y aprender de experiencias pasadas .⁴³

Centrarse en la robustez conduce a una postura "defensiva". Como el roble gigante de la fábula de Esopo, la robustez intenta luchar contra la tormenta, mientras que los juncos -al igual que los sistemas adaptativos- se doblan humildemente al viento, diseñados con el supuesto de que las condiciones adversas les afectarán. Como resultado, el statu quo de la ciberseguridad aspira a la prevención perfecta, desafiando la realidad al intentar evitar que se produzcan incidentes en primer lugar. Este enfoque en la prevención de lo inevitable nos distrae de prepararnos para ello.

La robustez también nos lleva a priorizar la restauración de un sistema comprometido a su versión anterior, a pesar de que sigue siendo vulnerable a las condiciones que propiciaron el compromiso.⁴⁴ Esta ilusión nos impulsa hacia controles técnicos o punitivos en lugar de hacia mitigaciones sistémicas o de diseño, lo que a su vez crea una falsa sensación de seguridad en un sistema que sigue siendo intrínsecamente vulnerable.⁴⁵ Extrayendo una lección de la frenética frontera de las catástrofes naturales, si se añade una barrera física contra las inundaciones a una zona residencial, es probable que se construyan más viviendas allí, lo que se traduce en una mayor probabilidad de resultados catastróficos si falla la barrera.⁴⁶ Para establecer un paralelismo en ciberseguridad, considera las frágiles aplicaciones internas que se dejan languidecer con un diseño inseguro debido a la creencia de que un cortafuegos o un sistema de detección de intrusos (IDS) bloqueará a los atacantes el acceso y la explotación.

El enfoque de la resiliencia se da cuenta de que el cambio es el lenguaje del universo. Sin aprender de la experiencia, no podemos adaptarnos a la realidad. La resiliencia también reconoce que prosperar es sobrevivir. La robustez, la capacidad de resistir un acontecimiento adverso como un ataque, no es suficiente.

Mito: Podemos y debemos evitar el fracaso

La industria tradicional de la ciberseguridad se centra en evitar que se produzcan fallos. El objetivo es "frustrar" las amenazas, "detener" los exploits, "bloquear" los ataques y demás verborrea agresiva para describir lo que, en última instancia, es la prevención de que los atacantes realicen cualquier actividad en el ecosistema tecnológico de tu organización. Mientras que las esclarecedoras revisiones de incidentes (a veces llamadas "postmortems") sobre incidentes relacionados con el rendimiento suelen hacerse públicas, los incidentes de seguridad se tratan como asuntos vergonzosos que sólo deben discutirse a puerta cerrada o entre grupos de intercambio de información de pago. El fracaso se enmarca en términos morales de "los malos ganan", por lo que no es de extrañar que el discurso del sector de la infoseguridad a menudo sea tan pesimista. El objetivo es evitar de algún modo todos los problemas en todo momento, lo que, irónicamente, aboca al programa de seguridad al fracaso (por no mencionar que asfixia la cultura del aprendizaje).

Relacionada con esta obsesión por la prevención está la pasión más reciente por la predicción. La metodología FAIR, un modelo cuantitativo de análisis de riesgos diseñado para la ciberseguridad, es habitual en los programas de seguridad tradicionales y requiere suposiciones sobre la probabilidad de "frecuencia de eventos de pérdida", así como sobre la "magnitud de la pérdida". La idea es que si puedes predecir los tipos de ataques que sufrirás, con qué frecuencia se producirán y cuál será su impacto, podrás determinar la cantidad adecuada a gastar en material de seguridad y cómo debería gastarse.

Pero la previsión exacta es imposible en los sistemas complejos; si crees que la previsión de la seguridad es difícil, habla con un meteorólogo. Nuestra predilección por la predicción puede haber ayudado al Homo sapiens a sobrevivir resolviendo problemas lineales, como la forma en que las presas navegarán por un bosque, pero podría decirse que perjudica más de lo que ayuda en un mundo moderno repleto de un vertiginoso grado de interactividad. Puesto que la resiliencia es algo que un sistema hace en lugar de tener, no puede cuantificarse mediante probabilidades de sucesos perturbadores. Como bromeó la sismóloga Susan Elizabeth Hough en el contexto de las catástrofes naturales: "A un edificio no le importa si se predijo o no un terremoto o una sacudida; resistirá la sacudida, o no".⁴⁷

Intentar prevenir o predecir el fracaso en nuestros complejos sistemas informáticos es una actividad costosa porque nos distrae y nos quita recursos para prepararnos realmente para el fracaso. Tratar el fracaso como una oportunidad de aprendizaje y prepararse para él son esfuerzos más productivos y pragmáticos. En lugar de dedicar tanto tiempo a predecir qué cantidad de recursos gastar y dónde, puedes realizar experimentos y aprender de la experiencia para perfeccionar continuamente tu programa de seguridad basándote en pruebas tangibles. (Y este enfoque requiere pasar mucho menos tiempo en Excel, lo que es una ventaja para la mayoría).

Los "malos"⁴⁸ a veces ganan. Eso es simplemente una parte insatisfactoria de la vida, mires por donde mires en la humanidad. Pero lo que podemos controlar es cuánto sufrimos por ello. Detectar a tiempo los fallos en los controles de seguridad puede significar la diferencia entre una vulnerabilidad no explotada y tener que anunciar una violación de datos a tus clientes. La resiliencia y la ingeniería del caos aceptan la realidad de que los modelos estarán incompletos, los controles fallarán, las mitigaciones se desactivarán; en otras palabras, las cosas fallarán y seguirán fallando a medida que el mundo gira y evoluciona. Si diseñamos nuestros sistemas para que esperen fallos, desafiamos proactivamente nuestras suposiciones mediante la experimentación e incorporamos lo que aprendemos como retroalimentación a nuestra estrategia, podremos comprender mejor cómo funcionan realmente nuestros sistemas y cómo mejorarlos y asegurarlos mejor.

En lugar de intentar evitar que se produzcan fallos, el objetivo de la resiliencia y la ingeniería del caos es gestionar los fallos con elegancia.⁴⁹ La detección temprana del fallo minimiza el impacto del incidente y también reduce los costes de limpieza tras el incidente. Los ingenieros han aprendido que detectar pronto los fallos de los servicios -como la latencia pletórica en una API de pago- reduce el coste de la reparación, y los fallos de seguridad no son diferentes.

Así llegamos a dos principios rectores básicos de la SCE:

1. Espera que fallen los controles de seguridad y prepárate en consecuencia.

2. No intentes evitar por completo los incidentes, sino más bien adoptar la capacidad de responder rápida y eficazmente a ellos.

Según el primer principio, los sistemas deben diseñarse partiendo del supuesto de que los controles de seguridad fallarán y de que los usuarios no comprenderán inmediatamente (ni se preocuparán) por las implicaciones de sus acciones para la seguridad.⁵⁰ Según el segundo principio, descrito por el experto en economía ecológica Peter Timmerman, la resiliencia puede concebirse como la creación de "capacidad de amortiguación" en un sistema para reforzar continuamente su capacidad de afrontar el futuro.⁵¹

Es esencial aceptar que se producirán compromisos y errores, y mantener la atención centrada en garantizar que nuestros sistemas puedan manejar con elegancia los acontecimientos adversos. La seguridad debe pasar de posturas defensivas a posturas resilientes, abandonando el estándar imposible de la prevención perfecta.

Mito: La seguridad de cada componente suma resistencia

Dado que la resiliencia es una propiedad emergente a nivel de sistemas, no puede medirse analizando los componentes. Esto es bastante desafortunado, ya que la ciberseguridad tradicional se basa en gran medida en el nivel de los componentes, ya sea evaluando su seguridad o protegiéndolos. La tabulación de las vulnerabilidades de los componentes individuales se considera una prueba del grado de seguridad de la organización frente a los ataques. Desde una perspectiva de ingeniería de la resiliencia, esa noción no tiene sentido. Si conectamos un frontend que recibe entradas a una base de datos y verificamos que cada componente es "seguro" individualmente, podemos pasar por alto el potencial de inyección SQL que surge de su interacción.

La mitigación y protección a nivel de componente se debe en parte a este mito. Otra creencia, que los profesionales son más reticentes a reconocer, es que abordar los problemas de seguridad uno por uno, componente por componente, es comparativamente más conveniente que trabajar en el panorama más amplio de la seguridad de los sistemas. Gravitar hacia el trabajo que parece más fácil y justificarlo con un impulso más profundo (como este mito) es una tendencia humana natural. A saber, también en la sanidad vemos el mismo enfoque en el rediseño de procesos y la ingeniería de seguridad a nivel de componentes.⁵² La escasez de conocimientos y comprensión sobre el funcionamiento de los sistemas complejos afecta a todos los sectores.

La buena noticia es que en realidad no necesitamos mediciones precisas para evaluar la resiliencia (como detallaremos en el Capítulo 2). La evaluación tanto de la fragilidad como de la resiliencia se obtiene observando el sistema en escenarios tanto adversos como sanos. Ésta es la belleza de la SCE: realizando experimentos específicos, puedes probar hipótesis sobre la resiliencia de tu sistema ante distintos tipos de condiciones adversas y observar cómo responden tus sistemas a ellas. Como las teselas de un mosaico, cada experimento crea una imagen más rica de tu sistema para ayudarte a comprenderlo mejor. Como exploraremos en el Capítulo 7, podemos incluso enfocar la seguridad como un producto, aplicando el rigor científico y la experimentación que nos ayudan a conseguir mejores resultados de producto.

Los dominios ajenos al software no tienen este lujo. No queremos inyectar ciclones en la Gran Barrera de Coral como experimento para evaluar su resistencia, ni querríamos inyectar condiciones adversas en una economía nacional, un cuerpo humano en la mesa de operaciones, un sistema urbano de agua, un avión en pleno vuelo o, en realidad, cualquier otro sistema real y vivo del que dependan los seres humanos. Dado que (por lo que sabemos) los ordenadores no son sintientes, y siempre que obtengamos el consentimiento de las partes interesadas humanas en nuestros sistemas informáticos, este dominio posee una enorme ventaja en relación con otros dominios a la hora de comprender la resiliencia de los sistemas, porque podemos realizar experimentos de caos de seguridad .

Mito: Crear una "cultura de la seguridad" soluciona los errores humanos

El sector de la ciberseguridad piensa y habla mucho de "cultura de la seguridad", pero este término significa cosas distintas según a quién preguntes. La infoseguridad no está sola en este enfoque; otros ámbitos, especialmente la sanidad,⁵³ han prestado mucha atención al fomento de una "cultura de la seguridad". Pero en la base de este enfoque en la "cultura" -independientemente del sector- está su belicosa insistencia en que los seres humanos entrelazados con los sistemas deben centrarse más en la seguridad (o "protección" en otros ámbitos). En ciberseguridad, especialmente, se trata de un intento de distribuir la carga de la seguridad al resto de la organización , incluida la responsabilidad por los incidentes. De ahí que veamos una obsesión por evitar que los usuarios hagan clic en las cosas, a pesar de la necesidad que tienen en su trabajo de hacer clic en muchas cosas muchas veces al día. Se podría caracterizar la cúspide de la "cultura de la seguridad" infosegura como impedir que la gente haga clic en cosas en la máquina de hacer clic en cosas: lamonomanía moderna de someter a la indomable ballena blanca de la era de Internet.

Los debates sobre la cultura tienen poco impacto si no se basan en la realidad de los sistemas dinámicos y complejos en los que operan los seres humanos. Es fácil sugerir que todo mejoraría si los seres humanos simplemente prestaran más atención a las cuestiones de seguridad en el curso de su trabajo, pero es poco probable que tales recomendaciones prosperen. Es más fructífero comprender por qué se pasan por alto los problemas de seguridad, ya sea debido a prioridades contrapuestas, presiones de producción, atención desviada en múltiples direcciones, mensajes de alerta confusos y otras causas. Y entonces, ¿a qué trabajo nos referimos? Prestar atención a la seguridad significa algo muy distinto para un profesional de la contratación, que interactúa frecuentemente con partes externas, que para un desarrollador que construye API que operan en entornos de producción.

Cualquier debate fructífero en este sentido suele verse sofocado por unas métricas de salud mal elegidas y otras métricas de "vanidad de la seguridad". Sencillamente, no proporcionan la imagen completa de la seguridad de la organización, sino que atraen a los profesionales haciéndoles creer que lo entienden porque la cuantificación se siente como ciencia real, igual que el chamanismo, el humoralismo y la astrología se sentían en épocas anteriores. El porcentaje de usuarios que hacen clic en enlaces de phishing en tu organización no te dice si tu organización sufrirá un incidente horrible si un usuario acaba haciendo clic en algo que no debería. Si aumenta el número de vulnerabilidades que encuentras, ¿es bueno o malo? Tal vez el número de vulnerabilidades encontradas en las aplicaciones importe menos que si estas vulnerabilidades se están encontrando antes en el ciclo de vida de entrega del software, si se están remediando más rápidamente o, mejor aún, si el entorno de producción está diseñado para que su explotación no tenga ningún impacto material. Ni que decir tiene que una métrica como el porcentaje de "cobertura de riesgos" (cuyo objetivo es el 100% de cobertura de este ectoplasma fantasmal) es poco más que relleno para alimentar a ejecutivos y consejos de administración que carecen de conocimientos técnicos.

El otro subproducto angustioso de los intentos tradicionales de fomentar una "cultura de la seguridad" es centrarse en castigar a los humanos o tratarlos como enemigos etiquetados de "amenazas internas". Los programas de seguridad del statu quo pueden comprar herramientas con sistemas de aprendizaje automático y capacidades de procesamiento del lenguaje natural para averiguar qué empleados suenan tristes o enfadados para detectar a tiempo las "amenazas internas".⁵⁴ O los equipos de seguridad pueden instalar programas espía⁵⁵ en los equipos de los empleados para detectar si están buscando otros trabajos o muestran otros síntomas arbitrarios de estar molestos con la organización. En el statu quo de la seguridad, preferimos tratar a los humanos como al atacante de Schrödinger que diseccionar los factores organizativos que podrían conducir a esta forma de vulnerabilidad en primer lugar. Esto puede aplacar a los responsables, pero representa nuestro fracaso en el fomento de la seguridad organizativa.

La ciberseguridad no es el único ámbito problemático que muestra esta tendencia. El sociólogo de Yale Charles Perrow observó en los sistemas complejos que:

Prácticamente todos los sistemas que examinaremos sitúan el "error del operador" en un lugar destacado de su lista de factores causales: por lo general, entre el 60% y el 80% de los accidentes se atribuyen a este factor. Pero si, como veremos una y otra vez, el operador se enfrenta a interacciones inesperadas y normalmente misteriosas entre fallos, decir que debería haber hecho zigzag en lugar de zag sólo es posible después de los hechos.⁵⁶

Sorprendentemente, el sector de la ciberseguridad atribuye aproximadamente la misma proporción de fallos también al "error humano". La contribución exacta del supuesto "error humano" en las violaciones de datos depende de la fuente que consultes: el Informe de Investigaciones sobre Violaciones de Datos de Verizon de 2022 dice que en el 82% de las violaciones "intervino un elemento humano", mientras que otro estudio de 2021 informó de que el error humano fue la causa del 88% de las violaciones de datos. De las violaciones comunicadas a la Oficina del Comisionado de Información (ICO) entre 2017 y 2018, el 90% también citó el error humano como causa. Pero si indagas en cuáles fueron esos errores humanos, a menudo representan acciones que son totalmente benignas en otros contextos, como hacer clic en enlaces, insertar código, actualizar configuraciones, compartir datos o introducir credenciales en páginas de inicio de sesión.

La SCE hace hincapié en la importancia de las perspectivas externas. Debemos tener en cuenta las perspectivas de nuestros adversarios (como veremos en el Capítulo 2) y realizar investigaciones sobre los usuarios (como veremos en el Capítulo 7), desarrollando una comprensión de las perspectivas de quienes construyen, mantienen y utilizan los sistemas, de modo que el programa de seguridad no se base en una fantasía. Adoptar una perspectiva sistémica es el primer paso para afrontar mejor el fracaso de la seguridad, ya que te permite ver cómo una combinación de factores estresantes crónicos y agudos conduce al fracaso.

Con el SCE, el programa de seguridad puede aportar un inmenso valor a su organización reduciendo la brecha entre el trabajo como se imagina y el trabajo como se realiza.⁵⁷ Los sistemas invadirán sus umbrales de seguridad cuando las políticas y los procedimientos se diseñen basándose en comportamientos operativos ideales (tanto de humanos como de máquinas). Esperar que los humanos realicen múltiples pasos secuencialmente sin recordatorios ni ayudas visuales es una receta para cometer errores y omisiones.

Los programas de seguridad de la SCE también se interesan por workarounds en lugar de prohibirlos. En realidad, las soluciones alternativas pueden contribuir a la resiliencia. Los humanos pueden ser muy hábiles a la hora de responder a presiones y objetivos contrapuestos, creando soluciones que permiten al sistema mantener el rendimiento de sus funciones críticas. Cuando se eliminan las soluciones provisionales, a los humanos que interactúan con el sistema les resulta más difícil utilizar una variedad de estrategias en respuesta a la variedad de comportamientos que pueden encontrar durante su trabajo. Y eso erosiona la resiliencia. A diferencia de la sabiduría infosegura tradicional, la SCE ve las soluciones provisionales como lo que son: adaptaciones en respuesta a condiciones cambiantes que son naturales en los sistemas complejos.⁵⁸ Merece la pena comprender las soluciones provisionales a la hora de diseñar los procedimientos adecuados para que los seres humanos actúen con flexibilidad y seguridad.

Conclusiones del capítulo

• Todos nuestros sistemas de software son complejos. Los sistemas complejos están llenos de variedad, son adaptativos y tienen una naturaleza holística.

• El fallo se produce cuando los sistemas -o los componentes de los sistemas- no funcionan como se pretendía. En los sistemas complejos, el fallo es inevitable y ocurre todo el tiempo. Lo que importa es cómo nos preparamos para ello.

• El fracaso nunca es el resultado de un solo factor; hay múltiples factores influyentes que trabajan en concierto. Los estresores agudos y crónicos son factores, al igual que las sorpresas informáticas y humanas.

• La resiliencia es la capacidad de un sistema para adaptar con elegancia su funcionamiento en respuesta a condiciones cambiantes, de modo que pueda seguir prosperando.

• La resiliencia es la base de la ingeniería del caos de la seguridad. La Ingeniería del Caos de la Seguridad (SCE) es un conjunto de principios y prácticas que te ayudan a diseñar, construir y operar sistemas complejos más resistentes a los ataques.

• Los cinco ingredientes de la "pócima de la resiliencia" incluyen la comprensión de la funcionalidad crítica de un sistema; la comprensión de sus límites de seguridad; la observación de las interacciones entre sus componentes a través del espacio y el tiempo; el fomento de bucles de retroalimentación y una cultura de aprendizaje; y el mantenimiento de la flexibilidad y la apertura al cambio.

• La resiliencia es un verbo. La seguridad, como subconjunto de la resiliencia, es algo que un sistema hace, no algo que un sistema tiene.

• SCE reconoce que un sistema resistente es aquel que funciona según lo necesario en diversas condiciones y puede responder adecuadamente tanto a las perturbaciones -como las amenazas- como a las oportunidades. Los programas de seguridad pretenden ayudar a la organización a anticiparse a los nuevos tipos de peligros, así como a las oportunidades de innovar para estar aún mejor preparada para el siguiente incidente.

• Hay muchos mitos sobre la resiliencia, cuatro de los cuales hemos tratado: la resiliencia se confunde con la robustez, la capacidad de "volver" a la normalidad tras un ataque; la creencia de que podemos y debemos evitar los fallos (lo cual es imposible); el mito de que la seguridad de cada componente se suma a la seguridad de todo el sistema; y que crear una "cultura de la seguridad" soluciona el problema del "error humano".

• SCE adopta la idea de que el fracaso es inevitable y lo utiliza como una oportunidad de aprendizaje. En lugar de prevenir el fracaso, debemos dar prioridad a gestionarlo con elegancia, lo que también se ajusta mejor a los objetivos de la organización.

¹ George V. Neville-Neil, "Asegurar las joyas de la empresa", Communications of the ACM 65, nº 10 (2022): 25-26.

² Richard J. Holden, "¿Personas o sistemas? La culpa es humana. The Fix Is to Engineer", Professional Safety 54, nº 12 (2009): 34.

³ David D. Woods, "Engineering Organizational Resilience to Enhance Safety: A Progress Report on the Emerging Field of Resilience Engineering," Proceedings of the Human Factors and Ergonomics Society Annual Meeting 50, nº 19 (octubre de 2006): 2237-2241.

⁴ Dirk G. Baur, "El contagio financiero y la economía real", Journal of Banking & Finance 36, nº 10 (2012): 2680-2692; Kristin Forbes, "The 'Big C': Identifying Contagion", National Bureau of Economic Research, Documento de trabajo 18465 (2012).

⁵ Iacopo Iacopini et al., "Simplicial Models of Social Contagion", Nature Communications 10, nº 1 (2019): 2485; Sinan Aral y Christos Nicolaides, "Exercise Contagion in a Global Social Network", Nature Communications 8, nº 1 (2017): 14753.

⁶ Steven Sanche et al., "High Contagiousness and Rapid Spread of Severe Acute Respiratory Syndrome Coronavirus 2," Emerging Infectious Diseases 26, no. 7 (2020): 1470.

⁷ Un Diógenes moderno podría levantar al Sr. Cabeza de Patata y declarar: "¡Contemplad! Un sistema lineal!"

⁸ Amy Rankin et al., "La resiliencia en las operaciones cotidianas: Un marco para analizar las adaptaciones en el trabajo de alto riesgo", Journal of Cognitive Engineering and Decision Making 8, nº 1 (2014): 78-97.

⁹ Rankin, "La resiliencia en las operaciones cotidianas", 78-97.

¹⁰ Joonhong Ahn y otros, eds., Reflexiones sobre el accidente nuclear de Fukushima Daiichi: Toward Social-Scientific Literacy and Engineering Resilience (Berlín: Springer Nature, 2015).

¹¹ Nick Chater y George Loewenstein, "The Under-Appreciated Drive for Sense-Making", Journal of Economic Behavior & Organization 126 (2016): 137-154.

¹² Instituto de Medicina, Hospital-Based Emergency Care: At the Breaking Point (Washington, DC: The National Academies Press, 2007).

¹³ Christopher Nemeth y otros, "Minding the Gaps: Creating Resilience in Health Care", en Advances in Patient Safety: New Directions and Alternative Approaches, Vol. 3: Performance and Tools (Rockville, MD: Agency for Healthcare Research and Quality, agosto de 2008).

¹⁴ Len Fisher, "Para crear resiliencia, estudia sistemas complejos", Nature 595, nº 7867 (2021): 352-352.

¹⁵ Nancy G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety (Cambridge, MA: MIT Press, 2016).

¹⁶ Los ámbitos pertinentes incluyen la gestión de catástrofes (por ejemplo, la resistencia a las inundaciones), el cambio climático (por ejemplo, la agricultura, la gestión de los arrecifes de coral) y las industrias críticas para la seguridad, como la aviación y la medicina.

¹⁷ Lynn Margulis y Dorion Sagan, ¿Qué es la vida? (Berkeley y Los Ángeles, CA: University of California Press, 2000).

¹⁸ Como ejemplo, Facebook publicó un estudio sobre los errores de memoria a escala y descubrió que el 9,62% de los servidores experimentaban errores de memoria corregibles (acumulativamente en todos los meses), lo que les llevó a "corroborar la tendencia de que los errores de memoria siguen siendo un problema generalizado en el campo" (el subrayado es suyo).

¹⁹ Jane Jacobs, La muerte y la vida de las grandes ciudades americanas (Nueva York: Vintage Books, 1992).

²⁰ Susan L. Cutter y otros, "Resiliencia ante los desastres: Un imperativo nacional", Medio ambiente: Ciencia y Política para el Desarrollo Sostenible 55, nº 2 (2013): 25-29.

²¹ Elizabeth B. Connelly y otros, "Características de la resiliencia", Environment Systems and Decisions 37, nº 1 (2017): 46-50.

²² Jens Rasmussen, "Gestión de riesgos en una sociedad dinámica: A Modelling Problem", Safety Science 27, nº 2-3 (1997): 183-213.

²³ K. J. Willis et al., "Biodiversity Baselines, Thresholds and Resilience: Testing Predictions and Assumptions Using Palaeoecological Data," Trends in Ecology & Evolution 25, no. 10 (2010): 583-591.

²⁴ Didier L. Baho et al., "Un marco cuantitativo para evaluar la resiliencia ecológica", Ecology & Society 22, no. 3 (2017): 17.

²⁵ Esto se conoce como la parte de "colapso" o "confusión" del ciclo adaptativo. Brian D. Fath y otros, "Navegar por el ciclo adaptativo: Un enfoque para gestionar la resiliencia de los sistemas sociales", Ecology & Society 20, nº 2 (2015): 24.

²⁶ El libro profundiza sorprendentemente en la teoría de los sistemas no lineales, mientras que la película sólo araña la superficie.

²⁷ Arie Staal et al., "Histéresis de los bosques tropicales en el siglo XXI", Nature Communications 11, no. 4978 (2020).

²⁸ Craig R. Allen et al., "Cuantificación de la resiliencia espacial", Journal of Applied Ecology 53, no. 3 (2016): 625-635.

²⁹ Carlo Rovelli, "La desaparición del espacio y el tiempo", en Filosofía y fundamentos de la física: The Ontology of Spacetime, 25-36 (Amsterdam y Oxford, Reino Unido: Elsevier, 2006).

³⁰ Terry P. Hughes et al., "La memoria ecológica modifica el impacto acumulativo de los extremos climáticos recurrentes", Nature Climate Change 9, nº 1 (2019): 40-43.

³¹ Jill F. Johnstone et al., "Changing Disturbance Regimes, Ecological Memory, and Forest Resilience," Fronteras de la Ecología y el Medio Ambiente 14, nº 7 (2016): 369-378.

³² Fath, "Navegar por el ciclo adaptativo".

³³ John Ljungkvist y otros, "El Antropoceno Urbano: Lecciones para la sostenibilidad de la historia medioambiental de Constantinopla", en La mente urbana: Cultural and Environmental Dynamics, 367-390 (Uppsala, Suecia: Uppsala University Press, 2010).

³⁴ Nick Brooks y otros, "Assessing and Enhancing Adaptive Capacity", en Adaptation Policy Frameworks for Climate Change: Developing Strategies, Policies and Measures, 165-181 (Nueva York y Cambridge, Reino Unido: PNUD y Cambridge University Press, 2005).

³⁵ Carl Folke y otros, "Resiliencia y desarrollo sostenible: Crear capacidad de adaptación en un mundo de transformaciones", AMBIO: Revista del Medio Humano 31, no. 5 (2002): 437-440.

³⁶ Shana M. Sundstrom y Craig R. Allen, "El ciclo adaptativo: Más que una metáfora". Complejidad Ecológica 39 (agosto): 100767.

³⁷ Woods, "Engineering Organizational Resilience to Enhance Safety", 2237-2241.

³⁸ Nemeth, "Minding the Gaps".

³⁹ J. Park et al., "Integrating Risk and Resilience Approaches to Catastrophe Management in Engineering Systems", Risk Analysis 33, no. 3 (2013): 356-366.

⁴⁰ Connelly, "Características de la resiliencia", 46-50.

⁴¹ Richard Cook y Jens Rasmussen, "Going Solid: A Model of System Dynamics and Consequences for Patient Safety", BMJ Quality & Safety 14, nº 2 (2005): 130-134.

⁴² Alan Lightman, Imposibilidades probables: Musings on Beginnings and Endings (Nueva York: Pantheon Books, 2021).

⁴³ Rankin, "Resiliencia en las operaciones cotidianas", 78-97.

⁴⁴ Adriana X. Sánchez et al., "¿Son algunas formas de resiliencia más sostenibles que otras?" Procedia Engineering 180 (2017): 881-889.

⁴⁵ Esto se conoce como la "paradoja del desarrollo seguro": la seguridad prevista que se obtiene al introducir una solución técnica a un problema facilita, en cambio, la acumulación de riesgos con el tiempo, lo que conduce a mayores daños potenciales en caso de incidente. Véase Raymond J. Burby, "Hurricane Katrina and the Paradoxes of Government Disaster Policy: Cómo tomar decisiones gubernamentales sensatas para las zonas peligrosas", The ANNALS of the American Academy of Political and Social Science 604, nº 1 (2006): 171-191.

⁴⁶ Caroline Wenger, "El roble o la caña: cómo se traducen las teorías de la resiliencia en políticas de gestión de catástrofes", Ecology and Society 22, no. 3 (2017): 18.

⁴⁷ Susan Elizabeth Hough, Predicting the Unpredictable, reprint ed. (Princeton, NJ: Princeton University Press, 2016).

⁴⁸ No utilizaremos el término chicos malos o actores malos a lo largo de este libro por diversas razones, entre ellas la visión infantil del mundo que confiesa. Sin embargo, es probable que lo encuentres en el discurso típico de la infoseguridad como un intento de invectiva contra los atacantes en general.

⁴⁹ Véanse los principios de Bill Hoffman sobre los servicios favorables a las operaciones, a través de James R. Hamilton, "On Designing and Deploying Internet-Scale Services", LISA 18 (noviembre de 2007): 1-18.

⁵⁰ Los "usuarios finales" y los "administradores de sistemas" aparecen continuamente como "principales actores" implicados en las violaciones de datos en las ediciones anuales del Informe de Verizon sobre Investigaciones de Violaciones de Datos (DBIR) (Informe 2020).

⁵¹ Peter Timmerman, "Vulnerabilidad, resiliencia y el colapso de la sociedad", Monografía Medioambiental nº 1 (1981): 1-42.

⁵² Nemeth, "Minding the Gaps".

⁵³ Cook, "Going Solid", 130-134.

⁵⁴ Hay algunos ejemplos de este tipo de análisis de sentimientos para detectar "amenazas internas", uno de ellos es: https://oreil.ly/qTA76. Consulta la entrada del blog de la CMU sobre los retos que plantea en la práctica.

⁵⁵ Normalmente los vendedores no dirán "keylogging" explícitamente, sino que utilizarán eufemismos como "dinámica de pulsaciones", "registro de pulsaciones" o "análisis del comportamiento del usuario". Como explica CISA en su Guía de Mitigación de Amenazas Internas sobre el Monitoreo de la Actividad del Usuario (UAM), "En general, el software UAM monitorea toda la gama del comportamiento cibernético de un usuario. Puede registrar las pulsaciones de teclas, hacer capturas de pantalla, grabar en vídeo las sesiones, inspeccionar los paquetes de red, supervisar los núcleos, rastrear la navegación y las búsquedas en la web, registrar la carga y descarga de archivos y supervisar los registros del sistema para obtener una imagen completa de la actividad en toda la red." Véase también la presentación "Exploración de la dinámica de pulsaciones de teclas para la detección de amenazas internas".

⁵⁶ Charles Perrow, Accidentes normales: Vivir con tecnologías de alto riesgo, edición revisada (Princeton, NJ: Princeton University Press, 1999).

⁵⁷ Manikam Pillay y Gaël Morel, "Measuring Resilience Engineering: An Integrative Review and Framework for Bench-marking Organisational Safety," Safety 6, no. 3 (2020): 37.

⁵⁸ Rankin, "La resiliencia en las operaciones cotidianas", 78-97.