🥷
🥷
文章目录
  1. 其他
  2. Resources

ATT&CK与入侵检测

突然,那么一刻。我觉得朋友圈又开始全部在炒作ATT&CK了。不懂得为什么突然这个框架火了。不过更多是跟风,一问落地都不答。直到看到内网也开始有人讨论这个东西了。想想,正如股市,盈利的原因终究是因为把握趋势,而不是因为涨跌。有的人能把握住,有的人把握不住。 正好一直做的东西和这个有点关系吧。入侵检测用ATT&CK作规范,完成场景覆盖。(不过,我始终觉得,不应该依赖于任何一个框架),探索未知才是正确的。

谈到ATT&CK来规划入侵检测规则。让我们先看看下图。这是目前我设计的一套很基础的检测流程。基础思想是针对数据分层过滤,(当你面临数据不足的时候,更重要的是一定要知道自己需要哪些数据,可以利用哪些数据补足,满足检测需求。)无论是针对原始数据还是告警数据。同时需要注意的时,告警升级为事件后的应急响应链路要尽可能的短平快。

image

从图中个可以看出,数仓建设 分层检测。具体到实施就是规则分级,建立反哺机制,以数据链路为基础,去完成该检测的性能控制。但是需要注意的是,比如你依赖HIDS采集的数据,是否能保证覆盖率?如果不能又该怎么办? 如果依赖了资产数据,那么资产数据能不能保证及时的更新,如果不能,能接受多大的延时?
至此,还是没有提到ATT&CK, 对于我而言, ATT&CK在此处就是根据提供的场景产生对应的规则。可以是单点,可以是链路的检测。对应到规则上就是数据源的多少,一次采用几个数据源进行检测,如是而已。
针对数仓建设,我之前有写过一篇日志收集的,当然日志收集只是初步,把数据的领域化知识输出才是我们需要的。

image

我们可以按照上图来根据公司的自身情况去进行收集。当用户通过业务交互到达主机时,会经过大概以下组件(针对不同的人员,注:不一定全,也不一定全部经过)那么来看一下正常的攻击链路

image

目标主要为了通过对业务的交互能获取到主机的交互(外面每层都是防御系统,或者是检测系统,图中有一点没有表示出来的就是针对业务系统和IT系统,云上和IDC的不同环境导致的覆盖问题),或是直接从主机出去,或者原路返回(这一类更难检测),针对外联的检测,当你拥有IDC和云上的出口流量五元组,配合资产表,以及访问接入层的机器列表(都可以从资产列表中分析出来),那么最基础的出网管控就检测完了。而你的依赖就是新增的机器和白名单放行,要及时的添加到资产数据中。同时要能够保证出口流量获取的有效性。

至此,是不是还是感觉和ATT&CK没有关系,其实不是的,你已经在做其中某些的场景规则。下面仅以生产网再举个例子(图中部分场景不是)。

image

从ATT&CK选取了如上的场景,开始做规则检测。为什么没有针对Iinitial这一块做,一来是这边的业务系统在流量层面本身有waf的防御检测,以及阿里云基础设施的防御检测。但这并不意味着其他公司不需要。同时之所以选取这几个场景,还是因为一个问题是有的数据采集不到。在入侵检测过程中,一部分必不可少的就是基础数据分析,然后针对指标进行分析。最后根据指标找到目标去做入侵检测。比如说C2场景中的一个Commanly Used Port 需要先对整体环境Commanly Used Port进行分析,再对单台主机的Commanly Used Port进行分析。过滤出常用的,在根据不同的VPC,不同的IDC设定。而不是上来就是我写个规则,过滤下常见的22,23,80,443,8080… 其他的就ok了。同时像DGA这种检测,需要依赖抓取到的域名数据用规则和模型分别去检测。

总之这篇似乎谈ATT&CK不多,大多是谈入侵检测。但是内容就是大部分的入侵检测规则编写可以参考ATT&CK框架,同时针对已有的规则,打上ATT&CK场景的标签,再后续可以发挥Deep Learning Or Display Learning的魅力,去自动发现不曾用规则检测出的场景。

至此为止,文章结束。对于我个人而言,其实最开始接触ATT&CK的时候是为了研究APT攻击的手法,大概17年中吧。现在则用其来做入侵检测规则。但是,肯定不止这么多用处了,比如说给你的IOC加上场景标签,也是美滋滋啊。或者按照ATT&CK场景调整蜜罐系统,自动化适应攻击者场景,钓他的工具。

其他

我一度觉得,傻不可怕,坏才可怕。正所谓拿人消遣是傻X,劝人熬夜是坏X。 以及最近不知道为什么大肆鼓吹安全运营,说的似乎安全运营是No.1一样,安全运营存在一定的重要性是不争的事实。但是安全运营本身确实技术含量不那么高,也导致能够较为容易寻找替代对象的职位。不是说安全运营不好,我本身也承担着一部分安全运营的角色,正所谓不亲历则没有发言权。根据周边同事的水平状况,以及针对业界的现状。不难发现,当在一个小圈子内不再以技术为主,又要保住优势地位。似乎引领潮流像安全运营过度也自然而然了。当然你要是以除却安全研发之外的所有角色均为安全运营的话,我也没法反驳。但是现实往往是,大量的安全运营水平参差不齐,正如安全现状。安全运营是最容易提现出来的。比如有一次问集团的安全运营申请终端设备的数据表权限,缘由是用于办公网安全数据分析,结果该安全运营直接来了一句什么是办公网安全,这个和xx数据有什么关系。(我和该运营不认识,也无仇无怨),同样,在饿了么这边目前依旧存在部分的安全运营水浅瓶深。唯一剩余的优势可能是沟通能力和脾气。我们不能一棒子敲死,但也不能大肆鼓吹。正如不能鼓吹ATT&CK一样,也不能鼓吹安全运营。孰优孰劣,一试便知。

Resources