Hace unos días, a raíz de los ataques de ransomware “relacionados” con el producto Kaseya de gestión remota de TI, publiqué en LinkedIn una breve publicación en la que decía lo siguiente:
La cadena de suministro es el elefante en la habitación y tenemos que hablar más de ello.
Sí, hablemos un poco de prevención y dejemos la detección y gestión para otro momento. Como dice el dicho, mejor prevenir que curar. Para desarrollarlo un poco más, añadí que:
deberíamos empezar a pensar que el software y el hardware de terceros son inseguros por defecto y que se debería imponer la obligación a los fabricantes de software de realizar y publicar, hasta cierto punto, pentestings serios, regulares y profundos para las aplicaciones críticas que venden (y sus actualizaciones). E incluso entonces, cualquier software o dispositivo de terceros debería considerarse inseguro por defecto, a menos que se demuestre lo contrario.
En un comentario, Andrew (David) Worley hizo referencia a los informes SOC 2, que deberían ser capaces de prevenir mínimamente este tipo de “problemas”, y comentó un par de iniciativas que yo desconocía: el Software Bill of Materials (SBoMs) y el Digital Bill of Materials (DBoMs).
Me comprometo a hablar de ello en otro post, pero de momento sigamos.
Acerca de SOC 2 y otras evaluaciones
Conozco los informes SOC 2 y otros informes de evaluación similares, pero en mi humilde opinión, a no ser que
- lo pague un tercero (un cliente, un socio),
- lo haya hecho yo mismo o un colega que conozca bien, o
- me proporcionen la lista completa de evidencias,
tengo algunas reservas sobre ese tipo de evaluaciones. Y lo mismo para cualquier otra evaluación de control general como la ISO 27002, en lo que tengo bastante experiencia.
En primer lugar, siempre me ha parecido un poco preocupante el hecho de que una organización pague por sus informes de evaluación cuando estos tienen que servir como garantía frente a un tercero.
Y al respecto, viene muy a cuento este extracto del fabuloso paper de Ross Anderson, Why Information Security is Hard – An Economic Perspective (traducción mía):
A pesar de todos sus defectos, el Orange Book tenía la virtud de que las evaluaciones eran realizadas por la parte que confiaba en ellas: el gobierno. El equivalente europeo, el ITSEC, introdujo una innovación perniciosa: la evaluación no la pagaba el gobierno, sino el vendedor que buscaba una evaluación de su producto. Esto se trasladó a los Common Criteria. Este cambio en las normas supuso un incentivo perverso crítico. Motivó al vendedor a buscar el contratista de evaluación que le diera a su producto el mejor trato, ya sea haciendo menos preguntas, cobrando menos dinero, tardando menos tiempo o todo lo anterior. Para ser justos, el potencial de esto se hizo realidad, y se crearon esquemas por los que los contratistas podían obtener la aprobación como CLEF (instalación de evaluación con licencia comercial, commercial licensed evaluation facility). La amenaza de que a un CLEF se le retirara la licencia debía contrarrestar las presiones comerciales para recortar gastos.
Pero en ninguna de la media docena de casos controvertidos en los que he participado, el enfoque de los Common Criteria ha resultado satisfactorio. […]. Los motivos del fracaso parecen implicar una complacencia bastante directa con los deseos de los clientes, incluso (de hecho, especialmente) cuando estos estaban en conflicto con los intereses de las organizaciones para los que supuestamente se estaba preparando la evaluación.
En segundo lugar, tengo mis reservas sobre ese tipo de evaluaciones porque, por su naturaleza o por ser rentables, se quedan en la superficie, y permítanme explicarlo. Una evaluación ISO 27002 o un informe SOC 2 comprobará que la organización cuenta con un proceso de gestión de vulnerabilidades, que realiza evaluaciones de auditoría periódicas que se gestionan adecuadamente o que dispone de controles IAM, entre otros muchos controles.
Y, teniendo en cuenta el estado de la seguridad de la información en muchas organizaciones, eso es un punto de partida enorme. Pero esas evaluaciones no verán que hay un puñado de vulnerabilidades que llevan meses esperando en la cola o que hay una docena de usuarios genéricos sin que nadie se responsabilice de ellos.
Y ese esa es una gran parte del problema de la seguridad de la información. De nuevo, me viene a la mente el paper de Ross Anderson:
La guerra de la información [information warfare] se parece bastante a la guerra aérea de los años 20 y 30. El ataque es simplemente más fácil que la defensa. La defensa de un sistema de información moderno también podría compararse con la defensa de un territorio extenso y poco poblado, como el Salvaje Oeste del siglo XIX: los hombres con sombrero negro pueden atacar en cualquier lugar, mientras que los hombres con sombrero blanco tienen que defenderse en todas partes.
En resumen. Hay demasiados usuarios, aplicaciones, sistemas, portátiles, segmentos de red, vulnerabilidades, patrones de comunicación, reglas de cortafuegos, actualizaciones,… Hay demasiado de todo, demasiadas cosas que controlar. Como sabemos, el diablo está en los detalles, y eso resume el problema al que nos enfrentamos en este sector.
Sin embargo, sé que los informes de SOC 2 y la ISO 27002 son útiles y hasta cierto punto (y es imprescindible que todo el mundo conozca ese punto para que nadie vaya flotando por el océano en una placa de hielo pensando que está en tierra firme), son una buena forma de medir el estado de la ciberseguridad.
La propuesta de pentesting
Pero volvamos a la idea del pentesting que mencionaba al comienzo del post. Aunque es una idea que evidentemente requiere un cierto desarrollo (aun siendo bastante intuitivo que instalar parches sin validar no es lo más seguro), sí creo firmemente que:
- Los fabricantes de software deberían proporcionar mucha más información sobre los controles de seguridad de la información que tienen implementados para garantizar la seguridad de sus productos (y los resultados de dichos controles, siempre en un contexto de confidencialidad) y, especialmente,
- los clientes que utilicen ese software deberían realizar pruebas de seguridad exhaustivas y supervisar ese software antes de desplegarlo. En resumen, mi opinión es que, en lo que respecta al software crítico como el que fue objeto de ataque de SolarWinds o Kaseya (y cuando hablo de crítico, no me refiero a software que gestiona procesos o información crítica, sino software que tiene un elevado nivel de acceso a los datos y la infraestructura), los controles deberían ser mucho más estrictos de lo que son y mucho más finos.
De hecho, yo abogaría por un pentesting detallado y regular en el fabricante, pero principalmente (ya que estoy asumiendo que no se puede confiar en el software del fabricante), en el lado del cliente:
- un pentesting continuo automatizado del software,
- la monitorización de la aplicación en un entorno no productivo durante un periodo de tiempo razonable para identificar cualquier cambio de comportamiento, principalmente en sus patrones de comunicación, y
- un pentesting exhaustivo manual para cada nueva actualización o parche, antes evidentemente de la puesta en producción (de hecho, no recuerdo, aunque puedo estar equivocado, que el pentesting de un software sea un requisito habitual en los procedimiento de gestión de cambios, como sí puede serlo la realización de copias de seguridad). Dicho de otra forma, sin meterse en temas de reversing, pero lo más cerca que se pueda sin violar la propiedad intelectual del fabricante.
La cuestión es que eso es mucho dinero y no muchas organizaciones pueden permitírselo.
El modelo del índice de riesgo
Lo que se plantea como una posible alternativa sería un modelo de validación profundo y continuo por parte de terceros independientes y no relacionados, ni entre sí ni con el fabricante del producto analizado, que se encargarían no solo de las evaluaciones y pruebas de seguridad necesarias, sino de coordinar con los fabricantes la resolución de las vulnerabilidades. Y el trabajo de estos análisis sería pagado por los clientes de dichas aplicaciones analizadas, ya sean gobiernos o grandes empresas (y probablemente por las propias empresas de desarrollo, como beneficiarias directas en el ámbito de su ciberseguridad). El modelo económico queda fuera del ámbito de esta entrada, pero creo que se visualiza la idea.
Sí, soy consciente de que así estamos externalizando (falsamente) el riesgo de la cadena de suministro a terceros, y eso crea más problemas, así que la cuestión sería no depender de una única organización, sino de múltiples independientes entre sí, de modo que existan múltiples puntos de control, que además reduzca la posibilidad de que se establezcan dinámicas ocultas y malintencionadas entre las empresas de desarrollo y las organizaciones auditoras.
Desarrollando esto, una idea propuesta por Andrew (David) Worley sería concretar estas múltiples evaluaciones en torno a un índice numérico de riesgo, que permitiera a un tercero conocer la seguridad de un producto de software a partir de este.
Sí, esto impone una presión extra a las empresas de desarrollo, pero los dos casos que introducían esta entrada son una pequeña muestra de hacia dónde nos dirigimos si no le ponemos coto a la inseguridad que hoy en día reina en la cadena de suministro. De cualquier modo, uno tiende a pensar que un software debería distribuirse libre de puertas traseras, malware o vulnerabilidades graves.
Con un índice de ese tipo, los clientes deberían poder realizar pruebas de ciberseguridad asequibles del producto/actualización. Sé que todo esto es una fantasía con la madurez actual del desarrollo seguro de software, pero soy un gran fan de Bohemian Rhapsody de Queen.
En cierto modo, esta idea es similar a algunos controles que los navegadores y los antimalware aplican antes de descargar archivos. Es como:
Déjame comprobar esto por ti, porque no podemos confiar en la fuente, aunque te lo haya enviado tu madre.
