背景

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后花园，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。