连接我们的安全流程 | 第一部分：功能模块
作者：Martin Connarty
阅读时间：7分钟
发布日期：2023年12月4日
在本篇博客中，我将讨论当前对安全功能的分解理解，包括它们的输入、输出和核心内部流程。随着学习的深入，这些观点可能会发生变化，欢迎提出任何想法和反馈！
如需更权威的文档，请参阅：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或其他来源。
- 内部风险：应记录易受攻击的软件和其他风险。
流程
- 评估：上述输入信息为钻石模型的各个角落提供信息，有助于提炼和优先处理威胁。
- 威胁狩猎：通过基于已知威胁和风险进行 pivot，或使用其他威胁狩猎方法（如假设引导），我们可以通过发现未知威胁来倍增已知信息的价值。
输出
- 威胁档案：详细描述威胁的文档，再次 loosely framed around the Diamond Model（尽管有时能力/TTP将是主要焦点）。这通常更常被称为用例。
漏洞管理
漏洞管理与威胁情报紧密合作，后者可以告知优先级。他们的目标是 catalog、优先处理并推动业务中漏洞的修复。可以说，这应该扩展到CVE之外，并可以包括拥有和推动所有安全建议。
输入
- 外部报告：如CVE报告的漏洞。
- 系统背景：描述业务中使用的IT系统的CMDB或其他来源。
流程
- 评估：漏洞与从系统背景中已知的系统对齐。
- 优先处理：基于上述评估，漏洞应根据缓解措施部署的紧迫性进行优先处理。
- 管理：与业务和系统所有者合作，帮助管理和缓解漏洞。这通常需要一定程度的 delegated business authority 才能有效。
输出
- 内部风险：这是记录这些漏洞及其所代表的业务风险的方式。它们可以由合适的利益相关者拥有。
检测工程/内容工程
检测工程的目标是将已知威胁转化为安全运营团队可操作的稳健检测。
输入
- 威胁档案：详细描述威胁的文档，再次 loosely framed around the Diamond Model（尽管有时能力/TTP将是主要焦点）。这通常更常被称为用例。
流程
- 分析：理解威胁的不同变体，以及每种变体可能如何被发现和在哪里被发现。他们可能需要与平台工程合作以获取所需的数据源。
- 构建检测：基于威胁档案中突出的威胁分析构建检测。他们应尝试捕获技术可能表现的各种方法，然后进行测试以确保有效性。
- 构建/对齐剧本响应：如果检测真实触发，响应分析师需要能够快速获得正确信息以进行分类、调查并随后响应威胁。基于威胁本身以及检测，这些方法可能 vary，以及所用方法的具体细节。我使用了 RE&CT Framework https://github.com/atc-project/atc-react 的 slight variation，它将剧本分解为 specific actions covering the SANS 6 steps of Preparation, Identify, Contain, Eradicate, Recover, and Lessons Learned。我相信它可以更深一层，给出 specific methods such as a Script or series of tool specific steps。
输出
- 威胁档案：应更新威胁档案以突出显示已为该威胁实施的检测。
- 检测：这些是检测本身。它们应被视为代码并进行版本控制和管理。它们可以以许多不同的方式表示，但我相信像 Splunk ContentCTL 或 Sigma rules 中的基本 YAML 结构是好的。
- 剧本/响应行动/响应方法：这些详细描述了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应行动（例如阻止URL），这反过来又有响应方法（例如使用此API调用）。
平台工程
输入
- 系统背景：描述业务中使用的IT系统的CMDB或其他来源。
- 数据需求：描述检测威胁所需规范化数据的文档。
流程
- 获取数据：基于系统背景，平台工程需要努力提取检测工程所需的相关数据。
- 规范化数据：数据应尽可能过滤和规范化，以允许检测（理想情况下）对底层技术不可知。这有助于确保检测规则的 longevity 当该技术可能更新或替换时。
- 构建/维护：系统需要 watering and feeding and monitoring 以确保它们仍以预期格式提供数据。
输出
- 规范化数据：可供检测工程使用的规范化数据的详细信息。
安全运营
输入
- 检测：严格来说，它是检测规则触发后对威胁的实际检测。
- 剧本/响应行动/响应方法：这些详细描述了威胁和/或检测的响应过程。例如，网络钓鱼剧本有不同的响应行动（例如阻止URL），这反过来又有响应方法（例如使用此API调用）。
- 威胁档案：详细描述威胁的文档，再次 loosely framed around the Diamond Model（尽管有时能力/TTP将是主要焦点）。这通常更常被称为用例。
流程
- 分类：对已触发的检测警报进行快速评估和优先处理。这可以通过 appropriate Playbooks 中详述的 enrichment sources 来告知。
- 调查：再次使用 appropriate Playbooks 以辅助调查，以及威胁档案以告知背景，安全运营将调查检测突出显示的潜在妥协的广度和深度。
- 响应：再次使用 appropriate Playbooks，可以遵循安全运营可以采取的响应。此时，这可能涉及与业务合作，并 potentially including any Business Incident Response capability that exists。
- 经验教训：这是对响应检测过程中所学到的一切的回顾。这可能包括流程改进、识别的其他威胁或对业务的建议。
输出
- 经验教训：新威胁、检测调整建议、流程改进或业务建议的文档。
紫队/红队测试
紫队/红队测试有助于 sharpening 所有其他功能，并可以帮助确保实践反映理论。
输入
- 检测：这些是检测本身，可以由紫队/红队验证。
- 威胁档案：详细描述威胁的文档，再次 loosely framed around the Diamond Model（尽管有时能力/TTP将是主要焦点）。
- 业务背景：关键资产和其他业务优先级的文档，以及业务运作的高层概述。
- 系统背景：描述业务中使用的IT系统的CMDB或其他来源。
流程
- 识别风险：紫队/红队可以努力理解业务和系统背景，以测试和揭示新风险。
- 验证流程：应测试检测、剧本和其他流程以确保它们按预期工作。例如，一个威胁可能突出显示了一种 specific technique，导致检测和 subsequent playbook for investigating it suitably。对 same technique 的紫队/红队测试可以证明这些按预期工作。
输出
- 风险：已识别的额外风险，例如新漏洞。
- 改进：流程改进建议。
治理、风险与合规（GRC）
admittedly not my strength/area（所以请建议我哪里错了！）——但我的理解是，GRC 充当业务和安全之间的接口，基于已知风险和最佳实践提供建议和指导，然后进行相应管理。
输入
- 风险：风险的集合，如漏洞，以及缓解/修复计划的所有者和详细信息。
- 外部来源：通常，正在实施的安全标准将源自组织外部。这些通常以框架的形式出现。
流程
- 消化和优先处理：选择所需的合规框架以及已知风险，然后将它们转化为优先处理、拥有和可操作的业务项。
- 管理：与业务合作，帮助拥有、实施和修复/缓解这些已知风险或合规项。
输出
- 业务背景： specifically around the state of compliance and known risks。理解这一点可以帮助威胁情报团队重新聚焦优先级；例如，如果风险项无法缓解或修复，那么检测将是更高优先级。
- 安全指导：基于已知威胁以及合规/风险项的指导。这可用于推动业务决策，如更战术性的变化（例如实施AD策略），但也 longer term more strategic architectural decisions（例如将服务迁移到云中）。
总结
通过以上六大功能模块的详细解析，我们可以看到企业安全体系的复杂性和协同性。每个模块都有其独特的输入、流程和输出，但它们之间又紧密相连，共同构成了一个完整的安全防护体系。在第二部分中，我将探讨如何利用DevOps工具如Azure DevOps将这些模块连接起来，实现安全流程的自动化和代码化。