连接我们的安全流程
第1部分 - 功能模块
在这篇博客文章中，我想讨论我对安全功能分解、输入输出和核心内部流程的当前理解。随着我学习的深入，这些观点可能会发生变化，欢迎提出任何想法和反馈！
关于这一主题的更权威文档，请参阅 https://www.ncsc.gov.uk/collection/building-a-security-operations-centre/operating-model/the-target-operating-model（感谢 Sevan Hayrapet 的建议）
在第1部分中，我将讨论这些功能，然后在第2部分中计划撰写我的个人目标，以及如何将我学到的 DevOps 知识（可能理解有误！）如 Azure DevOps 将所有内容连接起来，使一切都成为代码/工作项。
功能模块
在网络安全领域，存在各种互补的功能模块，都在帮助组织保持安全方面发挥着作用。这些功能模块不一定意味着不同的人员团队，即使在安全只有一个人的情况下，这些功能模块可能仍然以某种形式存在。
我将功能模块分解为输入、输出和内部流程 - 以及我对它们应该包含什么内容以及如何组成的看法。如果我遗漏了某些非常明显的内容或犯了错误，我表示歉意 - 所以请评论！
威胁情报
前提是，高层次的威胁情报应该是初始驱动力，告诉我们应该关注什么。
输入
- 外部报告 - 任何描述新威胁 TTP、参与者详情和 IOC 的威胁报告/博客文章等
- 业务背景 - 关键资产和其他业务优先级的文档，以及业务运营的高层概述
- 系统背景 - 描述业务中使用的 IT 系统的 CMDB 或其他来源
- 内部风险 - 应记录易受攻击的软件和其他风险
流程
- 评估 - 上述输入为钻石模型的每个角落提供信息，有助于提炼和优先处理威胁
- 威胁狩猎 - 通过基于已知威胁和风险进行支点分析，或使用其他威胁狩猎方法如假设引导，我们可以通过发现未知威胁来倍增已知信息的价值
输出
- 威胁档案 - 详细描述威胁的文档，再次松散地围绕钻石模型构建（尽管有时能力/TTP 会是主要焦点）。这可能更常被称为用例
漏洞管理
漏洞管理与威胁情报密切合作，后者可以告知优先级。他们的目标是分类、优先处理并推动业务内部漏洞的修复。可以说，这应该扩展到 CVE 之外，可能包括拥有和推动所有安全建议。
输入
- 外部报告 - 如 CVE 报告的漏洞
- 系统背景 - 描述业务中使用的 IT 系统的 CMDB 或其他来源
流程
- 评估 - 漏洞与从系统背景中了解的系统对齐
- 优先排序 - 基于上述评估，漏洞应根据部署缓解措施的紧急程度进行优先排序
- 管理 - 与业务和系统所有者合作，帮助管理和缓解漏洞。这通常需要一定程度的授权业务权限才能有效
输出
- 内部风险 - 这是记录这些漏洞及其代表的业务风险的方式。它们可以由合适的利益相关者拥有
检测工程/内容工程
检测工程的目标是将已知威胁转化为安全运营团队可操作的强大检测。
输入
- 威胁档案 - 详细描述威胁的文档，再次松散地围绕钻石模型构建
流程
- 分析 - 理解威胁的不同变体，以及每种变体可能如何被发现和在何处被发现。他们可能需要与平台工程合作获取所需的数据源
- 构建检测 - 基于威胁档案中强调的分析威胁构建检测。它们应尝试捕捉技术可能表现的各种方法，然后应进行测试以确保有效性
- 构建/对齐剧本响应 - 如果检测真实触发，响应分析师需要能够快速获得正确的信息来进行分类、调查，然后响应威胁
输出
- 威胁档案 - 应更新威胁档案以突出显示已为该威胁实施的检测
- 检测 - 这些是检测本身。它们应被视为代码并进行版本控制和管理
- 剧本/响应行动/响应方法 - 这些详细说明了威胁和/或检测的响应流程
平台工程
输入
- 系统背景 - 描述业务中使用的 IT 系统的 CMDB 或其他来源
- 数据需求 - 描述检测威胁所需的规范化数据的文档
流程
- 获取数据 - 基于系统背景，平台工程需要努力提取检测工程所需的相关数据
- 规范化数据 - 数据应尽可能过滤和规范化，以使检测（理想情况下）与底层技术无关
- 构建/维护 - 系统需要维护和监控，以确保它们仍以预期格式提供数据
输出
- 规范化数据 - 可供检测工程使用的规范化数据详情
安全运营
输入
- 检测 - 严格来说，这是检测规则触发导致的威胁实际检测
- 剧本/响应行动/响应方法 - 这些详细说明了威胁和/或检测的响应流程
- 威胁档案 - 详细描述威胁的文档
流程
- 分类 - 对触发的检测警报进行快速评估和优先排序
- 调查 - 使用适当的剧本辅助调查，以及威胁档案提供背景信息
- 响应 - 再次使用适当的剧本，可以遵循安全运营可以采取的响应
- 经验教训 - 这是对响应检测过程中学到的一切的回顾
输出
- 经验教训 - 新威胁、检测调整建议、流程改进或业务建议的文档
紫队/红队测试
紫队/红队测试有助于磨砺所有其他功能，并有助于确保实践反映理论。
输入
- 检测 - 这些是紫队/红队可以验证的检测本身
- 威胁档案 - 详细描述威胁的文档
- 业务背景 - 关键资产和其他业务优先级的文档
- 系统背景 - 描述业务中使用的 IT 系统的 CMDB 或其他来源
流程
- 识别风险 - 紫队/红队可以努力理解业务和系统背景，以测试和揭示新风险
- 验证流程 - 应测试检测、剧本和其他流程，以确保它们按预期工作
输出
- 风险 - 已识别的额外风险，如新漏洞
- 改进 - 流程改进建议
治理、风险与合规（GRC）
我的理解是，GRC 充当业务与安全之间的接口，基于已知风险和最佳实践提供建议和指导，然后进行相应管理。
输入
- 风险 - 风险集合，如漏洞，以及所有者和缓解/修复计划详情
- 外部来源 - 通常实施的安全标准源自组织外部
流程
- 消化和优先排序 - 选择所需的合规框架以及已知风险，然后将它们转化为优先排序、拥有和可操作的业务项
- 管理 - 与业务合作，帮助拥有、实施和修复/缓解这些已知风险或合规项
输出
- 业务背景 - 特别是关于合规状态和已知风险
- 安全指导 - 基于已知威胁以及合规/风险项的指导