4月11日，中国人民银行科技司司长王永红就金融信息系统的安全风险及防范措施等内容，接受了中国电子银行网的专访。

信息安全风险体现在三方面

中国电子银行网：目前信息安全事件时有发生，金融信息安全局面较以往更加复杂，您认为我国信息安全风险主要来自哪里？

王永红：我觉得从自身能力角度来看，信息安全风险主要体现在以下三方面：

首先是自主可控能力不足。在IT领域，现在，比较明显的特点是：现在防病毒、网络设备、安全设施用的国产软硬件越来越多，但核心软硬件还是以国外的为主，如IBM、oracle等。这种依赖导致我们的自主可控能力不足，基本上到了核心关键领域还是依赖于厂家的服务，这是我们第一大问题。另外表现出来的就是金融机构灾备体系建设不够完善，很多单位都没有做到、或者说没有完全发挥两地三中心的作用，有很大改进空间。

其次是精细化管理的能力不足。随着计算机系统的发展，规模越来越大，机房庞大无比。规模越大，结构复杂带来的安全隐患就越大。搞安全管理工作的科技人员无法预测如此庞大的基础设施哪些方面会出问题，相应的对故障隔离，应急处置复杂性要求也在增加，对我们精细化的管理能力提出更高要求。

第三是应急处置能力亟待提升。某些银行忙于发展。重建设、轻管理，重开发运行、轻安全维护的现象时有发生。应急预案的有效性和可操作性存在改进的空间，应急演练的真实性也有待加强。因为应急演练做得少，操作熟练程度肯定还有很大改进空间。

此外，除了自身能力不足，客观上，现在形势比以前更复杂，我们还面对病毒，智能木马等风险，特别是来自于国外大型黑客组织，有政府背景的黑客有组织的攻击越来越多，如伊朗核电站事件——震网病毒、火焰病毒等。所以从人民银行角度来看，金融信息系统与网络系统出问题，不仅仅是一种经济安全问题，由于它存在一种共振，有可能从一种单纯的技术问题或者说单纯的信息安全问题，演变为一种社会政治的稳定问题，这是我们政府、人民银行对信息安全的一个定位、观点。

一旦系统瘫痪，老百姓取不到钱，加上网络炒作，网上网下互动，形成一种共振，局面将更加复杂。另外，服务窗口解释口径不一致，导致火上浇油。举个例子，最近有一家银行因为系统瘫痪，导致无法取款，但他们采取紧急支付策略成功处置了这个问题。我觉得他们很聪明，他们把一个信息安全事件通过紧急支付这个做法成功解决了，这家银行的理念很值得借鉴。因为知道系统瘫痪的人很少，恶意取款的也很少，事后对账，发现无差错。如果他们没有启动紧急支付这样一种应急处置手段，那这次信息安全事件影响就会很大。

银行须重视信息安全风险管理

中国电子银行网：银行在保障信息安全时应当注意什么？主管部门提出了哪些主要/具体要求？

王永红：党中央、国务院对信息安全问题看得非常清楚。为此，在2012年6月28日发文《关于大力推进信息化发展和切实保障信息安全的若干意见》（国发【2012】23号）。大家注意，很少有文件如此这样将发展和安全并列，这是李克强同志任副总理时主持召开多次研讨会议，定下来的基调，一方面发展，一方面安全，在安全中发展，发展不忘安全。这份文件写得很好，谈得很具体。结合我国银行实际情况，未来若干年，我们国家在信息化发展中要发展哪些领域，安全方面我们要做那些保障，我个人认为从专业角度看，大家要注意以下两点：

第一点是要将信息安全风险纳入本单位的全面风险管理体系。防范和化解信息安全风险是一项综合性、长期性的工作，不能将其简化、弱化为一个单纯性的技术工作，如果哪个单位认为信息安全只是科技部门的事情，那就说明理念落伍了，它不是一个部门的事，它是整个单位的事。银监会主席讲话中对信息安全的看法很明确：IT风险是唯一可以在一瞬间让整个银行陷入瘫痪的风险。人民银行的要求：信息安全管理的底线是，绝对不允许发生系统性和区域性的风险。两个主管部门的定位是明确的，大家要引起高度重视。我们去商业银行检查时更关注商业银行的高管是否会经常研究这个问题，是否重视信息安全风险管理。

要深刻认识到技术支撑业务，业务与技术相融合的发展趋势，明确业务部门和技术部门要形成有效地协同机制，共建信息安全保障体系，共同提高业务连续性，坚决扭转由分管信息安全工作的负责人一个人负全责的不当做法，要纳入全面风险管理。

第二点是从人民银行角度来看，要求严格执行信息安全的报告机制。2010年，人民银行、工信部、公安部、安全部、电监会五部委建立了跨部委的应急协调工作预案。2011年，人民银行在副省级以上城市建立了区域的信息安全应急协调机制。大家定期有交流，有沟通，形成一种机制，互通有无。这种全国性的制度安排和属地化管理相结合，实际上构成应急协调机制、保障机制。各单位在信息安全事件发生、发展、善后等不同阶段，要采取各种联系方式向人民银行报告相关情况，便于人民银行组织协调进行应急处置，尽量避免造成社会因恐慌情绪引发群体性事件。我很理解出事以后大家的心态，但大家不要有侥幸心理，你无法预判事件将会有多大影响，有可能愈演愈烈，何况现在资讯如此发达，因此必须及时报告。一旦有事件，不管大小，一律向人民银行报告。

