IEC62443工业自动化与控制系统标准介绍、构建与应用

当前，许多工业控制系统（ICS）的所有者和运营商均意识到优化和有效管理 ICS 网络安全的必要性。因为工控系统的设计、部署和操作均基于传统技术、方法和意识形态，导致  ICS 中潜藏大量安全问题和漏洞。如今，意识形态虽有所改变，但核心 ICS 技术尚未迎来重大改变，因此针对ICS 的网络安全发展依旧缓慢。远程访问和针对 ICS 的攻击等明确而现实的危险，迫使我们对方法进行调整，但也仅限于文化、劳动力资源和技术限制允许的范围内。对工控系统进行全面调查以检查其安全性已属常规  操作，与此同时，还应关注操作人员操作这些大型复杂控制设备以及可能全天候持续运行的物理系统时所面临的复杂性和挑战。对于关键基础设施而言，全天候不间断运行意味着系统需持续提供服务。而挑战不仅源自网络安全问题的管理，还源自运营风险和网络安全问题的管理。

在未了解网络安全问题与运营风险关系的情况下，专注于识别和修复网络安全问题，只是将安全问题简化为一系列调查结果，这些调查结果仅能代表整个 ICS 网络安全态 势的一小部分，而不能展示其全貌。审查这些调查结果后发现，考虑到当前 ICS 网络 安全成熟度、敏捷性和可用预算等因素，缓解措施可能需长达一年甚至三年才能完成。届时，又需进行新一轮安全评估，尽管无法衡量先前的努力是否有益于安全或是 否能够确保面临网络攻击威胁依然保持运营有效性。一些必要的优化可能得以实施， 但依旧缺乏紧密协同优势。

优化ICS 网络安全并非仅简单增加安全对策以期应对薄弱环节。应仔细筛选安全对策，以有效缓解  ICS 运营风险，并在操作人员努力维持缓解措施并挫败活动威胁时， 能够持续补充安全操作。这些对策应共同协作，使网络安全事件的预防、监控、检测和响应工作流更加清晰直观。优化整个 ICS 的网络安全无法一蹴而就，不能归结为一 个简单、连续的阶段路线图。理想情况下，应考虑持续风险评估过程中确定的安全要求，将 ICS 划分为不同成熟度阶段运行的安全区域。

IEC 62443（以下简称“标准”）是由 ICS 专家为不同应用领域和行业的 ICS 所有者、 制造商和集成商编写的一套 ICS 网络安全标准。该标准提供了开展 ICS 网络安全计划 设计的建议和技术指南，以推动构建一种支持紧密协同的安全解决方案，该解决方案充分考虑了组织推进 ICS 网络安全计划过程中的不同成熟度阶段。该标准采用包含成 熟度阶段的分步流程，概述了作为 ICS 网络安全计划一部分的生命周期方法。通过将 ICS 划分为安全区域，组织可在整个 ICS 环境中 ，从局部和全局的角度更好地关注与 风险、漏洞和合规性相关的威胁缓解举措。

接下来，我们将共同探究该标准，详细了解其内容。

IEC 62443 概述

IEC 62443-3-2 根据风险评估将 ICS 组织划分为不同安全区域（Security Zones）和管道（Conduit）。该标准提供了有关如何选择或设计安全区域和管道以及如何确定安全等级（SL：Security Level）的相关指导。需采取某些对策来达成每个区域的 SL。典型的 ICS 所有者和运营商组织必须评估其现有安全控制与所确定的安全等级标准定义之间的差距。然后按SL1 到 SL4 为这些区域确定安全等级，如图 1 所示。

图 1. IEC62443安全等级

即便组织将其 ICS 环境化分为 多个区域，所有区域之间的完 美风险隔离通常无法实现，因为一个薄弱区域可能通过两种 方式影响相邻区域。首先，薄弱区域内的服务或运营中断可 能会级联到与这些服务有业务 关联的其他区域。其次，由于 通信路径可能存在于区域之间，一个区域被攻陷会使威胁 横向传播至其他区域。为有效 克服此类挑战，该标准引入了 一种特殊类型的区域，称为“通信管道（Communications Conduit，以下简称“管道”）。

通过识别和分析这些管道内存在的通信信道，组织可明确区域内和区域间适当的通信保护等级。

