从 Target 事件看安全运营的困境

背景

2013年11月12日至2013年12月15日期间,攻击者以 HVAC 承包商 Fazio 为跳板,入侵了美国零售巨头 Target 网络,在其门店POS终端上植入“BlackPOS”恶意软件变种,用户刷卡时它会直接读取内存中的信用卡磁条信息,最终盗取了4000多万张信用卡信息以及7000万条包括姓名、地址、email、电话等用户个人信息,用于地下交易1。CIO和CEO相继引咎辞职,2014年6月 Target 任命了公司历史上首位 CISO。 2017年3月21日, Target 同意支付1850万美元用于赔偿47个州和哥伦比亚特区的索赔、以及针对这次事件开展的多州调查。Target 为这次数据泄露事件付出的代价为2.02亿美元2

安全运营困境

根据Bloomberg 报导3,不同于其他零售企业,Target 表现出了对安全的高度重视,雄心勃勃组建了300+员工的安全团队,花费160万美元购买 FireEye 产品并在事前6个月做了上线部署,同年9月还通过了 PCI DSS 合规认证。而这次事件被曝光后,则充分暴露了Target 存在一系列的安全问题,包括安全架构设计(安全域和权限管理存在问题)、第三方厂商管理(对于低级别的第三方访问鲜少采用双因子认证)、漏洞管理、安全告警响应等。详情可以参见美国参议院 CCST 委员会应用杀链模型做的案例分析4,以及最早公开披露这一事件的 Brian Krebs 对此跟进做的后续报导5 6

最为引人注目的是,在 Bloomberg 发布轰动一时的深度报导7后,众多舆论压倒性地指责 Target 所犯的“低级”错误:现网FireEye设备检测到 exfiltration malware 8的安装过程并进行多次告警(入侵者多次更新过版本),由印度安全监控人员上报给美国 SOC 中心,而美国安全团队“对此进行评估后,确定不需要立即跟进”9。Target 的安全人员事先关闭了 FireEye 设备的在线阻断功能。他们还忽略了 Symantec 终端防护软件同时被触发的告警。而事后调查发现,FireEye 和 Symantec 的告警信息中均包含相同的服务器地址,也即数据泄漏的对端服务器地址。到底是什么原因造成 Target 安全运营和应急响应机制失效?这其实是企业安全运营困境的一个缩影:

  • 太多告警
  • 缺乏上下文的告警

太多告警

Target 在内的多起重大数据泄漏事件发生后,研究机构 Ponemon 针对性做过一份调查报告“The Cost of Malware Containment”10。里面指出,平均而言,一个组织在典型的一周会收到近17000个恶意软件告警,其中只有19%(3218)是可靠的告警,而仅有4%(705)的告警会被进一步调查。这组数据说明了企业安全运营在人员和技能上的捉襟见肘。

回到 Target 事件本身,美国团队对告警做出了错误判断。结合事发生当时正值节假日购物高峰期,从常理推断,只能认为安全人员当时的工作超负荷,有太多的告警需要处理。FireEye 在其后的一份白皮书“THE SIEM WHO CRIED WOLF” 中,引用 ThreatTrack 前 CEO —Julian Waits, Sr. 观点:“面临日常运营常规困境时,忽略威胁告警已成为标准运营流程”,侧面说明了 Target 安全团队当时的处境。

太多告警实质是太多噪音的问题,需要优先处理的真实告警淹没于大量虚警(比如大量扫描行为触发的告警)和误报中。Josh Goldfarb 在《信噪比》11一文中,将信噪比概念应用于安全运营和应急响应,真实的告警被看作有效的信号,而误报则被视为噪音。这篇文章同时还讲述了 SOC A 和 SOC B 两个团队的故事。A 团队每天工作内容是处理100个可靠的、高精度的、能采取行动的告警。每个告警都会由分析师进行逐一review,如有必要则会有进一步响应。B 团队每天则面临10万个告警,而多数告警为误报。B团队的分析师会试图review最高优先级的告警,但由于最高优先级告警的数量也很大,往往分析师很难处理完所有这些告警。此外,由于大量误报,最后会导致分析师对告警变得不敏感。有一天,突发10个额外的、窃取支付卡信息的恶意软件告警。对于运营环境信噪比高、会逐条review告警的 A 团队,通过分析在24小时内识别到数据泄漏事件,并采取相应措施及时止损。而运营环境信噪比低且分析师只能review极少数告警的 B 团队,根本不可能重视这10个告警,自然也未能发现数据泄漏。很可能几个月后才从第三方获悉事件的发生,最终整个组织为此付出沉重的代价。根据 Josh Goldfarb 的经验,现实中 SOC B 的数量远多于 SOC A。

而误报带来的另一个负面影响则是,安全运营人员出于对误报的担心,会主动关掉在线防护设备的自动阻断功能,使得安全策略不能真正发挥效用。安全运营人员主要寄希望于人工干预判断和决策。Target 事件中安全团队对 FireEye 设备的处理方式,则证明在大量告警的运营环境中这种方式的不可行。

缺乏上下文的告警