建立安全可控的生产运维机制

中国电子银行网：金融系统信息安全情况十分复杂，往往牵一发而动全身，事前预防比事后补救更加重要，银行应该如何做好信息安全保障工作？

王永红：在技术层面，表现为我们要建立有管理、可控制的安全生产运维机制。联网系统规模、范围越来越大，服务对象也越来越复杂。运维监控一定要做到：监控人员比用户先发现问题，中心机构比联网机构、分支机构先发现问题，这也是评判和衡量一个单位科技水平的重要指标之一。要做好管理工作，我提三个建议：

首先要建立量化的监控指标体系。监控对象的指标化是自动化监控的基础，也是优化网络效率和提升系统健壮性的重要参照，是运维技术体系的核心内容。如何发挥监控系统的作用呢？主要是看是否有量化的监控指标，量化的比较结果才有确切的说服力。在动态调整量化监控指标过程中，我们不但要包括传统的各种系统资源使用率，还要注意增加交易进度，数据状态等应用及监控的内容，及时发现运行环境和交易处理流程方面出现的异常情况。

其次要加强监控的分析。从专业角度来看， 要对运维监控中发现的各种异常现象，不论是否影响系统正常运行，都必须纳入系统运行分析会，对风险隐患必须一追到底，并及时处理，同时根据运行分析结果加强容量的管理，定期清理生产环境，动态评估系统的处理能力，动态优化技术资源的配置。在实际中摸索、固化处理能力和资源配置之间的量化关系。我们传统工厂里的班前分析会、班后研讨会很值得我们IT部门借鉴。这种习惯很好，我们要求银行最好建立这种制度，很多时候系统出问题，最开始只是有苗头，并不一定影响系统运行，表现出一种症状，如果出现苗头的时候不一追到底，是否出事就完全靠运气了，这跟人体体检是一个道理，银行对这个原则一定要把握住，工作很辛苦跟工作有成绩是两个概念，希望大家不要做无用功。

我们一直强调，银行服务外包责任无外包。在IT领域服务外包是很普遍的情况，从人民银行到商业银行都一样，毕竟软硬件是厂家生产的，但不要天真的以为，厂家能承担全部责任，人民银行和银监会都不会认为厂家完全承担责任。实际上，这几年我看过很多事件处理报告，因为没有量化的要求，之前没有考虑清楚，经常发现外包厂家因为种种原因，如堵车、工具软件不齐全等，并不能及时赶到并提供服务。因此银行必须对厂家的服务进行量化，认真研究运维合同，甚至对关键设备的备件都应该提前准备到本单位库房。

第三是完善预案，提高业务连续性。随着数据集中，系统整合的不断推进，银行的技术体系日趋复杂，但是对技术体系的驾驭经验和能力有待在实践中积累、提高。基本上可以这么说，出事是一定的，不出事是不可能的。万无一失是一种要求，我们要争取不出大事。所以应急预案，应急演练很重要，在应急预案制定过程中和应急演练在中要贯彻优先恢复系统对外服务这个原则，因此如何编排应急预案就很讲究了。

坚持优先恢复系统对外服务原则

中国电子银行网：您提到要贯彻优先恢复系统对外服务原则，体现在哪些方面？银行应如何把握？

王永红：关于这个问题，我有三点总结。第一点是银行要不断完善应急预案。各单位应该研究人民银行发布的金融业信息安全风险提示，人民银行和国家相关部门会定期发布一些信息安全提示，金融机构对此要引起足够重视，这些安全提示是一种情况交流，从别人的问题和事故中举一反三对自身情况进行排查，通过了解信息安全动态，从风险状况、应急内容和处理措施去充实和完善自己的应急预案。通过我们这几年的实践可以看出，应急预案的完善不是开会这么简单，而是要测算关键点的耗费时间，也即测算完成每一部分工作所需要的时间，通过测算关键点的耗费时间可以发现很多不必要的中间环节，可以发现很多可以转化为并行操作的串行环节。

第二点是银行要改进交易的处理流程。实际上系统中断的种类和交易处理的场景是难以穷尽的，我们应该从提高业务连续性的角度，去设计和实现替代的流程与数据处理的方式。也就是说无论我们怎么设计应急预案都无法包罗所有的故障场景，因此要去设计一些替代的流程和数据处理方法，包括手工交换数据、手工补录数据、交易流程路径变换等方法去作为替代服务，最终要达到的目的是——中断业务时间一定要大大短于系统恢复时间。很多时候我们衡量一个事件处理是否成功就是看这一点。换句话说，关键是看在系统恢复之前是否已经采取其他手段提前将业务恢复。

最后，银行要提高应急处置效率。出现信息安全事件时，初步判断无法在30分钟以内恢复系统时，应优先考虑隔离故障设备，切换至热备、替代的系统，或者果断启动应急预案，以控制事态的进一步发展。在应急处置的过程中，特别要消除“技术万能”的盲目乐观思想，应采取各种可能的举措来缩短系统恢复的时间，不能拘泥于和局限于保证局部数据的正确性而不恢复系统的对外服务，恢复系统的服务是最重要的，实际上，局部数据的正确性可以通过事后冲账等方式补救。