2.3 如何协调资源

多数安全相关的工作都不能单打独斗，需要大量人员、资金以及政策上的支持。所以协调资源很重要，这种事无非是两个层面：“要什么”和“怎么要”。貌似简单的问题，在实际工作中可能面临极大的困难。

2.3.1 要什么？

除了3岁之前的孩子能做到一定程度的“想要什么就要什么”外，我们在任何情况下都不太可能做到随心所欲地索取资源。所以搞清楚自己的需求是什么非常重要。

（1）要Head Count

作为一个团队的管理者，在排除“一个人的安全部门”的情况下，自然需要团队支持，要设计团队的岗位组成，包括但不限于：安全运维、渗透测试、源码审核、安全运营、安全开发等，如果是一个比较大的团队，还需要相应的管理岗。除非公司在推着你去扩大安全团队，否则你都要向领导明确陈述这些岗位的作用和带来的价值。

比如安全开发这个岗位不是所有安全团队都会有，我们想要设置这个岗位就可以从下面几个角度去陈述。

1)预算批复需要时间，但如果我们有开发团队就可以在需求确定后快速进入工作状态，而不用等预算。

2)企业需求频繁变更，项目制使需求变更这件事变得非常困难，开发团队可以让很多工作进入“小步快走”的状态，更有利于风险控制。

3)自主研发这件事虽然在互联网公司司空见惯，但在传统企业还是一个很能体现技术实力的工作，有利于企业技术形象提升，甚至对外实现产品级输出。

（2）要钱

其实企业中大部分需求最后都落地到要钱这一环节，上文提到的Head Count就等于工资预算。要钱这件事是一个团队最重要，也是最难的事。因为再有钱的企业预算也是有限的，对不存在绝对的安全行业来说，企业有多少预算都可以用更高的安全等级消耗掉预算。要预算需要根据企业的特点，甚至某些负责人的喜好采取不同的策略。

对于轻资产的企业，就尽量不要提出采购海量硬件设备的解决方案；对于很看重技术创新的企业来说，自主研发所带来的满足感是商业产品所不能满足的。

（3）要政策

鉴于安全工作的复杂性，埋头苦干肯定不是最好的工作方式。安全团队需要与外界大量协作：安全漏洞需要和运维与开发协作；内部活动需要与培训或行政部门协作；安全响应中心（Security Response Center，SRC）需要与白帽子协作等。企业的规模越大，跨部门甚至跨企业的协作成本越高。在很多工作前期就与领导沟通，争取到一些文件级的政策，对后面的工作有很大的帮助。至少在较高层的会议中的口头协定，都会极大降低你在后续工作中的沟通成本。

2.3.2 怎么要？

2.3.1节已经一定程度上解答了怎么要资源的问题，这一节主要回答下面两个问题。

（1）“无休止地要预算”的错觉如何避免

一般情况下，企业中各部门都会每年申请自己的预算。在预算申请的时候经常会给领导层一个错觉——安全需求永远无法满足，永远用不同原因申请预算。一旦让领导产生这种情绪，很可能导致预算审批变得越来越困难。这种情况可以从如下几点规避。

1）解决痛点，前文中谈到过这个问题，如果我们识别出了企业的痛点，并得到了领导的认同。那最好的方法就是将你的安全方案和解决痛点的关系阐述清楚，是事半功倍的选择。

2）安全体系要有一致性，除非企业技术架构有重大调整，否则安全体系的规划一定要有一致性。并不是说放弃创新，而是说创新要在符合整体体系大方向的范围内进行。切忌每年搞不同的体系架构，去年PDCA，今年滑动标尺，明年再搞纵深防御，这会让听你汇报的人感觉一头雾水。记住，如果你的领导不是安全行业出身，他能完全接受一个体系就很不错了。

3）别炫技，除非你的老板是个懂安全相关技术的人，否则千万别在你的报告或者汇报中掺杂太多技术性较强的名词或逻辑。记住，你的核心需求是让领导认同你并给你想要的资源，而不是展现你技术有多强。

（2）陈述了需求，但出于种种原因无法得到想要的资源怎么办

比起领导不认同的情况，更无奈的是领导很认同你的想法，但综合考虑之后他做出了很艰难的选择——放弃你的方案，因为有限的资源内他有更重要的事情要做。这种情况下只有两件事可做。

1）争取退而求其次的第二方案：这需要首先弄清楚为什么我们的方案被拒绝。如果是因为A方案预算太高，我们是否能提供所需预算更少的备选方案？如果由于公司编制问题不让招人，我们是否能提供一个人力外包的解决方案？如果因为公司体制问题无法给你很明确的政策支持，我们能否寻求一个口头承诺？总之，别急着放弃，看看有没有更多的选择。

2）放平心态：就算所有方案都没有可能被采纳，也不要灰心。一般情况下领导不会无端否定你的方案，要在有限的资源下尽量帮助企业解决更多问题。就算你想跳槽，也不要让这件事情变成跳槽的原因，否则你可能会面临不断跳槽的境地，因为没有哪个企业会很顺利地满足安全团队所有要求。