前言

互联网日新月异的发展过程中，各种技术层叠交织。从最初处理速度极慢的庞然大物到如今便捷小巧的高性能桌面pc。计算机硬件的发展着实印证了摩尔定律。随之而来的是，NLP，CV，自动化等领域终于得到了算力的灌溉，相应的技术开始蓬勃发展。各种神经网络模型也应运而生，展现出了一片欣欣向荣之感。同样伴随着技术发展而来，计算机安全上的威胁亦层出不穷，不容小觑。
下面本文将从计算机物理无关的角度谈一谈其面临到的威胁及检测方式。

之所以写此文，一是为了回顾所学，二是并未读到有关此类的文章，希望此文可助后人梳理思路。起笔于12月8号，完成于12月16日。虽已修改7遍有余，但受限于个人行识，仍感难以驾驭综述类文章，因此难免有管窥蠡测之嫌。若有高见，烦请赐教。

计算机威胁检测

计算机威胁从来源看可被划分为来自内部和来自外部的，从攻击者角度又可以划分为人为的和非人为的。著名的威胁建模方法“STRIDE”便将其分为了六类。然而攻防是一种持续的对抗性行为，虽然可以看到当前的防御效果，但却无法通过一时的结果去衡量防御措施的有效性，以及时效性。攻击者总会想方设法的绕过防御者的防御措施，所以针对威胁防御的措施根本出发点在于减缓，而不是“杜绝”。之所以不能杜绝，是因为新生技术的迭代虽然解决了旧的缺陷问题。却总会带来更新的漏洞缺陷。即便问题不是发生在技术上面，也有可能因为业务逻辑的不清晰，从而可能产生一些逻辑漏洞。例如业务逻辑中密码找回的逻辑漏洞。

不同来源的针对性威胁攻击直接或间接的造成了企业资产的损失。例如，仅从数据安全来说，攻击可能会导致数据被窃取，被篡改，或者被滥用等。而在整个防御过程中，需要防御方不停的完善自身系统的安全性。否则导致的问题不仅可能会影响到当前的系统，还会间接影响到其他依赖系统。这一部分会在后文中架构设计中谈到，尽量通过减少系统间的耦合来提升其稳定性。降低威胁产生的扩散范围。

随着各种概念的提出，多年来也出现了许多形形色色的安全产品。最常见的有防火墙，入侵检测系统等等。而单单入侵检测系统就又分为主机入侵检测系统和网络入侵检测系统等。防火墙也分为软件防火墙，硬件防火墙，芯片防火墙等等。例如针对WAF而言，其具备了SQLi检测，XSS检测，webshell检测等功能。这些常规的威胁检测功能从应用层开始防御入侵者的攻击以及尝试性攻击。而逃逸出web应用防火墙的检测之后(大量请求分布落在WAF节点上，WAF处理不及导致直接被穿过)，还有NIDS系统进行进一步的检测。NIDS的分析器可以对网络流量进行分类，通过模式匹配发现不同类型的网络攻击，通常有URL混淆，域名生成算法(DGA)等等。而到了文件的落地，则会经过HIDS以及AntiVirus软件的检测，AV软件可以针对病毒，恶意软件，间谍软件，勒索软件，特洛伊木马，计算机病毒，蠕虫等等进行检测。虽然经过了以上重重的防御措施，看起来似乎是能够进行较为稳健的防御。但是事实并非如此，在现实案例中仍然有许多的攻击被送达到受害者的服务器上。这是由于什么产生的呢？防御产品本身的设计还是实现上的缺陷？毕竟安全产品本身也是一个产品，同样会存在缺陷。

近年来，API网关也承担了部分的防御功能。在其原始的API网关本身的功能之外，以插件的形式补充了WAF的功能。这些检测手段的背后是否存在着相似的地方？显然是的。下文以通用视角的思考方式阐述下威胁检测的方法论。至于特殊检测，例如APT攻击检测，也可以应用这种威胁检测的方式。

方法论

攻击者为了达成某种目的采取了不同的攻击措施，而防御方需要发现其中的共同之处。面对其繁杂的攻击手段，检测的根本思想是通过追踪足够多的纪录去发现唯一实体采取的攻击行为。本篇中的方法论就是针对如何追踪足够多的纪录，如何确定唯一实体，如何发现攻击行为两、三个方面进行阐述。

日志收集

纵深防御中有一个要点就是收集日志。通过分析日志进行防御。而针对日志的收集中的要点，无非是覆盖全面，纪录详细。通过对日志进行分类分级(error, info等)，并覆盖网络层，应用层，系统层等不同层面(深度)，以及不同的业务系统(广度)。同时也要考虑存储以及检索。目前成熟的开源方案可以采用ELK栈，当然也有成熟的商用解决方案，类似Splunk等。

