换种思路做入侵检测

本文是对CIS2022网络安全创新大会议题《数字银行可信纵深检测探索与实践》的一个补充，点击“阅读原文”获取历次演讲PPT，欢迎与我交流数据驱动安全的理论与实践。

可信理念

给定上图这种情况，问题是如何把黑样本都区分出来？

理想答案是通过一系列非线性线段完美分隔黑白样本，而机器学习正是可以画出这条线的技术手段之一，这也让我们认为机器学习是高效解决网络安全的新兴手段之一。

但现实情况并非如此，由于小概率安全事件特性，导致很难用机器学习精准画出这条线。我们能做的是另寻出路，尽可能逼近这条区分线。

首先想到的方法是，只需要做几次圈定的动作，直接把黑样本摘出来。同时，圈定动作所需的成本和黑样本的数量成正相关，而黑样本又很少，省时省力，是不是很完美？

理论上是的，但实际情况是有很多不可知的黑样本，很难在安全事件发生前，枚举出所有攻击手法。但只要有1次安全事件的发生，可能CTO和CSO就再就业了。因此，对黑样本遗漏的低容忍度，造成了摘出来这种方法是有严重缺陷的。

另一种方法也比较容易想到，就是方法比较笨，把白样本都踢出去，剩下的就全是黑样本了。这种方法优势和劣势都比较明显，优势是理论上可以解决黑样本遗漏的问题，劣势是白样本数量占绝大多数，剔除动作的成本也随之正相关，一旦剔除不完全，大量的白样本会被误认为是黑样本，告警量也会爆炸，令人心生恐惧。

心理上的恐惧会影响实际的动作，要不还是选择摘除黑样本方法吧，只要够快，也是可以把黑样本都摘干净的，同时安全事件也是非常小概率事件嘛。以前我是这么想的和做的，但有些勤并不能补拙，要补拙还得依靠有方法的勤。

战胜恐惧，理念的首先转变是前提，我把理念归纳到两个符号：“=”和“!=”，之前想的主要是“=”，等于xxx就是异常，现在的观念是“!=”，只要不是xxx就是异常，守株待兔，以劳待逸，只要把落在数据层面的业务正常行为理清楚，也就找到了可信行为，那剩下的都是异常行为。

可信行为

那什么是可信行为呢？如何快速找出可信行为？可信行为包括两方面，一是理论上可信行为，应用系统在架构设计之初计划会承载的业务行为，二是实际行为中的实际可信行为，应用系统实际触发的业务行为。理论上来说，理论可信行为和实际可信行为是应该完全重合的，但实际情况一定不是如此。

• 理论可信行为A，是指系统设计之初，计划承载但实际未使用到的业务行为

• 预期内行为A+B，是指系统设计之初，计划承载的业务行为

• 实际行为B+C，是指系统实际运行时触发的业务行为

• 预期外行为C，是指系统实际运行了非预期内的业务行为

• 实际可信行为B，是指系统实际运行的在预期内的业务行为

• 最大可信行为A+B+C，是指预期内行为和实际行为（假设不包含攻击行为）的并集

• 实际可信行为B=实际行为（B+C）左交集  预期内行为（A+B）

• 预期外行为C=实际行为（B+C）差集  实际可信行为（B）

• 计算出预期外行为C，具体分析后有两种操作：

1. 如是正常行为，加白后变成实际可信行为B

2. 如是不正常行为，联动事前防御拦截和事后风险治理

这两者的交叉区域是理论上可信行为且实际触发过，是符合业务架构设计和实际访问预期的。如果是理论上可信行为，但是实际未触发，原因可能是应用系统功能被过度设计，系统功能未被用户完全使用到；如果是实际行为，但不是理论可信行为，原因一可能是应用系统功能功能缺陷，用户实际使用了系统最初未计划承载的业务功能，本没有路，但走的路多了也便有了路，原因二可能是攻击行为。具体是正常行为还是攻击行为需要安全工程师的研判，这里也会涉及到研判成本的问题，之后我们会说到。

到这里我们可以看出可信行为的建模是一个持续性的过程，是以理论可信行为为基础，实际行为为依据，不断运营预期外行为，无限逼近预期内行为的过程。而逼近的程度取决于建模的精细化程度，综合考虑多方因素，建设步调是小步快跑，由粗到细，不一步到位。

可信案例

那具体如何找出理论可信和实际可信行为呢？关键在于对业务行为的理解（都被说烂了），这里举个具体的例子：XX系统非预期查询。

XX系统是面向一线研发人员开发的一款分布式架构、微服务、云原生软件系统下分布式链路追踪式定位问题、排查问题的智能化产品。其目的为辅助一线研发人员持续解决研发过程中出现的信息类故障问题，提升研发工作效率从而降低人力成本（抄自XX系统官方文档）。

一句话说，就是研发人员查日志解决系统bug的地方，相信大多数公司都有这么个系统。XX系统汇集了海量的日志，研发可以查，那攻击者也可以查，强大的搜索功能就在哪里，可能攻击者用的更6，这就是XX系统非预期查询的风险。

