Entiendo que se busque humor en este desastre, pero me pregunto cómo queda el tema de la responsabilidad.
He visto varias veces en HN que este incidente causó pérdidas de miles de millones de dólares, pero todavía no se habla mucho de demandas.
¿Las licencias están tan blindadas que los clientes no tienen forma de obtener reparación? Puedo entenderlo si se trata de consumidores cuyas PCs personales quedaron detenidas durante horas o días, pero me parece absurdo que la industria acepte este nivel de exposición al riesgo.
Esta es una de las grandes razones por las que la ingeniería civil se considera una disciplina seria. Si un puente se cae, puede haber no solo responsabilidad económica, sino también penal, y a los estudiantes de ingeniería civil se les repite que pueden ir a la cárcel si actúan de forma poco ética o asumen riesgos inaceptables como ingenieros.
¿Habrá algún camino para que los ingenieros de software alcancen ese nivel de responsabilidad y normas profesionales?
La ingeniería civil es distinta porque diseña productos físicos. Nada se diseña justo al límite; todo tiene un margen de seguridad suficiente.
Es como calcular un puente lleno de camiones durante un huracán y, además, un terremoto, y luego sumarle 20%. Si no estás seguro de que una viga aguante, la haces más grande; si el cálculo está errado en 0,5%, no pasa gran cosa.
Si en los documentos de diseño hay un error tipográfico y se intenta poner una viga de 150 pies en un hueco de 15,0 pies, el constructor pedirá confirmación. Por eso, el colapso de un puente casi con certeza es resultado de negligencia grave.
En cambio, en programación, que haya un solo < en lugar de <= puede marcar la diferencia entre un estado perfectamente funcional y daños de miles de millones de dólares. Ningún programador en la Tierra puede escribir una aplicación de complejidad no trivial con cero defectos al 100%.
Incluso el microkernel seL4, que presume pruebas formales de corrección, tiene bugs. Los compiladores y los verificadores de pruebas son técnicamente posibles, pero no se quejan aunque les pidas hacer algo evidentemente incorrecto.
Ninguna persona razonable aceptaría una responsabilidad prácticamente ilimitada por el más mínimo error.
Si queremos exigir responsabilidad a los ingenieros de software, primero hay que encontrar una forma de distinguir los errores cotidianos de buena fe de la negligencia grave, y formalizar eso sería muy difícil.
Cuando Delta amenazó con demandar por pérdidas de 500 millones de dólares, CrowdStrike respondió públicamente que, por contrato, el límite de responsabilidad de CrowdStrike era de unos pocos millones de dólares.
Luego envió una lista diciendo que, si comenzaba la demanda, pediría en el discovery los planes de respaldo, los planes de conmutación por error, los calendarios y resultados de pruebas, cuándo fue el último simulacro de recuperación de respaldos, etc.
En la práctica, el mensaje fue: “Si demandan, vamos a escarbar en sus prácticas de IT con tanta profundidad que ustedes quedarán más avergonzados que nosotros, y mostraremos que la culpa fue de ustedes”.
Hay vías de reparación, pero, como dices, no son para la gente común. Las empresas están presentando demandas contra CrowdStrike y seguirán haciéndolo; por los documentos que publicó CrowdStrike, parece muy probable que las empresas afectadas ganen.
Parece bastante probable que convenzan a un juez, jurado o árbitro de que CrowdStrike incurrió en negligencia grave y que causó a las empresas pérdidas directas y un daño reputacional indirecto evidente.
Sinceramente, ni siquiera sé si CrowdStrike peleará hasta el final. Creo que la mayoría de los casos se resolverán fuera de tribunales, y puede que en los próximos años veamos cómo CrowdStrike se derrumba.
Muchas empresas tienen seguros para incidentes que cortan sus fuentes de ingresos. Igual que el seguro de cosechas para agricultores o el seguro contra desastres de una gran tienda minorista, imagino que debe existir algo para situaciones en las que una caída de infraestructura reduce las ventas a cero durante cierto período.
Aunque todos los afectados le reclamaran a ClownStrike el 100% de sus pérdidas, los ingresos de ClownStrike no alcanzan para cubrirlas. Aunque quisieras hacer que la empresa cierre, no podrías recuperar una suma cercana a las pérdidas reales.
Por eso me pregunto qué se propone en la práctica. El código sin bugs es casi imposible, y algunos riesgos los acepta el usuario.
¿De verdad crees que el software debe estar 100% libre de bugs antes de usarse? ¿Cómo lo demostrarías? Y entonces la siguiente pregunta sería qué tan limpio es tu propio código como para pensar que eso es posible.
Es posible, pero la respuesta es tiempo. La ingeniería civil tiene miles de años de historia; la ingeniería de software es mucho más joven y sus fundamentos todavía están cambiando.
Al menos en mi país, desde fines de los años 70 hubo proyectos de ley para licenciar a analistas de sistemas, programadores de computadoras electrónicas, operadores de máquinas de procesamiento de datos y mecanógrafos (!).
Si esas leyes se hubieran aprobado, el desarrollo de software de nuestro país se habría atrasado décadas. Por ejemplo, un proyecto quería permitir la “operación y manejo de dispositivos o máquinas de procesamiento electrónico, incluidos terminales (dispositivos digitales o visuales)” solo a quienes tuvieran licencia de “operador de máquinas de procesamiento de datos”.
Este problema va más allá de CrowdStrike: muestra todo un enfoque de seguridad en el que se compran productos de seguridad comerciales para satisfacer a reguladores y aseguradoras, sin preocuparse realmente por qué hacen ni cómo funcionan.
No quiero decir que no deba regularse la tecnología, pero el modelo actual de “compremos esto para quitarnos responsabilidad de encima” no funciona.
Lo peor es que las personas que habrían previsto esto —es decir, el departamento de IT— probablemente no podían hacer nada. Lo más probable es que la alta dirección lo haya impuesto por requisitos de “seguro cibernético” u otras regulaciones. Es una locura.
He visto a muchos buenos responsables de IT que se sienten así, pero en mi experiencia la mayoría de los departamentos de IT, si cumplen los puntos que exige el contrato, no se interesan mucho en si eso resuelve el problema real.
En un trabajo anterior, durante el fin de semana instalaron en mi estación de trabajo un software similar a CrowdStrike, y cuando volví descubrí que el tiempo de compilación se había vuelto 20% más lento.
En ese momento yo lo estaba midiendo, así que tenía decenas de mediciones, y con trazas ETL mostré que el software era la causa, pero IT no lo reconoció. El contrato del proveedor decía que no habría impacto en el rendimiento para nuestra carga de trabajo.
La mayoría de los departamentos de IT no habría previsto esto, y es razonable que no diseñaran toda su estrategia de seguridad en torno a esa posibilidad. No sé de dónde sale esta narrativa.
Falcon brindaba, y todavía brinda, beneficios de seguridad reales y concretos a sus clientes. Eso no significa que elimine todos los riesgos ni que no genere riesgos propios.
Como cualquier problema de ingeniería, literalmente es un juego de compromisos. No debería ser algo desconocido para la gente de aquí.
De repente, HN está lleno de expertos en seguridad cargados de sesgo retrospectivo y sesgo por el evento más reciente, explicando cómo las empresas podrían haber esquivado esta bala, pero sin considerar las balas reales que ya estaban esquivando al usar Falcon en primer lugar.
Esto podría terminar usándose como evidencia en tribunales o en demandas, y no es algo gracioso.
Originalmente habría sido un momento cerrado entre geeks de seguridad, pero ahora quedó expuesto para que el público general, que sufrió grandes daños, pueda burlarse a gusto.
No me pareció en absoluto que el ejecutivo de CrowdStrike se tomara la situación a la ligera. Al contrario, ese discurso parecía tomar la situación en serio, reconocer que fue un error enorme y aceptar ese trofeo como una marca de vergüenza y una advertencia para futuros empleados de CrowdStrike.
Creo que fue un gesto realmente digno que ese ejecutivo aceptara el premio. Claro que decir eso no significa en absoluto que CrowdStrike quede exenta de responsabilidad por el incidente ni de responsabilidad indemnizatoria.
Podría ser gracioso hacerlo en una camiseta:
When I use
REGEXP
I use it in my
KERNEL CODE
La tragedia y la comedia son dos caras de la misma moneda.
Los problemas de seguridad informática ya aparecieron durante la guerra de Vietnam, y Estados Unidos de hecho trabajó para encontrar modelos eficaces de seguridad informática. Pero vivimos en una sociedad que prácticamente borró eso de la memoria.
¿Por qué tiene que haber un escáner corriendo 24/7 sobre todo lo que una computadora intenta ejecutar?
¿Por qué el sistema operativo tiene que depender de permisos periféricos?
Culpar a CrowdStrike solo desvía la atención de fallas de diseño fundamentales que ignoramos todos los días en sistemas operativos como Linux, MacOS y Windows.
Todavía sigo culpando a Microsoft, porque no es imposible ejecutar el código que se actualiza fuera del kernel y usar el código en modo kernel solo para observar y actuar, no para la lógica.
Trabajo en IT y fui la pobre persona que justo estaba de guardia cuando Clown Strike tiró abajo la mayor parte de la infraestructura.
Personalmente, gracias a que me resistí a usar porquerías basadas en la nube, probablemente recuperamos todo en horas en lugar de días.
Me preocupa bastante que, como gente tipo directores de IT no ve esto como un problema y no toma ninguna medida para frenar estas porquerías, pronto tengamos que lidiar con otra gran caída basada en la nube.
Vengo repitiendo hasta el cansancio que “solo los idiotas dependen de computadoras ajenas”, y estoy 100% de acuerdo con eso.
Es raro que haya gerentes o ejecutivos que entiendan por qué un punto único de falla es malo dentro de la infraestructura interna, pero les parezca bien que el producto o servicio de un proveedor externo se convierta en un punto único de falla.
Parecen creer que, si firman un contrato y pagan, lo construyen y mantienen superhumanos que, a diferencia de los ingenieros internos, no cometen errores. No entiendo esa confianza equivocada.
100% de acuerdo. Además, me sorprende ver cómo se pagan costos absurdos por servicios en la nube como Azure VD.
Con solo una parte del presupuesto anual de nube, una empresa podría construir por su cuenta una infraestructura muy estable y capaz de funcionar sin conexión.
Tu tono suena muy agresivo. Aunque tengas razón, no creo que me gustaría trabajar contigo.
Tal vez podrías transmitir mejor la idea si no hablaras de forma tan agresiva.
No hay mucho que se pueda hacer cuando CTOs idiotas aceptan consejos de cumbres de CTOs, consultores con incentivos distorsionados y todo tipo de conferencias al azar.
Naturalmente, Microsoft domina la mayoría de los ganadores anteriores de “Most Epic Fail”.
Se puede seguir repartiendo vergüenza, pero si uno cree que este tipo de caída en producción se debió a malos procesos, Microsoft claramente también tuvo un papel importante aquí.
De verdad me pregunto cómo el CEO y el CTO siguen en sus puestos después de este desastre.
En varias ciudades el 911 no funcionaba y el flujo de los hospitales se volvió tan lento que prácticamente se detuvo, ¿pero tienen tiempo para ir a Defcon a bromear?
¿Todavía hay hospitales que no pudieron arreglar sus computadoras? Claro que CS la arruinó, pero aparte de pagar daños y cambiar procesos, no sé qué más se puede hacer ahora.
Advertir a la gente para que no repita los mismos errores no parece una mala forma de usar el tiempo.
Es correcto que aquí se critique a CS, pero creo que haber puesto CS en sistemas críticos como el 911 fue en sí mismo un gran error.
Aunque probablemente la persona que lo hizo sabía que podía evitar la responsabilidad, así que supongo que no tenía motivos para preocuparse.
1 comentarios
Opiniones de Hacker News
Entiendo que se busque humor en este desastre, pero me pregunto cómo queda el tema de la responsabilidad.
He visto varias veces en HN que este incidente causó pérdidas de miles de millones de dólares, pero todavía no se habla mucho de demandas.
¿Las licencias están tan blindadas que los clientes no tienen forma de obtener reparación? Puedo entenderlo si se trata de consumidores cuyas PCs personales quedaron detenidas durante horas o días, pero me parece absurdo que la industria acepte este nivel de exposición al riesgo.
Esta es una de las grandes razones por las que la ingeniería civil se considera una disciplina seria. Si un puente se cae, puede haber no solo responsabilidad económica, sino también penal, y a los estudiantes de ingeniería civil se les repite que pueden ir a la cárcel si actúan de forma poco ética o asumen riesgos inaceptables como ingenieros.
¿Habrá algún camino para que los ingenieros de software alcancen ese nivel de responsabilidad y normas profesionales?
Es como calcular un puente lleno de camiones durante un huracán y, además, un terremoto, y luego sumarle 20%. Si no estás seguro de que una viga aguante, la haces más grande; si el cálculo está errado en 0,5%, no pasa gran cosa.
Si en los documentos de diseño hay un error tipográfico y se intenta poner una viga de 150 pies en un hueco de 15,0 pies, el constructor pedirá confirmación. Por eso, el colapso de un puente casi con certeza es resultado de negligencia grave.
En cambio, en programación, que haya un solo
<en lugar de<=puede marcar la diferencia entre un estado perfectamente funcional y daños de miles de millones de dólares. Ningún programador en la Tierra puede escribir una aplicación de complejidad no trivial con cero defectos al 100%.Incluso el microkernel seL4, que presume pruebas formales de corrección, tiene bugs. Los compiladores y los verificadores de pruebas son técnicamente posibles, pero no se quejan aunque les pidas hacer algo evidentemente incorrecto.
Ninguna persona razonable aceptaría una responsabilidad prácticamente ilimitada por el más mínimo error.
Si queremos exigir responsabilidad a los ingenieros de software, primero hay que encontrar una forma de distinguir los errores cotidianos de buena fe de la negligencia grave, y formalizar eso sería muy difícil.
Luego envió una lista diciendo que, si comenzaba la demanda, pediría en el discovery los planes de respaldo, los planes de conmutación por error, los calendarios y resultados de pruebas, cuándo fue el último simulacro de recuperación de respaldos, etc.
En la práctica, el mensaje fue: “Si demandan, vamos a escarbar en sus prácticas de IT con tanta profundidad que ustedes quedarán más avergonzados que nosotros, y mostraremos que la culpa fue de ustedes”.
Parece bastante probable que convenzan a un juez, jurado o árbitro de que CrowdStrike incurrió en negligencia grave y que causó a las empresas pérdidas directas y un daño reputacional indirecto evidente.
Sinceramente, ni siquiera sé si CrowdStrike peleará hasta el final. Creo que la mayoría de los casos se resolverán fuera de tribunales, y puede que en los próximos años veamos cómo CrowdStrike se derrumba.
Aunque todos los afectados le reclamaran a ClownStrike el 100% de sus pérdidas, los ingresos de ClownStrike no alcanzan para cubrirlas. Aunque quisieras hacer que la empresa cierre, no podrías recuperar una suma cercana a las pérdidas reales.
Por eso me pregunto qué se propone en la práctica. El código sin bugs es casi imposible, y algunos riesgos los acepta el usuario.
¿De verdad crees que el software debe estar 100% libre de bugs antes de usarse? ¿Cómo lo demostrarías? Y entonces la siguiente pregunta sería qué tan limpio es tu propio código como para pensar que eso es posible.
Al menos en mi país, desde fines de los años 70 hubo proyectos de ley para licenciar a analistas de sistemas, programadores de computadoras electrónicas, operadores de máquinas de procesamiento de datos y mecanógrafos (!).
Si esas leyes se hubieran aprobado, el desarrollo de software de nuestro país se habría atrasado décadas. Por ejemplo, un proyecto quería permitir la “operación y manejo de dispositivos o máquinas de procesamiento electrónico, incluidos terminales (dispositivos digitales o visuales)” solo a quienes tuvieran licencia de “operador de máquinas de procesamiento de datos”.
Este problema va más allá de CrowdStrike: muestra todo un enfoque de seguridad en el que se compran productos de seguridad comerciales para satisfacer a reguladores y aseguradoras, sin preocuparse realmente por qué hacen ni cómo funcionan.
No quiero decir que no deba regularse la tecnología, pero el modelo actual de “compremos esto para quitarnos responsabilidad de encima” no funciona.
Lo peor es que las personas que habrían previsto esto —es decir, el departamento de IT— probablemente no podían hacer nada. Lo más probable es que la alta dirección lo haya impuesto por requisitos de “seguro cibernético” u otras regulaciones. Es una locura.
En un trabajo anterior, durante el fin de semana instalaron en mi estación de trabajo un software similar a CrowdStrike, y cuando volví descubrí que el tiempo de compilación se había vuelto 20% más lento.
En ese momento yo lo estaba midiendo, así que tenía decenas de mediciones, y con trazas ETL mostré que el software era la causa, pero IT no lo reconoció. El contrato del proveedor decía que no habría impacto en el rendimiento para nuestra carga de trabajo.
Falcon brindaba, y todavía brinda, beneficios de seguridad reales y concretos a sus clientes. Eso no significa que elimine todos los riesgos ni que no genere riesgos propios.
Como cualquier problema de ingeniería, literalmente es un juego de compromisos. No debería ser algo desconocido para la gente de aquí.
De repente, HN está lleno de expertos en seguridad cargados de sesgo retrospectivo y sesgo por el evento más reciente, explicando cómo las empresas podrían haber esquivado esta bala, pero sin considerar las balas reales que ya estaban esquivando al usar Falcon en primer lugar.
Esto podría terminar usándose como evidencia en tribunales o en demandas, y no es algo gracioso.
Originalmente habría sido un momento cerrado entre geeks de seguridad, pero ahora quedó expuesto para que el público general, que sufrió grandes daños, pueda burlarse a gusto.
Creo que fue un gesto realmente digno que ese ejecutivo aceptara el premio. Claro que decir eso no significa en absoluto que CrowdStrike quede exenta de responsabilidad por el incidente ni de responsabilidad indemnizatoria.
When I use
REGEXP
I use it in my
KERNEL CODE
La tragedia y la comedia son dos caras de la misma moneda.
Vía xcancel: https://xcancel.com/singe/status/1822324795645575263
Los problemas de seguridad informática ya aparecieron durante la guerra de Vietnam, y Estados Unidos de hecho trabajó para encontrar modelos eficaces de seguridad informática. Pero vivimos en una sociedad que prácticamente borró eso de la memoria.
¿Por qué tiene que haber un escáner corriendo 24/7 sobre todo lo que una computadora intenta ejecutar?
¿Por qué el sistema operativo tiene que depender de permisos periféricos?
Culpar a CrowdStrike solo desvía la atención de fallas de diseño fundamentales que ignoramos todos los días en sistemas operativos como Linux, MacOS y Windows.
Todavía sigo culpando a Microsoft, porque no es imposible ejecutar el código que se actualiza fuera del kernel y usar el código en modo kernel solo para observar y actuar, no para la lógica.
Trabajo en IT y fui la pobre persona que justo estaba de guardia cuando Clown Strike tiró abajo la mayor parte de la infraestructura.
Personalmente, gracias a que me resistí a usar porquerías basadas en la nube, probablemente recuperamos todo en horas en lugar de días.
Me preocupa bastante que, como gente tipo directores de IT no ve esto como un problema y no toma ninguna medida para frenar estas porquerías, pronto tengamos que lidiar con otra gran caída basada en la nube.
Vengo repitiendo hasta el cansancio que “solo los idiotas dependen de computadoras ajenas”, y estoy 100% de acuerdo con eso.
Parecen creer que, si firman un contrato y pagan, lo construyen y mantienen superhumanos que, a diferencia de los ingenieros internos, no cometen errores. No entiendo esa confianza equivocada.
Con solo una parte del presupuesto anual de nube, una empresa podría construir por su cuenta una infraestructura muy estable y capaz de funcionar sin conexión.
Tal vez podrías transmitir mejor la idea si no hablaras de forma tan agresiva.
Lista de ganadores anteriores de los Pwnie Awards para comparar: https://en.wikipedia.org/wiki/Pwnie_Awards
Se puede seguir repartiendo vergüenza, pero si uno cree que este tipo de caída en producción se debió a malos procesos, Microsoft claramente también tuvo un papel importante aquí.
De verdad me pregunto cómo el CEO y el CTO siguen en sus puestos después de este desastre.
En varias ciudades el 911 no funcionaba y el flujo de los hospitales se volvió tan lento que prácticamente se detuvo, ¿pero tienen tiempo para ir a Defcon a bromear?
Advertir a la gente para que no repita los mismos errores no parece una mala forma de usar el tiempo.
Aunque probablemente la persona que lo hizo sabía que podía evitar la responsabilidad, así que supongo que no tenía motivos para preocuparse.