唯一标识

分析攻击实体的过程唯一标识的确认是至关重要的，只有确认了唯一实体，才能分辨出攻击者产生的行为，以及评估该攻击者在系统中产生的危害范围。标识唯一实体可以通过对其属性进行关联，例如浏览器指纹(跨浏览器指纹)，设备指纹, ip, 无线路由ID,地理位置(经纬度)等等。此处指的是针对数据进行关联分析得到单个的唯一实体，而非前期过程中为了获取某个具体唯一属性时的技术实现。在处理的过程中还会面临到对大量数据的处理，单机已经无法满足计算需求，需要通过分布式集群才能处理海量数据。

威胁检测

对全链路上的大量的实体进行关联和去重后，得到了实体对应的具体行为以及具体属性。而威胁检测则是需要针对其行为和属性进行分析，来判断该实体行为是否为威胁攻击以及该实体属性是否已经处于威胁列表之中。威胁检测的方法一般有三种，黑白名单，模式匹配，计算模型三种方式。黑白名单和模式匹配较为容易理解。名单库一般通过聚合不同的威胁列表源进行维护，而模式匹配一般是输出IOC进行匹配或者正则匹配，由规则引擎执行即可。知名的模式匹配引擎Yara还提供了数值计算模块(属于具有逻辑的模式匹配)和沙箱模块，并且可以通过自定义模块去实现一些功能扫描内存中的数据块。

计算模型的方式目前较为流行的是采用机器学习的方式进行分类和聚类的操作。通常是异常检测系统的算法，同样可以通过对有标签的数据进行训练得到分类模型或者对无标签数据直接进行聚类生成新的类别。计算模型的方式是近几年开始兴起的方式，当主流向AI靠拢的同时，我们既不应该轻易否定，也不能过于盲目自信。其中细节还有许多需要踩坑的地方。webshell检测和xss检测可以通过文本分类的方式，恶意软件检测可以通过其api调用序列和线程数来分类，也可以通过将其映射为基因图谱并利用图片分类的方式进行分类。方法不一而足，仍然需要很多尝试。但作为学科间的知识迁移，具有较大的应用意义。

针对通用的威胁检测常常可以通过以上几种方式进行检测，但APT(高级持续性入侵)检测似乎并无有效的防范。传闻较多的即是APT攻击无法检测，能检测的到就不是APT检测。似乎是一个悖论，这并不意味着不能被检测，在充分利用各种现有资源的情况下。依旧可以发现APT入侵威胁，只是难易程度而已。此时的威胁检测中，黑白名单中的很多属性都会失效，模式匹配也无法防御0day，在各种设备都被打穿的情况下，计算模型能否发现APT组织，尚未可知。但在检测过程中，发现新的可关联属性将会大幅提升检测效果，并且使结果更加可信有效。例如之前Mandiant在2004年提出的imphash，通过计算PE文件的导入表哈希值，发现相似的病毒。

通过综合不同的检测手段去发现威胁攻击时，同时无法避免的一点就是加解密，调试与反调试。这种攻防怎么在持续对抗中更迭并改善当前的检测效果(虽然获得IOC并不难，但同时也要获得解密后实体的IOC)。是不能脱离场景和策略这两个关键因素的。下文通过对场景和策略的简要描述来介绍威胁检测的现有局限。

场景与策略

实体在场景中的时间序列动作构成了某种策略，攻防双方皆是如此。脱离了具体场景的防御策略并不具有什么意义。思考下面的问题，考虑下针对特定场景的策略问题:

面对爬虫，怎么发现爬虫，发现爬虫在爬什么，带来了什么影响。是监管机构？竞对？搜索引擎等等。防御方应该有什么样的策略，从哪些层面去应对？
面对入侵者，入侵发生在哪一层，通过哪种方法检测到的？攻击者正在进行什么操作，防御方是踢出并对机器镜像取证溯源，还是引流攻击者到蜜罐进行后续观察？当尚未观测到攻击但又被攻击了怎么办？
面对网络流量，四层七层的流量得到的数据在什么时候开始检测，性能与效果的取舍怎么最优化？