IEC 62443 标准入门

该标准提供了建立 ICS 安全计划的完整流程，称为“ 网络安全管理系统（CSMS：cybersecurity management system）”。本文重点讨论 CSMS 各组成要素之间的高阶关 系：风险分析、利用 CSMS 缓解风险以及监控和优化 CSMS。

如简介中所述，网络安全是帮助组织管理  ICS  环境风险的有效工具。这种管理需全盘了解风险，以便选择和部署有效的应对措施。标准中概述的过程包括许多步骤，但本文将重点介绍一些关键步骤。例如，高级风险评估将根据受损的 ICS 情况确定财务、运行健康状况、安全性和环境影响。这一关键步骤将帮助组织清晰了解每种风险被触发后可能产生的 负面影响。掌握这些内容，组织即可基于每种风险创建优先级列表，帮助组织在环境漏洞 评估期间或之后，集中精力和资源应对高危等级风险。组织面临的风险并非一成不变，可 能因内部和外部影响随时发生变化。必须定期触发风险流程，以响应风险相关事件，如系 统设计或功能的变化、新兴威胁和组织内部变化等。

CSMS 通过三种并行方法应对风险：安全策略和意识、安全对策和对策执行。在许多 ICS  网络安全活动中，安全策略和意识方法经常被忽视。实际而言，安全策略的存在不仅是为 了确保人们的行为符合预期要求；还可用于帮助组织确保并维持已执行对策的有效性。例 如，许多防火墙已部署至 ICS 网络，但之后却失去有效性，主要原因是组织未采取有效的 对策执行以确保通过严格、可重复的流程部署和/或禁用安全规则。

鉴于业务或财务等多种因素影响，组织 ICS 环境中的部分系统可能处于不同 的成熟阶段。如标准中所述，“组织可通过评估工业自动化和控制系统各阶 段和步骤取得的成果，获得更详尽的安全成熟度评估。”表 1 列出了与该标 准对应的成熟度阶段和步骤，以及已设定的假定风险缓解目标。

遵循 CSMS 可确保构建原生的紧密协同优势，最终优化 ICS 网络整体安全态势。

​

安全

组织必须明确并努力达成每个安全区域对应的安全等级（SL）。换言之，如果组织希望在某个区域实现最高安全等级 SL 4，则必须确保安全控制的执行者清晰了解组织的目标，以便该区域的安全控制举措能够满足该等级要求。

图 2 描绘了网络分段方法如何比整体方法看似更复杂，但其实更简单、更有效，因 为这一方法将整个系统拆分为更小、更集中且更具成本效益的小区域。

整体式安全方法通常更难以达到和维护安全等级要求，因为这种方法要求每个区域 均达到 SL4 最高安全等级，这就要求对 ICS 网络安全计划进行广泛的对策执行、管理和总体成本控制。整体安全方法可能 很有必要，但多数 ICS环境在技术、人员和流程等方面无法确保整体一致性， 从而引发更多复杂性挑战，如果对此视 而不见，将极大影响对策执行时间和结 果。这些复杂性挑战可能包括安全对策 无法互相兼容，以及系统和团队之间存在的操作差异。减少（或消除）与操作SL 4和技术差异、新人入职和培训相关的复 杂性挑战需要花费一定的时间，且需与 CSMS 构建过程相契合。

图 2 右侧所示的分段式安全方法，支持跨整个环境实现执行变更的可衡量有效性， 使组织得以制定成熟度策略规划路线图，以在有限预算范围内实现并管理基于风险 的既定目标。

图2.整体式方法与分段式方法跨整个环境 的安全等级衡量比较

IEC62443-3-3 对七个基 本要求（FRs：foundational requirements）进行了 分类，并扩展为一系列  系统要求（SRs：system requirements） 和增强要求（REs：requirement enhancements)。参见图3。

图3.基本要求

