成熟度模型中的建筑安全 15 15

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。

组织中的安全相关方会就数据分类方案达成一致，并使用该方案根据所处理的数据类型或调用的服务来清点软件、交付工件（例如容器）及相关的持久数据存储，无论部署模型如何（例如本地或云端）。可能有多种分类方案——一种方法是例如重点关注个人身份信息（PII）。根据所使用的方案和软件，最简单的方法可能是先对数据存储库进行分类（参见 [CP2.1]），然后根据应用程序使用的存储库来推导其分类。其他方法包括根据知识产权保护、信息泄露影响、攻击暴露、与 GDPR 的相关性以及地理边界来对数据进行分类。SSG识别潜在攻击者，以便了解并开始记录他们的动机和能力。这一定期演练的结果可能是一套攻击者档案，其中包括攻击者类别的概述，以及对值得关注的个体更详细的描述，这些档案可用于端到端设计审查（参见 [AA1.2]）。在某些情况下，可能会与第三方供应商签约以提供这些信息。具体的、有上下文的攻击者信息几乎总是比从他人列表中复制的通用信息更有用。此外，仅将世界划分为内部人员和外部人员的列表不会产生有用的结果。识别攻击者还应考虑组织不断发展的软件供应链、攻击面、理论上的内部攻击者以及合同员工。SSG 通过了解新型攻击和漏洞，确保组织保持领先地位，并将这些信息适应于组织的需求。攻击情报必须能够转化为可操作和有用的信息，供各种用户使用，这些用户可能包括开发人员、测试人员、DevOps、信息安全运维以及可靠性工程师等。在许多情况下，订阅商业服务可以为收集与应用程序、API、容器化、编排、云环境等相关的基本攻击情报提供一种合理的方式。参加技术会议并监控攻击者论坛，然后将这些信息与组织内部发生的情况相关联（可能通过使用自动化挖掘操作日志和遥测数据），有助于每个人更多地了解新兴的漏洞利用情况。SSG 与利益相关者合作，构建与潜在攻击者相关的攻击模式和滥用案例（见 [AM1.3]）。攻击模式通常包含有关目标资产、攻击者、目标以及使用的技术的详细信息。这些资源可以从零开始构建，也可以从标准集合构建，例如 MITRE ATT&CK 框架，SSG 会根据自身的攻击案例进行补充，以为组织准备 SSDL 活动，如设计审查和渗透测试。例如，一个关于针对设计不良的云原生应用的攻击的故事，可能会导致一种容器化攻击模式，从而促使新型测试的产生（参见 [ST3.5]）。如果公司跟踪与特定攻击相关的欺诈和金钱损失，这些信息反过来可以用于优先考虑构建攻击模式和滥用案例的过程。由于软件架构（例如零信任、云原生、无服务器）、攻击者和技术的不断变化，组织可能需要随着时间推移不断调整其攻击模式和滥用案例创建的优先级以及内容。为了最大化从这些往往代价不菲的经验教训中获得的收益，SSG 会收集并发布有关针对组织软件的攻击案例的故事。无论是成功还是失败的攻击都可能值得关注，讨论有关软件攻击的历史信息还有助于将软件安全建立在企业的实际情况之上。这在培训课程中尤其有用（见 [T2.8]），可以帮助避免过于依赖针对其他组织最常见漏洞列表或过时平台攻击的泛泛方法。对新系统开发者隐藏或过度净化关于攻击的信息，无法从负面事件中获得任何积极的收益。组织内部有一个互动论坛，SSG、冠军、事件响应团队和其他人员在这里讨论攻击及攻击方法。讨论的目的是向所有人传达攻击者的视角，因此在这里包括所有成功的攻击都是有用的，无论攻击来源如何，例如供应链、内部、顾问或漏洞赏金贡献者。SSG通过一个内部沟通渠道（见[T2.12]）增强了论坛，鼓励订阅者讨论公开已知事件的最新信息。对与公司相关的攻击和漏洞进行剖析尤其有用，因为它们能促进关于软件、基础设施及其他防护措施的讨论。简单地转载公共邮件列表上的内容，并不能实现像积极且持续的讨论那样的好处，而对开发代码和配置的人隐藏的闭门讨论也无法达到同样的效果。每个人都应该可以自由地提问并了解漏洞和利用手段。一个研究小组致力于识别和减轻新型攻击的影响，并与相关方分享他们的知识。识别并不总是需要原创研究——该小组可能会在他人发现的想法基础上进行扩展。在内部进行这项研究对于新技术和新配置的早期采用者尤其重要，这样他们就可以在攻击者发现之前发现潜在的弱点。一种方法是在以目标为导向的红队演练中创建模拟持续攻击者的新攻击方法（参见 [PT3.1]）。这不是一个渗透测试团队发现已知类型漏洞的新实例，而是一个研究小组，专注于创新攻击方法和缓解手段。示例缓解手段包括测试用例、静态分析规则、攻击模式、标准以及政策变更。一些公司通过使用漏洞赏金计划或其他协调披露的方式，为研究人员提供时间来跟进他们的发现（参见 [CMVM2.4]）。其他公司则允许研究人员在像 DEF CON 这样的会议上发布他们的发现，以造福所有人。实施技术控制，提供工程团队正在部署的各种网络、机器、软件及相关基础设施资产的持续更新视图。为了帮助确保适当的覆盖范围，SSG 会与工程团队（包括潜在的影子 IT 团队）合作，了解编排、云配置以及其他自助式软件交付方式，以确保适当的监控。这种监控需要专业的努力——普通的系统、网络和应用日志记录与分析是不够的。成功可能需要多管齐下的方法，包括使用编排和虚拟化元数据、查询云服务提供商的 API，以及从外部进行爬取和抓取。SSG 为工程师、测试人员和事件响应团队提供自动化工具，以模拟攻击者将要执行的操作。例如，由内部研究小组识别的一种新攻击方法（见 [AM2）。8]）或者披露方可能需要一个新工具，因此SSG可能通过冠军角色打包该工具并分发给测试人员。这里的想法是将攻击能力推动到超出典型商业工具和产品的范围，然后使其他人容易使用这些知识和技术。模拟攻击者，尤其是攻击链，几乎总是需要根据公司特定的技术栈、基础设施和配置来定制工具。当技术栈和编程语言的发展速度超过供应商创新的速度时，内部创建工具和自动化可能是最好的前进方式。在DevOps领域，这些工具可能由工程团队创建，并直接嵌入到工具链和自动化中（见 [ST3.6]）。SSG 通过收集并提供与组织技术相关的攻击知识，促进特定技术攻击模式的创建。例如，如果组织的云软件依赖于某个云供应商的安全设施（例如密钥和机密管理)，SSG 或相关的主题专家可以帮助列出加密包的怪异之处以及如何可能被利用。与安全前沿直接相关的攻击模式（例如 AI、无服务器）在这里也可能很有用。通常，最简单的方法是从现有的通用攻击模式开始，以创建所需的特定技术攻击模式，但仅仅在通用模式名称的末尾加上“用于微服务”，例如，是不够的。SSG会定期梳理不断增长的适用攻击类型清单，创建一个优先级的短名单——前N项——然后使用该名单推动变更。这个初始列表几乎总是结合来自组织内外的多个来源的输入。一些组织根据潜在的商业损失来优先排序列表，而其他组织可能根据防止对其软件的成功攻击来优先排序。前 N 名列表不需要频繁更新，攻击可以进行粗略分类。例如，SSG 可能每年进行两次头脑风暴，创建组织应当准备应对的攻击列表，分别标注为“现在”、“不久将来”和“未来某天”。