Maximum Possible vs. Minimum Required: Designing for Real Users

Security programs have a uniformity problem. The instinct is to define a single security baseline and apply it to everyone in the organization. One endpoint policy, one acceptable use policy, one set of authentication requirements. Uniform, consistent, auditable.

Also often wrong.

A senior executive who travels internationally and needs to access sensitive systems from airports, hotels, and customer sites has a different risk profile, different operational constraints, and different acceptable friction levels than a call center agent who sits at the same desk every day, uses two applications, and handles high volumes of customer PII. Applying the same security design to both means either under-protecting the executive or making the call center agent’s job materially harder, usually both.

The CDM addresses this through what Yu calls security design patterns: a structured way to think about the maximum possible security posture for a given user context and whether that maximum is above or below the minimum required.

The design pattern concept

A security design pattern is the set of controls that apply to a specific user context. Not a generic “user” but a specific persona with specific characteristics: what systems they access, from where, on what devices, with what data, under what operational constraints.

Yu’s “Reloaded” presentation identifies eight common enterprise personas:

Office Workers: Standard office environment, managed devices, on-premises or cloud applications, moderate data sensitivity. The baseline persona that most security programs are implicitly designed around.

Road Warriors: Frequent travelers, high international exposure, access from uncontrolled networks, mix of managed and unmanaged endpoints. Elevated risk from network interception and physical device loss. Higher authentication burden is appropriate; high workflow friction is not.

Senior Executives: Access to sensitive financial, strategic, and personnel data. High-value targets for spear phishing and business email compromise. Often resist security controls more than other groups because of seniority. Need strong protection with low friction; getting both simultaneously is the design challenge.

Developers and Data Analysts: Elevated system access by job necessity, frequent interaction with production environments, use of personal tools and scripts, access to sensitive data for analytical purposes. Security restrictions that interfere with development workflows will be circumvented rather than accepted.

Call Centers: High-volume, repetitive work, access to significant quantities of customer PII, often on thin clients or locked-down workstations, typically higher staff turnover than other groups. The insider threat risk (data exfiltration at scale) is specific to this context.

Branch Office Workers: Remote from central IT, inconsistent physical security, potentially different network security posture than headquarters, may rely on local IT support with different skill levels. Geographic distribution creates asset inventory and patch management challenges.

Day Extenders: People who regularly work outside normal hours, often from home, mixing personal and professional activities on the same device or network. The boundary between personal and work activity is blurry.

Commodity Traders and Specialized Functions: Roles with extreme latency sensitivity, specialized hardware, regulatory requirements for specific trading environments, or other operational constraints that make standard security tooling impractical without affecting business outcomes.

Maximum possible vs. minimum required

For each persona, the CDM framework asks two questions that most security programs don’t ask clearly:

What is the maximum achievable security posture for this user context?

This is bounded by operational constraints, not just technical ones. A call center agent on a thin client with no USB ports and no internet access except through a web proxy can achieve a very high posture in the Devices row. Strong endpoint controls, locked-down configuration, no removable media. The constraints of their working environment enable aggressive security design.

A developer who needs root access to production debugging environments, uses a personal MacBook, writes code in a home office, and contributes to open-source projects in their personal time has a fundamentally lower maximum achievable posture in several cells because the operational requirements of the role conflict with the security controls you’d want to apply.

What is the minimum required security posture for this user context?

This is bounded by the risk the user context creates. A call center agent with access to 50,000 customer payment records has a high minimum required posture in the Data row. An executive with access to merger and acquisition planning documents has a high minimum in the Data row and the Users row (they’re high-value phishing targets). A developer with production deployment rights has a high minimum in the Applications row.

The comparison between maximum possible and minimum required determines whether you have a viable security design for that persona.

When maximum possible is below minimum required

This is the situation most security programs avoid looking at directly, because the honest answer is uncomfortable.

Yu’s example in the “Reloaded” presentation shows a persona where maximum achievable security posture is 50 (on a normalized scale) and minimum required posture is 55. You cannot get this user context to an acceptable security level given their operational constraints. The business model or operating environment creates an inherent security gap.

What do you do with that?

Option one: accept the residual risk explicitly, document it, and get sign-off from the appropriate business owner. Not the security team’s sign-off. The business owner’s sign-off, because they’re the one accepting the operational constraint that creates the gap.

Option two: change the operating model to increase maximum achievable posture. Maybe the role that requires both high-sensitivity data access and uncontrolled device access needs to be redesigned. Maybe the business process can be restructured so that the data-sensitive parts happen on managed, controlled devices and the device-uncontrolled parts of the job don’t touch sensitive data.

Option three: compensating controls that don’t affect the primary user workflow but add detection or monitoring capability to partially close the gap. You can’t encrypt the device, but you can add behavioral monitoring. You can’t restrict network access, but you can add DLP on the data layer.

What you can’t do, or shouldn’t do, is pretend the gap doesn’t exist. That’s where most programs end up: the security policy says employees must use managed devices, developers are using personal Macs, and nobody has formally acknowledged that the policy doesn’t match reality.

The bingo card analogy

Yu uses the term “security bingo card” for the CDM grid as applied to a specific persona. The controls that apply to this persona are the squares that are filled in. Squares that are empty because the operational context makes them infeasible are explicitly blank rather than silently absent.

The bingo card makes visible both what you’re doing and what you’re not doing, and why. It’s a better artifact for a risk acceptance conversation than a list of exceptions to a baseline policy, because it shows the full picture rather than just the delta from an assumed baseline.

For organizations that manage diverse user populations at scale (a bank with both trading floor staff and branch office tellers, for instance), maintaining a library of security design patterns by persona is more practical than trying to maintain a single policy with hundreds of exceptions. The patterns can be reviewed and updated as the threat landscape or operational requirements change, and new roles can be mapped to the closest existing pattern rather than built from scratch.

Where this connects to zero trust

The security design pattern approach intersects naturally with Zero Trust architecture, which Article 9 covers in more detail. The Zero Trust principle of never trust, always verify means that access decisions are made dynamically based on the assessed trustworthiness of the device, user, and context at the moment of the request.

The CDM design pattern approach feeds directly into what Zero Trust needs: a clear definition of what “trustworthy” looks like for each persona. What device posture is required before this user type can access this data? What authentication strength is required from this network location? What behavioral baseline should we expect from this role?

Without the design pattern work, Zero Trust policy tends to be either too permissive (falls back to role-based access control without context sensitivity) or too restrictive (breaks workflows for personas with legitimate operational constraints). The CDM gives you the persona analysis that Zero Trust policy needs to be calibrated correctly.

Practical starting point

Most organizations don’t have eight clearly defined security personas with formal design patterns. That’s fine. Start with two or three that represent meaningfully different risk profiles in your environment.

For a Japanese financial institution: start with branch office retail banking staff (high PII access, thin client environment, lower technical sophistication), corporate banking relationship managers (high client data sensitivity, mobile work patterns, international travel), and IT infrastructure staff (privileged access, development tools, production environment access). Those three personas cover a significant range of risk profiles and operational constraints.

For each persona, work through the CDM and identify: which cells have achievable, strong controls? Which cells have inherent gaps due to operational constraints? Is the minimum required posture achievable in each cell?

The output is three simple grids, each with green, yellow, and red cells. That’s more useful than a 400-page security policy that applies nominally to everyone and practically to no one.

Next: Article 8 — VA, Pentest, BAS, Red Team: What Each One Actually Tests