安全运营场景下的机器学习算法应用

观测到一个有意思的现象：

假设把安全划分为 基础安全 和 业务安全，PR类的议题中，会出现分级：基础安全领域，喜欢讲纵深防御，给出一个炫酷的架构图，然后各种技术关键字往上标；业务安全领域，喜欢讲算法，给出各类数据源，然后把各种算法模型往上标。

这里面当然有很多原因，比如：搞基础安全的人通常是攻防出身，不擅长算法；业务安全的技术层面不深，所以出彩需要靠算法；等等等。

但本次的主题，尝试从安全和算法的角度来展开，为什么基础安全和算法的结合，是一件相对困难的事情。以及个人最近在尝试研究的一些解决方向和思路。

1. 安全运营场景下的算法难题

基础安全是个重运营的工作，不论技术多么炫酷，最终想要拿到结果，都必须落到运营头上。

不论部署了多少安全产品，收集了多少数据，维护了多么精密的规则，最终产出的告警仍然是以误报为主。本质原因在于，基础安全是和人在对抗，在行为特征上，存在极大的变数。正常员工可能某天心血来潮，就登录上一台新的机器，执行某个危险命令。（与之相对的，业务安全通常是和机器在对抗，各种脚本、模拟器环境。虽然代码是人写的，但业务见到的批量请求，还是机器发出的。）这个时候，就需要安全专家对告警事件的上下文进行收集和研判，依靠过往经验判断是否为一起真实入侵。

这个运营过程，可以被算法替代嘛？当然是可以的。但会带来另一个更哲学的问题，算法出现了误判，到底是谁的责任。这个问题代入到医学或自动驾驶领域会更好理解。假设“医院”引入了某“公司”开发的算法，对“医生”的病人执行了错误的治疗方案，导致病人死亡（哪怕本来就没有多大的几率救活），这个时候，应当谁去承担责任呢？

1. 从医院的视角，算法的引入经过了严格测试，准确率达到99.999999%，超过了医生的判断水平，算法代替医生能够在全局样本下取得更好的治疗结果，应用算法看起来是个合理决策。
2. 从公司的视角，已经把算法的准确率优化到99.999999%了，你总不能要求算法的准确率达到100%，所以算法工程师已经尽职尽责了。
3. 从医生的视角，算法决策的过程，医生全程没有参与，自然轮不到医生去背什么锅。

病人死亡这个结果，一定是需要有人来承担责任的。但从各方视角来看，似乎谁都没错，那就只能怪病人自己倒霉了呗。

补充说明一下，这里的承担责任，未必是要惩罚，重点在于归因。

在我看来，这个责任关系的定义，是目前算法在医学、自动驾驶、安全等领域下，无法起到革命性作用的最根本原因。区别于常规领域（推荐、搜索、翻译等），少量的错误是可以被接受的，因此算法追求准召率的最大化即可。但在特殊领域，个例的频次较低，后果却极其严重。这个时候，概率是没有意义的，真正需要的是明确的责任归属。

那为什么规则在特殊领域是可以被大规模使用的呢？这就是规则和算法的最大区别，算法是黑盒的。对于规则来说，其实同样不存在准召的概念，只要输入明确，输出