Indagamos por diferentes foros para así mostrarte la respuesta a tu duda, en caso de dificultades deja la duda y respondemos con gusto.
Solución:
En primer lugar, quiero decir que el hecho de que una empresa sea grande no significa que su seguridad sea mejor.
Dicho esto, mencionaré que habiendo realizado trabajos de seguridad en una gran cantidad de compañías Fortune 500, incluidas muchas marcas conocidas que la mayoría de la gente conoce, diré que actualmente el 60-70% de ellas no lo hacen como por mucho que creas que deberían hacer. Algunos incluso dan a cientos de empresas de terceros en todo el mundo acceso completo para extraer de su código base, pero no necesariamente escribir en él.
Algunos usan múltiples repositorios privados de Github para proyectos separados con autenticación de dos factores habilitada y un control estricto sobre a quién otorgan acceso y tienen un proceso para revocar rápidamente el acceso cuando alguien se va.
Algunos otros se toman muy en serio la protección de las cosas, por lo que hacen todo en casa y utilizan lo que para muchas otras empresas parecerían niveles excesivos de control de seguridad y supervisión de los empleados. Estas empresas utilizan soluciones como herramientas de prevención de pérdida de datos (DLP) para vigilar la exfiltración de código, el acceso VPN interno a entornos muy reforzados solo para el desarrollo con una tonelada de controles de seguridad y supervisión tradicionales y, en algunos casos, la captura de paquetes completos de todos. tráfico en el entorno donde se almacena el código. Pero a partir de 2015 esta situación sigue siendo muy rara.
Algo que puede ser de interés y que siempre me ha parecido inusual es que la industria financiera, especialmente los bancos, tiene una seguridad mucho peor de lo que uno pensaría y que la industria farmacéutica es mucho mejor que otras industrias, incluidos muchos contratistas de defensa. Hay algunas industrias que son absolutamente horribles con respecto a la seguridad. Menciono esto porque hay otras dinámicas en juego: no se trata solo de grandes empresas versus pequeñas, una gran parte tiene que ver con la cultura organizacional.
Para responder a su pregunta, voy a señalar que es el negocio en general quien toma estas decisiones y no los equipos de seguridad. Si los equipos de seguridad estuvieran a cargo de todo, o incluso supieran de todos los proyectos en curso, es probable que las cosas no se parezcan en nada a lo que son hoy.
Dicho esto, debe tener en cuenta que la mayoría de las grandes empresas cotizan en bolsa y, por varias razones, tienden a estar mucho más preocupadas por las ganancias a corto plazo, por cumplir con las cifras trimestrales y por competir por la participación de mercado contra sus otros grandes competidores que por los riesgos de seguridad. , incluso si los riesgos pudieran destruir efectivamente su negocio. Así que tenlo en cuenta al leer las siguientes respuestas.
-
Si el código fuente fue robado:
-
A la mayoría no les importaría y casi no tendría impacto en su marca o ventas. Tenga en cuenta que, en muchos casos, el código en sí no es lo que almacena el valor de la oferta de una empresa. Si alguien más obtuviera una copia de la fuente de Windows 10, no podría crear de repente una empresa que venda un sistema operativo clonado de Windows 10 y poder respaldarlo. El código en sí es solo una parte de la solución vendida.
-
¿El producto correría un mayor riesgo debido a esto? Si, absolutamente.
-
-
Modificación externa: Sí, pero es más difícil de hacer y más fácil de detectar. Dicho esto, dado que la mayoría de las empresas no están monitoreando seriamente esto, es una posibilidad muy real que esto les haya sucedido a muchas empresas grandes, especialmente si el acceso por la puerta trasera a su software es de valor significativo para otros estados-nación. Esto probablemente sucede con mucha más frecuencia de lo que la gente cree.
-
Atacante interno: Dependiendo de qué tan inteligente sea el atacante, es posible que esto nunca se note o que parezca un error de programación discreto. Fuera de las verificaciones de antecedentes y el monitoreo del comportamiento, no hay mucho que pueda prevenir esto, pero es de esperar que algunas herramientas de análisis de código fuente capten esto y obliguen al equipo a corregirlo. Este es un ataque particularmente difícil contra el que defenderse y es la razón por la que algunas empresas no subcontratan el trabajo a otros países y realizan verificaciones de antecedentes exhaustivas de sus desarrolladores. Las herramientas de análisis de código fuente estático están mejorando, pero siempre habrá una brecha entre lo que pueden detectar y lo que se puede hacer.
En pocas palabras, los agujeros siempre saldrán antes de las correcciones, por lo que lidiar con la mayoría de los problemas de seguridad se convierte en una especie de carrera contra el tiempo. Las herramientas de seguridad ayudan a compensar el tiempo, pero nunca tendrá una seguridad “perfecta” y acercarse a eso puede resultar muy costoso en términos de tiempo (ralentiza a los desarrolladores o requiere muchas más horas de trabajo en otro lugar).
Una vez más, el hecho de que una empresa sea grande no significa que tenga una buena seguridad. He visto algunas pequeñas empresas con mucho mejor seguridad que sus competidores más grandes, y creo que este será cada vez más el caso, ya que las empresas más pequeñas que quieren tomar su seguridad más en serio no tienen que hacer cambios organizativos masivos, donde las empresas más grandes se verán obligadas a seguir con la forma en que ‘ He estado haciendo cosas en el pasado debido al costo de transición.
Más importante aún, creo que es más fácil para una empresa nueva (de cualquier tamaño, pero especialmente para las más pequeñas) tener la seguridad fuertemente integrada en su cultura central en lugar de tener que cambiar sus culturas actuales / heredadas como tienen que hacerlo las empresas más antiguas. Incluso puede haber oportunidades ahora para quitarle participación de mercado a un producto menos seguro creando una versión muy segura del mismo. Del mismo modo, creo que su pregunta es importante por una razón totalmente diferente: la seguridad aún está en su infancia, por lo que necesitamos mejores soluciones en áreas como la administración de código, donde hay mucho margen de mejora.
Descargo de responsabilidad: Trabajo para una empresa muy grande que hace un buen trabajo en esta área, pero mi respuesta es mi propia opinión personal y no es indicativa de la posición o las políticas de mi empleador.
En primer lugar, cómo proteger el código para que no se filtre:
- Seguridad de la red: Esta es la más obvia: si los piratas informáticos chinos obtienen credenciales en sus sistemas internos, buscarán su código fuente (aunque solo sea por el hecho de que el código fuente les dirá a dónde ir a continuación). Por lo tanto, la seguridad informática básica tiene que ser un “hecho”.
- Control de acceso: ¿Su recepcionista necesita acceso a su repositorio de códigos? Probablemente no. Limite su exposición.
- Sea selectivo al contratar y mantenga un ambiente de trabajo saludable: Las medidas de DLP como escanear el correo electrónico saliente son ingeniosas en teoría, pero si su ingeniero es lo suficientemente inteligente como para serle de alguna utilidad, son lo suficientemente inteligentes como para descubrir cómo eludir sus medidas de DLP. Tus empleados no debería tener una razón para filtrar su código fuente. Si lo hacen, ha hecho algo horrible, horriblemente mal.
- Supervise su red: Esta es una extensión de la respuesta de “seguridad de la red” pero con un énfasis en la prevención de pérdidas digitales. Si ve un aumento repentino en el tráfico de DNS, ese puede ser su código fuente exfiltrado por un atacante. Bien, ahora pregúntese si incluso saber si hubo un aumento repentino en el tráfico de DNS de su red. Probablemente no.
- Trate los dispositivos móviles de manera diferente: Los teléfonos y las computadoras portátiles se pierden De Verdad a menudo. También los roban De Verdad a menudo. Nunca debe almacenar información confidencial (incluido el código fuente, los datos del cliente y los secretos comerciales) en dispositivos móviles. Seriamente. Nunca. Eso no significa que no pueda usar dispositivos móviles para acceder y editar el código fuente. Pero si una computadora portátil se pierde, debería poder revocar de forma remota cualquier acceso que tenga la computadora portátil a los datos confidenciales. Normalmente, eso significa que el código y los documentos se editan “en la nube” (consulte c9.io, koding.com, Google Docs, etc.) con la autenticación adecuada y todo eso. Esto se puede hacer con o sin confiar en un tercero, dependiendo de la cantidad de trabajo que desee realizar. Si su solución no es compatible con 2 factores, elija otra solución; tú quieres reducir su exposición con esta medida, no incrementar eso.
En segundo lugar, cómo evitar la modificación de códigos maliciosos; Realmente solo hay una respuesta a esta pregunta: control de cambios.
Para cada carácter de código en su repositorio, debe saber exactamente quién agregó (o eliminó) ese código y cuándo. Esto es tan fácil de hacer con la tecnología actual que es casi más difícil no tener el seguimiento de cambios en su lugar. Si usa Git o Mercurial o cualquier sistema de control de fuente modestamente utilizable, obtiene un seguimiento de cambios y depende en gran medida de él.
Pero para aumentar un poco la confiabilidad, agregaría que cada cambio en su repositorio debe ser firmado por al menos otra persona además del autor que envía el cambio. Herramientas como Gerrit pueden simplificar esto. Muchos regímenes de certificación requieren revisiones de código de todos modos, por lo que hacer cumplir esas revisiones en el momento del registro significa que los actores malintencionados no pueden actuar solos para obtener código incorrecto en su repositorio, ayuda a evitar que se comprometa código mal escrito y ayuda a garantizar que al menos 2 la gente comprende cada cambio enviado.
Habrá medidas para prevenir la accidental inserción de código problemático, también conocido como errores. Algunos de estos también ayudarán contra la inserción deliberada de código problemático.
- Cuando un desarrollador quiere enviar código al repositorio, otro desarrollador tiene que examinar esta solicitud de fusión. Quizás se requiera que el segundo desarrollador explique al primer desarrollador lo que hace el nuevo código. Eso significa repasar cada línea.
- Si el código parece confuso, es posible que se rechace como de mal estilo y no se pueda mantener.
- El código tiene pruebas unitarias y de integración automatizadas. Cuando no hay una prueba para una determinada línea de código, la gente se pregunta. Así que tendría que haber una prueba de que la puerta trasera funciona, o algún tipo de ofuscación.
- Cuando se crea una nueva versión del software, los desarrolladores y el control de calidad verifican qué confirmaciones son parte de la compilación y por qué. Cada compromiso debe tener un propósito documentado.
- El software se crea y se implementa mediante scripts automatizados. Eso no es solo por seguridad, sino también para simplificar la carga de trabajo.
Por supuesto, estas medidas dependen de la honestidad y la buena voluntad de todos los participantes. Alguien con acceso de administrador al servidor de compilación o al repositorio podría causar muchos estragos. Por otro lado, los programadores ordinarios no necesitan este tipo de acceso.
Puedes añadir valor a nuestra información colaborando tu experiencia en las críticas.