张欣宇/中信建投证券股份有限公司/zhangxinyubj@csc.com.cn
张建军/中信建投证券股份有限公司/zhangjj@csc.com.cn
肖钢/中信建投证券股份有限公司/xiaogang@csc.com.cn
赵茂军/世纪证券有限责任公司/zhaomj@csco.com.cn
王海航/深圳市金证科技股份有限公司/wanghaihang@szkingdom.com
1 引言
不知不觉间在证券行业里摸爬滚打了五个年头，感谢领导和同事们多年的支持与鼓励，让我在这个未知领域克服困难，快速成长。笔者也尽自己所能，把这几年所学、所知、所想分享给大家，希望能对行业的应急管理有所帮助，不足之处敬请各位批评指正。
2 应急管理工作的重要性
随着中国证券行业新业务的推陈出新，金融科技发展的日新月异，信息系统的安全稳定运行愈发重要，证券经营机构信息安全保障工作面临前所未有的挑战。毫不夸张的说，信息技术应急管理水平直接反映了公司整体的信息技术管理水平，是一个证券公司持续稳定经营的重要环节。很多人谈到应急管理都觉得不就是写个应急预案，做个应急演练，怎么成了影响公司经营的“大事”？大家天天都在谈应急，年年都在做演练，觉得没什么大不了的。笔者认为，应急管理对公司经营的影响主要体现在以下几方面：
首先，证券监管机构陆续发布了《证券期货业信息安全事件报告与调查处理办法》、《证券期货业信息系统运维管理规范》、《证券基金经营机构信息技术管理办法》等一系列法律法规用于规范证券经营机构的应急管理工作。同时，每年证监会派出机构会对辖区内证券公司进行信息技术专项现场检查，包括信息安全事件应对与应急管理工作的落实情况。如果发现证券公司应急管理工作存在较大疏漏，很可能受到监管处罚措施。
其次，由证信办组织的证券期货业网络安全联合应急演练已经持续十个年头。演练也由最开始的预先指定证券公司进行应急演练到后来的通过现场抽签的方式确定演练单位。这些变化增强了应急演练的实战性，也增加了证券公司的演练难度。演练过程不光在全行业中进行直播，同时还邀请了银行、电力、网安等外部机构观摩，一旦演练出现失误，将直接导致公司在行业中声誉受损。
最后，根据《证券公司分类监管规定(2017修订)》，中国证券业协会每年组织对证券公司进行分类评价。根据资本充足、公司治理与合规管理、全面风险管理、信息系统安全、客户权益保护、信息披露等6类评价指标对证券公司风险管理能力进行评价。分类评价结果将对不同类别证券公司规定不同的风险控制指标标准和风险资本准备计算比例，同时也作为证券公司申请增加业务种类、新设营业网点以及新业务、新产品试点范围和推广顺序的依据。如发生较大及以上级别信息安全事件可能导致公司被出具监管警示函或其他监管措施，直接影响公司分类评价结果，从而影响投资者保护基金的缴纳金额。
3 当前存在问题
笔者根据这几年的工作经验，对证券公司应急管理工作中常见的几个问题进行总结，概括为“四重四轻”。
3.1 重技术，轻业务
很多业务部门的同事都会觉得信息系统的应急演练跟自己没关，信息系统坏了技术人员去修就行了，做不了业务，责任也不在自己。与此同时信息技术部门在演练的时候，也很少叫上业务部门。笔者认为业务和技术是密不可分的，技术服务于业务，信息技术部门要有信息系统的技术应急预案，业务部门也应该有业务层面的应急预案。信息系统失效只是业务应急预案的里一个或几个应急场景，要把业务应急管理上升到业务连续性管理的层面，每个业务部门都应成立本部门的应急组织，并编制业务应急预案。在信息技术部门进行应急演练的时候应主动参与并配合，检验业务应急预案的可操作性，不断完善、持续优化。
3.2 重表演，轻练习
演练演练，很多公司将重点放在了“演”上。每年行业组织应急演练的时候根据预设的几个场景大家写好“剧本”，定好台词，“中签”的在台上走一遭，事后剧本一扔，出现问题的时候依旧是手忙脚乱。其实演练演练，重要的是在“练”上，表演只是形式，演的不好没关系，演是给别人看的，而练才是精髓，是内功。每一次应急演练的目的不是为了应付监管检查，而是查缺补漏，真正从演练中吸取经验教训，找到每一次演练的不足之处，有针对性的优化应急预案，提高应急处置效率，熟悉应急响应程序，运用PDCA的方法论持续提升应急管理水平。
3.3 重自动，轻人工
很多公司现在采购了自动化运维工具，通过自动化运维程序实现灾备一键切或其他一些应急操作一键处置，在发生信息安全事件的时候，可以大大提升应急处置效率，缩短故障恢复事件，减轻故障影响。然而，自动化运维工具也是程序，是程序就可能出现问题，笔者在参与应急演练的过程中就遇到过多次自动化运维工具失效的情况。因此，运维人员必须能够熟练掌握手工切换过程。敲黑板，建议在每次组织应急演练的时候，自动化运维工具、人工切换都练一遍，多花30分钟买不了吃亏、买不了上当，关键时候有可能会“救命”。
3.4 重生产，轻灾备
还有一部分证券公司对集中交易系统、投资交易系统等重要交易类信息系统的生产环境的运维非常重视，但是忽略了备份环境、灾备环境的建设与维护。很多证券公司生产环境和灾备环境是两个团队分别负责维护，如果没有好的配置管理、变更管理机制，很容易造成生产环境、备份环境、灾备环境三者在网络上、应用软件版本上、关键配置参数上不一致，直接影响应急处置结果。某证券公司曾发生过一起案例，其融资融券系统交易网关主用服务器发生异常，启用备用服务器后仍无法连接深交所，报盘中断时间29分钟左右，差不到10秒定级为“较大级别信息安全事件”，险些在分类评价中扣分。经调查，备份系统无法正常启用的原因正是因为备用服务器程序版本与生产环境不一致导致。
4 完整的信息安全事件应急预案
工具善其事必先利器，要想做好应急管理，必须有一套行之有效，禁得起推敲，能够有效指导应急处置的预案。下面笔者会通过一套经过实战检验的应急管理预案，把应急管理工作中的每个要点都进行归纳总结，供大家参考。
4.1 应急管理框架
一般证券公司信息技术制度体系分为三个层级，分别是信息技术基本制度、管理办法、实施细则。第一层，基本制度追求大而全，信息技术治理里有的方方面面都要涵盖；第二层，办法类是对基本制度的细化，追求专一，要对基本制度里的某一方面结合公司实际情况进行全面规范；第三层实施细则类追求小而精，要针对办法类制度进行详述，清楚的定义好角色、职责、流程、工具等。
应急管理框架应该从两个维度进行考虑。第一个维度，要从制度层级上考虑，需要制定一个公司整体的应急管理办法类制度，可以把这个制度叫《某证券公司信息安全事件应急管理预案》（第二层办法类）。同时，还要有很多个信息系统的技术处置预案，也就是《某证券公司某系统应急预案》（第三层细则类）。本文主要从第二层级的信息技术应急预案制度进行讲解。第二个维度，要从这个第二层级的制度本身的架构考虑。一个好的应急管理制度要完整、高效、可用。完整就是能够涵盖国家及监管部门的各项法律法规；高效就是能够在发生突发事件时，应急响应是否高效；可用就是制度里的每一条的切实有效，具备可操作性。笔者建议，如果大家没有好的思路或者没有较高的造诣，应急管理框架可以“拿来主义”，直接照搬《中华人民共和国突发事件应对法》的目录结构稍加修改即可。这样做的好处有两点：一是，国家的法律法规是经过无数专家学者论证，具备较高的实用性；二是，这样编写的制度从架构上就站在了制高点，制度是参照国家的法案来的，任谁也说不出来哪儿有问题。下面，笔者会针对应急管理预案中的每一个章节进行讲解，争取多说点干货。
4.2 应急组织体系
一个应急制度的第一章是总则，一般就是制定的依据、对信息安全事件的定义以及适用范围，大多车轱辘话，大家参照之前公司已发布的制度写就行了。
言归正传，先说说应急组织体系。这一章节主要说明公司信息安全事件的应急组织架构和职责分工。一般来说，公司会有一个整体的突发事件应急组织，由公司领导担任组长，负责所有突发事件，包括公共类突发事件、舆情类突发事件、业务类突发事件和信息技术类突发事件等。在突发事件应急组织中下设信息技术应急组织，即“信息安全专项应急小组”，一般由CIO担任组长，成员包括：系统运行部门、系统研发部门、运营结算部门、财务部门、总经理办公室、合规与风控部门、品牌管理部门及交易相关的业务部门。笔者建议信息技术应急管理组织尽量扁平化，不要有领导小组、工作小组、工作办公室等。信息安全事件发生后争分夺秒，组织架构越复杂，信息传递、汇报的层级就越多，应急响应的效率就越低。1秒之差有可能信息安全事件最终定级是“一般级别”还是“较大级别”，直接影响监管措施的严重程度。
“信息安全专项应急小组”中可常设两个专项小组，分别是“应急协调组”和“技术处置组”，这两个常设小组也是信息技术应急处置过程中最核心的成员。“应急协调组”一般由信息技术部门中的支持人员组成，负责信息的汇聚，上传下达应急处置指令以及对外的监管报送；“技术处置组”一般由运行团队、研发团队组成，也可包含相关的外部厂商及外部专家，负责信息安全事件的技术处置。设置应急协调组一方面可以协调资源，另一方面可以高效的传递信息技术部门之间、信息技术部门与业务部门之间、信息技术部门与外部监管机构间的信息，专人专岗，职责明确。
建议法律合规部、品牌管理部门也加入“信息安全专项应急小组”。法律合规部主要是负责协助相关部门处理因安全事件引发的纠纷，审核对外公布或报送监管部门的事件说明、报告、公告等。品牌管理部门主要负责舆情监测、危机处理及媒体沟通等。其他组织成员参考《证券期货业信息系统运维管理规范》即可。如下是某公司的信息安全应急组织架构图供参考：
图2 某证券公司应急管理组织架构图
4.3 预防与应急准备
这一章主要内容是明确应急管理的预防与准备工作。预防主要是用什么方式手段防患于未然，“准备”是说应急来不得临阵磨枪，必须“粮草充足”。
4.3.1 应急预防
预防可以通过如下条款进行规范：
“各信息技术部门应建立预防预警工作机制，每季度根据监管及公司下发的信息技术相关制度、规范进行检查评估，形成检查报告，针对存在的问题限期整改，减少风险隐患，防止信息安全事件的发生。”这样不但满足了《运维管理规范》中“4.8.3 证券期货机构应每季组织开展内部检查，形成检查报告”的要求，还能够提早发现风险，防患于未然。
4.3.2 应急准备
应急准备主要应该从以下几方面考虑：
1、应急预案
这里着重强调的是业务部门要根据各自业务场景制定信息系统时效场景下的业务应急预案，将业务部门制定业务应急预案写进公司制度，目的的是便于合规、风险管理部门推进业务连续性计划，并给出应急预案中的必备要素，有效指导业务部门编写预案。当然也可以制作公司的统一模板，以附件的形式放在制度的后面，以便于规范文档的一致性。
2、确保生产、备份、灾备环境保持一致
为避免出现之前提到日常运维过程中，生产、备份、灾备环境程序及配置不一致的情况，建议在公司“系统变更流程”或“上线、升级流程”的OA页面中增加是否需要同步变更备份系统和灾备系统等关键字段，提醒系统运维负责人在生产环境进行变更的参数的时候，同步操作备份与灾备环境，减少差错发生的可能。同时，还可以通过自动化监控工具监控生产、备份、灾备环境的关键配置，辅以人工定期巡检的方式，规避上述风险。
3、应急决策的授权机制
大部分证券公司的CIO或有决策权的领导经常做飞机到各地开会，因此，必须考虑特殊情况下，领导无法取得联系的时候由谁下指令进行应急处置（灾备切换），不怕一万就怕万一。应明确说明休假期间发生应急事件时代为决策的人员。
4、建立应急渠道
信息技术部门应该在制度中明确应急沟通渠道，包括公司信息技术应急事件受理的热线电话、应急处置过程中信息传递渠道。这里推荐使用企业微信或钉钉之类的企业内部通讯工具，通过企业内部通讯工具进行管理，这样即使群内人员因岗位调动没有及时调整，也不会有非本公司员工获知敏感信息，向外扩散。
建议建立两个应急沟通群，一个用于信息技术内部使用，作为技术处置的沟通；一个用于公司应急沟通，将公司所有应急小组成员、应急联络人加入群中。由应急协调组在两个群之间进行指令的上传下达，技术处置进展与业务部门之间的反馈不会互相干扰，避免了关键信息被刷屏而无法有效传递。
5、编制应急联络手册
应急协调组应建立应急联络手册，应急联络手册应包括但不限于监管部门，交易所、登记结算公司、公安、银行、电力、通信、设备供应商、软件开发商、各系统供应商，安全服务提供商等相关业务单位，以及当地政府部门的联系人、联系电话等内容。同时，应急联络手册应至少每季度进行定期更新，避免联系方式失效。
6、上报各单位的应急联络人
所有应急小组成员包括中后台部门、内控部门、业务部门都应该上报两个应急联络人，互为主备岗。以便发生信息安全事件的时候，信息技术部门或相关业务部门、内控部门能够快速的找到对应的人员，迅速传达应急信息。
除上述内容外，应急准备工作还应该包含应急预算及启动条件、应急预案的修订及发布机制、应急物资的储备、敏感时期特别保障等内容。
4.4 监测与预警
建立网络与信息安全事件日常的监测与响应机制。
4.4.1 应急监测
关于应急监测可以从三方面考虑：
1、通过自动化监控系统提早发现网络与信息安全事件，及时处理。
2、建立一线值班制度，发现异常后能够第一时间将异常信息传达到系统运行负责人。
3、增加对行业突发的信息安全事件进行监测手段，如大规模病毒爆发、信息系统存在重大安全漏洞等，如可能导致发生信息安全事件时，应当立即启动应急响应程序。
4.4.2应急预警
预警是指证券公司要对可能或已经发生的信息安全事件做出响应。预警信息是基于日常监测、现场巡检、员工报告、客户报修等方式获悉。同时，要定义好预警事件的响应级别。《中华人民共和国突发事件应对法》将预警事件响应级别按照突发事件发生的紧急程度、发展势态和可能造成的危害程度分为一级、二级、三级和四级，分别用红色、橙色、黄色和蓝色标示。
笔者结合实际工作经验，建议将信息安全事件应急响应级别分为三级，分别为红色预警、橙色预警和黄色预警，红色预警为最高响应级别、黄色预警是最低响应级别。预警响应级别定义如下：
红色预警，指信息安全事件可能或已经对公司交易类业务造成重大影响或已达监管上报要求。
橙色预警，指信息安全事件可能或已经对公司交易类业务造成影响，但不会中断交易，或影响客户正常业务办理但未达监管上报要求。
黄色预警，指信息安全事件可能或已经对公司员工办公系统或办公网络造成影响，或分支机构线路、电力中断无法提供服务等。
定义好应急响应级别后，要对每个应急响应级别事件发布后应该做什么，准备哪些工作，进行规范。笔者以红色应急响应级别为例，供大家参考：
当宣布红色预警后，各信息安全事件应急工作组成员及相关单位应当针对即将发生或已发生的信息安全事件采取以下一项或多项措施：
1、信息技术部门立即启动技术处置预案，受影响业务部门立即启动业务应急预案，包括业务应急措施、应急话术等；
2、各单位应急联络人应实时关注 “XXX公司应急处置微信群”，并向下传达“XXX公司应急处置微信群”中应急指令和应急处置进展，反馈应急关键信息；
3、有应急响应职责的人员立即进入待命状态，并通知相关人员做好应急准备工作；系统运行部门负责人、业务受影响单位负责人、受影响的分支机构总经理立即回归工作岗位，保持手机畅通状态；
4、应急协调组应准备应急手册及对外报送模板，确保视频会议系统、打印机、传真机准备就绪；根据监管要求和本预案要求上传下达应急指令，完成对公司内部和外部监管部门的信息报送。
5、系统运行负责人应组织业务部门、研发负责人、服务提供商进行应急处置，随时对事件信息进行分析和评估，必要时应要求服务提供商赶往现场支持；
6、分支机构信息技术人员、柜台人员应配合总部，实施应急处置；
7、品牌管理部门应加强互联网及其他媒体的舆情监控，减轻负面消息对公司的不良影响。”
8、不能准确界定事件响应级别时，应按照较高响应级别处置。随着信息安全事件的发展，信息安全事件的响应级别需不断重新评估。重新评估后，应根据新的响应级别处置。
有了上面的机制，在发生信息安全事件的时候，大家就不会一脑袋浆糊，可以完全参照应急预案去执行对应的操作，大大提高了应急预案的实用性。
4.5 应急报告
应急报告是应急管理里非常重要的环节，应急处置要秉着先报告后处置的原则。很多情况下，信息技术人员在知悉信息安全事情后的第一反应就是尽快解决问题，但系统运行负责人并不能准确判断出要花多长时间才能搞定异常情况，但监管对每种异常事件的上报是有时限要求的，如果沉迷于解决问题，而疏漏了上报，公司可能会遭受监管处罚。因此必须先报告，后处置。一定要强调、强调、再强调。
应急报告可以分为两部分，即“内部报告”和“外部报告”。内部报告是指证券公司内的信息传递路径；外部报告是指与外部机构的报告路径。
4.5.1内部报告
首先，要安排受理信息安全事件的热线电话。一般由交易系统运行部门负责。这个热线电话要通过新员工培训、每年的信息安全培训、日常的应急管理培训甚至公司公告等发布，让公司所有员工都清楚，当发生信息安全事件或疑似信息安全事件的时候，要通过什么方式通知给谁。
其次，要明确定义每个应急响应级别的内部报告的职责、路径和要求。如“发生红色应急响应事件时，应急协调组应先通过电话向总经理办公室和经纪业务总部负责人、风险控制部负责人通告事件基本情况，再向“公司应急处置微信群”中发布事件信息；在系统恢复正常运行之前，应急协调组每隔5分钟持续报告技术处置进展，期间有重要情况应立即报告”
需要强调的是，除了应急协调组需要对内报告外，业务部门和后台部门也要承担一部分内部报告职责，如“经纪业务部负责汇总分支机构信息，判断事态，向“公司应急处置微信群”中发布业务处置进展；总经理办公室负责根据事态发展与舆情向“公司应急处置微信群”中发布应急处置相关信息；其他各业务部门应指派应急联络人根据实际情况，及时向“公司应急处置微信群”中报告业务处置进展。橙色应急响应级别、黄色应急响应级别也一样，结合实际情况调整即可。
4.5.2 外部报告
监管发布的《证券期货业信息安全事件报告与调查处理办法》中已经明确了对外报送要求，我们只需要按照要求做就行了。对外报送文件前应让CIO和法律合规部审核，分支机构报所在地证监局的材料也要经过CIO和法律合规部审核。建议每个证券公司都提前准备一个《信息技术应急手册》，将需要报送的内容都提前进行罗列，报一个打一个勾，避免发生迟报漏保情况。样例如下：
图3 应急手册样例（1）
图4 应急手册样例（2）
另外，可以针对重要的角色如，应急协调组，应急工作组组长分别编制《应急手册》，这样每个角色的备岗，甚至临时抽调的员工参照手册都能够从容应对突发事件。
4.6 应急处置
关于应急处置，首先要提前规定好应急处置原则。笔者认为信息安全事件的处置原则主要有四个“一定”：
1、一定要应依据应急预案（技术处置预案和业务处置预案）执行。
应急预案是大家在平时或者事件发生后的总结和凝练，是经过仔细推敲和讨论的结果，只要应急预案中有对应的场景，就应该严格按照应急预案中的处置步骤操作，避免突发事件发生时，按主观意愿进行操作，导致其他衍生事件。
2、一定优先考虑启用备份系统方式尽快恢复业务
部分运维人员习惯于先找到问题的原因，然后根据原因寻找对应的解决方案。笔者认为当发生信息安全事件时，应优先启用备份系统或备份手段恢复业务，然后再根据日志等调查问题根本原因。
3、一定优先恢复实时性交易系统，再恢复非实时性交易系统。
一定要提前设定好系统的重要程度和优先级，当多个信息系统同时出现故障，优先恢复面向客户的实时性交易业务，再恢复其他非实时性交易业务，最后恢复办公系统。
4、一定要保存好应急处置过程文件
在应急处置过程中无论是事后调查根本原因，还是编制事件总结报告，都需要过程文件作为支撑。应保留图片、音频、文字、现场数据、流水记录、日志等有关证据和线索。
关于应急处置程序，笔者认为主要有六个阶段，即发现异常、初步诊断、事件预警、应急处置、故障恢复、总结善后阶段。各公司可以结合本公司实际情况对上述六个阶段进行细化，下面分享一个应急处置阶段供大家参考：
图5 应急处置程序图
4.7应急恢复与重建
本章主要是对信息安全事件的善后进行规范。当事态得到有效控制后须立即对影响和结果进行评估，对受到损毁设施进行修复。具体内容概括如下：
1、信息安全事件技术处置结束、系统恢复正常运行后，应立即停止采取的应急处置措施，恢复常态运行，同时采取必要的善后措施消除事件造成的影响，防止发生次生、衍生事件，尽快恢复正常工作。
2、事件中出现故障或损毁的信息系统和设备，应限期修复或更换，不留安全隐患。对应急处置过程中进行的变更操作应补录变更流程，更新配置管理数据库。
3、信息安全事件应急处置工作结束后，应当立即组织信息技术人员、受影响业务部门及其他相关部门对事件造成的损失进行评估，涉及基础设施、办公场所等重要信息技术设备损毁的，应制定恢复、重建计划，并向公司领导报告。
4.8 总结与调查
本章节最重要的就是寻找问题根本原因，与ITIL的问题管理比较相似。需要明确的是，应急处置结束后，系统运行的责任部门必须当天对事件进行分析，找到导致信息安全事件的根本原因。能够当日整改的应于日内整改完毕，确实无法当日整改完成的应明确整改安排，落实整改责任人，并制定临时解决方案，防止类似问题再次发生。
对于信息安全事件的调查，笔者认为可以参考丰田的“5Why”分析法。所谓5Why分析，也就是对一个问题连续以5个为什么进行自问，以找到问题的根本原因。实际使用过程中没必要纠结是5次还是10次，只要找到问题根本原因就行。关于事件调查，主要有分为三个阶段，
1、识别问题
即，知道什么？也就是第一问，这里要叙述事实，发生了什么事情，什么应该发生？自己做了什么？问题的频次、数量、周期、错误信息、影响范围等，都是应该搜集的对象；
2、通过5Why方法，持续提问，直至找到问题根本原因；
3、针对根本原因制定解决方案。
问题调查清楚了，就该进行总结报告了。《证券期货业信息安全事件报告与调查处理办法》中明确规定了事件报告的要素和时限，可以在制度中直接进行引用。
4.9 应急演练与培训
针对应急演练与培训在《证券期货业信息系统运维管理规范》、《证券基金经营机构信息技术管理办法》中有明确的要求，可以直接针对每一条结合公司实际情况进行细化。此外，《证券基金经营机构信息技术管理办法》出台后，要求两年内应急演练覆盖所有重要信息系统。因此，我们首先要识别哪些是重要信息系统，列出清单，然后信息技术部门应提前制定全年的应急演练计划，按计划进行演练。前文已经说了，很多公司在上线自动化运维工具后就不重视人工的方式演练了。可以在制度中进行明确要求通过自动化运维工具进行应急演练后，应由系统运行负责人通过手工的方式再次进行演练，确保系统运行负责人可以熟练掌握应急处置步骤。
笔者建议在OA或者运维管理平台中建立一套应急演练的流程，从演练排期、演练计划、演练通知、演练验证、演练恢复测试、演练总结等对应急演练工作进行全生命周期的闭环管理。
5 实际应用
笔者在某证券任职期间，亲身经历了一次信息安全事件应急处置工作，其中主要过程就是依据了上述应急管理体系。现对当时情况做一个简要回顾：
1、事件发现
某日早上7点27分，客户服务中心应急联络人在“应急处置群”（微信群）中发出了“某移动交易客户端，一直连接服务器失败”的消息。
2、初步诊断
7点29分，应急协调组负责人在“生产故障通报群”（微信群）中转发了上述消息，深圳和北京的技术人员已经开始远程分析排查故障原因，于7点38分，发现深圳电信主站有问题。
3、事件预警
7点42分，运维组同事报告“公司机房所在大厦起火，物业反馈弱电井冒烟，让大家紧急疏散”。随后，到达深圳生产机房所在大厦的同事在微信群中发来了现场图片，并报告警察封锁大厦，人员不能进入。
图6 当日生产机房所在大楼着火现场
8点06分，信息技术分管领导结合现场情况，在“应急处置群”（微信群）中发出了启用北京灾备机房的命令。同时，应急协调组向公司内部相关部门及上交所、深交所、住所地证监局等监管机构报告相关情况。
4、应急处置
灾备切换指令发出后，公司应急响应体系立即行动起来，合规风控、公关、经纪、自营、股转等部门按照应急预案做好各项应对安排；客户服务中心负责统一受理客户咨询投诉工作，安抚客户；深圳运行团队和北京灾备中心紧密配合实施交易系统灾备切换。
深交所深证通公司、上交所上证技术公司、股转公司等外部支持机构也立即启动应急支持，迅速帮助公司办好了灾备中心通信小站软件证书发放和权限开通等事宜。
8点35分~8点45分，灾备环境各交易相关系统相继启动完成。全天集合竞价及连续竞价均正常。
5、故障恢复
经过调查，生产机房所在大厦火灾是因层弱电井失火而引发的，导致整个弱电井内的通讯电缆严重损毁，大楼停电，现场被警方封锁人员不得进入，短期无法恢复使用。
后续几个交易日，公司临时在深圳某数据中心建立运行保障办公场地，灾备中心运行一周后，按照预定计划组织了从灾备中心回退到生产机房的全网测试，交易相关信息系统由灾备中心系统成功回退切换到生产环境。
最后，公司恢复使用生产机房，各交易、行情、清算及相关系统均运行正常。
6、总结善后
在信息安全事件发生后，主动及时地向监管机构进行事件报告，让监管机构了解事件动态及影响，对于指导事件处置、控制事态影响、避免引致行业风险有非常重要的作用。
由于有应急协调组的存在，保证了技术处置组不会直接收到客户或业务部门的打扰，可以集中精力排除故障恢复生产；应急协调组定期跟踪处置进展也避免了技术处置组忙于处置而疏于及时报告，有利于应急负责人全面评估做出进一步决策。在事件报告和内部沟通中，应急协调组发挥了重要的作用。
通过回顾本次事件的应急处置过程，能够看出基于上述应急管理体系能够从实战出发，简化应急决策、强化应急组织、优化应急流程，大幅提高了预案的可操作性，能够有效指导信息安全事件的应急处置工作。
6 总结
感谢大家抽出宝贵时间阅读，希望本文能对证券公司的应急管理工作有所启发。由于水平有限，文中不够完善之处敬请谅解，有什么问题也可以随时与笔者交流。
参考文献
1.《证券基金经营机构信息技术管理办法》
2.《证券期货业网络与信息安全事件应急预案》
3.《证券期货业信息安全事件报告与调查处理办法》
4. 《证券期货业信息系统运维管理规范》
5.《中华人民共和国突发事件应对法》
6.《证券公司分类监管规定(2017修订)》
声明：本文来自证券信息技术研发中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