我们尝试采用之前说的可信行为的思路解决这个风险。首先理解业务行为，因为XX系统的定位是研发人员查系统日志，拆解成2个子问题，研发人员，具体是哪些人？查系统日志，具体查哪些系统的日志？对第一个问题，研发人员是广义范畴，主要包括应用系统的研发owner和测试owner，也包括一些安全人员、风险管理人员或者风控。看似回答了第一个问题，实际情况是否就如此呢？可以试着将这个可信策略上线，一定会产生大量的误报（因为我试过）。再分析分析误报的数据，发现一些不是系统研发和测试owner的人员也会访问，为什么呢？因为名义上的系统研发owner可能只有1个（一号位只有1个），但真正的系统研发人员可能是一些人，分析发现这些人和名义上研发owner的关系大多是同组或同部门的人。到这里我们就可以相对完整的回答第一个问题了，系统的预期内用户是研发测试owner及其同组研发测试人员。我们的人员范围暂时缩放到这里，因为目前没有更好的选择了。

对第二个问题，查哪些系统的日志。需要和第一个问题结合在一起看，owner当然能查自己own的系统的日志，除此之外呢，因为应用系统之间会产生大量的调用，owner经常会排查上下游的应用系统日志，解决本系统的bug。因此owner也需要查询自己own的系统的全链路上下游系统的日志。到这里，我们对XX系统查询日志功能的理解已经完成了，这里的理解也不是理论上的理解，是找了很多用户交流他们实际使用的诉求。

剩下的就是要收集数据资源，自动化产出日志查询功能的预期内行为数据了，只要不是预期内的查询行为，就是预期外的查询行为（这不是废话嘛），产出的这部分预期外行为对我们会非常有挑战，下面我们会说到。

先收集数据资源，首先收集人员数据、组织架构数据、应用系统和人员关系数据，然后是应用链路数据，比如系统A的上下游可能是B-》C-》D-》A-》B-》C，我们要获取应用间的调用关系数据。几部分数据关联起来，就知道了谁可以查哪些应用系统的日志。

再交叉比对下真实的访问行为，就可以过滤出预期外行为了，这时候安全运营人员介入研判了。研判是个大问题，因为这部分数据真的是完全预期外的，也就是我们之前对此一无所知，只有从头理解数据再研判，更可恶的是有些情况，只知道是非预期行为，无法确定到底是业务行为还是攻击行为。不像黑名单策略产出的行为数据，相对容易研判是否是误报，因为我们对此是有预期的。

可信效果及做到了什么程度

虽然白名单策略由于其粗细粒度的问题，也有被绕过的风险，但从实际效果来看检出了黑名单策略遗漏的入侵行为以及可能的绕过行为，因此是个不错的建设方向，剩下的就是不断增加更多维度特征，建设更细粒度的白名单策略，目前白名单策略已经批量覆盖了约50%的数据盗取类高危威胁场景，理想情况是要黑白名单策略比例为1:1，每一个黑名单策略都有对应的白名单策略。

可信的现实问题

实践虽然证明白名单方法相较于黑名单方法可以更好的缓解入侵检测遗漏的问题，也是目前已知最佳的方法。

但也要意识到建设白名单的短期困难被高估，长期运营成本被低估。

被高估的主要原因是心理上对未知的恐惧，初期一定会有海量的告警误报，但实际上短期内还是可以优化的。

被低估的主要原因是白名单的理论和实际复杂性都要远高于黑名单，无论是从策略的制定，到维护保养，还是重构。看个例子，同样是一个威胁场景的检测策略，如果是用黑名单做，条件表达式可能是一个以几个等于符号为基础，加上少量不等于符号去误报的样子：

($c1 || $c2 || $c3) && !$w1 && !($w2 && $w4)

但如果换成白名单思路做，条件表达式就是另一个充满不等于符号的样子：

!$c1 && !$c2 && !$c3 && !$c4 && !$c5 && !$c6 && !$c7 && !$c8 && !$c9 && !$b1 && !$b2 && !($b4 && ($b5 || $b6 || $b9)) && !($b7 && $b6) && !(($b8 || $a1 || $a2) && $b9) && !($a3 && $a4) && !($a5 && $a6) && !($a7 && $a8) && !($a2 && $a8) && !($a9 && $b6) && !($b8 && $a8) && !($a9 && $b6) && !($d1 && $d2) && !($a1 && $d3)

显然，黑名单很短，白名单很长，这是现象，但长期来看，这种现象极易造成策略可读性、可维护性、可解释性、稳定性的缺失。这也是现阶段实践遇到的最大问题，如何降低成本是接下来需要重点思考的问题。

结合纵深防御

一个单点的可信检测做好了，下一步是如何扩展到更多威胁场景，扩展到哪些更多场景，到底有多少个场景，这些场景之间关系和优先级是什么？以及我们的应对策略？这些都是必须要回答的问题。

