微信号:freebuf

介绍:国内关注度最高的全球互联网安全新媒体

等保到底是个啥(七):系统运维管理部分

2019-04-23 18:37 lywhiz

本篇为管理要求中系统运维管理的部分,等级保护中内容最多的一个章节。文中内容都是个人观点,如有不对的地方欢迎纠正。文章以等保三级系统为基础,从合规角度解读要求。

前序文章(请点击底部阅读原文查看):

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

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

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

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

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

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

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

正文

本部分内容有些地方看起来可能会和技术要求差不多,但是从管理和流程方面来约束的,主要考察管理制度的运行情况。本部分内容较长,建议各位分段看,全部阅读起来可能会需要较长时间。

7.2.5 系统运维管理

7.2.5.1 环境管理(G3)

a) 应指定专门的部门或人员定期对机房供配电、空调、温湿度控制等设施进行维护管理;

b) 应指定部门负责机房安全,并配备机房安全管理人员,对机房的出入、服务器的开机或关机等工作进行管理;

c) 应建立机房安全管理制度,对有关机房物理访问,物品带进、带出机房和机房环境安全等方面的管理作出规定;

d) 应加强对办公环境的保密性管理,规范办公环境人员行为,包括工作人员调离办公室应立即交还该办公室钥匙、不在办公区接待来访人员、 工作人员离开座位应确保终端计算机退出登录状态和桌面上没有包含敏感信息的纸档文件等。

这里又把物理安全的内容重新提了一遍,但重点是管理而非技术。

a) 机房的日常巡检,一般是每日,也可以是三日,最多不能超过一周,不然有些说不过去;这类工作大部分是由运维来负责,除了设备状况和信息告警这类常规检查外,环境和设施也要检查,比如温湿度是不是在合理范围内、灭火系统的压力表是否正常(对于指针位于红色区域的灭火器材要及时更换)、强电设备及UPS运行状况有无异常、机房内有无凝露的情况等等。并且要有巡检的记录和巡检人签名。

b) 本条要求一般只要不是配线间级别的机房都会做得差不多,可能有些企业不会去做各种访问记录、操作记录,但检查时看的就是这些记录文档;从管理角度来看,这些基础的工作还是要做起来的,不能偷懒。

c) 小企业可能没有机房制度或者太简单,大中型企业一般都有,这类制度目前大同小异,都是模板式的文档,可以根据自身情况修改一下,做成宣传板挂到机房或管理室的墙上。

d) 这里是一些安全意识细节,也是不好管理的点,毕竟制度和要求可以有,具体能执行的如何没办法有效控制。本条只是举了几个例子,其实目前不是检查,而是督促企业加强安全意识教育和宣传,不要因为缺少相关意识给企业带来损失,不只是资金上,大公司还有企业形象层面的社会影响。

这里提的就是离职人员,一定要第一时间收回各种权限,门禁、钥匙之类物品;工作设备不用时要手动锁屏,或设置自动锁屏;关键区域外人及无关人员不得访问;敏感类资料不要直接放在桌面,纸质材料不能随便至于办公桌,会议讨论的方案或系统架构类的信息要及时清除(在白板上临时写的一些内容)。

这类细节其实很多,标准不可能穷举。

7.2.5.2 资产管理(G3)

a) 应编制并保存与信息系统相关的资产清单,包括资产责任部门、重要程度和所处位置等内容;

b) 应建立资产安全管理制度,规定信息系统资产管理的责任人员或责任部门,并规范资产管理和使用的行为;

c) 应根据资产的重要程度对资产进行标识管理,根据资产的价值选择相应的管理措施;

d) 应对信息分类与标识方法作出规定,并对信息的使用、传输和存储等进行规范化管理。

资产管理一直都是大事,但一直不被重视,大多数公司摸不清自己的家底,存在边缘资产。这种情况无论是管理还是安全层面都是潜在风险,等被人搞了才知道原来自己还有这么个东西在网络中。

