Policy Discovery, Application Dependency Mapping, and Policy Lifecycle
This domain tests how you get from raw flow data to an enforceable policy: ADM clustering, the scope/consumer-provider model, simulation, and the staged path to enforcement.
Application Dependency Mapping
ADM analyses historical flows over a window you choose - typically one to two weeks so monthly jobs are captured - and clusters workloads that communicate into dependency groups. You then name clusters, merge or split them, and promote a cluster into a scope with generated policy. ADM output is a draft: it faithfully reflects what happened, including traffic that should never have been allowed.
The policy model
- A scope is a hierarchical container whose members are selected by inventory filters.
- Inside a scope, rules are consumer → provider with ports and protocols; direction matters and reversing it produces a wrong policy.
- Once enforced, anything not described by a rule is denied, so every required flow must be stated explicitly.
- Infrastructure flows (DNS, NTP, monitoring, agent-to-sensor, patch servers) are usually handled as separate absolute policies so a catch-all does not quietly widen application access.
Lifecycle
Discover (flows, ADM) → design (scopes and rules) → simulate (policy analysis over historical flows: which flows would be denied?) → enforce in visibility mode → enforce → monitor drift. The simulation step is what candidates skip, and it is the step that prevents outages.
Worked example
A payments application: web → app on 8443, app → db on 3306, and all tiers to DNS on 53. Create scope payments-prod with the filter env=prod AND app=payments. Add web→app:8443 and app→db:3306, plus DNS as an absolute policy. Analysis over 14 days reports 12 flows that would be denied, including web→db:3306 - that is a finding to escalate to the application owner, not an automatic rule to add.
Traps
- Reversing consumer and provider, or matching on too broad a filter so unrelated hosts join the scope.
- Treating ADM clusters as finished policy.
- Omitting DNS, NTP, monitoring, and patching, then taking an outage at enforcement time.
- Enforcing on day one instead of running analysis against real traffic first.