为什么安全团队越来越疲于应付告警? 该如何减轻他们的工作负担?
现代安全团队中存在一个太过常见的现象: 来自多种工具 (有时候是错误配置的) 的告警流淹没运营中心, 迫使分析师分辨并排序哪些告警值得注意. 可以说, 重大问题会在错过关键告警时出现, 并导致安全事件.
加剧告警疲劳的一大因素就是安全团队对自己的配置或自己拥有的资产没信心或不确定. 最终结果则是被大量警报淹没, 因为他们不理解问题的本质, 也没有时间去理解.
很多公司被告警淹没是因为他们之前从不需要处理这些告警.
太多公司直到最近都还没真正接受自己必须检测攻击并响应事件的事实. 如今, 这些从未拥有安全运营中心或安全团队的公司企业, 正在采纳威胁检测, 准备不足也是肯定的.
安全工具组合也在给报警疲劳问题增加砝码. 我们如今查找威胁的范围比以前是广阔得多了. 要监视的东西更多, 告警也随之增长. 当然, 告警过载最明显的风险, 就是公司企业可能会错过最危险的攻击.
如果安全人员不得不处理超量告警, 他们最终会士气低落, 产生职业倦怠. 更糟的是, 不堪应付的员工还可能干脆关闭自己的工具.
这不是技术的错, 问题不在于检测, 而缺乏排序. 商业安全环境中每个人都身兼数职: 解析数据, 撰写脚本, 知晓云端输入和输出, 还要管理安排自家环境中的各种技术.
如今流经企业网络的数据量可不是十年前能够想象的. 公司企业无不疲于应付, 告警暴击令他们陷于风险.
有问题就有解决问题的办法, 安全专家给出了他们关于告警疲劳成因与影响的思考, 分享了可用于缓解告警疲劳的工具和技术. 您用什么策略对抗警报过载? 哪些有效? 不妨参考专家的看法.
1. 自身用例
公司企业能做的最重要的事就是花时间理解自身面临的问题. 比如说, 如果你使用入侵检测系统 (IDS), 觉得告警太多, 你就需要调查自身环境中哪些东西可能引起太多误报? 相对于误报, 真正的告警有哪些特征? 真正的威胁是什么?
为减少告警流, 安全团队应有用于检测的用例. 你的最大担忧是什么? 如果你担心信用卡数据流出, 你就可以用 IDS 设置适用于你特定忧虑的规则.
检测用例应反映公司关心的东西. 高保真用例严格定义你的优先考虑. 没人会想说 "我怕任何数据流出公司". 该说的是 "我关心这种数据".
公司应花点时间仔细思考自己到底想要保护什么. 仅仅是照单划勾吗? 对着某个说你必须这么做的规定, 规则或垂直机构给出的清单划勾? 如果真是这样, 那可真是没检查对地方. 退回一步, 考虑你所有的数据 -- 你真的清楚它们都在哪儿吗?
在相信某条告警之前, 你必须了解自己的数据. 安全团队应仅在能够信任自己自动化的数据后才利用自动化, 分析的信息必须准确.
2. 小心配置
在采购威胁检测工具, 安全信息与事件管理 (SIEM) 系统或其他平台时, 别假定这些工具从一开始就能给出有价值的信息. 若对立即产生明确可行告警的系统抱有过高期待, 公司企业可能会恶化告警疲劳.
不存在一部署就产生明确可行信息的系统. 如果你用的工具 [显示] 每条告警都是明确且可行的, 那你很可能漏掉很多东西.
错误配置是个常见而危险的问题. 有些告警系统是乱枪打鸟式的, 因为安全团队由于过于谨慎, 宁可错杀一千不愿放过一个. 这就造成 "狼来了" 效应, 安全团队被毫无价值的告警淹没, 最终渐渐无视告警, 甚至真正重要的警报出现也不响应了.
配置系统的人缺乏正确配置所需的必要培训和专业背景是个很常见的现象. 有些系统可能会为对该特定工具而言关键却难以利用的漏洞触发紧急警报, 但实际上可能不需要采取这种 "重大消息立即关注" 的态度. 公司企业需更好地理解自己的问题.
错误配置是当今安全团队面临的最大问题, 给安全团队制造了更多工作量.
3. 威胁工具: 调整 SOAR,SIEM,EDR
安全编排, 自动化与响应 (SOAR) 工具无疑很有帮助, 但安全团队需根据自身情况校准该工具确认告警的方式. 运行活动目录 (AD) 的公司与采用专有系统的公司执行的策略就会不一样. 如果正确使用, SOAR 工具可以采取人类分析师会用的步骤确认告警.
EDR 工具帮助输送信息到分类告警的人手中, 还可以提供同一系统过去的历史告警. 这比帮助人类分析师无需太多挖掘就能做出判断还有意义.
有些公司外包告警工作给托管服务提供商 (MSP). 这种情况下, 最好告诉 MSP 具体哪些需要标记而哪些不需要. 外包, SOAR 和 EDR 都是解决方案的一部分.
对每家公司而言, 挑战与最佳实践都是找到工作流自动化, 外包和信息呈现之间的平衡点.
4. 学会操作已有工具
某些情形下, 公司某个工具的预算只够采购工具本身, 覆盖不了工具使用所需的培训费用. 有些公司提供的培训会很贵, 但与购买工具却发挥不了其价值相比, 还不如多花点钱做好培训.
与错误配置类似, 人员缺乏培训也是告警疲劳的一大原因. 安全团队需要从培训和经验中学习, 还需要向同事学习.
大企业最好多个安全团队使用同样的工具. 例如, 一家金融机构曾经部署了一款产品, 后来发现另一个分支机构也在用这款工具. 两家分支机构间的跨团队协作促进了整合, 节省了开支.
只要共享经验知识, 忽然之间就会发现产品好用多了.
5. 确保资产更新
确保任一系统的资产是最新版, 包括 EDR,VPN, 防火墙和云等, 也可以帮助削减告警量. 尽可能保证分析的数据是当前最新状态, 并经常检查这一信息. 数据是很容易过时的.
你不会想要等到必须亡羊补牢的时候再来后悔没事先更新数据. 安全团队可能会接到告警, 却在调查后发现 IP 地址已经不存在了. 有些东西可能早该关了却仍在运行, 新员工的笔记本电脑也有可能没加入到资产注册表中. 此类信息如果没有更新, 就有可能引发不必要的告警.
技术需要维护和清理. 安全团队必须确保之前构造的规则, 警报和仪表板仍适用于现在的企业环境. 并且, 购买新工具时也得确保没买入自己已经拥有却没能恰当使用的平台或功能.
6. 解释 "合法" 告警
有必要协调安全团队与服务提供商, 以确保告警不是因为某人忠于职守而产生的. 很多公司, 尤其是安全领域内的公司, 常必须调查恶意域, 文件或其他可疑发现. 安全团队可能会标记此类行为为告警.
公司内部需要调查安全事件的团队如果因为自己的调查而触发安全事件告警, 可能会产生很多不必要的戏剧性事件. 比如说, 安全人员可能会被标记为使用 Tor 浏览器, 但却是处于合法的业务需要在做研究.
7. 从过去的错误中学习
如果出了错, 错过了重要告警, 或者发生了安全事件, 最好记录下所有细节. 出现问题或技术挑战的时候, 团队记录下发生的细节会花点时间. 但这是向人显示环境中事务进行方式的简单方法.
在配置系统和了解警报的时候, 让当前和未来员工能够评估成功和逐步改进是很有帮助的. 案例研究能够准确描绘数据流经各业务环节的情形和团队解决问题的办法.
安全运营是个主动过程, 解决问题的答案存在于公司的风险意识中. 大多数公司在处理安全问题上都是反应式的, 但其实安全运营应该成为日常, 要主动发现潜在问题.
应主动记录, 规划和严肃对待安全问题.
来源: http://zhuanlan.51cto.com/art/201910/605025.htm