2.1 解决实际问题

相信绝大部分企业组建安全团队不会仅仅为了组建而组建，我们站在企业管理者的角度思考一下为什么要组建安全团队？

一定是有问题需要这个团队来解决。这看似是句废话，但是继续深究呢？所有在甲方工作的安全工程师或主管，是否非常明确公司组建这个团队最想解决的是什么问题？这个问题会不会随着形势的变化而变化。之前提到过，企业安全工作是一个二级混沌系统，这类系统的最大特点就是不断变化，而且是随着你的行为而变化。

所以，对于安全团队来说，最大的考验不是一次性识别核心问题，而是不断更新这个（或这些）问题。

设想这样一个场景：

刚接手安全工作的时候几乎每天都会遭受DDoS（分布式拒绝服务攻击），这个阶段的核心问题就是解决DDoS攻击，让企业的IT系统可以正常工作。在经过一番艰苦卓绝的工作之后，DDoS的问题基本解决了。这个时候发现，虽然网站运行情况非常好，但是“羊毛党”来了，所有运营支出都被人薅走，这个阶段的核心问题就变成了对抗羊毛党。又一番艰苦卓绝的工作之后羊毛党的问题也基本解决，薅网站“羊毛”的成本已经高于平均水平很多了。这个时候发现几个黑产都在盯着公司的数据，甚至在暗网中有人兜售我们的数据，第三个任务又来了……

如上所述，如果系统每天都在DDoS中挂掉，就根本不涉及薅“羊毛”的情况，但是薅羊毛和数据窃取是可以并行的，这说明了核心问题可能不止一个，很多时候需要多线作战。

上述这个例子还算是比较好的情况，还可以通过一些具体的安全事件明确核心问题在哪，但我们如何确定运营经费被“羊毛党”薅走了？数据要是不在暗网上兜售，而是通过其他更隐秘的方式交易，我们如何发现这些行为？所以，识别核心问题并没有想象中那么简单。但这是安全工作的第一步，也是安全团队存在的基础。有些安全团队完全是为了救火而创建的，这类团队在初期就规避了这个问题，但在初期的问题解决之后，还是要找到下一步切入点。总体来说，识别企业核心问题可以从如下几个方面入手。

（1）对标同行

尽量多与同行交流，他们面临的问题很可能是你可能遇到，或者是遇到了还不知道的问题。即使你在圈子里没有那么多人脉也没关系，现在很多安全媒体已经做得非常好了，可以多关注这些媒体的报道，这是一个经济、快捷的渠道。

（2）贴近业务

如果你所在的行业比较冷门，甚至是涉密的，安全团队就不能再只埋头研究技术。用更多时间了解你所在企业的业务，跟业务专家一起分析系统的风险在哪。这时如果你的团队有良好的群众基础就有了非常大的优势。

（3）参考标准

安全行业内有很多标准可以参考，如ISO 27000、等级保护等（标准的话题在2.2节会展开讨论）。参考标准的意义是提供一个更全局的视角，标准的描述是宏观的、概括的，读者可以根据自己企业的情况对标标准的描述，从而找到自己需要关注的核心问题。

识别出核心问题后，下一步就是解决这些问题。解决的过程可以归纳为分步实施，逐步解决，先到及格，再到优秀。

如果要解决DDoS，最直接的就是先买服务，不管是运营商的还是云厂商的，先保证服务正常，再考虑自己是否囤积带宽研发抗D平台，或者采购抗D产品。

如果对抗“羊毛党”，前期可以先用商业反垃圾的接口，让这方面的防御能力达到一个及格线，然后再根据企业的实际情况组建研发团队，研发自己的识别能力，从而进一步提高门槛。

如果做威胁感知，前期可以直接采用开源分析模型或商业产品实现标准场景的分析，让安全分析能力也达到一个及格线。然后再根据应急事件实现对定制化场景的分析。

这种阶段性步骤也支撑了前文提到的阶段性汇报工作的需求。当然，每个企业的实际情况都不一样，不能生搬硬套。有的企业可能强调自主可控，宁可扛一段时间，也不会直接采购商业产品或服务。出现这种情况一般来说无非有两种可能，要么这个痛点还不够痛，可以忍；要么就是企业认为组建团队的目的就是自主解决问题，如果采购安全产品还要安全团队做什么？

对于前者，安全团队负责人的任务就是快速启动研发，从简单的环节入手逐步解决问题。

后者的情况比较复杂，这种情况下安全团队负责人需要与公司管理层深入沟通，陈述自己方案的合理性。比如，“商业产品只是整体方案的一部分而非所有，而且从目前每天的损失来看，前期采购的成本远小于等待研发这个时间窗口的损失。”这就要求负责人有较强的沟通能力。

如果能顺利到达实施阶段，相信这个阶段是很多技术团队的舒适区。但舒适区往往意味着危险。这个阶段最容易陷入某个细节出不来。我们要做的是低头走路的同时要抬头看路，所有的技术手段都是为了实现一个终极（或阶段性）目标，任何偏离了目标的技术路线，再好都是不完美的，甚至是错误的。这里不是要求僵化地按照预先制定的技术路线前进，而是在某些细节上可以有很多灵活的方案，但总体目标一定要符合企业利益。其实笔者在制定某些目标的时候，就会提出相对模糊的目标，留给技术人员发挥的空间，但是一定要在可控范围之内。