例MS17-010补丁刚发布的时候，其漏洞的严重程度微软说得很清楚，但立即安排全公司最快速度使用补丁的团队并不多，他们在Wannacry肆虐后，却喜欢宣传自己的紧急加班方式。由于紧急加班可以在一个周末完成，4个多月前，为什么要去呢？另外，主机agent在部署时，很容易造成资源占用过多，Bug导致宿主机崩溃，所以很多安全工程师写完agent后，在公司没有100%的推广覆盖。由于无法安装多少台，一次事故就会让业务排斥抗拒部署，导致公司实际上根本没有主机入侵检测的能力。但是，既然知道这件事是必然的结果，熔断降级自杀设计有没有，能不能让公司95%以上的机器具备相应的能力先？长尾问题慢慢迭代收拾？

例如，白盒审计工具扫出了大量的误报，以致无法操作，那有没有想过只让误报低的规则运行起来，逐个增加和优化规则，在低误报的前提下，提高白盒的能力？所有这些，没有经验的同学一上来往往都会畏难，你说这件事做得成功，只是他当时做得不对，他还是会感到委屈。急急忙忙地妥协地做些费力可能还没有效果的事情，至少不能正常经营下去，临时处理表明自己是顺从和尽责的。所以，我认为，评价安全工作好坏的第一条，其实对当事人的认知能力要求最高，至少要知道这件事，是否能做好，要有客观的认识。而且这种认知能力除了自己探索学习之外，实际上还有捷径可走。即行业对标。同样的事情，把国际、国内、同规模公司的现状摸一摸，多多少少会有合理的判断，当然，由于安全行业成熟度一般，所以有很多实际上可以做好的事情，国内同行没有做好，造成误判，也很常见。这个话题就按下来了。

二、投入的合理性。在有合理认知的前提下，首先要考虑的是自己领域的风险全景图和合理的应对节奏。其实用对标的方法输出并不难。很难。很多人会抱怨自己目前的资源现在的资源，不能做这么多事情。由于资源不足，所以即使知道很多风险没有解决，暂时也不去动它，这件事不能怪自己，要怪领导不重视，不投入。这个观点其实也有问题。对企业高层来说，绝大多数时候，认可企业资源并不足以支持你舒适地做事。但这并不意味着，一件非做不可但事，企业也坚持不给资源。没有资源的道理只有一个——你没有有效地说清楚这件事，而这，并非经理的错。比方说，老板手里有一百万，现在沙漠里，口渴了，旁边有人拿着农夫山泉卖100块，你觉得很贵不划算，默认老板不会掏钱，所以没有告诉老板有水卖。但是你怎么知道老板不愿意掏这100块呢？诚然，也确实有很多从业人员会夸大其词，自己YY安全风险很大，能带来的后果，比这家公司的市值、营业额还要大很多，然后老板不予置评，不支持，感到委屈。事实上，大多是没有换位思考，假设自己是老板的partner，在众多的经营风险中，公司有限的资源，到底该分配多少来处理这些事情。直截了当地说，如果你能处理的风险盘很大，而公司还没有达到相应的阶段，我认为最好的策略可能是跳槽去一家更加重视安全的公司，而不是在目前的公司中欺骗老板在安全领域投入过多的资源——否则，公司的主要业务能否发展起来还不知道，资源可能会先消耗掉。

假定，资源问题放在一边，已经确定只有有限的资源，面对风险大盘，如何看菜下饭合理分配，其实也很考验安全负责人的认知。实用，但不出彩的地方要投入，实用，但对于团队前瞻性或知识结构储备的地方，同样值得投入。特别是，当安全负责人自身视野有限时，花费大量资源，但以非常低效的方式解决单一问题，以致其他风险投入不足，却误以为是高层不支持不投入的现象，也很常见。比如大部分公司都会有一个问题，就是权限控制，大多不符合最小化的最佳安全实践。因为权限分散在太多系统中，运维权限、DB权限、应用系统权限(知识库、代码仓库、报表平台、人力资源系统…)，公司规模越大，这些系统越多。

而且这些权限问题往往很容易暴露给高层看，总会发生事故，所以安全团队必须迎难而上。一些同学会非常努力地承担权限管理的责任，试图帮助公司的每个系统，设计一份权限管理清单，谁能访问，谁不能访问。由于兹事体大，因此也会投入大量的人力，长期地做这个项目，做到最后，各种采访，各种调查，各种数据分析，判断谁应该访问哪个权限。(这还不算开发全球IAM权限管理系统的工作量)。企业规模越大，完成这些工作的时间就越长，可能无法完成，一段时间后，内部的红蓝对抗仍然可以很容易地暴露问题，权限仍然没有收敛到预期的目标。但是，原本捉襟见肘的安全团队，确实在这个项目上投入了大量的精力，以致于还有许多其他同样重要的风险，无法进行治理。