ACSC - 基本八项成熟度模型 - 2023 年指南审查

• 在工作站上禁止执行操作系统、Web 浏览器和电子邮件客户端使用的标准用户配置文件和临时文件夹中的可执行文件、软件库、脚本、安装程序、编译的 HTML、HTML 应用和控制面板小程序。

• 在工作站和面向互联网的服务器上实施应用控制。
• 应用控制仅允许执行组织批准的可执行文件、软件库、脚本、安装程序、编译的 HTML、HTML 应用和控制面板小程序。
• 记录工作站和面向互联网的服务器上允许和阻止的执行事件。

• 在工作站和服务器上实施应用控制。
• 应用控制仅允许执行组织批准的可执行文件、软件库、脚本、安装程序、编译的 HTML、HTML 应用、控制面板小程序和驱动程序。
• 实施 Microsoft“建议的阻止规则”。实施 Microsoft“建议的驱动程序阻止规则”。
• 每年或更频繁地验证应用控制规则集。
• 集中记录工作站和服务器上允许和阻止的执行事件。
• 事件日志受到保护，不会被擅自修改和删除。监控事件日志，查看是否存在入侵迹象，并在检测到任何入侵迹象时采取措施。

生产环境中实用程序的使用受到限制和控制。所有服务器都使用我们的集中式 puppet 配置系统进行配置，以符合我们的标准操作环境，包括从默认映像和关键软件包更新中移除部分软件包。所有服务器角色对传入的网络请求都默认为全部拒绝，而部分端口仅面向其他需要访问该端口以获取其功能的服务器角色开放。Atlassian 的企业网络与我们的生产网络是隔离的，我们的计算机映像经过强化，只允许必要的端口和协议。所有生产系统目前都托管在我们的云提供商的美国地区。在经过强化的虚拟私有云网络 (VPC) 之外传输的所有数据均通过行业标准通道进行加密。
此外，所有生产服务器上都安装了 IDS 系统，其中包括对生产系统文件或配置的任何更改以及异常安全事件进行实时监控和发出警报。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。至少每天使用一次漏洞扫描仪，以发现面向互联网的服务中缺少的针对漏洞的补丁或更新。
• 至少每两周使用一次漏洞扫描仪，以发现办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中缺少的针对漏洞的补丁或更新。
• 针对面向互联网的服务中漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中漏洞的补丁、更新或其他供应商缓解措施在发布后一个月内应用。
• 删除供应商不再支持的面向互联网的服务、办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件、Adobe Flash Player 和安全产品。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。
• 至少每天使用一次漏洞扫描仪，以发现面向互联网的服务中缺少的针对漏洞的补丁或更新。
• 至少每周使用一次漏洞扫描仪，以发现办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中缺少的针对漏洞的补丁或更新。
• 至少每两周使用一次漏洞扫描仪，以发现其他应用中缺少的针对漏洞的补丁或更新。
• 针对面向互联网的服务中漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用。
• 针对其他应用中漏洞的补丁、更新或其他供应商缓解措施在发布后一个月内应用。
• 删除供应商不再支持的面向互联网的服务、办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件、Adobe Flash Player 和安全产品。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。
• 至少每天使用一次漏洞扫描仪，以发现面向互联网的服务中缺少的针对漏洞的补丁或更新。
• 至少每周使用一次漏洞扫描仪，以发现办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中缺少的针对漏洞的补丁或更新。
• 至少每两周使用一次漏洞扫描仪，以发现其他应用中缺少的针对漏洞的补丁或更新。
• 针对面向互联网的服务中漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对办公效率套件、Web 浏览器及其扩展程序、电子邮件客户端、PDF 软件和安全产品中漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对其他应用中漏洞的补丁、更新或其他供应商缓解措施在发布后一个月内应用。
• 移除供应商不再支持的应用。

对于我们提供的所有产品和服务，我们都有广泛的缺陷修复流程（利用我们自己的产品 Jira，它可以捕获问题并帮助我们管理解决请求）。支撑这一点的是我们遵守的众多安全缺陷修复政策、咨询服务和 SLO。我们通过支持频道、缺陷赏金计划和 security@atlassian.com 接收缺陷报告。请访问我们的 Trust Center，了解有关安全缺陷修复 SLO 的更多信息。

有关我们安全测试方法的更多信息，也请访问我们的 Trust Center：外部安全测试方法

