那些底部写着一条简短格言的海报非常不错。你知道，那些宣扬“持之以恒”和“团结一心”的精神的海报就是这样子。如果要给我自己也制作一幅的话，我的想法就是画上一座燃烧的城市，然后一位僧人在院子里若无其事地坐禅。它表达的是“从容不迫"。

　　僧人无论何时何地都能全神贯注，这让人非常惊讶。但是，他们这种功力绝非一日之功，这需要年复一年的不懈努力。而且还要恪守戒律，这也是区分真信徒和伪君子的标准。

　　当然，可能看到这里你会觉得奇怪，这和我们要讲的安全问题有什么关系。但是现实情况就是，安全专家就得应对可能的各种威胁。也许不是今天，也许不是明天，但就在某个时候，威胁突然就出现，不管是由于一个有缺陷的Web应用程序还是由于内鬼引起，这个时候，大多数安全人员都还猝不及防。安全经理在这样的情况往往不是依赖既定的完善事件响应计划，而是陷入恐慌，无法采取有效的反应措施，最后只好寻找跳槽机会。因为一旦发生了重大安全事故，并且没有得到妥善处理，他在公司内就名声扫地了。

　　但事情也并非一定要到这个地步。只要有完善的应急响应计划，能确保数据的安全，抵御任何破坏，那么就算是火烧摩天楼了你也可以不慌不忙。有一些步骤是任何一位安全经理都可以马上付诸实践的，它能让你在灾难不期而至时有所准备。

　　第1步：记下你们的计划 

　　很多安全人员都有自己的想法，但只是在脑海中构思。这是不够的。在跑步机上练习脚步？这也一样不够好。这些计划需要得到更广泛的沟通，而不是家庭晚餐的桌子上讨论，这意味着要把它写下来，与同事分享讨论，然后修改它，并确保所有受影响的各方都对其有所了解。

　　这份文档应该要描述清楚事故发生后会是什么情景。还需要明确责任分工、调控手段，以及是否/何时需要采取法律手段。如果你不把这些都清清楚楚写在纸上，那它可能就跟没有一样。这不光是因为事故发生时你可能根本无法就位，还因为把它写下之后各方都能早在事故发生前就熟悉它。

　　第2步：开始行动

　　一旦计划写下来了，就要分发给组织内的各个部门，以确保每个人都对这份文档有一致的认识，并明确自己的责任。当然，这其中也包括CIO，因为一次意外事故可能使得整个系统和/或网络不可用。

　　在事发之前就一定要先讨论研究出合适的策略，否则就只有等噩运临头时自食其果了。

　　也不要忽视了其它高层管理人员，尤其是人力资源部门和总法律顾问(general counsel)。如果事故最终导致要提起法律诉讼，那么这两个部门的人可以帮你确定需要收集哪些数据以及需要采取哪些应对措施和个人行动。

　　第3步：学会如何向上级汇报

　　之前我提到了向上级汇报的问题，但是还需要更具体一些。首先要明确的就是通知流程。要通知谁和什么时候通知？在什么情况下才应该汇报CIO,CFO,CEO这些高管呢？如果是在深更半夜发生情况，那该什么时候通知呢？如果你凌晨3点打过去，CEO很可能会唠叨上一大堆，抱怨你打搅了她的美梦。

　　除此之外，确定可以接受的损坏控制程度也是非常重要的。如果一个很关键的面向用户的应用可能受损了，是该进行带外(out-of-band)调查呢，还是该把这个应用先撤下？该由谁来作出这个决定？大多数时候都不是安全专家来作这个决定，但是确保有人要为此作决定是至关重要的。

　　第4步：实践，实践，再实践

　　你们企业上一次进行事故演练是什么时候？大多数公司给出的答案都是数年前，如果你们也是这样的话，那真是个问题。现实情况下，每家公司都有变动的工作人员、贸易伙伴、应用库(application base)以及其它一些时时变动的事物。因此，应急响应计划必须得保持更新。当业务发生改变的时候，响应计划也应作出修改，并且要通过实践进一步验证。

　　我也知道要激发大家去参加一个离现实还很遥远的应急反应演习不太容易，但是这确实是很重要的。如果直到事故发生时企业才意识到计划中有疏漏，这就有可能导致重大失误或时机延误。请记住，理想情况下许多在应急响应措施都是在一定条件下都会触发的，也只有通过反复实践才能检验它们。

　　第5步：吸取教训 

　　即使是最好的，实地测试过的安全工程师也会把事情弄砸，尤其是在事故发生时。这也是为什么除了当时控制破坏，事后进行剖析也同样是处理流程的最重要方面。每个人都会犯错，但最好不要再次犯同样的错误。

　　只有大家通力协作弄明白事故的性质和根本原因，明白今后该采取哪些应对措施，这样才不会重蹈覆辙。

　　所以，放下面子，好好深入分析一下事故并采取一切必需的措施来确保类似事故不会重演。对于审计来说，这种类型的事后处理也是非常重要的，因此还要向审计人员说明公司是如何从事故中恢复的，以及从中积累了哪些教训。

　　谨记，是成为不畏困境的英雄，还是成为饭碗不保的替罪羊，区别就看你如何处理事故。遵循上面这五个步骤，安全专家也可以活着开始新一天的奋斗！