等保2.0即将发布,对工控安全的几点思考
作者: 日期:2019年04月10日 阅:3,671

近日,一则等保2.0标准有望在4月出台的消息,刷屏了笔者朋友圈。诚然,2016年度等保大会上,网络安全保卫局宣布等级保护进入2.0阶段。而等保2.0的编制更是要提前到2014年,数十家单位历经5年调研、讨论、编写,标准框架结构经历两次大幅修订,终于在2018年四季度提交国家标准化管理委员会报批。本次官宣被普遍认为“第二只靴子” 要落地了。笔者作为工控安全行业从业者,对等保2.0的发布亦是望眼欲穿。

等保2.0标准是一系列文件,最基本的应包含如下三个文件,经了解,如4月发布,以下三个标准会同期发布。

  • 《信息安全技术 网络安全等级保护安全设计技术要求》
  • 《信息安全技术 网络安全等级保护基本要求》
  • 《信息安全技术 网络安全等级保护测评要求》

一般提及等保2.0标准,多代指《信息安全技术 网络安全等级保护基本要求》,下称《基本要求》

在阅读《基本要求》过程中,对于标准中部分要求在工业控制系统领域的应用、实施总结了些思考,与大家探讨。

等级保护两次被《中国人民共和国网络安全法》(下称:《网络安全法》)“点名”,第一次明确国家实行网络安全等级保护制度,第二次就明确了关键信息基础设施要在网络安全等级保护制度的基础上,实行重点保护。官方材料“关键信息基础设施的安全保护等级不低于第三级”的论断也符合网络安全从业者的基本判断。能源、交通、水利、金融、公共服务作为关键信息基础设施的主力军,在其生产网络开展安全建设势在必行。

《网络安全法》

第二十一条

国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求,履行下列安全保护义务,…………

第三十一条

…………关键信息基础设施,在网络安全等级保护制度的基础上,实行重点保护。关键信息基础设施的具体范围和安全保护办法由国务院制定。…………

对于企业组织、人员的要求

无论是《网络安全法》还是《基本要求》均要求企业设置专门安全管理机构和安全管理负责人。建议组织形式上应按三级开展架构设置,以总经理或分管副总牵头的决策层,以IT或生产主管为主的监督指导层,以专职和兼职的技术人员任职的执行层。在人员管理上从录用、离岗、培训教育等方面开展工作,要求在岗人员能力满足、保密协议已签,离岗人员权限清零、调离手续严格,外部人员全程陪同、最小权限、保密协议已签。做到企业网络安全方针策略明确,安全要求下达通畅、安全问题上送无阻,安全管理制度流程健全、监督严格,安全管理、技术措施执行到位。

对安全方案、技术产品的选择

在介绍本部分之前,我们花一点时间再介绍一下当前《基本要求》,近期依然看到不少文章还在用旧版本做解读和引用。如上文所述,《基本要求》在整体架构上有两次大幅修订,用下表对比一下这两次变化。(以第三级安全要求为例)

从上表中不难看出,《基本要求》编制专家组在文档整体架构描述逻辑上一直在寻求工控安全业务和网络安全技术相融合、协调,最终选定的方案在笔者看来具备良好的可阅读性和可操作性,也同时解决了设计要求和基本要求脱节的问题,早在GB/T 25070-2010 《信息安全技术 信息系统等级保护安全设计技术要求》中就已经提出“一个中心、三重防护”即“……通过第三级的安全计算环境、安全区域边界、安全通信网络以及安全管理中心的设计加以实现。”。网络安全最高频词汇“纵深防御”在基本要求标准上终于落地。

  • 可信机制成为优选项
8.1.4 安全计算环境

……

8.1.4.5 恶意代码防范

应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为,并将其有效阻断

8.1.4.6 可信验证

……在应用程序的关键执行环节进行动态可信验证, 在检测到其可信性受到破坏后进行报警,并将验证结果形成审计记录送至安全管理中心。

……

2000年初,可信的概念就在中国落地发芽,经过近20年的积累、发展终于在《基本要求》中明确体现。尤其是在恶意代码防护要求中提到的主动免疫可信验证机制在工业控制系统安全领域非常适合,已经成为工控安全病毒防护的主流技术选择,AWL(Application WhiteListing)经过近几年工控安全产业实践,基于应用程序启动控制的“白名单”技术由于其资源占用小、兼容性好、可抵御“0day”,尤其是不存在升级且规避了杀毒软件误杀的问题已经被广泛接受和应用。公安部计算机信息系统安全产品质量监督检验中心对应AWL的检测标准“文件加载执行控制”已经有40家企业通过检测,几乎是所有工控安全从业厂商不二的选择。面对越来越复杂难缠的恶意程序,如载体为“脚本”、“宏”,传播通过“远程溢出”等方式,对于企业业主来说市面产品过于“琳琅满目”,不少产品还停留在针对exe、bat、dll文件甚至进程级的控制,面对越来越高级的病毒传播方式显得束手无策,自身都漏洞百出。考察一款AWL产品是要特别注意以下三点:

1、AWL产品支持的PE文件类型种类是否丰富。

2、AWL产品自身强壮性是否可靠。

3、AWL产品工程实施是否具备可行性。(上来就安装程序而不做先期查毒清毒工作,对工业主机病毒防护简直是灾难)

除了工业主机恶意代码防范采用可信机制,目前工业防火墙、工业流量监测审计等产品也都普遍采用“白名单”机制,可信思想的核心机制“认证”、“度量”在工业控制系统的特殊环境下得到了充分的发挥和应用。

  • 边界明确要求单向隔离
