所以我已经差不多一年没有从团队进攻跳到团队防守了。
我在一个纯粹专注于进攻的组织里呆了很长时间，以至于开始思考防守问题的时候有点不和谐。
一点也不是因为在进攻中猎杀虫子与在防守中猎取虫子的经济是完全颠倒的。
进攻是以目标为导向的。你要确立你想要实现的目标，并相应地进行审计。照料你的攻击面花园，直到你长出所有你需要的配料来完成第0天的汤。
在防御方面，你被困在试图从过去的哈克斯节的鬼魂中推断出来。虽然这些天来确实有大量已知的和新颖的攻击研究在那里进行，但…。归根结底，你要面对的是一个攻击者，他的目标、时间表和资源基本上是未知的。
假设代码有问题，并将其放入沙箱、虚拟机管理程序、锡箔纸包裹的Chromebook中，在邻居的WiFi…上运行。
重新洗牌记忆。将其设置为不可执行。见鬼，把它弄成不可读的！注意指示器。验证控制流。曲奇所有的东西。堆完整性检查。SMEP/SMAP/SMOP/SMUP…。
哦，对了，硬件。假设硬件出现故障。取消优化。慢慢来。在每个权限级别复制所有内容。
现在相当多的高级漏洞开发都是公开的，而Arxiv显然是新的Phack。
如今，你甚至可以根据进攻研究获得博士学位。而且也不是那些喋喋不休的关于多态外壳代码检测的手摇式的抨击，不，不，是真正的东西。
如果你错过了这样一个时代，在irc频道的黑暗角落里，大多数事情都是出于纯粹的愤怒或好奇心而发生的，…。你在背景中听到的声音是世界各地40多岁的黑客们开始担心衰老而发出的略带紧张的笑声。
有很多关于以某种自动化方式建立可利用性的重要性的讨论。其想法是，您只能通过已证实的可利用性适当地确定要修复哪些bug的优先级。
一个明显的论点是，是的，如果一个bug有可证明的安全影响，那么它就应该被优先考虑。
我认为它变得棘手的地方在于可利用性的概念。可开发性是个奇怪的术语。这听起来像是一个客观的估值。
因此，无论出于何种意图和目的，您所能做的最多就是根据您作为防御者所了解的与您的资产部署方式和位置以及您实际操作的威胁模型相关的利用情况来建立可利用性。
本·霍克斯(Ben Hawkes)在这个问题上有一些扎实的想法[1]，就等价类而言。将漏洞A出现的条件与已知的漏洞B的可利用条件相匹配，如果有足够的重叠，那么您可以做出一个合理的可利用假设。
如果没有，那么就付钱让人尝试编写漏洞，并将努力的结果堆积到您的黑客图标中。
很多个月前，当微软第一次发布可利用性指数时，我为他们写了一份关于这个主题的白皮书[2]。我当时试着沿着类似的思路进行论证，但我认为2020年的主要区别在于，开发知识的公共主体的质量要高得多。
Julien Vanegue最近也提出了一些有趣的论点[3]，支持基于可开发性的分类优先顺序，而这正是目前所缺乏的。
在可利用性领域要解决的一个较难的实际问题是，当您将平台配置与软件生态系统相结合时，问题空间开始爆炸。
攻击面垂直的每一层都会带来潜在可利用性的巨大增长，这是你现在必须要考虑的。
VuSec最近的工作[4]将他们的推测性执行漏洞研究与更传统的软件漏洞结合在一起，这是一个很好的例子，说明了当某人现在转向基于脱节的威胁模型的安全假设时会发生什么。
因此，您所能期望的最好结果可能是对Benand Julien的想法进行一些有限的解释，并将其应用于您的代码的某个特定子集，在一些已知的静态平台配置中。您对威胁模型指数的限制越多，有关可利用性的自动化决策就会变得越实际。
但是，就利用开发而言，这并没有考虑到bug的变形性。许多成功的利用漏洞实际上都是错误的组合。独立地说，这些错误可能并不代表可被利用的漏洞，但是一致地，它们代表了一个可利用的漏洞。
或者，更有趣的是，一个bug变成了多个利用漏洞的原语。朱利安在他关于近似可利用性的有缺陷的思考一节中略微触及了这一点。为了真正做出关于可利用性的明智决策，您必须列举每个bug的所有副作用，以及每种组合。
这使得以可利用性为中心的分类过程变得更加棘手，因为现在您需要综合的bug感知。这种意识需要有重点的审计，试图找到各种碎片来完成攻击拼图。
一种更实用的方法可能是评估bug作为利用原语的可行性。肖恩·希兰(Sean Heelan)在AEG领域的研究深入。
但即便如此，从非常具体的平台和配置约束出发，也很难对问题一概而论。您将不得不为几乎每个平台和软件堆栈重新发明相同的轮子，每个平台和软件堆栈都有自己的可利用知识语料库。
这让我们回到了防守与进攻的人体工效学。如果我是一个攻击者，我显然关心可利用性。这就是我做事的方式。
但是，如果我是开发者意义上的捍卫者，那么我可能更关心一般的代码质量。
错误和错误密度是代码质量的症状。细菌越少，然而潜在的利用原始人…。潜在的利用原语越少，成功利用链的机会就越小。
因此，根据定义，我们需要做的提高代码质量的事情就是我们需要做的减少漏洞的事情。如果这种关系在两个方向都成立，那么从整体上关注代码质量和分类速度的流水线策略可能会带来更大的收益？
我确实认为开发人员理解开发后的想法是很重要的。明确了解输入如何影响您的代码，以及这种影响有时如何转化为有利于攻击者的行为。
但是我们把副作用变成了它自己的东西。美化了它。在此基础上建立了自己的事业。
埋在没膝深的虫子里，试图让世界相信，我们最了解的人才是最重要的人。一次删除一个电子邮件通知…。希望无论是谁收到他们的…。我同意。