Shell Information Technology International BV 使用 AWS 主动识别网络安全威胁

Shell 决定通过采用 Splunk Enterprise 和 Splunk Enterprise Security 来扩展 SIEM 解决方案，Splunk Enterprise Security 是一个平台，可用于快速搜索和分析来自其各种系统的历史机器数据和日志数据。它选择在 Amazon Web Services (AWS) 上托管 Splunk，因为 AWS 提供了满足 Shell 全球业务需求所需的可扩展性和灵活性。

该公司预计每天会从其各种系统收集数 TB 的日志数据，并且希望存储更多的数据用于历史分析。“我们很快得出结论，本地解决方案不具有成本效益，因为我们每周都需要额外的服务器和存储空间，”Hazenbroek 说。

虽然最初打算在本地托管其实时 SIEM 解决方案，并添加 AWS 上的 Splunk 以进行历史分析，但 Shell 最终决定将这两种解决方案（历史和实时）与 AWS 上的 Splunk 集成。

“我们意识到，与在本地运行我们的实时 SIEM 解决方案相比，在 AWS 上运行将为我们提供一种更可靠且更具可扩展性的解决方案，因为在本地运行时，我们会继续面临所需的硬件组件性能有限这一难题，”Brink 说。“最好有一个集成式解决方案，使我们能够进行实时监控并对历史数据进行深入分析，同时将所有数据放在同一个系统中。”

Shell 依靠大约 100 个 Amazon Elastic Compute Cloud（Amazon EC2）实例在 AWS 上运行其 Splunk 基础设施。“我们使用 Amazon EC2 c4.2 实例作为 Splunk 转发服务器，使用 c4.8 实例作为 Splunk 索引器，并使用 c4.4 实例作为 Splunk 搜索应用程序，”Hazenbroek 说。

它还使用若干个本地实例来将数据移入 Splunk 平台，并使用 SSL 客户端身份验证来确保可信连接。“我们决定不在其间使用 VPN，因为我们不想受到连接速度的限制，”Hazenbroek 说，“我们每天要通过该连接发送数 TB 的数据。”

对于索引器（即存储数据并处理搜索查询的 Splunk 组件），Shell 使用两种类型的 Amazon Elastic Block Store（Amazon EBS）卷来获得最佳性能并最大限度地降低成本。“Splunk 索引器需要速度极快的磁盘和大量 IOPS，”Hazenbroek 说。Shell 发现，Amazon EBS gp2 卷可以提供处理最近 30 天的数据（这些是用户最常搜索的数据）所需的速度。对于其余 11 个月的数据（这些是用户搜索频率较低的数据），该公司使用 sc1 卷。在所有 Amazon EBS 卷类型中，这种卷的每 GB 费用最低。

借助 AWS 的可扩展性和 Splunk Enterprise Security 的功能，Shell 创建了全面的 SIEM 解决方案和方法，能够分析实时数据和历史数据，并在不断变化的网络安全格局中保持领先地位。

“我们原有的本地 SIEM 解决方案的可扩展性有限，这导致我们无法以所需方式处理所有事件，”Brink 说，“我们无法将数据保留一两天以上，也无法测试或了解趋势。这意味着某些恶意企图在被发现之前就已经存在了较长一段时间。”

目前，Shell 每天会向 Splunk 中注入数 TB 的数据，并使用 PB 级数据湖来进行历史分析，这意味着其网络防御团队可以确定趋势并主动发现网络威胁。“通过在 AWS 上使用 Splunk Enterprise，我们能够以更好的方式保护 Shell 及其外围（内部和外部），因为我们的能力比之前大大提高了，”Brink 说。

现在，该公司可以通过数据分析来识别漏洞并提前消除漏洞，从而防止事件发生。“我们的网络防御团队现在所能发现的可能导致安全问题和违规活动的事件数量是之前的两倍以上，”Brink 说。“与之前的本地解决方案相比，我们对 AWS 上的 Splunk SIEM 解决方案的灵活性、可扩展性和功能非常满意。”