创建 VDP

计划政策对任何 VDP 都至关重要,因此需要仔细拟定。 安全研究人员在参与 VDP 时首先映入眼帘的就是计划政策。它设定了该计划的基调,定义了预期,并说明了您对选择参与研究的研究人员的承诺。

如何制定和托管您的计划政策

您可以参考以下准则来起草 VDP 计划政策。计划政策通常只有 1-3 页,通常包含以下主题:

  • 研究人员承诺
  • 测试准则
  • 计划范围

必须向所有潜在的研究人员都提供计划政策。如果您计划仅向少数受邀研究人员私下发布 VDP,则需要对计划政策进行某种访问控制,才能将其提供给您邀请的研究人员,但仅限于其他所有人。研究人员还需要一种提交报告的方法,例如用来跟踪报告的网络表单或连接到工单系统的电子邮件别名。请在设置 VDP 的在线资源时考虑这一点。

第三方漏洞披露和 bug 奖励平台通常提供如下功能:

  • 一种创建、修改和发布政策的方式
  • 创建私密计划的访问控制
  • 以舒适的节奏自动邀请黑客
  • 便于处理收到的报告的收件箱功能

第三方平台还提供各种咨询服务,帮助简化 VDP 的制定和发布流程。通常情况下,使用第三方平台和咨询服务是需要付费的。在确定您的组织的最佳前进路径时,应考虑使用第三方与在内部构建和管理计划的成本和收益。

如需了解应在计划政策中包含哪些内容,请阅读美国司法部的在线系统漏洞披露计划框架

计划政策相关方

在起草计划政策时,请考虑如何与利益相关方合作。各个团队可能会提供有关要纳入政策的注意事项的建议。

Stakeholder 注意事项
Legal
  • 与您的法务团队合作,起草您的计划政策和条款,黑客将根据这些政策和条款参与其中。
  • 研究人员不会获得报酬,因此没有充分的理由要求自己承担严格的入职要求或繁琐的条款。
IT
  • 与您的 IT 团队合作,帮助制定测试要求和范围,例如不要创建拒绝服务条件。
工程
  • 工程团队可以提供有关测试要求和范围的建议,包括哪些类型的漏洞最重要或最不感兴趣。
PR
  • 与您的公关团队合作,审核关于披露的政策措辞。
安全性
  • 安全团队通常主导政策的制定。
  • 安全团队可能会收到黑客的反馈,并随着时间的推移与其他利益相关方一起反复改进政策。

研究人员承诺

研究人员承诺解释了组织对参与研究的研究人员的承诺,他们将遵循政策中列出的测试准则,本着善意行事。例如,承诺在特定时间范围内响应所有收到的安全报告,以及就接受和修复哪些漏洞报告作出决策。

例如:

<您的组织的名称> 致力于与安全研究人员合作,帮助识别和修复我们系统和服务中的漏洞。只要您本着善意行事并遵守本政策中列出的准则,我们即会尽可能做到以下几点
  • 在三个工作日内对您的漏洞报告进行初步回复
  • 在 10 个工作日内确定我们是接受(打算修复)还是拒绝(将您的报告标识为误报或可接受的风险)您的漏洞报告
  • 及时了解我们接受的报告的修复进展

在您的计划政策中采用安全港用语有助于确保研究人员不会因对您的系统的测试而对其采取法律行动,只要他们本着善意行事并遵循政策中所述的所有准则即可。

测试准则

测试指南说明了在 VDP 涵盖范围内的安全测试,以及不在范围内且应由研究人员避免的测试。如果您希望研究人员关注特定类型的漏洞,此部分是重点介绍这些漏洞的好地方。

示例:
执行安全测试时,请遵循以下准则

  • 仅测试您自己的帐号和数据(例如创建测试帐号)。如果您发现可能会导致可访问其他用户数据的漏洞,请先与我们联系,然后再进一步测试。
  • 如果您在测试中不小心访问了其他用户的数据,请告知我们,并且不要存储任何此类用户数据。
  • 请勿执行会导致出现拒绝服务攻击情况或我们的生产服务降级的测试。
  • 社交工程不在此计划的范围之内;请勿试图对我们的组织或我们的用户进行社会工程学攻击。


