背景

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对此跟进做的后续报导56

最为引人注目的是,当 Bloomberg 发布轰动一时的深度报导7后,众多舆论压倒性地指责 Target 所犯的“低级”错误:现网FireEye设备检测到exfiltration malware8的安装过程并进行多次告警(入侵者多次更新过版本),由印度安全监控人员上报给美国 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 SecureWork 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. https://www.securityweek.com/security-operations-moving-narrative-driven-model

声明:本文来自Viola后花园,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。