近日，【金融业企业安全建设实践群】针对安全运营中心SOC告警降噪的问题展开讨论，不乏有远见且审慎的评论。我们将群友讨论的内容整理成此文公开分享，希望与大家一起讨论以下四个部分：
-
SOC降噪，除了告警归并，同源历史告警，日志富化，多维染色等降噪方法以外，实践中还有其他比较有效的方式吗？
-
-
-
01 | SOC降噪，除了告警归并，同源历史告警，日志富化，多维染色等降噪方法以外，实践中还有其他比较有效的方式吗？
A2：告警降噪在SOC工作中是一个本质性、长期存在的问题，是系统工程，没有银弹。除了大家提到的一些方法，基于我弄的实践，有几个建议方向：
1、日志质量问题。数据分析中的“垃圾进垃圾出”原则对于安全告警分析同样适用。
2、业务与架构治理：九龙城寨天天小偷小摸，打打杀杀，到底哪一次是真正高价值的告警，就很难判断了。
3、业务设计：比如站岗士兵每次交接对“暗号”，一般就比按照“军服”识别敌我的告警误报要低。
A3：告警降噪方式没有最好，只有更好，需要长期持续优化形成适合自身公司的方法论，我们自己目前来看主要是：
1、从安全产品的源头提升原始告警的准确性，这块需要持续和不同安全厂商打磨优化。
2、提升告警模型建立的质量，不追求多，优先级高的安全风险先建告警模型，告警模型在正式投产运行之前需要通过攻击手段的验证。
3、告警产生需要经过多步系列分析，规则模型、压缩、流程编排诊断后才可形成告警。
A4：同意，这个是SOC基本的、长期的工作，没有银弹。个人理解其实本质上还是UseCase规则的制定和优化，之前群里应该也讨论过，个人经验：
1、降噪换一个思路其实是提取，从海量告警中提取真实有价值的攻击行为，这类似威胁狩猎，需要持续发现并转化为监控规则固化；
2、除了控制接入的日志质量，很重要的是明确企业的安全架构，比如监控区域、流量，可能涉及的资产、地址等，这样就可以排除掉或发现一些异常；
3、熟悉各类安全设备探针系统的功能和日志进行综合，比如除了基于源的数量和攻击类型统计、基于目的统计，还可以设定关联规则，比如被打的目的又作为源进行攻击，流量的和主机的关联等等；
4、和运维、变更管理系统进行联动，避免自己人的干扰；
5、设备和SOC都要能精确加白，并且尽量降低高级成本，通过对已知行为加白压降告警。
6、没有能安静下来、知攻知防有经验踏实干活的人，上面几条都是白扯，最有效的方法是找到并使用这样的人，他会找到更多方式。
2、安全产品的能力和准确性，比如依据单位时间连接的次数超过阈值就说是暴力破解就是耍流氓，建议国内学习一下corelight的玩法，不然条件允许还是取主机端日志吧。
3、基于行业场景去排除行业应用的误报或加白，比如万得、聚源数据、同花顺，比如彭博社的金融终端。
A6：现在的很多攻击行为都是基于云IP的攻击，很多时候IP是随机的，封IP可以解决一时的问题，但是不能彻底解决问题，甚至可能误伤业务。采用多个设备的日志联合分析，解决SOC误报数量过大的一部分问题，但是多个设备的联合分析，基于简单的规则的话，还是很容易产生噪声过大的问题，个人感觉这块，AI在日志联合判断方面可以发挥作用。
A7：关于SOC降噪，说得很全面了，个人补充一点：可以根据场景与特殊手段补充验证告警，例如在边界攻击告警方面，结合“防御有效性验证”等手段，可以聚焦相关告警，进一步提升效率。
1、日志数据格式归一，尤其是时间戳，现在很多数据源的日志时间戳格式、时区各异，在实际关联分析中很容易造成误报，做好各类数据源时间戳的格式归一对于降低误报率效果很好；
2、做好安全事件分类处理，比如钓鱼邮件、凭据窃取、密码爆破、后门回连、内鬼威胁、挖矿勒索等，对于有明确处置SOP和调查数据支撑的安全事件可以通过自动化或者AI技术处置（如AWS GuardDuty）提升自动化率，对于需要SOC分析师深度分析的要注重人的经验积累（如SOAR）。
组织：https://www.microsoft.com/en-us/security/blog/2019/02/21/lessons-learned-from-the-microsoft-soc-part-1-organization/人员：https://www.microsoft.com/en-us/security/blog/2019/04/23/lessons-learned-microsoft-soc-part-2-organizing-people/人才培养：https://www.microsoft.com/en-us/security/blog/2019/06/06/lessons-learned-from-the-microsoft-soc-part-2b-career-paths-and-readiness/技术工具：https://www.microsoft.com/en-us/security/blog/2019/10/07/ciso-series-lessons-learned-from-the-microsoft-soc-part-3a-choosing-soc-tools/
A9：SOC降噪的话题，前面大佬们讲的挺全了，我这边工作中的感受：
一是数据要尽可能地全面完备，除了网络、端点、应用等各个层级的告警数据，还应该关联流量上下文、进程上下文、威胁情报、漏洞信息、资产组件等等待分析实体的各种上下文信息。即使soc平台中没有采集存储的数据，也可以在关联分析过程中通过动态调用的方式去获取（把人工的活自动化实现），信息足够多，相应关联规则能匹配的场景更准确，否则大部分告警出来都是可疑，不一定需要处置，还得人工分析研判，“日志-告警-事件”收敛度不够，把很多告警当成事件去研判处置，事件应该是提炼出来的准确攻击场景，是待处置需要处置的对象。
二是SOC的规则一定是跟业务强相关的，这是降躁非常重要的内容，ftp的业务上http的告警肯定不需要关注，业务有哪些资产、系统，中间件，可能涉及哪些攻击风险，花时间去梳理、复盘、验证迭代，而不是按照按照攻击模型把所有的规则全用上，误报无用告警肯定多。
三是SOC规则一定要攻防团队的人来运营，要让攻防团队的人定期来挑战规则，可通过实战、沙盘等检验，最后定期复盘，不断根据业务变化、系统变化、攻击方式变化调整规则模型。
A10：学习了各位大佬分析经验，方法上已经挺全面的：
个人认为降噪的过程也可以是优先级排序的过程，把最高优先级/TOP告警出来也是可以的。单从降噪角度出发，应该重点优化终端或者主机侧的事件告警，主机攻击阶段比较靠后告警准确价值更高。再补充几条实践方面的思路供参考：
（2）对威胁场景分类建设，特别是互联网侧区分入站和出站的威胁场景专项建设，内网区分横向移动和出站场景专项建设。
（3）网络侧或端主机侧的告警，都可以尽可能关联EDR/CWPP进程日志，通过对进程ioc情报或行为判定AV告警来实证告警。
（4）多源威胁情报做加权评分模型，可以针对不同类型ioc可以给不同的权重，多探针源同时触发可以提升优先级。
A11：在实践中，消息是需要运营的，每天把报警前50或前十名消除，找到跟因，也很有效果。
A12：关键是要推进安全左移，研发物料采集，形成大数据，进行分析，有效攻击入侵。供参考。
02 | SOC降噪过程中可能出现的漏报问题怎么解决？
A1：SOC降噪我讲一个反向问题，我们在追求降噪的过程中（加白）可能会导致漏报上升，现在我理解的降噪应该是要去做告警的分层，各种优化的目的应该是抓到更精确的入侵事件提升响应的紧迫程度，不应该追求通过降噪来优化告警数量，有时候目标的一时偏差可能就自我带来了安全短板。
所有的白不一定真的可以白，运营对白的判断把握有多大，为了准确率极有可能就是提高了漏报率。
A2：要看SOC处于什么阶段，刚开始还是要精度为主，广度为辅，提高人效才能持续运营起来，然后逐渐往广度发力。
A4：SOC是要分内外网区别对待的。外网，攻击本来就杂，不精准很正常，对方都买的IP池，以攻击量的大小、强弱判断即可，能做到自动封也不错，记得及时解封。内网，有条件的尽量降噪，有的降不下来也正常，又或者选几条或者造几条精准的环形红线(没必要也很难达到所有都精准)，毕竟内网有主场优势，大量虚实布防一下，形成新的精准告警，选一些精准的后面连soar自动告警、预判风险值、处置。不准的，让人工判断。保障期，把拦截阈值设低一点，情报都用上，误拦一些也问题不大，及时处置就好。
A5：认同，对于加白的规则，还是要定期进行梳理，评估是否还有必要加白，加白条件是否需要细化，误报和漏报做好平衡。
A6：审计的时候问我，为啥我这里改规则和加白没有审批，我从人员已分权不必要、时效不满足、无删除已审计可回滚几个方面硬是圆过去了，但是日常还真担心加白条件没写好，最坏情况能跟rm /*类似对范围内全部加白。或者加个有效性监控。
A7：soc这么多规则怎么可能审批的过来，不过话说回来还是要定期review稳点。
A1：基线降噪貌似没人说，这个和白名单还不一样，周期性生成就行，类似七天内第一次收到的发件人，三日内第一次执行的cmd，复杂点上算法 onesvm这种入门可以，稍微复杂点算法可以看我之前发的论文 zerowall，自动学习waf基线的一个paper，我给了四种方法，前两种是统计学后两种是算法，由浅入深，前两种没用过的可以先试下。
A2：不要总试图用算法解决问题。噪音太大，貌似实战中没法运营，只存在于理论中。
A3：你们这是在挑战算法落地的可行性啊，兜哥这边算法团队在降噪提高召回方面产出都不错的。
Q：你们有没想过误报的根本原因是啥？单个数据源在还原事实本身上有天生的缺陷，实网中充斥着所谓的“异常”，但这种异常往往是由于我们的认知不足或者获取的信息不足导致的无法判断。
A5：不是数据质量低，是数据压根没法还原事实本身，其实检出本身如果是一个奇怪的东西，在某种意义上已经达到了一定的价值，这在我们这里叫做一个hint，其本身是可解释的。
A6：现实中公安办案，也是从单个线索（告警）组合还原案件事实。事件调查也是大胆假设、小心求证。
A7：是的，比如NIDS为什么“误报”多，仅仅针对网络IDS的告警运营你会发现很多查到最后却是是虚惊一场，这里“误报”我打了引号。本质上是依赖现有的信息源没法定性。厂家辛辛苦苦分析漏洞，分析exp写了那么多签名，在流量的统计学或者其他属性组合产出了异常，甚至是抱着高召回的目标在做，在落到甲方运行时，却容易被定性成一个噪音过大。
这个其实是我蛮不认可的评价。只是靠他们看到的那些东西，他们真的已经尽力了
主客体、凭据、context，这些东西结合企业的规范和具体工种、人的尿性，才能进行意图判定，你想想这个中缺乏了啥；而数据工程、算法、甚至采集点在里面发挥了很大的左右，至于噪音大这块，只能简单说，你对自己要保护的系统了解不够。这也是刚才兜哥说的基线，其实也就是画像。
对于算法的诉求，甚至他能让我获取我了解不到的新知识、新姿势，见识到新奇葩，在某种意义上也是在扩充我们对于保护系统的理解。
当然，对于算法特别难搞的，我们可能用规范、治理的方式来搞掉，减轻算法负担。现有的现成售出产品，因为缺乏对于你环境的了解，只能从异常，从黑的角度来做检测，结合它的分析对象受限，比如只有流量，产出就更受限了。
我们这边算法的产出项，有个一个目标就是有效支撑治理项的发现，不光是威胁的检出。而且，算法在某种层面上，能够大大的简化规则的研发，并且让规则具备非常好的泛化能力。
举个例子，如果我设定了个规则，这个规则相信也是非常符合很多的企业要求的：有“人”在某台机器上执行了某个命令，那么这个主体一定是通过堡垒机登录并执行的命令，否则就报警异常命令执行。大家想想看这个规则，要让规则同学写，该怎么写？
但是我觉着我们对于算法在安全领域的认知和实践还是需要深化的，这块等后续取得更多的进展，再给大家汇报下吧。现有的安全算法要么是吹的有点凶，万金油的感觉。要么就过于悲观，场景使用反倒是受了限制。
A8：这一点好多人都说到了，不要老想着降噪，更要从源头治理控制异常的发生、提升数据质量，并兼顾召回。算法落地需要脚踏实地做很多数据工作。很多瞎吹的厂商自己最后都不敢吹了。
根据前面大佬的日志质量问题、业务与架构治理、业务设计的提纲，举一个软件供应链安全排查的例子，我感觉要对每条日志的每个字段有控制力，并且对业务优先排序规则有一定理解，加上多个角色一起共创，才有好的降噪效果。
线上出了一个安全事故，需要全面排查源码库。假设源码库有240G，2000个项目，我们需要能够全面、精确、快速地找出所有有风险的代码。这就要求我们输出的日志要满足以下条件：
富化：不能只有简单的代码行号和漏洞类型，还要有更多的语义信息，如人员、部门、时间、分支、备注等。
高效：不能花费太长时间或占用太多资源，否则就会影响其他任务或服务。
这时候，可能关心的还是初级的质量。架构师可能会担心能否能排查到，进一步是能否全面排查；我作为安全人员，可能会期望能报出越多的风险日志，就越有成就感。
当我们拿到一大堆排查结果后，我们就要和项目团队沟通，让他们及时修复漏洞。但是项目团队可能会告诉我们，有一部分的源码已经被修改或覆盖了，不需要再管了。他们只关心现有分支上的漏洞情况，不在分支上的就不用理了。这就意味着我们要对数据处理进行降噪，去掉那些无效或过时的日志。这时候，我们就需要加入动态的分支数据来过滤日志。同时，我们也要利用这个机会，获取项目团队对漏洞优先级排序的知识，让我们更好地理解业务需求和架构设计。
当我们完成了一次排查和修复后，并不意味着我们就可以松一口气了。老板可能会说，历史上出过事的代码，以后都要加强监控和预警，越早发现越好。这就要求我们建立一个持续的软件供应链安全运营体系，包括以下几个方面：
漏洞知识库：收集和更新各种内外部漏洞类型和修复方法的信息，为日志富化提供支持。
左移：将安全排查和修复流程集成到CI/CD甚至IDE中，异步排查变成同步扫描，实现左移。
前端展示和运营闭环：为不同角色（如安全人员、开发人员、架构师等）提供定制化的界面和功能，提高用户体验和效率，前端需要能自动判别是否已经修复。
场景打磨：根据用户的反馈和需求，不断优化和创新数据处理的方法和模式，降低噪音。这个阶段，安全和其他角色的协作共创会更加顺畅和高效，更加相互信任。
最后，希望可以帮助到各位负责企业安全的朋友们，也欢迎大家留言区分享和评论：在安全运营中心/态势感知运营方面，您公司是如何进行告警降噪的？有哪些落地的经验或者有哪些解决思路可以分享呢？
如何进群？
原文始发于微信公众号（君哥的体历）：安全运营中心SOC告警降噪方法讨论
