等保到底是个啥(六):系统建设管理部分

2019-04-18 139605人围观 ,发现 3 个不明物体 安全管理

*本文原创作者:宇宸@默安科技合规研究小组,本文属于FreeBuf原创奖励计划,未经许可禁止转载

本篇为管理要求中系统建设管理的部分,文中内容都是个人观点,如有不对的地方欢迎纠正。文章以等保三级系统为基础,从合规角度解读要求。本部分为人员安全和安全管理机构部分。

往期内容请戳:

等保到底是个啥(一):物理安全部分

等保到底是个啥(二):网络安全部分

等保到底是个啥(三):主机安全部分

等保到底是个啥(三):主机安全部分

等保到底是个啥(四):应用与数据安全部分

等保到底是个啥(五):制度与人员安全部分

正文

不多说了,直接进入正题。最后两个部分,内容比较多,分别进行解读。

7.2.4 系统建设管理
7.2.4.1系统定级(G3)
a) 应明确信息系统的边界和安全保护等级;
b) 应以书面的形式说明确定信息系统为某个安全保护等级的方法和理由;
c) 应组织相关部门和有关安全技术专家对信息系统定级结果的合理性和正确性进行论证和审定;
d) 应确保信息系统的定级结果经过相关部门的批准。

系统定级在以前并非强制,一般都是政府部门、事业单位会被要求必须定级。但是2017年6月《网安法》出台后,要求所有系统原则上都必须定级备案,这样一来,政府、国企、事业、大中型私企都要定级,只有部分很小的系统,对社会影响可以忽略不计的那种可以不去做,不过如果后期业务发展,要与大公司或政府合作,那还是要备案,所以基本就是说只要你有运行的系统就要定级备案。

对于如何定级可以参考GB/T-22240-2008,里边写的比较详细,在后边备案和测评章节会简单解释一下,因为内容比较多,五个级别,各级别的定义,三个客体,影响程度,定级矩阵,标准里都有提到。

a) 说得是边界的界定,定级以系统为单位,要明确边界,不能无限延伸,一般来说按照老的标准,从边界防火墙到核心,再到系统所在的服务器区间,以及下边可以访问该系统的PC或移动端,这一整套网络都属于该系统,那么边界就是从防火墙到用户终端这么一个圈;

b) 一般定级都会先提交系统相关的详细资料,之后会填下定级报告;国家提倡自主定级,就是企业自己组织专家组或聘请第三方专家来为系统定级,主要依据还是系统对社会影响的程度,系统的量级(参考GB/T-22240),一般来说大多系统会定为二级,一部分为三级,四级系统一般会有国家级机构来定,五级系统就不是我们操心的了。各省级测评机构最多有权测评三级系统。

c) 这块其实感觉有些多余,一般来说自定级和专家评审之后,会把定级结果送交到公安,如果合理会走后续流程,如果不合适会通知重新定级;所以这个正确性与否其实让公安来把控就好了,不过一般来说大多不会定错级,除非有些企业为了投机故意低报级别。

d) 去公安申报,先申请备案,按正常流程走就可以,这是外部流程。企业内部要对系统定级,要先向上级申请,提出某系统要进行定级备案,经高层审批通过后,开始执行外部流程。注意不要只考虑外部流程,忘了内部审批流程。

7.2.4 系统建设管理
7.2.4.2安全方案设计(G3)
a)应根据系统的安全保护等级选择基本安全措施,并依据风险分析的结果补充和调整安全措施;
b)应指定和授权专门的部门对信息系统的安全建设进行总体规划,制定近期和远期的安全建设工作计划;
c)应根据信息系统的等级划分情况,统一考虑安全保障体系的总体安全策略、安全技术框架、安全管理策略、总体建设规划和详细设计方案,并形成配套文件;
d)应组织相关部门和有关安全技术专家对总体安全策略、安全技术框架、安全管理策略、总体建设规划、详细设计方案等相关配套文件的合理性和正确性进行论证和审定,并且经过批准后,才能正式实施;
e)应根据等级测评、安全评估的结果定期调整和修订总体安全策略、安全技术框架、安全管理策略、总体建设规划、详细设计方案 等相关配套文件。

a) 本项在1.0本中解释起来有点麻烦,不过按照最近的“三同步”解释,大家都明白了,在系统设计初期就要考虑安全性的问题,如果还不太了解,可以参考SDL中安全设计阶段,一个是对软件,一个是对系统,目的相同。

b) 类似于要启动项目就要建立一个项目组团队,系统定级备案也是一样,不是一个人就能搞定的事(包括系统设计和建设),然后要有项目计划,这点不难理解。

c) 这里说的是提前规划的情况,目前大多数还是先有系统后做定级,这种三同步的规划没多少企业会真正落实,规划周期长,设计复杂,而且当年没有强制性要求,没人关心定级的事;本项要看的就是系统当初设计时的设计文档,各阶段的记录和报告,类似于SDLC。