我们定义起点和终点，威胁场景是起点到达终点过程中的安全问题，起点是攻击者，终点是数据，攻击者有很多类型，数据及存储也有很多类型，我们按照网格棋盘作人群和数据存储分割。

我们通过3+1层检测策略体系，尝试回答上面的问题。3层检测策略分别是从攻击者、数据存储实体、应用系统维度出发，1层加白策略。第一层策略，不同的攻击者群体有着不同的攻击偏好，我们通过对攻击者的画像，归纳总结出攻击者身份、意图和偏好的攻击手法信息，再做针对性的检测策略。这里面，一种攻击手法可能就对应一个单元格正方体，对应一个威胁场景。

攻击者攻击偏好定向监控策略：单元格正方体建设

第二层策略是数据存储视角的检测策略。以终为始，知道自己要保护的是什么，才会知道如何去保护。安全团队的目标是保护网商银行用户的数字化资产，而数据是其中重要组成部分。我们的工作围绕数据展开，以数据为终，以数据为始。

数据是数字世界对物理世界的表示，数据也会存储到物理世界，其存储形式多种多样，有SQL数据库、NoSQL数据库等等。我们理清网商环境中所有的数据存储类型及其详细信息，包括但不限于OSS、SFTP、OB、SLS、ODPS，逆向推导出访问这些数据存储的上一跳节点。

非预期访问数据存储检测策略：贯穿式长条形长方体建设

在上一跳节点直接访问数据存储实体的过程中，利用白名单的方法对不同数据存储实体做卡点检测，粗粒度的策略是，不区分数据存储实体里面具体的存储点，比如不区分OSS里面的具体bucket、OB里面具体的数据库，只要不是预期内的上一跳节点，就是异常；细粒度的策略是，区分具体的存储点位，制定可信访问策略。

第三层是应用系统视角的检测策略。要事第一，应用系统是访问数据存储实体上一跳节点的最关键类型，没有之一，面临着通用性和特异性两种威胁，需要全面覆盖检测策略。

非预期访问应用系统检测策略：屋顶式建设

通用性威胁指的是，不管应用系统有几千个或是几万个，是什么应用系统，都会遇到的未鉴权、已鉴权但凭据泄漏、已鉴权但可以绕过问题，针对这些问题，进行统一治理和检测。这里重点讲下特异性威胁，是指仅有某些系统存在、不是所有系统都会存在的问题（又是废话），而且不同业务的应用系统面临的可能是不同的威胁。

我们的做法是，首先根据业务类型，将办公网重点应用系统划分为基础资源服务应用（之前提到的XX系统就被归纳到这里）、业务小二后台、数据资源服务应用、运维管控系统、安全管控后台等几类。然后依据不同业务系统的不同威胁场景，分而治之，比如基础资源服务经常会出现滥用搜索功能泄露敏感信息风险，业务小二后台会出现违规查询业务信息等问题，数据资源服务可能会出现命令执行直接控制数据库风险，运维管控系统可以被滥用登录任意机器。

最后一层是误报加白策略，误报不可怕，加白不简单，相反我认为误报加白是一项非常有挑战的技术活。如果前三层检测策略大量基于白名单思路做建设，一定会产生大量的预期外行为，里面一定有大量的业务正常行为（但你事先不知道，所以至少是你的预期外，并不代表是其他人的预期外），因此对这部分行为的研判成本很高，也没啥好的解决方法（至少目前我还没想到），只有结合业务逻辑反复分析误报数据，不断完善对业务广度和深度的理解，简单的加白。

误报加白策略：镂空式建设

组织协同保障

把可信的思想融入到全局纵深后，就构成了入侵检测的检测策略体系雏形。而入侵检测策略体系在整体安全体系建设中所处的位置又是什么呢？之前写过的一篇文章《安全团队的演进及个人定位思考》曾思考过这个问题，首先第一道防御体系是默认安全，第二道是可信纵深防御，然后是依赖威胁路径大图的入侵检测和实战检验，数据安全建设贯穿始终。因此入侵检测的前后左右协同关系也就很明确了，从事前的各方吸收养料，完善策略体系，事中检出和响应威胁，联动事前和事后治理。我以前是这么理解的，感觉逻辑也没啥毛病。后来老板补充了很关键的一点：事中要给各方提要求，而不是提需求。实际情况可能确实如此，从个人感官上，以前提的更类似于需求而不是要求，虽然只有一字之差，但有很大差别。一看需求这个字眼，就知道有一定概率不被满足或是可以不被满足，而要求就不一样了，明确表明了态度，必须要解决问题，不解决问题不罢休。

在理解需求和要求存在巨大差异后，刚开始实际做之前很担心会冒犯到合作方，因为要求确实会比需求给人以更大的压力。后来感觉也没啥了，都是为了更好的收敛风险，成为更好的自己，动机是好的的前提下，方式方法可以持续调整和磨合，我相信长期主义，时间会给我们答案。

来的都来了，交个朋友～