Target 事件还涉及到安全运营的另一挑战,缺乏上下文的告警信息。在“Breaking the Target: An Analysis of Target Data Breach and Lessons Learned”12一文中,作者就FireEye威胁防御平台的告警信息样例做了分析,认为仅有“类型、严重性、异常行为标识以及告警内容的简单描述”等信息,缺乏威胁相关的上下文信息,不足以帮助分析人员做充分判断。在当时路透的一份报导13中,也有类似观点。Target 事件中,FireEye 的告警名称为“malware.binary”,虽然当时触发了最高级别的告警,但缺乏更多信息,很难引起分析人员的重视。Josh Goldfarb 也认为,真实的告警没有得到妥善处理,原因可能是,“当告警触发时,分析师不得不以很少的支撑证据作出快速决定,或者花费宝贵的周期来构建针对事件的叙述。当告警量太高时后者将变得非常困难。因此,一些真正的积极因素将被忽略”14

Josh Goldfarb 在 “Security Operations: Moving to a Narrative-Driven Model”15中写到:“当前安全运营是基于告警驱动的模式,不同技术生成的告警被发送到工作序列中。分析师和事件响应人员按照工作序列中的优先级进行处理,并在所需的范围内针对每一个告警进行分析和取证,试图全面了解告警相关发生的事情,也即事件叙述(the narrative)”。“告警是一个瞬时快照,而事件叙述则是还原了一段时间内攻击链展开的过程。后者提供了威胁的背景和细节,安全人员才有可能做出是否需要响应的决策,如果是,还需要采取什么级别的响应”。

再结合之前的传统实时防御产品,单纯基于规则检测,在真空中分析攻击、不考虑环境数据和威胁情报,设备产生的告警,往往缺乏上下文信息。比如我们在 Web 服务器防护场景下经常看到的 SQL 注入告警,它有时候是扫描行为的产物,有时候又是真实人的攻击行为,或者可能是误报。针对这类可能大量产生的告警,在实际运营中多数人的选择可能是,仅在出报表时会特别关注。那么我们是否能够对这些攻击告警给予更多的上下文信息,使得安全人员在需要的时候,可以对攻击性质做判断,比如相关 IP 最近在互联网上是否存在攻击活动、是否为扫描器 IP、是否采用匿名代理、是否为企业出口 IP 或者 IDC 服务器 IP、IP 地理信息等等。另外还需要关注是否有后续阶段的攻击告警。

硬币的另一面

最后,回顾整个事件,我们不难看到堆砌再多的安全产品也难以达到理想的效果,安全运营是技术、人、流程三方面的有机结合。而其中最基础的问题是,我们需要给告警添加更多的上下文,用更快速的方式去掉误报和虚警,否则有再多的安全运营人员也无济于事。在这个领域,当前已经有很多新兴的技术或产品推出,它们有希望帮助我们解决这方面的问题,包括威胁情报、SOAR(Security Orchestration, Automation and Response)。让我们拭目以待。

  1. https://www.commerce.senate.gov/public/*cache/files/24d3c229-4f2f-405d-b8db-a3a67f183883/23E30AA955B5C00FE57CFD709621592C.2014-0325-target-kill-chain-analysis.pdf
  2. https://www.reuters.com/article/us-target-cyber-settlement/target-in-18-5-million-multi-state-settlement-over-data-breach-idUSKBN18J2GH
  3. https://www.bloomberg.com/news/articles/2014-03-13/target-missed-warnings-in-epic-hack-of-credit-card-data
  4. https://www.commerce.senate.gov/public/*cache/files/24d3c229-4f2f-405d-b8db-a3a67f183883/23E30AA955B5C00FE57CFD709621592C.2014-0325-target-kill-chain-analysis.pdf
  5. “Target Hackers Broke in Via HVAC Company”, URL: https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/
  6. “Inside Target Corp., Days After 2013 Breach”, https://krebsonsecurity.com/2015/09/inside-target-corp-days-after-2013-breach/
  7. https://www.bloomberg.com/news/articles/2014-03-13/target-missed-warnings-in-epic-hack-of-credit-card-data
  8. 本次入侵主要有三个恶意软件,exfiltration malware将已盗取到的数据周期性传输到外部中转站。源:”Inside a Targeted Point-of-Sale Data Breach ”, Dell SecureWorks CTU, URL: https://krebsonsecurity.com/2013/12/sources-target-investigating-data-breach/
  9. https://www.nytimes.com/2014/03/14/business/target-missed-signs-of-a-data-breach.html
  10. https://www.ponemon.org/local/upload/file/Damballa%20Malware%20Containment%20FINAL%203.pdf
  11. https://ananalyticalapproach.blogspot.com/2014/03/signal-to-noise-ratio.html
  12. https://arxiv.org/abs/1701.04940
  13. https://www.reuters.com/article/us-target-breach/target-says-it-declined-to-act-on-early-alert-of-cyber-breach-idUSBREA2C14F20140313
  14. https://www.securityweek.com/security-operations-moving-narrative-driven-model
  15. 同上

你可能感兴趣的:(从 Target 事件看安全运营的困境)