Rotated Keys, Same Map: Vendor Firewall Leaks Explained

Scope

This guide explains what your bank's information security team should do when a payment-connectivity vendor's firewall configuration is leaked by an extortion group. Using the recent n0n leak involving Finzly as a case study, we focus on a key issue: rotating credentials fixes access secrets but doesn't address the exposed network topology.

This isn't a full third-party risk management program. It's a practical response and verification reference.

Key Concepts and Definitions

Configuration leak vs. data breach. A firewall configuration leak exposes secrets (passwords, keys) and structure (tunnels, trust relationships, rules). It doesn't necessarily expose Cardholder Data, customer records, or transactions. In the Finzly case, files reviewed by the press didn't contain customer data, bank data, or transaction records.

Secrets vs. topology. Secrets can be rotated quickly. Topology (IP addresses, tunnel endpoints, trust relationships) changes slowly. As one security executive noted, network layouts change far more slowly than passwords.

Shared connection model. Finzly's BankOS platform links banks to ACH, Fedwire, and FedNow through a single connection shared by all its clients. The leaked files described a direct link labeled "FED" and rules for FedNow and FedACH traffic. A shared pipe means one vendor's exposure is every client's exposure.

Reversible secret storage. Firewalls store passwords and keys in encrypted form, but not always strongly. Fortinet acknowledged in 2019 that older FortiGate software versions used a single hard-coded key, identical on every device, to encrypt passwords in configuration files. A leaked configuration from an unpatched or legacy device may therefore be decryptable. The summary file in this leak stated the secrets had been decrypted on Oct. 15.

Requirements Breakdown

No single control "covers" this scenario. Map your response to the frameworks examiners already use.

• FFIEC IT Examination Handbook. The third-party relationship and information security guidance expects ongoing oversight of service providers, not point-in-time onboarding diligence. A vendor breach is a trigger for reassessment.
• NIST Cybersecurity Framework (CSF). The supply chain risk management category (Govern/Identify) covers supplier assessment and incident-response coordination with suppliers. Use Respond and Recover for the post-incident verification steps below.
• PCI DSS v4.0.1. If the vendor's connection touches Cardholder Data environments, Requirement 12.8 (third-party service provider management) and 12.9 (TPSP responsibility acknowledgments) apply. Requirement 1 (network security controls) and 8 (identification and authentication) are the relevant technical anchors. Confirm scope before assuming applicability; ACH, Fedwire, and FedNow flows are not card flows.
• FIPS 140-3 and key management. Where the vendor manages cryptographic keys for your connectivity, ask whether Key Encryption Keys (KEKs) and Data Encryption Keys (DEKs) are separated and where each is protected. Secrets embedded in configuration files should be an exception, not the norm.

Implementation Guidance

Step 1: Demand proof, not assurance

Ask the vendor: have you rotated every credential and key in that file, and can you show me? Then ask whether the vendor notified the Federal Reserve. Finzly says it rotated system keys and credentials, but it hasn't said when, so you can't tell whether rotation preceded or followed publication. Ask for timestamps.

Step 2: Inventory every connection

List every tunnel, API credential, VPN peer, and service account between your institution and the vendor. You can't verify what you haven't enumerated.

Step 3: Rotate what you control

Change every credential on your side. Agree on new VPN pre-shared keys or certificates with the vendor proactively rather than waiting to be told. Treat any shared secret that existed in the leaked configuration as compromised.

Step 4: Hunt backward

Review logs for unusual connections from the vendor's address space going back months, not just since the leak date. The leaked configuration was annotated as a "2023 config," and the vendor hasn't said when the intrusion occurred. Your lookback window should reflect that uncertainty. Hunt for Indicators of Compromise (IoCs): new source IPs on vendor tunnels, off-hours sessions, and unexpected administrative access.

Step 5: Address the map

This is the step most teams skip. Ask the vendor:

• Have tunnel endpoints, addresses, or trust relationships changed since the leaked configuration?
• If not, what compensating controls (allowlisting, anomaly detection, mutual authentication, additional filtering) cover the exposed paths?
• What is the timeline for re-architecting exposed paths?

Then apply the same question to your side. Which of your systems are reachable from the vendor's network, and does that reachability need to exist? Apply Least Privilege to network paths, not just accounts.

Step 6: Verify, don't accept attestations

Request evidence: forensic scope summaries, firmware and software versions on perimeter devices, confirmation of Multi-Factor Authentication (MFA) on administrative access, and results of post-incident Segmentation Testing. If the vendor can't produce them, document the gap and escalate it through your risk committee.

Common Pitfalls

• Treating "no customer data compromised" as "no risk." A topology map is reconnaissance. In the worst case, a leaked firewall configuration can lead to total domain compromise, according to a Huntress analyst.
• Equating rotation with remediation. Rotation closes the secret-based door. It leaves the trust relationships and routing the attacker now understands.
• Narrow lookback windows. Starting log review at the publication date misses earlier use of the secrets. The leak date and the compromise date are different events.
• Ignoring the extortion timeline. n0n extended its deadline, then published after it passed, suggesting no payment was made. Assume non-payment extortion ends in publication, and that the data may have been held, and usable, before then.
• Skipping notification checks. Confirm whether your vendor has informed the Federal Reserve and its other regulators, and determine your own notification obligations separately.
• Assuming the vendor knows its own exposure. The vendor has not said how the intruder got in or whether the compromised device was the firewall itself. Ask for the access vector.

Quick Reference Table

Your vendor can change its locks in a day. Redrawing the map takes far longer, and until that happens, your compensating controls are doing the work. Verify that they exist.