Base para "confiar" en el código y servicios de terceros

Question

Base para "confiar" en el código y servicios de terceros

#1 de Ohnana (3 votos)

1

Recuerdo haber leído un artículo que menciona que los servicios y el código de terceros no deberían ser confiables, es decir, confianza ciega.
Por lo tanto, estaba pensando que todos usan códigos de terceros en el desarrollo diario de software, incluso compañías de seguridad de TI de alto perfil, y algunos de nosotros damos por sentado que el código que acaban de usar es confiable, es decir, seguro y probado.

Preguntas :

¿Cuál es la base para confiar en el código y los servicios de terceros en el desarrollo de software?
¿Qué medidas toman las empresas de seguridad de TI antes de otorgar esa confianza?
¿Qué medidas toman las empresas de seguridad de TI para mantener esa confianza?

Tanto de código abierto como de código cerrado.

Por ejemplo, piensa en:

La empresa de alojamiento web para hospedar su aplicación y los datos de su cliente
El software que no escribiste pero con el que trabajas.

¡Gracias!

audit trust software web-service

pregunta HassenPy 16.12.2015 - 16:24

fuente

1 respuesta

Lea otras preguntas en las etiquetas audit trust software web-service

¿Los protocolos de fax T4 y / o T30 son seguros / encriptados? ¿Cómo cambiar el cifrado SSL predeterminado / preferido en Linux?

score 3 · Accepted Answer

Recientemente trabajé para una organización que usaba software de terceros. Aquí está nuestro proceso de pensamiento.

Hay fuerza en los números. Software de terceros que es A) de código abierto, B) tiene un equipo de seguridad dedicado y bien informado, C) tiene una política de divulgación responsable y D) es ampliamente utilizado por miles de clientes es mejor que cualquier cosa que nuestra organización pueda publicar.
Hay fuerza para hacer el trabajo de piernas. Me asignaron todos los módulos de este software de terceros e hice una revisión completa antes de permitir que se agregara a nuestra infraestructura. Y si encontramos una vulnerabilidad, utilizamos el programa de divulgación responsable para mejorar el software.
Hay fuerza en la actualización. Nos suscribimos a las alertas de los proveedores para asegurarnos de que, si alguien más encontraba algo, pudiéramos responder al incidente y proteger nuestra infraestructura.

Por supuesto, también hay puntos débiles en este enfoque:

Hay debilidad en el software homogéneo. Si surgió un gran exploit, es muy probable que alguien encuentre nuestro sitio e intente un exploit de apuntar y disparar.
Hay debilidad en los números. Hicimos una revisión completa, pero ¿los otros miles de personas lo usaron? Probablemente no.
Hay debilidad en el trabajo voluntario. Si algo sucediera, no había ningún representante del vendedor con quien hablar. Tuvimos que A) desandar el problema y B) solucionarlo antes de que nos golpearan.
Hay debilidad en el control de calidad. El código abierto tiene que ver con la contribución de la comunidad. Sin embargo, la primera ley de los humanos es que los humanos son estúpidos, y ningún lenguaje es una prueba estúpida. Especialmente PHP, que es en lo que se escribió el software.

Al igual que con todas las políticas de seguridad, debe tener en cuenta los riesgos y minimizar los riesgos donde pueda. La única forma de reducir su riesgo a cero es escribir en tabletas de cera a la luz de las velas.