应用安全--到 SOC 还是不到 SOC？--其乐融融的IT技术小站

接下来，这个系列我们跟着英国的专家，探讨一下SOC，看看SOC的发展趋势，当然我们还是秉承一贯的声明，这些内容是为了大家能够多一个参考，在开展工作中，一定有因地制宜，切实履行我国的法律法规，履行法定义务，做到合规和安全。

因此，如果在英国正在实施一个大型数字项目，并在项目的每个阶段都遵循GOV.UK 服务手册。

您现在已准备好上线，但项目的认证机构需要知道该服务是否具有“保护性监控”。这意味着团队需要花费时间和精力来采购（或建立）安全运营中心（SOC）。

或者确实如此？

构建 SOC 是一项需要投入大量时间和金钱的任务。本博客探讨组织是否有可能以不需要“全脂”SOC 的方式设计系统。

SOC 如何工作？

SOC 通常由与操作人员不同的团队来运行。这有助于区分管理数字服务的人员和监控安全日志的人员之间的职责。

SOC 本身通常有专门的工具，最常见的是 SIEM（安全信息和事件管理）工具。它以日志和数据源作为输入，执行一些关联和规则检查，然后输出警报以进行分类。SOC 工具的许可可能很昂贵，通常以企业为中心的解决方案往往成本最高（并且通常需要每年续订）。

SOC 团队通常包括：

安全分析师对事件和警报进行分类
安全工程师管理工具（以及将项目引入 SOC）
某种形式的管理和行政职能

并且在某些情况下

威胁情报功能

遇到安全事件，没有日志来帮助弄清楚发生了什么，并且必须向高层报告，这是一个糟糕的情况。在某些情况下，出于法律和取证目的可能需要日志，因此证明其处理和完整性的监管链非常重要。

根据 SIEM 工具，有些工具提供日志的加密完整性和验证，以确定日志是否已被篡改。SOC 通常是确保日志的一个很好的策略：

安全收集
经授权的个人可以访问
根据组织政策
不是简单地收集以备不时之需（或被遗忘）

然而，设置自己的 SOC 可能既昂贵又耗时，因此一种选择是外包 SOC。然而，外部 SOC 分析师可能缺乏（例如）项目架构的知识，并且可能无法像内部 SOC 那样及时响应警报。

GPG13：房间里的大象

NCSC 的前身 CESG 发布了有关保护性监测的“良好实践指南”(GPG)。被称为 GPG13，负责处理风险的人员经常在服务上线之前使用 GPG13 作为要求。在某些情况下，这将保护性监控变成了一项复选框练习，SOC 工具的营销材料将其产品描述为“符合 GPG13”。

随着应用程序和服务的架构和技术堆栈开始多样化，这个问题变得更加严重，因为服务所有者没有动力去识别和监控未记录在 GPG13 中的风险。

GPG13 在 NCSC 成立之前已被弃用。然而，我们仍然让客户在他们的保证过程中引用 GPG13，并且偶尔会被问到何时发布更换指南。为了区分“GPG13 保护性监控方法”和 NCSC 当前的方法，我将使用术语“安全监控”来描述使用云原生服务构建的服务所考虑的方法。

云如何改变一切？

英国政府于 2013 年推出了“云优先”政策，目标是让政府部门在考虑传统的本地部署之前考虑云优先解决方案。

那么，向云的转变如何调整我们的安全要求呢？对于从本地基础设施直接迁移到托管 IaaS 的部署，这并不会减少对 SOC 的需求，因为没有固有的共享责任模型来减少运营责任。通过遵循和实施NCSC 的云安全指南，组织可以越来越多地转向云提供商提供的监控工具（而不是依赖 SIEM、SOC 或专业安全人员）。

SOC 的一个关键优势是能够识别特定于环境的风险并发出警报。此要求不会随着安全监控而消失，识别和监控任何自定义警报仍然很重要。

什么，没有 SOC？

