Close

我们的外部安全测试方法


Atlassian 定期请客户提供渗透测试报告,以求保证落实我们为识别(并修复)Atlassian 产品和 Atlassian Cloud 中安全漏洞而制定的流程。我们的外部安全测试方法围绕“持续保障”的概念构建,采用的不是时间点渗透测试,而是利用了众包缺陷赏金计划的持续测试模型。

我们的理念和方法

Atlassian 以我们的价值观而闻名于世,这些价值观真真切切地影响着我们所做的一切,包括我们的安全测试方法。在实践中,我们的价值观促使我们采用以下理念和方法:

  • 缺陷是开发过程中不可避免的一部分。问题不在于我们有没有缺陷,而是我们能够以多快的速度、多高的效率找到并解决它们。这并不表示我们喜欢缺陷,或者不会持续革新方法来降低其发生频率和严重程度;其真正的含义在于:涉及到软件缺陷时,否认并不是有效的做法。
  • 我们的目标是提高他人发现和利用我们产品和服务中漏洞的代价。通过迅速识别和解决问题,提高发现安全漏洞的经济成本。提高利用漏洞所需的代价,使不良分子需要花费更多时间、掌握更多知识和投入更多资源才能利用漏洞,从而降低他们的投资回报。回报变得足够低时,就会令人却步或没有吸引力。
  • 我们支持并采用行业标准。对术语和方法进行标准化,有助于我们确保面面俱到,也能帮助客户了解如何理解我们的工作。例如,使用通用漏洞评分系统 (CVSS) 对漏洞进行通用的评级,可确保我们与客户双方都清楚特定漏洞的严重程度。同时,我们也遵循 ISO 27001云安全联盟 (CSA) 规定的漏洞管理流程。
  • 外部安全研究人员是我们团队的重要延伸。如果 Atlassian 产品存在漏洞,那么尽快找到并修复漏洞符合所有人的利益,不仅是我们自身,也包括我们的客户。Atlassian 推出了现金奖励的缺陷赏金计划,以此激励外部研究人员找出我们产品中的漏洞。有了外部安全研究人员的支援,我们就能以远超传统的方式扩展我们的团队!
  • 我们的安全测试计划保持公开透明。缺陷赏金计划提供了有关我们发现的缺陷的统计数据。我们会公开我们努力解决安全缺陷的速度,也会尽可能公布测试摘要报告

持续的安全保障

渗透测试

我们邀请专业安全咨询机构对高风险产品和基础设施进行渗透测试。这可能是为我们搭建的新基础设施(例如我们的 Cloud 环境)、新的产品(例如 Trello),或基础架构重建(例如广泛使用微服务)。

在这些情况下,我们的渗透测试方法具有高度针对性和集中性。这样的测试通常是:

  • 白盒 - 我们的产品工程师向测试人员提供设计文档和简报,以支持他们的测试
  • 代码辅助 - 测试人员可以不受限地访问相关的代码库,以协助诊断测试期间的所有意外系统行为,并识别潜在的目标
  • 基于威胁 - 测试聚焦于特定的威胁场景,例如假设存在受感染的实例,并测试从该起点开始的横向移动

本页底部贴出了来自渗透测试合作伙伴的评估报告 (LoA),以供外部取用。测试人员在进行这些评估时可以访问广泛的内部信息,因此我们不提供完整的报告。这些系统和产品中的大多数随后会纳入我们公开的缺陷赏金计划,为客户提供他们期待的持续外部保证。这些评估的任何结果都将根据我们的公共安全漏洞 SLA 进行分类和补救。

缺陷赏金计划

我们的缺陷赏金计划Bugcrowd 主持,宗旨是确保我们的产品不断接受安全漏洞测试。这是我们外部安全测试计划的核心,也是大量研究、分析和比较各种测试模型的结果。

我们认为,由独立安全研究人员群体参与我们缺陷赏金计划能够提供最有成效的外部安全测试流程,原因如下:

  1. 缺陷赏金计划始终开放。渗透测试通常限定时间为几周时间。在真正敏捷的开发环境中,版本发布非常频繁,持续测试必不可少。
  2. 缺陷赏金计划有 60,000 多名潜在测试人员。渗透测试通常有 1 至 2 人参与。无论这一两人有多么出色,他们永远不会超过缺陷赏金计划参与者团体的总体能力。
  3. 缺陷赏金计划研究人员开发专门的工具,并且能够进行垂直(特定缺陷类型)和水平(特定赏金)处理。这种专业度为识别模糊但重大的漏洞提供了最大的机会。

我们将继续使用渗透测试和专业安全顾问来提供内部支持,但若需要覆盖广泛的外部计划,则缺陷赏金计划更加适合。我们相信,搭配使用多种方法能够最大限度提高发现漏洞的几率。

缺陷赏金计划涵盖了我们 25 种以上的产品或环境,涉及服务器产品、移动应用和 Cloud 产品等。有关报告的漏洞数量、平均响应时间和平均支出的详细信息,可在 Bugcrowd 网站上找到。另外,有 800 多名测试人员特地注册了我们的计划。