9.5.2 安全通信网络(扩展要求)

9.5.2.1 网络架构

a) 工业控制系统与企业其他系统之间应划分为两个区域,区域间应采用符合国家或行业规定的

专用产品实现单向安全隔离

……

相信大部分业主看到这条要求,第一反应就是不可能,“生产网和办公网还混在一起呢”、“生产网里面还有视频呢”、“生产网给办公网送数据,两边通信还是TCP协议呢”、“办公网和生产网还共用一个三层核心呢”种种种种……。笔者在看到这条要求的时候,站在网安从业者角度我认为没错,确实物理上保证了不会有恶意流量从边界进入生产网,但站在业主角度,业务完整性和安全性确实难以两全。基于此建议如下:

  • 着手开始“两改”工作,一是逐步开始双网改造,如生产控制网和视频网的分离,暂时做不到物理隔离的,就先做到逻辑隔离如划分vLan;二是生产办公隔离措施两边的应用做单向通信改造,如UDP。
  • 在“两改”完成前,利用防火墙或双向隔离网闸完成安全隔离,安全策略要严格,通常在隔离措施两边的通信不会是多对多,ACL要仔细设置;隔离措施应能检测工业控制协议并阻断,在生产和办公之间通常不会有控制协议,最多会出现数采协议如OPC。
  • 在边界处部署基于流量的恶意代码检测和漏洞利用监测措施。
  • 对于新建网络,初期就应在网络架构设计和应用的选取上就考虑此问题。电力生产企业是非常好的范例,所有电力生产企业的生产控制大区和管理信息大区之间必须实施专用正反向隔离装置,效果良好。
  • 设立安全管理中心
8.1.5 安全管理中心

……

8.1.5.4 集中管控

a) 应划分出特定的管理区域,对分布在网络中的安全设备或安全组件进行管控;

b) 应能够建立一条安全的信息传输路径,对网络中的安全设备或安全组件进行管理;

c) 应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测;

d) 应对分散在各个设备上的审计数据进行收集汇总和集中分析,并保证审计记录的留存时间符

合法律法规要求;

e) 应对安全策略、恶意代码、补丁升级等安全相关事项进行集中管理;

f) 应能对网络中发生的各类安全事件进行识别、报警和分析。

……

在GB/T 22239—2008中,在技术要求部分没有明确要求设置管理中心,在其“管理要求—>系统运维管理下—>监控管理和安全管理中心c)应建立安全管理中心,对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。”,然而这里的安全管理中心与当前《基本要求》的安全管理中心从内涵和外延上都有显著差异,当前的安全管理中心一是承担着对现网安全设备、安全软件策略管理、告警收集、日志分析的基础任务,二是承担对当前网络开展脆弱性评估、威胁行为识别、设备状态采集、安全事件溯源、安全指数量化等进阶任务。

在工控网络下,工控网络通常物理范围较大,厂房较多,对于安全设备仅提供就地管理显然不合适,更不要说SCADA一类的工控系统了,安全管理中心大幅提高了运维管理效率,同时更关键的一点也充当了安全管理员的“眼睛”,网络安全的价值不再是“No news is good news”,价值通过可视化的角度以丰富的样式、统计、分析得以展现。

时下,“网络安全态势感知”是圈里最时髦的词,《基本要求》对于安全管理中心的强调刚好为整体态势感知提供了基础条件。尤其对生产企业集团层面,基于生产侧的安全管理中心构建的中心级平台既能对集团生产网络安全做宏观掌控,亦能对具体企业做安全建设指导,在安全管理上实现闭环。

  • 强调基于业务需求的“最小化”
8.1.4 安全计算环境

8.1.4.2 访问控制

……

b) 应重命名或删除默认账户,修改默认账户的默认口令;

c) 应及时删除或停用多余的、过期的账户,避免共享账户的存在;

d) 应授予管理用户所需的最小权限,实现管理用户的权限分离;

……

8.5.4 安全计算环境(扩展要求)

8.5.4.1 控制设备安全

……

c) 应关闭或拆除控制设备的软盘驱动、光盘驱动、 USB 接口、串行口或多余网口等,确需保留的应通过相关的技术措施实施严格的监控管理;

……

最小化权限是网络安全策略设计的一般概念和常规措施,无论是业务人员、IT运维管理人员此类的实体用户,还是操作系统用户、数据库用户此类的虚拟主体,在为其分配操作权限、范围边界时都要按照“所需即所得”的原则来处理。这里收缩权限、框定范围并不是对实体用户或虚拟主体的完全不信任,而是在最小化权限下一旦出现事故,其范围、程度也是最小的,是一种典型风险控制的机制。

笔者在这里对“最小化”做一点延伸,目前公认的工控安全防护技术路线“白名单”也是在做一种“最小化”,通过对工控业务的学习建立最小化行为模型,这个模型越逼近真实业务轮廓,安全防护、异常检测的效果就越好。在工业控制系统环境下,业务相对清晰,允许用技术语言描述业务行为,无论是权限管理上的最小化还是基于业务的 “白名单”都是为生产提供“充分必要”的同时保障安全可靠。

等保2.0的发布势必会释放不少处于观望的市场空间,如何更好的为生产企业提供更优秀的解决方案与产品是我们必须要回答的问题。工控安全无论是市场还是技术都还有很大的成长空间,对于关键信息基础设施的安全保护是网安人的责任与荣耀,希望借本文抛砖引玉,共同推进工控安全市场与技术的蓬勃发展。

 

关键词:

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章