ThreatModel - Controls

Controls are the security controls we create for reducing risk and protecting your services from threats. They work by identifying what's authorized, preventing misuse, and detecting and recovering from security issues when they arise. When building controls, we start by understanding where threats exist—like misconfigured services, overly permissive access, or missing safeguards.

Some of the things we base controls around are:

• Know what’s authorized: Maintain a list of approved services, features, and resources.
• Defining proper use: Establish rules for how services and resources should be used.
• Enforce what’s allowed: Ensure only authorized items and configurations are deployed.
• Verify enforcement: Confirm protective mechanisms are working as intended.
• Restrict access: Use IAM, network policies, and org-level constraints to block unauthorized actions.
• Protect interactions: Consider the broader ecosystem (e.g., dependent services) when designing

Control Categories

Controls (COSO/NIST-aligned) are categorized based on their function and purpose:

Type	Description
Directive/Identify	Define what’s authorized (e.g., systems, accounts, data types).
Directive/Protect	Add non-cloud-native safeguards in code, pipelines, or app logic.
Directive/Detect	Enable logging or detection (e.g., container threat detection).
Directive/Respond	Define training or processes for compromised assets.
Directive/Recover	Train or prepare teams to recover after incidents.
Preventative/Protect	Use cloud-native tools to block unauthorized actions (e.g., IAM conditions, policies).
Detective/Detect	Monitor for compromise indicators using logs or metrics.
Corrective/Respond	Automate or guide incident response.
Corrective/Recover	Automate or guide post-incident recovery (e.g., backups).
Assurance/Detect	Validate that other controls are active and functioning (e.g., audit mode policies).

Control Dependencies, Testing, and Effort

• Dependencies: Controls may rely on others to function properly.
• Testing: Every control should be tested to ensure it works as intended.
• Effort Levels:
  • Very Low: Few clicks
  • Low: Quick documentation lookup
  • Medium: Adapt existing examples
  • High: Dedicated development work
  • Very High: Novel and complex work

• Examples

  ID	Objective	Type	Control	Effort
  1	Only deploy authorized resources	Directive/Identify	Maintain a list of approved resources	Low
  2	Only deploy authorized resources	Directive/Protect	Enforce only approved resources are used	Medium
  3	Only deploy authorized resources	Assurance/Detect	Detect unauthorized resources	Medium

Control Impact Ratings

Controls are rated based on how effectively they mitigate threats:

Impact	Reduction
Very High	>1,000x reduction in risk or likelihood
High	100x reduction in risk or likelihood
Medium	10x reduction in risk or likelihood, or detection with close to no false positives
Low	Marginal benefit or detection with false positives
Very Low	No direct reduction on threats or unreliable detection (lots of noise)

Prioritization of controls

For 1 threat

You can prioritize the control implementation based on the effort and the mitigation impact. Our default matrix for any given threat is as follow:

Across all threats

CVSS is taken into account when determining the control priority across threats, and create a CVSS-weighted priority score.