作者:薄云览

国务院令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。