DISCAIMER:这篇文章不仅适用于已经被黑客攻击的组织......IEC 62443是一个公认的通用标准,适用于制造、能源、运输、医疗和许多其他关键部门。

这篇文章是8个系列的第一集,涵盖了任何旨在满足工业和自动化控制系统网络安全现状的组织所要实施的主要做法。基于IEC 62443-4-1标准部分的实用方法,定义了与安全开发生命周期相关的要求,本文为您提供了如何在您当前组织流程中处理此类活动的指导。

为了系统地开发安全产品,必须在整个软件生命周期中强调安全,从而使结果在设计上是安全的。因此,普通软件生命周期的每个阶段都必须通过安全实践来加强。这导致了一个安全的开发生命周期,如下图所示。在这第一集里,我们将重点讨论定义安全目标所需的实践。威胁分析

 

威胁分析实践包括一个由组织实施的过程,以满足从IEC 62443-4-1中提取的以下要求。

  • 应规定一个威胁模型,包括系统的架构元素、资产、安全环境、攻击媒介和信任边界。
  • 应确定威胁,包括评估其未减轻的和剩余的风险。
  • 有助于组件要求(CR)及其增强(CR-RE)的反措施应被定义。
  • 应确保工作产品的可追溯性,从威胁到对策要求和测试案例。

为了确保威胁分析的有效方法,一些额外的要求可以被正式化。

  • 威胁分析过程应被整合到现有的开发过程(如V模式或其他)和敏捷方法中。
  • 产品开发过程中的威胁分析工作应尽可能的低(合理和可控)。
  • 威胁分析过程应被所有利益相关者接受。
  • 利益相关者应得到软件工具的支持,以确保方法一致,避免错误

利用这种分析的结果,可以创建一个安全的设计,专门针对已确定的威胁,在架构层面上采取适当的对策。这最后一个主题将是下一集的主题(第二集)。以下是对五步法的描述。

 

第1步 - 背景规范

通过这第一步,系统架构和它的安全环境在威胁模型中被指定。系统架构被指定为数据流图,其中包含与系统环境交互的组件、它们的资产、它们的交互路径和使用的通信技术。此外,还指定了信任边界以确定不同的信任区。为了建立这个威胁模型,一些工具可以支持以结构化的方式管理信息。例如,微软提供了一个威胁建模工具(MS-TMT),可以免费使用。它通过提供所谓的威胁模型模板来支持威胁分析,这些模板定义了模型元素的可用类型。

 

第2步 - 威胁的识别和评估

在第二步中,必须根据预先确定的方法来识别和分析对步骤1中指定的系统的威胁,该方法可能因系统背景和应用部门而不同。STRIDE方法是众多方法中的一个例子。它定义了一种方法,允许识别与以下方面有关的威胁。欺骗篡改抵赖信息披露拒绝服务权限提升。工具可以通过自动生成基于系统定义的威胁来支持你的进程。

对于风险评估,组织根据标准化的或自我定义的等级来确定威胁的严重性。此外,他们还通过结合从IEC 62443安全级别定义和例如从著名的通用漏洞评分系统(CVSS -https://www.first.org/cvss/calculator/3.0)中得出的四个额外指标来确定威胁的可能性。这些指标是所需技能、所需资源、所需权限和攻击载体。第2步的结果是IEC 62443要求的威胁及其未减轻的风险列表。

 

第3步 - 反措施和安全要求的定义

在第三步,定义了减轻步骤2中确定的威胁的对策。为了便于追踪,每个对策要求都与它所缓解的威胁和它所贡献的IEC 62443 CRs/CR-REs相关联。

 

第4步 - 剩余风险的评估

在第四步,确定每个威胁的剩余风险(在实施对策后)。该风险的评估方法与步骤2中未缓解风险的评估方法相同。如果残余风险被认为是不可接受的,就必须回到步骤3来确定额外的对策。在步骤4之后,结果是一份具有未减轻风险和剩余风险的威胁清单和一份减轻这些威胁并有助于标准的CRs/CR-REs的对策清单。

 

第5步--规范和实施反措施

最后,这第五步包括根据现有的发展进程设计和实施对策。

在步骤5之后,只要系统发生变化,使威胁模型不再与开发状态同步(例如,在新的冲刺开始时),就必须从步骤1开始重复威胁分析过程。更新威胁模型以反映系统的变化,分析新引入的威胁,修改/增加对策要求,并更新风险。

 

即使62443合规性不是目标,威胁分析也应被视为主要的最佳实践之一,由处理多种类型资产的组织发起和处理。它促进了所有利益相关者对网络安全相关方面的理解,并通过确保在概念的早期阶段支持识别这些风险的务实方法,将网络风险降至最低。

如果您对威胁分析方法和/或认证标准有任何疑问,请不要犹豫,与我们的网络安全专家联系。基里安-马蒂