当安全遇到FinOps时，所以SecFinOps

标准框架中提到的所有云安全最佳实践的实现最终占用了应用程序总预算的16%到49%。
我们认为这一成本是不合理的，可以显著改善。
我们找到了在不影响风险覆盖范围的情况下节省18%到54%云安全成本的方法。

背景

这一切都始于与FinOps团队的同事讨论他们帮助优化安全服务的工作；事实证明，云安全服务通常占云账单的10%到15%，高达25%的峰值很难证明是合理的…
根据我们的同事，这些意外成本的原因可以解释为：信息系统安全策略不适合云的具体情况，缺乏技术情报和对安全服务实际成本的可见性，以及安全服务被激活但未得到充分利用或被遗忘。
在这些观察之后，我们想用一个对照实验来证实它们，如果它们是真的，在试图找到优化它们的方法的同时，理解这些成本背后的机制。为此，我们试图回答以下问题：

• 我们能否通过一个受控实验来证明FinOps团队观察到的云应用程序安全成本的数量级？
• 我们能否优化云应用程序的安全成本，同时保持相同的风险覆盖水平？

Demo测试

按照我们的思路，我们设计并构建了一个基于客户常见架构模式的演示应用程序。该应用程序为需要定制设备的工业客户提供了B2B服务。
它由三个主要部分组成：电子商务网站，利用计算机辅助设计(CAD)文件处理客户订单；然后是一个分析后端，控制CAD文件的符合性和技术方面，从订单中获得度量；最后，一个同步步骤，将订单细节和CAD文件推送到内部企业资源计划(ERP)。

该应用程序管理一些客户数据：个人信息(PII)和公司内部设备细节。为了保护这些敏感资产，我们通过以下五个云公共支柱，将云安全最佳实践和防御深入应用到混合架构中：

• 基础结构/周边安全：网络深度防御、强化计算资源如虚拟机和函数（托管脚本运行时）和漏洞扫描。
• 数据保护：所有数据在静止状态和传输过程中使用云管理服务进行加密，确保所有应用网络流都是私有的（在云网络中传输）。
• 标识和访问管理：使用Cloud-IAM服务，阻止生存期凭据/令牌，对所有涉及云服务和On-Prem ERP的系统应用最小特权原则。
• 检测：识别主要的云错误配置，检测云管理平面上的可疑行为。
• 弹性：通过跨区域复制，确保服务（网站）的高可用性和客户数据（CAD文件）的完整性。

我国财务分析模型的构建

为了证实我们同事的FinOps发现，我们选择依赖最重要的云提供商之一。我们开始对所有使用的云资源进行普查，并将其安排到生产和安全服务中。我们将应用程序组件与超过65个价格项目进行映射，以获得一个客户订单每月成本的第一张图片。
我们改进了我们的模拟，以动态地得到基于任何订单量的精确成本。下图显示了与生产和安全相关的每月成本的演变，这取决于订单数量和“希望得到的”生产与安全的比率。

一些安全服务的成本在高流量应用程序中爆炸式增长

仿真结果表明，生产/安全比随客户订单数的增加而非线性增加。它达到49%，每月订单10万个。结果证实了FinOps团队的结果。

转向SecFinOps方法

从这些令人惊讶的发现中，我们得出一个假设，这个问题是由以下三个因素造成的：

• 基于云的安全服务正在成倍增长和伸缩，为优化创造了机会。
• 安全措施的成本与所涵盖风险的严重程度之间存在脱钩关系，这为根据风险优先级进行重新分配创造了机会。
• 传统的风险分析方法很少包括围绕安全措施成本的讨论。

从这个假设出发，我们提出了一种新的云应用程序风险分析方法，包括围绕安全措施成本的讨论。该方法的目标是帮助安全从业者找到机会，对安全措施进行成本优化，但不改变应用程序的风险覆盖范围。我们称之为COSMIRC：云优化的安全措施，具有相同的风险覆盖。

那么我们是如何构建这个SecFinOps方法的呢？

我们从一个标准的风险分析方法开始，然后我们向其中添加了一些用户故事。我们确定以下内容：

• 作为一名安全从业者，我希望能够看到安全措施对应用程序云账单的影响。
• 作为一名安全从业人员，我希望能够可视化与减轻特定风险场景相关联的成本。
• 作为一名安全从业者，我希望能够选择一种安全措施，以覆盖预定义的云安全服务集中的风险场景。

然后，我们问自己哪些数据源是构建我们的方法所必需的。我们确定以下内容：现实的云风险场景列表、每个CSP上可用的技术安全措施目录以及云服务成本知识。

如果您想自己合并数据源，我们想给您一些实用的提示来帮助您合并数据源。以下是我们的建议。
首先，要根据我们所依赖的现实场景构建云风险数据库：

• 云环境攻击策略的著名技术来源，云提供商的MITRE Att&CK矩阵。
• 公有云安全事件历史数据。
• 云安全专家小组成员，提炼风险场景的频率。在quantify risk management中，创建一个内部云安全专家小组是一项

众所周知的技术，可以在数据非常稀疏的情况下提高我们估计的准确性（在大多数情况下，安全事件是私有的）。如果你想更多地了解这种方法，我可以强烈推荐Ryan McGeehan在Medium上的文章，比如这篇。
然后，为了构建每个标准风险场景的可能的技术安全措施列表，我们依赖于云安全提供商的最佳实践和相关的安全配置文档。此外，我们从云安全专家小组收集了一些见解。

