=Start=
缘由：
没事的时候多看点文章学点东西，避免闲下来不知道干什么，反正总比漫无目的的刷短视频要好。为了更聚焦一些，之前整理了一批想了解想记录的主题，这就是其中之一，在原定主题的基础之上再搜索阅读整理记录一下其它文章中对我来说印象深刻的点，形成一篇文章，方便后面有需要的时候参考和查阅。
正文：
参考解答：
对于开发和运维来说：
监控告警是稳定性运行的基石。
对于安全来说：
监控告警是安全运营和响应的基础和前提。
监控的几个主要指标：
- 准确率：分析产生了100条告警，但是只有60条告警是对的，这时告警的准确率是 60% 。
- 召回率：实际中其实一共有80次异常操作，但产生的100条告警里只覆盖了80条中的60条，这时召回率是 75%(60/80) 。
- 告警延迟：异常操作是在时间点T进行的，但是告警时间是在T+1，这时告警的延迟就是1天，一般情况下离线数据分析的延迟都是在天级别或小时级别；实时的分析用Storm/Flink延迟一般是秒级别或分钟级别，但这种一般是针对比较简单或很准确的告警策略才行，否则告警量会爆炸。
前期不要太关注准确率，先尽量把召回率给提上去，把已知的各种异常类型覆盖住；然后通过日常的不断运营提高准确率；在准确率达到一定程度之后再去上实时策略，降低告警的延迟。
==
告警降噪在SOC工作中是一个本质性、长期存在的问题，是系统工程，没有银弹。告警降噪方式没有最好，只有更好，需要长期持续优化形成适合自身公司的方法论：
1、日志质量问题。数据分析中的“垃圾进垃圾出”原则对于安全告警分析同样适用。
2、创建告警策略要追求质量而非数量。告警策略不追求多，优先级高的安全风险先建告警策略，告警策略在正式投产运行之前需要通过测试和验证。
3、告警是需要运营的，每天把报警前50或前10消除，找到根因，也很有效果。
4、业务与架构治理：九龙城寨天天小偷小摸，打打杀杀，到底哪一次是真正高价值的告警，就很难判断了。
5、和运维、变更管理系统进行联动，避免自己人的干扰。
6、没有能安静下来、知攻知防有经验踏实干活的人，上面几条都是白扯，最有效的方法是找到并使用这样的人，他会找到更多方式。
==
对于7*24小时不间断运行的后台服务，监控告警是稳定性运行的基石。很多开发者都有过这样的经历，对服务的每一个指标都做了严格的监控和告警，唯恐漏掉告警导致问题无法发现，导致每天接收到大量的无效告警，告警的泛滥逐渐麻痹了警惕性，结果真实的问题初漏端倪时却被忽略，最终导致了严重的故障。
如何提升告警的有效性，准确识别问题，同时又不至于淹没在大量的无效告警中，正是本文所探讨的内容。
告警是可靠性的基础
首先来看一下告警的重要性，为什么我们需要耗费这么多精力来优化告警。虽然我们都期望一个服务是没有故障的，但事实确是不存在 100% 没问题的系统，我们只能不断提升服务的可靠性，我们期望做到：
- 对服务当前状态了如指掌，尽在掌控
- 能够第一时间发现问题，并且快速定位问题原因
要想做到以上两点，只能依赖完善的监控&告警，监控展示服务的完整运行状态，但是不可能一直盯屏观察，并且也不可能关注到所有方面，要想被动的了解系统状态，唯有通过告警，自动检测异常情况。
告警面临的现实问题
理想中的告警，不存在误报（即本来正常的，告警为异常）也不存在漏报（即本来异常的，误认为正常），所以理想的模型满足以下三点：
- 误报为0：出现的告警都是需要处理的问题
- 漏报为0：异常问题都能够告警发现
- 及时发现：能够第一时间发现问题，甚至于在导致故障前发现问题
但在实践中无法做到理想情况。要减少漏报，需要针对每一种可能发生的场景进行监控，同时配置告警，这其实并不算困难；但我们的告警往往不是太少了，而是太多了，以至于需要耗费大量时间处理无效告警，由于告警过多，容易忽略真正有用的告警，导致异常发现的时间变长，或者忽略的潜在的风险。所以对于告警，最大的问题在于如何减少无效告警，提升告警的效率。
先来看一下无效告警产生的原因。
监控系统应该解决两个问题：什么东西出故障了，以及为什么会出故障。其中“什么东西出故障了”即为现象，“为什么”则代表了原因（可能是中间原因）。现象和原因的区分是构建信噪比高的监控系统时最重要的概念。
在实践中，想绝对做到这两点几乎不可能，但我们可以无限趋向于理想模型。
告警一般是通过“现象”来判断，而是否有问题要看产生现象的原因判断。相同的现象引起的原因可能不同，这种“可能性”是导致误告警的最核心原因。
告警分类
同样是告警，对于CPU跑满这种情况需要立即处理，但对于单机健康状态告警（正常情况下异常机器会自动置换，异常情况可能置换失败），系统并不能自动解决这种状况，但是一段时间内不处理，也不会造成影响，负载均衡设备会自动摘除。
所以这里涉及到一个告警分类的问题，当然，告警可以有很多种分类方法，分成很多种级别区别对待，但在优化无效告警的目标下，我们通过是否需要立即停下手头工作立即处理，分为三类：
- 紧急：收到报警就需要立即执行某种操作。如CPU跑满，内存跑满等。判断标准，是否对业务有影响，以及是否有潜在的未知风险
- 不紧急：系统并不能自动解决目前状况，但是一段时间内不处理，也不会造成影响。如单机出现访问不通异常。判断标准，对业务无影响，基本无潜在的风险，但最终需要人工介入处理
- 不需要处理：已知异常并且系统会自动恢复，不需要人工接入。如机器虽然出现异常，但运维底座会再一段时间内自动处理，不需要人工介入
对于一个异常，首先需要判断是否需要立即处理，区分进行优化。
告警设置原则
- 告警具备真实性：告警必须反馈某个真实存在的现象，展示你的服务正在出现的问题或即将出现的问题
- 告警表述详细：从内容上，告警要近可能详细的描述现象，比如服务器在某个时间点具体发生了什么异常
- 告警具备可操作性：每当收到告警时，一般需要做出某些操作，对于某些无须做出操作的告警，最好取消。当且仅当需要做某种操作时，才需要通知
- 新告警使用保守阈值：在配置告警之初，应尽可能扩大监控告警覆盖面，选取保守的阈值，尽可能避免漏报。
- 告警持续优化：后续持续对告警进行统计分析，对误报的告警，通过屏蔽、简化、阈值调整、更精准的体现原因等多种方式减少误报，这是一个相对长期的过程。
善用工具
另外优化告警的一个必备条件，就是要熟悉所用告警平台使用，如果都不知道告警平台可以做到什么程度，可以设置怎样灵活的条件阈值，是很难对告警做合理优化的。
告警处理流程
前面提到了告警的优化是一个持续的过程，不存在一劳永逸的事情。需要每天或者每周安排值班人员负责告警事宜，这点上确实是需要一定的投入。值班同学需要持续关注告警的有效性，对于出现的无效告警，分析清楚原因，持续优化阈值或者告警策略。
- 确保能够收到所有告警：可以通过接收人组解决，确保所有值班同学都在一个接收人组，如果有人员变动也方便修改
- 上升线路：需要判断问题的严重性，适合时机上升，增加资源快速把问题消灭再萌芽状态
- 明确根本原因：确保弄清楚问题原因，而不是表面上恢复。比如单台机器CPU跑满告警，可能存在未知的死循环问题，如果仅仅重启进程恢复，很可能掩盖了问题，导致未来出现大面积的死循环引发故障
==
有效告警配置难、维护难的原因
- 许多运维指标起伏不定，很难设定合适的静态阈值。
它们往往呈现出以小时、天、周为周期的季节性特征。这些指标本身就起伏不定，导致静态阈值、同比阈值都不好配。- 同一指标，不同应用/接口阈值不同。
以 RT 指标(响应时间)举例，有的接口正常时 RT 在 200ms 左右，那么当 RT 大于 300ms 时，可以判定为异常。然而，有些接口长期访问量大，整体指标在 500ms 左右正常波动，合适的告警阈值可能是 600ms 左右。而一个应用可能有几百个接口，运维同学要对所有接口配置合适的阈值，时间成本非常高。- 指标的正常水位会随着业务的增长变化。
随着公司业务发展、新应用上线，一些指标正常状态水位会不断变化。如果没有及时更新阈值，就很容易产生大量误告警。我们希望能够从历史指标数据学习指标的特征，并对未来一段时间内指标正常变化范围做出预测，生成上下边界。这里的上下边界围成的区间默认就是 90 置信区间——也就是按照前面几天的趋势，指标没有发生异常的话，有 90% 的概率，它未来的值会落到我们预测得到的上下边界中，尽力做到精准告警、泛化能力强，在提高或保持告警准确性的前提下降低维护成本。
参考链接：
无效告警优化实践总结
https://mp.weixin.qq.com/s/cBCaHwEvQFGM7RNDMMavzA
跟误告警说再见，Smart Metrics 帮你用算法配告警
https://mp.weixin.qq.com/s/jfT1pqKXGh3JjT5ajR8qTA
安全运营中心SOC告警降噪方法讨论
https://mp.weixin.qq.com/s/bk_mzU67VnQ2PiMKAuO7ng
关于安全告警规则运营的思考 | 总第200周
https://mp.weixin.qq.com/s/cpkbGE52S8fEa06AoU8t_w
Effective Alerting in Practice
https://newrelic.com/resources/ebooks/effective-alerting-guide
Why most monitoring strategies fail
https://abdulapopoola.com/2022/11/16/why-most-monitoring-strategies-fail/
为什么你的大多数监控策略都失败了
http://www.yunweipai.com/43193.html
=END=
《 “如何让监控告警更准确？” 》 有 4 条评论
Why most monitoring strategies fail
https://abdulapopoola.com/2022/11/16/why-most-monitoring-strategies-fail/
`
感知与现实脱节（Disconnect）：组织对用户体验的感知与实际用户体验之间存在鸿沟。
不信任（Distrust）：告警疲劳。一个大的危险信号是对触发警报缺乏信心。监控系统发出的错误警报越多，工程师们就越不信任这个系统。不幸的是，这种低信噪比的状态加速了失修周期；工程师们厌倦了不断喊“狼来了”的监视器，直到不再关注这个问题。在这个阶段，你就应该拿着爆米花，等待不可避免的大规模中断。
组织混乱（Disorganization）：缺乏有效且明确的可操作SOP。没有特定的案例，给到的“建议方法”取决于你与谁合作。这种缺乏组织性和清晰指导的表现为监控框架激增、缺乏实战检验的工具以及临时中断补救措施。工程师们总是采取碰运气的解决方案，例如重启电脑，并希望“问题”消失）。
失修（Disrepair）：缺乏持续的更新和维护。工具、系统和警报已经失修。产生问题的原因各不相同，有的是服务处于维护模式，有的是由于损耗而缺乏专门知识，还有的则是半死不活的项目。
==
以用户为中心的可观察性指标有两个目标：
1. 指导完成目标。它们用户为改善服务提供了一个目标灯塔——帮助确定优先次序、跟踪修复工作，并将重点放在杠杆率最高的干预措施上。它们也可以被整合到组织实践中（如服务审查、事后检查等），以确保细微的偏差不会被忽视（如几周内健康趋势下降了 0.05%）。
2. 主动警报。它们高度准确，可以提供回归的早期警报。健康指标的任何突然和持续下降都与真正的用户影响直接相关。在这些指标上设置警报将弥补生产上的可观察性差距。
==
确保你的监控策略与最终目标直接挂钩。
* 告警逻辑要和真实情况相符，不能存在脱节（Disconnect）的情况。
* 发出的告警需要准确，不能总是错误的，否则容易让人产生告警疲劳，对告警不信任（Distrust）。
* 告警信息要给出有效且明确的可操作SOP，避免让人干着急。
* 告警策略要进行持续的维护和更新，避免工具、系统和告警出现失修（Disrepair）的情况。
`
为什么你的大多数监控策略都失败了
http://www.yunweipai.com/43193.html
如何减轻WAF误报带来的业务风险？如何衡量告警的漏报与误报？| 总第214周
https://mp.weixin.qq.com/s/2GRQbK95j9eiSlWsUZW5Pw
`
* WAF有**观察模式**，可以先观察告警一周，稳定了再拦截呀，然后对误报策略进行调整。
* 这个要做WAF**有效性验证**，前期黑名单守住底线，需要你有抗压能力，然后收集日常访问信息后再细化策略。
* **有误报很正常啊，不能给领导和开发没有误报的预期。**我们没上rasp，没钱买不起，开源的没人搞。
==
* **误报只是噪声了，漏报有时候是关键的，所以我是宁误报别漏报**，漏报就说明你的产品没有覆盖全。误报场景也很多，不太好数字化的，除了设备自身能力外，各种环境也会触发非入侵的告警。
* **漏报是安全建设最难解决的问题，误报是安全运营最难解决的问题。**
==
# 话题一：请教各位大佬，有没有WAF的最佳实践？域名一接入，策略即便很宽松也对业务有影响，或多或少总会拦截正常业务访问的，然后被投诉。对于跟开发沟通成本较高的组织，WAF真的有必要吗？
A1：这个要做WAF有效性验证，前期黑名单守住底线，需要你有抗压能力，然后收集日常访问信息后再细化策略。
A2：我们是所有暴露公网的web没有商量余地全部接WAF，内网的可以做不同策略。你的waf最好不是基于特征的，最好开发是规范的，这得分析误报原因，并通过观察模式来减少。
Q：多少次有效拦截或攻击防护不重要，但凡有次拦了正常访问，就群起攻之了。
A3：可以不开WAF啊，叫他们领导签字就好了。出了任何安全事故，责任，他们领导承担。公网应用不上WAF，这是要上天吧，随便找个扫描器应用就要坏吧，都不用渗透的。
回到规则类waf误报太高问题，可以试试基于语义的waf，不过根源还是开发规范。我遇到的waf误报，主要源自开发不规范，这个时候我会先定义，waf该不该报？waf不该报的报了，叫误报。waf应该报，但影响业务了，说明业务可能是有漏洞的，咱们去渗透测试。
A4：上线应该有个试运行阶段吧，让业务触发请求，告诉领导可能有误拦，这段时间调整策略，过了阶段后面误拦推给业务之前没触发过请求，另外每次升级规则后注意一点新增的误拦情况。waf有观察模式，可以先观察告警一周，稳定了再拦截呀，然后对误报策略进行调整。
Q：我们基于规则的，大多也是开发团队编码不规范导致的，误报很高，一般影响访问了只能临时关掉策略。
A5：边界松口，后面镜像流量分析，hids告警更加多，更难降噪。之前其实探讨过，在安全团队还不成熟，人员、技术不完善的情况下，边界控制已经是最容易实现安全防护的方式了，性价比非常高。而WAF又是其中重点，要是这个都能退守，那后续的更难。咱们心理上就得有底气，守住。
A6：有的业务很离谱，在前端传sql，能不拦吗？我们因为接口加密规范太多，waf没法检测，那必须得上rasp，body、字段加密，下游穿了，走正常业务过来的APT非常难搞。
Q：还是要具体分析为什么误报。所有应用都上rasp了？
A7：有误报很正常啊，不能给领导和开发没有误报的预期。我们没上rasp，没钱买不起，开源的没人搞。
# 话题二：大佬们，告警准确度大家从哪几个指标落地衡量？
A1：准确度不难，准确度=1-误报率，难的是漏报以及漏报和误报怎么平衡，我们现在也有这个困境。
A2：我觉得不要漏报优先，误报可以慢慢排，如自己发起内部攻击并对比监测到的攻击来检验漏报，告警事件汇总与真实需要处置的安全事件对比来检验误报。
A3：漏报不好识别，误报还好，这个涉及到了设备告警的有效率，用BAS来验证有效性，但是覆盖不全，总会有遗漏。
这是一个长期的过程，或者找相关的专业人士来配合进行验证漏报，这种手段既可以解决覆盖问题，也可以衡量漏报问题，之前也这么尝试过，的确发现了很多覆盖和漏报的问题。设备告警的有效性就需要专门做攻防的人来研究了。
A4：误报只是噪声了，漏报有时候是关键的，所以我是宁误报别漏报，漏报就说明你的产品没有覆盖全。误报场景也很多，不太好数字化的，除了设备自身能力外，各种环境也会触发非入侵的告警。
A5：我们验证过的市面上的设备都存在不少漏报。我以前就看谁的漏报少，然后才是看误报，特别是关键的不能给漏报了。感觉主要还是目前市面上的安全设备各自为政，的确总是存在漏报的场景。
误报的结合SOAR等自动化手段，比较容易识别。针对没有ioc情报的攻击事件，很难识别准确，我们自己打的都识别不到。
总之，减少漏报个人感觉需要有专门的人去维护规则，持续更新。另外就是以攻促防去验证查漏补缺。误报就比较好处理，根据业务场景慢慢针对性地优化规则就好了。另外研究一下BAS还是有必要，BAS+红队评估。
A6：漏报是安全建设最难解决的问题，误报是安全运营最难解决的问题。这就需要厂家的行动力，比如谁最快响应和更新。
A7：漏报是一定有的，比如0Day，没有发现前，大家都不知道。
A8：排除0day这种情况，这个太特殊了。我前段时间模拟了内网横向的通用手段，告警率和拦截率有点低。内网横向的攻击监测目前国内没啥好的产品吧，现在的设备基本上都是基于ioc和通用规则，主机侧的防护设备都不告警，已经落地到机器上面了。
A9：只做过流量层的，主机测是否告警倒是没有尝试过，下次有机会试一下，又长见识了。
A10：我们测的主机测的，现在的c2马基本上都是加密通信了，流量设备没有加密流量特征的话，比较难识别，主机侧相对容易。总之需要多维度，多层面建立纵深防御体系，每个层面的告警很难做到万无一失，端侧和网络侧结合起来。
A11：端侧不乏机器就被干掉了，告警还没出来的情况，只能搞体系话，不要依赖一个点。有新漏洞产生就会有漏报现象出现，解决漏报又需要新的规则。有新规则就会有新的误报产生，所以个人感觉还是得通过自动验证，验证安全设备的有效性。不至于应用安全，邮件安全，主机安全，等等都需要持续验证有效性。像GET的接口，现在最后个id都表示资源，不知那些产品能不能归并到最上一层。
`
已完美适配 APPLE M3 和 macOS Sonoma
https://mp.weixin.qq.com/s/icjokphQXbjTjd60jkeWEA
`
先刷重点。
青雅 DDR 已完美适配 APPLE M3 系列芯片和最新系统 macOS Sonoma
所有兼容适配都在面市一个月内完成。
1. 安装无需关闭 SIP
安全启动 (System Integrity Protection，简称SIP) 是苹果操作系统上的一项安全功能，是确保系统更高等级安全的必要手段。它限制了root用户和其他进程的访问权限，以保护核心系统文件和目录。许多 DLP 软件需要关闭 SIP 才能进行安装，这往往也会存在较大的安全隐患，而 青雅 DDR 可以在不关闭 SIP的情况下安装，在实现系统完整性保护的同时，确保系统的稳定性。
* 安装包约30MB，轻量简约化，一键推送安装
* 大文件检测效率提升，终端用户感知低，保持超高效能
* CPU 占比低至1%，青雅 DDR 支持终端进程设定资源使用上限包括CPU占用率、内存使用量和网络带宽等
* 有效减少80%误报，充足上下文和 AI 加持，数据防护效率大幅提高
企业数据安全，DDR 与你共同守护。
数据资产安全：
Data 数据
数据资产扫描
数据分类分级
数据专项治理
Detection 检测
数据流转追踪
数据资产测绘
行为洞察
Response 响应
溯源取证 标密定密
DLP阻断 代码管控
文档加密
数据环境安全：
桌面管理
合规基线 外设管控
软件管理 介质管控
网络管理
进程联网
网络准入
运维管理
无损安装 紧急逃生
IM同步 机器人告警
`
如何降低规则的误报率？
https://mp.weixin.qq.com/s/wHmYomTXBEwisS5IzntFmQ
`
DLP 规则和策略的制定与管理（日常的日志、风险和事件的审计与跟踪）是一项繁重的工作，配置的不合理或不准确，会导致较高的误报率，同时也会影响内部用户体验以及公司业务运行。
本文从实践经验出发，围绕如何降低规则误报率，分享一些规则配置的指南/技巧，希望能对相关的安全从业者们提供一些思考与帮助。
01-制定文件识别规则时，**词汇的数量不是越多越好，而是词汇的准确性越高越好**。因为许多词语是通用的，如果单条识别规则包含了过多的关键词，可能会误识别其他类型的文档。
例如：若要识别特定的财务报告，如果规则中仅包含如“财务”“报告”“数据”这样的通用词汇，虽然这些词汇频繁出现在财务报告中，但同样也会出现在其他类型的文档，如市场分析报告或内部会议纪要。这样的规则可能导致系统错判，从而产生误报。
相反，如果规则包含更准确的词汇组合，如“财务年度”“盈利报表”“资产负债表”等，这些词汇不仅在财务报告中出现频率高，且很少出现在其他类型的文档中。这样的规则将更准确地识别财务报告，减少误报的可能性。
02-**尽量使用 “至少命中M项” 这样的条件，而 “至少命中N次” 这样的条件适合作为辅助条件**。
例如：要判断一个文档是否为规划类文档，【至少命中“目标、研发项目、建设、关键节点、里程碑、方案、资源”5 项（即这 7 个词中有 5 个出现在一个文档中）】的规则准确率会高于 【至少命中 5 次（可能存在命中了“建设” 5 次的情况）】。
03-在识别规则中可以加入公司名称/简称或者是公司专属名词，以排除非本公司的文件。
例如：可以通过增加“薮猫”“薮猫科技”“青骓 DDR”等公司专属名称，或者有特色的高管人名/花名等，可进一步锁定公司内部文件，缩小识别范围。同时，也可以辅助增加命中的次数来提高识别精准度。
04-可以加入文件后缀作为判断条件。
例如：报表、列表类文件，一般都为 excel 文件。
05-**可以适当地对关键词进行拓展与扩充，若靠个人实在想象不出更多常用词语，也可以尝试问问 ChatGPT **。
06-**规则上线后，多查看风险详情日志，分析每个误报的原因，继而完成策略/规则的优化**。
==
青骓 DDR 提供了更智能、更高效的方式
01-内置丰富成熟的安全规则与策略，一键启用。
凭借薮猫科技团队在安全行业的丰富实践经验，青骓 DDR 在遵循以上原则的基础上，内置各类成熟的安全规则与策略，让安全策略的配置和使用变得简单易行。
02-主 & 被动数据持续发现，逐渐完善文件识别规则。
青骓 DDR 通过资产主动发现功能，可以对企业数据文件进行全盘扫描，再通过聚类功能将相似的文件聚合，提取出类似文件的关键词，做成文件内容识别规则。
此外，青骓 DDR 还支持将所有办公文件都进行审计，通过每天查看传输的文件名来进一步补充和完善分类集和文件名识别规则。
03-AI 技术的深化应用：实现效率的倍增。
青骓 DDR 利用 AI 技术，对数据文件进行智能精准识别，大幅提升安全运营效率。
**规则和策略的配置是一个需要持续思考和优化的过程**，它要求安全团队不断深入理解业务流程和数据分类分级，并全面考虑各种潜在的数据泄露场景。同时，由于数据类型和业务场景的多样性，安全团队需要动态调整和持续优化，以应对环境的不断变化。
`