以业务行为驱动的反入侵安全能力建设

0x0 背景

    最近听到一些甲方安全领域的专家分享了部分安全建设的经验，对安全运营下的反入侵技术能力建设有了些新的看法，依靠单个/多个异构的安全产品的关联能力形成的安全中台并不能在实际的攻防对抗当中占据主动地位，且很容易达到一个天花板，而真实的有效方案应该是伴随着业务环境变化可以持续生长、动态变化的安全能力平台；

    在之前的文章当中曾描述过大部分的SOC和SIEM的平台仅仅只是将异构的安全告警数据进行数据接入、数据标准化处理后，通过一系列的存储分析后和一些流程工单、通报预警、OA系统、绩效评估、处置响应、SOAR系统进行了打通，成为了一些业务系统依赖的数据源；但后续的各项功能，**本质上都是依赖于告警/事件的准确性与数量**；也很好理解、如果这个告警/事件一开始就是误报、那么后续的所有旅程都是徒劳甚至有反面效果。如果每天的告警/事件的数量过多，一天有成千上万的告警远远超出现有的工作量那么本身也没有意义；

      所以、在日常的安全运营Job当中，最本质的需求**是发现那些真实有效的安全隐患与入侵行为并快速响应处置**，而不是从海量的安全告警当中筛选出真实有效的安全告警；而这二者之间，其实有着比较大的差异性；发现真实有效的安全隐患与入侵行为其实有是二个关键的动作：

1. 有效识别
2. 快速筛选
3. 调查处置

0x1如何才有效识别与筛选

    由于自己的一些职业经验是从渗透测试 -> 应急响应 -->反入侵的角色转换，尤其是在做应急响应的阶段接触了大量的病毒类、挂马类、定向攻击类的安全事件，很自然的会从这些事件的响应的行为当中去提取部分检测场景，并添加到安全产品的检测引擎当中去，尤其是一些绕过安全设备检测能力的攻击手法导致设备没有告警的，例如前几年热门的隧道通信、系统进程白利用行为、社交网络钓鱼、精心伪装的鱼叉邮件、隐蔽的内网横向、终端进程隐藏等，大多数的应急事件或多或少都会有一些新的技术收获。

    但是从日常繁忙的应急响应->入侵检测的循环里面跳脱出来的时候，就会思考另外一个安全问题。专业化的入侵者似乎总是能领先一步、安全产品总能悄无声息的绕过，入侵检测的能力只能被动的防守、最好的情况也难道只是快速步步跟随而已吗？从一定程度上来讲如没有没有一种破局的思路，一次次新类型的漏洞预警、变种木马工具检出能力的快速更新、从漏报到规则升级背后也是一种步步亦趋的迫于无奈；

     如果只是从技术的思路出发，这个问题似乎很难回答；常规的攻击手法产生的告警大多数都是误报或者是失败攻击的尝试；现在越来越多的攻击行为日趋隐蔽，也难以被简单的方法有效的识别出来；于是就有一个有趣的现象，**安全产品的告警分析后的结论就是没有问题，但是真实情况却是入侵者已经目的达成后安全离场**；传统的规则引擎、基于特性场景的聚类分析无法简单的平衡误报率与检出之间的关系；但是如果从业务的视角出发，则思路就会不一样，入侵者占上风的只是对攻击技术、手法的快速更新与研究，通过实际场景的应用快速快速迭代更新，打的只是一个时间差。而业务的视角，能够**占据优势的应该是对自己网络环境、与业务的熟系程度与理解**，大多数入侵者缺少业务方面的认知在真实的入侵环境下很容易就被发现；比如理论上，人力资源HRBP的个人PC是不会直接访问财务系统的server服务器22端口，客服人员的个人PC也不会短时间发起大量的异常DNS的请求；而这些业务的场景、是攻击者和安全厂商都不知道的，是安全建设者和入侵者之间的业务对抗，而不是安全厂商与入侵者的技术对抗；

    所以如何才有效识别真实有效告警是依赖于**安全人员、业务人员、数据分析人员**的多方参与、一个在越做越好的平台当中逐步走向100分的过程；从安全人员的角度来看，不同的安全能力以适应不同的层次的威胁，安全人员应该在安全经历用于分析哪些攻击成功概率大、危害性较大、检测难度更高的手工投毒、数据窃取、APT等人工参与成分较多的定向攻击层面，而不是每天应对大量程序自动化的扫描器尝试性攻击告警上；

     比较多的安全建设方已经通过将异构的安全产品，部署在网络、终端、云主机、容器等环境进行监测然后分开运营处置，少部分群体并借由一个大数据平台的数据对接能够实现统一化的运营平台，结合流程、服务的配套完成初步的跑通，基本足以应对/响应日常的漏洞、蠕虫木马、甚至少部分的人工参与攻击，但**在针对性较强、潜伏周期较长的定向攻击场景下依然需要自身的业务场景与网络情况量体裁衣，才能掌握主动权；**不能仅仅依靠一个或者多安全产品、就能高效准备的识别到这些隐蔽的定性攻击。

