No estoy seguro de si este es el medio adecuado para preguntar esto, pero estoy buscando indicaciones o si se está haciendo. Me doy cuenta de que esto todavía es una pregunta abierta.
Cuando la red interna contiene datos críticos y software / hardware de control, la interrupción del aire es la norma. Pero como hemos visto en Stuxnet / Flame y sus hermanos, tiene sus límites. Y ahora que el gato está fuera de la bolsa, es probable que veamos atacantes no patrocinados por el estado usando este vector.
Entonces, asumamos un atacante sofisticado y motivado sin acceso físico. El atacante intentará contrabandear el firmware contaminado mediante intercepciones de hardware, ingeniería social o enfoques novedosos. Sería ideal auditar el firmware antes de conectarse a la red, pero incluso así, puede que no sea posible obtener una detección del 100%. Estoy buscando formas de mitigar el daño y minimizar el tiempo hasta la detección si tienen éxito.
Supuestos: acceso a la fuente de todo lo que ejecutamos dentro de la red. Las fuentes de datos están encriptadas. Attacker sabe en términos generales que el software y el hardware utilizados tienen una buena estimación de la arquitectura de red. No tiene acceso físico al sistema. El atacante tiene vulnerabilidades de día cero disponibles que les permitirán violar defensas de nivel superior como los privilegios de los usuarios.
¿Se podría mitigar esta amenaza haciendo que el código precompilado no pueda ejecutarse en el sistema haciendo que toda la red interna no pueda ejecutar el código precompilado? ¿Cómo podríamos lograr esto?
Estoy pensando en líneas de vincular todo con las bibliotecas locales con suficientes diferencias que se requeriría compilar con esas bibliotecas para que el ataque funcione. ¿Qué más podemos barajar? El objetivo es maximizar la dificultad añadida y al mismo tiempo conservar la capacidad de integrar software nuevo al compilarlo en el sistema.
¿Esto ayudaría incluso? El firmware aún funcionaría y podría hacer mucho daño. Pero la limitación de la capacidad para inyectar cosas aumentaría el riesgo de detección, que es, después de todo, lo más que podemos esperar.
Me doy cuenta de que la seguridad por oscuridad está mal vista, pero creo que podría tener su lugar en esto. Dado que la parte oculta es específica del sitio, el atacante tendría que tener acceso a un sitio en el lugar y debemos confiar en la seguridad del personal para evitarlo.
Para resumir en forma de preguntas:
- ¿Es posible limitar significativamente la ejecución de código foráneo dentro de la red por cambios que requieren binarios construidos localmente?
- ¿Se está haciendo esto?
- ¿Esto tiene sentido?