在一个群里又看到人们在讨论 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安排失败的通病》指出了六大通。。。。。和氩恢堋⒐婺2磺濉⑵谕摺⒃肷蟆⑶榫巢环蟆⒆试慈狈。。。。。对应原文是: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语重心长的告诉我们不要漫无目的的网络日志,,越多不代表越好,,即便在大数据剖析的情形下。。。。。大数据也是要看数据质量的!那收罗什么日志,,不收罗什么日志???先收罗什么日志???后收罗什么日志???一句话“基于输出的设计”。。。。;U站梢远ハ蛳碌纳杓颇康男枨,,然后凭证这个需求去收罗须要的日志。。。。。然后扩展需求和用例,,逐步收罗更多的日志,,或者沿着攻击链去收罗更多的日志。。。。。若是真的不知道收罗什么日志的话,,可以从先构建一个日志湖最先,,先做日志历史剖析与审计、日志存储。。。。。
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 ? 南宫NG娱乐 版权所有 京ICP备05032414号
京公网安备11010802024551号