0x2 威胁分类做好调查处置

    即使内部具备了对入侵行为有一定的识别能力，但安全告警却无法做到100%的准确不同的安全/事件的误报率、检出率不尽相同，处置不能只有少数的几个简单操作；理论上来讲、攻击复杂度越低的攻击、攻击特征越明显检出率则越高、对应的误报率则越低，当然前提是特征工程的质量基本合格。

自动化攻击的事件比如常见的永恒之蓝的MS17-010漏洞、包括一些特定类型的激活工具、漏洞扫描工具特征、后门远控(ranmit)、挖矿特征(Miner)类、特定家族的威胁情报IOC等；因为准确性相对较高、故自动化的处置率相对较高，通过与SOAR的联动结合资产属性与业务熟悉基本上少部分可实现自动化处置，常见的操作包含：

1. 恶意文件隔离

2. 主机隔离(网络)

3. 封堵IP/IOC

4. 全盘病毒查杀

5. 进程终止(kill)

6. 删除文件

7. 清理持久项(服务、注册表、启动项、账号等)

8. 更改系统配置项目(密码策略、防火墙策略等)

9. 专杀工具/特定脚本等

    然而一旦涉及到重点资产、业务权重较大的服务器，或者人工参与较多的安全告警时候、则较难通过自动化处置需要人工分析、并结合业务后统一分析处置；一方面由于部分资产承载着较为重要的业务系统，自动化处置的行为无法轻易评估对业务的影响，另外一方面人工参与的安全告警准确性难以单一指标判断；
   
    资产的属性往往可以通过与CMDB、EDR等系统对接、结合资产台账和人工的梳理能够识别重要性，相对容易一些。而对应人工参与的安全告警与用户自定义的安全告警、则需要提供更多丰富的数据源供安全运营人员分析研判，常用的数据应该包含：
   

10. 告警的标准字段、时间、告警名称、分类、攻击字段、五元组等基本属性

11. 安全告警的举证信息、包括恶意字段、数据包、进程上下文、命令行CMDLine等内容；

12. 威胁情报信息、针对攻击IP、IOC、恶意文件的丰富举证字段(定性、sandbox)

13. 安全告警的发生的时间线、规律

14. 安全告警对应的资产属性、业务情况、脆弱性风险(业务误报)

15. 异构安全产品的检出情况(交叉验证)

16. 当前事件主机涉及到的影响面、访问关系与传播链(自动化溯源

0x3 业务驱动的威胁运营对抗

    安全建设应该是以保护业务的思路出发、但是很多安全产品在规划设计的时候其实并没有这些的思路，更多的都以威胁对抗的思路出发，最后在真实的实际环境当中验证后的确能够应对常规的自动化攻击、单在高级威胁领域要么没有对应能力，要么就是海量的误报让真实的告警淹没，与狼来了的剧本类似、日常误报太多最后就失去了信任。

    没有一个安全产品可以100%检出所有安全威胁，也没有一个安全产品或者方案可以在不同的用户群体下发挥100%的效果；安全能力更应该需要安全厂商与安全建设方的业务人员、共同努力后的量体裁衣才能真正提高组织的应对不同威胁的能力，把安全工作越做越好。