La interrupción del servicio de CrowdStrike y la fragilidad impulsada por el mercado La interrupción masiva del servicio de Internet del viernes, causada por una empresa tecnológica de tamaño medio llamada CrowdStrike, afectó a las principales aerolíneas, hospitales y bancos. Se cancelaron casi 7.000 vuelos. Derribó sistemas del 911 y fábricas, juzgados y estaciones de televisión. Calcular el costo total llevará tiempo. La interrupción afectó a más de 8,5 millones de computadoras con Windows y el costo seguramente será de miles de millones de dólares, igualando fácilmente los ciberataques anteriores más costosos, como NotPetya. La catástrofe es otro recordatorio de lo frágil que es la infraestructura global de Internet. Es compleja, está profundamente interconectada y llena de puntos únicos de falla. Como experimentamos la semana pasada, un solo problema en una pequeña pieza de software puede dejar fuera de servicio grandes franjas de Internet y la economía global. La fragilidad de la sociedad moderna no se limita a la tecnología. Podemos verla en muchas partes de nuestra infraestructura, desde los alimentos hasta la electricidad, desde las finanzas hasta el transporte. Esto suele ser resultado de la globalización y la consolidación, pero no siempre. En el ámbito de la tecnología de la información, la fragilidad también se debe al hecho de que cientos de empresas, de las que no ha oído hablar, desempeñan cada una un papel pequeño pero esencial para mantener el funcionamiento de Internet. CrowdStrike es una de esas empresas. Esta fragilidad es resultado de los incentivos del mercado. En informática empresarial (a diferencia de la informática personal), una empresa que proporciona infraestructura informática a redes empresariales tiene incentivos para ser lo más integral posible, tener el mayor acceso posible a las redes de sus clientes y funcionar de la forma más eficiente posible. Las redundancias no son rentables. Ser lento y cuidadoso no es rentable. Estar menos integrado y menos esencial y tener menos acceso a las redes y máquinas de los clientes no es rentable (al menos en el corto plazo, que es el método por el que se mide a estas empresas). Esto es cierto para empresas como CrowdStrike. También lo es para los clientes de CrowdStrike, que tampoco contaban con resiliencia, redundancia o sistemas de respaldo para fallos como este, porque también son un gasto que afecta a la rentabilidad a corto plazo. Pero la fragilidad sólo es rentable cuando todo funciona bien. Cuando un sistema frágil falla, falla estrepitosamente. El coste del fracaso para una empresa como CrowdStrike es una fracción del coste para la economía global. Y habrá otro CrowdStrike, y otro después de ese. El mercado recompensa a los sistemas que maximizan los beneficios a corto plazo y no penaliza suficientemente a esas empresas por el impacto que pueden tener sus errores (los precios de las acciones caen sólo temporalmente, las sanciones regulatorias son menores, las demandas colectivas se resuelven, los seguros atenúan las pérdidas financieras). Ni siquiera está claro que la industria de la tecnología de la información pudiera existir en su forma actual si tuviera que tener en cuenta todos los riesgos que causa esa fragilidad. La asimetría de los costes se debe en gran medida a nuestra compleja interdependencia con tantos sistemas y tecnologías, cualquiera de los cuales puede causar fallos importantes. Cada pieza de software depende de docenas de otras, normalmente escritas por otros equipos de ingeniería a veces años antes en el otro lado del planeta. Algunos sistemas de software no han sido diseñados adecuadamente para contener el daño causado por un error o un hackeo de alguna dependencia clave del software. Estos fallos pueden adoptar muchas formas. El fallo de CrowdStrike fue el resultado de una actualización de software defectuosa. El error no se detectó durante las pruebas y se extendió a los clientes de CrowdStrike en todo el mundo. A veces, los fallos son resultados deliberados de un ciberataque. Otros fallos son simplemente aleatorios, el resultado de alguna dependencia imprevista entre diferentes piezas de sistemas de software críticos. Imagine una casa donde los paneles de yeso, el suelo, la chimenea y las luminarias están fabricados por empresas que necesitan un acceso continuo y cuyos fallos harían que la casa se derrumbara. Nunca pondría un pie en una estructura así, pero así es como se construyen los sistemas de software. No es que el 100 por ciento del sistema dependa de cada empresa todo el tiempo, pero el 100 por ciento del sistema puede fallar si falla cualquiera de ellas. Pero hacerlo mejor es caro y no contribuye inmediatamente a los resultados de una empresa. El economista Ronald Coase describió célebremente la naturaleza de la empresa -cualquier negocio- como una colección de contratos. Cada contrato tiene un coste. Realizar la misma función internamente también tiene un costo. Cuando los costos de mantener el contrato son menores que los de hacerlo internamente, entonces tiene sentido subcontratar: a otra empresa de la misma calle o, en una era de comunicación y coordinación baratas, a otra empresa del otro lado del planeta. El problema es que tanto los costos financieros como los de riesgo de la subcontratación pueden estar ocultos (retrasarse en el tiempo y enmascararse por la complejidad) y pueden generar una falsa sensación de seguridad cuando las empresas están realmente enredadas en estas dependencias invisibles. La capacidad de subcontratar servicios de software se hizo fácil hace poco más de una década, debido a la conectividad de red global ubicua, los modelos de negocio de la nube y el software como servicio, y un aumento de las certificaciones y los ejercicios de verificación de casillas dirigidos por la industria y el gobierno. Esta fuerza del mercado ha llevado a la actual interdependencia global de los sistemas, mucho más allá de su industria y su ámbito original. Es por eso que volar aviones depende de un software que no tiene nada que ver con la aviónica. Por eso, en nuestro mundo conectado de Internet de las cosas, podemos imaginar que una mala actualización de software similar haga que nuestros coches no arranquen una mañana o que nuestros frigoríficos fallen. No es algo que podamos desmantelar de la noche a la mañana. Hemos construido una sociedad basada en una tecnología compleja de la que dependemos por completo y no tenemos una forma fiable de gestionarla. Comparemos Internet con los sistemas ecológicos. Ambos son complejos, pero los sistemas ecológicos tienen una complejidad profunda en lugar de una complejidad superficial. En los sistemas ecológicos, hay menos puntos únicos de fallo: si algo falla en un ecosistema natural sano, hay otras cosas que tomarán el relevo. Eso les da una resiliencia de la que carecen nuestros sistemas tecnológicos. Necesitamos una complejidad profunda en nuestros sistemas tecnológicos, y eso requerirá cambios en el mercado. En este momento, los incentivos del mercado en tecnología son centrarse en cómo las cosas tienen éxito: una empresa como CrowdStrike proporciona un servicio clave que marca la funcionalidad requerida en una lista de verificación de cumplimiento, lo que hace que todo se centre en las características que ofrecerán cuando todo funcione. Eso es exactamente al revés. Queremos que nuestra infraestructura tecnológica imite a la naturaleza en la forma en que las cosas fallan. Esto nos dará una complejidad profunda en lugar de una complejidad superficial, y resiliencia en lugar de fragilidad. ¿Cómo lo logramos? Hay ejemplos en el mundo de la tecnología, pero son fragmentarios. Netflix es famoso por su herramienta Chaos Monkey, que provoca fallos intencionalmente para obligar a los sistemas (y, en realidad, a los ingenieros) a ser más resilientes. Los incentivos no se alinean en el corto plazo: hace que a los ingenieros de Netflix les resulte más difícil hacer su trabajo y más costoso para ellos operar sus sistemas. Con el paso de los años, este tipo de pruebas genera sistemas más estables, pero requiere un liderazgo corporativo con visión de futuro y la voluntad de invertir en el corto plazo para obtener posibles beneficios a largo plazo. La actualización de la semana pasada no habría sido un gran fracaso si CrowdStrike hubiera implementado este cambio de forma incremental: primero el 1 por ciento de sus usuarios, luego el 10 por ciento, luego todos. Pero eso es mucho más costoso, porque requiere un compromiso de tiempo de los ingenieros para monitorear, depurar e iterar, y puede llevar meses hacerlo correctamente en el caso de un software complejo y de misión crítica. Hoy en día, un ejecutivo analizará los incentivos del mercado y concluirá correctamente que es mejor para ellos correr el riesgo que “desperdiciar” tiempo y dinero. Las herramientas habituales de regulación y certificación pueden ser inadecuadas, porque el fallo de los sistemas complejos también es inherentemente complejo. No podemos describir de antemano las incógnitas desconocidas involucradas. Más bien, lo que necesitamos codificar son los procesos mediante los cuales deben realizarse las pruebas de fallos. Sabemos, por ejemplo, cómo probar si los autos fallan bien. La Administración Nacional de Seguridad del Tráfico en las Carreteras choca autos para saber qué les sucede a las personas que están dentro. Pero los autos son relativamente simples y mantener a las personas seguras es sencillo. El software es diferente. Es diverso, cambia constantemente y tiene que adaptarse continuamente a nuevas circunstancias. No podemos esperar que una regulación que ordene una lista específica de pruebas de choque de software sea suficiente. Una vez más, la seguridad y la resiliencia se logran a través del proceso mediante el cual fallamos y arreglamos, no a través de una lista de verificación específica. La regulación tiene que codificar ese proceso. Los sistemas de Internet actuales son demasiado complejos para esperar que si somos inteligentes y construimos cada pieza correctamente, la suma total funcionará correctamente. Tenemos que romper cosas deliberadamente y seguir rompiéndolas. Este proceso repetido de romper y reparar hará que estos sistemas sean confiables. Y luego, la voluntad de aceptar las ineficiencias hará que estos sistemas sean resilientes. Pero los incentivos económicos indican a las empresas la dirección opuesta, para construir sus sistemas tan frágiles como les sea posible. Este ensayo fue escrito con Barath Raghavan y apareció previamente en Lawfare.com. Publicado el 25 de julio de 2024 a las 14:37 • 1 comentario
Deja una respuesta