我们的 Atlassian 安全团队使用多种方法来检测内部和外部基础架构中的漏洞。Jira 请求单是为跟踪和修复目的而创建的，到期时间是按照漏洞的严重性和来源根据我们的 SLO 分配的。我们有一个持续的流程，向系统负责人发出已识别漏洞的请求单，我们的安全管理团队会审查所有报告的漏洞并确保对其采取措施。

• 对于没有明确业务需求的用户，禁用 Microsoft Office 宏。
• 禁止在来自互联网的文件中使用 Microsoft Office 宏。
• 启用 Microsoft Office 宏防病毒扫描。
• 用户无法更改 Microsoft Office 宏安全设置。

• 对于没有明确业务需求的用户，禁用 Microsoft Office 宏。
• 禁止在来自互联网的文件中使用 Microsoft Office 宏。启用 Microsoft Office 宏防病毒扫描。
• 禁止 Microsoft Office 宏调用 Win32 API。
• 用户无法更改 Microsoft Office 宏安全设置。
• 记录允许和阻止的 Microsoft Office 宏执行事件。

• 对于没有明确业务需求的用户，禁用 Microsoft Office 宏。
• 只允许执行在沙盒环境、可信位置运行或由可信发布者进行数字签名的 Microsoft Office 宏。
• 只有负责验证 Microsoft Office 宏不含恶意代码的授权用户才能在可信位置写入和修改内容。
• 无法通过消息栏或 Backstage 视图启用由不可信的发布者数字签名的 Microsoft Office 宏。
• 每年或更频繁地验证 Microsoft Office 的可信发布者列表。
• 禁止在来自互联网的文件中使用 Microsoft Office 宏。
• 启用 Microsoft Office 宏防病毒扫描。
• 禁止 Microsoft Office 宏调用 Win32 API。
• 用户无法更改 Microsoft Office 宏安全设置。
• 集中记录允许和阻止的 Microsoft Office 宏执行事件。
• 事件日志受到保护，不会被擅自修改和删除。
• 监控事件日志，查看是否存在入侵迹象，并在检测到任何入侵迹象时采取措施。

Atlassian 与第三方分包商合作，提供网站、应用开发、托管、维护、备份、存储、虚拟基础架构、支付处理、分析和其他服务。这些服务提供商可能会以向我们提供这些服务为目的来访问或处理 PII。Atlassian 在处理之前会通过通知向其相关客户披露可能会用于处理其 PII 的任何分包商。在 Atlassian 辅助处理商页面上提供了与 Atlassian 合作的外部分包商列表：数据辅助处理商列表。在此页面上，邀请访客订阅 RSS 源，以便在我们添加新的 Atlassian 辅助处理商时收到通知。

我们已经为我们的 Mac 笔记本电脑机群实施了集中式系统管理解决方案（移动设备管理）。
我们已经为我们的 Windows 端点和智能手机实施了移动设备管理解决方案 (VMware Workplace ONE)。

• Web 浏览器不处理来自互联网的 Java 内容。
• Web 浏览器不处理来自互联网的 Web 广告。
• Internet Explorer 11 不处理来自互联网的内容。
• 用户无法更改 Web 浏览器安全设置。

• Web 浏览器不处理来自互联网的 Java 内容。
• Web 浏览器不处理来自互联网的 Web 广告。
• Internet Explorer 11 不处理来自互联网的内容。
• 已实施 ACSC 或供应商提供的针对 Web 浏览器的加固指南。
• 用户无法更改 Web 浏览器安全设置。
• 禁止 Microsoft Office 创建子进程。
• 禁止 Microsoft Office 创建可执行内容。
• 禁止 Microsoft Office 向其他进程注入代码。
• Microsoft Office 已配置为阻止激活 OLE 软件包。
• 已实施 ACSC 或供应商提供的针对 Microsoft Office 的加固指南。
• 用户无法更改 Microsoft Office 安全设置。
• 禁止 PDF 软件创建子进程。
• 已实施 ACSC 或供应商提供的针对 PDF 软件的加固指南。
• 用户无法更改 PDF 软件安全设置。
• 已记录受阻止的 PowerShell 脚本执行事件。

