Application Dependency Mapping

Application Dependency Mapping automatically captures which applications and systems actually communicate with one another and presents these relationships as a map. This article explains how it works and shows why reliable communication maps form the foundation of every microsegmentation and migration plan.

Before you can segment or migrate an application, you have to answer one question: who does it actually communicate with? In environments that have grown over time, no one often knows this answer in detail any more. Documentation is out of date, and behind many applications hang dependencies that are recorded nowhere. Application Dependency Mapping (ADM) closes this gap: it observes the actual communication and turns it into a reliable map that serves as the basis for both microsegmentation and migration planning.

What is Application Dependency Mapping?

Application Dependency Mapping refers to the automated capture and visualisation of the communication relationships between applications and the systems they run on. The data basis comes from telemetry in the running environment: agents on the workloads or flow data from the network record which process talks to which target over which port. From this raw data, a dependency map emerges that shows the actual state rather than the documented target state. That is precisely where the value lies: the map depicts what really happens, including the connections that no one knew about any more. Modern tools combine visibility and enforcement here: the same agents that observe flows also implement the segmentation rules later on.

How it works

Capture telemetry: Agents on servers and workloads or sensors in the network log connections with process, port and remote endpoint. Capture runs continuously so that rare events such as month-end closings also become visible.
Enrich context: Bare pairs of IP addresses say little. Workloads are therefore given metadata such as application membership and environment. This produces understandable statements: the web shop talks to the payment database.
Build the map: The relationships appear as an interactive map, grouped by application and filterable by environment. Because telemetry keeps flowing in, the representation stays close to real time.
Spot anomalies: The map also shows what no one expects to be there: connections from the test environment into production, or systems that should have been shut down long ago.
Derive policies: The observed flows give rise to suggested rules for segmentation. These can first be simulated to rule out operational disruptions before they are enforced.

Why it matters

No segmentation without a map: every segmentation rule presupposes knowledge of legitimate communication. Anyone who writes rules without this basis risks operational disruptions or ineffective policies.
Migrations without surprises: before a move to the cloud or a new data centre, the map shows which systems must move together and which connections would in future run over wide-area links.
Faster incident analysis: in a security incident, the map immediately shows which systems communicated with the affected workload and where an attacker could have moved.
Cleaning up with facts: the map exposes dead connections and forgotten systems, a factual basis for any consolidation.
Evidence instead of assumptions: auditors receive an up-to-date representation of the data flows, for example as proof of the separation of environments.

Typical scenarios

The most important field of application is preparing microsegmentation : before policies restrict east-west traffic in the data centre, the dependency map provides a reliable picture of legitimate communication. Rules then arise from observation rather than assumption. The second field is migrations: whether a cloud move or a data centre change, the map defines move groups, that is, systems that are migrated together because they are tightly coupled. Third, modernisation: before retiring a legacy application, the map shows who still depends on it. And fourth, compliance: wherever personal or payment-relevant data flows, audits require proof of the actual data paths. In Zero Trust programmes, the map also forms the starting point, because protection goals can only be formulated once the real communication paths are known.

ADM and CMDB: drawing the line

A Configuration Management Database manages inventory data: which systems exist and who owns them, supplemented by details such as installed software. This view is valuable, but it has two structural weaknesses. It is maintained manually or semi-automatically and therefore goes out of date quickly. And it knows configurations, but rarely the actual behaviour: whether two systems talk to each other appears there at best as a statement of intent. Application Dependency Mapping, by contrast, continuously observes the real behaviour and thereby keeps itself up to date. Where maintaining a CMDB demands interviews and manual work, telemetry delivers a first reliable picture within a short time. The two tools complement each other: the CMDB supplies master data and responsibilities, the dependency map supplies the behaviour. For segmentation and migration decisions, the observed communication is the more reliable source.

Working with KAEMI

For KAEMI, the dependency map is the first step of every segmentation project. Based on the Illumio platform, we map the communication of your workloads across data centre and cloud and derive policies from it that are simulated before enforcement. The result feeds directly into microsegmentation , with which lateral movement by attackers can be contained effectively. When a migration or restructuring is on the horizon, KAEMI supports you with Professional Services for analysis and planning on the basis of the map that has been collected. As a managed service provider, we operate the mapping on an ongoing basis so that it stays current, instead of ending as a one-off snapshot. You can get started via Contact .

Frequently asked questions about Application Dependency Mapping

Why does microsegmentation need a dependency map?

Segmentation rules describe which communication remains permitted. Without knowledge of the actual connections, every rule is guesswork: policies that are too strict interrupt business processes, ones that are too loose miss the point of the protection. The dependency map provides the factual basis and makes it possible to simulate planned rules first. Only once no legitimate connection would be blocked any longer does enforcement take place.

Is a well-maintained CMDB enough as a basis?

As an inventory, yes; as a basis for segmentation or migration decisions, rarely. A CMDB documents assets and responsibilities, but goes out of date quickly and depicts intentions rather than observed behaviour. Application Dependency Mapping measures the actual communication continuously. In practice, you combine both: master data from the CMDB gives the observed map context and owners.

Where does the data for the dependency map come from?

The most reliable source is lightweight agents on the workloads that capture connections together with the associated process, in the data centre as well as in the cloud. As a supplement or alternative, flow data from the network infrastructure and metadata from the cloud platforms serve the purpose. Continuous capture is decisive, because a one-off snapshot overlooks rare but business-critical connections.

How long does it take to arrive at a reliable map?

First insights appear shortly after the workloads are connected. For a reliable basis for decisions, an observation period of several weeks is advisable so that periodic events such as monthly or quarterly closings are also captured. The duration depends on the size and dynamism of the environment. After that, ongoing telemetry keeps the map permanently up to date.

Does Application Dependency Mapping also help with migrations?

Yes, it is one of the most important tools in migration planning. The map shows which systems are tightly coupled and should therefore move together as a move group. It makes visible which connections would run over wide-area links after the move and could cause latency problems. After the migration, it proves that no overlooked dependency leads back to the old environment.