Me interesa saber qué amenazas presenta, si se filtra el código fuente de una suite de seguridad. Me vino a la mente después de leer las siguientes URL:
¿Cuál sería la amenaza si el código fuente estuviera actualizado y cómo podemos asegurarnos de que al usar dicho producto, la seguridad se encuentra en su riesgo mínimo (en comparación con la situación en la que no se filtra ningún código fuente)? .
Es posible que exista un potencial de amenaza a corto plazo, ya que puede garantizar que los atacantes rastrearán el código para encontrar puntos débiles, sin embargo, también habrá un número de sombreros blancos que hacen lo mismo, así como equipos de revisión de código de las organizaciones. que utilizan Kaspersky, por lo que es probable que se encuentren problemas, pero es probable que el resultado final sea una base de código más segura de lo que podría haber sido el caso.
Muchos ojos, y todo eso.
Sin embargo, el riesgo relativo es difícil de estimar, ya que es muy probable que los atacantes ya hayan sido de ingeniería inversa y diseccionen el código AV de todos modos, por lo que en este caso la adición de los buenos al grupo de revisión podría reducir el riesgo. .
¿No es esta la vieja pregunta de si el código abierto reduce la seguridad o no? La teoría popular entre los profesionales de la seguridad al menos es que si confía en que no se acceda a su código para proporcionar seguridad, todo lo que tiene es seguridad por oscuridad. Esta es la razón por la que los únicos algoritmos de cifrado de confianza son aquellos en los que el código ha sido abierto y analizado exhaustivamente por un gran número de personas durante varios años. No veo realmente por qué el software de seguridad en este caso Kapensky debería ser diferente.
Dicho esto, hice el siguiente punto en mi publicación en código abierto:
Incluso la metodología de calificación de riesgo de OWASP tiene facilidad de detección y facilidad de explotación como factores de vulnerabilidad que aumentan el riesgo general. Estoy seguro de que las empresas tienen muchos códigos de mainframe y vulnerabilidades de seguridad, pero cuando calculas el puntaje de riesgo, tiene que ser inferior a la vulnerabilidad de scripts entre sitios existente en el último CMS de código abierto que acabas de descargar. Ahora puede ver que esta es una daga que se cierne sobre su cabeza, solo es cuestión de tiempo antes de que alguien la encuentre y la explote (por ejemplo, Stuxnet y SCADA). Una visión alternativa es que con recursos limitados, construir una defensa en profundidad con controles de seguridad y mantener el código fuente confidencial es una estrategia legítima de mitigación de riesgos.
Es muy probable que el efecto sea mínimo de cualquier manera.
Ciertamente, si la seguridad de su sistema depende fundamentalmente del secreto del código, entonces este es un problema en sí mismo. No olvide que, de todos modos, hay herramientas para producir automáticamente el código fuente a partir de imágenes compiladas, y también hay personas que pueden descompilar el código de máquina a lenguajes de alto nivel tan rápido como pueden escribir.
Creo que el principal riesgo que enfrentan en tales eventos es un riesgo comercial: la compañía percibe que su código fuente es el activo que le da una ventaja sobre sus competidores, solo que ahora los competidores tienen igual acceso a ese activo. En segundo lugar, obviamente hay daños en la reputación de la empresa: ¿una empresa de seguridad que ni siquiera puede asegurar sus propios procesos de negocios?
Sí, también es probable que existan vulnerabilidades que pueden descubrirse más fácilmente con el acceso a la fuente, pero el principal daño es para la empresa. Como otros lo han indicado, encontrar una vulnerabilidad es un poder que puede usarse tanto para el bien como para el mal.
Un punto importante aquí ... solo porque el código fuente está "filtrado" no significa que sea comparable a Free / Open Source. Si en realidad se filtró (es decir, se diseminó ilegalmente y aún está cubierto por patentes, derechos de autor, NDA, etc.), existe un motivo legal cuestionable para que los buenos lo auditen. En mi opinión, una vez que se filtre, los propietarios / autores deben al menos aceptar legalmente no procesar / demandar a cualquiera que audite el código ahora público.
Soy un administrador de sistemas / desarrollador, que trata casi exclusivamente con código abierto, y paso un poco de mi tiempo en el código que ejecutamos. En cuanto a la pregunta de código abierto que se ha planteado aquí, todos sabemos que los atacantes están ocupados probando y descompilando software propietario. Tiene sentido permitir también que los buenos vean. Si no fuera por otra razón, preferiría que todos recibieran alertas sobre una vulnerabilidad (de manera responsable y con suerte) que los atacantes se enteren hasta que el proveedor decida divulgarla.
Lea otras preguntas en las etiquetas data-leakage source-code disclosure incident-response