Security Overview
Zero Trust Architecture
Zero Trust is a security paradigm built on the principle of "Never trust, always verify." Unlike traditional perimeter-based security (castle-and-moat), Zero Trust assumes that threats exist both inside and outside the network boundary. Every access request must be authenticated, authorized, and continuously validated regardless of where it originates.
The core tenet: no implicit trust is granted to any asset or user account based solely on physical or network location.
The Five Pillars of Zero Trust
Identity
Strong authentication (MFA), identity federation, continuous session validation. IdPs: Okta, Azure AD, Google Workspace.
Device
Device health attestation, MDM enrollment, endpoint compliance checks before granting access.
Network
Micro-segmentation, software-defined perimeters, encrypted east-west traffic (mTLS), no implicit LAN trust.
Application
Application-layer access controls, WAF, API gateways, per-request authorization checks.
Data
Data classification, encryption at rest and in transit, DLP, data access logging and anomaly detection.
Zero Trust Implementation Steps
- Know your traffic: Identify all users, devices, applications, and data flows
- Map the transaction flows: Understand how data moves across your environment
- Architect a Zero Trust network: Define micro-perimeters (protect surfaces)
- Create the Zero Trust policy: Who, what, when, where, why, how for each resource
- Monitor and maintain: Continuous inspection, logging, and adaptive policy enforcement
Threat Modeling
Threat modeling is a structured approach to identifying, quantifying, and addressing security risks early in the design phase. It answers the question: "What can go wrong?"
STRIDE Threat Model
STRIDE is a mnemonic for six categories of security threats, developed by Microsoft:
| Threat | Description | Violated Property | Example |
|---|---|---|---|
| Spoofing | Impersonating another user or system | Authentication | Forged JWT tokens, ARP spoofing |
| Tampering | Unauthorized modification of data | Integrity | SQL injection, MITM data modification |
| Repudiation | Denying performing an action | Non-repudiation | Deleting audit logs, unsigned API calls |
| Information Disclosure | Exposing data to unauthorized parties | Confidentiality | Misconfigured S3 buckets, verbose errors |
| Denial of Service | Disrupting service availability | Availability | DDoS attacks, resource exhaustion |
| Elevation of Privilege | Gaining unauthorized elevated permissions | Authorization | Container escape, SSRF to IMDS |
Attack Surface Analysis
Every exposed interface is a potential attack vector. Key attack surfaces in cloud-native environments:
- External APIs & endpoints: Public-facing REST/gRPC APIs, load balancers, ingress controllers
- Container images: Vulnerable OS packages, application dependencies, secrets baked into layers
- IAM configurations: Overly permissive roles, unused credentials, unrotated keys
- Infrastructure code: Terraform modules, Helm charts, Kubernetes manifests with misconfigurations
- CI/CD pipelines: Third-party actions, build environment secrets, artifact integrity
- Supply chain: Open-source dependencies, container base images, third-party SDKs
- Metadata services: AWS IMDS, GCP metadata server — accessible from any EC2/GCE workload
Threat Actors
| Actor | Motivation | Capability | Primary Threats |
|---|---|---|---|
| Nation-state APT | Espionage, disruption | Very high | Supply chain compromise, zero-days |
| Cybercriminal | Financial gain | High | Ransomware, data theft, cryptomining |
| Insider threat | Sabotage, personal gain | Medium | Data exfiltration, privilege abuse |
| Hacktivist | Ideological | Medium | DDoS, defacement, data leaks |
| Script kiddie | Recognition, fun | Low | Known CVE exploitation, scanning |
Security Frameworks Overview
NIST Cybersecurity Framework (CSF)
The NIST CSF provides a policy framework of computer security guidance for organizations. It is organized around five core functions:
Identify
Understand the organizational context, assets, risks. Asset management, risk assessment, governance.
Protect
Implement safeguards: access control, data security, protective technology, training.
Detect
Identify cybersecurity events: anomalies, continuous monitoring, detection processes.
Respond
Take action on detected events: response planning, communications, analysis, mitigation.
Recover
Maintain resilience and restore capabilities: recovery planning, improvements, communications.
CIS Controls v8
The CIS Controls (Center for Internet Security) are a prioritized set of 18 actions to protect against cyber attacks. They are grouped into three implementation groups (IG1, IG2, IG3) based on organizational maturity:
- IG1 (Basic Cyber Hygiene): Controls 1–6: Inventory, software inventory, data protection, secure configuration, account management, access control management
- IG2 (Foundational): Controls 7–16: Continuous vulnerability management, audit log management, email/browser protections, malware defense, network monitoring, network infrastructure, security awareness, service provider management, application software security, incident response
- IG3 (Organizational): Controls 17–18: Penetration testing, security awareness training program
ISO 27001 Key Domains
ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). Annex A contains 93 controls organized into 4 themes:
| Theme | Controls Count | Key Areas |
|---|---|---|
| Organizational | 37 | Policies, threat intelligence, IS in project management, supplier relationships, incident management |
| People | 8 | Screening, terms of employment, training, disciplinary process, remote working |
| Physical | 14 | Physical security perimeters, clear desk, equipment security, secure disposal |
| Technological | 34 | Access control, authentication, key management, network security, SIEM, vulnerability management |
Cloud Security Shared Responsibility Model
In cloud computing, security responsibilities are shared between the cloud provider and the customer. Understanding this boundary is critical — misconfiguration of customer-managed components is the leading cause of cloud security incidents.
| Layer | AWS | GCP | Azure | Responsible Party |
|---|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider | Cloud Provider |
| Hypervisor / virtualization | Provider | Provider | Provider | Cloud Provider |
| Network infrastructure | Provider | Provider | Provider | Cloud Provider |
| Managed service security (RDS, GKE, etc.) | Shared | Shared | Shared | Shared |
| Operating system (IaaS) | Customer | Customer | Customer | Customer |
| Network & firewall configuration | Customer | Customer | Customer | Customer |
| IAM & access management | Customer | Customer | Customer | Customer |
| Data encryption & integrity | Customer | Customer | Customer | Customer |
| Application code & config | Customer | Customer | Customer | Customer |
| Data classification & DLP | Customer | Customer | Customer | Customer |
Defense in Depth — Security Layers
Defense in Depth is a layered security strategy where multiple independent security controls are applied at different levels. If one layer fails, others continue to provide protection. This is analogous to a medieval castle with a moat, walls, towers, and guards — no single point of failure.
Security Layers (Outermost to Innermost)
Key Security Principles
Least Privilege
Grant only the minimum permissions required to perform a task. Review and revoke unnecessary access regularly. Apply to users, service accounts, and applications alike.
Need-to-Know
Access to sensitive data is granted only to those who need it to perform their job function. Data classification and compartmentalization enforce this principle.
Separation of Duties
No single person should control all aspects of a critical process. Require multi-party approval for sensitive operations (deployments, key ceremonies, access approvals).
Fail Secure
When a system or component fails, it should default to a secure state. Deny by default; deny if uncertain. Never fall back to plaintext or unauthenticated access on error.
Security by Design
Build security in from the start, not as an afterthought. Threat model during design, apply secure coding standards, and enforce security requirements as acceptance criteria.
Defense in Depth
Never rely on a single security control. Layer multiple independent mechanisms so that the failure of one does not result in a system breach.
DevSecOps: Shift-Left Security
Shift-left means integrating security testing and controls as early as possible in the software development lifecycle — moving it "left" on the timeline from production back to design and coding. The cost of fixing a vulnerability found in production is 6–100x higher than finding it at the code level.
Security Integration at Each SDLC Stage
| Stage | Security Activity | Tools |
|---|---|---|
| Plan | Threat modeling, security requirements | OWASP Threat Dragon, Microsoft TMT |
| Code | Secure coding, IDE plugins, pre-commit hooks | SonarLint, Semgrep, git-secrets |
| Build | SAST, dependency scanning, secret detection | Semgrep, Trivy, Gitleaks, Snyk |
| Test | DAST, IAST, container scanning | OWASP ZAP, Burp Suite, Trivy |
| Deploy | IaC scanning, policy-as-code, signing | Checkov, OPA/Kyverno, Cosign |
| Operate | Runtime security, CSPM, SIEM | Falco, AWS Security Hub, Wiz |
| Monitor | Threat detection, anomaly detection | GuardDuty, Chronicle, Datadog SIEM |
Next Steps
Explore the detailed topics in this Security section:
Identity management, RBAC/ABAC, AWS/GCP IAM deep dives, Kubernetes RBAC, MFA enforcement, and Privileged Access Management.
SAST, DAST, container security, supply chain security, IaC scanning, policy-as-code, and complete CI/CD security pipelines.
HashiCorp Vault, SOPS, AWS Secrets Manager, GCP Secret Manager, Kubernetes External Secrets Operator, and rotation patterns.
SOC 2 Type II, ISO 27001, CIS Benchmarks, PCI DSS, cloud compliance tools, audit logging, and compliance as code.