a) 由于标准比较老,这里提的还是纸质的资产列表清单,当前来看基本都是电子清单或者是资产统一管理平台。建议如果有预算还是上一套资产管理系统,若是没钱,那就辛苦点进行资产梳理,尽可能避免存在边缘未知资产。这里其实对于自己的东西还好(接触过一个CIO,下边每个员工的鼠标键盘他都清楚,对资产管理非常重视,但是提到外包人员在企业内部新建的资产清单情况,瞬间就心虚了),重点是第三方人员的管理,比如外包开发软件,要利用企业资源搭建开发环境,测试环境,安服方面演练可能还会搭个靶场什么的,这帮人装了多少个虚拟机,建了多少个数据库,开了多少端口,哪些设备连了外网,这些作为甲方坑内不可能全都弄清楚,那么项目交付后,这些临时的资产(硬件、软件、信息类)是否全部下线或卸载,以我的实际经历来看,大多安全主管、运维主管都不清楚,CIO就更不知道了。所以,这里建议由系统去自动发现和管理资产,尽可能减少人为低级别工作的参与度。

b) 有了上述的资产管理系统,制度就相对没那么重要了,但不代表没用,要约束一些基本原则和流程。

c) 资产梳理清晰之后,就要进行分类分级了,和数据类似,有高中低之分,目的是明确哪些是关键资产,重点保护,出现问题时要优先处理;对于硬件资产要粘贴不易撕除的标签,说明资产类别、编号、SN号等信息,检查时候会看。

d) 本条其实应该在c前边,对于资产分类分级的依据说明,有点像应急预案中的安全事件等级定义;此外后边还提到了对信息的访问权限、传输和存储管理,可以归为数据治理范畴,本人没有深入接触,所以只能提一句。等级测评时,主要做到不用级别的数据有访问权限设置,低级用户访问高级数据要提交申请,审批后才允许访问,并对这个过程进行记录(各种日志),敏感信息存储要加密或专业的防护措施,传输过程要对通信加密。一般能做到这几点,本条的要求点也就基本满足了。

7.2.5.3 介质管理(G3)

a) 应建立介质安全管理制度,对介质的存放环境、使用、维护和销毁等方面作出规定;

b) 应确保介质存放在安全的环境中,对各类介质进行控制和保护,并实行存储环境专人管理;

c) 应对介质在物理传输过程中的人员选择、打包、交付等情况进行控制,对介质归档和查询等进行登记记录,并根据存档介质的目录清单定期盘点;

d) 应对存储介质的使用过程、送出维修以及销毁等进行严格的管理,对带出工作环境的存储介质进行内容加密和监控管理,对送出维修或销毁的介质应首先清除介质中的敏感数据,对保密性较高的存储介质未经批准不得自行销毁;

e) 应根据数据备份的需要对某些介质实行异地存储,存储地的环境要求和管理方法应与本地相同;

f) 应对重要介质中的数据和软件采取加密存储,并根据所承载数据和软件的重要程度对介质进行分类和标识管理。

介质管理在检查中算是一个重点,但是很多企业做得都不太好,包括一些大型知名企业,安全防护是做的不错,但一到内部管理流程就一塌糊涂。

a) 介质管理制度一定要求,哪怕简单的十几行也可以;网上素材也有,参考一下结合企业实际情况进行可落地的制度修订。

b) 介质要有专门的存储空间,可以是仓库,可以是保密室、也可以是办公室,只要你能保证存放在此空间的介质得到有效保护就行,并且要制定专人管理(没说不能兼职);一般我看到的多数就是一堆移动硬盘、U盘直接放某人的抽屉里(磁带之类的一般还都有仓库存放),或者放档案柜里。别说保护了,就是当一堆办公用品在管。不过换个角度来看,外人也不知道这些东西会涉密,感觉就是一堆垃圾随便乱堆。

c) 这块我接触到的企业没有做到的,要求介质在运输(物理传输太书面了)中要有相关要求和操作,保证数据安全;介质也算资产,包括里边存储的数据,要盘点列入资产清单,存储敏感信息的介质使用和查看都要有审批和记录。这点我印象比较深刻的好像是亚马逊云的一个产品,好像叫Snowball,主要用于灾备运输,就是这玩意。

d) 本条就是对介质使用、维修及销毁的管理,对于环境外介质使用的加密和监控很难管理,这部分更多的还是建议制度和追责相结合,毕竟不是谁都有钱搞DLP的,而且企业越大DLP越难实施。至于送修可能不太可能,除非意外,没做备份,介质里的数据很重要,必须去做数据恢复,那么这又涉及到恢复人员可能读取或窃取企业资料的问题,尽量避免这种情况发生。销毁比较好说了,报废的介质,尽可能彻底销毁,不要叫给外部专业机构去做,除非量特别大,一般可以给员工发个锤子,拿着一堆介质去房间里发泄一下,尤其是研发同学(开玩笑)。测评时重点会看介质管理制度,使用、维修、销毁、外带的约束,此外这些操作的记录要有。