我们希望通过缺陷赏金计划识别的漏洞包括开放 Web 应用安全项目 (OWASP)Web 应用安全联盟 (WASC) 威胁列表中收录的常见类型。具体包括:

  • 跨实例数据泄露/访问
  • 远程代码执行 (RCE)
  • 服务器端请求伪造 (SSRF)
  • 跨站点脚本执行 (XSS)
  • 跨站请求伪造 (CSRF)
  • SQL 注入 (SQLi)
  • XML 外部实体攻击 (XXE)
  • 访问控制漏洞(不安全直接对象引用问题等)
  • 路径/目录遍历问题

作为我们开放和透明计划的一部分,欢迎大家访问我们的缺陷赏金计划页面,注册参加该计划并来考验我们。

漏洞报告

如果您在正常使用相关产品的过程中发现漏洞(而不是借助特定的系统测试行为来识别,那需要通过缺陷赏金计划才可),欢迎您联系 Atlassian 支持团队来告诉我们。我们会迅速响应提交的漏洞,并在调查和回应问题期间随时向询问方提供最新信息。

我们要求研究人员在公开披露问题之前先征求我们许可。Atlassian 会根据每份报告处理公开披露请求。只有报告的漏洞得以修复后,才会考虑公开披露请求。

我们安全测试计划以外的排除项

正如我们对所做的测试保持公开透明一样,我们也对自己不做或目前不支持的测试保持公开透明。以下各项不在我们的安全测试计划范围内:

Marketplace 应用 - 虽然 Marketplace 应用被严格排除在我们的缺陷赏金计划之外,但您可以通过漏洞披露计划提交安全事务。我们会转告收到的所有应用漏洞报告,但这不在奖赏资格范围内。

客户发起的测试 -

根据 Cloud 产品使用条款,我们现在允许客户发起的测试。我们致力于保持开放,并将继续定期发布我们缺陷赏金计划的统计数据。

在我们看来,缺陷赏金计划是评估我们产品和服务安全性的更有效、更经济的方法,但我们也理解,您可能希望自行测试安全性。我们允许客户执行安全评估(渗透测试、漏洞评估等),但有一个要求,您必须遵守一些规则来确保我们所有人的安全。如果您确实发现了问题并想提交报告,我们的网站上也提供了有关如何报告漏洞的说明

某些低风险漏洞类型 - 我们的产品是为了释放每个团队的潜力而开发的,而这需要协作。与枚举和信息收集相关的漏洞通常不视为重大风险。

衡量正确的指标

我们制定的缺陷修复政策可在产品团队和安全团队之间发挥内部服务级别协议 (SLA) 的作用。在对缺陷进行分类时,我们使用了通用漏洞评分系统CVSS 版本 3),它有助于向客户传达漏洞严重性。我们尽力在以下时限内解决安全问题:

  • 严重性为严重的缺陷(CVSS v2 分数 >= 8,CVSS v3 分数 >= 9)应于报告之日起 4 周内在相关产品中解决。
  • 严重性为的缺陷(CVSS v2 分数 >= 6,CVSS v3 分数 >= 7)应于报告之日起 6 周内在相关产品中解决。
  • 严重性为的缺陷(CVSS v2 分数 >= 3,CVSS v3 分数 >= 4)应于报告之日起 8 周内在相关产品中解决。

每年对这些时限进行重新评估,并根据不断变化的威胁环境按需调整。

此外,由于我们的目标是提高发现和利用产品中漏洞的代价,因此需要一种方法来量化所需的成本。我们将通过“赏金”引入的安全研究人员用作查找漏洞的代理人。简而言之,通过我们缺陷赏金计划识别出的缺陷数量应该会逐渐变少。届时,如果我们希望继续收到报告,就需要提高我们愿意为此类缺陷支付的赏金。如果查找 3,000 美元奖金的漏洞的最终结果是得不偿失(因为所需投入的价值超过 3,000 美元),我们就等于提高了发现此漏洞的代价。

换句话说,您应该会看到我们的赏金付款随着时间推移而增加。

总结

Atlassian 已围绕我们的缺陷赏金计划构建了一个成熟、开放且透明的外部安全测试计划。

想要深入了解?

这篇短文中提到了不少其他文档和资源,如果您想进一步了解我们的安全测试方法,我们鼓励您深入阅读这些文档和资源。

下载最新的缺陷赏金报告

以下报告中发现的任何安全漏洞都会在我们的内部 Jira 中进行跟踪,它们通过缺陷赏金计划的引入流程进入我们系统,而且来自缺陷赏金计划的任何发现也会根据我们的公共安全漏洞 SLA 进行分类和补救。

下载评估报告 (LoA)

以下报告中发现的任何安全漏洞都会在我们的内部 Jira 中进行跟踪,它们通过渗透测试报告流程进入我们的系统,而且来自这些评估的任何发现也会根据我们的公共安全漏洞 SLA 进行分类和补救。