Los Pentesters / "Auditores" deben mantener una captura completa del paquete de todo lo que sus herramientas ponen en el cable y esto debe estar disponible para usted como cliente. Use esto si algo se bloquea, se identifica incorrectamente, etc. para identificar el (mal) comportamiento de los sistemas bajo prueba.
También, inicie básico y manual antes de atacar el sistema con todo tipo de tráfico. (las cosas pueden ir mal rápidamente y no tendrá idea de lo que lo causó hasta que escarbe a través de las capturas) Esto significa identificar pasivamente los puertos en uso, luego comenzar enviando conexiones / SYNS simples en lugar de un escaneo completo de huellas dactilares / servicio de nmap. etc. (es poco probable que las herramientas tengan firmas útiles para identificar el equipo de todos modos)
Considera también obtener los datos por otros canales. Por ejemplo, muchos dispositivos admiten una MIB SNMP estándar que le proporcionará información sobre el modelo, los puertos tcp / udp, la tabla de rutas, etc. Si puede recuperar esta información con consultas estándar de SNMP, no necesita escanear todos los 65,000 puertos. .
Ignora la respuesta de Rook a tu comentario. Aunque muchos componentes de software de los sistemas de control se ejecutan en los sistemas Windows y * nix ahora, todavía existe un gran riesgo de bloquear / corromper las aplicaciones en estos sistemas, por no mencionar los dispositivos integrados que conforman el campo del sistema de control que son Aún más notorio por no ser amable con el escaneo o las pruebas. Hay muchos ejemplos de ambos para respaldar esto, incluso cuando se ejecutan en sistemas operativos modernos.
TL; DR: siempre hay más enfoques de prueba pasivos / de no intervención a los que puede recurrir para realizar su tarea de prueba y obtener cobertura del sistema de control. Sea creativo y coopere con el cliente o el equipo de prueba.