Una mejor junta de investigación para incidentes cibernéticos Cuando un avión se estrella, los organismos de investigación imparciales entran en acción, autorizados por ley para descubrir qué sucedió y por qué. Pero no existe un organismo tan autorizado e imparcial para investigar la actualización defectuosa de CrowdStrike que se desarrolló recientemente, enredando a bancos, aerolíneas y servicios de emergencia por una suma de miles de millones de dólares. Necesitamos uno. Para estar seguros, existe la Junta de Revisión de Seguridad Cibernética de la Casa Blanca. El 20 de marzo, la CSRB publicó un informe sobre la intrusión del verano pasado por un grupo de piratas informáticos chinos en el entorno de la nube de Microsoft, donde comprometió al Departamento de Comercio de EE. UU., el Departamento de Estado, oficinas del Congreso y varias empresas asociadas. Pero el informe de la junta, bien investigado y que contiene algunas recomendaciones buenas y prácticas, muestra cómo sufre por su falta de poder de citación y su falta de voluntad política para generalizar a partir de incidentes específicos a la industria en general. Algunos antecedentes: la CSRB se creó en 2021, por orden ejecutiva, para proporcionar un análisis y una evaluación independientes de los ciberataques importantes contra Estados Unidos. El objetivo era perforar la confidencialidad corporativa que a menudo rodea a este tipo de ataques y proporcionar a toda la comunidad de seguridad lecciones y recomendaciones. Cuanto más sepamos todos sobre lo que sucedió, mejor podremos hacerlo la próxima vez. Es el mismo pensamiento que llevó a la formación de la Junta Nacional de Seguridad del Transporte, pero para los ciberataques y no para los accidentes aéreos. Pero la junta inmediatamente no estuvo a la altura de su misión. Se fundó en respuesta al ciberataque ruso a Estados Unidos conocido como SolarWinds. Aunque se le encomendó específicamente investigar ese incidente, no lo hizo, por razones que siguen sin estar claras. Hasta ahora, la junta ha publicado tres informes. Solo ofrecían recomendaciones simplistas. En la primera investigación, sobre Log4J, la CSRB exhortó a las empresas a parchear sus sistemas más rápido y con mayor frecuencia. En el segundo informe, sobre Lapsus$, la CSRB les dijo a las organizaciones que no usaran la autenticación de dos factores basada en SMS (es vulnerable a los ataques de intercambio de SIM). Estas dos recomendaciones son higiene básica de ciberseguridad y no es algo que necesitemos que nos diga una investigación. El informe más reciente, sobre la penetración de China en Microsoft, es mucho mejor. Esta vez, la CSRB nos brindó un análisis extenso de las fallas de seguridad de Microsoft y culpó directamente a sus hombros del éxito del ataque. Sus recomendaciones también fueron más específicas y extensas, y se dirigieron específicamente a la junta y los líderes de Microsoft y a la industria en general. El informe describe cómo Microsoft dejó de rotar las claves criptográficas a principios de 2021, lo que redujo la seguridad de los sistemas afectados por el ataque. El informe sugiere que si la empresa hubiera establecido un sistema de rotación de claves automático o manual, o una forma de alertar a los equipos sobre la antigüedad de sus claves, podría haber evitado el ataque a sus sistemas. El informe también analizó cómo los competidores de Microsoft (pensemos en Google, Oracle y Amazon Web Services) manejan este problema, y ​​ofrece información sobre cómo empresas similares evitan errores. Sin embargo, todavía hay problemas, con el informe en sí y con el entorno en el que se produjo. En primer lugar, el informe público cita un gran número de fuentes anónimas. Si bien el informe culpa de la violación a la laxa cultura de seguridad de Microsoft, en realidad es bastante deferente con Microsoft; hace una mención especial a la cooperación de la empresa. Si la junta necesitaba hacer transacciones para obtener información que solo se proporcionaría si se les daba el anonimato a las personas, esto debería exponerse de manera más explícita en aras de la transparencia. Más importante aún, la junta parece tener problemas de conflicto de intereses que surgen del hecho de que los investigadores son ejecutivos corporativos y jefes de agencias gubernamentales que tienen trabajos de tiempo completo. En segundo lugar, a diferencia de la NTSB, la CSRB no tiene poder de citación. Esto se debe, al menos en parte, al temor de que los ejecutivos tecnológicos y los empleados gubernamentales en conflicto usen el poder de una manera anticompetitiva. Como resultado, la junta debe depender de la persuasión y la cooperación para su investigación de los hechos. Aunque el comunicado de prensa del DHS decía que «Microsoft cooperó plenamente con la revisión de la Junta», la próxima empresa puede no ser tan cooperativa, y no sabemos qué no se compartió con la CSRB. Una de nosotras, Tarah, testificó recientemente sobre este tema ante el Comité de Seguridad Nacional y Asuntos Gubernamentales del Senado de Estados Unidos, y los senadores que hicieron preguntas parecían realmente interesados ​​en cómo solucionar la extrema lentitud y falta de transparencia de la CSRB en los dos informes que habían emitido hasta ahora. Es una tarea difícil. El estatuto de la CSRB proviene de la Orden Ejecutiva 14208, por lo que, a diferencia de la NTSB, no tiene poder de citación. El Congreso necesita codificar la CSRB en la ley y darle el poder de citación que tan desesperadamente necesita. Además, los informes de la CSRB no proporcionan una guía útil para el futuro. Por ejemplo, el informe de Microsoft no proporciona ninguna correlación de los problemas de seguridad de la empresa con ningún estándar gubernamental que pudiera haberlos evitado. En este caso, el problema es que no existen estándares supervisados ​​por el NIST (la organización a cargo de los estándares de ciberseguridad) para la rotación de claves. Hubiera sido mejor que el informe lo hubiera dicho explícitamente. La industria de la ciberseguridad necesita estándares del NIST para darnos un piso de cumplimiento por debajo del cual cualquier organización está incumpliendo explícitamente la debida diligencia. El informe condena a Microsoft por no rotar una clave de cifrado interna durante siete años, cuando su estándar interno era de cuatro años. Sin embargo, durante los últimos años, la rotación automática de claves más del orden de una vez al mes o incluso con mayor frecuencia se ha convertido en la pauta esperada de la industria. Sin embargo, una pauta no es un estándar o una regulación. Es solo una sugerencia enérgica. En este caso específico, el informe no ofrece orientación sobre la frecuencia con la que se deben rotar las claves. En esencia, el informe de CSRB dijo que Microsoft debería sentirse muy mal por el hecho de que no rotaron sus claves con mayor frecuencia, pero no explicó la lógica, no dio una línea base real de la frecuencia con la que se deben rotar las claves ni proporcionó datos estadísticos o de encuestas para respaldar por qué ese cronograma es apropiado. La rotación automática de certificados, como la que ofrece el servicio público gratuito Let’s Encrypt, ha revolucionado las comunicaciones cifradas por defecto, y las expectativas en la industria de la ciberseguridad han aumentado en consonancia. Lamentablemente, el informe solo analiza las claves propietarias de Microsoft por nombre de marca, en lugar de tener un debate más amplio sobre por qué existe la infraestructura de clave pública o cuáles deberían ser las mejores prácticas. En términos más generales, debido a que los informes de la CSRB hasta ahora no han logrado generalizar sus hallazgos con una investigación transparente y exhaustiva que proporcione estándares y expectativas reales para la industria de la ciberseguridad, nosotros (los responsables de las políticas, los líderes de la industria, el público estadounidense) nos encontramos llenando los vacíos. Los expertos individuales tienen que proporcionar interpretaciones anecdóticas e individualizadas de lo que sus investigaciones podrían implicar para las empresas que simplemente intentan aprender cuáles son sus verdaderas responsabilidades de diligencia debida. Es como si nadie estuviera seguro de si hervir el agua potable o clavar una herradura sobre la puerta es estadísticamente más probable que reduzca la incidencia del cólera. Claro, muchos de nosotros pensamos que hervir el agua es probablemente lo mejor, pero nadie lo está diciendo con ciencia real. Nadie dice cuánto tiempo hay que hervir el agua o si hay fuentes de agua que sean más propensas a transmitir enfermedades. Y hasta que haya cifras reales y estándares generales, nuestras opiniones informadas están en pie de igualdad con las herraduras y la esperanza. No debería ser tarea de los expertos en ciberseguridad, ni siquiera de nosotros, generar lecciones a partir de los informes de la CSRB basados ​​en nuestras propias opiniones. Por eso seguimos pidiendo a la CSRB que proporcione estándares generalizables que se basen en la estandarización del NIST o exijan su aplicación. Queremos informes descriptivos y prescriptivos de los incidentes: véase, por ejemplo, el informe de la GAO del Reino Unido sobre el ransomware WannaCry, que sigue siendo un estándar de oro de los informes de investigación de incidentes de ciberseguridad del gobierno. Necesitamos y merecemos más que anécdotas puntuales sobre cómo una empresa no hizo bien la seguridad y debería hacerlo mejor en el futuro. Empecemos a tratar la ciberseguridad como el equivalente a la seguridad pública y aprendamos algunas lecciones reales. Etiquetas: seguridad informática, ciberseguridad, piratería Publicado el 6 de agosto de 2024 a las 7:01 AM • 0 Comentarios