¿Cómo evitar que el código se filtre fuera del trabajo? [duplicar]

Esta es una de las situaciones en las que está buscando una solución técnica para un problema social .

Un problema social debe requerir una solución social, que, en este caso, toma dos formas complementarias y una solución organizativa adicional que puede ayudar:

• Confianza. Si no confías en los desarrolladores, no los contrates. Trabajar con gente en la que no confías es sinónimo de fracaso. Las relaciones basadas en la desconfianza requieren mucho formalismo, lo que puede afectar gravemente no solo la productividad de sus empleados, sino también la cantidad de personas listas para trabajar con usted. Es probable que los mejores desarrolladores eviten su empresa a toda costa.

• NDA. Confiar en alguien no significa que no debas tomar precauciones legales. Esas precauciones pueden tomar la forma de un contrato o una cláusula NDA con graves consecuencias para el empleado en el caso de una divulgación.

  La gravedad de las consecuencias depende de quién eres. Las organizaciones gubernamentales, los terroristas o la mafia pueden permitir algunos disuasivos. Las empresas ordinarias pueden estar limitadas, por ley, solo a las financieras.

• Rebanar. La confianza y los contratos son un buen comienzo, pero podemos hacerlo mejor. Si la parte sensible del código base se puede dividir para que se requieran dos o más partes para que funcione el producto, asegúrese de que el desarrollador del departamento 1 nunca vea el código fuente desarrollado en el departamento 2 y viceversa.

  Las personas de un departamento no deberían poder conocer a personas de otros departamentos, e idealmente, ni siquiera deberían poder adivinar qué están haciendo otros departamentos, ni cuántos departamentos hay. Cada persona conoce solo una pequeña parte, lo cual no es suficiente para tener una imagen completa (y reconstruir un producto completo fuera de la organización).

Esas eran medidas sociales y organizativas.

Ahora, técnicamente hablando, no hay nada que puedas hacer.

Puedes intentar:

• Obligue a los desarrolladores a trabajar en una habitación cerrada en una máquina que no está conectada a Internet y no tiene puertos USB.

• Instale cámaras que monitoreen todo lo que sucede en la sala, con varios oficiales de seguridad observando constantemente a los desarrolladores que trabajan.

• Realice una búsqueda de separación en cada desarrollador cada vez que abandone la sala para asegurarse de que no tenga ningún dispositivo electrónico que pueda contener el código.

• Requiera que todos los desarrolladores tengan un monitor de tobillo. El dispositivo escuchará lo que dicen, registrará su posición e intentará detectar cualquier dispositivo electrónico cercano. Si el desarrollador estaba cerca de un dispositivo que no está identificado y no tiene instalado su software de seguimiento, los investigadores privados y los piratas informáticos pueden intentar verificar si el desarrollador no estaba usando el dispositivo para filtrar información.

• Prohibir a los desarrolladores que abandonen sus edificios, a menos que estén bajo una vigilancia estricta, y que interactúen de alguna manera con el mundo exterior.

Algunas o todas esas medidas son ilegales en muchos países (a menos que represente a agencias gubernamentales ), pero la peor parte es que incluso con todas esas medidas implementadas, los desarrolladores podrán obtener el código, por ejemplo, escribiéndolo discretamente en su piel o en un pedazo de papel y escondiéndolo en su ropa, o simplemente memorizándolo si tienen Memoria eidética .

O simplemente pueden memorizar globalmente las estructuras de datos y los algoritmos, que es lo único importante en lo que respecta a la propiedad intelectual, y crear su propio producto inspirado en esas dos cosas.

1. Haz que firmen un acuerdo de confidencialidad.

2. Solo contrate personas de confianza.

3. Compartimentalice su base de código. Use la inyección de dependencia para que pueda darles requisitos que, cuando terminen, las clases resultantes encajarán en la arquitectura existente, pero no tendrán Acceso al "cuadro completo", solo piezas sueltas. Solo las personas mayores y de confianza tendrían autorización para el "pegamento arquitectónico" que hace que todo funcione como un todo completo.

Me encanta la idea de que podría haber una idea "inteligente" de que "nosotros" como desarrolladores nos desconcertaría. Dado que cada herramienta de desarrollador escrita fue escrita por un desarrollador y todo eso.

El mayor problema de tu jefe es la ingenuidad con una pizca de paranoia. Estoy siendo educado allí. Realmente muy educado.

Si realmente desea una lista de compras de cosas para mantener su código de propietario, simplemente implemente lo siguiente:

1. Desactive el USB y otras IO en todas las computadoras de la compañía. Esto se puede hacer a través de la mayoría de los antivirus empresariales o similares.

2. Todas las máquinas desarrolladoras serán escritorios o torres. No hay computadoras portátiles.

