连接我们的安全流程
第一部分 - 功能模块
在这篇博客文章中，我想讨论当前对安全功能的分解、它们的输入、输出和核心内部流程的看法。随着我学习的深入，这些观点可能会发生变化，欢迎提供任何想法和反馈！
关于这方面更权威的详细文档，请参阅 https://www.ncsc.gov.uk/collection/building-a-security-operations-centre/operating-model/the-target-operating-model（感谢Sevan Hayrapet的建议）
在第一部分中，我将讨论这些功能，然后在第二部分中计划写我的个人目标，以及如何将我学到的DevOps知识（可能有些误解！）如Azure DevOps，将一切都代码化/工作项化的旅程中的进展。
功能模块
在网络安全领域，存在各种互补的功能，所有这些功能都在帮助组织保持安全方面发挥着作用。这些功能不一定意味着不同的人员团队，即使在安全只有一个人的情况下，这些功能可能仍然以某种程度存在。
我将功能分解为输入、输出和内部流程 - 以及我对它们应该包含什么以及如何包含的看法。如果我遗漏了非常明显的内容或弄错了什么，我表示歉意 - 所以请评论！
威胁情报
前提是，高层次的威胁情报应该是初始驱动因素，它应该告诉我们关心什么。
输入
- 外部报告 - 任何描述新威胁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
- 构建/维护 - 系统需要浇水、喂养和监控，以确保它们仍以预期格式提供数据
输出
- 规范化数据 - 可供检测工程使用的规范化数据的详细信息
安全运营
输入
- 检测 - 严格来说，这是检测规则触发导致的威胁的实际检测
- 剧本/响应操作/响应方法 - 这些详细说明了威胁和/或检测的响应过程
- 威胁档案 - 详细描述威胁的文档，再次松散地围绕钻石模型构建
流程
- 分类 - 对已触发的检测警报进行快速评估和优先排序。这可以通过适当剧本中详述的丰富来源来告知
- 调查 - 再次使用适当的剧本辅助调查，以及威胁档案告知上下文，安全运营将调查检测突出显示的潜在泄露的广度和深度
- 响应 - 再次使用适当的剧本，可以遵循安全运营可以采取的响应。此时，这可能涉及与业务合作，并可能包括任何现有的业务事件响应能力
- 经验教训 - 这是对响应检测过程中学到的一切的回顾。这可能包括流程改进、识别的其他威胁或对业务的建议
输出
- 经验教训 - 新威胁、检测调整建议、流程改进或业务建议的文档
紫队/红队
紫队/红队有助于磨练所有其他功能，并可以帮助确保实践反映理论。
输入
- 检测 - 这些是检测本身，可以由紫队/红队验证
- 威胁档案 - 详细描述威胁的文档
- 业务背景 - 关键资产和其他业务优先级的文档
- 系统背景 - 描述业务中使用的IT系统的CMDB和/或其他来源
流程
- 识别风险 - 紫队/红队可以努力理解业务和系统背景，以测试和揭示新风险
- 验证流程 - 应测试检测、剧本和其他流程，以确保它们按预期工作。例如，威胁可能突出了导致检测和随后适当调查剧本的特定技术。同一技术的紫队/红队测试可以证明这些按预期工作
输出
- 风险 - 已识别的额外风险，如新漏洞
- 改进 - 流程改进建议
治理、风险与合规（GRC）
admittedly 不是我的强项/领域（所以请建议我哪里错了！）- 但我的理解是，GRC充当业务和安全之间的接口，基于已知风险和最佳实践帮助建议和指导，然后进行相应管理。
输入
- 风险 - 风险集合，如漏洞，以及所有者和缓解/修复计划的详细信息
- 外部来源 - 通常，正在实施的安全标准将源自组织外部。这些通常采用框架的形式
流程
- 消化和优先排序 - 选择所需的合规框架以及已知风险，然后将它们转化为业务优先的、拥有的和可操作的项目
- 管理 - 与业务合作，帮助拥有、实施和修复/缓解这些已知风险或合规项目
输出
- 业务背景 - 特别是关于合规状态和已知风险。理解这一点可以帮助威胁情报团队重新聚焦优先级；例如，如果风险项目无法缓解或修复，那么检测将是更高的优先级
- 安全指导 - 基于已知威胁以及合规/风险项目的指导。这可用于推动业务决策，如更战术性的变更（例如实施AD策略），也包括更长期、更战略性的架构决策（例如将服务迁移到云中）