还是在看《反脆弱》这本书。从书里谈到“反脆弱性的原型”中借鉴的米特拉达梯式解毒法、毒物兴奋反应等，可以看出来，反脆弱性来源于我们下意识认为对自己有害的东西，而实际来说，只要在受控范围内，这些东西是有益的。比如人们为了保持健康进行健身，而健身实际是人为地为身体创造可预期的、更高强度的压力和内外部环境，从而提高身体的抗压性，即反脆弱性，也就是“健康”。类比可知，企业信息安全体系要保持“健康”，就必须保持一定的压力刺激，将对受控的、不过度的安全事件进行发现、分析、处理作为常态，甚至人为地制造这类的事件，来锤炼和刺激自身安全机制的完善、进化。缺乏这样的刺激，反而是有害的。这也是为什么“安全的价值在于不出事”这句话是错误认知的原因。
在这里，我将对各类安全事件及其处置称为企业信息安全体系的“应激反应”。常态化、不过度的安全应激反应，是会让企业的信息安全体系不断完善、健全，甚至进化的。
那么，如何建立一个应激反应式的企业安全团队来保障安全机制的“健康”呢？我们可以按照“4W2H”（因为想不出5W2H，汗～）来理清下思路。
“Who”：团队包括哪些人？个人认为，除了安全专家外，这个团队至少还要包括熟悉业务流程的业务专家、熟悉系统架构的IT专家和熟悉内部管理机制的管理人员。这个团队应该直接对企业高级管理层直接负责，具备横向、纵向的协调和处置能力。为什么要这样，后面会说。
“What”：团队需要什么做安全决策？个人想法，从情报学的角度来看，任何决策实际都是由情报分析所得出来的。那么，我们需要什么样的情报呢？三类：TI（威胁情报，内外的威胁，一个“5W2H”），SI（系统情报，也是一个“5W2H”），PI（人员情报，偏重内部人员和用户，外部攻击者可从TI提取，又是一个“5W2H”）或是OI（组织情报，还没想好用PI还是OI，个人认为OI包含PI，会更好点）。只有获得了这三类情报，我们才能知道XX人在操作XX系统时，遇到XX威胁时，或做XX操作时，他会怎么处理？系统的会怎么处理？这就是一个应激反应式安全评估的概念。
需要注意的时，我们要认识到其中这个XX人认为的XX系统会怎么做，与实际系统的处理情况并不一定一致，甚至与系统设计该怎么做也不一定相符。所以，应激反应式安全评估的重点会放在威胁情报分析、渗透攻防、仿真靶场、软件测试、业务评估等方面，也就是搭建一个“试错”机制，结合TI分析的结果，建立试错环境（可控时是可以放在真实环境下来做的），进行TI的复制模拟和攻防演练，以尽可能地在可控范围内人为创造一个完整的应激反应过程。这也是为啥我们的团队需要更多其他方面的专家参与，需要高层支持的原因（单纯安全的肯定搞不定）。
“Why”：团队的安全工作动机是什么？我们需要认识到，TI是不随我们意志改变的，但是SI、PI/OI是大致可控的。实际，团队安全工作的动机就是通过真实或模拟的安全应激反应，获取SI、PI/OI的准确情报，找到隐患、漏洞和与理想情况的差距，再进行分析决策，确定系统、组织、人员管理的调整策略和具体做法，从而进一步完善企业自身的安全机制，并由此受益。
这里还要谈到受益这个问题。采取什么样的模式才能让企业从安全机制改进上受益呢？从互联网企业来说，我能想到的是构建网络信用体系，貌似蚂蚁现在在做这个。金融机构呢？想办法促成安全风险管理和金融风险管理的融合，甚至介入到打击金融犯罪和违规操作层面。传统行业来说，是效率和止损，要考虑与生产安全、工作效率挂钩，例如BCM之类，甚至更高层次的业务安全评估。政府机构呢？网络维稳和国家间的信息对抗。当然，这些是后话了。
“When”：什么时候做？虽然可控的安全应激反应是有益的，需要常态化。但是不能忽略的是，要给予整个机制足够的压力恢复和调整时间。所以，一个完整的安全应激反应周期应该包括发现、响应、恢复、总结、调整五个阶段。对于同一个系统、同一个人、同一类威胁而言，在同一个时间必须保持只有一次安全应激反应，否则就相当考验团队的人力、技术、资金乃至时间等资源了。但是，优化的方法也有，就是将团队分成数个完整的小团队（以3个小团队为例），保持1个团队随时待机处理突发性外部安全事件，另2个团队进行安全应激反应模拟，然后就像三球杂耍一样进行周期性轮换，从而保证整个机制的车轮式滚动完善。
“How&How much”：对于组建一个这样的团队而言，主要的成本在于两块，一是团队人力成本。这方面来说，对于大阿里、大腾讯、大百度等钱主来说，可以忽略。二是试错成本。理想的是有一个仿真的模拟测试环境，但是我们都知道绝大部分情况下这是不可能的。那怎么用小成本来干大事呢？渗透测试是一种方法，可以解决大部分应激反应需求。但由于大多点到即止，总会有忽略的，并不全面。业务安全评估是一种方法，但是从方法论框架来说，还没有一个可操作性强的、通用的，不同行业、不同企业，甚至不同业务，在实际操作上的差异化和问题都很大（我深有体会），所以只能作为辅助方法。应急演练是一种方法，如果用应急演练等同实际事件的标准来强制要求大家改变走走过场应个景的态度，实际是一个好办法，但要注意周期的问题。我这里想到的最好的办法，就是在开发阶段下手，在系统开发测试阶段就开始做全面的各种应激反应测试，模拟各种攻击、误操作、系统故障等等，虽然会得罪开发人员，但效果拔群（我也试过，真心可以）。
当然，上面的东西只是个人瞎想的，还需要具体实践摸索。TI、SI、PI/OI作为整个思路的关键，怎么来定义、获取和分析，还有待完善。