e) 就是异地场外备份,此外某些机密信息(非数据库、用户信息数据)电子档,要异地进行备份;后边还提到了一句备份的方式和要求必须一致,不能异地备份有另外一套策略。

f) 在前边几条我已经一起啰嗦出来了,什么DLP啊,资产分类分级啊;如果难以实施,那么最起码的介质分类要做,这个不费时间,加密实在不行就用bitlocker,一人管理介质,一人管理密钥(虽然不是很靠谱,但没办法穷嘛),或者买个保险柜专门保存介质,一人负责档案室大门钥匙管理,另一人负责保险箱密码和钥匙(不能都由一个人去管,容易出事)。这是最便宜的控制方式了,此外介质上要有标签。

7.2.5.4 设备管理(G3)

a) 应对信息系统相关的各种设备(包括备份和冗余设备)、线路等指定专门的部门或人员定期进行维护管理;

b) 应建立基于申报、审批和专人负责的设备安全管理制度,对信息系统的各种软硬件设备的选型、采购、发放和领用等过程进行规范化管理;

c) 应建立配套设施、软硬件维护方面的管理制度,对其维护进行有效的管理,包括明确维护人员的责任、涉外维修和服务的审批、维修过程的监督控制等;

d) 应对终端计算机、工作站、便携机、系统和网络等设备的操作和使用进行规范化管理,按操作规程实现主要设备(包括备份和冗余设备)的启动/停止、加电/断电等操作;

e) 应确保信息处理设备必须经过审批才能带离机房或办公地点。

偏运维的管理,包括的制度其实比较多,差不多每一条都要有一个对应的制度,而且,最特么烦的就是没个制度都要跟一个流程,都要有过程记录(可以是电子流程),这就很麻烦了,不过大企业标准流程就是这么搞的,真正跑起来之后其实也不错。

a) 机房巡检里包括这些内容,具体分工各企业会有不同,可以在监控平台进行自动化巡检,比当年省心多了。

b) 设备管理制度要求,信息类物品的采购要有规范,一般是采购部的事情,所以这块的制度我没有写过。

c) 这部分和巡检有重叠,定期巡检查看设备状况也算是维护的一个环节,不过从后半句的描述来看,应该是指与供应商之间的设备维修、更换、升级一类的制度,可以简单写几条。一般来说,企业申请设备维修或更换都会提审批,所以流程应该不会少,就看有没有人管理这些记录。;

d) IT部门员工操作规范/手册,呵呵,大多企业都没有,不过也不算重点项,有最好,没有也无妨,如果人手够,事情不太多,可以试着做一下,好处也是有的,记得要添加主要设备的启动/停止、加电/断电操作方法。

e) 这点对于当前的企业来说,我觉得是废话,没有谁会不打招呼直接把核心交换、防火墙或路由器拆走带出去吧。如果真有,那这种公司我觉得就不要搞什么IT了,不适合。检查时,一是看机房制度,二是看审批记录。一般是设备维修或更换才会带离机房。

另外在终端层面,做得好的公司都会有策略,确保外部办公设备的保密性;做得不好的,压根不担心,因为那些东西丢了也无所谓。重点还是制度宣传,追责和惩罚来约束。

7.2.5.5 监控管理和安全管理中心(G3)

a) 应对通信线路、主机、网络设备和应用软件的运行状况、网络流量、用户行为等进行监测和报警,形成记录并妥善保存;

b) 应组织相关人员定期对监测和报警记录进行分析、评审,发现可疑行为,形成分析报告,并采取必要的应对措施;

c) 应建立安全管理中心,对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。


a) 网络监控平台,对机房所有设备进行监控,一般都会自带报表生成功能;没钱买,那就搞开源好了,也可以用,主要好安全防范,不要被当做突破口就好。

b) 流量分析、日志审计、态势感知,配合做好应急预案,基本就差不多了,态势感知可能有点扯,但是前两个应该问题不大。

c) 部署漏洞管理平台,HIDS,可以参考下安骑士的那些功能,很像这种防护软件。如果没预算,那最基本的把补丁管理做好,这块测评时也说得过去。

7.2.5.6 网络安全管理(G3)

a) 应指定专人对网络进行管理,负责运行日志、网络监控记录的日常维护和报警信息分析和处理工作;

b) 应建立网络安全管理制度,对网络安全配置、日志保存时间、安全策略、升级与打补丁、口令更新周期等方面作出规定;

