Ayuda para tener en cuenta todos los puntos de acceso físico a un servidor en rack para robar software

Su atacante tiene acceso físico a la máquina y puede iniciarla bajo un sistema operativo bajo su control o montar la unidad en otra máquina. Por lo tanto, necesita seguridad que se proporcione, al menos en parte, fuera del almacenamiento de la máquina, de una manera que sea algo resistente a la manipulación física.

Este es un caso de uso típico para un Trusted Platform Module (TPM) . El TPM es un chip adicional en su placa base un tanto resistente a la manipulación (no para un laboratorio bien equipado, ni para un individuo experto con un poco de equipo electrónico, sino para una persona informal equipada con nada más que un destornillador y un USB pegada) y a prueba de manipulaciones (puede ser derrotada arrancándola de la placa base e insertando un chip activo entre el TPM y el resto de la placa base, pero sería difícil volver a soldarlo sin dejar rastro). El TPM puede almacenar claves secretas que nunca se le escapan y puede realizar operaciones criptográficas con estas claves. En particular:

• El TPM puede monitorear el estado de la plataforma y un informe sobre la integridad de la plataforma .
• El TPM puede almacenar una clave de cifrado del disco , que le permite usar encriptación completa del disco para que su disco no se pueda montar de manera útil en otra máquina.

Un TPM no es una bala mágica. Debe configurarse correctamente y, en general, toda la plataforma debe configurarse correctamente. Un TPM no es bueno si el atacante puede conectar un teclado y obtener acceso a la consola debido a una cuenta protegida de forma incorrecta o porque la BIOS permite el arranque desde un disco que no sea el suyo.

Otro ataque que un TPM no evitará es en la RAM. Por ejemplo, el atacante podría intentar un ataque de intercambio en caliente en la RAM y leer su contenido. Por lo tanto, necesitarías un caso resistente a la manipulación indebida, o al menos una prueba de manipulación indebida.

Si usa un TPM de esta manera, no olvide hacer una copia de seguridad de todas las llaves maestras del TPM antes de enviar la caja, ya que sus datos se perderían sin ellos.

Dada la forma en que presentas tu situación, sospecho que

• o bien exageras el valor de tu código a la empresa de alojamiento (¿por qué les importaría? ¿a quién se lo venderían?);
• o, si esto vale tanto para usted, debe pagar por un alojamiento más caro.

No olvides que si tienen tu código, no sirve si no pueden ganar dinero con él. Si de repente ofrecen un servicio como el tuyo, es posible que tengas una buena razón para demandar y exigir que descubras cómo desarrollaron su servicio (consulta a tu abogado). No todas las medidas de seguridad son técnicas, un contrato puede ser disuasivo.

Creo que no estás pensando en esto con claridad.

Si está convencido de que el proveedor de alojamiento intentará robar su código, hay una solución muy simple: ¡no implemente su código en una máquina con ese proveedor de alojamiento!

Si está convencido de que todos los proveedores de hosting intentarán robar su código, no lo implemente en ningún proveedor de hosting: implementelo en las máquinas en sus propias instalaciones.

Dicho esto, sospecho que su análisis de amenazas está equivocado. Me resulta difícil creer que hay un 90% de probabilidad de que cada proveedor de alojamiento robe su código, si pueden salirse con la suya. Simplemente no hay manera de que sea precisa. Si fueran atrapados, el golpe a su reputación sería devastador: los pondría fuera del negocio. Es improbable que los proveedores de renombre asuman ese riesgo. Y, lo que es más, la mayoría de los proveedores de hosting no tienen interés en su código; están enfocados en su negocio de servicios de alojamiento, y probablemente no se preocupan por su código.

Entonces sospecho que usted ha estimado mal el riesgo. Pero, si está convencido de que tiene el riesgo correcto, la solución es simple. Simplemente no uses un proveedor de hosting.

Usted conoce la vieja broma:
Paciente: Doctor, doctor, por favor, ayúdeme. Me duele cuando me golpeo la rodilla.
Doctor: ¡Pues no hagas eso entonces!

Clásicamente, hay cuatro cosas que puedes hacer con cualquier riesgo:

• Trátelo implementando controles de seguridad.
• Toléralo como aceptable.
• Transferirlo a un tercero.
• Termínalo.

En la situación que describe, donde tiene una probabilidad muy alta de un incidente, y suponiendo que el costo de un incidente también es alto, entonces el mejor enfoque será eliminar el riesgo, es decir, no hazlo en primer lugar.

No es de mucha ayuda para usted, por supuesto, pero hay una razón por la que la gente de seguridad habla sobre el acceso físico a la caja; no hay controles de seguridad realmente efectivos cuando el atacante tiene acceso ilimitado a la casilla.

Si no puede Terminarlo, entonces, por supuesto, puede probar los otros métodos. La transferencia a un tercero será difícil, ya que esto sería complicado y costoso de asegurar, y ya no confía en el contrato que tiene con el proveedor de alojamiento.

Eso deja una combinación de Tratar y Tolerar. Tratar el riesgo involucraría cosas como la detección de intrusión / manipulación indebida, el monitoreo de la actividad en la caja, advertirle al proveedor que demandará en un abrir y cerrar de ojos, y así sucesivamente. Sin embargo, debido a que el atacante tiene acceso físico a la caja, la red y el poder, y está preparado para romper su contrato y la ley, estos tratamientos no podrán reducir el riesgo en gran medida.

Eso deja de tolerar el riesgo a pesar de su gravedad: aceptar que si tiene que poner la casilla en esa situación es muy probable que su activo se vea comprometido.

Por último, hay otro tratamiento que te recomendaría que consideres en este caso. Si pudiera saber que le robaron el código porque comienzan a usarlo y dicen que no lo hicieron, podría intentar que su abogado agregue cláusulas de penalización al acuerdo con ellos, una especie de -completar. No es lo ideal, ya que solo se activa después de que se haya hecho el daño, pero en esta mala situación, cada tratamiento que puedas acumular ayuda un poco.

En realidad, la mejor manera de proteger su código fuente es no colocarlo en un servidor que no controla. ¿Puedes compilar tu código y solo desplegar los binarios?

Parece que hay otro gran riesgo que no mencionas, ¿estás planeando hacer copias de seguridad? ¿Quién los hará?

Si el colo está haciendo las copias de seguridad, ¿cómo sabes que no hicieron una copia?

Si está realizando las copias de seguridad a través de la red a un sitio remoto, ¿cómo sabe que no están olfateando el tráfico?