Security Overview

Core Principle: Security is everyone's responsibility — shift-left from code to cloud. Every engineer, platform team member, and operator shares accountability for building and maintaining a secure system. Security cannot be bolted on at the end; it must be woven into every stage of the software delivery lifecycle.

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

  1. Know your traffic: Identify all users, devices, applications, and data flows
  2. Map the transaction flows: Understand how data moves across your environment
  3. Architect a Zero Trust network: Define micro-perimeters (protect surfaces)
  4. Create the Zero Trust policy: Who, what, when, where, why, how for each resource
  5. 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

ActorMotivationCapabilityPrimary Threats
Nation-state APTEspionage, disruptionVery highSupply chain compromise, zero-days
CybercriminalFinancial gainHighRansomware, data theft, cryptomining
Insider threatSabotage, personal gainMediumData exfiltration, privilege abuse
HacktivistIdeologicalMediumDDoS, defacement, data leaks
Script kiddieRecognition, funLowKnown 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:

ThemeControls CountKey Areas
Organizational37Policies, threat intelligence, IS in project management, supplier relationships, incident management
People8Screening, terms of employment, training, disciplinary process, remote working
Physical14Physical security perimeters, clear desk, equipment security, secure disposal
Technological34Access 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 infrastructureProviderProviderProviderCloud Provider
Hypervisor / virtualizationProviderProviderProviderCloud Provider
Network infrastructureProviderProviderProviderCloud Provider
Managed service security (RDS, GKE, etc.)SharedSharedSharedShared
Operating system (IaaS)CustomerCustomerCustomerCustomer
Network & firewall configurationCustomerCustomerCustomerCustomer
IAM & access managementCustomerCustomerCustomerCustomer
Data encryption & integrityCustomerCustomerCustomerCustomer
Application code & configCustomerCustomerCustomerCustomer
Data classification & DLPCustomerCustomerCustomerCustomer
Common Misconception: Moving to the cloud does not mean the cloud provider secures your workloads. Misconfigured S3 buckets, overly permissive IAM roles, and unencrypted databases are customer responsibilities — and among the top causes of cloud data breaches.

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)

Perimeter — DDoS protection, WAF, DNS filtering, edge firewalls, CDN with geo-blocking
Network — VPCs, security groups, NACLs, private subnets, VPN/PrivateLink, network flow logs, IDS/IPS
Host — Hardened OS, CIS benchmarks, host-based firewall, EDR/AV, patch management, integrity monitoring
Application — SAST/DAST, dependency scanning, input validation, WAF rules, authentication, authorization, secrets management
Data — Encryption at rest (AES-256), encryption in transit (TLS 1.2+), RBAC on data stores, DLP, backup encryption, key management

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

StageSecurity ActivityTools
PlanThreat modeling, security requirementsOWASP Threat Dragon, Microsoft TMT
CodeSecure coding, IDE plugins, pre-commit hooksSonarLint, Semgrep, git-secrets
BuildSAST, dependency scanning, secret detectionSemgrep, Trivy, Gitleaks, Snyk
TestDAST, IAST, container scanningOWASP ZAP, Burp Suite, Trivy
DeployIaC scanning, policy-as-code, signingCheckov, OPA/Kyverno, Cosign
OperateRuntime security, CSPM, SIEMFalco, AWS Security Hub, Wiz
MonitorThreat detection, anomaly detectionGuardDuty, Chronicle, Datadog SIEM

Next Steps

Explore the detailed topics in this Security section: