English日本語
在一个群里又看到人们在会商 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运维的主题力量；蛘咦钪辽俳丛宋娜嗽币渭咏？突Х讲荒馨裇OC做成一个单一的建设/移交的项目。由于，在规划的时辰，就要把将来运维的好多事件都思考到，想明显，甚至做好了沙盘推演。
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号
