¿Es razonable realizar un pentest (u otra auditoría de seguridad no teórica) sobre una infraestructura crítica?

En cualquier prueba que se ocupe de sistemas críticos, generalmente se limitaría la prueba a operaciones de bajo riesgo y evitaría las herramientas automatizadas (por ejemplo, Nessus) que podrían dañar el sistema.

Específico para infraestructura crítica, diría lo siguiente:

• Programe la prueba en un punto de baja demanda donde corresponda.
• Haga que los ingenieros y otro personal de soporte estén al tanto de la prueba, y haga que estén listos para solucionar cualquier problema rápidamente.
• Asegúrese de que se planifique una capacidad / redundancia adicional durante la prueba, cuando sea posible.
• Asegúrese de que los evaluadores reciban un plan de acción adecuado que detalle cómo tratar fallas graves o sistemas que no responden. Esto debería incluir contactos de emergencia.

A pesar de esto, siempre habrá un riesgo. Es algo con lo que tienes que lidiar, y en cierto modo es algo bueno. Si los evaluadores dejan algo fuera de línea realizando solo acciones de bajo riesgo, entonces saben que un atacante podría hacerlo mucho peor. Una falla accidental del sistema durante una prueba planeada apestaría, pero no tanto como las fallas generalizadas debido a la malicia cuando nadie lo espera. Tenerlo en el escenario de prueba le permite planificar en consecuencia y hacer las correcciones adecuadas.

Bueno, no, no es "razonable" realizar pruebas posiblemente destructivas en una infraestructura crítica. Eso es por definición: la infraestructura crítica es crítica .

Hagamos matemáticas (las matemáticas son geniales). Una prueba de penetración tiene alguna probabilidad (con suerte pequeña) de p₁ para interrumpir el servicio en el que se aplica. También tiene la probabilidad p₂ para permitir la detección y solución de un problema que habría tenido la probabilidad p₃ para ser explotado, lo que lleva a una interrupción del servicio. Entonces, la probabilidad de interrupción al aplicar la prueba de penetración es p ₁ + (1 - p ₂ ) · p ₃ (o el pentest rompe las cosas de inmediato, o "pierde" el agujero y el atacante tiene éxito de todos modos). Si ese valor es mayor que p₃ , entonces el pentest en el sistema crítico en vivo hace más daño que bien y no debe realizarse.

En general, esto es todo análisis de riesgos : tiene que equilibrar los riesgos que implica hacer el pentest, con los riesgos involucrados con no haciendo el pentest. Contrariamente a lo que parecen indicar algunas de las pocas anotaciones matemáticas anteriores, las probabilidades relevantes no se pueden conocer con una precisión decente, por lo que al final todo es una cuestión de conjeturas. Lo que realmente se debe recordar es que hay un conjunto relativamente grande de estrategias posibles:

• Puedes hacer el pentest en el sistema crítico en vivo.
• Puede pagar la configuración de un clon del sistema en vivo, que será tan idéntico al sistema en vivo como se puede lograr físicamente, y hacer el pentest en ese sistema.
• Puede realizar la mayor parte del pentest en una emulación burda del sistema en vivo, y trabajar con el pentester para categorizar las acciones del pentest: para algunos, es probable que el sistema en vivo se comporte como la emulación, para otros no. Esto ya puede revelar cosas interesantes.
• También puedes hacer nada en absoluto. Sin embargo, el riesgo podría ser transferible con un mecanismo de seguro (según el contexto; los negocios se transfieren fácilmente, las vidas humanas son más difíciles).

Un punto adicional a considerar es que los ataques son solo un tipo de riesgo. Tienes otros tipos, por ejemplo Inundaciones, terremotos e incendios, que pueden destruir gran parte de la "infraestructura crítica" de todos modos, y también hay que tenerlos en cuenta. Una forma típica de lidiar con las inundaciones es tener una infraestructura de respaldo en algún lugar (un "sitio frío", "sitio cálido" o "sitio caliente", dependiendo de cuán lejos se completó de antemano la instalación de ese sitio). En algunos casos, este sitio de copia de seguridad se puede utilizar para pentests sin riesgos.

Convierta los anfitriones en invitados de máquinas virtuales, luego llévelos fuera del sitio para probarlos en otro lugar. Reúna muestras de firmware y ejecútelas con Qemu. Solicite algunos dispositivos DCS, PLC, RTU o medidores inteligentes que puedan forzarse a la jubilación anticipada para fines de laboratorio.