Firewall rules that someone on your team can still explain, and segments an intruder can't just walk across.
Rule bases grow by a few entries every week and almost never shrink. We review and clean up firewall policy, segment flat networks around the systems that matter, send web and SaaS traffic through a security service edge, and move cloud network rules into Terraform.
User devicesoffice · remoteVendor remote accessnamed · time-limited
02 · Controls
Security service edgeEntra Internet AccessFirewallszone allow rules with ownersProtective DNSegress filteringCloud network policyTerraform · NSGs · security groups
03 · Destinations
Internet and SaaStenant restrictionsServer zoneapps · databasesManagement and backupisolated firstOT networkplant control systemsCloud VNets and VPCsprivate endpoints
04 · Monitoring
SIEMfirewall · DNS · SSE logs
TerraformMicrosoft Entra IDCyberArk
in short·15-second read
Network security is the question of what can talk to what, inside and out.
Cohash cleans up firewall rule bases and designs segmentation for data center, cloud and OT networks. We roll out secure web and SSE services such as Microsoft Entra Internet Access, swap shared vendor VPN accounts for brokered access, and put cloud security groups and firewalls into Terraform.
you probably need this if
The firewall rule base only grows, and nobody can explain half the rules.
Backup servers and management interfaces sit on the same network as user laptops.
Vendors reach your network through shared VPN accounts.
terms on this pageEgressdefinitionData leaving a cloud provider's network. Getting data in is free. Getting it out is billed by the gigabyte.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Network Security, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · network security3 open
openThe firewall rule base only grows, and nobody can explain half the rules.
recurringBackup servers and management interfaces sit on the same network as user laptops.
blockedVendors reach your network through shared VPN accounts.
exposure
Firewall rule review and clean-upSegmentationSecure web and SaaS accessVendor remote accessCloud network policy as codeDNS and egress control
startrehearsehandover
Collect
Analyze
Change in batches
Codify
we are here
ready to hand over
The rule base is smaller, and every rule left has an owner and a ticket.
The only way to the backups and management interfaces now is a brokered admin session.
Rule changes go through review now.
Rule base analysis with removal candidates
chapter 01 · where it hurts
Why teams reach out
The firewall rule base only grows, and nobody can explain half the rules.
Backup servers and management interfaces sit on the same network as user laptops.
Vendors reach your network through shared VPN accounts.
chapter 02 · what we change
How we solve it
Firewall rule review and clean-up
Segmentation
Secure web and SaaS access
Vendor remote access
Cloud network policy as code
DNS and egress control
chapter 03 · how it runs
Our approach
Collect
Analyze
Change in batches
Codify
chapter 04 · where you end up
What changes
The rule base is smaller, and every rule left has an owner and a ticket.
The only way to the backups and management interfaces now is a brokered admin session.
Rule changes go through review now.
Rule base analysis with removal candidates
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Unused, shadowed and any-to-any rules found from hit counts and traffic logs, then removed in scheduled batches with owners signing off. Every rule that survives gets a ticket reference and an owner.
Zones for user, server, management and OT networks, with allow rules built from observed flows. Management interfaces and backup systems get separated first, because ransomware operators go looking for them.
Secure web gateway and SSE policy, for example Microsoft Entra Internet Access. We scope TLS inspection carefully and add tenant restrictions, so staff can't sign in to personal cloud tenants from company devices.
Shared vendor VPN accounts get replaced with named, time-limited access brokered through PAM or ZTNA. Where a contract requires it, sessions are recorded.
Security groups, NSGs, cloud firewalls and private endpoints are defined in Terraform. Changes go through pull requests and get checked for public exposure before anyone runs apply.
Protective DNS and outbound filtering that cut off command-and-control and exfiltration paths, with the logs sent to your SIEM.
capability 01 / 06in production
Firewall rule review and clean-up
Unused, shadowed and any-to-any rules found from hit counts and traffic logs, then removed in scheduled batches with owners signing off. Every rule that survives gets a ticket reference and an owner.
Zones for user, server, management and OT networks, with allow rules built from observed flows. Management interfaces and backup systems get separated first, because ransomware operators go looking for them.
Secure web gateway and SSE policy, for example Microsoft Entra Internet Access. We scope TLS inspection carefully and add tenant restrictions, so staff can't sign in to personal cloud tenants from company devices.
Shared vendor VPN accounts get replaced with named, time-limited access brokered through PAM or ZTNA. Where a contract requires it, sessions are recorded.
Security groups, NSGs, cloud firewalls and private endpoints are defined in Terraform. Changes go through pull requests and get checked for public exposure before anyone runs apply.
We pieced these together from Network Security situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
4,000 firewall rules, and a third of them with no hits in a year
composite · not a client story
Beforethe situation
Two data center firewall pairs carry about 4,000 rules, many left from an old migration. Hit counts show a large share unused, dozens of any-to-any rules sit near the top, and quarter-end batch jobs make everyone wary of deleting anything.
What we dothe work
Collect hit counts across at least one full quarter-end, and tag each rule with a ticket and owner where one exists. Disable unused rules in batches with logging on a deny rule below them, and delete only after another clean cycle. Rebuild any-to-any rules from observed flows.
Afterwhere you end up
The rule base is smaller, and every rule left has an owner and a ticket. Quarter-end jobs ran during the disable period, so the deletions rest on evidence.
case file 02
Backup consoles reachable from the user VLAN
composite · not a client story
Beforethe situation
Backup servers, hypervisor management and iDRAC or iLO interfaces share a routed network with user laptops. In a tabletop, one stolen admin password got a ransomware operator all the way to the backup console.
What we dothe work
Move management interfaces and backup infrastructure into their own zone first, reachable only from PAM jump hosts. Build allow rules from a few weeks of flow logs, run them in monitor mode, then enforce. Give immutable backup copies credentials that live outside the main domain.
Afterwhere you end up
The only way to the backups and management interfaces now is a brokered admin session. Steal a user's password and you're stuck at the user tier.
case file 03
Azure NSGs edited in the portal during incidents
composite · not a client story
Beforethe situation
Production NSGs across several subscriptions get edited in the portal during incidents, and a few rules allowing RDP from any source were left behind. Terraform manages the VNets but not the rules.
What we dothe work
We import the existing NSGs into Terraform state and fold the rules into modules for each application tier. A pull request check blocks inbound internet rules on management ports. An Azure Policy assignment denies the same change if someone tries it in the portal.
Afterwhere you end up
Rule changes go through review now. RDP and SSH from the internet are blocked at two layers, and manual changes in the portal show up in the next Terraform plan.
How traffic is filtered, segmented and logged across the estate
Traffic to the web and SaaS passes through a security service edge. Between internal zones, firewalls allow only flows we've actually observed. Cloud rules come from Terraform, and the SIEM collects firewall, DNS and SSE logs.
01 · Traffic sources
User devicesoffice · remote → Security service edge · web and SaaS→ Protective DNS · DNS queries→ Firewalls · internal traffic
Security service edgeEntra Internet Access → Internet and SaaS · inspected traffic
Firewallszone allow rules with owners → Server zone · allow rules→ Management and backup · admin hosts only→ OT network · change window→ SIEM · traffic logs
Protective DNSegress filtering
Cloud network policyTerraform · NSGs · security groups → Cloud VNets and VPCs · terraform apply
03 · Destinations
Internet and SaaStenant restrictions
Server zoneapps · databases
Management and backupisolated first
OT networkplant control systems
Cloud VNets and VPCsprivate endpoints
04 · Monitoring
SIEMfirewall · DNS · SSE logs
Read the diagram as text
User devices → Security service edge: web and SaaS
Security service edge → Internet and SaaS: inspected traffic
User devices → Protective DNS: DNS queries
User devices → Firewalls: internal traffic
Vendor remote access → Firewalls: brokered via PAM
Firewalls → Server zone: allow rules
Firewalls → Management and backup: admin hosts only
Firewalls → OT network: change window
Cloud network policy → Cloud VNets and VPCs: terraform apply
Firewalls → SIEM: traffic logs
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Collect
Configurations, rule bases, traffic logs and diagrams. If the diagrams are out of date, flow captures instead.
step 02
Analyze
Rule usage, internet exposure and segmentation gaps ranked by risk.
step 03
Change in batches
We roll out the clean-up and the new segmentation through your normal change process. Each batch has its own rollback.
step 04
Codify
Cloud rules and standard patterns moved into Terraform with review gates.
you keep
What you're left with
We write these for your Network Security setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Network security engineer
Firewall engineer
Cloud network engineer
SSE and ZTNA engineer
Network architect
due diligence · network security
Questions to ask any partner, including us.
Put these to anyone bidding on your Network Security work. The ones who've done it answer differently from the ones who've read about it.
Q1
How long a hit-count window will you use before calling a rule unused?
Thirty days misses quarter-end, annual and DR test traffic. The window has to cover your longest business cycle, or a disabled rule breaks something months later.
Q2
How will you build segment allow rules when our network diagrams are out of date?
Segmentation built from diagrams breaks undocumented flows. Ask for flow log or NetFlow capture, a monitor phase, and owner sign-off per flow.
Q3
Where will TLS inspection be turned off, and who decides?
Inspection breaks certificate pinning and touches health and banking traffic with privacy implications. Exclusions should be a written list with an owner, not ad hoc bypasses.
Q4
How are vendor remote sessions approved, recorded and ended?
Shared VPN accounts give vendors standing access nobody watches. Named, time-limited access through PAM or ZTNA should expire on its own and leave a record.
01Which firewall vendors do you work with?
Rule analysis, segmentation design and flow mapping are largely vendor-neutral, so that part of the work applies to any platform. For hands-on configuration, tell us what you run and we'll say plainly where we can do the work and where your vendor's own services are the better choice.
02Should we buy a single-vendor SASE platform?
It depends on your contracts and how much of your estate already runs on Microsoft. One vendor makes policy and support simpler. Pairing Entra Internet Access with the firewall or ZTNA vendor you have can cost less if the licenses are already paid for. We compare the options on your real traffic. A feature grid won't tell you much.
03How do you clean up a rule base without causing outages?
With evidence. We read hit counts over a window long enough to catch the monthly and quarterly jobs. Rules get disabled before they're deleted, and each batch is scheduled for a time when the application owners are around.
04Do you work on OT and industrial networks?
Yes, on segmentation design and remote access, which is where most OT exposure sits. We work with your control engineers, follow plant change windows, and plan changes on control networks more conservatively than IT changes.
05We already use CloudFormation or Bicep. Can you still manage our cloud network rules in Terraform?
Yes, though we'd usually extend whichever tool already manages your network so there's one source of truth. If you're consolidating on Terraform, we import existing resources into state first so nothing gets destroyed and recreated.
related
Often paired with
Projects on Network Security usually end up touching one of these, so they're worth a look.