• Web 浏览器不处理来自互联网的 Java 内容。
• Web 浏览器不处理来自互联网的 Web 广告。
• Internet Explorer 11 已禁用或移除。
• 已实施 ACSC 或供应商提供的针对 Web 浏览器的加固指南。
• 用户无法更改 Web 浏览器安全设置。
• 禁止 Microsoft Office 创建子进程。
• 禁止 Microsoft Office 创建可执行内容。
• 禁止 Microsoft Office 向其他进程注入代码。
• Microsoft Office 已配置为阻止激活 OLE 软件包。
• 已实施 ACSC 或供应商提供的针对 Microsoft Office 的加固指南。
• 用户无法更改 Microsoft Office 安全设置。
• 禁止 PDF 软件创建子进程。
• 已实施 ACSC 或供应商提供的针对 PDF 软件的加固指南。
• 用户无法更改 PDF 软件安全设置。
• .NET Framework 3.5（包括 .NET 2.0 和 3.0）已禁用或移除。
• Windows PowerShell 2.0 已禁用或移除。
• PowerShell 已配置为使用受限语言模式。
• 已集中记录受阻止的 PowerShell 脚本执行事件。
• 事件日志受到保护，不会被擅自修改和删除。
• 监控事件日志，查看是否存在入侵迹象，并在检测到任何入侵迹象时采取措施。

AWS Linux AMI 基础操作系统映像内部版本的端口、协议和服务有限。我们会将内部版本与当前 AMI 版本进行比较，以确保采用适当的设置。
我们的 Docker 映像在严格控制的变更环境中进行管理，以确保对所有变更进行适当的审查和批准。

出于保护用户的目的，我们的端点已经过加固，但我们并未限制对硬件端口的访问。

我们在 Jira/Confluence 公共边缘使用第三方 HTTP 代理产品，并已在其上实施第七层 HTTP 安全规则（也可以称之为 WAF，其功能实质上相同）。

• 对系统和应用的特权访问请求在首次提出时会进行验证。
• 特权帐户（不包括特权服务帐户）不能访问互联网、电子邮件和 Web 服务。
• 特权用户使用独立的特权和非特权操作环境。
• 非特权帐户无法登录特权操作环境。
• 特权帐户（不包括本地管理员帐户）无法登录非特权操作环境。

• 对系统和应用的特权访问请求在首次提出时会进行验证。
• 除非重新验证，否则对系统和应用的特权访问权限将在 12 个月后自动禁用。
• 对系统和应用的特权访问权限将在闲置 45 天后自动禁用。
• 特权帐户（不包括特权服务帐户）不能访问互联网、电子邮件和 Web 服务。
• 特权用户使用独立的特权和非特权操作环境。
• 特权操作环境未在非特权操作环境中虚拟化。
• 非特权帐户无法登录特权操作环境。
• 特权帐户（不包括本地管理员帐户）无法登录非特权操作环境。
• 管理活动通过跳板服务器执行。
• 本地管理员帐户和服务帐户的凭据具有长度长、唯一、不可预测和受管理的特点。
• 已记录特权访问事件。
• 已记录特权帐户和群组管理事件。

• 对系统和应用的特权访问请求在首次提出时会进行验证。
• 除非重新验证，否则对系统和应用的特权访问权限将在 12 个月后自动禁用。
• 对系统和应用的特权访问权限将在闲置 45 天后自动禁用。
• 对系统和应用的特权访问权限仅限于用户和服务履行职责所需的权限。
• 特权帐户不能访问互联网、电子邮件和 Web 服务。
• 特权用户使用独立的特权和非特权操作环境。
• 特权操作环境未在非特权操作环境中虚拟化。
• 非特权帐户无法登录特权操作环境。
• 特权帐户（不包括本地管理员帐户）无法登录非特权操作环境。
• 在管理系统和应用时采用实时管理。
• 管理活动通过跳板服务器执行。
• 本地管理员帐户和服务帐户的凭据具有长度长、唯一、不可预测和受管理的特点。
• 已启用 Windows Defender Credential Guard 和 Windows Defender Remote Credential Guard。
• 已集中记录特权访问事件。
• 已集中记录特权帐户和群组管理事件。
• 事件日志受到保护，不会被擅自修改和删除。
• 监控事件日志，查看是否存在入侵迹象，并在检测到任何入侵迹象时采取措施。