最后，为了收集有关云安全服务成本的信息，我们建议在云服务提供商(CSP)上使用“成本计算器”，在CSP上分析您的实际云账单报告或商业FinOps工具。
此外，我们知道，如果我们想要一个新的方法被实践者使用，它必须在构建时考虑到关键的采用原则。我们认为有几个

• 标准（除了解决一个真正的问题之外）是一个方法必须具备的，以便于采用。
• 易于沟通：您的方法必须产生非安全人员易于理解的发现。
• 保持简单愚蠢：尽量避免过早的过度优化或复杂的过程/操作，以便在组织级别上更容易扩展它。
• 低差距：确保新方法与实际操作流程只呈现微小的变化（用于风险分析）。

从方法到工具

我们第一次实现了我们的COSMIRC方法。目前，我们通过在一个电子表格上重用现有的风险分析工具来保持简单，我们对该工具进行了扩展，以包括我们的新功能。目前，我们只在环境中实现了它，但它可以很容易地扩展到其他CSP环境中。
而且我们可以告诉你，结果是非常有希望的！
在我们的实验中，COSMIRC可以节省18%-54%的安全成本。我们能够在不改变我们主要风险覆盖范围的情况下进行两项成本优化措施：机密数据泄露风险和客户数据丢失风险。

另外，我们从这个实验中得出的另一个结论是帕累托定律似乎也适用于云安全成本优化。简而言之，80%的成本优化将由20%的努力产生（例如安全措施的更新）。
但确切地说，我们是如何在不改变风险敞口的情况下，将云安全成本降低到58%的应用程序的呢？让我们看看我们是如何在一个成本优化上进行深入研究的。

数据丢失风险度量优化

如果您想降低云应用程序中数据丢失的风险，许多框架建议使用跨区域灾难恢复配置在另一个云区域复制数据。问题是，这种关于弹性和可用性的建议非常昂贵。但是覆盖数据丢失的风险真的有用吗？
也许为了改变您对云环境中这种风险的看法，我们希望您问问自己云经济学家Corey Quinn在他关于S3数据耐久性的伟大文章中提出的以下问题。
您的组织中有人（意外或其他）从错误的桶中删除关键数据或错误配置生命周期策略来为他们这样做的几率有多大？

事实上，云风险管理中的现实更接近于这种说法：
与云区的彻底灾难、政府的崩溃或恐怖组织接管云数据中心相比，向控制平面的糟糕推动没有被抓住并摧毁您帐户中的所有数据更有可能。
因此，我们为云环境中的数据丢失风险确定了两种可能的场景，它们是：
完整云区不可用（低概率）
关键数据被合法或非法用户删除，导致业务中断（高概率）
旁注：我们知道第二种情况已经在2014年的CodeSpaces攻击中出现在现实世界中。该公司不得不关闭他的业务，因为黑客破坏了他们云环境中的所有客户数据。您可以在本文中阅读更多关于此攻击的信息。

在这里，我们有一个优化机会，因为这两个场景不需要相同的安全措施来减轻，第二个场景的措施实际上比第一个场景的措施便宜。在我们的COSMIRC实现中，优化机会以以下方式呈现：

在我们的风险分析讨论中，我们选择不涉及第一种情况（完全云区域不可用），因为这种情况不太可能发生，但我们选择用“隔离帐户中的同区域复制”措施来缓解第二种情况。我们没有选择最便宜的选项来覆盖第二个场景，因为我们想要一个更多功能的解决方案，它不依赖于服务的特定特性

这个优化云环境中数据丢失风险的例子只是我们实验和研究中强调的众多可能性之一。以下是我们为成本优化找到的其他一些例子：

吸取的教训

最后，我们的方法可以归结为一些非常简单的事情：
我们远离了标准的遵从性框架，从云环境中现实的风险场景开始重新思考安全措施#BacktoFoundamentals。
然而，我们的方法的一个缺点是，转向个性化的安全措施以优化经常性成本与现代云环境开发方法是不兼容的。实际上，通过基础设施即代码的方法，我们希望标准化我们的堆栈（包括安全措施），以便我们可以轻松地复制应用程序的基础设施，并减少开发时间，这直接转化为节省资金。
我们的意见是，这两种方法仍然具有很高的价值。从这两个方面获益的一种方法是，将基础设施作为具有小规模应用程序（和小规模应用程序）默认安全性的代码保持标准化，但将细粒度的SecFinOps方法应用于表示大部分支出的大型应用程序。

接下来是什么？

在这一点上，我们的方法基于成本变量优化安全措施，因为我们知道这个变量对世界上任何公司都仍然非常重要。但我们认为，下一个巨大的挑战将不仅仅是关于钱。它将是关于气候变化的。
我们，安全专家，有责任确保我们部署的安全工具不仅是为了降低成本，而且是为了减少碳足迹而优化。
我们的SecFinOps方法可以从风险分析阶段就围绕安全措施的碳足迹提供机会和见解。正如埃森哲在其分析中所显示的那样，云的使用满足了绿色IT的挑战。在未来，如果能找到将我们的方法与云碳足迹等工具集成到“绿色安全”战略中，帮助安全团队在不影响安全态势的情况下测量、监控和优化他们的云碳排放，那将是再好不过的了。