Security Principles

The following seven principles form the conceptual foundation of the Security pillar in WAF++. They are formulated technology-independently and apply across all cloud providers.

Principles are not controls. They explain the why behind the controls. A team that understands the principles makes better decisions even in situations that no control explicitly covers.

SP-1 – Security by Design

Security is planned from the start – not added after the fact.

Security measures added after the architecture phase are more expensive, more incomplete and harder to enforce. When network design, database schema and IAM structure are already in place, every security change is a compromise.

Security by Design means: security requirements are considered in the first design meeting, not in the last review before go-live. This includes threat modeling, data classification and IAM design.

Implication: No new feature, no new service without a brief security review at the beginning of the design. The result: security is a feature of the architecture, not a downstream patch.

Related Controls: WAF-SEC-010, WAF-SEC-020, WAF-SEC-050

Why it matters: Retrospective security hardening of existing systems is one of the biggest cost drivers in cloud security projects. Security by Design prevents technical debt that accumulates over years.

SP-2 – Least Privilege by Default

Every identity receives only the permissions it needs for its specific task – and nothing more.

Least Privilege is not a restrictive principle based on mistrust. It is a damage containment principle: if an account is compromised, minimal permissions limit the radius of the damage. A development account with read-only access to S3 cannot exfiltrate data from production.

Least Privilege also means: permissions are temporary, reviewable and revocable. Permanent admin roles for daily tasks are an anti-pattern.

Implication: Every new IAM role starts with minimal permissions and is extended when a concrete need is demonstrated. "Better too much than too little" is wrong. "Exactly what is necessary" is correct.

Related Controls: WAF-SEC-020

Why it matters: Most major cloud security breaches of recent years were based on excessive IAM permissions. Least Privilege is the most effective single measure for limiting the blast radius of an attack.

SP-3 – Defense in Depth

Multiple independent protection layers are better than a single strong control.

Defense in Depth is based on the recognition that every single security measure can fail. No password is uncrackable, no certificate eternal, no firewall rule error-free. When multiple independent controls are in place, an attacker must overcome all of them.

In the WAF++ context this means:

IAM controls access (who is allowed?)
Encryption protects data (even if access occurs)
Network segmentation limits lateral movement (even if a system is compromised)
Monitoring detects attacks (even if prevention fails)
Incident response limits damage (even if detection was delayed)

Implication: No single control replaces all others. WAF++ requires controls in all relevant layers. A system that is "secure" because it has a good firewall but no encryption and no monitoring does not meet the requirements.

Related Controls: WAF-SEC-030, WAF-SEC-040, WAF-SEC-050, WAF-SEC-080

Why it matters: Defense in Depth is the only concept that also provides residual protection against previously unknown attack vectors (zero days).

SP-4 – Zero Trust

No trust based on network location. Every request is explicitly authenticated and authorized.

The classic perimeter model – "internal is trusted, external is not" – is obsolete in the cloud era. In cloud environments there is no clearly defined perimeter: services communicate via API calls, developers access via VPNs and CI/CD systems execute code with service accounts.

Zero Trust replaces the question "Is the request from inside?" with:

Who is making the request? (Identity: user, service, workload)
What does the requesting entity want to do? (Permission: least privilege)
Is the device/environment trustworthy? (Context: device trust, runtime)

Implication: VPC-internal service-to-service communication is not implicitly trusted. Internal services also require mTLS, service accounts with minimal permissions and explicit authorization decisions.

Related Controls: WAF-SEC-010, WAF-SEC-020, WAF-SEC-040, WAF-SEC-050

Why it matters: Lateral movement – the spread of an attacker after the initial breach – is only possible because internal network communication is implicitly trusted. Zero Trust eliminates this risk.

SP-5 – Shift Left

Security is integrated into the pull request process – not just in the audit after deployment.

"Shift Left" means anchoring security checks as early as possible in the development process. The later a security problem is found, the more expensive and complex the remediation.

Phase of detection	Relative remediation effort
When writing the code (pre-commit hook)	1x
In the pull request (CI check)	10x
After the merge (staging scan)	50x
In production (incident)	100x+

Phase of detection

Relative remediation effort

When writing the code (pre-commit hook)

In the pull request (CI check)

10x

After the merge (staging scan)

50x

In production (incident)

100x+

In the WAF++ context Shift Left means:

Pre-commit hooks: run tfsec, checkov or wafpass locally
CI gates: WAF++ checker blocks PRs with critical findings
Container scanning: vulnerability scan before image push (not after deployment)
IaC linting: security rules in the same pipeline step as syntax checks

Implication: Security becomes part of the developer workflow, not a downstream process. Developers receive immediate feedback on security problems in the same context in which they write the code.

Related Controls: WAF-SEC-070, WAF-SEC-090

Why it matters: Shift Left dramatically reduces the average time to remediate security findings (MTTF – Mean Time to Fix) and prevents vulnerabilities from reaching production at all.

SP-6 – Immutability

Infrastructure is replaced, not repaired. No direct SSH access to production systems.

Immutable Infrastructure means: configuration changes are not made directly on running systems but by replacing the system with a new, pre-configured version. Patches are built into new AMIs or container images, not applied to running VMs.

This has security implications:

No SSH access: No direct shell access to production systems → no attack target
No config drift: What is deployed matches the IaC code – no manual changes
Forensics via logs: Incidents are analyzed using logs, not interactive debugging sessions

Implication: Any need for direct server access is a sign of a process problem. Debugging happens via centralized logging. Hotfixes go through the normal IaC deployment process (accelerated, but not shortcut).

Related Controls: WAF-SEC-010, WAF-SEC-020

Why it matters: Direct SSH/RDP access to production systems is one of the most common vectors for insider threats and external attackers. Immutability completely eliminates this attack surface.

SP-7 – Assume Breach

Plan for the case that an attacker is already in the system. Detection and response are just as important as prevention.

Assume Breach is a paradigm shift: instead of investing exclusively in prevention, one accepts that attacks can be successful and invests in detection and response.

Concretely this means:

Monitoring and SIEM are not optional – they are the answer to successful attacks
Incident response playbooks are tested before an incident occurs
Blast-radius minimization: if an account is compromised, how much damage can be done?
Data exfiltration prevention: even if someone is in the system, they should not be able to get data out

Implication: Every week without security monitoring is a week in which a successful attack goes unnoticed. Mean Time to Detect (MTTD) is one of the most important security metrics.

Related Controls: WAF-SEC-080, WAF-SEC-100

Why it matters: According to studies, the average breach goes undetected for over 200 days. Assume Breach forces monitoring investments that massively shorten this period.