Close

我们的外部安全测试方法


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

我们的理念和方法

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

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

持续的安全保障

渗透测试

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

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

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

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

缺陷赏金计划

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

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

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

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

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

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

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

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

Marketplace 应用 - Marketplace 应用不包含在主要 Atlassian 缺陷赏金计划中。但是,Marketplace 应用包含在 Atlassian 主办的单独缺陷赏金计划中,例如漏洞披露计划Atlassian 构建的应用缺陷赏金计划

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

在我们看来,缺陷赏金计划为评估我们的产品和服务安全性提供了更为有效、更经济的方法,但我们也理解,您可能希望自行测试安全性。我们允许客户执行安全评估(渗透测试、漏洞评估等),但有一个要求,您必须遵守一些规则来确保我们所有人的安全。

漏洞报告

如果您确实发现了问题并想向 Atlassian 提交报告,请参阅有关如何报告漏洞的说明

Atlassian 的价值观之一就是开放的公司,绝无虚言,同时我们认为漏洞披露就是这一价值观的组成部分。我们的目标是在相关的服务级别目标 (SLO) 政策内修复安全漏洞。在问题得到修复并发布到生产环境后,我们接受通过缺陷赏金计划提出的披露请求。但是,如果报告包含任何客户数据,则该请求将被拒绝。如果您打算通过我们的缺陷赏金计划之外的途径进行披露,那么我们会要求您向我们发出合理的通知,然后等待关联的 SLO 通过。

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

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

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

衡量正确的指标

我们制定了安全缺陷修复政策,该政策根据严重性和产品,规定了漏洞修复服务级别目标 (SLO) 的时间范围。在评估漏洞时,我们使用了通用漏洞评分系统,这样有助于向客户传达漏洞严重性。

此外,我们的目标是提高发现和利用产品中漏洞的代价。因此,我们使用缺陷赏金计划来量化成本。随着我们安全状况的改善,通过我们缺陷赏金计划识别出的缺陷数量应该会逐渐变少。届时,如果我们希望继续收到质量报告,就需要提高我们愿意为此类缺陷支付的赏金。例如,如果查找 3,000 美元奖金的漏洞的最终结果是得不偿失(因为所需投入的价值超过 3,000 美元),我们就等于提高了发现此漏洞的代价。

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

总结

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

下载最新的缺陷赏金报告

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

下载评估报告 (LoA)

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