该标准提供了一个图表，以便将这些 SR 和 RE 映射至 SL 1-SL 4。但 ICS 威胁态势因不同部门、行业类型和组织而异。因此，尽管以上所述均为可靠定义和优秀范例，但在应用时应基于不同组织独特的防御态势和具体需求加以考量。SL 可能需根据每个安 全区域在威胁类型、操作变化和所使用技术（如工业物联网）方面的差异进行修改，应注意的是，所有这些调整均可改变 ICS 攻击面。SL 有助于建立目标，但必须始终保 持目标的灵活性，且根据威胁态势变化积极调整目标。这便是为何应定期触发并在每 个风险相关事件发生后触发组织风险分析过程，以此确保组织始终紧跟安全风险态势变化，并确保适用的 SR 列表始终保持最新状态，令组织处于积极主动防御状态。

表 2 将 SR 和 RE 映 射至 FR 安全等级。

监控和优化 CSMS 对 于保持和评估 ICS 网 络安全态势整体有效 性至关重要。组织可 每年执行一次 CSMS  中的这一步骤，但建 议组织随时执行该步 骤，以确保一致性和 有效性。

一致性有助于组织验证是否已采取应对风险的相关 步骤。基于 7 个 FR以及 SR 和 RE 测量每个已划分安全区域确定的 SL，可对每个安全区域的防御态势提供更精细的视角。评估活动还可提供应用MITRE ATT&CK® for ICS Matrix 的机会，以分析威 胁活动组织使用的战术、技术和程（TTP）及行为相对于每个安全区域的现有或缺失对策的适用性。

安全对策的作用，详细解释了 对策如何更好地适应 SL 方法。

安全对策的作用：

遵循 SL 中 FR 和 SR 的定义可能需使用多种安全对策，这些对策基于安全区域的构成而异。查看建议列表时，应注意识别有助于扩展可能有利于其他安 全区域的对策以及对 TTP 或相关威胁活动团体行为进行分析的机会和能力。

开展详细的网络安全风险评估，确定每个区域的目标 SL（SL-T)，并明确列示有助于该安全区域达到目标 SL-T 或同样有助于其他安全区域的对策，将可能获得已投入时间和精力的最大化回报。

引入的对策需满足评估报告的具体风险降低建议，同时也需审查所有安全区 域的要求，因为所选对策可能有益于多个安全区域（包括评估范围之外的安 全区域）。此外，在选择对策时，应注意识别对策能够提供检测和响应活动 以及保护能力的机会，从而实现当前和未来投资回报的最大化。还应注意记录不同解决方案提供的功能扩展，这些功能扩展可能有助于确定以后的安全 对策。

区域、子区域和管道

每个安全区域和管道都分配有一个目标 SL 或 SL-T。为达到满足标准要求的安全级 别（目标安全等级或 SL-A），必须满足几个促成因素。该标准涵盖了图 4 中描述   的因素，但应注意还涵盖更多其他因素。正如标准中所描述，这些因素很复杂且难 以实施，但许多因素都会影响所选对策的有效性。因此，在决定实施这些措施时，不仅要选择和验证对策，还需考虑其影响。

例如，组织可能希望审视对策功能依赖性对不同安 全区域中易受攻击服务的影响。为达到特定安全等 级并缓解风险，选择一种适当的对策固然重要，但在使用这些对策时评估残留或引入的风险同样至关 重要。

在建立安全区域和管道及每个 FR 所需的安全等级 时，必须充分考虑上述因素。正如我们下文讨论的，可将ICS 划分为多个安全区域，但通信路径可能会在这些区域之间残留攻击媒介。因此，必须评估这些路径和相邻关联安全区域并满足 SL-A 要求，才能使所审查的安全区域满足 SL-A。

图4.达成 IEC62443SL-A所需的要素

普渡模型：IEC 62443 参考架构

通常所说的普渡参考模型源自普渡企业参考架构（PERA)，该架构基于普渡大学应用工 业控制实验室（PLAIC)构建的原则，目前被视为该标准的参考架构。应用程序相关安全等级的使用和分配，可追溯至 1989 年 ISA 发行的 220 页出版物“计算机集成制造（CIM）的 PERA 参考模型”。3该出版物是从工业自动化的角度编写，旨在“帮助推进计算机集成制造技术的 发展，并解决当下困扰该行业的一些问题”（“当下”指 1989 年）。这些安全等级被 用作定义“站点范围网络架构”的方法，该架构按照四个原则（响应时间、分辨率、可靠性和可修复性）分为多个安全等级，主要应有于数据上下文。

