Forrester Wave Network Segmentation
Teams use the forrester wave network segmentation report to pick tools that split networks. You set up these tools by grouping servers and blocking unwanted traffic between them. Many teams start with broad firewall rules that let whole subnets talk to each other. When network rules are too wide, one bad server can reach every database. How forrester wave network segmentation works in practice Network segmentation splits a flat network into small, separate zones. Each zone holds a specific ap
Network Segmentation + Forrester Zero Trust eXtended (ZTX): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Teams use the forrester wave network segmentation report to pick tools that split networks. You set up these tools by grouping servers and blocking unwanted traffic between them. Many teams start with broad firewall rules that let whole subnets talk to each other. When network rules are too wide, one bad server can reach every database.
How forrester wave network segmentation works in practice
Network segmentation splits a flat network into small, separate zones. Each zone holds a specific app, service, or database group. Teams install software agents on hosts or use cloud network rules to control traffic. These rules check the source address, target address, and port number before packets move.
Before locking down traffic, teams must map how servers talk to each other. Agents watch live traffic and build a visual map of all server talks. Engineers review this map and write rules that allow only needed paths. Then they switch the rules from test mode to block mode.
In block mode, the system drops any packet that breaks a rule. A web server can talk to its own app server on one port. That same web server cannot reach a payroll database in another zone. This setup stops attackers from moving sideways across the network after a breach.
What network rules solve and what they leave open
Network segmentation is great at stopping sideways movement between servers and cloud zones. It cuts down the attack surface by hiding ports from outside hosts. It also helps security teams pass audits that require separate zones for card data. If a hacker compromises a test server, network rules block paths to live servers.
Still, network tools only check where traffic comes from and where it goes. Once a rule allows a port, the network tool stops looking inside the session. An engineer or app on an allowed host still logs in with a shared role. The network firewall does not know which human ran a database query or command.
Network Segmentation + Forrester Zero Trust eXtended (ZTX): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This leaves a big gap during live maintenance and bug fixes. Network rules decide which machine can reach a database port. They do not inspect what individual queries, commands, or requests do in flight. A permitted user can still run a bad delete command or pull raw customer data.
How to add session and data controls
To close this gap, teams must pair network zones with command-level checks. You need a way to tie every database query or shell command to a user. Instead of trusting an IP address, you check user identity on every single action.
You can also add data masking to rewrite sensitive fields in query results. Masking rewrites emails, phone numbers, card numbers, and national IDs before results return. Engineers can fix bugs in live systems while sensitive fields stay masked in output. Adding approvals for risky commands also prevents accidental drops or updates in live databases.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between network segmentation and microsegmentation?
Classic segmentation uses routers and firewalls to split big subnets or data centers. Microsegmentation uses host agents or cloud rules to isolate single workloads and apps.
Why do network segmentation projects often take a long time?
Teams often lack an accurate map of how legacy apps talk to each other. Turning on block rules too fast can break live traffic and cause outages.
Does network segmentation protect against insider data leaks?
No, network rules only control which machines can open a port to another host. Authorized users on allowed paths can still run broad queries unless you inspect commands.