搜索
综述指南•多个期望从单个上学到有意义的东西的多对一关系学术讨论会•所有人都希望在为小组做贡献，同时也希望从小组那里学习的多对多关系本指南介于这两者之间攻击的历史1988年，美国电脑紧急应变团队（CERT）成立1993年，美国电脑紧急应变团队（CERT）/合作中心攻击响应组（1）1995年，我加入了美国电脑紧急应变团队（CERT）•吉姆埃利斯和拉里罗杰斯带领我们进入了我们后来一直在的轨道上。2003年，总共有了10多个响应职员2004年，有了两个新的攻击工作区•攻击分析•攻击发现和避免软件的过程模型（现今）Conception：概念Requirements：需求Architecture：体系结构Design：设计Implementation：执行QA/Testing：质量评价/测试Correct/Patch：纠正/补丁Release：释放Vulnerability：攻击发现Publication：发布美国电脑紧急应变团队（CERT）/合作中心哲学体系白痴们会说他们是由经验获取知识的。而我更喜欢从别人的经验上获取知识。OttovonBismark德国首相1871-1890对于构建足够的理论基础或是实际应用，直接获得的经验都具有先天的局限性。B.H.LiddellHart大不列颠军事理论家VDA的使命美国电脑紧急应变团队（CERT）©合作中心攻击发现和避免机构的作用是，显著的减少众所周知的攻击。VDA的目标调查和研究现有的方法，技术和工具与现有的VDA的组织合作直接或者是间接的推进实践的状态建立VDA的效率的测量方法为特定的读者编写VDA知识广泛的传播上述的VDA知识•信息保证社团•质量保证社团•软件工程社团VDA反对的目标我们自己不需要建立重大的发现机构，因为•其他人计划或者是已经在做着发现工作•无论如何我们自己都不能发现许多的攻击－许多更高的影响因素•我们希望其他的人从事到VDA的研究中－尤其是在软件工程社团•最终，我们希望美国电脑紧急应变团队（CERT）－如VDA组织，需求减小。－以常规的方式•我们不做软件工程－尽管我们的名字如此，但是我们不做软件工程。软件的过程模型（未来）Requirements：需求Architecture：体系结构Design：设计Implementation：执行QA/Testing：质量评价/测试Correct/Patch：纠正/补丁Release：释放VulnerabilityDiscovery：攻击发现Publication：发布VulnerabilityDiscovery&Avoidance：攻击发现&避免VDA的过程模型（全世界的）Publish/Patch：发布/补丁Release：释放PublicVulnerabilityDiscoveryProcess(es)：公众的攻击发现程序PrivateSoftwareEngineeringProcess(es)：私人的软件工程程序CaseInspection：个案检查Infusion：灌输VDACodificationProcess：VDA的编写过程个案的学习识别所有的公众攻击发现组织，如下：•即使是那些看起来是有组织的，程序的定向是为了发现的•具有可靠的发现攻击的历史•具有分担的意志，用抽象的术语来说，就是将这一知识作为一个总体而和社团一起分担。去观察他们的影响并且以一个新闻工作者的角度来采访他们出一本书来证明这些个案•这本书要包括这些组织以及他们的工作两个方面个案研究为成功者颁发大量的专门的荣耀•以组织或者是个人的名字来命名•将成功或者是很有希望成功的精确的归功于它们的创造者•记述失败或者是不确定的实践时，不记录它们的归属者包括他们的工作的技术方面，程序方面和组织方面每年重复这个过程一次每年出版这本书的一个新的版本包括我们知道的关于VDA的“所有的事情”求助！我们需要你的意见：•什么组织或者是个人需要进行个案研究？为什么？•他们的特征是什么？成就又是什么？应该包括什么专业的讨论会？•用来学习？•用来教授？迄今为止我们鉴定的组织/个人基本方法如果我们真诚的希望在攻击出现以前就把它们停止掉，那么我们就必须：•采用软件工程师们的观点－因为软件工程师们是唯一的可以使这种情况发生的人－并且，我们必须从他们的观点来看这个问题，进而以他们的语言来描述这个问题和它的解决方法观点的改变（1）和我们以前在攻击上使用的观点相比，VDA中的A需要有一个不同的观点•VDA对“验证”攻击不感兴趣•VDA对开发或者是攻击不感兴趣•VDA对“验证”攻击的影响不感兴趣•VDA对“验证”工作区不感兴趣•VDA对“配置”不感兴趣•VDA对“验证”最差的攻击不感兴趣从根本上讲，VDA实际上是关于抢先减少所有潜在的工程攻击观点的改变（2）然而，一种软件工程观点认为•所有可能被开发的缺陷都必须被消除掉－“潜在的”和“事实上的”是同等重要的•必须总是能够设想到全能的对手－所有的对手，包括现在的和未来的，都必须得考虑到计划从一个“公众”攻击发现的观点来看•这个过程从第一个客户关系开始•主要在“公众”中传导•必须是“可以控制的”从一个软件工程的观点来看•这个过程从观念的规划开始•两个非常清晰的发现的案例－先前发布的编码基数中的攻击－最新发布的编码基数中的攻击攻击发现的问题•目标的选择•发现所使用的技术•发现所使用的工具•暴露的事实•工程上的纠正•各个评价之间的关系•潜在的合法的障碍•国内和国际关注的东西•长时间的影响•无意识的副作用目标的选择（1）互不相关的动机•当攻击研究的发起者和VDA组织的发起者具有互不相关的动机时，会怎么样呢？－在技术选择上的争论可能会加速研究，从而“证明”哪一个是更好一点的方向发展隐藏的或者是敌对方的评估•在不与成果的创造者合作的情况下，评估这个成果会有多少困难呢？•发起者会认为这种评估是客观的吗？－对成本而言，客观性是值得的吗？目标选择（2）附着于评估的串•抑制结果？•延迟结果？•顺从成果的所有者？•顺从发起者？•限制除了攻击以外的细节？•限制副作用结果的产生？商业秘密•如果合作伙伴中的卖方提供商业秘密来帮助评价，那怎么办呢？•VDA组织中的哪个人可以接触到商业秘密呢？发现所使用的技术（1）攻击的可证明性•在评估（没有经过“处理”）中，为了列出攻击的特征，而需要的证据的水平－必须把攻击的特征证明给卖主在没有可证明性的情况下，完成的评估•这个“报告”真的还可以完成吗？•是否一个清晰的缺陷就够了，还是说它必须得是可以被开发的呢？•在没有进行局部的“处理”的情况下，可以对攻击下结论吗？发现所使用的技术（2）评估的成本/利益•什么样的评估投资是最有价值的呢？－体系结构上的和设计上的攻击是更有价值的，但是，也更难发现。因为在发布之后的修正可能是极端地，或者是无限的昂贵，所以它要远远的有价值－执行攻击比发现攻击要简单多了，但是相对应的，也就具有较少的价值之所以具有更少的价值仅仅是因为它们容易被发现在发布以后，保证书必须是可确定的•第三方评估通常是具有最差的成本/利益比－信息的数量最少－最小的价值，攻击最容易发现发现所使用的工具（1）增加的攻击发现•新的工具将如何影响社团呢？－伴随着工具的使用，更多的攻击将会被更多的人发现（至少是增加的）－加重“处理”组织的负担指南协助的要求•是否VDA组织能够负担得起发布这些工具呢？－需要其他人为这些工具的使用提供“支持”发现所使用的工具（2）业余者用法•业余者能够使用这些工具吗？－对于业余者而言，工具不太容易被操作。－工具用户界面需要把目标定位于专家，而不是定位于普通的公众暴露的事实（1）VDA并不能够“处理”这些攻击•VDA攻击是怎么处理的呢？－必须使用已经建立起来的“处理”程序，而且这些处理程序不可以复制－对于VDA的目的来说，这些已经存在的“处理”程序是否是充足的呢？个人攻击公众暴露的事实•攻击与成果观点是相互冲突的吗？－即使VDA不关心个人攻击揭露的事实，风险承担者也会期望他们将这个问题恰当的解决的。－在VDA和VH之间需要建立一种独立的而不是共生的关系暴露的事实（2）评估报告揭露的事实•在评估的最后，由哪个人根据结果决定发生什么？－发起者这样的关系将会希望得到切实的文件－他们能够自由的四处展示－作为成就的证据评估报告的所有权•谁拥有这个报告的所有权呢？－从处理的观点来看－从知识产权的角度来看暴露的事实（3）报告的发表•发表的频率频繁到等于只揭露几个攻击•在发布报告前，报告中包括的所有的攻击，是否都必须得“处理”了呢？－是？这样将会使VH在通往VDA的里程碑的关键路径上工作－否？发布包含“新”攻击的报告的结构会是什么呢？暴露的事实（4）不明确的攻击•“潜在的”攻击的报告是否会引起问题呢？•在发表的报告中，从工程角度看的一个非常清晰的缺陷，可能会在攻击分析社团引起相当大的争论－对于攻击的开端来说，从工程师的角度看要比从分析家的角度看要低的多评估的副作用•非常清晰的缺陷不是攻击吗？－对于发起者而言，它们显然是有价值的•缺陷和攻击的分界线在哪里呢？－VDA与QA相比是多呢还是少呢？揭露的事实（5）成果内部•如果成果内部的揭露需要理解攻击呢？－许可是可能的吗？或者甚至它就是一个好主义呢？•如果评估是“不公开的”或者是“敌对的”呢？竞争评估•对你的报告，其他的VDA组织将会做出什么样的反映呢？－其他的VDA组织可能会评估你的评估这是同行审查过程中很正常的一步其目标可能会是推进认识也可能会是诋毁其他人的名望对可靠性有疑问的攻击，这样的竞争可能会产生明确的结构工程纠正•如果评估是不公开的，那么，将会期望什么样的处理，或者是什么样的处理是可能的呢？•如果发起者希望这个攻击继续，那又怎么办呢？发起者专用的纠正•如果工程纠正是专用于发起者组织的，那么又怎么样呢？－报告的发布可能会危及到发起者组织－对于其他的组织来说，这份报告也许会是毫不相关的，或者甚至可能会是错误的各个评估之间的关系（1）遗传性攻击•如果“发起者的”评估发现了“遗传性”攻击，那又怎么办呢？－其他受到影响的“成果”又该如何处理呢？•如果不公开的评估中发生了遗传性攻击，那又该怎么办呢？－“其他的”攻击是否需要进行不公开的考虑呢？争论•如果两个不同的发起者希望相同的目标评估，但是却使用相互冲突的串，那么又该怎么办呢？各个评估之间的关系（2）工程的相互依赖性•什么样的依赖性呢？－共用的图书馆－静态的图书馆－资源的重复利用公共界面条件私人界面条件－随意的剪切和复制•我们怎么发现依赖的成果呢？－一些“依存性的博物馆”？－一些只有卖主才有的公告？－公众的公告和期望？－这难道不是“处理”吗？潜在的合法的障碍反向工程•什么“水平”的RE是被合法的允许的呢？－美国的DMCA？－欧洲，日本？商业秘密•商业秘密，甚至是从来没有被揭露的商业秘密，真的可以在UDA中“使用”吗？－那是否是违背产权的呢？－或者是违背专利权呢？国内和国际的关注点有吗？长远的影响质量下降•范围广大的VDA组织会使得软件的质量下降是否是可能的呢？•生产者是否期望其他的人来发现攻击呢？－免费的？－在契约下？无意识的副作用卖方操作•是否卖方会故意的逼迫VDA社团，免费的为他们发现他们的攻击呢？•是否“少量”的卖主甚至能够发现他们自己的攻击呢？－他们支付得起吗？时间对市场可能会是生或死的问题－甚至他们是否具有这个技术呢？道德规范过剩的卖主•对于一个特定的目标，如果它已经在为一个卖主评估时，又出现了另一个卖主要评估这个目标，那么该怎么办呢？－如果他们中的一个，或者是两个都是不公开的进行的，又该怎么办呢？•对于一个特定的目标，如果它已经在为一个卖主不公开的评估完成了，又出现了另一个卖主要评估这个目标，那么该怎么办呢？－先前的结果是否可以被重新使用呢？－先前的评估的不公开性必须得到保护吗？是否较低的评估价钱就揭示了，已经不公开的进行过这样的评估了呢？软件工程问题我们不知道VDA词典每个人以自己的方式来定义基本的术语所以我也是以自己的方式来定义基本的术语的主要的术语(1)所有者•一个或者是多个人[拥有]这个系统。