Pulseguard
Under Attack?A flat network is one credential away from everything.
Segmentation, firewall policy, remote access, and load balancing. We design the network as zones with a written policy between them, because the question after an incident is never what the firewall allows. It is what the attacker could reach next.
Nobody designed the flat network. It just never stopped being one.
Networks are built once, under time pressure, and then extended. A VLAN gets added for the new office. A rule gets opened so a supplier can reach a server, and the supplier relationship ends but the rule does not. Guest Wi-Fi is on the same switch as the finance workstations because that is where the free ports were.
None of this is visible from inside. A firewall with 400 rules looks like a network with strong controls, and it usually is not: what it has is a lot of exceptions and no policy. The test is simple. If a laptop on the guest network gets malware, what does it reach? In most estates the honest answer is the database, eventually.
Segmentation is the control that changes the answer, and it is unglamorous work: mapping what actually talks to what, before you can safely deny anything else. We do that mapping with flow data rather than with a workshop, because the flows people remember and the flows that exist are different lists.
Zones, and what is allowed between them.
Deny between zones, allow by exception, and every exception carrying the reason it exists. The matrix is the same policy in the form people argue about it in.
| from \ to | DMZ | App | Data | Internet |
|---|---|---|---|---|
| Office / VPN | allow | allow | deny | allow |
| Guest Wi-Fi | deny | deny | deny | allow |
| DMZ | - | allow | deny | allow |
| Application | deny | - | allow | deny |
| Data | deny | deny | - | deny |
Deny between zones, allow by exception, and every exception written down with the reason it exists. A rule nobody can explain is a rule we remove.
The data zone has no route out to the internet at all, which is the control that turns a database compromise into a contained incident rather than an exfiltration.
What we take on
Segmentation design
Zones drawn from how traffic actually flows, not from the org chart.
Flow collection first, so the design is based on observed traffic rather than on what people believe the applications do. Then zones, a default deny between them, and a documented exception list. The data zone gets no route to the internet at all, which is what turns a database compromise into a contained incident rather than an exfiltration.
Firewall and rule hygiene
Shadowed, duplicated, and orphaned rules removed, and the rest explained.
Rule bases are audited for rules that can never match, rules that are broader than their comment claims, and any/any entries added during an outage and never revisited. Every surviving rule gets an owner and a review date, so the base stops growing in one direction only.
Remote access
Modern VPN with device identity, or a zero trust broker where that fits better.
WireGuard or IPsec with per-user keys, MFA, and split policy so a contractor's laptop reaches one application rather than the whole office subnet. Gateways deployed in pairs so patching the VPN is a maintenance task rather than an evening outage.
Load balancing and failover
Health checks that remove a bad node, and a failover you have watched work.
Layer 4 and layer 7 balancing with health checks that test the application rather than the port, TLS terminated where it makes sense, and a floating address or DNS failover with a documented recovery time. Failover is tested during the engagement, in daylight, with everyone watching.
Routing and interconnects
BGP, multiple transit, and the config that stops a leak becoming an outage.
Multi-homed routing with filters and prefix limits so a mistake upstream does not become your incident, plus RPKI and route object hygiene where you announce your own space. Site to site and cloud interconnects included where the estate spans both.
Visibility
Flow data and IDS where the traffic crosses a boundary.
Flow export from the boundary devices and inspection where it is worth the throughput cost, so that after an incident there is a record of what moved and where. Feeds into the same timeline PulseGuard already keeps for findings, DNS changes, and deployments.
Map it, agree it, cut it over quietly.
Map
Flow collection across the existing network, plus a read of the current rule base, producing what talks to what rather than what people think does.
Design
Zones, the policy matrix, and the exception list, agreed in a document before a single interface is touched.
Cut over
New policy in monitor mode first, so the would-have-blocked list is reviewed before enforcement. Migration runs zone by zone, in windows.
Review
Exceptions revisited on a cycle, new flows checked against the policy, and anything nobody can justify removed.
Find out what the guest network reaches.
The mapping phase answers that in two weeks, with flow data rather than an opinion, and the report stands on its own.