该模型的原理在今天仍然有效，特别是从 ICS 中数据价值的角度来看。然而，在某些领域，该模型还不够完备。首先，1989 年发现的问题与我们今天面临的问题不同。随 着 ICS 的广泛应用及其与运营之间日益加深的关联度，无线通信技术、云服务、物联网、远程访问、受 SLA 约束的关键外包服务等技术不断涌现，当然还有网络安全。该  模型在当下甚至在 1989 年的使用（如下页图 5 所示），其目的均非要求所有组织基于 同一理念构建相同的 ICS 网络架构，而是作为一种工具，达到描述、引导和利用的目的，提供具有创新性的解决方案，有效解决面临的问题。

为何安全区域和子区域 至关重要？

与 1989 年一样（参见“普渡模型：IEC 62443 参考架构”），该标准提供了深入理 解 ICS 的视角以及一些概念 ， 组织可基于这些概念缓解 ICS  安全挑战并优化 ICS 环境。其 中提及的安全区域、子区域和 管道概念是更具价值的概念之 一，为实际应用提供了安全基 础。安全区域是 ICS 分段的基础。

图5.参考架构与示例分段架构的一致性

不同系统的集大成者是对 ICS 最恰当的描述。根据部门和行业类型的不同，ICS 可 从概念上细分为三种相互依存资产类型的较小运营资产组：

1.   执行特定操作的物理系统，例如机器

2.   应用程序，例如 ICS 设备、网络和软件的集合，编排整合以执行特定操作 功能或分担直接操作风险

3.   可能在其他组内生成或从其他组流出或流入的数据，例如压力值或工单详细信息

运营资产组应代表组织的最小自主运营单位。多个运营资产组构  成了工厂或工厂整体运营架构。定义这些运营资产组时，应明确  影响的后果和严重性，以推导出所需的 SL。后果或严重性的确定 应考虑运营、财务、安全运行状况、安全性和环境因素。一个安  全区域将是一个单独的操作资产组或共享通用安全要求（在本例  中为 SL）或目标的操作资产组集合，且可在逻辑上组合并隐藏于 逻辑边界中。图 6 显示了这些分组。

图6.ICS中的三个资产组

ICS 架构可能包含需较高安全等级的运行资产组（例如锅炉），也可从周围资产  的安全等级中受益。对于此类情况，可使用子区域。执行分段时，安全区域和子 区域仅为 ICS 操作的逻辑架构，且应在实际物理网络的上下文之外进行查看。

在某些情况下，信息必须通过管 道在安全区域内传递或流入、流 出安全区域。管道促进分组通信链路（通道）的建立，以在区域 内和区域之间传输信息。该过程涉及但不限于编程终端、移动设备、便携式媒体设备和供应商连 接之间的间歇性通信。管道和通道可被识别为可信或不可信。未跨区域边界的管道在很大程度上 被认为是可信的。当任何一方与参考区域的安全等级不同时，即 被确定为不可信的通道或管道。 从通信媒体的角度来看，通道继承了管道的安全属性。然而，通过使用安全通信功能，可信管道或通道实际上可扩展安全区域的范围。

为确定和部署适当的安全对策， 有必要对区域和终端之间的通信进行深入研究。图 7 是安全区域 和管道之间的关系示图。

图7.高级制造业安全区域和管道示例

对于许多组织而言，分段是一项艰巨挑战，特别是棕地设施（brownfield facility） 需执行当前部署的 ICS 技术时，这一挑战尤为突出。这就是为何区域应被抽象化，而无需过多关注实际部署的硬件和软件。只有在应用 SL 后，才可覆盖实际的 ICS 技术（如网络设备、PLC、驱动器、计算机、防火墙、服务和协议等）。此过程将清晰描述环境中区域之间的所有共享硬件、网络路径和软件。当区域之间共享技术时，这些区域的 SL 必须调整为更高等级的 SL，以使风险降低要求与使用 IEC 62443 标准 9 获得有效 ICS 网络安全后果和严重性保护要求保持一致。该信息可识别技术性分段和重新调整机会，有助于最大限度减少为多个区域分配更高等级 SL 的任务量，从而最大限度降低成本。每个网络环境各不相同，但所使用的流程可囊括以下 基本原则：

• 较低的安全等级需较少的安全控制。