c) 应根据厂家提供的软件升级版本对网络设备进行更新,并在更新前对现有的重要文件进行备份;

d) 应定期对网络系统进行漏洞扫描,对发现的网络系统安全漏洞进行及时的修补;

e) 应实现设备的最小服务配置,并对配置文件进行定期离线备份;

f) 应保证所有与外部系统的连接均得到授权和批准;

g) 应依据安全策略允许或者拒绝便携式和移动式设备的网络接入;

h) 应定期检查违反规定拨号上网或其他违反网络安全策略的行为。 

管理的东西比技术还多,全做到可能性不大,投入人力和时间太多。中小企业确实搞不起,可以选择性来做,成熟后再逐步完善。

a) 指定网络管理员(AB岗,不可与其他运维职位兼职),做好日常运维工作,做好巡检记录;

b) 已经说的很明白了,制定一份网络安全管理制度,包括配置管理(这里只提到了安全配置,其实网络配置也要一起备份)、日志管理(6个月)、安全策略(根据实际情况来写)、补丁管理(之前说的漏洞管理平台)、密码管理(一般3个月换一次,8位以上,复杂度要求)。这只是为了应付检查来写的内容,如果认真去搞安全运营,还会涉及其他内容。

c) 及时更新设备版本,规则库,后边很良心的还提示了,升级前做好备份工作。

d) 同样是补丁管理的一个环节,定期漏扫已经成为常态,不再是问题了。

e) 最小化安装原则,没必要的服务和插件、软件一律不装,对于系统配置文件定期备份(建议不要超过一周),存储到介质或其他存储设备。

f) 本条强调私自连接外网的情况,现在手机都可以开热点,笔记本一联,防不胜防,考技术手段来防,策略设置比较复杂,增加额外成本,建议还是以思想教育为主,提高员工安全意识,这是最靠谱的。我说的有点引申了,其实测评主要考察的就是能够访问外网的设备,必须是经过审批授权的。

g) 同f,加强安全意识,用惩罚来威慑。

h) 拨号上网具体指什么,这么多年一直没有个明确的概念,个人感觉应该就是私自连接外网的行为吧,技术要求中提出要能够检测内部设备私接外网的行为,技术层面可以做,但是费时费力费钱,从个人角度来看,说到底还是加强管理更靠谱一些。

7.2.5.7 系统安全管理(G3)

a) 应根据业务需求和系统安全分析确定系统的访问控制策略;

b) 应定期进行漏洞扫描,对发现的系统安全漏洞及时进行修补;

c) 应安装系统的最新补丁程序,在安装系统补丁前,首先在测试环境中测试通过,并对重要文件进行备份后,方可实施系统补丁程序的安装;

d) 应建立系统安全管理制度,对系统安全策略、安全配置、日志管理和日常操作流程等方面作出具体规定;

e) 应指定专人对系统进行管理,划分系统管理员角色,明确各个角色的权限、责任和风险,权限设定应当遵循最小授权原则;

f) 应依据操作手册对系统进行维护,详细记录操作日志,包括重要的日常操作、运行维护记录、参数的设置和修改等内容,严禁进行未经授权的操作;

g) 应定期对运行日志和审计数据进行分析,以便及时发现异常行为。 

这里有点重复啰嗦了,不过也逐条说一下。

a) ACL运维层面都会去做,安全层面也会去做,最基本的划好安全域,做好不同组别的逻辑隔离,不同权限的访问限制,基本也就够了,再细的东西要看实际情况。

bc) 漏扫不再重复了。

d) 主机层面的安全管理制度,和前面的网络安全管理制度其实差不多,不再重叙。

e) 指定系统管理员(AB岗,不能兼职其他运维职位),要有岗位职责说明,注意做好权限分离,不要一个人拥有所有权限;系统同样权限最小化原则。

f) 前边说的操作手册,来了吧,这里是检查是否按照操作手册去执行,记录有没有做,对于违规操作有没有惩罚和处置记录。

g) 一般驻场人员会做这个事情,不过现在大多配备日志审计和安全设备,有问题会直接告警。如果这些设备都没有,那要制定一个人定期查看这些日志,工作量较大。

7.2.5.8 恶意代码防范管理(G3)

a) 应提高所有用户的防病毒意识,及时告知防病毒软件版本,在读取移动存储设备上的数据以及网络上接收文件或邮件之前,先进行病毒检查,对外来计算机或存储设备接入网络系统之前也应进行病毒检查;

b) 应指定专人对网络和主机进行恶意代码检测并保存检测记录;