Atlassian 对需要这种访问权限才能履行工作角色和职责的人员保持限制。所有 1 级系统均通过 Atlassian 集中式单一登录 (SSO) 和目录解决方案进行管理。我们会根据这些个人资料，按照我们人力资源管理系统的工作流，为用户提供适当的访问权限。Atlassian 利用 MFA 来访问所有的 1 级系统。我们对虚拟机管理程序管理控制台和 AWS API 启用了双重身份验证，并对虚拟机管理程序管理功能的所有访问启用了每日审计报告。我们会每季度对虚拟机管理程序管理控制台和 AWS API 的访问列表进行一次审查。我们还在人力资源系统和身份存储之间保持八小时的同步。

在权利审查流程中，我们对关键服务保持每年进行两次审查的周期。定期向系统负责人验证内部企业用户帐户的用户访问权限。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。
• 至少每天使用一次漏洞扫描器，识别面向互联网服务的操作系统中缺失的针对漏洞的补丁或更新。
• 至少每两周使用一次漏洞扫描器，识别工作站、服务器和网络设备操作系统中缺失的针对漏洞的补丁或更新。
• 针对面向互联网服务的操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对工作站、服务器和网络设备操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后的一个月内应用。
• 供应商不再支持的操作系统将被替换。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。
• 至少每天使用一次漏洞扫描器，识别面向互联网服务的操作系统中缺失的针对漏洞的补丁或更新。
• 至少每周使用一次漏洞扫描器，识别工作站、服务器和网络设备操作系统中缺失的针对漏洞的补丁或更新。
• 针对面向互联网服务的操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对工作站、服务器和网络设备操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后的两周内应用。
• 供应商不再支持的操作系统将被替换。

• 至少每两周使用一次自动发现资产的方法，为随后的漏洞扫描活动提供资产检测支持。
• 在开展漏洞扫描活动时，使用带有最新漏洞数据库的漏洞扫描仪。
• 至少每天使用一次漏洞扫描器，识别面向互联网服务的操作系统中缺失的针对漏洞的补丁或更新。
• 至少每周使用一次漏洞扫描器，识别工作站、服务器和网络设备操作系统中缺失的针对漏洞的补丁或更新。
• 针对面向互联网服务的操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 针对工作站、服务器和网络设备操作系统漏洞的补丁、更新或其他供应商缓解措施在发布后的两周内应用，如果发生攻击事件，则在 48 小时内应用。
• 使用最新版本或前一版本的操作系统。供应商不再支持的操作系统将被替换。

对于我们提供的所有产品和服务，我们都有详尽的缺陷修复流程（利用我们自家产品 Jira 来捕获问题并帮助我们管理问题解决请求）。为此提供支持的是我们遵守的众多安全缺陷修复政策、咨询服务和 SLO。我们通过支持通道、缺陷赏金计划和 security@atlassian.com 接收缺陷报告。有关安全缺陷修复 SLO 的更多信息，请访问我们的 Trust Center。

有关我们安全测试方法的更多信息，也请访问我们的 Trust Center，网址为：外部安全测试方法

我们的 Atlassian 安全团队使用多种方法来检测内部和外部基础设施中的漏洞。Jira 工作单是为跟踪和修复目的而创建的，到期时间是按照漏洞的严重性和来源根据我们的 SLO 分配的。我们有一个持续的流程，用以向系统负责人发出已识别漏洞的工作单，我们的安全管理团队会审查报告的所有漏洞并确保对其采取措施。

• 组织的用户在对组织面向互联网的服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织非敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证（如果可用）。
• 针对以下情形默认启用多重身份验证：组织的非组织内部用户对组织面向互联网的服务进行身份验证（但他们可以选择退出）。

• 组织的用户在对组织面向互联网的服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织非敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证（如果可用）。
• 针对以下情形默认启用多重身份验证：组织的非组织内部用户对组织面向互联网的服务进行身份验证（但他们可以选择退出）。
• 在对系统的特权用户进行身份验证时使用多重身份验证。
• 多重身份验证使用：用户拥有的某样东西和用户知道的某项信息，或者用户拥有的由用户知道的某项信息或用户本身的生物特征解锁的某样东西。
• 已记录成功和不成功的多重身份验证事件。

• 组织的用户在对组织面向互联网的服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证。
• 组织的用户在向处理、存储或传送组织非敏感数据的面向互联网的第三方服务进行身份验证时使用多重身份验证（如果可用）。
• 针对以下情形默认启用多重身份验证：组织的非组织内部用户对组织面向互联网的服务进行身份验证（但他们可以选择退出）。
• 在对系统的特权用户进行身份验证时使用多重身份验证。
• 在对重要数据存储库的用户进行身份验证时使用多重身份验证。
• 多重身份验证可以抵御网络钓鱼，并且使用：用户拥有的某样东西和用户知道的某项信息，或者用户拥有的由用户知道的某项信息或用户本身的生物特征解锁的某样东西。
• 已集中记录成功和不成功的多重身份验证事件。
• 事件日志受到保护，不会被擅自修改和删除。
• 监控事件日志，查看是否存在入侵迹象，并在检测到任何入侵迹象时采取措施。

