建立安全运营中心（SOC）威胁建模

笔记：

同样重要的建立是要记住，这种方法不会立即突出整个系统中风险的安全出现。这只是运营将适当的日志源引入您的 SOC 系统，此时可以考虑系统范围的中心风险 。有关识别系统范围风险的胁建更多信息 ，请参阅检测 。建立

需要注意的安全是，源码库执行威胁建模的运营方法有很多种 ，这只是中心有关如何开始组件级分析的指南 。它大致遵循攻击树方法，胁建但重点是建立识别最有价值的日志源和适当的检测用例。

威胁建模流程

上图描述了使组织能够系统地分析系统潜在风险、安全识别攻击向量和日志源的运营过程。然后，中心该信息也可以用作创建一套检测的胁建基础 。香港云服务器我们将在下面详细探讨每个步骤。

成分

威胁建模的第一步是确定：

用户与您的系统交互数据流入或流出您的系统

这通常称为系统的攻击面。

识别用户、数据流和攻击面将使您能够开始识别系统上的潜在风险和攻击 。

作为一个非常简单的示例，Web 服务器具有验证和提交信息的用户。它存储敏感数据并面向公众 。因此 ，免费模板该服务器将被视为对攻击者有吸引力的攻击目标 。这意味着该服务器将被视为潜在的攻击媒介。

图片

风险

简而言之
，下一步就是找出可能出现问题的地方 。会发生什么情况会影响系统的安全 ？

机密 性
、完整性和可用性 (CIA) 模型在这里很有用，它为您提供了一种枚举潜在风险的简洁方法 。同样，您还可以应用其他方法对威胁或攻击类型进行分类
，例如STRIDE 模型，亿华云以获得更深入的效果。

将 CIA 模型应用到我们之前的 Web 服务器示例中是有启发性的。我们发现 
，由于 Web 服务器处理客户数据，因此如果服务器遭到破坏，该数据的机密性就会面临风险。

如果身份验证控制失败，那么除了获得未经授权的访问并损害存储数据的机密性之外 ，攻击者还可以利用该访问权限对数据进行未经授权的模板下载更改，损害其完整性或删除存储的数据，使其对授权用户不可用。

这种风险分析至关重要，因为它可以合理化组织内特定组件的监控。突出的风险还可以帮助指导检测用例的开发。（有关更多信息
，请参阅检测）
。

攻击图V1

图片

注意：还可以扩展风险分析 ，以涵盖风险发生后对您业务的潜在影响。这可以帮助利益相关者了解潜在的云计算结果，并帮助确定入职行动的优先顺序。

威胁者

接下来，您应该设法了解可能尝试攻击或恶意影响您的系统的用户或参与者 。

每一类参与者都会以不同的方式与系统进行交互 。例如，专家攻击者有能力发起比新手更复杂的攻击。同样，与特权管理员相比，典型用户将具有不同级别的访问权限 。

攻击图V2

图片

攻击图的这一部分还认为，保护性监控的级别应与组织的威胁状况成比例（如操作模型部分中所述）。如果您确定您的系统不会受到最复杂的攻击者的攻击，则不应专注于尝试检测它们。相反，请专注于您的系统更有可能遇到的攻击。

攻击

此时您可以客观地探索每一个抽象风险 。这是详细说明攻击“如何”的地方。然后可以使用它将风险链接到日志源
。

例如，如果风险是用户数据泄露 ，您只需详细说明这种情况在您的系统中如何发生
。它不必非常详细 ，并且仍然可以非常抽象
，因为目标是识别日志源 。此时 ，使用MITRE ATT&CK 框架也非常有用 ，因为它可以帮助识别对手可以使用的特定技术 ，并帮助您找到最合适的日志源。

攻击图V3

图片

日志来源

威胁分析的倒数第二部分及其主要输出是日志源的识别。在这里，您可以识别并列出任何可用的日志源 ，这些日志源可用于指示您确定的系统内可能发生的任何攻击 。

攻击图V4

图片

检测

一旦完成了威胁建模过程 
，您就应该拥有一个模型，其中详细说明了多个日志源 、系统风险以及各种攻击。然后可以使用该模型来开发检测用例或确保您已经拥有适当的覆盖范围。（有关用例的更多信息，请参阅检测）

图片

概括

威胁建模应该是周期性的，并且您生成的模型应该随着系统或其面临的威胁的变化而进行审查 。

确定了最有价值的日志数据源后，现在应该可以开始工程流程，将这些信息源引入到 SOC服务中。