How to Protect Against Lateral Movement
To understand how to protect against lateral movement, you must isolate network zones and restrict user roles. You also need to verify every single command before it runs on a server or database. Most teams start by setting up firewalls and grouping servers into private subnets. They then assign cloud roles to users and apps so teams can do their jobs. Still, teams often make these roles too broad during busy incidents. When an attacker steals one broad key, they can move from one machine to ano
End-to-End Encryption: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand how to protect against lateral movement, you must isolate network zones and restrict user roles. You also need to verify every single command before it runs on a server or database. Most teams start by setting up firewalls and grouping servers into private subnets. They then assign cloud roles to users and apps so teams can do their jobs. Still, teams often make these roles too broad during busy incidents. When an attacker steals one broad key, they can move from one machine to another. They use that single login to read data across the whole cloud.
How to protect against lateral movement with native controls
Your first step is splitting your network into smaller, separate zones. You set up firewall rules so web servers can only talk to specific app servers. Those app servers can only talk to the database they need for daily work. You block direct traffic between developer laptops and production subnets. You also turn off shared admin accounts on every Linux and Windows machine. Instead, you link your cloud accounts to a central identity provider. Every engineer must log in with multi-factor checks before they get a cloud role. You scope each role down to the minimum permissions needed for one task. A billing app role should only read the billing tables, not the user tables. You also rotate keys and passwords on a strict schedule so old keys expire fast. This setup forces every user and service to prove who they are at the subnet door.
Where network and role limits fall short
Network zones and cloud roles are great for stopping outside traffic at the perimeter. They decide who can open a session to a database or a server. Still, they cannot see what happens inside that session once it starts. If an engineer has a valid role to fix a database, the network lets them in. If an attacker steals that engineer's active session, the firewall still lets them through. Native roles decide who logs in, not what individual statements or commands do in flight. Once inside, an attacker can run a query to dump all customer emails and phone numbers. They can also look for local keys saved in text files on that server. With those keys, they hop to the next server that shares the same network zone. Static roles and network walls cannot stop bad commands inside an allowed session.
Controlling actions at the command level
Stopping an attacker mid-hop requires checking every action right when someone runs it. Instead of trusting a whole session for hours, you check each query and shell command. If a user tries to run a risky delete command, the system pauses it. Another team member must review and approve that exact command before it runs. You can also apply data masking to rewrite sensitive fields like card numbers or national IDs in query results. This means an attacker who steals a session still gets masked text instead of raw records. By logging every single query and command, your security team can spot weird behavior right away. Moving security checks down to the command level cuts off the paths attackers use to spread.
End-to-End Encryption: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the main cause of lateral movement in cloud setups?
Overly broad roles and shared admin keys are the main causes. When one user or app has access to many servers, one stolen key opens them all. Attackers use these leftover keys to hop between machines without triggering login alerts.
Do firewalls and private subnets stop attackers from moving around?
Firewalls only block traffic on ports that do not need to talk to each other. Attackers move through the open ports that your apps and engineers use every day. Once they steal a valid login, the firewall lets their traffic pass right through.
How does data masking reduce the risk of a stolen session?
Data masking rewrites matched fields like emails, phone numbers, and card numbers in query results. Even if an attacker runs a query through a stolen session, the system masks the sensitive fields. This keeps raw customer records out of the query output.