关于 Confluence 和 Jira，它们均支持针对个人帐户启用多重身份验证。有关如何启用多重身份验证的更多信息，请参阅：强制执行双重验证

截至 2022 年 2 月，BBC 仍然支持 2FA，并且总体上已与 Atlassian Access 集成并支持通过 Access 提供的其他功能。可以使用 Atlassian Access 在组织级别设置强制性多重身份验证。有关更多信息，请参阅：强制执行双重验证

关于特定产品

Bitbucket 支持使用基于 MFA 的 SSO 选项。有关更多信息，请参阅：强制执行双重验证 | Bitbucket Cloud

Halp 通过 Slack OAuth 和 MS Teams 使用 SSO。Slack 和 MS Teams 提供多种多重身份验证选项。有关更多信息，请参阅：SAML 单一登录和 Azure AD Connect：无缝单一登录

Opsgenie 支持使用基于 MFA 的 SSO 选项。有关更多信息，请参阅：为 Opsgenie 配置 SSO

Statuspage 支持使用基于 MFA 的 SSO 选项。

Trello 支持多重身份验证。有关如何启用多重身份验证的更多信息，请参阅：为 Trello 帐户启用双重身份验证。

Jira Align 支持使用基于 MFA 的 SSO 选项。

• 按照业务连续性要求以特定频率和保留期限执行和保留对重要数据、软件和配置设置的备份。
• 重要数据、软件和配置设置的备份同步进行，以便能够还原到共同的时间点。
• 重要数据、软件和配置设置的备份以安全、弹性方式保留。
• 在灾难恢复练习中，对将备份中的重要数据、软件和配置设置还原到共同时间点进行测试。
• 非特权帐户无法访问属于其他帐户的备份。
• 非特权帐户不能修改和删除备份。

• 按照业务连续性要求以特定频率和保留期限执行和保留对重要数据、软件和配置设置的备份。
• 重要数据、软件和配置设置的备份同步进行，以便能够还原到共同的时间点。
• 重要数据、软件和配置设置的备份以安全、弹性方式保留。
• 在灾难恢复练习中，对将备份中的重要数据、软件和配置设置还原到共同时间点进行测试。
• 非特权帐户无法访问属于其他帐户的备份。
• 特权帐户（不包括备份管理员帐户）无法访问属于其他帐户的备份。
• 非特权帐户不能修改和删除备份。
• 特权帐户（不包括备份管理员帐户）不能修改和删除备份。

• 按照业务连续性要求以特定频率和保留期限执行和保留对重要数据、软件和配置设置的备份。
• 重要数据、软件和配置设置的备份同步进行，以便能够还原到共同的时间点。
• 重要数据、软件和配置设置的备份以安全、弹性方式保留。
• 在灾难恢复练习中，对将备份中的重要数据、软件和配置设置还原到共同时间点进行测试。
• 非特权帐户无法访问属于其他帐户的备份，也无法访问属于自己帐户的备份。
• 特权帐户（不包括备份管理员帐户）无法访问属于其他帐户的备份，也无法访问属于自己帐户的备份。
• 非特权帐户不能修改和删除备份。特权帐户（包括备份管理员帐户）在备份保留期内不能修改和删除备份。

Atlassian 会维护数据保留和销毁标准，该标准规定了我们需要保留不同类型数据的时间。我们会根据《Atlassian 数据安全和信息生命周期政策》对数据进行分类，并在此基础上实施相应的控制措施。
对于客户数据，在 Atlassian 合同终止后，属于客户团队的数据将从实时生产数据库中移除，直接上传到 Atlassian 的所有文件附件将在 14 天内移除。团队的数据将保留在加密备份中，直到这些备份超出 60 天的备份保留期，并根据我们的 Atlassian 数据保留政策进行销毁。如果需要在请求删除数据后的 60 天内还原数据库，运营团队将在实时生产系统完全还原后尽快重新删除数据。有关更多信息，请参阅：跟踪存储和跨产品移动数据