作者：薄云览

国务院令745号《关键信息基础设施安全保护条例》，对能源、电信、交通等八大关键信息基础设施的安全保护进行了顶层设计。在轨道交通领域，安全认证、安全评估并不陌生，两者有什么差异，如何理解网络安全与现有安全的要求，本文参考国际通行的相关标准，谈谈它们之间的关系。

Safety和Security经常都叫做安全，容易混为一谈，在英文中具有不同的意义。在系统工程的术语中，Safety指系统的安全性，Security指系统的安保性。在轨道交通领域，Safety用于指功能安全，Security用于指网络安全。下面介绍下这两个概念的联系和区别，为了避免歧义，这两个名词分别用功能安全和信息安全表示。

原则1：功能安全和信息安全是不同的概念，应该区别对待。

这两者在概念上有

  • 互补的目标：功能安全主要是为了保护人或环境免受自动化系统故障的影响，而信息安全则是为了保护系统免受来自环境的攻击。

  • 不同的监管机构，例如，城轨领域，中国的交通运输部和国家网信部门；欧洲铁路的欧盟铁路局（ERA）和欧盟网络与信息安全局（ENISA）等。

  • 不同的管理方式，如功能安全方面的危害（hazard）风险管理相对于信息安全方面的威胁（threat）风险管理。

  • 不同的标准，例如，轨道交通RAMS（包括功能安全）的GB/T21562系列和信息安全的ISO27000或IEC62443系列。

  • 不同的变化适应性，功能安全要求尽量避免变更带来的不确定性，信息安全则要求及时更新以修补漏洞。现在的趋势是尽可能地将safety与security隔离开来。

两者的要求往往相互冲突。例如，紧急关闭信号（例如，立即关闭或停止一个系统）。从safety的角度来看，该信息应该尽可能快地被传送，并且应该立即执行反应。从security的角度来看，信息应该被验证，以防止伪装，如果攻击者可以简单地发送紧急信息，至少可能导致DoS。但是，加密代码的计算和检查会消耗时间，导致紧急信息和反应的延迟。因此，在两者设计中的权衡是不容易的，有时很难找到一个最佳解决方案。它们不能轻易合并，此外，security不能简单地被视为safety的附加物，反之亦然。

原则2：信息安全环境应保护系统的基本功能，包括功能安全。

功能安全应控制系统的内部影响和外部影响，以保证safety。在外部影响的控制要求中，其中要涵盖的一个方面是访问保护，这也是信息安全与功能安全的接口所在。

从信息安全的角度，例如IEC 62443。Safety属性被认为是需要保护的系统基本功能。其他基本功能是操作功能或可用性。这意味着功能安全只有在适当的安保环境中才能实现其预期用途。

原则3：风险分析是信息安全与功能安全的协同接口。

两者概念上的差异，将安全和安保结合是不合理的。然而，系统生命周期需要协同，需要建立适当的接口。特别是在功能安全风险分析中，需要确定由信息安全导致的危害，然后在网络安全威胁风险评估中把它们作为威胁。在这里，Safety工程师需要提供支持，以便在网络安全评估期间评估对系统Safety属性的影响，但适当的Security对抗措施的推行是security工程师的责任。

原则4：尽可能将安保和安全分开，但要有效协调。

应解决已确定的安全措施和安保措施之间的冲突。在现有的城轨安全风险评估期间，评估员评估被评估对象系统设计的Safety影响，其中包括其security要求的实施（注意，安全评估员并不评估所设计解决方案的security）。在这里，Security方面已提供对应的管理证据，例如具有明确说明的假设和应用规则的可信的验证文件，那么Safety和Security评估可以解耦。

原则5：应根据国际标准，如IEC62443，对security进行评估。

如果safety和security是紧密结合的，那么security方面的任何变化都可能导致Safety安全案例失效。一个有效的策略是，从安全案例的角度来看，只依靠security功能的那些部分来创造一个保证安保性的环境和应用规则。因此，如果security功能和应用规则都保持不变，即使安全SW被更新，安全案例仍然有效。然而，应该提供证据证明这些变化对safety没有影响。

功能安全标准EN50129中，建议仅在安全案例中参考security分析。为了便于整合和兼容，建议将security考虑建立在既定的国际标准上，如ISO 27000或IEC 62443。

原则6：以概率方式评估信息安全风险不可行。

与safety有关的security问题之所以发生，是因为系统的完整性受到了威胁。这些威胁来自攻击者，他们利用安全环境中的漏洞。攻击者根据一定的攻击或黑客技术，利用他们可以获得的关于系统的所有信息，有意地采取行动。这个攻击程度可能是不同的，取决于攻击者的能力水平。因此，与safety不同的是，不存在攻击的概率或失效率。与safety的相似之处是，security威胁的原因与safety中的系统故障相似。漏洞通常来自于安全功能的错误，主要是软件，这与safety中的软件故障相似。

原则7：Safety与Security目标措施不应相互耦合。

在IEC 62443，Security等级（SL）是根据攻击者的类型来定义的。SL 1仅代表无意的错误或可预见的误用，而SL 2、SL 3和SL 4则与故意攻击有关，攻击者拥有越来越多的知识、动机和资源。由于safety角度认为security是一种外部环境条件，因此，根据任何特定的SIL采取的措施并不包括针对故意攻击的措施，这是显而易见的。然而，错误和可预见的滥用也需要由安全系统来解决，所以任何safety系统也应该涵盖SL1级的要求，至少是与完整性有关的要求。但是，对于其他SL等级来说，SL和SIL之间没有必然的对应关系，因为SL总是取决于安全环境。还应注意的是，安全要求不能只通过IT措施来实现，物理安全措施也是必要的。

原则8：Security是一种协作性的持续努力。

信息安全是运营方（在安全方面通常被称为资产所有者）、系统集成商（提供完整的系统）和供应商（部件提供方）的共同努力，在国内，运营方对网络安全保护付总责。与safety不同的是，评估过程在security方面的运作频率更高。即使没有任何事故，每年至少更新一次威胁风险评估，并将结果向前和向后反馈给接口的利益相关者，是很好的实践做法。与功能安全类似，有效的网络安全保护在很大程度上依赖于公司文化。

声明：本文来自薄说安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。