3. No permita que ninguna máquina se conecte a Internet. No web, ftp, correo electrónico, mensajería instantánea, no internet. Cortar los cables.

4. No hay acceso / trabajo remoto (no cubierto por Internet, pero alguna chispa inteligente podría sugerir una VPN)

5. No se deben llevar teléfonos móviles ni otros dispositivos electrónicos a la sala de "desarrollo" seguro.

6. Configure todas las impresoras para imprimir una marca de agua visible grande en cada página, al frente y atrás.

7. la bolsa busca tanto dentro como fuera. Busque notas escritas a mano, cualquier cosa impresa en las impresoras de la empresa (cualquier cosa, ¡pueden tener código oculto en una imagen con esteganografía!). Cualquier dispositivo eléctrico o electrónico. De hecho, probablemente lo mejor sea asegurarse de que las bolsas se mantengan fuera del área segura y los desarrolladores deben usar trajes limpios, el tipo de cosas que verías en las tiendas de drogas y plantas de fabricación de chips.

8. Los servidores deben estar igualmente aislados, las copias de seguridad deben estar encriptadas y solo su jefe debe saber la contraseña para restaurarlas.

Si no se puede confiar en que las personas en cuestión cumplan con sus contratos de trabajo, entonces él no debe contratarlos.

Si él cree que NO se puede confiar en UNO, entonces está siendo demasiado paranoico, y en última instancia va a dañar a la compañía si lo mantiene.

En algún momento DEBES confiar en tus empleados. No es realmente una opción para hacer lo contrario. Si no confía en sus empleados en absoluto, entonces no es posible que sean efectivos, porque está perdiendo demasiado tiempo en desconfiar de ellos y está perdiendo mucho tiempo saltando a través de aros debido a problemas de confianza.

Además, cuando le dejas en claro a las personas que no confías en ellas, tienden a molestarse. Y los programadores enojados finalmente encuentran otro trabajo donde no son tratados de esa manera.

La solución correcta es una verificación de antecedentes básica, un acuerdo de empleo bien pensado y algo de confianza.

Solía escribir código para sistemas informáticos clasificados. Tenían todo tipo de aros ridículos para saltar para mantenerlo en secreto. Por ejemplo, no se nos permitió llevar CD de música a ciertas habitaciones porque podrían ser CD-RW disfrazados.

La cuestión es que los aspectos prácticos del trabajo abren agujeros de seguridad por necesidad. A veces, tenía para transportar datos / códigos no clasificados dentro o fuera de un área clasificada para realizar el trabajo. Sí, también había reglas y procedimientos para eso, pero todos eventualmente se redujeron a confiar en la gente. En lugar de confiar en que las personas no coloquen datos clasificados en un conveniente dispositivo USB, simplemente confían en las mismas personas para que superen todos los obstáculos de seguridad.

En otras palabras, hay muchas cosas que puedes hacer para protegerte de extraños, pero una vez que los dejas entrar, es solo una cuestión de cuánto quieres molestarlos.

En resumen , debe tener un acuerdo / contrato de no divulgación con los empleados que está contratando. Además de este acuerdo firmado, contrate desarrolladores en los que puede confiar .

Desde el punto de vista técnico, ese código puede copiarse fácilmente al dispositivo y reutilizarse en otro lugar. Lo que su jefe no quiere es el acceso de sus competidores a este código. Solo puede hacer cumplir dichas políticas a través de contratos de trabajo o sociedad.

Otra cosa que puede funcionar es proporcionar capacitación sobre la sensibilidad de la información , cómo se debe alertar a cada empleado cuando se viola la confidencialidad de la información. Además, el seguimiento de las actividades informáticas dentro de la red de su oficina también aumentará el nivel de advertencia.

Se realiza una capacitación similar para los empleados que trabajan con Información relacionada con la PHI .

Sin embargo, lograr que una gente de confianza se incorpore y brindar capacitación sobre cómo proteger esta información puede ser la mejor manera de hacerlo.

¿Viste Paycheck con Ben Affleck? Creo que esa es la única manera de garantizar que su IP no sea "robada". Puedo decirles que gracias a mi memoria, pude recrear casi todos los sistemas en los que he trabajado durante un tiempo significativo. Si no fuera una recreación línea por línea, podría producir los elementos significativos y probablemente mejorarlos en el proceso debido a la forma en que mis habilidades han crecido con los años.

Simple y simple, solo hay dos cosas que puedes lograr al "bloquear" tu código:

1. Rechazará a los buenos desarrolladores que se ofendan por su evidente falta de confianza
2. Levantará una gran bandera grande que tienta a los desarrolladores más inescrupulosos

Si crees que tu software es tan novedoso y sorprendente, obtén una patente.

