在一个隔离的、高安全性的环境中，如果没有必要就不会允许访问，那么如何执行安全性评估，从而要求其他系统和安全提供商进行临时访问？

在2016年孟加拉国银行抢劫案之后，环球银行金融电信协会(SWIFT)推出了客户安全计划(CSP)，要求采用客户安全控制框架(CSCF)。 因此，任何组织的 SWIFT 系统或与 SWIFT 相关的系统现在都与一般的 IT 环境隔离，被锁定在一个”安全区”内。 在这里，访问仅限于促进内部银行系统和 SWIFTNet 之间的消息流所需的系统。 这种可靠的安全性提出了一个挑战——如何维护一个只有少数人能够访问的环境？

为了有效地对系统或解决方案进行技术安全性评估，安全合作伙伴需要直接访问它们所处的环境。 对于应用程序测试，可以从他们的笔记本电脑(通过连接到相同的环境)访问应用程序，或者访问目标环境中的远程系统，可以在其中安装工具以供使用。网络安全评估也是如此。

尽管如此，为促进在安全区内对SWIFT系统进行有效的安全测试而实施的明确策略和程序并不多见。虽然可以创建定制的工作区，但它们可能既不可靠，也不具有可伸缩性。这是因为对它们的需求经常在组织需要的时候意外出现，因此也会花费额外的时间和金钱。

环球银行金融电信协会 CSP是否允许安全评估?

任何安全的环境只有在得到维护的情况下才能对攻击保持弹性。 当需要在安全合作伙伴无法访问的环境中进行维护时，就会出现第22条军规。在我们的咨询顾问自己寻找解决方案的过程中，他们首先解开了SWIFT的CSP中列出的控制，以了解供应商的期望和指导。特别值得注意的是两个控制：

CSCFv2020 - 7.3A渗透测试

技术安全评估的要求在控制 7.3A 中概述。这表明应该对生产环境或复制生产环境的预生产环境中的所有“硬件、软件和网络组件”进行安全评估。此控制的主要风险驱动因素是识别可能促进或导致被入侵的“安全漏洞或安全错误配置”。 

本质上而言，这要求安全提供商获得对安全区内系统的临时访问权，并对范围内组件执行高质量、深入的安全测试。没有这种访问，就无法对组织的安全状态提供可靠的保证。但是，由于组件是隔离的，所以除了下游系统之外，没有任何东西可以与安全区通信，因此可能会错误地解释为不能向上述安全提供商提供访问。

CSCFv2020 - 1.1 SWIFT 环境保护

在 CSCFv2020 控制的 1.1 中概述了将 SWIFT 系统与一般公司 IT 网络隔离的要求。 这项规定要求”建立一个‘安全区’ ，以便将本地的 SWIFT  基础设施隔离开来，使其不受位于安全区以外的系统和服务的危害”。 这种控制的总体风险驱动因素是，可能通过来自互联网的攻击或对一般公司网络的攻击，获得对关键SWIFT系统的未授权访问。

这种控制的实施准则范围很广，但它指出，”一般而言” ，跨越安全区边界的连通性应限于：

· 与后台应用程序和SWIFTNet的双向通信

· 从批准的普通操作员 PC 到跳转服务器的入站通信

· 出站管理数据(数据日志、备份等)

它进一步指出，入站和出站流量应该“尽可能地”受到限制，并且应该实现一个流程来定期检查“管理连接的规则”。 举个例子——尽管不推荐——需要定期执行漏洞扫描，这在某些环境中可能会利用位于安全区域之外的扫描系统。 环球银行金融电信协会承认这种可能性，并表示，如果该区域的扫描系统与外部企业环境共享，“应该监控在整个环境中使用的凭证，以确保它们只在预期的时间和地点使用”。

因此，设立明智的政策和程序，为完成技术安全评估提供便利而临时进入安全区(或在安全区内)，并未受到 CSCF 的禁止。 如上所述，这实际上是内在要求，并在 SWIFT 自己的指导概述的控制“7.3A -渗透测试”得到鼓励。

解决方案

对所有人来说，理想的解决方案是实现一个流程，以便于可信合作伙伴直接访问安全区，从而提供必要的安全评估。 这不仅没有降低安全区设计的健壮性，反而通过促进完整、全面和未中断的技术安全评估，增强了其总体安全状态。 通过我们与客户的互动，我们找到了以下两个有效实现这一目标的解决方案：

直接访问安全区内的服务

 这种直接访问可以通过引入短暂的防火墙规则来实现，这些规则允许白名单里的”测试人员”使用的设备限制或不受限制地访问安全区环境中的某些系统，例如网络应用程序接口和服务器。 这种白名单只适用于测试人员的静态 IP 和 MAC 地址，因此便于从他们自己的笔记本电脑进行测试和分析。 一旦评估结束，这些防火墙规则随后可以被删除，以减轻在评估时间框架内引入的风险。

访问连接到安全区的专用“测试”系统

这可以通过创建一个带有工具的专用工作站来实现，测试人员可以通过特权访问管理(Privileged Access Management，PAM)解决方案进行访问。 工作站可以存在于安全区域中，也可以存在于组织的服务器环境中，具有对安全区的特定白名单访问权限。 作为一项安全防范措施，这个系统可以在需要的时候“打开”——或者在虚拟化的情况下创建——从而降低与它在环境中日常存在相关的任何风险。

不需要向安全区的生产实例授予访问权限。 相反，它可以(理想情况下是这样的)复制生产环境的预生产实例。 这将促进执行全面测试的自由，而不会有任何评估干扰实时通信流量或将生产环境暴露于不必要风险的风险之中。

下图说明了上述高级解决方案如何适用于现有的 SWIFT 安全区架构：

图1. 通过直接访问或通过测试系统在 SWIFT 安全区内实现的测试人员评估

结论

在设计 SWIFT 安全区时，需要考虑测试人员的访问需求，或者将其作为现有安全区时的优先级扩展。 环球银行金融电信协会的客户可能会发现，他们无法根据审计要求进行可靠的安全测试，无法准确评估风险，甚至无法充分了解其最关键系统的安全状况。

在安全评估的范围内，有多种解决方案可以促进对组件的访问。 然而，这最终将取决于组织的体系结构设计和风险偏好。 一旦解决方案得到实施，重要的是要对其进行仔细审查，从安全角度进行评估，并提供详细的文件以供审计，因为它可能会成为安全区安全边界的一部分。

环球银行金融电信协会（SWIFT）的客户必须维护一个健全和受限制的安全区的实施，同时还要创建新的策略、程序，并在必要时创建基础设施，以便能够进行全面的安全评估。 如果没有专门的解决方案，使用外部测试伙伴的组织可能会发现，当需要进行评估时，他们可能会浪费时间、金钱和资源。

本文翻译自：https://www.f-secure.com/en/consulting/our-thinking/testing-swift-systems-in-a-more-secure-world如若转载，请注明原文地址：