连接我们的安全流程
第一部分 — 安全功能模块
在这篇博客文章中，我想讨论我对安全功能模块划分的当前理解，包括它们的输入、输出和核心内部流程。随着我学习的深入，这些观点可能会发生变化，欢迎提出任何想法和反馈！
关于更权威的文档，请参阅 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 的 6 个步骤：准备、识别、遏制、根除、恢复和经验总结。我相信它可以更深一层，给出具体的方法，如脚本或一系列工具特定步骤
输出
- 威胁档案 — 应更新威胁档案以突出显示已为该威胁实施的检测
- 检测 — 这些是检测本身。它们应被视为代码并进行版本控制和管理。它们可以以许多不同的方式表示，但我认为像 Splunk ContentCTL 或 Sigma 规则中找到的基本 YAML 结构是好的
- 剧本/响应动作/响应方法 — 这些详细说明了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应动作（例如阻止 URL），而响应动作又有响应方法（例如使用此 API 调用）
平台工程
输入
- 系统背景 — 描述业务中使用的 IT 系统的 CMDB 和/或其他来源
- 数据需求 — 描述检测威胁所需的规范化数据的文档
流程
- 获取数据 — 基于系统背景，平台工程将需要努力提取检测工程所需的相關数据
- 规范化数据 — 数据应尽可能过滤和规范化，以使检测（理想情况下）与底层技术无关。这有助于确保检测规则在技术更新或更换时的 longevity
- 构建/维护 — 系统需要浇水、喂养和监控，以确保它们仍以预期格式提供数据
输出
- 规范化数据 — 可供检测工程使用的规范化数据的详细信息
安全运营
输入
- 检测 — 严格来说，这是检测规则触发导致的威胁的实际检测
- 剧本/响应动作/响应方法 — 这些详细说明了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应动作（例如阻止 URL），而响应动作又有响应方法（例如使用此 API 调用）
- 威胁档案 — 详细描述威胁的文档，再次大致围绕钻石模型构建（尽管有时能力/TTP 将是主要焦点）。这可能更常被称为用例
流程
- 分类 — 对已触发的检测警报进行快速评估和优先级排序。这可以通过适当剧本中详述的丰富信息来源来获得信息
- 调查 — 再次使用适当的剧本辅助调查，以及威胁档案提供背景信息，安全运营将调查检测突出的潜在泄露的广度和深度
- 响应 — 再次使用适当的剧本，可以遵循安全运营可以采取的响应。此时这可能涉及与业务合作，并可能包括任何存在的业务事件响应能力
- 经验总结 — 这是对响应检测过程中所学到的一切的回顾。这可能包括流程改进、识别的其他威胁或对业务的建议
输出
- 经验总结 — 新威胁、检测调整建议、流程改进或业务建议的文档
紫队/红队测试
紫队/红队测试有助于磨砺所有其他功能，并有助于确保实践反映理论。
输入
- 检测 — 这些是检测本身，可以由紫队/红队验证
- 威胁档案 — 详细描述威胁的文档，再次大致围绕钻石模型构建（尽管有时能力/TTP 将是主要焦点）
- 业务背景 — 关键资产和其他业务优先事项的文档，以及业务运作的高层概述
- 系统背景 — 描述业务中使用的 IT 系统的 CMDB 和/或其他来源
流程
- 识别风险 — 紫队/红队可以努力理解业务和系统背景，以测试和揭示新的风险
- 验证流程 — 应测试检测、剧本和其他流程，以确保它们按预期工作。例如，一个威胁可能突出了导致检测的特定技术以及随后用于适当调查的剧本。对同一技术的紫队/红队测试可以证明这些按预期工作
输出
- 风险 — 已识别的额外风险，如新漏洞
- 改进 — 流程改进建议
治理、风险与合规（GRC）
admittedly 不是我的强项/领域（所以请在我错误的地方提出建议！）— 但我的理解是 GRC 充当业务和安全之间的接口，基于已知风险和最佳实践提供建议和指导，然后进行相应管理。
输入
- 风险 — 风险集合，如漏洞，以及所有者和缓解/修复计划的详细信息
- 外部来源 — 通常实施的安