一个应用完成与用户的交互，可以简要的将其划分为两个部分。一是用户端(B端或C端或者移动端，无所谓)，一是服务端。而完成服务的过程一是用户向服务层发出交互请求，而后是该请求在服务端的一系列处理，最后返回给用户结果。这便是提供服务的过程。而一个请求进来之后的所有行为(鉴权，判危，请求服务，请求数据等等)一般来讲对用户来说是不可见，不可控的。作为用户本身也不会关心进行了哪些操作，只关心服务是否有正常提供服务，服务是否正常。作为防御者进行防御的同时，仍需要考虑的是用户的最终体验。精准打击到恶意攻击者是一件好事，当对正常用户产生了误伤之时，又该怎么样处理。明确了场景，根据场景制定相应的策略才有意义。

同时如何确保用户的环境在一个可信环境(或一个较为可信的情景之中)，当检测到DNS劫持时如果通过技术手段去确保用户加载正确的资源等等。明确场景中的一系列响应，将其构成策略并进行反击。但场景的明确程度往往受限于受限于“左右互搏”的能力(个人或者团队的经验)。对于经验不足考虑不周的成员，往往是一叶障目不见泰山。

架构设计与产品实现

软件架构的目的是为了在工作中更好地对这些组件进行研发，部署，运行以及维护。同时SDL作为软件开发的安全保障自始至终贯穿整个软件生命周期。而安全架构作为SDL中的一环(或者说某一部分，作为设计的一环，并没有详细的列出在SDL过程的步骤中)，在软件开发初期时就需要从架构设计的角度介入其中。因此如果在安全架构的初期就考虑到运行时保护(侵入式，研发阶段)，则需要通过修改代码的方式为应用本身嵌入或者接入相应的SDK。这样就会增加软件架构的依赖，提高了变更成本。那么需要怎么样平衡软件架构和安全架构，使业务运营和风控安全间的依赖最小。如果以非侵入式的方式进行保护，那么只需要通过对网络层主机层，以运维的方式接入，对原有软件架构不会产生较大的影响。

传统架构解决起来可以按照上面的方式进行设计，但是针对基于云的安全架构又是另一种情况，云安全的构建主要可以通过购买云厂商提供的安全服务或者集成的第三方安全服务去实现安全防护，取之于物，用之于物。至于微服务架构同样也是取决于具体软件架构的部署方式。基于容器部署的微服务架构，可以通过对全链路进行监控，通过分析指标和日志(目前也有完整的云上解决方案)发现威胁。微服务架构重点在微，当其微的时候。由于其粒度小，职责单一。因此重构简单，易于开发，部署。同时由于其边界清晰以及接口稳定可以很清楚的发现安全问题，并进行防护。但是当其数量成千上万时。仅仅是部署就令人望而生畏，配置服务间的连接也会导致许多问题。当部署成本越高，其可用性就越低。

但是软件工程随着项目变得越来越庞大，产研人员之间的协调变得困难，沟通效率下降。迭代的过程导致也会使得代码难以维护。这时就不仅需要考虑架构设计，还需要权衡软件开发效率。通过适当的削减架构设计上的功能点(包含安全架构)向软件架构妥协，使其能够在预期时间内能完成。

业务与运营

具体的业务需求产生了特定场景，而业务运营者即策略产生者(也可能不是)。针对相应的业务和相应的场景进行威胁检测以及防御。威胁检测过程中方法论中的理论对应的实现并不难理解，但是如果想要达到较好的效果。则需要精细化运营。精细化运营是目前威胁检测过程中任务繁琐的一部分。通过分离产品职能，降低运营成本和运营难度。目前安全产品的一个短板所在是往往一个产品，背后需要大量的技术人员运营。从而增加了产品成本，以及重复性劳动输出(不同公司间的竞争，同一公司内不同团队为了竞争)。通过自动化的精细运营，可以解放生产力。精细化运营的最终目标是自动化运营。前期通过半自动化运营，从而使运营人员有精力着手于精细化。而后期则进行全自动精细化运营，从而达到提高检测效率，以及缩短其反应时间。

总结展望

威胁检测目前已经具有较为成熟的体系。文中所述也是仅仅包含了软件层次，系统层次的检测，而非真正概念意义上全方位的威胁检测(包含物理层次，人员层次划分等等)。从应用层到网络层，以及主机层。各有形形色色的产品承担着不同的角色，但是纵观检测方式，在产品的输出上依然有所欠缺。此外，公有云上入侵检测能力如何进行平台化，服务化以及可视化依旧是可以发展的方向。如可视化上来说，检测到某个入侵者，以可视化的形式展示出该入侵者所处资产模型的位置。预测其下一步动作，模拟其可能的攻击流程，并根据预测结果产生针对性的防御措施。依旧是一片空白领域。最后针对计算模型正确的看法应当是不盲目的认为机器学习可以解决现在的一切问题。同时在将机器学习模型应用上去的时候知其然知其所以然。