You Don't Just Defend Your Assets

The instinct in most security programs is to draw a perimeter around what the organization owns and controls, then defend that. It’s a reasonable starting point. It’s also increasingly insufficient.

The devices your employees bring from home. The SaaS platforms your business runs on. The code your vendors wrote and you’re running in production. The customer-facing applications processing payment data. None of these fit cleanly inside a traditional enterprise perimeter, and adversaries know it. Third-party compromise has been a consistent attack vector for years: the 2013 Target breach came through an HVAC vendor’s credentials; the 2020 SolarWinds compromise affected roughly 18,000 organizations through a single software vendor’s update mechanism.

The CDM’s answer to this is to extend the matrix beyond enterprise-owned assets. Not one CDM, but four.

The four asset rings

Sounil Yu describes the extended model as four distinct asset environments, each of which can be analyzed with its own instance of the 5x5 matrix:

Enterprise assets: The core. Everything the organization owns, operates, and is directly responsible for. Standard CDM application.

Employee assets: The personal devices, personal accounts, and home networks that employees bring into contact with enterprise systems. BYOD programs, personal mobile devices with corporate email, home broadband connections used for VPN. The organization doesn’t own these assets but has security dependencies on them.

Vendor/third-party assets: The systems and software your supply chain runs on. Your cloud providers, SaaS vendors, managed service providers, software development shops, and anyone else who has access to your data or whose software runs in your environment. You don’t control these assets, but a compromise there becomes your problem.

Customer assets: The devices and accounts your customers use to interact with your services. Relevant for any organization operating consumer-facing digital services: banking apps, e-commerce platforms, B2B portals. Customer-side compromise through credential stuffing, account takeover, or client-side malware affects your platform even if your own infrastructure is clean.

There’s a fifth environment worth acknowledging, though it operates differently: threat actor assets. Threat intelligence, dark web monitoring, deception technologies, and malware sandboxing are all capabilities oriented toward understanding or disrupting what adversaries are doing in their own environment. This row has fewer cells with obvious defensive controls but it’s a real part of the security investment picture.

Why this matters operationally

Running each ring as a separate CDM instance forces a different set of questions for each environment.

For employee assets, the relevant questions look like: what’s the minimum security posture I need on a personal device before it can access corporate resources? How do I detect anomalous behavior on a device I don’t own? If that device is compromised, what’s my respond posture? The tools that apply here (MDM, MAM, conditional access, mobile threat defense) are different from the tools you’d use for managed endpoints, and the RACI is different too: HR, Legal, and IT all have opinions about what you can require employees to do on personal devices.

For vendor assets, the CDM maps naturally to third-party risk management. The Identify column asks: what vendor systems have access to my environment, and what vulnerabilities do those systems have? The Protect column asks: what contractual and technical controls constrain what vendors can do in my environment? The Detect column is where most TPRM programs fall down: few organizations have meaningful visibility into what their vendors’ systems are doing. Vendor questionnaires (the industry’s current standard answer) are largely Identify/Process activities. They tell you what controls a vendor claims to have; they don’t tell you whether those controls work or whether the vendor’s environment is currently clean.

For customer assets, the coverage map looks completely different from the enterprise model. You can’t patch a customer’s browser. You can’t mandate MFA on their personal accounts (well, you can try, but the abandonment rate will remind you quickly that customers aren’t employees). The tools that operate here are fundamentally detection and fraud-oriented: device fingerprinting, behavioral biometrics, web fraud detection, account takeover monitoring. The Protect column is thin by design; the Detect column carries most of the weight.

The vendor ring in practice: where TPRM actually sits

Third-party risk management is a mature enough discipline to have its own certification track, its own software category, and its own regulatory requirements in most jurisdictions. It’s also, in practice, remarkably shallow in most organizations.

Mapping TPRM against the CDM reveals the problem immediately.

Identify/Vendor Assets: Most programs do this reasonably well. Vendor inventories exist. Risk questionnaires get sent. Due diligence processes (of varying rigor) run at onboarding. The data quality is often poor because it’s self-reported, but the process exists.

Protect/Vendor Assets: Contractual controls, scope-of-access limitations, network segmentation for vendor connectivity, privileged access management for vendor accounts. This is where variation between programs is highest. Some organizations treat third-party access as a fully managed identity and access problem. Others hand out VPN credentials and call it done.

Detect/Vendor Assets: Almost empty in most programs. Real-time monitoring of vendor activity in your environment requires either privileged access management tooling with session recording, or UEBA/behavioral analytics capable of profiling what “normal” looks like for a given vendor’s access patterns. Cloud Access Security Brokers (CASBs) partially address SaaS vendor visibility. Most organizations don’t have comprehensive coverage.

Respond/Vendor Assets: Incident response runbooks rarely have a specific playbook for “vendor account was compromised and used to access our environment.” The general IR process applies, but the specific actions (notify the vendor, revoke vendor access without breaking the business process that depends on it, determine scope of what the vendor touched) need to be pre-planned.

Recover/Vendor Assets: Vendor Risk Assessments, at least in theory, live here: post-incident evaluation of whether a vendor’s security posture justifies continued use. In practice, this function is driven almost entirely by business dependency rather than security posture.

This isn’t a criticism of TPRM as a discipline. It’s an observation that running the CDM against your vendor environment will show you exactly which parts of the program are developed and which aren’t.

The BYOD cell nobody wants to talk about

Employee assets are a governance problem as much as a technical one. The controls that apply to personal devices in a regulated industry look different from what’s acceptable in a technology company with a permissive culture. In Japan specifically, where personal device ownership patterns and enterprise mobility adoption lag some other APJ markets, the BYOD conversation often doesn’t happen until there’s an incident.

The CDM frames it correctly: employee assets get their own matrix. The question isn’t “do we allow BYOD” but rather “what coverage do we have in each cell of the employee asset environment, and what coverage are we missing?”

Missing coverage in Devices/Protect for employee assets might mean you have no way to enforce disk encryption or screen lock on personal devices. Missing coverage in Users/Detect might mean you have no behavioral baseline for what an employee’s remote access pattern looks like, so you can’t detect credential compromise on a personal account used for corporate access.

Both of those are specific, addressable problems. The CDM surfaces them. What you do about them depends on your regulatory environment, your employment agreements, and how much political capital you want to spend.

Applying the multi-ring model

You don’t need to run full CDM exercises on all four rings simultaneously. That’s a lot of scope and it will stall before it produces anything useful.

A practical sequencing:

Start with enterprise assets. Get the core CDM picture clear: your coverage, your gaps, your People/Tech imbalance. That exercise is valuable on its own and it establishes the baseline vocabulary for the conversations that follow.

Add the vendor ring next, specifically for your highest-criticality vendors: the ones with data access, code execution rights, or persistent network access to your environment. For most organizations, that’s a short list. Map the Identify and Detect cells for those vendors first, because those are most likely empty.

Then look at employee assets if you have significant BYOD exposure or remote work population. This one has a direct connection to identity and access management decisions, so it pairs well with any IAM modernization work.

Customer assets come later, and only if you’re operating consumer-facing services where client-side risk is a meaningful part of your threat model.

The goal isn’t to run four simultaneous CDM exercises. It’s to have a clear picture of which rings exist in your environment and which cells in those rings have no coverage at all. The blank cells in the extended model are often where incidents start.

Next: Article 3 — Using the CDM to Cut Through Vendor Noise