我们特别关注以下类型的漏洞和影响

  • 远程代码执行
  • 导致访问敏感数据(例如会话信息)的 XSS
  • 导致访问敏感数据或功能的 SQL 注入
  • 导致访问敏感数据或功能的业务逻辑缺陷


我们对以下类型的漏洞不太关注,它们更有可能
因误报或可接受的风险而被拒

  • 在没有状态更改功能的情况下,页面上缺少 X-Frame-Options 标头
  • 未经验证的自动扫描器结果
  • 不太可能被利用和/或没有实际安全影响的问题

范围

范围定义了研究人员可以针对哪些资源进行测试,以及哪些资源不属于 VDP。您需要仔细考虑此范围,并尽可能扩大范围,同时避免您的团队负载过重。您愿意纳入测试范围越多,就越有可能获得安全研究人员的参与。但是,范围不要过大,以至于您的团队无法及时处理收到的报告。先从报告范围内的一些资产入手。随着您对将收到的报告量有了更深入的了解,可以扩大范围。在逐步公开发布您的 VDP 之前,请努力将所有内容纳入考虑范围。

关于如何在计划政策内定义范围,添加每项资产或区域的详细信息将有助于安全研究人员了解您看重什么,以及他们应关注哪些方面。您还可以添加有关如何安全地测试您的资产的提示。示例如下:

资源 mail.example.com
说明 供用户访问其电子邮件的主域名。
有趣的漏洞和影响
  • 导致其他用户的电子邮件遭到未经授权的访问的漏洞。
  • 能够以不可恢复的方式删除其他用户的电子邮件或整个帐号。
可能会被拒绝的问题
  • SPF
  • 钓鱼式攻击或助长钓鱼式攻击的问题
  • 能够发送潜在恶意附件
测试指导原则 请仅测试您拥有的帐号或明确同意测试的帐号。 创建测试帐号时,请在用户名的某处添加“vdptest”。您可以在 mail.example.com/new 创建测试帐号。

这是一个相当详细的明细。或者,您也可以添加一个包含范围内和范围外资产的简单列表:

范围内

  • mail.example.com
  • example.com

不涵盖的内容

  • blog.example.com

为 VDP 筹备资源

在推出 VDP 之前,您需要具备一些适当的资源。您将需要以下资源:

  • 查看收到的漏洞报告
  • 与黑客沟通
  • 查找资产所有者和提交错误
  • 修复 bug
  • 漏洞管理 / 跟进修复

重新审视主要利益相关方

如果您还没有与之前讨论过 VDP 的主要利益相关方进行对话,请确保他们与 VDP 的推出时间表保持一致,并为发布的所有必要资源排队。例如,您可能需要与工程主管合作,确保其团队为在发布后的前几周内可能涌入的大量安全 bug 做好准备。在安全团队中,确保对检测和响应系统中的提醒进行分类的人员了解 VDP 的发布日期,并考虑为测试开始分配更多时间和资源。您还需要组建一支团队来帮助支持 VDP 的日常运营。

组建团队

运行 VDP 需要投入大量的中断驱动工作。 如果您尝试审核、从技术角度验证并响应收到的每份漏洞报告,提交每个 bug、跟踪状态并向研究人员传达更新,可能会感到倦怠。即使您没有大型安全团队,也可以寻找具有安全意识的志愿者来帮助组建团队,以帮助您实施和执行 VDP。您仍然需要定义 VDP 的“所有者”或“负责人”,由其最终负责您的 VDP 取得成功,但您还需要一个团队来为该领导者提供支持。

制定排班表

