---------------------------------------------------------------------
我发誓,再也不会将文章拆成上下篇,思路断的实在是太厉害。
---------------------------------------------------------------------
【1】通用的告警体系
预设一个通用结构,大概如下:
将原有告警体系作为辅助判断的机制,所以无需破坏原有告警体系。
为了增加威胁的确定性,需对所有IP进行最小粒度的精确信息探测,形成针对端口、应用和版本的列表清单,例如:
通过威胁信息、NetFlow、告警和资产情况可判断其攻击的确定性,如:威胁信息提供“针对TCP 135蠕虫”,则:NetFlow确认出现流量、告警确认出现内容、资产确认目标端口开放可达。
但这里会涉及到原有告警体系中的告警内容的标准化,由于告警的命名不统一,所以可能各说各话导致信息串联起来并没有那么顺畅,这里有两种方式来解决:
-
最有效的方式就是未来产品支持威胁情报推送,这样就形成了告警的标准化,而这个判断依据中的第三方平台也不再需要接受外部信息了,直接把信息扔到内网或边界的产品上就可以了;
-
有可能比较折中的方式,现在多数安全产品推送告警的时候支持五元组的方式,五元组里的source(ip:port)和destination(ip:port)就基本可以拿来进行匹配进行确认了;
这样的,形成几套判断机制。
第一,确定性告警:威胁信息 + netflow + 资产信息 + 告警 ,全匹配;
第二,预警:
-
威胁信息 + netflow + 告警匹配,所有资产均不匹配
-
威胁信息 + netflow + 告警匹配,目标资产不匹配,但其他资产匹配
第三,灰名单:
-
无流量端口(资产中存在,但在一段约定时间内,netflow无流量)
-
未在资产信息中的端口(netflow捕获到,但资产信息中不存在)
-
高频次的“netflow + 资产信息”匹配
-
跨区域(zone)的异常时间访问(基于历史累计的时间统计正常分布时间)
【2】依然存在的(普遍)缺陷
-
关联匹配过于复杂
上面已经提到了,由于原有告警体系对告警定义的高度不统一,所以需要过多的元素导入到一个集中平台中进行复杂的关联才能完善各种不足的判断机制,这大概也是SIEM类产品会持续不断发展和活下去的重要因素。
而未来如果能够通过威胁情报将告警标准化(至少部分标准化)并统一推送至各个安全产品之上,从匹配方式上来说将变得更简单,也许很多传统重型SIEM的工作可以逐步分化到不同环境中去,形成多个轻量化的SIEM来根据特定环境进行关联然后再进行二次汇总,最终形成一个异步的SIEM体系,既保证效率,更提升了准确性。
-
评价问题
APT 作为一个过程化和持续性极强的隐蔽性攻击,如果不是攻击方主观定义完成或目标得到明确损失的话,任何一个环节的捕获和分析都可能无法被完整的定义成为一次APT。
所以这类就陷入了一个怪圈 —— 我捉到了一个0-day,这是一个多么隐蔽的APT啊!!! —— 质疑者总会有充分的理由反驳你:“为什么0-day就等于APT ?”
所以APT最大的困惑在于评价。
因为一次APT可能持续数年,经历无数次攻击、入侵、挖掘、分析等等一系列你所能想象或不能想象的动作。如果仅仅将其中某一个或某几个环节捕获分析出来,都会有大批质疑者来告诉你“这不过借风起势的一次自我PR而已”。
为了避免陷入对终极问题的反复尝试和推测,很多APT的评价都以特定、固化的场景进行评测 —— 假设,有Office 0-day出现在XX环境中,则认为,一次针对XX业务的敌对组织的APT是成立的。所以在我看来,之所以每次的APT报告篇幅都比传统的病毒或入侵分析要来的长,更多的是在于证明这是一次APT,而非真的想说明详细的过程。
-
拉黑与变形
是什么把APT的检测逼迫到了使用动态沙箱这种效能低下的手段上去的?
对黑客来说,保持一个权限如此之不易 —— 甚至他们远比那些安全管理员要更勤奋。因此要不断的关注他权限所处环境中的细微变化,随时根据新出现的检测规则来变化自己,其辛苦程度绝不亚于当初白骨精变来变去的去骗唐僧。
手段变化之多、变化之快、漏洞之新、exp之速,逼得大家最后只好在黑名单之外再加上一道行为沙箱。不过,沙箱很快又再次遇到了“若拉黑则形变”的新困境,沙箱逃逸技术现在也不是什么高科技了,很快又需要寻求新的反形变技术。
本文始发于微信公众号(Piz0n):杂谈 APT(下)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论