In my previous blog I briefly explained the new SWIFT regulations framework that will come into force on January 1st, 2018. In this blog I will focus on what is required to meet the first SWIFT requirement: “Restrict Internet Access & Protect Critical Systems from General IT Environment”. I will also explain how Guardicore can help in complying with these requirements faster, simpler and in a more robust and maintainable way.
This requirement is designed to create a clear and controlled boundary between SWIFT components and all other components in the network (general IT). In a very detailed implementation guidance document, SWIFT explains what is meant by that and how SWIFT expects its customers to implement this requirement along with the components that should be part of the SWIFT secure zone.
Just to name a few of those guidances:
- Inbound and outbound connectivity for the secure zone is limited to the fullest extent possible.
- Transport layer stateful firewalls are used to create logical separation at the boundary of the secure zone.
- No “allow any” firewall rules are implemented, and all network flows are explicitly authorized.
- Firewall rules are reviewed at least annually.
- Operators connect from dedicated operator PCs located within the secure zone (that is, PCs located within the secure zone, and used only for secure zone purposes).
- SWIFT systems within the secure zone restrict administrative access to only expected ports, protocols, and originating IPs.
SWIFT also recommends to implement internal segmentation between components in the secure zone to even further reduce the risk.
Now let’s take some time to understand what complying with this paragraph (just one out of sixteen) requires from the administrator.
1. First you will need to identify all the components that belong to a secure zone along with all their connections. This mapping is far from being trivial. The number of SWIFT related components in a big financial institution can reach tens and hundreds of components, some physical and some virtual and hosted on different types of infrastructure. We usually see people using firewall logs, NetFlow and other “manual” mapping methods which are time consuming, prone to error and tedious. A good visibility tool is a must when going through such a process.
2. Once all the components are mapped and all the connections between them and to the outside world are clear, the SWIFT guidance dictates that every flow that is crossing such a boundary be clearly understood and authorized. Again without a good visibility tool this can be a very long procedure. Application owners, system administrators and network architects will need to provide input to figure out that “This machine connects to an outside server on this 63422 port, because it is a BES client, the IBM monitoring software that is built into some of the images” – true story.
And we are talking hundreds of such examples. A tool that visually shows on a map machine names rather than IP addresses; processes, user-names and application paths such as “/opt/BESClient/bin/BESClient” instead of random high ports makes this process fast, simple and reproducible.
3. Next, after all the mapping has been done, the administrator will have to actually implement the segmentation and enforcement of the policy in line with the regulation. Well, this can become quite tricky. The naive approach of putting all machines in the SWIFT secure zone in a separate VLAN can prove quite a difficult task, as you will need to go and configure switches on different infrastructures (some virtual ,some physical). This will require involving different people in the organization and cutting those tickets can take weeks.
The plot thickens even more – the components may be physically spread around different locations and teams; any change across the network such as a new operator PC added to the pool (due to a business requirement) or a machine migrates from VMware to OpenStack means you need to do this all over again. This this will lead, over time, to holes and issues in auditing procedures. But what if the tool that you used for mapping could also help you set the policy in a logical way saying “All operator PCs can only talk to SWIFT connectors on only this port”? Now, move the Operator PC to OpenStack, add one more to the pool, keep the tag on it and the policy will be enforced automatically. I think this is the only sane way to go.
4. Last, but not least, during auditing times when all the data needs to be presented to the auditor, if you are not using one single tool to do it all, the audit may take much more longer – going over different switches, firewalls, etc., to prove segregation and that “every flow is authorized.”
Given the complexity and dynamic nature of modern IT, a seemingly simple task of “putting a border around my secure zone” can become a real headache if you don’t have the right tools in place. Guardicore Centra is the platform that provides the right level of visibility, allows you to build simple and maintainable policy, enforce it, and pass audits easily – across any infrastructure at any scale.