【转载】为什么机器学习解决网络安全问题总是失败
本文由toooold原创发布
谈谈特征空间
本文的所有内容与作者的日常工作无关，其观点也仅代表作者个人意见，与作者的雇主无关。
近年来网络安全从业者纷纷神往机器学习的魔力，加之深度学习在图像、NLP等领域的成功，大家都想在此寻求一发银弹。不过作者在安全业界没有看到太多如虎添翼的机器学习案例，更多的是对生产环境里金玉其外的模型效果的失望，“模型误报太多了，运营没法处理”，“就这两个独检结果还不如我写两条规则”，“PPT上说深度学习、自我演化，实际都是 if-else”等等。为什么机器学习解决网络安全问题总是失败呢？
机器学习模型在解决网络安全问题时效果不好的原因大致可以归结为这几类：
- 错误的特征定义和样本标记
- 算法的脆弱，工程的脆弱，运营的脆弱
- 错误的评价标准以及错误的优化方向
- 误解机器学习就是人工智能算法的全部
我们先从特征空间和样本标记谈起。
什么是合理的特征空间
图像识别问题的特征就是一张张图里的像素，NLP特征就是文本里的文字，那么网络安全类的特征就是每一条 WAF 攻击记录的字符，每一个恶意软件二进制文件的字节码，这样对吗？
合理的描述问题本质的特征空间可以让模型轻松解决问题，而错误的选择了特征空间会让问题难度成倍上升。不妨看这个例子：如果问大家，心算
5765760 加上 2441880
等于多少，任何一个学过基本算数的人都会毫不费力的答出
8207640。但如果是心算 5765760 乘以 2441880
呢？这几乎可以难倒一片小伙伴。这是因为十进制不是乘法友好的表示方法，因为我们选错了特征空间，所以问题就人为的变难了。对乘法更友好的表示方法是因式分解，如果把题目换成“11*12*13*14*15*16
乘以
17*18*19*20*21“这个等价问题的话，它的答案甚至比之前的加法还简单。
一个异曲同工的例子是 malconv
深度学习检测恶意软件，类似的基于字节码的卷积方法并不能学到正确的特征空间。Raff
et al 等作者的 “Malware Detection by Eating a Whole EXE”
使用二进制文件本身作为输入，试图利用卷积网络从 010101
这样的原始字节码特征空间构建一个端到端的恶意软件静态检测分类模型
malconv，它在自己论文的测试集上可以达到 90% 以上的
AUC。然而，抛开其对新样本和对抗样本检测时极不稳定的表现，“DeepMalNet:
Evaluating shallow and deep networks for static PE malware detection”
这篇文章引入新的测试集对比了 malconv
等多个深度模型以及论文作者自建的随机森林模型后发现，通过手工构建特征工程的随机森林模型也几乎可以达到并超过
malconv
的效果。究其原因，卷积网络在原始字节码上并不会学习到合适的特征空间，论文中展示的有效性更多是碰巧的结果。Fireeye
的研究人员 Coull et al 的文章 “Activation Analysis of a Byte-Based Deep
Neural Network for Malware
Classification”表明了malconv的卷积结果其实是把静态二进制文件的文件头信息当作当作主导特征，而由指令跳转组合对模型预测分类的权重极小，其后续改进
EMBER malconv 也延续了类似特性，具体的分析和解释可以参见
Bose et al “Explaining AI for Malware Detection: Analysis of Mechanisms
of
MalConv”。如果加以使用一定的领域知识工具，比如获取函数导出表、利用一些动态特征比如沙箱采集的函数调用序列，或者使用静态反编译得到指令集序列，将原始二进制转换到这些更能表征软件运行时行为的特征空间当作输入数据集，其机器学习模型的表现比
malconv
类仅用字节码卷积方法的稳定的多，分类效果也更好，请有兴趣的小伙伴阅读相关参考文献并继续调研。
同样的道理，我们也不能期望有一个精准的端到端的模型在不需要切分和筛选 token 的情况下，仅基于原始的 WAF 记录即可预测攻击，也不能期望一个模型学习到 DGA 的字符组合方式并精确分类甚至生成新的 DGA 域名，更不能幻想有一个深度学习模型读入任意 HTTPS 数据流即可精确预测其对应的网站。市面上的机器学习模型在解决这些问题上的失败均证明了选择合适特征空间的重要性：模型在错误的特征空间上可能因为碰巧适应特定数据集而产生所谓“好结果”，但这些结果不够稳定也远不足以支撑生产环境和产品的质量。
为什么模型效果和特征空间相关
大家经常提到的“机器学习”指的是基于样本的统计学习，它学习的结果是样本在其特征空间分布的统计期望。我们可以借用一句古诗“横看成岭侧成峰”来理解特征空间对模型判别的影响。如果特征空间并不能描述造成样本分布的本质原因，其特征的数值分布就不能提供足够的判别能力，直观地说，模型只能“横看”到一连串的“岭”而不能“侧看”独立的“峰”，那么模型顶多在“岭”上大概划分个差不多的样子以适应现有数据集，于是，它“不识庐山真面目”的丢失了“峰”所代表的实质特征。
特征空间与样本标记方法也有关联。基于样本的统计学习有一条实战经验，再好的模型也只能尽可能学会人工的标记。网络安全从业者常常认为，“模型只能学会我规则标记的样本，要这破模型有何用呢？” 据本文作者观察，很多模型的工作均掉入“标记样本仅为标记原始样本”这一误区，而有经验的数据科学家会标记与表征空间对应的样本，它可以是原始样本在新空间的映射，比如各种关联图模型里学习到的向量表示，也可以是原始样本的拆分，比如基于汇编码区块的恶意文件检测等，这些合理的样本选择和标记跳出了原始样本的局限，并使用更简单可靠的模型解决问题。
如何寻找正确的特征空间
有些特征显而易见，有些特征需要绞尽脑汁。“岭”和“峰”的区别不仅限于同一个数据集里的特征选择或者特征超平面的转换，更重要的抛开“显而易见”“想当然”的特征，寻求能够描述样本分布本质原因的特征。一个典型的例子是前一篇博客“为什么 LSTM 检测 DGA 是无用功”里提到的一类 LSTM 检测 DGA 的算法，它们的特征空间为每个域名的相邻字符串组合，LSTM 模型事倍功半的去拟合可以产生这些相邻字符组合模式的未知函数，这远远超过了 LSTM 这个浅模型的学习能力。事实上，现在还没有一个足够聪明的网络结构可以在小数据集上学习到包含异或、移位等复杂操作的函数。多数 DGA 的本质特征为由 DGA 算法产生域名序列，按照多个域名的序列映射到嵌入空间或利用其共同出现的概率可以更好的对其行为建模，利用简单的图嵌入模型或者邻接矩阵计算即可达到很好的 DGA 检测效果。
寻找正确的特征空间并没有一劳永逸的办法，暂时也没有更高的人工智能的辅助或自动化，它需要的是数据科学家对现有模型的分类原理有深入的理解，也从数据模型的角度对安全领域的基础知识有根本的认识。因为本文作者看到过太多建立在错误的假设和特征空间的工作，所以建议数据科学家在头脑中保留这个问题并在解决问题过程中反复提醒自己：
”这个特征空间可不可以表征问题的实质？“
总结
网络安全方向的数据算法模型不像机器视觉类问题有清晰直接的样本定义。它更像语音和空间控制类的问题：它要求该领域的数据科学家对领域知识有更深入的了解，探寻可以表征问题实质的特征空间，并聪明的将问题从其表面映射到实质的特征空间。加以合适的样本标记方法描述这些特征的分布，而非迷信深度学习带来天降神力，我们可以找到更合适办法去解决问题。
本文分析的是网络安全方向的建模在算法方向上失败的主要原因，我们还有若干话题，比如从系统上理解和处理模型的脆弱性等等，这些在以后的文章里都会谈到。不只是网络安全从业者，很多领域的研究人员和工程师也过分专注于模型本身，而忽略了建模是个系统工程问题，寻找更多更好的样本、更能描述本质的特征、对预测错误的处理等都是这个系统里重要的步骤。本文作者希望由此提起大家对系统和工程的关注，让机器学习和其他人工智能算法在网络安全领域发挥真正的作用。
脆弱的系统工程
用机器学习等算法解决网络安全问题常遇到数据模型与规则模型的效果之争，覆盖率与误报率的平衡，模型独检结果和防火墙整合的遥遥无期，这些都是数据科学家在设计算法时的纠结。然而一位资深安全研究员大哥喝高了一曲《有多少爱可以重来》扶着我吐露了他的内心：
“算法才分对错，攻防只讲成本”
数据模型的自我纠结以及与安全运营的矛盾都来自于脆弱的模型预测结果，或者说，很多数据模型只是给安全运营团队或者安全产品使用者抛出了一个半成品，导致了“你这个模型没法用”，“我为什么信你的结果”等等负面反馈。应用机器学习等算法解决网络安全问题并不仅是算法本身的工作，它是一个系统工程，其脆弱性来自于系统的每一步。接着上篇特征空间和样本标记的讨论，我们简单谈谈系统工程框架下如何理解算法的脆弱，工程的脆弱，以及运营的脆弱，并有效的避免其对解决方案的负面影响。这里的讨论也不仅限于网络安全行业，多数内容也适用于其他使用算法模型的工业界场景。
算法的脆弱
除了准确度召回率等衡量预测质量的指标，为解决网络安全领域问题设计的算法对预测结果的茁壮性也有若干特别的要求，最重要的是识别错误结果并且提供妥善的处置方法，就像基于机器视觉的自动驾驶一样，需要保证即使模型误判也不会撞墙。然而业界对这个主要原因的讨论甚至少于非平衡数据和小数据集标记等引起算法脆弱的其他原因。
错误的预测结果客观存在，作为算法提供方的数据科学家不能忽视，也不能惧怕它的存在。一个看似完美的 AUC 是多数论文的结论，而它只是所有工业界工作的开始。在机器学习论文里常见0.1% 误报率可能会被工业界以亿为基本计量单位的海量数据放大成几十万条运营数据，每一条预测结果数据都与运营的时间人力资源相关。因为运营或者产品团队关于误报带来成本的反馈，数据科学家作为算法的提供方惧怕误报，并限制了算法构建时的思路，比如说，为了极少的精度提高而在判别模型的召回率上的较大妥协，手工添加大量名单规则对结果过滤，甚至因为模型精确度没有上90%即放弃等等。忽视或者惧怕错误的预测结果是算法脆弱性的最主要原因。
与其忽视或惧怕，不如正视其成因并开始思考如何妥善处理。从算法角度来看误报，其最大原因是源自对事件观测的信息不全，这是网络安全在防守方的客观劣势。攻击方可以在多个角度设计并投入攻击资源，而防守方只能以自己观测到的部分建模，即使在防守方的资产上布满了完备的检测点，我们也很难完全透析攻击方的所有动作，更何况完备的检测点本身也是挂一漏万。正如鲁迅真的说过这样，“于是所见的人或事，就如同盲人摸象，摸着了脚，即以为象的样子像柱子。”*
在信息不全的情况下建模带来的不确定性要求从系统工程角度容忍不确定性并识别处理错误结果。
当然算法的脆弱来自于多个方面，我们也不能忽视数据集的选择偏差带来的算法偏向性，比如某犯罪预测模型默认地域和肤色与犯罪率的极高相关性，也不能削弱样本采集和标记的统计误差的影响，比如某保险风控模型认为100岁以上老人结婚率很低，更不能期望“未知的未知”威胁*可以通过已知的建模轻松解决，比如业界某些产品声称自己的
AI 模型可以检测并处理所有 APT
攻击。我们先从当前市场上最主要的脆弱性着手，一步一步前进。
工程的脆弱
业界绝大多数的论文不会涉及算法的工程实现，而工程实现上保证模型结果的可用性是脆弱的另一个主要来源，它包括上下游数据的可用性，算力的支持，监测和恢复系统等，同时数据可访问难度也是一个重要因素。
网络安全行业的多数算法模型根据自身或者客户平台采集的日志等数据源建模，这些日志由专门的团队负责采集，保存为互不相同的文件格式，有着不同的实时性和可靠性，并利用不同的数据平台输出，加之各种情报和第三方五花八门的格式，以及数据里各种字段的定义和冲突，这些学术论文里不会提到的数据采集的工作是数据科学家建模之前必须要面对的几件棘手工作之一。
即使能够顺利采集并整理出可用的数据集，稳定并及时的计算结果也是工程脆弱性的另一个因素。比如作者在实现前文提到的
domain2vec
这个将序列共现概率转化为几何向量空间的模型时，每小时约10亿条 DNS
记录要求的算力为其工程化带来不小的挑战。因为每个时间段的 DNS
数据流量可能有完全不同的模式，我们必须在该时间段内完成数据的采集和模型的计算，以避免结果的延迟和计算平台的阻塞。
数据质量和模型完成的监控与恢复也常被忽视，其负面影响直到出现重要事故或者入侵事件时才发现，模型本来可以检测并阻止这些事件的发生，但是因为上游数据的丢失或延迟、共用计算平台的排队过长、模型的白名单版本错误、模型代码 OOM 等原因，导致了最终结果的无效。有些安全团队和公司并不认为这些监控和恢复是核心工作，往往不投入足够的资源和优先级，而这恰好是“千里之堤溃于蚁穴”的典型案例。
在理想条件下，数据科学团队可以不受限制访问所需的数据，而在监管环境的要求以及公司利益的博弈下，数据的持有者和可以构建数据模型的团队并不能完美融合，这样的数据壁垒也是导致工程脆弱性的一个重要因素。
运营的脆弱
多数安全运营团队缺少处理模型预测结果的相关机制，它无形中推高了每个案例的运营成本，这是运营脆弱的主要原因，而网络安全对领域知识的门槛也使得数据科学团队难以助力。它主要有两方面因素，算法模型是否支持运营所需的信息，以及运营是否理解模型预测的结果。
数据科学家往往觉得模型的任务仅限于提供预测结果，如果正确就万事大吉，错误的话，大不了损失点召回率换精度也可以。可是正确的结果也需要运营，就好比模型检测出某个视频内含有暴恐内容，而运营团队需要一帧一帧查找这一个多小时的视频，又好比模型检测出新的 APT C&C，却让运营团队挨个排查几十台主机几百个进程和文件。正如坊间传言在亚马逊负责包裹分发算法的团队要跟着快递卡车送了一个月快递，对运营团队的工作置身事外的数据科学团队也做不出有效的数据模型。
运营团队的相关机制、工具框架以及培训也没有跟上数据科学时代的步伐。多数运营团队并不分级而是全力投入所有人力处理检测结果，这就导致了不管案例复杂程度都随机分配给团队中经验等级不同的安全研究员。同时，事件调查和进一步行动所需的上下文信息也分布在数据系统的各个角落，需要使用多种工具按需查询。安全研究员理解并使用算法的预测结果也有一定阻碍，包括对结果的归因分析，如何在例如防火墙等产品中应用预测结果，以及合理处置因预测的不确定性带来的影响等。这些阻碍带来的运营焦虑感进一步阻碍了安全研究员使用数据模型的结果，数据科学和安全运营团队的对话常常终结于“你就明确告诉我能不能阻断吧”。
在以上两个因素之上的，还有安全运营团队与数据科学团队因为领域知识构成的不同造成的沟通交流障碍也导致“反馈迭代”这个常规方法不能顺利执行，安全运营团队更看重对事件的作为个体的特点，同时也专注于特定事件的具体描述，而数据科学团队却因为背景知识的缺乏而难以从这些具体描述中剥离并抽象出模型上的共性，交流的双方总觉得鸡同鸭讲，讨论也没有什么结果。这些大大小小因素的堆积导致了运营的脆弱。
关于如何坚强起来的一些建议
从系统工程角度看，消除脆弱性及其影响差不多需要这些工作：
- 识别错误的结果，并提供对正确和错误结果的解释。
- 建立现代化成熟的数据仓库和相关工程框架，保证模型的可用性
- 为模型预测结果的运营建立相关机制，提供工具和培训
这里的每一步都和其他工作相辅相成，实际工作中也有很多案例展示了改善算法修正工程难点，重新设计安全架构降低算法难度等方法。请各位小伙伴从系统工程这一整体来理解以下的建议。
算法需要收集错误结果的渠道。常见的误区来自于错误结果完全依靠用户反馈，这除了惹恼用户之外几乎没有任何意义，反而会导致海量的告警信息阻塞了运营队列，使得使用安全产品的团队或者运营团队不得不依照经验丢弃大部分告警以保证运营带宽。这种情况下，安全团队不仅没有时间提供反馈，甚至会让模型提供方误以为自己的模型很完美，而事实上是用户已经懒得理你了。合适的反馈渠道可以有多个阶段：
- 基于模型特征的反馈：它一般是基于其他特征的规则或者机器模型。例如算法预测的鱼叉钓鱼页面是 google 首页，它可以通过与流量排序模型交叉验证并利用“高流量网站与鱼叉钓鱼的相关性很低”的事实排除。这类反馈利用多种其他特征有效补充了检测模型观测攻击模式时的视野局限，从理论基础上提供了反馈方式，并可标记绝大多数的错误。
- 基于关联知识的反馈：如果一个预测结果是正确的，它的关联结果也应该是正确的，直到将关联延伸若干步骤达到一个错误结果。例如算法预测了某个域名为恶意软件 C&C ，它可以通过在 DNS 查询记录对应的 IP 记录关联延伸到沙箱里访问该 IP 的二进制在 VirusTotal 或者其他检测引擎或者安全团队的二进制文件分析结果，直到完成了整个链路的延伸。这类反馈利用了特征空间之外的第三方知识作独立验证，成本略高于模型特征的反馈，是模型特征反馈方法的有效补充。
- 基于用户使用的反馈：经过前面几个阶段的努力，能够到达用户需要运营的结果已经很少。在算法提供的上下文信息的辅助下，用户可以结合自身的经验和更多的情报，对结果做出判断。这一步的用户反馈不仅是结果的正确与否，更重要的是用户根据哪些相关信息作出的判断。
算法也要尽可能的提供对预测结果的可解释性，不仅是错误结果，算法也需要解释正确的结果。其中包括解释算法本身所用的特征（常见于深度学习模型），标记并定位判断依据（比如恶意脚本代码段的具体哪一行），以及该预测结果的上下文信息（比如上文提到的关联知识，例如该二进制由某
URL 实行分发，该 URL
下的其他已知恶意行为等）。关于解释结果的重要性，这里有一个直观的例子：我们不难发现，在数据模型和规则模型的效果之争里，虽然数据模型在多数情况下有着漂亮的纸面指标，安全运营团队仍然倾向于规则模型。这是因为运营人员可以通过阅读规则本身理解模型依据，加上自身的安全经验，以及从模型提供的信息出发的进一步调研等后续工作，最终可以做出合理的判断。从这一思路出发，Sophos的AI团队开源了一套从机器学习模型的结果转译出相关
yara
规则的代码*，这是一份很有意思的工作，属于解释算法本身所用特征的方法，有兴趣的小伙伴可以自行阅读。值得指出的是，提高模型结果的解释性不只是转译成规则，同时规则模型也没有完美的提供解释性，我们依然没有银弹。
算法也需要提供对错误结果的快速处理方法以及部分的自动化，包括合适的分诊算法，添加足够的上下文信息以辅助运营等。可能是因为学术届和工业界对此的讨论有限，无论是在数据科学方向还是在安全研究方向，分诊算法（Triaging）常常被忽视。常见的场景是一个有效的异常检测模型因为其需要运营的预测事件数量较多而被放弃，这无论对数据科学团队还是安全运营团队都是一个巨大损失，而分诊算法可以有效的对预测结果按照运营优先级排序并合理的安排运营资源。一个例子是作者的同事在
2017 年 botconf 的演讲 Asiaee et al “Augmented Intelligence to Scale
Humans Fighting Botnets”*，在每小时亿级的 DNS
日志流量里使用异常检测模型输出所有未见过的域名，并利用
domain2vec
构建域名之间的访问关联，以强关联模式作为运营的重要性指标做分诊排序，将每小时约千万级的异常事件降低到十几个有效的聚类，并成功应用到检测
DGA
恶意软件上。分诊算法有多种指标和方法，包含聚类、排序等，是一个与安全领域知识相关的数据科学方向，在此就不赘述，有兴趣的话可以以后再谈。
工程的脆弱性对业界有更广泛的影响，我们可以沿用别的领域带来的一般的解决方法，建立数据质量保证系统（Data Quality Assurance）。关于 DQA 的相关建设，请小伙伴们自行阅读参考文献，对这一成熟方向在此依然不需赘述。
工程脆弱性的另一个原因是在网络安全行业更为突出的的数据壁垒问题。除了一些开放数据组织或者联盟之外，技术上必须提到含隐私保护的数据模型工程实现，简单来说就是模型不需要数据明文即可学习并预测。这类方法中的比较广泛使用的是联合学习（Federated
Learning），通过服务器-客户端的架构保证了模型和数据方的隐私，同时让模型得到需要的特征。这些联合学习的方法常见于一些
NDR 和 XDR
的初创企业产品中，暂时只在较为简单的一些场景上使用。在联合学习的实现上，FATE*通过一系列开源工作站稳了脚跟，有兴趣的小伙伴可以自行前往参考文献深入阅读。隐私保护计算利用了较高的计算成本在一定程度上缓解了数据壁垒问题，但根本上解决数据壁垒的工作还有很长一段路要走。
运营的脆弱需要数据科学团队和安全运营团地联手解决。在算法模型做到对结果的可解释性并且通过分诊算法将检测结果按重要性排序后，安全运营团队可以根据其提供的上下文快速的做出判断并决定后续的工作。同时，一些方便的数据工具可以帮助快速运营，比如方便好用的图数据库系统，这些可以由工程团队提供。与此同时作者观察到，对数据感兴趣的安全研究员可以是很好的老师，他们可以给数据科学家快速有效的教授相关背景知识，使数据科学团队更深入的理解安全问题并提出数据模型。这些跨越知识鸿沟的努力逐步解决运营的脆弱。
总结
网络安全专业对结果的脆弱性有较高的要求。有经验的网络安全专业研究人员可能也发现了，以上关于脆弱性的讨论也适用于例如使用第三方威胁情报等其他方面，解决脆弱性的一般方法在此也适用，比如使用云上或者运营商流量对威胁情报做进一步自动化验证等，限于篇幅在此就不赘述。同样，由安全研究员领域知识和经验出发的规则模型也面临着结果的脆弱性：巧妙的检测规则需要足够的解释性，大量的陈年老酒型白名单规则需要维护和更新以及对抗蓝军的试验和猜测，模型检出结果缺乏可用的分诊重要性排序等等，这些都是规则模型也需要面对的问题。作者在此抛砖引玉，希望有安全研究的专业人士对规则模型的脆弱性及其解决方法展开讨论。
对于数据科学家来说，从系统工程解决脆弱性甚至比提出有效的检测模型更为重要。在大家一直争论的规则模型和数据模型哪个更实用的同时，我们也看到很多不完美的规则或者数据模型在很好的工程实现和运营支持下得到不错的结果，规则模型和数据模型互相验证和分诊，而非互相竞争。这也提醒我们在构建数据模型的时候，要跳出思维局限的井底，从更宽广的系统工程视角解决问题。
同样，由网络安全专业的需求出发，我们从系统工程角度也对模型的脆弱性进行了讨论，这些讨论和其一般性解决方法也可以适用于图像、视频、语音、风控、自动控制等其他依赖数据模型的行业。总的来说，工业界依赖的数据模型从来都是一个系统工程问题，我们必须从系统工程角度思考设计和解决。
不合理的评估指标
网络安全和风险控制行业一向被认为是消耗商业价值的成本中心，所谓“安全一上，怨声载道。风控一拦，市场白玩”。与此同时，安全从业者需要通过保证系统和业务的整体安全以保持可持续的长期商业价值，毕竟靠黑产薅羊毛刷起来的日活和营收总有一天会以更高的代价还回去。从网络安全对长期商业价值的意义这一角度出发，我们可以讨论一下机器学习解决网络安全问题的第三大失败原因，不合理的评估指标。简单来说，我们在设定数据模型的评估指标时，有时候忘记了长期商业价值这一根本出发点。
文中关于设计评估指标的讨论在学术界并不多见，其原因可能来自于学届的研究的问题脱胎于具体问题并且独立于商业产品的细节，同时也有相对通用的评估指标，而工业界的具体问题与其商业价值关联更加紧密，更需要数据科学家将这些通用的指标具体化并关联到商业价值。
为什么需要合理的评估指标
合理的评估指标为数据和安全模型在达成目标的道路上提供指导方向。对指标的提升可以直接映射到行业内的商业价值，从而驱动数据模型和安全模型有的放矢的提升，同时其带来的商业价值也保证对模型的持续投入，比如提升 1% 的恶意软件检测率可以避免感染成千上万台云主机，缩短 0.01 秒的 WAF 检测时间会提高客户主机网络吞吐量的阈值以更有效的抵御攻击风险等等。
网络安全行业需要在动态且强对抗环境下解决安全问题，由攻击方或者环境带来的不确定性也会带来设定评估指标的困扰。例如对入侵检测模型的评估，如果我的业务结构没有受到有效的攻击，这是因为我的检测模型做得好，还是因为对方没有能攻破前几层防线，或者干脆就懒得攻击我，甚至是其实被攻破了只是我不知道？这些对抗和动态环境使得数据科学团队在构建模型时常陷入两难境地，一方面想检测出更多的攻击，一方面想保证更好的防御，可是更好的防御意味着更少的攻击，那么如何如何评估防御指标？同样的困扰也存在于各个风险控制团队、漏洞巡视和检测团队等等。“善战者无赫赫之功”*，我们如何更好的构建和评估检测和防御体系呢？
在实际的工作中，作者发现设定合理的评估指标需要面临诸多挑战：那些不能正确反映长期商业价值的评估指标也往往错误的指引了数据和安全模型的研究方向，这些指标也常常挑起商业增长与安全防护的矛盾，更有甚者，部分从业人员迫于不合理的指标带来的压力而使用非常手段来利用指标的漏洞，使得模型和产品功能偏离其设定方向。
总的来说，合理的评估指标是连接优秀的建模工作和其商业价值的重要桥梁，它有效指引了模型工作的方向，而不合理的评估指标会让优秀的模型在错误的方向上努力，其不令人满意的结果也让建模工作承担不必要的责难。
错误之一：失去目标的指标
目标和指标的关系是数据科学基础知识之一，但这种“失去目标的指标”错误几乎占了不合理指标的绝大多数情况！
各位小伙伴在上课时有没有想过这个问题：既然判别模型为了追求准确，那机器学习模型为什么不用准确率代替目标损失函数进行优化呢？*
抛开其背后的统计和数学原因（包括假设、后验和先验等以及他们的实际意义），直观的理解可以是，损失函数定义目标的优化方向，而准确率等指标评估其优化完毕时结果的好坏。准确率只能被人用来评估机器预测（指标）是不能被机器拿来判断对错（目标），否则机器会失去损失函数降低带来的优化方向而陷入它误以为的最优解。这也对应了人工智能课程提到的决策的基本原则：智能体需要做明智的决策而不仅是结果正确的决策。
但是聪明的人类在决策过程中却因为利益等原因混淆了目标和指标。我们见过很多因为考试作弊没有被抓而洋洋得意的学生最终的失利，也见过为了单日活跃用户数发出大量红包，但没有足以留存用户的产品功能而最终流失用户的各大APP。一时的考试成绩和几天的日活数字只是指标，指标只能在“牢固知识”和“构建好产品”这些目标下才有意义。
网络安全团队和网络安全产品的目标是为了保障自身和客户的资产免受网络攻击的侵害，在这一目标下，不同的领域有不同的子目标，以及对应的指标以衡量目标的达成情况。业界有很多指标不反映目标的情况，例如某 WAF 产品以自己每天为客户防御多少亿次攻击为指标，而不是以产品的易用易部署、低成本高吞吐、低延迟等更能反映其商业目标的指标。这样的“防御多少亿次攻击”的“想当然”的指标看似容易量化，但其荒谬程度就好比某消防站以扑灭多少次火灾为绩效考核标准一样，失去目标的指标对商业价值没有意义。
以这样的不合理指标评估的工作甚至会带来负面影响：它会在错误优化方向上浪费人力和计算资源，也变相鼓励短期效益忽略长期目标，甚至有时候它甚至纵容玩弄评估系统和弄虚作假。如果用威胁的覆盖率作为指标，那么模型可以认为所有活动均为恶意行为，并将大量事件输出给安全运营团队处理；如果用检测准确率作为指标，那么模型最好什么都不汇报，只要不预测就不会犯错；如果用告警量作为指标，那么模型会不加甄别的发送海量告警，只要足够多就可以拖垮客户运营团队让他们没时间投诉。可以对这些看似无理取闹的行为在实际工作中以不同形式真实存在。
错误之二：机械套用常规指标
基于统计的机器学习判别模型是为了学习目标分布的期望而设计的，它暗示着算法总是被激励去预测多数群体的行为*，因为多数群体主导了目标分布的统计期望。如果机械套用常规的准确率召回率指标，而非理解算法更倾向于寻找多数群体行为并按照特定问题设计符合该问题的指标，不仅不能解决问题，反而会让人们对算法的有效性产生疑问。
网络安全中攻击事件的发生频率分布极度不平衡，攻击事件往往只有千万分之一的概率出现，同时每种攻击事件发现的难度千差万别，如果想当然的要求判别模型达到对攻击事件有90%的准确率，那么模型最好就什么都不检测，因为负样本比正样本高出若干数量级，单个样本的误判足以将准确率降低到接近于0，这类问题已经不能通过常规的非平衡样本方法解决。
网络安全的各种情况里，多数情况缺少基准事实（ground
truth），例如0day漏洞的发现，APT攻击等，在这种情况下对数据模型要求所谓的召回率，甚至所谓“未知威胁的召回率”，这样的指标可以说“连错误都算不上”（“not
even
wrong”）。”世界上只有两种公司，一种被黑客入侵过，另一种将被入侵。“*
我们同样也不能等待自己被入侵以计算召回率。入侵攻击事件的对商业的效果有很大延迟，比如若干年后的数据泄露，或者暗网上正在出售已泄露的数据而安全团队依然不知道。如果为了追求基准事实而仅仅依赖某些攻击评测手段，例如邀请蓝军攻击等，其受限的攻击场景也会片面评估模型的效果。如果数据科学团队因为任何原因应允了类似的指标，团队会为此付出大量的人力和资源，最终以不能解决问题而失败收场。
除了常规的准确率召回率等指标，数据模型还应该有面对未知情况的茁壮性、可解释性、可运营条件等，否则该模型的有效性只停留在已知的固定数据集而不能成为可靠的生产环境流程。
错误之三：独立检出的诅咒
检测类的模型是机器学习模型在网络安全行业的热门话题，例如恶意二进制文件/脚本检测、钓鱼页面检测等，其超越已有规则模型或者第三方情报的独立检出常常被用来当作评估指标。这个看似合理的指标在实际工作中带来了不少的问题，不限于以下这些：
- 检出样本的商业价值更多在其可以影响的业务资产而非样本个数，评估过程也忽略了检出时间的先后次序带来的影响。
- 缺失准确率等质量评估的规则模型的结果作为分母不足以合理的计算独立检出率
- 使用完全不同方法的规则与机器学习模型的结果常有大量重合，仅评估机器学习模型而忽视规则模型的独立检出指标，这也常引发评估公正性的讨论。
本文作者甚至观察到，某些安全团队一方面排斥数据模型的检测结果，一方面从数据模型的结果提取规则加入自己的检测库，通过提高分母的办法让数据科学团队的独立检出率保持在较低水平。安全团队口中的“机器学习没有用”和数据科学团队提出的“安全团队又当运动员又当裁判员”等观点均来源于此，这些无意义的内部竞争消耗了多个团队的精力和信任，最终造成了公司层面的人员流失和经济损失。独立检出这一指标带来了割裂团队阻止合作的诅咒。
荣誉提名：正确的指标，错误的问题
我们在实际工作中也观察到，有些网络安全问题问题本身不适合机器学习和人工智能，比如利用第三方情报检测未知 APT 攻击等目标；想要构建基于日志的威胁发现，然而忽略了所需要的数据采集和数据仓库工作；某些问题本身需要巨大投入，而现有资源不足以支撑，最常见的是各个公司热衷于自研反病毒引擎；或者是该问题本身并不存在，比如说机器学习生成安全运营的告警白名单，而白名单本身就是个伪命题。这些问题都可以设立明确的指标，但是其目标本身是个错误的问题，最终导致数据科学团队无功而返。
一些设计评估指标的建议
所有的指标必须以目标为前提。目标定义了解决问题的有限责任，只有在有限责任下才可以提出合理的指标。我们必须总是保证目标优先，而指标只是在保证目标时候的关键结果，需要理解商业需求制定目标而非拍脑袋拍出一个看似有道理的指标，数据科学家也需要清晰鉴别此类拍脑袋的评估标准并及时提出反馈。
在规划问题和设定目标时，应该评估该目标是否过大或者过小，该场景是否适合使用该解决方案，以及该解决方案的目标是否在合理的资源预算内。建议在规划对比业界一般解决方案和自身特定问题，按照当前情况合理安排资源。
独立检出一般是个很坏的指标，把数据模型和规则模型或者外部采购放到了对立面，同时忽略了检出样本对资产的影响以及检测时间先后等因素。对于检测类的模型，我们尽量避免将独立检出作为指标，而使用交集并集看检出结果的总体覆盖率和对资产的影响；如需对比模型应该看检测时间先后而非鼓励规则模型获取独检结果后更新规则以取代数据模型；同时考虑到作为基础模型的规则模型解决的是该问题较为容易部分，机器学习模型的独立检出应该以大于零为指标，并考虑下一轮迭代更新的代价。
如果没有基准事实或攻击方测试怎么办？在缺少基准事实的情况下，尽可能多的异常检测以及尽可能多的解释这些异常发生的原因，能够解释异常结果的召回率可能是更好的评估指标。在缺少攻击方测试的情况下，可以利用防守方对资产所需的防守面的覆盖程度评估攻击检测的指标。在网络安全这一动态对抗环境下，我们也必须主动且及时调整评估策略。
总结
合理的评估指标可有效的促进数据和安全模型在其业务领域体现商业价值，我们需要设定符合目标的合理评估指标。数据科学团队也需要深刻理解算法总是被激励去预测多数群体的行为，并合理设计评价指标以发挥算法模型的优势。
合理的指标也可以避免对模型的无谓优化甚至错误优化。无论该模型的优化目标是否正确合理，聪明的数据科学家可以将建模工作做的很出色，而脱离了合理的指标，优化的越好带来的错误就越多，其最终带来的商业损失和工作的挫败感需要更多的代价来平复。
机器学习不是万能灵药
这是本系列文章的最后一篇，我们从问题求解的角度来讨论机器学习解决网络安全问题时失败的另一个原因，机器学习在解决某些问题时，有时是方法的用法不对，有时是方法和问题根本不适合。
- 深度学习不是一切
- 机器学习仅是人工智能领域之一
- “你是否考虑过更简单的方法？”
深度学习不是一切
我们见到很多谈机器学习就必谈深度学习的场景。深度神经网络在图像文本等领域表现了深层网络对特征表示学习（representation learning）的强大优势，加之由神经网络带来的迁移学习（transfer learning）在解决多个问题时的神奇效果，它对解决网络安全问题的思路带来不小的冲击，大家都想试试看网络安全问题能不能因此受益。不过”天下没有免费午餐“，神奇的深度学习用其适用性作为代价换来了部分问题的解决，过去的几年里涌现的失败案例给我们总结了一些经验。
特征表示对网络结构的选择需要建构在对问题和模型的理解上。网络安全领域里序列模型似乎最为受宠，RNN/LSTM
因为其简单的开源实现而备受关注，于是我们在各个问题上都可以看到它的身影，比如之前提到的
LSTM 预测 DGA 算法的多个工作，其本意是寻找模型拟合 DGA
背后的伪随机数生成器（PRNG）。抛开 DGA
可能使用异或、位移、素数变换等多种不同的 PRNG 组合导致 LSTM
等浅层网络很难有效完整拟合并解释，LSTM 对初始状态的记忆和依赖也会对 PRNG
的拟合效果适得其反。Mostafa Hassan “Cracking Random Number Generators
using Machine Learning – Part 1: xorshift128” * 抛开 LSTM
而只设计使用了 Dense Network 即可对基于 xorshift128 的 PRNG
做到很好的拟合，文中也对比了 LSTM + Dense Network
的实验效果，并对拟合结果做了了分析，有兴趣的小伙伴可以继续阅读。
机器学习行业有一句俗话，“垃圾进，垃圾出”。网络安全问题有多样的输入，而深度神经网络并不是关于特征组合的通用人工智能，它需要该网络结构可以处置的合理的输入才可以通过表示学习得到特征。一个典型的例子是之前提到的
malconv
，它试图借用图像处理的方法，通过输入二进制文件的原始字节码到简单的卷积层并抽取和归纳基础特征，而简单卷积并不足以感知编译器对字节码的组合，其结果为该网络仅学习到文件头签名等特征而非与恶意行为相关的函数调用特征。在
Joshua Saxe with Hillary Sanders “Malware Data Science: Attack Detection
and Attribution“* 这本书里分析了 opcode 和基于 opcode
的相关建模工作，指令跳转或者函数输出表等作为模型的输入可以更好的支持恶意软件的检测模型。
网络安全问题有较强的对抗和动态性，它需要模型自带一些基本的假设去处理未知情况并证实其预测理由，而深度神经网络缺乏归纳偏置（Inductive
bias）*，它对未知情况的预测很不确定也不好解释，这导致了使用深度模型时的“黑盒”困扰。如果是线性回归做拟合，我们可以观测其
Y 值与以 X 向量为参数的线性函数，如果是 Logistic
回归，我们可以观察其超平面对正负样本的切分情况，这些归纳偏置都可以证实（justify）模型的预测，而深度神经网络只能表明
Y 是 X
向量的某种非线性函数，该函数与数据增强、网络结构、激活函数、归一化等各种在训练过程中加入的约束条件有关，这导致在实际使用中很难证实预测结果的有效性，加之网络安全问题往往需要较强的领域知识做较为昂贵的验证，最近的一些增强模型可解释性的工作对此也仅有有限的缓解。一个有趣的例子是
SpamAssassin 这个垃圾邮件检测的开源项目，它在历史上出现过一个神奇的
bug，会把所有 2010
年之后的邮件全部判别为垃圾邮件。因为在垃圾邮件这种强对抗场景里攻击方总在变换不同花样，它的
Bayesian
判别器按照年份调整了每个特征的权重，这本是一个合理的做法，但是训练集里没有
2010年之后的数据，该判别器就本着宁可错杀也不放过的偏置将所有未知的邮件全部判断为垃圾邮件。当然，SpamAssassin
的模型偏置提供了方便理解的证实预测的理由，这个问题很快就被找到并修复。
同样，因为网络安全领域每个问题个体特性和对领域知识的要求较强，不像图像、文本等常见场景可以方便复用预训练模型，这也限制了深度神经网络迁移的用武之地。总的来说，深度学习作为机器学习的一个子类，它远不能让人随手一箭八百里外射下雄鹰，它的技术优势伴随着应用的局限，我们需要合理的使用该方法而不是盲目套用。
机器学习«人工智能
《人工智能：一种现代方法》将“机器学习”放在第五单元，大家常说的“基于样本的学习”是该单元下第十九章（以 2019 年第四版为准）。人工智能作为学术领域方向，它还包括搜索、规划、逻辑、推理、知识表示、感知与行动等多方面，它在问题求解的应用方式应该是多个子方向的结合而不局限于机器学习。举例来说，AlphaGo 这个人工智能的标杆应用的成功来自于深度神经网络与蒙特卡洛树搜索方法（Monte Carlo tree search (MCTS)）的结合，而后者是每一本人工智能教材里介绍状态搜索都会提到的算法，而 AlphaGo 加入了深度网络的特征抽取与对抗训练，将 MCTS 算法的涉猎范畴从课本里的五子棋一举提高到了广大媒体欢呼的围棋。
机器学习之外的其他人工智能方法在网络安全领域问题也有不少例子。这里仍然有一个有趣的例子：攻击方试图利用
N 个漏洞及其组合试探目标的 K 个攻击点，每次必须使用 N 个漏洞中的 K
个测试，且漏洞利用的顺序与结果相关。在若干轮测试之后，攻击方只得到一些失败的组合以及其失败的原因，可能是挑选的
K
个漏洞部分已经失效（只知道个数但是很难知道哪一部分），可能是漏洞组合顺序不对等，我们能否根据已知测试结果设计更有效的漏洞组合设计新的测试策略？更难的问题是，是否可以设计根据上一轮结果做出调整的自动化的策略？这个问题可以通过状态空间搜索完成。如果将其简化，各位小朋友们会发现它和3位密码锁的谜题*很相似，从
0-9
十个数字里挑选三个数组成密码，从错误的密码中总结出规律，得到正确的密码。三位密码锁的问题（N=10，k=3）可以通过暴力搜索
000 到 999 的各种组合并验证其是否会掉进已知错误，但如果 N 很大，k
也较大的情况，我们必须使用上面提到的 MCTS
搜索并设计合理的剪枝条件（比如可能触发部分漏洞无效的漏洞组合等）减少搜索空间，可以引入主动学习（active
learning）的办法按照提出的测试方法及其反馈调整搜索方向。这类问题统称为
MasterMind* 问题，感兴趣的小伙伴可以自行参考阅读。
在问题求解中，机器学习与非机器学习方法不应该互相排斥，而需要通力合作。基于样本的学习总会有由样本带来的局限性，它需要别的模型帮它“向其他地方看看”（look
elsewhere）。在 NLP
中常见的例子就是实体消歧，例如智能体试图理解“苹果”这个单词，它需要知道这是水果还是那个电子产品公司，它的一般方法是通过上下文关联的知识库以图谱的形式推断“苹果”在语境中的意义。类似的方法在网络安全里也有不少结合了图模型与知识图谱的例子，比如本文作者团队去年发表的工作
“Honeypot + graph learning + reasoning = scale up your emerging threat
analysis”*
就是结合了序列关键模型和知识图谱，它从发现两个不同 URL
在网络流量中的序列关联出发，通过构建知识图谱将
URL、二进制哈希值、对应的检测结果等上下文信息连接起来，再通过图模型中链接预测（link
prediction）算法询问图谱是否能找到一条语义路径可以解释两个 URL
之间的关联，并利用了一阶逻辑（first order
logic）的推理方法保证语义路径在充分但不必要和必要但不充分条件存在时的合理性，从而达到预测未知恶意软件下载途径的结果。
当然，本文不能包含人工智能方法下的各种子方法及其组合解决网络安全问题的方案，以上几个例子仅为抛砖引玉，更多的方法和组合方式留给各位小伙伴探索。
你是否考虑过其他办法？
Joshua Saxe
的推特上问过一个很好的问题，当我们展示基于机器学习模型的成果时，我们有没有考虑过更简单的办法？*
这些简单方法可以来自于理解领域知识并对其一般化表示，也可以来自于对数据的预处理，也可以对目标问题的认真理解与分拆等各个方面。
之前有某位小伙伴从课题研究中提出一个有意思的问题：在目标资产侦查阶段，攻击方通过子域名枚举爆破方法（subdomain enumeration），利用字典单词组合去猜测目标子域名，能不能通过收集其 DNS 流量并使用机器学习的办法破解其原始字典内容呢？在他尝试抄起 GPU 跳入 BERT 等深度模型之前，我建议不妨试试先把数据排序用相邻字串的最长公共子串猜测一个含有噪声的字典，再用这个字典去切分子域名，将字典问题变成字符串切分问题。随后的实验证明，这种更简单的算法不仅可以有效得到绝大部分字典，并且可以灵活对抗插入的噪声。
机器学习的优势是从数据中学习其统计表示，直观的认为是它拟合规则，但问题求解并不排斥由领域知识直接带来的规则，即使该规则只能部分的解决问题。例如
Alexa Rank 这个全球网站排名常被用来当作恶意软件 C&C
域名检测结果的参考，它包含的领域知识是”恶意软件不太可能利用高排名域名当作
C&C“。随着新的商业模式和攻防对抗，Alexa Rank
也被攻击方利用，本文作者和同事也通过 DNS
流量构建了更符合网络安全的域名信誉排名方法*，请有兴趣的小伙伴自行阅读。
更简单的方法也可来自于数据的筛选。正如好的食材只需要简单的烹饪即可迸发其香味，好的数据只需要简单的模型即可带来清晰的结果。一个有意思的例子来自于本文作者与前同事讨论他的文章
Asaf Nadler et al “Detection of Malicious and Low Throughput Data
Exfiltration Over the DNS Protocol”* 在 DNS
数据流中检测低吞吐隧道这样常用在 APT 攻击中的数据渗出方法。因为低吞吐
DNS 隧道的信号很弱也很罕见，文中用独立森林（Isolation
Forest）做异常检测需要细致的筛选特征，导致它在大规模有噪声的数据下很难表现其检测威力，也因为算力的问题限制了其解决问题的规模。我们在讨论中发现，如果在
DNS
数据流中对所有未见过的域名做一轮筛选并以此作为独立森林模型的输入，其预测表现和算力均可满足大规模数据流的要求。通过深入理解目标问题的场景，我们简单的调整了更合适的输入数据使得现有模型可以更上一层楼。
更简单的方法也可以来自于分拆目标问题，它可能是代表部分目标问题的子目标，也可以是目标问题的抽象降解（reduction）等，这些均遵循问题求解的一般方法，请有兴趣的小伙伴自行探索。一个有趣的例子是，本文作者与团队发表在
Botconf 工作 “Math + GPU + DNS = Cracking Locky Seeds in Real Time
without Analyzing Samples”*，它在 DNS 数据流中检测 Locky
勒索软件的 DGA 域名，通过 GPU 暴力破解其 DGA
的种子并成功预测其未来域名。在这个工作中，我们将这一较难的问题分多步骤拆分和降解，并复用了之前工作中的异常模型和关联模型：
- Locky DGA 域名均为新域名，所以在 DNS 异常检测并筛选从未见过的域名
- Locky DGA 含有多个域名，所以我们通过
domain2vec计算异常域名之间的序列关联而仅对较强关联的族群测试其 DGA 属性。 - Locky 通过伪随机数生成器生成单个长整数并以此输出域名字符串，所以我们将每个候选域名逆运算得到其对应的长整数，即可利用 GPU 批量爆破该整数在当前日期下可能对应的种子。
由此我们成功破解了 Locky DGA 的几十个随机数种子并将其反馈给研究社区。
本文作者建议数据科学团队在思考解决每个问题时可以反复提醒自己：
是否存在可以全部解决或者部分解决这个问题的其他办法？
总结与后记
在解决问题的过程中，我们必须坚持“问题求解”为主要目的，而相关的技术选型是支持该目的的方法，这些方法之间的合作应该大于竞争。这同时也要求数据科学团队不断的拓宽视野，多留意别的领域的成熟方法以及其为何有效的根本原因，并尝试引入网络安全领域。同时，本文作者也看到很多数据科学团队积极学习网络安全的领域知识，只有这样才能更有效的寻找适合该领域问题的技术。
本文作者收到了对这系列博客不少有意义的反馈和建议，各位小伙伴们也会从“机器学习为什么失败了”的话题出发，结合自己的工作和研究延伸了不少讨论。数据模型在网络安全领域是最近几年才出现较大规模的应用，工业界里的各种问题和困难也随之而来，这些问题的求解不像图像、语音、视频、文本等领域有较为成熟的方法框架，往往需要数据科学家从问题求解的基本方法出发，将数据模型知识结合网络安全的领域知识，寻找可以切入问题的方向，这其中难免有无数的失败，这都是符合现代科研方法的可预期的失败。我也相信通过多次失败的沮丧和偶然成功的惊喜，我们可以总结足够的经验教训，构建属于网络安全领域数据模型的一般方法框架，一起构建更加安全的互联网。
参考文献
- Raff et al, Malware Detection by Eating a Whole EXE https://arxiv.org/abs/1710.09435
- Vinayakumar R., Soman K.P., DeepMalNet: Evaluating shallow and deep networks for static PE malware detection https://doi.org/10.1016/j.icte.2018.10.006
- Coull et al, Activation Analysis of a Byte-Based Deep Neural Network for Malware Classification https://arxiv.org/abs/1903.04717
- Bose et al, Explaining AI for Malware Detection: Analysis of Mechanisms of MalConv http://vigir.missouri.edu/~gdesouza/Research/Conference_CDs/IEEE_WCCI_2020/IJCNN/Papers/N-21218.pdf
- 为什么 LSTM 检测 DGA 是无用功 https://toooold.com/2021/07/12/dga_detection.html
- 鲁迅《且介亭杂文末编·这也是生活》
- Uncovering The “Unknown Unknowns”: Why Threat Hunting is a Security Must-Have https://www.crowdstrike.com/blog/uncovering-the-unknown-unknowns-why-threat-hunting-is-a-security-must-have/
- Sophos AI YaraML Rules Repository
- https://github.com/sophos-ai/yaraml_rules
- Augmented Intelligence to Scale Humans Fighting Botnets https://www.botconf.eu/2017/augmented-intelligence-to-scale-humans-fighting-botnets/
- 7 Steps to Ensure and Sustain Data Quality https://towardsdatascience.com/7-steps-to-ensure-and-sustain-data-quality-3c0040591366
- FATE (Federated AI Technology Enabler) https://github.com/FederatedAI/FATE
- 曹操批注孙子兵法，“善战者无赫赫之功”
- Quora “Why do we use loss functions in machine learning instead of simply optimizing for accuracy?” https://www.quora.com/Why-do-we-use-loss-functions-in-machine-learning-instead-of-simply-optimizing-for-accuracy
- The Myth of the Impartial Machine https://parametric.press/issue-01/the-myth-of-the-impartial-machine/
- Not even wrong https://en.wikipedia.org/wiki/Not_even_wrong
- “There are only two types of companies: Those that have been hacked and those that will be hacked.” – Robert Mueller, former Director of the FBI
- Joshua Saxe with Hillary Sanders, Malware Data Science: Attack Detection and Attribution https://nostarch.com/malwaredatascience
- Mostafa Hassan, “Cracking Random Number Generators using Machine Learning – Part 1: xorshift128” https://research.nccgroup.com/2021/10/15/cracking-random-number-generators-using-machine-learning-part-1-xorshift128/
- Inductive Bias https://en.wikipedia.org/wiki/Inductive_bias
- Monte Carlo tree search https://en.wikipedia.org/wiki/Monte_Carlo_tree_search
- A step-by-step look at Alpha Zero and Monte Carlo Tree Search https://joshvarty.github.io/AlphaZero/
- 3 digit lock riddle: Using Prolog to solve a brain teaser (Master Mind) https://stackoverflow.com/questions/61276283/using-prolog-to-solve-a-brain-teaser-master-mind
- Mastermind https://en.wikipedia.org/wiki/Mastermind_(board_game)
- Joshua Saxe twitter https://twitter.com/joshua_saxe/status/1328834273214861314
- “System for Domain Reputation Scoring” Patent us 14/937699
- Asaf Nadler et al “Detection of Malicious and Low Throughput Data Exfiltration Over the DNS Protocol” https://arxiv.org/pdf/1709.08395.pdf
- “Math + GPU + DNS = Cracking Locky Seeds in Real Time without Analyzing Samples” https://www.botconf.eu/2017/math-gpu-dns-cracking-locky-seeds-in-real-time-without-analyzing-samples/
- “Honeypot + graph learning + reasoning = scale up your emerging threat analysis” https://www.youtube.com/watch?v=r7KbGJPFkxQ&ab_channel=botconfeu