• 分层分区和子分区可提供纵深架构防御。

•  区域和子区域边界可为网络安全监控提供南北向和东西向流量阻塞点。

•  ICS、网络和软件应用程序微分段可能会产生额外的安全成本/收益机会。

• 在第2 层使用网络访问控制技术，有助于扩展区域边界控制。

分段挑战示例：

假设一家分布式控制系统（DCS）供应商提供了一种一站式解决方案，支持构建由计算机、软件、网络和可编程自动化控制器紧密集成的安全控制架构。由于在供应商的支持下  才能进行系统测试验证，即便有机会在 DCS 环境中添加子区域，资产所有者大多也会因此 被供应商拒绝。但与此同时，供应商通过其产品提供了一定程度的服务和安全性。拥有DCS 供应商的组织，应与供应商一同审查 SL、FR 和SR。否则，其分段将应用于 DCS 控 制的生产资产之外但为其提供生产服务的系统，包括单个 DCS 和非 DCS 生产资产的边界，以及可能存在于DCS范围之外的任何安全仪表系统。

如图  8  所示 ，SCADA  所有 者倾向于拥有与其网络架构一致且明确定义的安全区域 ，但在这种情况下 ，更有可能将不可信的管道用于关 键通信。

图8.SCADA参考架构与示例分段架构的一致性

SCADA 所有者还需探索如何在每个主控制中心和备用控制中心之间保持隔离状态，以确保 每个中心的完整性，避免两者在同一安全事件中同时遭受损害。即便通信媒介是传统电话而非以太网，架构通常也会保持不变。

制造业环境（参见图 7）可能很复杂，因其控制系统可能与企业信息系统之间建立了重要 的数据通信，从而形成必须设立大型安全区域的操作依赖性。企业资源规划（ERP）系统、制造执行系统（MES）、实验室信息管理系统（LIMS）、仓库管理系统（WMS）等许 多信息系统与企业紧密关联，导致企业难以构建独立的纵深防御等级区域。这些系统和ICS 之间的相互通信关系较为复杂，从理想的 ICS 安全网络设计角度而言，没有明确的分  段边界。采用搭载基于角色和网络访问控制功能的交换机，在现有和新环境中创建多个子 区域，可能是一种有效的分段策略。

最后，传统系统的设计初衷旨在优化成本、确保正常运行时间和运营效率，通常未考虑安全区域的构建。在许多情况下，不堪重负的系统架构可能需跨多个安全区域部署更少的组 件。这些组件能够提高生产和运营效率，但却无法满足当今的安全要求。更换控制系统成 本高昂，且会导致可分配的安全区域更少，而资产可能更多，从而要求更高的安全等级。 因此，当控制系统未来需更换时，能够识别这些安全区域将有助于未来的规划。

安全对策所面临的挑战

确定安全区域和管道及其各自的 SL 和相关要求后，即可开始审查和实施控制措施。

与 ICS（如 Windows 操作系统）中使用的常见 IT 技术不同，可应用于 ICS 技术的安全控制受到 ICS 供应商提供能力的限制。组织很少选择向嵌入式 ICS 技术中添加额外的安全代理和软件。供应商可能会为其设备提供安全补丁，但针对安全区域的保护应不仅限于基于漏洞的防护，还应考虑威胁行为分析来确保安全性。了解这种防护方法，有助于为您阐释 Fortinet 如何通过其 FortiSIEM 产品提供威胁行为分析功能。

通信接入和外部管道在保护安全区域边界方面发挥着关键作用。Fortinet 通过其 FortiSwitch 安全交换机FortiGate（以及 FortiOS 操作系统）防火墙和 FortiAnalyzer/FortiManager 分析与集中管理 产品为这些领域提供集成式协同防护功能。深入研究三类特定的访问控制点，有助于我们为您阐释Fortinet 解决方案如何帮助组织实现这些常见应用场景的投资管理最大化。从 ICE 标准的角度而言，这些控制点主要涉及以下管道：

• 安全区域接口（逻辑或虚拟）

• 无线（802.11）网络接口

• 虚拟专用网络（VPN）接口

