连接我们的安全流程
第一部分——功能模块
在本篇博客中，我想探讨当前对安全功能的分解理解，包括它们的输入、输出和核心内部流程。随着我学习的深入，这些观点可能会发生变化，欢迎提出任何想法和反馈！
关于更权威的详细文档，请参考：https://www.ncsc.gov.uk/collection/building-a-security-operations-centre/operating-model/the-target-operating-model（感谢Sevan Hayrapet的建议）
在第一部分中，我将讨论这些功能模块，然后在第二部分计划撰写我的个人目标，以及如何利用我学到的DevOps知识（可能还存在误解！）——如Azure DevOps——将所有这些零散部分连接起来，实现一切代码化/工作项化。
功能模块
在网络安全领域，存在多种互补的功能模块，各自在帮助组织保持安全方面发挥着作用。这些功能不一定意味着不同的人员团队，即使在安全团队只有一人的情况下，这些功能某种程度上仍然存在。
我将这些功能分解为输入、输出和内部流程——以及我对它们应该包含什么内容及如何运作的理解。如果我遗漏了非常明显的内容或存在错误，敬请谅解——欢迎评论！
威胁情报
之前我写过类似的博客文章：https://medium.com/@martinconnarty/threat-intelligence-lead-content-creation-782a0ac9bbcd
其前提是，高层级的威胁情报应该是初始驱动力，告诉我们应该关注什么。
输入
- 外部报告——任何描述新威胁TTP、攻击者详情和IOC的威胁报告/博客文章等
- 业务背景——关键资产和其他业务优先级的文档，以及业务运作的高层概述
- 系统背景——描述业务中使用的IT系统的CMDB或其他来源
- 内部风险——应记录易受攻击的软件和其他风险
流程
- 评估——上述输入为钻石模型的各个角落提供信息，有助于提炼和优先处理威胁
- 钻石模型威胁狩猎——通过基于已知威胁和风险进行支点分析，或使用其他威胁狩猎方法（如假设引导），我们可以通过发现未知威胁来倍增已知信息的价值
输出
- 威胁档案——详细描述威胁的文档，再次松散地围绕钻石模型构建（尽管有时能力/TTP将是主要焦点）。这可能更常被称为用例。
漏洞管理
漏洞管理与威胁情报密切合作，后者可以告知优先级。他们的目标是分类、优先处理并推动业务中漏洞的修复。可以说，这应该扩展到CVE之外，包括拥有和推动所有安全建议。
输入
- 外部报告——如CVE报告的漏洞
- 系统背景——描述业务中使用的IT系统的CMDB或其他来源
流程
- 评估——漏洞与从系统背景中了解的系统对齐
- 优先处理——基于上述评估，漏洞应根据部署缓解措施的紧迫性进行优先处理
- 管理——与业务和系统所有者合作，帮助管理和缓解漏洞。这通常需要一定程度的委派业务权限才能有效
输出
- 内部风险——这就是记录这些漏洞及其所代表的业务风险的方式。它们可以由合适的利益相关者拥有
检测工程/内容工程
检测工程的目标是将已知威胁转化为安全运营团队可操作的稳健检测。
输入
- 威胁档案——详细描述威胁的文档，再次松散地围绕钻石模型构建（尽管有时能力/TTP将是主要焦点）。这可能更常被称为用例。
流程
- 分析——理解威胁的不同变体，以及每种变体可能如何被发现和在何处发现。他们可能需要与平台工程合作获取所需的数据源
- 构建检测——基于威胁档案中强调的分析威胁构建检测。它们应尝试捕获技术可能表现的各种方法，然后进行测试以确保有效性
- 构建/对齐剧本响应——如果检测真实触发，响应分析师需要能够快速获得正确信息以进行分类、调查并随后响应威胁。基于威胁本身以及检测，这些方法可能有所不同，使用的具体方法也可能不同。我使用了RE&CT框架的轻微变体https://github.com/atc-project/atc-react，它将剧本分解为覆盖SANS六个步骤的具体行动：准备、识别、遏制、根除、恢复和经验教训。我相信它可以更深一层，给出具体方法，如脚本或一系列工具特定步骤
输出
- 威胁档案——应更新威胁档案以突出显示已为该威胁实施的检测
- 检测——这些是检测本身。它们应被视为代码并进行版本控制和管理。它们可以用许多不同的方式表示，但我认为像Splunk ContentCTL或Sigma规则中找到的基本YAML结构是好的
- 剧本/响应行动/响应方法——这些详细说明了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应行动（如阻止URL），而响应行动又有响应方法（如使用此API调用）
平台工程
输入
- 系统背景——描述业务中使用的IT系统的CMDB或其他来源
- 数据需求——描述检测威胁所需的规范化数据的文档
流程
- 获取数据——基于系统背景，平台工程需要努力提取检测工程所需的相关数据
- 规范化数据——数据应尽可能过滤和规范化，以允许检测（理想情况下）与底层技术无关。这有助于确保检测规则的 longevity，当该技术可能更新或替换时
- 构建/维护——系统需要维护和监控，以确保它们仍以预期格式提供数据
输出
- 规范化数据——可供检测工程使用的规范化数据的详细信息
安全运营
输入
- 检测——严格来说，这是检测规则触发后对威胁的实际检测
- 剧本/响应行动/响应方法——这些详细说明了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应行动（如阻止URL），而响应行动又有响应方法（如使用此API调用）
- 威胁档案——详细描述威胁的文档，再次松散地围绕钻石模型构建（尽管有时能力/TTP将是主要焦点）。这可能更常被称为用例。
流程
- 分类——对已触发的检测警报进行快速评估和优先处理。这可以通过适当剧本中详细的丰富来源来告知
- 调查——再次使用适当的剧本辅助调查，以及威胁档案告知背景，安全运营将调查检测突出的潜在泄露的广度和深度
- 响应——再次使用适当的剧本，可以遵循安全运营可以采取的响应。此时这可能涉及与业务合作，并可能包括任何存在的业务事件响应能力
- 经验教训——这是对响应检测过程中学到的一切的回顾。这可能包括流程改进、识别的其他威胁或对业务的建议
输出
- 经验教训——记录新威胁、检测调整建议、流程改进或业务建议
紫队/红队
紫队/红队有助于锐化所有其他功能，并可以帮助确保实践反映理论。
输入
- 检测——这些是检测本身，可以由紫队/红队验证
- 威胁档案——详细描述威胁的文档，再次松散地围绕钻石模型构建（尽管有时能力/TTP将是主要焦点）
- 业务背景——关键资产和其他业务优先级的文档，以及业务运作的高层概述
- 系统背景——描述业务中使用的IT系统的CMDB或其他来源
流程
- 识别风险——紫队/红队可以努力理解业务和系统背景，以测试和揭示新风险
- 验证流程——应测试检测、剧本和其他流程，以确保它们按预期工作。例如，威胁可能突出了导致检测的特定技术以及随后调查它的适当剧本。对同一技术的紫队/红队测试可以证明这些按预期工作
输出
- 风险——已识别的额外风险，如新漏洞
- 改进——流程改进建议
治理、风险与合规（GRC）
诚然这不是我的强项/领域（所以请建议我错在哪里！）——但我的理解是，GRC充当业务和安全之间的接口，基于已知风险和最佳实践提供建议和指导，然后进行相应管理。
输入
- 风险——风险集合，如漏洞，以及所有者和缓解/修复计划的详细信息
- 外部来源——通常正在实施的安全标准源自组织外部。这些通常以框架的形式出现
流程
- 消化和优先处理——选择所需的合规框架以及已知风险，然后将它们转化为业务优先处理、拥有和可操作的项
- 管理——与业务合作，帮助拥有、实施和修复/缓解这些已知风险或合规项
输出
- 业务背景——特别是关于合规状态和已知风险。理解这一点可以帮助威胁情报团队重新调整优先级；例如，如果风险项无法缓解或修复，那么检测将是更高优先级
- 安全指导——基于已知威胁以及合规/风险项的指导。这可用于推动业务决策，如更战术性的变更（如实施AD策略），也包括更长期、更战略性的架构决策（如将服务迁移到云中）