在一个群里又看到人们在讨论 SIEM、安管平台和 SOC 的话题，还夹杂着态势感知的话题，论调无外乎是比较悲观的和负面的。
为什么会这样？是甲方（客户）的原因？还是乙方（供应商、开发商）的问题？抑或是甲乙双方在项目实施过程中的问题？是客户要求不合理？还是技术水平达不到？是甲方在忽悠乙方？还是乙方在忽悠甲方？
我在群里做了一些回复，贴出了一些早前发表的博客文章【譬如一些谈论安管项目的规划实施方面的文章：《Gartner：克服SIEM部署失败的通病》、《信息安全的投资结构》、《2013年国内安管平台市场和技术现状与发展分析、价值定位和规划指南》、《SIEM的隐忧》、《重新思考如何使用SIEM产品》、《Anton Chuvakin：SIEM落地不仅要靠技术》；
以及一些设计安管技术选择方面的文章：《评判SIEM的七条标准》、《Ponemon：优化SIEM时所面临的挑战》，还有大量的 Gartner SIEM MQ，关键能力分析、技术评估报告，SANS 的各种调研分析报告】。总之，我的博客里有大量此类文章。
我想说，其实，这是一个由来已久的话题，我断定这将继续成为一个话题。Why？因为 SIEM /安管平台建设是一个复杂的工程性问题，而不是 Yes OR No 的技术性问题。
Gartner 作为知名的市场分析与咨询公司，投入了大部分的精力在网络与信息安全领域。而在所有涉及安全领域的报告中，跟 SIEM/安管平台/SOC 有关的文章占据了重要的位置，其报告比例远高于 SIEM 在安全市场的占比，尽管 SIEM 市场也是安全的一个重要的主流的细分市场。Gartner 对 SIEM 研究时间之长、范围之广、程度之深，远超其它分析咨询公司。
可能平常我们看 Gartner 的分析报告，是为了了解如何更好地去做好 SIEM，去更好地进入和开拓这个市场。而这仅仅是乙方思维！其实，Gartner 大量的针对 SIEM 的分析报告都是针对甲方的，绝大部分都是讲给客户/用户听的。
没错，很多时候，客户比厂商更加需要深入了解 SIEM/安管平台这个议题。因为 Gartner 早就发现了 SIEM 项目的高失败率的问题，并早就指出这不仅仅是一个技术问题，而是一个工程问题。
为此，Gartner 给客户提出了一个SIEM指南框架，涵盖规划、实施（部署）、运营、演进和扩展五个阶段。针对其中的各个阶段都分别发表了针对性的指导，譬如《SIEM技术实施规划》、《SIEM项目范围与需求定义指南》、《SIEM技术实施指南》、《SIEM项目需求建议书撰写指南》、《SIEM项目POC测试指导书》、《SIEM技术评估》、《SIEM关键技术评价指标体系》、《SIEM市场分析与关键能力分析》、《SIEM技术、市场和供应商评估》、《SIEM架构与运营流程指南》、《SIEM项目实施失败的主要原因分析》、等等等等。我敢说，在Gartner安全，没有其他任何一个细分领域的报告有SIEM的多、完备！而且基本上每年还进行更新！可见SIEM之重要、SIEM之复杂（nan）！
如果要在这里介绍 Gartner 的整个框架和具体每个阶段的内容，恐怕要写上好几万字。因此，我就以 Gartner 今年五月份更新的《Overcoming Common Causes for SIEM Solution Deployment Failures》（《克服SIEM部署失败的通病》）报告为引子，谈谈我对于SIEM/安管平台项目实施的关键原因的分析吧。
跟之前那一版一样，《克服SIEM部署失败的通病》指出了六大通病：计划不周、范围不清、期望过高、噪声过大、情境不够、资源不足。对应原文是：Failure to Plan Before Buying，Failure to Define Scope，Overly Optimistic Scoping，Monitoring Noise，Lack of Sufficient Context，Insufficient Resources。
这次我稍微展开一下介绍：（注：下面不是译文，是我对原文的理解，以及我十几年经验的总结）
1）计划不周：就是轻视规划和计划环节，没有专门的项目组用一套体系化的方法论去规划整个安管平台的建设，很多实施和运维阶段的事情其实都是在规划阶段就能定下来的，如果现在不定，目标达成其实就是很不靠谱的。
2）范围不清：我想要什么说不清楚，就很容易变成我什么都想要。Gartner倡导的思路是“目标导向”，以“产出为导向”，以“业务产出为目标”。我再加上，要切合自身实际，安全能力是逐步提升的，认清自身的安全现状，做跳起来能够的着的事儿，不要好高骛远（为了搞预算除外，呵呵）。从技术上讲，安管平台建设有两大目标：合规性目标、威胁管理类目标。两类目标导向之下，很多建设思路、部署架构、运维流程和组织设置都是不同的。
3）期望过高：这个Gartner还是针对范围来说的，常用的一句话就是“Don't boil the whole ocean”。即便选定了明确的目标，有了清晰的技术路线，在实现的时候，也要不断迭代，一步步来。迭代什么？有很多东西需要迭代，但最重要的就是应用场景（use case，也叫用例）的迭代。应用场景都是能出具效果的，其实就是效果导向。先出一部分效果（实现若干个用例和应用场景），从而更清楚下一步要做的事情，也能增强所有项目参与者的信心，增强管理层的信心，然后就有更好的项目管理空间，更多的funding。
4）噪声过大：这个议题其实讨论过N多年了。常听到的话就是“Garbage in, garbage out”。Gartner苦口婆心的告诉我们不要漫无目的的收集日志，越多不代表越好，即便在大数据分析的情况下。大数据也是要看数据质量的！那采集什么日志，不采集什么日志？先采集什么日志？后采集什么日志？一句话“基于输出的设计”。还是要自顶向下的设计目标需求，然后根据这个需求去采集必要的日志。然后扩展需求和用例，逐步采集更多的日志，或者沿着攻击链去采集更多的日志。如果真的不知道采集什么日志的话，可以从先构建一个日志湖开始，先做日志历史分析与审计、日志存储。
5）情境不够：属于实施层面的问题，这里是指仅仅采集日志事件是不够的，分析需要很多日志相关的上下文，也就是情境（Context），也有的人叫语境。情境信息包括身份、地理位置、资产、漏洞、威胁情报等等。但是需要哪些情境，是跟目标和用例设计相关的。
6）资源不足：属于运维层面的问题，主要是指没有考虑和规划好在运维安管平台的时候的资源。要运营运维好安管平台，Gartner认为需要三种职责的人员：运行Run、观测Watch、调优Tune。运行人员就是对安管平台自身整个软硬件资源进行保障，确保系统自身的可用性和连续性，包括存储空间的管理。观测人员就是一线运维。需要长期在系统屏幕前操作观测坐班的人。调优就是高级的分析师和管理者，负责不断优化系统的分析能力，出具报告，进行（或者协调）应急响应处置，解决发现的安全问题。三者缺一不可！如果资源不足，可以考虑利用部分外包，远程外包，驻场外包都行。但不能盲目外包！
我认为，所有问题中最最重要的，就是计划！这里计划也包括规划。如果你把SIEM/SOC/安管平台当作一个技术，一个产品，那么你就不会觉得计划/规划是个多么重要的事情，因为这大体上就是一个采购行为。但如果你把SIEM/安管平台/SOC（太麻烦了，请允许我以后提及三个词中的任何一个时，都指代三个吧，除非特别注明）当成一个项目，是一个让客户自身具备某些安全能力的安全建设项目/工程的时候，你就会发现整个决策过程和采购过程就大不一样了。
安管平台很复杂，就在于它是一项集成性的技术，是建构在其他安全机制之上的，是需要客户方在各个方面进行配套的。现在所谓的NGSOC、态势感知其实也是一样的。不要把态势感知当作什么万灵丹和一招鲜。
更重要地，这里的规划，不是指如何选择和评测供应商的安管平台，主要是要说清楚客户自己到底想要什么，要达到什么目标，如何去达成。没错，规划，是指客户自身的安全建设规划！我见过太多错误的规划。错误的开始，就是目标迷失的开始，后面的一切工作都将成为撞大运。
我总是跟客户说，你们可以邀请各个厂商过来宣讲介绍自己的产品和功能，但要适可而止，关键是要从自身需求出发，听啥不听啥要分得清，并且要有定力。你自己的目标和规划越清晰，你的定力就越足。
现在的安管平台功能十分复杂，满足客户需求的点也比较多。如果客户自身没有想清楚，就让厂商过来宣讲，仅要几个回合，大部分就会发现，嗯，这个很好，嗯，那个我也想要，嗯，的确我们也存在这个问题，嗯，那个问题的确很重要。最后，你基于这些交流总结出来的建设目标和需求就很可能出问题，典型的，就是大而全。
所以，在规划阶段，自身需求分析很重要，这时候就算要请外部厂商过来，也不能让他们讲产品，而是要帮助自己分析和梳理需求。客户可以对自身的需求比较模糊（很正常），但一定要对安管平台建设的方法论比较了解，否则容易被厂商过度引导。什么是安管平台建设的方法论？这就包括上面Gartner的SIEM建设框架，也包括如何界定自身的安全需求，如何进行POC测试，如何构建自己的安管团队。如果自己真的一知半解，建议慎重，先搞一个mini安管平台，或者入门SIEM，或者干脆外包SOC吧。
除了对安管平台建设方法论要有认识，还有一点就是要对安管平台业界现状有较清晰的认识，既不乐观也不悲观。不要太技术化、理想化，建议太高的期望值，过分指望那些新兴技术（新兴就是刚涌现，但不成熟，没有被反复证明）。譬如，动不动就说我们这个安管平台项目要实现安全自动化，要应用AI技术，要自动发现未知威胁，要自动处置安全问题。也不要动不动就说，SOC没有用，SIEM没有用，采集日志没用，目前没有谁把SOC做好了。事实上，没做好的SOC项目比做好了的SOC项目更广泛地在业界流传开来。每个失败的案例，都要深入的去了解和分析，是技术原因，还是非技术原因。我认为更多是非技术原因。客户更多更深入的去了解具体的问题症结，有助于构建自身对于安管项目的正确认知。
好了，有了方法论，有了正确的认知，就能做好规划了吗？No！正如Gartner强调的，客户还需要一个团队！是的，我很赞成这个观点，尤其对于大型客户而言。这个团队应该在规划阶段就建立起来，这个团队中的核心力量就是将来SOC运维的核心力量。或者最起码将来运维的人员要参与进来。客户方不能把SOC做成一个简单的建设/移交的项目。因为，在规划的时候，就要把将来运维的很多事情都考虑到，想清楚，甚至做好了沙盘推演。
OK，进入规划！在规划阶段核心的工作内容就是确定建设的愿景、路线路Roadmap，当前的目标和范围，远期的目标和达成的路径，技术路线的选择、运作模式的选择、细化的需求、合格供应商的清单，等等。
我觉得具体做规划的时候，有几点需要注意：
1）要有机的将SOC建设规划跟自身信息安全整体建设规划相结合。
由于SOC/安管平台是一个平台型软件，是一个横向贯穿整个安全机制的系统，因此，跟信息安全建设整体规划紧密相关，如果考虑不周，后面对信息安全整体建设的影响不小。举个例子，我遇到过不少 SOC 项目，没有较好地跟客户自身整体安全建设目标相结合，导致规划做不下去，然后就不停的剪裁，最后项目的成功难以保障。譬如：
● SOC建设所需的硬件资源条件不具备，存储海量数据所需的存储都没地方着落；
● 很多SOC项目要接入的系统的自身规划都没有出来，而且也无权参与，“提前定义好接口”这种事情只能停留在纸面；
● 没有定义好和周边系统之间的关系，譬如工单系统、ITIL系统、NOC、CMDB，等等；
● 没有清晰的SOC运营部门和组织人员规划，现在参与项目的3个人，就是将来用SOC的3个人，而且定的目标还贼高，分明是想让这3个人累死，结果把他们吓死。
很多时候，做 SOC 项目规划的人没法参与到整体安全规划中去，就比较悲催了。
2）平台使用流程和组织的规划一定要有。
很多人在规划的时候就跟我谈技术，谈实现，但不谈使用流程和人员组织安排，要么就是层级到不了，谈了也白谈，要么就是看轻流程，看重技术，指望什么自动化、智能化解决问题。更有甚者，如果有人善意提醒，就反问说，是不是你们不行啊？我只好闭嘴。PPT，这三个东西我已经讲过N次，Gartner也讲过N次，但是就是有人不信这个理儿。Gartner的建议更牛，都建议客户将流程事先定义出来，事先反复推演好，在一个模拟的平台（可以是纸面）上，提前跑通，从而连岗位职责都事先定义的八九不离十。
3）在战术层面，尤其是针对当期安管平台建设的时候，在当前目标和范围方面，要避免出现前面Gartner提及的“范围不清”和“期望过高”的问题。
前面讲到 Garnter 对 SIEM 分为了两大类应用场景：合规的和威胁检测管理的。与此同时，我本人对安管平台列举出了 6 种 Sytyle。
但在实际工作中，很多客户都不愿意仅仅选择某一种类型，往往选择多种，还有的选择全都要。除了那种全都要的，我们一般都会面对客户需要两种及以上混合应用场景的情况。此时要如何进行下一步的规划设计？
我认为还是要分清主次，分清楚先后。目标太多，不是好事儿。设计应用场景（用例）是在规划阶段很棒的主意，Garnter 十分崇尚这个做法，有很多专门如何写用例的报告和相关的文章。说这个方法好，就是体现设定了系统将来应用的场合，提前列出要优先解决的安全问题，要达成的目标，并可以通过形式化的方法来进行证明。通过用例，可以很好地证明目标和需求，也可以用之去验证供应商的能力。当然，在具体实践过程中，这个用例设计不是一个简单的技术问题（如果是就好了），需要很好的整体项目管理能力，以及来自甲方和乙方的管理层的支持和授权。我本人也有幸参与过采用此种方式的项目前期规划，略有感触。
4）技术路线选择，这也是规划阶段要着重考虑的。
譬如是否采用大数据技术？需要分布式部署吗？如何部署？事件量多大？要多少存储？云部署还是物理部署？涉及哪些网络和部门，需要什么样的授权，需要对现有网络进行什么样的改造？这些问题，不是简单的让供应商去回答的，如果这样让他们说，都会说，我们都支持，看您需要啦。所以，这个需要客户自身的规划团队做好工作，厂商可以提供咨询。这个部分，还有一个涉及用国外厂商的技术还是国内厂商的技术的问题，也是很有意思的话题，以后有机会再说吧。
5）关于供应商评估选型、POC测试，这个以后再说。
进入实施阶段，就更加考验项目经理的项目管理能力了，有时候甚至是项目群管理。尤其是作为平台类项目，大量牵涉跟各种安全机制，更其他系统对接打交道，项目压力十分大。甲方项目经理和乙方项目经理如何配合，如何制定一份合理的项目计划，绝不容易。尤其是如果项目牵涉到定制开发的时候，还有研发项目管理的内容。当然，如果规划/计划阶段的功课做得足够好，实施阶段的技术压力和交付压力就会小很多，但进度与质量压力，以及突发事件管理与沟通能力是始终不能降低任何要求的，否则有好的计划，执行过程走样了，目标也达不成。
再就是运营交付和运营阶段，以及不断演进和扩展的阶段，这里就先不多说了，下次再说。
Copyright © 启明星辰 版权所有 京ICP备05032414号 
京公网安备11010802024551号