d) 本项是c的后续流程,按照正常流程,设计方案要内部评审,通过后才可正式实施,不过做到这么细的国内公司还是少数,而且中间的记录文档也不全,检查的时候很多东西都是临时伪造,补充出来的,其实这部分主要强调的还是流程管理的东西,检查时能拿出系统设计方案内部评审报告和记录就OK.

e) 按照要求二级系统2年一次复测,三级系统1年一次复测,这期间系统多少会有功能上的变更(如果有大变化就要重新定级),这样一来,系统相关的文档肯定会有变化,本项检查的就是不同版本变化中的过程文档和记录。

7.2.4 系统建设管理
7.2.4.3产品采购和使用(G3)
a)应确保安全产品采购和使用符合国家的有关规定;
b)应确保密码产品采购和使用符合国家密码主管部门的要求;
c)应指定或授权专门的部门负责产品的采购;
d)应预先对产品进行选型测试,确定产品的候选范围,并定期审定和更新候选产品名单。

本节内容没什么可细讲的,都是按照相关标准采购设备和产品,采购部门基本会按照这些要求来选择供应商。这里额外会要求一点:政府、国企、央企和国资背景企业的关键系统不能使用国外网络产品(Ciso、Juniper这类),私营企业没有这方面的要求。如果有可能,尽量采购国产产品和软件。

7.2.4 系统建设管理
7.2.4.4自行软件开发(G3)
a) 应确保开发环境与实际运行环境物理分开,开发人员和测试人员分离,测试数据和测试结果受到控制;b) 应制定软件开发管理制度,明确说明开发过程的控制方法和人员行为准则;
c) 应制定代码编写安全规范,要求开发人员参照规范编写代码;
d) 应确保提供软件设计的相关文档和使用指南,并由专人负责保管;
e) 应确保对程序资源库的修改、更新、发布进行授权和批准。

有自己开发团队的情况下:

a) 一般来说,测试环境基本都是封闭的,和外网、生产网、办公网这些都没有通信,这单还比较容易做到;开发人员和测试人员分离,一般可能做不到,毕竟经常要在一起讨论,所以实际检查中,更多的是关注测试环境的隔离情况。

b) 检查中会查看开发人员的行为规范和操作规范,开发部门管理制度等一系列文档;

c) 编码规范估计每家公司都会有,但不是有就可以,要看你有没有去按照规范去做,一般就是日常的编码规范和编码安全培训,以及在行为准则中如何规定的。

d) 本点要求是系统要有开发各阶段的文档,以及系统的使用手册/指南,往往都是各阶段文档齐备,但是缺少使用指南(文档和指南都是便于交接工作,由于人员变动,时间久了很多东西根本不从查起,如果没做好文档和流程管理,就会造成新人接手系统一问三不知的情况)。由专人负责保管这项不是重点,因为临时安排一个人来应付检查,也没法查出来。

e) 还是流程的事,版本变更,功能上线,系统发布都要有过程记录。

7.2.4 系统建设管理
7.2.4.5外包软件开发(G3)
a)应根据开发需求检测软件质量;
b)应在软件安装之前检测软件包中可能存在的恶意代码;
c)应要求开发单位提供软件设计的相关文档和使用指南;
d)应要求开发单位提供软件源代码,并审查软件中可能存在的后门。

外包第三方开发团队的情况:

a) 系统的功能测试,压力测试等,要保留测试报告以备检查;

b) 系统安全测试,白盒、黑盒、交互式等的测试,要有系统上线前的安全测试报告,并且对发现的漏洞已进行整改(一般是针对中高危级别的漏洞);

c) 很多企业外包开发,系统功能OK就可以了,需求文档、设计文档、设计方案、测试文档全都没有,检查的时候,外包商又说之前的员工离职了,现在这个系统的具体信息我们也不太清楚,这种局面就很闹心了;所以说,对外包商要求严一点,以后给自己找的麻烦就会少一点。

d) 和b有点重复,类似于代码审计工作,一般中小企业不太会花钱去做这块,大多找个开源工具扫一下,挑几个高危的修修了事。大型企业这块做的比较好(接触过的几家),各种安全测试、代码审计、渗透测试,能做的都会做,虽然不强制要求中小企业也这么去搞,但是希望在能力范围能尽力去做好安全工作,不要为了应付检查做一下表面工作。

7.2.4 系统建设管理
7.2.4.6工程实施(G3)
a)应指定或授权专门的部门或人员负责工程实施过程的管理;
b)应制定详细的工程实施方案控制实施过程, 并要求工程实施单位能正式地执行安全工程过程;
c)  应制定工程实施方面的管理制度,明确说明实施过程的控制方法和人员行为准则。

无论自研还是外包,肯定都会指定一个项目经理,一般来说会是甲方的人,也可能叫负责人,乙方的叫项目经理,主要就是负责把控项目进度和质量。实施部分要有详细的实施方案,进度计划表,启动会记录,里程碑记录,变更记录,延期记录(如果有的情况)。甲方对于项目实施会有一些管理制度,保密协议之类的,检查的时候不会非常细,但是会看各阶段的文档记录,以证明项目是按照计划和流程稳步推进的。