那么，什么样的方法已经被用作全脂 SOC 的替代方案呢？以下是目前正在采用的一些政府项目：

完全云原生架构仅使用“云原生”服务的已部署服务，利用围绕服务使用进行严格身份管理的优势，并且没有传统上部署在虚拟机上的部署、修补和故障排除服务的运营开销。
零接触生产部署的服务，工程师永远无法直接访问生产服务（除了严格监控和审核的打破玻璃解决方案之外）。这降低了系统风险并减少了安全监控用例。
环境分离对应保持隔离的功能使用单独的云帐户。例如，存储安全监控日志和不应访问的服务（即使在玻璃破碎事件期间）的帐户托管在单独的云帐户中，并具有严格的访问控制和警报。
简化日志收集云原生服务提供自己的日志（以及整合和分析日志的服务）。随着安全监控要求的简化，事件的记录也被简化。日志现在采用一致的格式，并且可以收集并存储在云端。一些云提供商提供了解决日志完整性的选项，例如存储可用于验证日志完整性的校验和，并且在审核期间可能有用。
取代已经拥有中央 SOC 的 SIEM政府部门发现入门服务是一项耗时的任务。通过保持架构简单，一些人已经能够通过扩展其云原生日志记录解决方案以及将规则和警报直接构建到平台中来取代 SIEM 的要求。安全开发实践意味着运营团队对安全负有责任，因此不需要安全团队。事件管理至关重要，了解该做什么以及他们的责任也很重要。
打破玻璃有时需要直接生产访问。这可能是由于操作需要（例如调查性能下降），也可能是安全事件的一部分的要求。在某些项目中，运营团队负责调查和运行事件，这是通过记录良好的流程和程序、良好的访问和变更控制以及严格的系统审核来实现的。访问是有时间限制的，所有事件都由团队中的其他人审核和监控。
验证日志记录如果日志记录停止工作并且没有人注意到，那么所有这一切都将毫无用处。如果在时间窗口内未观察到令牌，则可以向服务注入金丝雀令牌并发出警报/错误。

最后的想法

在官方构建服务的地方，“云优先”应该是重点，这应该包括上述所有强调的领域，以帮助加强和简化安全监控要求。

对于 AWS（例如），您拥有严格控制的云原生服务，例如 GuardDuty、Security Hub、CloudTrail、CloudWatch。因此，您无需部署 SIEM，而是让运营团队拥有监控权，在设计简单且安全的环境中工作。通过赋予运营团队更多的服务所有权，我们会发现安全监控变得可以重复使用，就像现在部署基础设施时发生的情况一样。

在评估项目是否需要 SOC 时，您应该考虑依赖 SOC 的功能以及这些功能是否以其他方式涵盖：

如果事件发生，您是否需要日志来调查事件？云原生服务（如果配置正确）可以做到这一点，您将需要考虑日志保留以及可以访问或删除日志的角色。
是否需要在攻击发生时进行检测？云原生/无服务器架构在可能的攻击性质方面将受到更多限制，因为组件通常是单一目的，需要处理底层基础设施。通过评估您的架构中可能存在的攻击类型，您可以设置特定的警报。
是否有管理事件的要求？与上述一样，在无服务器环境中警报的性质会有所不同，并且该服务的运营团队可能比一般 SOC 分析师更能够识别可疑行为。然后，重要的一步是确保运营团队知道如何升级怀疑并测试该流程。

NCSC 认为，基于 SOC 和保护性监控的系统在安全工具箱中仍然占有一席之地。对于某些企业IT系统（例如端点）和基于传统IaaS的架构（以及比官方分类更高的系统），仍然需要提供系统的反应性监控。集中式 SOC 也有好处，政府部门可以识别更广泛的攻击，这些攻击正在探测组织使用的多种服务。

David S，高级安全架构师

后记：所谓师夷长技以制夷，在思想解放的情况下，要充分发挥“拿来主义”，同时也要根据自己的需要修剪成自己所需要的样子。