A PRACTICAL GUIDE BY MATRIUM TECHNOLOGIES
Most organisations have controls designed to prevent and detect an initial compromise.
But if an identity, endpoint or workload is compromised, a different question becomes important:
What can it reach next - and how quickly can it be contained?
These five questions can help identify gaps in asset context, identity access, workload connectivity and containment.
You do not need a perfect CMDB or a major transformation program to begin. Start with one critical application, production environment or cloud account and build outward from there.
An asset inventory may show that a system exists without explaining what it supports, who owns it or how damaging its compromise would be.
How to get the answer
Start with the information already available across:
Cloud platforms and account inventories.
Endpoint and vulnerability-management tools.
Network and firewall records.
Existing CMDB or asset registers.
Application owners and infrastructure teams.
Add enough business context to distinguish one workload from another:
Application | Environment | Owner | Criticality | Internet exposure | Data sensitivity
Warning signs
Different tools produce conflicting asset lists.
Internet-facing or sensitive systems are not clearly identified.
Application owners cannot be established.
Production, development and testing assets are difficult to distinguish.
Criticality exists mainly as undocumented knowledge within individual teams.
What good looks like
A usable view of the assets supporting important business services, with enough context to prioritise exposure and make informed control decisions.
A practical starting point
Choose one critical application and establish its workloads, owners, environment, internet exposure and data sensitivity. A minimum viable view is more useful than waiting for a perfect enterprise-wide CMDB.
Formal permissions do not always show how an identity is actually being used.
Privileged users, service accounts, inherited access, shadow administrators and legacy authentication can create pathways that are difficult to see from directory records alone.
How to get the answer
Identify human, privileged, service and other non-human identities.
Observe real authentication activity over an appropriate period.
Map where authentication originates and which systems it reaches.
Review the protocols being used, including legacy authentication.
Identify excessive privileges, cross-tier access and MFA gaps.
Pay particular attention to service accounts with broad or poorly understood access.
Warning signs
Service accounts exist but nobody can clearly explain where or how they are used.
Privileged identities authenticate across security tiers.
Legacy authentication remains widespread.
MFA does not cover important systems, administrative tools or service identities.
Access reviews show assigned privileges but not actual authentication behaviour.
What good looks like
A current view of who or what is authenticating, from where, to which resources and using which protocols - supported by controls capable of challenging, restricting or denying inappropriate access as it occurs.
Credential vaulting and rotation remain important, but they do not determine whether a credential should be accepted each time it is used. At machine speed, even a short period of valid access can provide a meaningful opportunity for movement.
A practical starting point
Observe authentication activity for a defined application, identity group or period. Use the findings to identify high-risk access paths, unusual service-account behaviour, legacy protocols and gaps in authentication-time controls.
Network diagrams and firewall rules often show intended architecture. Observed communication shows what is actually occurring.
How to get the answer
Combine available asset, cloud and endpoint inventories.
Observe communication between workloads, applications and environments.
Include unmanaged workloads and unknown IP addresses.
Map dependencies supporting critical applications.
Identify connections that are permitted but may not be required.
Validate the resulting map with application owners.
Depending on the environment, this information may come from firewall and cloud-flow logs, agentless cloud telemetry or workload-level instrumentation.
Warning signs
Application dependencies are undocumented or outdated.
Development, test and production environments remain broadly connected.
Unmanaged systems do not appear in dependency maps.
Connectivity exists because “it has always been open.”
Teams are reluctant to restrict traffic because they cannot predict the impact.
What good looks like
A validated map of required communication between applications, workloads and environments, supported by enough business context to distinguish legitimate dependencies from unnecessary exposure.
A practical starting point
Select one critical application or cloud account. Observe its communication, identify the systems it depends on and validate those connections with the relevant owners.
Not every connection presents the same risk. Administrative access, excessive privileges, legacy protocols and inherited trust can allow an attacker to move more quickly.
How to get the answer
Review:
Privileged and administrative identities.
Service accounts and non-human identities.
Cross-tier and inherited access.
Trust relationships between domains, environments and applications.
Administrative protocols such as RDP, SMB, WinRM, Remote PowerShell and SSH.
High-risk or legacy protocols that remain broadly accessible.
Exceptions that are undocumented or no longer required.
Warning signs
Administrative ports are accessible from broad parts of the environment.
High-risk access is controlled mainly through credentials.
Exceptions do not have owners or expiry dates.
Service accounts have broad access across unrelated systems.
Nobody can explain whether an observed pathway is operationally necessary.
What good looks like
Administrative and high-risk access is limited to authorised identities, systems and pathways. Exceptions are approved, documented and reviewed.
A practical starting point
Identify broadly exposed administrative protocols and high-privilege access paths. Validate whether they are required, then progressively restrict unnecessary exposure through governed changes with rollback planning.
Detection does not automatically provide containment.
A security team may recognise suspicious activity but still depend on multiple teams, manual changes and lengthy approvals to stop it spreading.
How to get the answer
Test a realistic scenario:
Who is authorised to disable or restrict an identity?
Can suspicious authentication be challenged or blocked as it occurs?
Can an endpoint or workload be isolated without waiting for a major firewall change?
Can a critical application be ring-fenced from the wider environment?
Are quarantine, release and rollback procedures documented?
Have those procedures been tested with the relevant operational teams?
Warning signs
Containment depends on locating the right person during an incident.
Identity and workload isolation require separate, uncoordinated processes.
Teams have containment tools but have never tested them.
Nobody understands the likely business impact of isolation.
Releasing an incorrectly contained system is unclear or slow.
What good looks like
A governed and tested capability to restrict an identity, workload or application while investigation continues - with clear authority, logging, rollback and operational ownership.
A practical starting point
Run a tabletop or controlled technical exercise around one critical service. Measure how long it takes to restrict a compromised identity and isolate an affected workload, then identify the dependencies that slow the response.
Where should you start?
Poor asset context: Build a minimum viable view around one critical service.
Unclear identity exposure: Observe real authentication activity.
Unclear workload exposure: Collect communication telemetry and validate dependencies.
Known excessive access: Prioritise risky privileges, protocols and trust relationships.
Slow containment: Design and test identity and workload isolation procedures.
An unclear answer does not automatically mean another security product is required.
It identifies where better context, observed activity, control or validation may be needed.
Unsure which starting point fits your environment?
Matrium can help you work through the identity and workload sides of the problem and determine the most practical place to begin - without assuming the answer is another product.