在任何涉及关键系统的测试中，通常会将测试限制在低风险操作中，并避免使用可能会损害系统的自动化工具（例如 Nessus）。

具体到关键基础设施，我想说以下几点：

• 将测试安排在适用的低需求点。
• 让工程师和其他支持人员了解测试，并让他们随时待命以快速解决任何问题。
• 尽可能确保在测试期间计划额外的容量/冗余。
• 确保为测试人员提供适当的行动计划，详细说明如何处理严重故障或无响应的系统。这应该包括紧急联系人。

尽管如此，总会有风险。这是你必须处理的事情，在某种程度上这是一件好事。如果测试人员仅通过执行低风险操作来使某些东西脱机，那么您就知道攻击者可能做得更糟。在计划的测试期间发生意外的系统崩溃会很糟糕，但不会像没有人预料到的恶意导致的广泛崩溃那样严重。让它在测试场景中下降可以让您做出相应的计划并进行适当的修复。

嗯，不，对关键基础设施进行可能的破坏性测试是不“合理的”。这就是定义：关键基础设施是关键的。

让我们做数学（数学很酷）。渗透测试有一些（希望很小）概率p ₁来破坏应用它的服务。它还具有概率p ₂以允许检测和修复可能有概率p ₃被利用的问题，从而导致服务中断。那么应用渗透测试时中断的概率是p ₁ + (1 - p ₂ )·p ₃（渗透测试要么立即破坏事物，要么它“错过”漏洞并且攻击者无论如何都成功了）。如果该值大于p ₃，则渗透测试在现场，关键系统弊大于利，绝不能执行。

总的来说，这都是风险分析：您必须平衡进行渗透测试所涉及的风险，以及不进行渗透测试所涉及的风险。与我上面的几个数学符号似乎暗示的相反，相关概率无法以任何适当的精度知道，所以最终都是猜测。真正必须记住的是，有一组相对较大的可能策略：

• 您可以在实时关键系统上进行渗透测试。
• 您可以支付安装实时系统克隆的费用，这将与实时系统在物理上可以实现的相同，并在该系统上进行渗透测试。
• 您可以在实时系统的粗略仿真上进行大部分渗透测试，并与渗透测试人员一起对渗透测试操作进行分类：对于某些人来说，实时系统可能表现得像仿真，而对于其他人则不然。这可能已经揭示了有趣的事情。
• 你也可以什么都不做。尽管如此，风险还是可以通过保险机制转移（取决于具体情况；业务很容易转移，人的生活更艰难）。

需要考虑的额外一点是，攻击只是一种风险。你还有其他类型，例如洪水、地震和火灾，它们无论如何都会摧毁大部分“关键基础设施”，你也必须考虑这些。处理洪水的典型方法是在某处拥有备份基础设施（“冷站点”、“温站点”或“热站点”，具体取决于该站点的安装提前完成了多长时间）。在某些情况下，此备份站点可用于无风险渗透测试。

将主机转换为 VM 来宾，然后将它们带到异地以在其他地方进行渗透测试。收集固件样本并使用 Qemu 运行它们。要求一些 DCS、PLC、RTU 或智能电表设备，这些设备可以出于实验室目的而被迫提前退役。