c) 应对防恶意代码软件的授权使用、恶意代码库升级、定期汇报等作出明确规定;

d) 应定期检查信息系统内各种产品的恶意代码库的升级情况并进行记录,对主机防病毒产品、防病毒网关和邮件防病毒网关上截获的危险病毒或恶意代码进行及时分析处理,并形成书面的报表和总结汇报。

本节主要讲主机层面的杀软和网络层面的防病毒设备。

a) 这条讲了2点。1注意这里提的是用户,除了员工还包括你的用户;这就有点难搞了,内部人员可以培训,外部人员可以在软件使用帮助中加入安全意识提示标语或描述,或者在用户协议、操作手册中体现防毒意识的内容。2对于新的病毒和漏洞,及时告知用户。

b) 定期杀毒,记得留记录,检查时要看你有没有做过全盘扫描,周期频率多久;对于linux这类的系统,有的单位裸跑,中招了手工处理,如果有这样的团队能搞定这事也可以,若不是,那你想好了现场怎么跟对方解释。这里还隐含了一点,记住不要用破解版,你可以用免费版,但不能盗版,如果发现用盗版,本条直接就GG了。

c) 及时更新病毒库和版本。

d) 前边还好,杀软本身都会记录查杀过的病毒文件,但是对已发现的病毒进行分析和整理,并记录汇总,这点做的其实不多,一般都是中招的病毒才会去分析,如果直接被拦下的可能不太会在意。作为普通甲方来说,确实没必要,但如果有自己的知识库的,可以试着去做,检查的时候不是非要去做,本项非一票否决项。

7.2.5.9 密码管理(G3)

应建立密码使用管理制度,使用符合国家密码管理规定的密码技术和产品。

这个没必要说了,密码学东西很多,这里提到的是符合国家规定的密码技术和产品。另外对于密码管理要有制度。

7.2.5.10 变更管理(G3)

a) 应确认系统中要发生的变更,并制定变更方案;

b) 应建立变更管理制度,系统发生变更前,向主管领导申请,变更和变更方案经过评审、审批后方可实施变更,并在实施后将变更情况向相关人员通告;

c) 应建立变更控制的申报和审批文件化程序,对变更影响进行分析并文档化,记录变更实施过程,并妥善保存所有文档和记录;

d) 应建立中止变更并从失败变更中恢复的文件化程序,明确过程控制方法和人员职责,必要时对恢复过程进行演练。

变更管理时运维的一个重要流程,企业应该重视,包括乙方在内。

a) 变更要提前申请,提交完整的变更方案,其中包括回滚方案;

b) 变更管理制度,网上很多,目前已经很完善了,很多是针对项目的,运维方面的也有。不多做解释了,模板里写的都不错。

c) 变更要有流程,无论纸质还是电子流程,要适用、合理,不能为了应付弄个简化流程,这样不合适,不利于企业日后管理,留存好记录。

d) 这点就是回滚/恢复详细方案(中止变更流程,包含在变更流程中,是一种特殊情况),对于重要系统的变更,要预先进行演练,确认方案没问题再予以实施。

7.2.5.11 备份与恢复管理(G3)

a) 应识别需要定期备份的重要业务信息、系统数据及软件系统等;

b) 应建立备份与恢复管理相关的安全管理制度,对备份信息的备份方式、备份频度、存储介质和保存期等进行规范;

c) 应根据数据的重要性和数据对系统运行的影响,制定数据的备份策略和恢复策略,备份策略须指明备份数据的放置场所、文件命名规则、介质替换频率和将数据离站运输的方法;

d) 应建立控制数据备份和恢复过程的程序,对备份过程进行记录, 所有文件和记录应妥善保存;

e) 应定期执行恢复程序,检查和测试备份介质的有效性,确保可以在恢复程序规定的时间内完成备份的恢复。

备份和恢复是重点检查项,总结一下,主要会关注几个点:

首先灾难恢复计划时针对重要关键业务通,不是所有系统,一般系统只要有一定备份恢复可行方案即可,分优先级做备份恢复管理;

制度必要要有;

关键系统实时备份,场外备份,异地备份,6个月至少;

有钱的搞双活,没钱的搞双机双线;

定期进行灾难恢复演练,验证可行性、有效性,一般一年至少一次(建议)。

7.2.5.12 安全事件处置(G3)

a) 应报告所发现的安全弱点和可疑事件,但任何情况下用户均不应尝试验证弱点;