7.2.4 系统建设管理
7.2.4.7测试验收(G3)
a)应委托公正的第三方测试单位对系统进行安全性测试,并出具安全性测试报告;
b)在测试验收前应根据设计方案或合同要求等制订测试验收方案,在测试验收过程中应详细记录测试验收结果,并形成测试验收报告;c)应对系统测试验收的控制方法和人员行为准则进行书面规定;
d)应指定或授权专门的部门负责系统测试验收的管理,并按照管理规定的要求完成系统测试验收工作;
e)应组织相关部门和相关人员对系统测试验收报告进行审定,并签字确认。

a) 一般开发团队不会负责安全问题,所以会由安全团队来做测试,大多是以第三方就是乙方来做安全测试(代码审计、黑盒、渗透、基线等等);如果有自己的安全团队也可以内部来搞,但是不能水,要认真测试。检查时会看测试报告,包括代码审计报告、渗透测试报告、漏扫报告等。

b) 这点要求的就是两个文档,一个是验收方案(甲方会明确怎样才算合格);另一个就是验收报告,里边约定验收结果,并由甲乙方盖章签字。

c) 说实话这条我也没详细查过,一般都是略过去,所以无法解释,有了解的可以留言补充一下;

d) 这点很好理解,制定专人或部门来管理验收工作,临时指定等项目结束再解聘也是可以的,不过要有文档能证明此项工作;

e) 一般都会在项目验收(报告会)同时进行,高层领导、技术专家也会出席,同意后才会盖章签字,可以在项目验收会的签到表中体现。

7.2.4 系统建设管理
7.2.4.8系统交付(G3)
a)应制定详细的系统交付清单,并根据交付清单对所交接的设备、软件和文档等进行清点;
b)应对负责系统运行维护的技术人员进行相应的技能培训;
c)应确保提供系统建设过程中的文档和指导用户进行系统运行维护的文档;
d)应对系统交付的控制方法和人员行为准则进行书面规定;
e)应指定或授权专门的部门负责系统交付的管理工作,并按照管理规定的要求完成系统交付工作。

交付部分很容易理解,不需要详细解释了吧。同验收部分一样,d项检查的时候没有特别要求客户去做,所以这块还是不太了解。其他部分类似的。

7.2.4 系统建设管理
7.2.4.9系统备案(G3)
a)应指定专门的部门或人员负责管理系统定级的相关材料,并控制这些材料的使用;
b)应将系统等级及相关材料报系统主管部门备案;
c)应将系统等级及其他要求的备案材料报相应公安机关备案。

7.2.4.10等级测评(G3)
a)在系统运行过程中,应至少每年对系统进行一次等级测评 ,发现不符合相应等级保护标准要求的及时整改;
b)应在系统发生变更时及时对系统进行等级测评,发现级别发生变化的及时调整级别并进行安全改造,发现不符合相应等级保护标准要求的及时整改;
c)应选择具有国家相关技术资质和安全资质的测评单位进行等级测评;d)应指定或授权专门的部门或人员负责等级测评的管理。

备案和测评这两部分放在一起来说,是一个连续的过程。

定级前要知道的几点,等级保护制度主要监管方式公安部,分为五个级别,涉及三个客体,即:

a) 公民、法人和其他组织的合法权益;

b) 社会秩序、公共利益;

c) 国家安全。

对客体的危害程度分为三个级别:

a) 造成一般损害;

b) 造成严重损害;

c) 造成特别严重损害。

了解了这些基本的定义后,就好解释了。定级依据的矩阵如下:

如何来定级的流程如下:

定级备案其实是一起的,要先到当地公安进行备案,然后会让你提交一堆文档,包括:备案表、工作自查表、基本情况调研表等等;此后要先自定级,提交定级报告;再之后聘请测评机构对系统进行测评—整改—复测—下发备案证明—每年监督检查。

总结一下基本是这样一个流程:

如果定级备案后,系统有较大变更,比如新增一个模块,需要聘请专业机构进行重新定级,上述流程要重新再来一次。如果这种情况不报,被年检查出来,企业和负责人要接受警告或处罚。(详细的可以参考22240)

7.2.4 系统建设管理
7.2.4.11安全服务商选择(G3)
a)应确保安全服务商的选择符合国家的有关规定;
b)应与选定的安全服务商签订与安全相关的协议,明确约定相关责任;
c)应确保选定的安全服务商提供技术培训和服务承诺,必要的与其签订服务合同。

属于第三方管理制度范畴,这里说的比较简单,至少要有供应商管理制度、供应商服务合同、服务详细说明等文档。推荐看一下ISO 27002中15 供应商关系部分的细节(内容较多,不进行扩展了)。

结语

以上为管理要求在系统建设管理部分的要求。内容比较多的一部分,更多的是强调流程和记录。如果看过ISO27002或者C5(今年开始叫做COBIT2019了),那么理解起来就很容易了。

*本文原创作者:宇宸@默安科技合规研究小组,本文属于FreeBuf原创奖励计划,未经许可禁止转载

发表评论

已有 3 条评论

取消
Loading...

特别推荐

推荐关注

填写个人信息

姓名
电话
邮箱
公司
行业
职位
css.php