在实施工业控制系统以监测和控制关键基础设施的组成部分时，确保这些系统的安全可靠运行一直是至关重要的。传统上，建造和操作这类系统的人都专注于减轻设备故障或意外工艺条件的影响。近年来，这些担忧已经扩大到包括通过网络攻击意外或蓄意破坏计算机或网络的可能性。
工程学科已经定义了有效和公认的规范标准，以提高安全和保障。在应用这些标准时，资产所有者通过首先识别和描述需要保护的资产，然后组装和实现合适的对策，主要集中于保护他们现有的系统。
虽然这种方法是合理的大小和复杂的安装基础，它是不够的。为了获得长期收益，解决信息通信系统的基本设计至关重要。在可能的范围内，这些系统在设计上必须既安全又有保障。网络安全标准现在可以解决这一需求。
标准涉及缓解和对策
在过去几年中，各组织已经制定了与ICS网络安全相关的标准。一些针对特定的部门(例如，NERC CIP, AAMI 8001-1)，而其他有更广泛的关注(例如，IEC 62443, UL 2900)。其他有用的信息来源补充了行业标准，包括来自NIST的特别出版物(例如NIST SP800-53和NIST SP800-82)和来自SANS等组织的指导文件。
许多现有的标准和指导文件本质上是被动的，因为它们往往强调减轻可能影响现有系统的网络事件的影响。这些很大程度上反应性的标准主要(如果不是唯一的话)针对系统集成商和资产所有者。标准说明了必须做些什么来减轻不断变化的威胁和漏洞。重点是配置、操作和维护安全系统所需要的东西。
生命周期角度需要
虽然有必要，但降低风险和传统的应对措施(如恶意软件检测)不足以实现持久的改进。真正全面的应对措施必须包括开发和交付设计上安全(或安全)的新产品和系统。这扩大了关注点，包括解决方案生命周期的所有阶段。
包括开发阶段需要组件、系统和解决方案供应商的参与和承诺。供应商已经制定了相应的程序，以应对在其产品中检测到的漏洞。为了超越这一点并实现“设计安全”的目标，他们必须能够访问由集成提供者和资产所有者开发和审查的一组一致的需求。
在描述产品与安全相关的性能时，使用“secuable”一词更为准确。这是因为即使是最健壮的产品，如果没有正确地配置、实现和支持，也会受到损害。“弹性”是在此上下文中经常使用的另一个术语，它意味着产品具有一些内置功能，可以抵御攻击，同时仍然保持正常功能。
大多数主要的系统供应商已经接受了这个挑战，并与集成商、资产所有者和其他涉众一起定义必要的需求。
安全开发生命周期
许多供应商已经采取了正式和严格的方法来将安全性构建到他们的产品中。这个过程通常被称为安全开发生命周期，涉及设计、构造、测试和漏洞响应的所有方面。
尽管应用这样一个过程的主要责任在于产品或系统供应商，但也有机会让所有涉众团体都参与进来。资产所有者、监管机构和标准开发组织将根据公认的行业实践贡献需求。
标准定义的需求
尽管许多供应商在创建他们的产品时采用了安全的开发生命周期，但成功取决于有明确的需求。资产所有者和潜在客户可能会提供与安全相关的需求，作为他们选择和采购过程的一部分，但这是不确定的。鼓励这种做法的尝试，例如拟定建议采购用语，基本上都是不成功的。对于潜在的购买者来说，更关注功能需求是很常见的，常常忽略了安全需求和约束。
各种标准通过定义一组适用于几乎所有组件和产品的明确安全需求来解决这一潜在差距。一些特定于行业的标准可用于组件和设备。例子包括NERC CIP, AAMI-8001-1和UL 2900系列的部分。
IEC 62443标准定义了跨部门应用的安全要求。它们最近被扩展到处理用于开发安全产品的过程以及产品需求。
IEC 62443-4-1标准描述了ICS产品与网络安全相关的产品开发生命周期要求，并就如何满足对每个要素描述的要求提供了指导。
IEC 62443-4-2标准为组成ICS的组件(即嵌入式设备、网络组件、主机组件和软件应用程序)提供了网络安全技术要求。它指定安全功能，使组件能够减轻给定安全级别的威胁，而无需补偿对策的帮助。
这两个标准都已经完成并得到了ISA99委员会的批准。它们将从IEC(如IEC 62443)和ISA(如ANSI/ISA-62443)中提供。
埃里克·考斯曼，为ARC咨询集团在流程行业的运营IT解决方案的开发、交付、管理和支持方面拥有超过35年的经验。在他的职业生涯中，他的任务和职责包括过程自动化系统开发，通信网络设计，功能和技术架构设计，以及技术生命周期管理。他最近从陶氏化学(Dow Chemical)的运营IT咨询工程师职位上退休。