遵循以下标准进行分析：无论通信路径是通过有线连接、无线网络还是 VPN 接口，安全区域接口都应被单独处理。此外，每个无线接口和 VPN 接口均被视为独立的受控接入点。由 此，无论通信路径是通过无线网络或   VPN，都必须涉及两个控制接入点；首先访问无线网 络或 VPN 接口，其次访问安全区域接口。因此，许多用于保护安全区域接口的控制措施均可在无线网络或 VPN 上使用（如适用）。

威胁行为分析防护

挑战

需克服多重挑战才能确保 ICS 内的安全补丁处于最新状态。对于这种基于漏洞的防护，重点聚焦所使用的常见 IT 技术（如 Windows 服务器）领域。这些技术可持续提供补丁，有效应对主动发现的漏洞，并被动响应这些系统中发现的安全漏洞。虽然目前已有一种公认 且可信的机制，可自动更新已部署系统的安全补丁。然而，受 ICS 正常运行时间、完整性 以及在某些情况下的监管要求的限制，需对这些系统所做的更改（包括补丁修复）进行严 格且成本高昂的测试和验收流程。对于 DCS 和非 DCS 系统同样如此。

通用 IT 技术仅占整个联网 ICS 资产的一小部分。而其他资产是运行专有版本的嵌入式操作系统和实时操作系统（RTOS：real-time operating systems）的嵌入式设备组合。这些设备的漏洞可能更少，但数量却日益增加，因此补丁修复的维护难度更大。多数攻击者会伺机利用环境中已内置的功能和技术发动攻击。引发 ICS 设备中断或破坏的已知攻击，通常是攻击者针对该环境量身定制的攻击。

威胁行为分析防护采用基于持续监控和威胁活动组分析生成的威胁情报，可用于评估、构 建和测试 ICS 防御措施。威胁情报报告通常包含入侵指标（IoC）以及战术、技术和程序（TTP）。IoC 是攻击的特定技术元素，不仅可立即部署在被动防御安全控制中，还支持临时部署（在组织间的应用可能受限）。另一方面，TTP 允许更广泛的攻击者行为。IoC 是TTP 的一个特定但可更改的组件。安全运营团队可查找匹配或相似的行为，而非查找特定   的 IoC。这些 TTP 针对 MITRE ATT&CK FOR® ICS 知识库进行映射，不仅可精准识别已检测 到的攻击者位于杀伤链哪一阶段，还可针对特定威胁活动团体的行为有效评估安全控制和   检测能力的深度和广度。将 MITRE ATT&CK® for ICS 知识库与已部署的 ICS 进行映射，可 能是一个艰巨而广泛的过程。

安全区域接口

挑战

限制  ICS  边界处的通信通常涉及网络防火墙内的源  IP、目的  IP、源端口和目的端口的策 略配置。然而，确定政策是极其繁杂的过程，目前，有很多方法可以帮助确定需要或不需要哪些策略以及哪些具有时间要求（尤其是围绕高风险服务）。如果作为区域和管道设计过程的一部分进行深入分析，许多关键通信已被确定。通常余下的工作便是捕获和分析所有通信通道，并确定哪些应用程序负责流量分析。分析完所有流量后，实施者即可确定该流量是否必要，如非必要流量，则采取相应控制措施拦截该流量。

当 ICS 协议通信需跨区域边界时，进行工业网络流量检查和应用程序层面控制非常重要。 此功能可用于拦截来自低受信系统的非预期写入事件，还可防止滥用某些 ICS 协议引发的 基本 DoS 攻击，如发送任意可能填充设备连接限制的“通信关闭事件”或“连接初始化”命令。深入了解这些协议的具体使用，对于在工业网络中有效运用应用级控制非常必 要。

多数组织均将 IT（办公室）和 OT（ICS）环境进行明确区分。在当下制造业环境中，IT 环境之外的网络连接日益广泛，以适应连接至其机器的 OEM、为处理专家和员工提供远程支 持以及基于云的操作仪表板，所有这些连接均已突破传统 IT 与OT 环境的界限。此外，第三方服务提供商也需访问其位于 OT 环境中的设备。

为支持 IIoT（工业物联网） 的应用，国际自动化协会正积极开发一项新标准《ISA- TR62443-4-3-DC：62443 标准在工业物联网中的应用》。

人员、流程和技术