b) 应制定安全事件报告和处置管理制度,明确安全事件的类型,规定安全事件的现场处理、事件报告和后期恢复的管理职责;

c) 应根据国家相关管理部门对计算机安全事件等级划分方法和安全事件对本系统产生的影响,对本系统计算机安全事件进行等级划分;

d) 应制定安全事件报告和响应处理程序,确定事件的报告流程,响应和处置的范围、程度,以及处理方法等;

e) 应在安全事件报告和响应处理过程中, 分析和鉴定事件产生的原因,收集证据,记录处理过程,总结经验教训,制定防止再次发生的补救措施,过程形成的所有文件和记录均应妥善保存;

f) 对造成系统中断和造成信息泄密的安全事件应采用不同的处理程序和报告程序。

应急响应管理,目前外包形式较多,有自己应急团队的没多少。大多企业关心的还是出事了尽快搞定,别影响有任务,别影响形象,不出事的情况:跟我有毛关系,搞它干毛。

a) 渗透或无意中发现的漏洞,及时上报,不要去搞事,现在是要关小黑屋的。有些乙方的工程师,水平还可以,没事喜欢去挖洞,挖到了还喜欢去搞事,以前可能还好,最近如果还这么玩,估计很快会被公安请去喝茶。还有一点,没有授权,不要去搞政府网站,不要作死。

bc) 应急预案,不是那种随便写写的,看后边的要求,要包括事件分级、报告流程、应急流程、还有操作方法等。可以参考《国家网络安全事件应急预案》。

de) 应急预案的细节,对于一些常见的已知攻击或病的,要在附件形式附上不同状况的操作指导手册。至于应急响应的流程和每步操作,建议去看下ISCCC的应急处理资质的要求,里边虽然都是要求的内容,但是对于每步该走什么,该留存什么都很详细。官网可以下载《信息安全服务资质自评估表-应急处理类填写指南》。

f) 这条说的有点不太理解,中断和泄露为什么要用不同的预案和流程,这类可以定义为重大或特别重大安全事故,其实处理起来的过程差不多,只是造成的影响比较严重。有了解的同学可以解释一下。

7.2.5.13 应急预案管理(G3)

a) 应在统一的应急预案框架下制定不同事件的应急预案,应急预案框架应包括启动应急预案的条件、应急处理流程、系统恢复流程、事后教育和培训等内容;

b) 应从人力、设备、技术和财务等方面确保应急预案的执行有足够的资源保障;

c) 应对系统相关的人员进行应急预案培训,应急预案的培训应至少每年举办一次;

d) 应定期对应急预案进行演练,根据不同的应急恢复内容,确定演练的周期;

e) 应规定应急预案需要定期审查和根据实际情况更新的内容,并按照执行。

和应急响应章节相关,属于安全事件未发生前的预防措施。

a) 这条我是凭个人理解,针对不同的关键系统或基础设置制定不同的应急预案,由于业务原因应急方式可能会存在不同,所以不是一套预案就能使用所有系统。一般是指较大的企业。

b) 这条纯属屁话,众所周知,安全的预算你懂的。不过网安法出台了,等保强制了,也可以拿这条规定试着跟领导提要求,万一同意了呢。O( ̄__, ̄)o

cd) 已经白话了,不用再解释了;都是每年至少一次,没如果不做,测评时会扣分,印象中。

e) 建议和演练一起搞,每年修订一次,1-2年可能不变,要说3-5年还不变,就是扯了,一定要考虑预案的适用性,随着系统和业务的变化也要及时变更。不只是应急预案,同时也包括其他在行的制度和流程。安全是一个不断循环的过程。

结尾

到此为止,等保到底是个啥系列全部更新完成(说实话,我都不信我能写完这个系列)。希望能够帮到有需要的人,文中大多是个人经验和理解,肯定会有不当的地方,欢迎随意吐槽和纠正。感谢FB和各位的支持。

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



 
FreeBuf 更多文章 给CSO的三句话 | 企业风险自评框架 电商平台云集话费充值活动遭薅羊毛事件分析 UC浏览器被曝中间人攻击漏洞;个人简历已成数据黑产一环 | BUF大事件 企业安全架构体系的现状和解决方案 记一次入侵应急响应分析
猜您喜欢 关于 Yep 的想法,未来 要写易删除,而不易扩展的代码 一位 iOS 开发者使用 React Native 的体验 Node 之父:Node 失误太多无力回天,Deno 前景明朗 应对数据安全“黑天鹅”,金融级数据库的多活架构实践