在您获得资源并愿意为您的 VDP 提供帮助后,可以通过设置排班表来落实一些结构。您可以随意创建此 API,但每周轮替是相当常见的做法。是这周的队长,您要负责完成以下事项:

  • 分类 - 审核收到的漏洞报告
    • 从技术角度验证报告,然后决定“接受”或“拒绝”
    • 将您的决定告知报告该问题的黑客
    • 如果您无法重现问题,如有必要,请向黑客索取更多信息
    • 如果漏洞有效,则向合适的所有者提交经过整理的 bug
  • 漏洞管理 - 推进现有漏洞
  • 沟通 - 向安全研究人员提供现有报告的最新动态
    • 研究人员可能会主动要求现有报告进行更新;检查此问题并根据需要进行回复
    • 如果漏洞已修复,请将此信息反馈给研究人员,让他们知道自己的辛苦工作为您的组织带来了积极的变化。您甚至可以添加模板语言,让研究人员告知您修正结果中是否遗漏了任何信息,或者修正能否以某种方式被规避。

根据收到的报告数量、这些报告的复杂程度以及值班人员的技能和知识水平,值班时间可能从几小时到一整周不等。有关成功轮班的提示包括:

  • 确保您的团队已准备好介入,并在特别繁重的几周为值班提供支持。
  • 制定良好的移交流程;如果有可能需要下一位值班人员立即关注的问题,请写一些交接备注,或者在周末进行实时对话。
  • 创建自动化安排,确保每个人都知道自己的值班时间。 这可以非常简单,只需为每个用户创建周期性日历条目即可。
  • 尤其是在 VDP 开始时,请与值班人员再次确认,确保他们记住这是他们的一周,以及他们是否需要任何帮助。如果轮流的人员比较初级,可以让更高级的人员与他们合作,确保他们不会感到安心,并且可以在他们逐渐提升的过程中提出问题。
  • 可以灵活地调换星期。难免有人会面临紧急情况,需要在工作日请假,或者有人请假等。发生这种情况时,请鼓励团队根据需要调换星期,以适应每个人的日程安排。
  • 创建一份值班“备忘单”,概述了必须履行哪些职责,包括有关如何完成这项任务的文档。

决定内部人员还是第三方

到目前为止,大多数指南都是基于您在内部构建和运行 VDP 的。您可以借助各种咨询服务和平台来制定和执行 VDP。此类第三方通常会产生费用,但有助于指导您如何创建、发布和执行 VDP。有些组织甚至会提供分类服务,帮助您审核收到的漏洞报告,帮助处理与黑客的沟通,以及仅将有效报告上报给您的团队。决定是内部构建此流程还是使用第三方平台,取决于您的要求和可用资源。如果您预算较高但员工人数不多,那么利用第三方来帮助您运行项目不失为一个好的选择。如果正好相反,建议您花时间自行构建程序。

接收报告

如果您决定使用第三方平台,该平台应该能够让黑客直接向您提交报告。如果您在内部构建程序,则需要自行构建。可以是在问题跟踪器中自动创建工单或 bug 的电子邮件地址(例如 security@example.com),也可以是包含必填字段的网络表单,这些表单字段与您的计划政策相关联或位于同一页面。无论采用哪种格式,您都最好让黑客知道您希望以哪种格式接收报告。请注意,即使要求黑客以特定格式提交报告,也并不能保证一定会这样做,但提出请求也无妨。下例说明了您可以在报告提交表单中要求提供的信息:

标题:[请添加一行问题说明,例如“mail.example.com 中的 XSS”
导致会话被盗]

摘要:[请添加关于此漏洞及其重要性的简要说明。例如,由于缺少转义,您可以向其他用户发送一封包含 XSS 载荷的电子邮件,让攻击者能够窃取其他用户的包含会话信息的 Cookie。这样一来,攻击者就能登录受害者的帐号。] 重现步骤:[请添加有关如何重现漏洞的分步说明。]
1.
2.
3.

攻击场景和影响:[攻击者可能会如何利用此漏洞?此
问题对安全性有何影响?] 补救建议:[可选,如果您对如何解决此问题或补救有任何建议,请在此处添加。]