June 22, 2023

Third Party Wrangling: Refuting Common Arguments Against Network Segmentation

Let’s look at a few examples of what we see and hear when looking for proper network segmentation. For instance, some clients think segmenting third parties is unnecessary:

"SuperBankServicer is our trusted partner. We like open communication, and our current setup (with the rConnection router directly attached to our internal switch) helps facilitate that."

"They get a SOC audit. Looks good. They’re safe."

"Our IPS will catch any attack."

Others think such segmentation is atypical or too difficult:

"SuperBankServicer installed the router like that."

"They're part of the biggest bank in the land. Surely they did it right."

"They said it would break stuff." or "We tried last year, and it broke stuff."

Our Trusted Partner

Relationships with partner banks and core banking providers, such as SuperBankServicer, are revered by management, and without understanding the full technical operation of each product you are getting from those providers, it is easy to assume you need to keep the communications line clear and open for all their technologies to work today and tomorrow. If we're to follow guidance, adopting an open communication model for third parties defies the concept of zero trust architecture covered in the FFIEC's Architecture, Infrastructure, and Operations Booklet (https://ithandbook.ffiec.gov/it-booklets/architecture-infrastructure-and-operations/vii-evolving-technologies/viib-zero-trust-architecture/). The condensed version of that section is "only give what is needed." Your customers assume that you follow this model, and your privacy policies reinforce it. "We don't share unnecessary data." ...but you might be sharing much more unintentionally with lenient vendor connectivity. The risk of SuperBankServicer going rogue and putting malware on your network isn't the primary concern; it's that you don't have a guard at their entry point if they get breached and an attack pivots into your environment. Limiting their access is not a perfect mitigation, but it is one of the most fundamental information security controls.

Additionally, the Business Continuity Management Booklet (https://ithandbook.ffiec.gov/it-booklets/business-continuity-management/iii-risk-management/iiib-risk-assessment/iiib1-risk-identification/) highlights the need for understanding dependencies and considering defenses against potential supply chain attacks using vendor connections:

"A critical failure at a third-party service provider could have large-scale consequences. Management should identify interconnectivity points between the entity and its third-party service providers, as well as between other entities and third-party service providers. Documenting the flow of transactions, such as developing formal process diagrams, may help management identify interdependencies and end-to-end processes."

If something bad happens in SuperBankServicer's network, the best assurance that their bad day does not bleed into your network is your own set of firewall rules; not an email statement from them saying that the problem is contained. DMZ isolation offers the former, with the added benefit of being easily auditable. “Did any strange traffic patterns happen through our rConnection router? Let's look in the firewall logs”

Disclaimer: There will be instances where small environments, which are heavily reliant on managed service providers, legitimately require broad network access allowances. However, the most mature and capable providers will be able to supply necessary IP addresses, ports, and protocols needed for service delivery so that you don't have to provide too much remote access. Such providers have a strong understanding of how their products work and offer the information needed for least privilege controls to be properly implemented. We judge these sorts of arrangements with size and complexity discretion.

Warm and Fuzzy SOCs

We find issues that are missed by some SOC audits. Every firm has their own program, processes vary, scopes vary, auditor understanding differs, etc. Additionally, there are several assorted flavors of SOC audits. That is not saying a SOC audit for any third party is unreliable or that any SOC audit providers are inept. We just get to see service delivery from a different angle. In most cases, when data flow diagrams are reviewed as part of a vendor's SOC audit, the auditor is primarily assessing their client’s policy compliance and adherence to standards or best practices, not necessarily the level of security provided to you. We encourage you to look at how the controls of your providers’ SOC reports are worded. (Is the control assessment regarding the security of the service provider, the security it provides you, or a blend of both?) Unlike SuperBankServicer's SOC being focused on security of their networks, our focus is on the security of your networks, regardless of whether threats are sourced from the public Internet, a trusted partner's L2 fiber drop, or their VPN device. We want to make sure that you are aware of any potentially unnecessarily open connections, and having an unbridled third party directly attached to your internal networks qualify.

Intrusion Prevention Illusions

There is a reason many critical providers supply encrypted VPNs; it is so attackers or others cannot snoop on the traffic between their data centers or other resources on its way through to your endpoints and vice versa. If your IPS is only watching the Internet perimeter, communications between a directly attached third party and your endpoints or servers will probably not be seen by the IPS unless it's also probing internal traffic, either through an explicit configuration or some kind of add-on sensor. Even then, if the communication is fully encrypted end-to-end, controls may not detect any malicious activity until it affects an endpoint.

A direct attachment to your internal network bypasses your standard firewall controls. The vendor does not even need a key to your front door because you've broken down a wall to give them unfettered access to the interior of your environment.

"Well, it's a good thing we're doing intrusion prevention at the endpoints, too!"

Not so fast! Another common observation is exemption of endpoint protection for service providers, their products’ associated file directories, and their applications. Ask your IT folks to show you path exceptions and file exclusions configured in your antivirus or other endpoint protection product. You will often find applications and IP addresses associated with your provider entirely exempt from virus, behavior, or log analysis. Why so? See: It Broke Stuff below.

Vendor Can't Be Wrong

Processes and procedures fail sometimes, even at big publicly traded companies with rigorous risk management. If there is an implementation guide for SuperBankServicer's rConnection, your only assurance that it was installed with your network's protection considered is to read that guide for yourself. When starting the process toward wrangling a vendor into the DMZ, requesting your product's implementation guide is a tool worth keeping in your back pocket. If the vendor is combative or says, "that's unnecessary," (segmentation from your production networks) it may be worth asking for and reading. If the guide is too technical for your understanding, a trusted consultant may be able to determine whether least privilege principles were considered when the guide was written. For new vendors, it is a great way to gauge their maturity during vendor management reviews, and if they're already connected, a great way to confirm engineers from both organizations did it "by the book."

The Big Bank Can't Be Wrong

You already have a big bank in mind, and you're right. They are not wrong; however, we often see connectivity to FRB Services setup not "by the book"; with simple, unrestricted LAN attachment. FedLine Advantage implementation guides explicitly expect you to isolate traffic to and from their VPN devices, and the guides supply all necessary IP addresses and ports to achieve that. If you are an EUAC or Technical Contact within your institution, you can login to the FRB Services portal and download a copy of their guides for yourself.

It Broke Stuff

All IP communications coming into or out of your network follow a standard model that involves IP addresses, ports, and protocols. Most Internet communications these days are over HTTP or HTTPS, but there are others as well, and when a vendor needs access to those for service delivery, they should be able to communicate them effectively to you.

The core banking server may need to communicate over FTP to your document imaging server. In firewall speak, such an allowance may look like this: 192.22.22.1 allow TCP 21 172.12.21.4. Occasionally, a server at a provider network may push a software update to the same document imaging server over port 63022. An allowance for that could look like this: 192.22.22.2 allow TCP 63022 172.12.21.4. All workstations should be allowed telnet session access to the core banking server: 172.12.21.0/24 allow TCP 23 192.22.22.1. Such details should be available from mature vendors who understand their product delivery process so that your network engineers and firewall administrators are not left dealing with guesswork or making broad allowances for service delivery because they don’t know or understand the requirements.

If the number salad above looks like gibberish, that's okay, but it’s worth knowing a competent provider and firewall administrator will know how to use that kind of information to make granular rule sets to keep you safe from excessive exposure, whether necessary allowances or exceptions be set in a firewall or endpoint protection suite. It may take some time to configure, perhaps dozens of rules for your most critical providers, but it is a necessary step in mitigating the risk of supply chain sourced attacks.

PDF Icon Download Blog