在实践中，在安全区域接口上实施任何保护措施均需事先深入了解 ICS 通信，并需要运营团队、供应商和控制工程团队的积极参与或审核。强烈建议通信两端的资产所有者、数据所有者或数据接收者共同参与。团队成员将根据资产和数据、策略应用对象以及策略影响 对象而有所不同。在某些情况下，RASI 图可帮助管理变更控制流程。每项策略在设计、测试、启用和审核时都必须遵循严格的流程，且必须囊括紧急禁用策略以支持计划外操作事件。避免所运用的策略自行引发可见性和控制能力丧失的情况。

许多 ICS 威胁都会攻击授信系统。慎重决定是否部署可能对运营产生破坏性影响或造成非必要成本支出的高级功能。安全感知的错误使用和复杂性的增加无益于实现总体安全目标。

无线（802.11）网络接口

挑战

随着技术的进步和安全要求的升级，全新无线 802.11 标准应运而生。随着新标准的发布，ICS 设备制造商通常无法在其现有产品中采用这些标准。然而，连接这些 ICS 设备的网 络基础设施通常会更频繁地升级。尽管现有无线 ICS 设备和系统不会受益于新标准提供的任何额外安全功能，但新的无线解决方案仍可实现向后兼容性。为了适当降低不同于802.11 标准的相关运营风险，开展无线项目升级时可能需进行额外的分析、配置、验证和测试。

无线网络的使用因部门和行业类型而异。鉴于安全性等诸多因素，许多 ICS 所有者倾向于尽可能禁止或严格限制在其系统中使用无线技术。然而，即便是这些组织也面临增加更多数据分析以最大限度提高 ICS 营收的压力，这使得无线技术更具吸引力，因为它是一种极具经济效益的技术，无需布设网络线路。即便如此，组织仍需评估使用无线网络的安全影   响。例如，自 Wi-Fi 问世以来，制造业便开始使用无线技术。自动导引车、牵引电机系统和 其他机器层面功能中的无线技术的使用 ，表明该技术是一种可行的选择。应对这些网络进行持续的安全性审查和优化，不仅要考虑威胁，还要考虑这些系统的可用性和完整性，因其在运营中发挥着关键作用。

人员、流程和技术

ICS 中有许多无线网络应用场景。应采用正式的安全策略和访问请求流程。在新设备重大停机和调试期间，安全团队可能会采用临时无线网络，以实现更有效的工作流程。应讨论、捕获这些事件，并在需要时将其纳入 ICS 无线策略和计划。

与企业需使用无线网络更广泛地访问全球资源不同，ICS 无线网络通常可设计为仅支持使用特定（主要是 ICS）协议访问特定主机和用户。通过这种方式，ICS 无线可有效限制因安 全性薄弱、安全凭证被盗或未知协议漏洞引发的网络滥用行为。

实施策略

许多解决方案涵盖任何给定安全区域或管道的目标 SL 所需的许多控制措施。更复杂的是，还支持许多配置选项以支持单独控制。因此，即便选择了适当的控制措施，安全等级的实现也不像标准中描述的那样简单。帮助组织确定某项控制措施是否满足其 安全要求的方法包括：

• 联合供应商彻底审查每个配置选项，了解支持该控制措施的所有功能

•  内部或外部团队对控制措施的全面评估和衡量

维护控制措施需通过质询其持续的必要性、识别针对 SL 更改的差距、维护严格的更 改控制流程以及应用供应商功能更改和更新知识来主动监控控制措施。

最后，应用网络安全监控活动以完成确定至少一些安全区域和通道的目标。在安全区 域或管道中引入的多数控制措施均可产生信息。将这些信息集中汇总时，可生成丰富 的威胁上下文，并应用于当前和临近安全控制措施，此外还可用作早期威胁检测的深 入洞察。

在遭遇网络安全事件期间，可能需在控制措施中添加额外的安全对策，以遏制威胁或确保持续安全运营。

总结

供应商赋予其产品多种安全功能，但却难以在战术层面使这些功能与既定安全目标保 持一致。对于具有不同风险级别和风险程度的组织而言，ICS  通常提供众多不同功 能。为保持一致性，首先需了解整个环境中各区域的不同安全目标，其次是了解如何 在无需针对每个区域逐一部署控制措施的情况下，实现这些安全目标。