Systems lead after a cloud migration
Workloads moved quickly, security groups were opened to get things working, and nobody went back to close them.
Services
Know what your network exposes
We map what is reachable from the internet and from inside, find the permissions nobody meant to grant, and give you a segmentation plan your team can actually apply.
What arrives
- An inventory of every service reachable from the internet, and why
- A permissions review across cloud accounts, naming what is over-granted
- A segmentation plan, with the rules written for your firewall or cloud
- Findings on internal lateral movement, tested rather than assumed
Who this is for
Three profiles. If none of them is recognisably you, this is probably the wrong page - and the line below is the one worth reading before you book anything.
Not a fit: Skip this if you have no infrastructure of your own and run entirely on managed services, because there the account permissions matter and the network does not.
IT manager at a company with an office network
Every device can reach every other device, and a single compromised laptop would have the run of the place.
Engineering lead inheriting someone else's cloud account
There are roles and keys nobody recognises and no one is confident about deleting any of them.
What you get
- An inventory of every service reachable from the internet, and why
- A permissions review across cloud accounts, naming what is over-granted
- A segmentation plan, with the rules written for your firewall or cloud
- Findings on internal lateral movement, tested rather than assumed
- Logging and alerting gaps named, with what to turn on
- A retest confirming each change did what it was meant to
What we build it with
- nmap
- AWS IAM Access Analyzer
- Prowler
-
Terraform
- pfSense
- Tailscale
- Suricata
Chosen per project, not per fashion. If your team already runs something else and it works, we use that.
How the work runs
-
1
3-5 days
Map
We enumerate what is exposed externally and internally, and build the picture nobody currently has.
From you: A list of the domains, IP ranges and cloud accounts you own.
-
2
1-2 weeks
Test
We check what a compromised laptop or container could actually reach, rather than what the diagram says.
From you: A foothold host or a low-privilege account we may use.
-
3
1 week
Plan
We write the segmentation and permission changes in the order that reduces risk fastest.
From you: Who owns each system, so a change does not surprise a team.
-
4
1-2 weeks
Apply and retest
Your team applies the changes, we retest, and we confirm nothing legitimate broke.
From you: A maintenance window and an engineer on the call.
How we work together
Fixed project
Scope and price agreed up front. Best when the outcome is known and the deadline is real.
Dedicated team
A named team for a quarter or more. Best when the roadmap will change and you want the context kept.
Staff augmentation
Engineers inside your process and your tools. Best when you have the lead and need the hands.
Invoiced in
- USD
- EUR
- GBP
- CHF
- SGD
- AUD
- CAD
- AED
- SAR
- QAR
- JPY
- INR
Paid by
Card, netbanking, wallet and UPI through Razorpay, which is what our checkout runs on, so anything it accepts we accept. Bank transfer, SEPA, Wise and Payoneer for invoices that prefer it.
NDA before the first call. Full IP assignment on delivery. Contracts under Indian, English or Delaware law.
Work like this
Case studies are being written up
Three are in legal review. We can walk you through the work on a call in the meantime, including the parts that did not go to plan.
What clients say on Google
Live from our Google Business listing - not retyped here.
Loading reviews from Google - read them on Google.
Questions we get asked
It can, which is why the plan is ordered and applied in stages rather than all at once. We identify what currently depends on each over-broad rule before recommending its removal, and we ask for a maintenance window with an engineer present. Anything we are unsure about gets logged in monitor mode first, so you see what would break before it does.
Yes, and it is usually where the problems are. Security groups, VPC peering, load balancer rules and public storage buckets are all network decisions. Alongside them, the permissions model matters more in cloud than on a traditional network, so the review spends most of its time on roles, keys and what each workload can reach.
That one looks at your code and the running application. This one looks at everything around it: what is exposed, what can talk to what, and who holds which keys. A perfectly written application on a flat network with a public database is still a bad day. Most teams need both eventually, and we usually start with whichever is more exposed.
For the external map, no, only your written permission and the ranges you own. For internal testing we need a foothold: either a low-privilege account or a host we can work from, which mirrors what an attacker would have. We never need administrator credentials, and we say at scoping exactly what access each phase requires.
Not sure what is exposed?
Tell us the domains and cloud accounts you own and we will scope what a review would cover.