1. No puedes evitar que el código se filtre. Puede limitar la fuga a un código menos importante.
2. Normalmente, solo hay una parte de la aplicación que la hace única. Eso sería algún algoritmo. Puede conectar esto muy bien y colocarlo en una rama de control de fuente separada. Usted y solo aquellas personas que necesitan trabajar en él deben tener acceso a él. Usted proporciona solo un binario (ofuscado) y la interfaz a los otros desarrolladores.
3. Divida su código en más módulos y deje que las personas solo trabajen en un módulo en particular. Los otros módulos se proporcionan en binario (ofuscado). Esto, sin embargo, se puede estirar demasiado para que sea inmanejable y puede llevar a la duplicación de código.

Conozco a alguien que trabajó en un entorno como este.

Algunas medidas que se tomaron allí:

1. Sin acceso a la computadora física, todas las computadoras se almacenaron en una habitación cerrada con agujeros en la pared para la pantalla, el teclado y el mouse.

2. No hay acceso a internet.

3. Sistema operativo personalizado que utiliza un sistema de archivos interno con cifrado (en caso de que una computadora fuera robada de alguna manera).

4. Los proyectos se dividieron en bibliotecas estáticas, nadie tuvo acceso a todo el código fuente (esto por supuesto no se aplica a todos los lenguajes de programación).

5. Era un lugar de trabajo muy desagradable.

Tenga cuidado de no sobreestimar el valor de su código fuente a los que están fuera de su empresa.

Claro: pagaste a muchos ingenieros (desarrolladores, control de calidad, etc.) mucho dinero para desarrollarlo, pero eso no significa que sea intrínsecamente valioso para un tercero.

¿Qué ataques exactos existen?

El código fuente a menudo se filtra desde (por ejemplo) el desarrollo de juegos o las compañías de seguridad de TI. Por supuesto, estas fugas hacen que se vean mal, pero de lo contrario, no causan ningún daño real.

Pregúntate a ti mismo:

• ¿Está tan avergonzado por la calidad de su código fuente que dañaría su reputación si se filtra?
• ¿El código fuente contiene secretos confidenciales (por ejemplo, claves de cifrado codificadas, detalles de relaciones financieras con otras compañías)? ¿Deberia?
• ¿Puede un competidor realmente beneficiarse con el uso de su código fuente, a pesar del riesgo de ser descubierto?

Por lo que sé, hubo un caso en el que un miembro del personal de una empresa de seguridad de TI intentó vender el código fuente a un competidor. El competidor inmediatamente reportó esto a su empleador, y pronto fue despedido. Ningún dinero cambió de manos, pero el miembro del personal ya no puede trabajar fácilmente en la industria de la seguridad de TI.

Debes confiar, pero a veces es mejor monitorear las infracciones. Por ejemplo, si su código se ejecuta, podría llamar a alguna dirección IP en Internet cada vez que se ejecute, registrando la dirección IP, la información de la computadora, tal vez incluso la ubicación geográfica de donde se ejecuta. Revise ese registro para buscar problemas.

Por supuesto, hay maneras de solucionarlo, y los desarrolladores podrían simplemente mirar el código, no ejecutarlo.

Puede configurar su firewall para realizar la inspección de paquetes con algo como Snort que podría a) bloquear la conexión inmediatamente si lo detecta, por ejemplo. su aviso de derechos de autor, y b) informe a la administración para su seguimiento. Para poder evitar SSL y HTTPS, debería estar ejecutando un proxy HTTPS en su firewall.

Tal vez podría tener una utilidad del sistema en cada PC que verifique los archivos o las frases clave de las unidades externas y las unidades flash USB mientras están enchufadas. También puede desactivar / prohibir las unidades externas (escuché que el Departamento de Defensa de los EE. UU. hace esto ). Tendría que exigir que usen su hardware y no traer ningún hardware desde su casa.

Probablemente hay programas disponibles que registrarán todo lo que alguien hace con una computadora. Simplemente programe auditorías aleatorias de estos registros y asegúrese de que los desarrolladores conozcan esta capacidad.

Una vez que hayas encontrado una infracción, golpea al desarrollador en la cabeza con el NDA que firmaron.

Una solución técnica podría ser tener todas las sesiones de desarrollo alojadas en un servidor sin acceso a la red (o severamente restringido y monitoreado) más allá de lo requerido para atender las sesiones de RDP (o VNC). De esa manera, la fuente nunca está en la máquina de un desarrollador. También permitiría trabajar desde casa o desde un sitio cliente.

Sin embargo, en última instancia, creo que toda la situación está madura para el fracaso. Si le hace obvio a los desarrolladores que no confía en ellos y les dificulta el trabajo, en mi humilde opinión está creando un entorno donde los desarrolladores encontrarán alguna forma de hacer pública la fuente, solo para "pegalo al hombre".