Flat Network at a 14-Branch Credit Union: Which Finding First?
You are the security lead at a regional credit union: 14 branches, 1,900 employees, one data center, and a /16 internal network that has never been segmented. One firewall pair separates the internet from a small DMZ; everything else - teller workstations, ATM management servers, the core banking system, and branch printers - shares the same flat address space.
Three findings are on your desk. A contractor that monitors ATMs still has a 2018 rule allowing it to reach the entire server VLAN on any port; the ticket that authorized it was closed as "temporary." The VPN concentrator stopped receiving vendor patches in March and terminates 300 sessions a day. And the IDS reports 40–60 SMB connection attempts each night from one branch subnet to random /16 addresses - a pattern that matches both a known worm and a print-management tool the branch operations team insists it cannot work without.
The core banking vendor certifies only a narrow set of configurations, and you get one four-hour change window per month.
1. Rank the three findings for remediation and justify your first move, taking the vendor's certification constraint into account.
Read the worked answer
First: the contractor rule. It is the only finding where an external party already holds a working path to the highest-value systems. Anyone who compromises the contractor's laptop inherits any-port reach into the server VLAN - including the core banking hosts. The pattern is a classic third-party pivot: low effort, high blast radius, and no detection because the traffic looks authorized.
Remediate by narrowing, not deleting: replace any-any with explicit permits from the monitoring host to the ATM management subnet on the two ports the tool actually uses, force the contractor through the VPN with MFA and a managed device, rotate their credentials, and log the rule with an expiry date and owner.
Check the constraint. The core banking vendor certifies the core banking hosts and their software stack, not your firewall ACLs. Segmentation outside the certified zone normally does not violate certification - but get that confirmed in writing before the change window so you are not the person who voided support.
Second: the end-of-life VPN concentrator. Real risk, but 300 daily sessions means a bad cutover is a same-day outage. Run replacement in parallel with compensating controls meanwhile: restrict who can connect, require managed devices, log and alert on anomalous session geography.
Third: the SMB scan traffic - until you have evidence, it is a hypothesis, not a finding. Do not lead with it.
2. How would you determine whether the nightly SMB traffic is a worm or the print-management tool without disrupting branch operations?
Read the worked answer
The two hypotheses have different signatures, so look for discriminating evidence rather than acting on the alert text.
Destination behaviour. A worm sweeps: many unique destination addresses, often in sequence, mostly on 445, with short failed and retried connections. A print tool talks to a small, stable set of print servers and may use 9100 as well. Pull NetFlow for the branch subnet and count unique destination hosts per night. Forty attempts to forty different hosts is a sweep; forty attempts to two hosts is a tool.
Identity of the talkers. Compare source hosts against the branch's asset inventory and against the documented print server IPs. If the sources are the same three workstations every night, that is software, not propagation.
Host telemetry. EDR or Windows event data from those workstations shows which process opened the connection. A named print service is exculpatory; an unsigned binary in a temp directory is not.
A controlled test. Span a port for 24 hours to capture the actual SMB dialect and session setup. Optionally block the traffic for one branch on one night and see whether printing breaks - a reversible, single-site experiment.
Document the conclusion either way; the point is to convert an ambiguous alert into a decision you can defend.
3. Given one four-hour change window per month, what segmentation target is realistic, and how do you sequence it?
Read the worked answer
Aim for zones with enforced choke points, not microsegmentation. Full identity-based segmentation would take years at this size; three or four enforced boundaries remove most of the lateral movement you actually fear.
Sequence by value, not convenience.
- Core banking and ATM management - move these into a protected zone reached only from defined application and admin hosts. This is the zone a regulator and your board care about.
- Branch-to-server-VLAN deny by default - permit only the specific ports each branch service needs. This alone would have bounded the SMB question and the contractor rule.
- User workstations - isolate from each other and from servers except through defined services.
Work within the window. Each month's change is: build the ACL or VLAN on the existing firewall, pilot with one branch or one server group, monitor for a week, then roll forward. Never cut over everything in one four-hour slot - the risk is not the ACL, it is the undocumented dependency nobody remembered.
Handle exceptions explicitly. Every permit you cannot yet remove goes into the risk register with an owner, a business justification, and an expiry date. Track the metric that matters: number of paths from a workstation or third party to the core banking zone. That number should fall every month.