Created
July 14, 2025 22:56
-
-
Save jonathanhle/a94718771d3ab46c9f745cba729040ae to your computer and use it in GitHub Desktop.
Revisions
-
jonathanhle created this gist
Jul 14, 2025 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,93 @@ # Security Organization Structure (Reference Model) This document outlines a structured and scalable security organization suitable for a high-growth, cloud-native technology company with significant infrastructure, regulatory obligations, and user-facing product surface area. The organization is designed for ~1,000 employees and ~150–200 engineers, and it aims to cover the entire security lifecycle: from build-time controls to runtime detection, incident response, compliance, and onchain or product-specific risk. --- ## 🌲 Security Org Tree with Inline Role Scopes ### 📎 Notation Each role in the org tree is followed by a `(num)` indicating **recommended headcount for that function**. ``` CSO/ ├── Deputy-CSO-or-CISO (1) — Strategic leadership; separates governance from execution ├── Security-Engineering (30) — Builds and defends core systems: AppSec, Infra, IAM, Crypto │ ├── Application-Security (7) — Secures code, libraries, pipelines, and partner teams │ │ ├── AppSec-Engineers (3) — SAST, secure reviews, bug triage, developer enablement │ │ ├── Threat-Modeling (1) — Architecture analysis and attack surface definition │ │ ├── Partner-Security (1) — Embedded security with product teams │ │ └── CI-CD-Security (2) — Protects the build pipeline, secret scanning, signing │ │ ├── Pipeline-Hardening (1) — Controls for Jenkins/GitHub/GitLab workflows │ │ └── Build-Signing-Tooling (1) — SLSA/Cosign, enforce artifact integrity │ ├── Infrastructure-Security (10) — Hardens infra runtime: cloud, containers, K8s, network │ │ ├── Cloud-Security (2) — IAM boundaries, SCPs, IaC policies │ │ ├── Host-Hardening (1) — Hardened AMIs, OS security, EDR config │ │ ├── Network-Architecture (1) — Segmentation, egress policies, bastion/ingress rules │ │ ├── PKI-Engineering (2) — Internal CA, mTLS, cert rotation, SPIFFE/SPIRE │ │ │ ├── Internal-CA (1) — Vault/StepCA management │ │ │ └── Cert-Lifecycle-Automation(1) — Rotate, revoke, alert │ │ ├── Container-Security (2) — Image scanning and runtime protection │ │ │ ├── Image-Scanning (1) — Build-time SBOM/Vuln checks │ │ │ └── Runtime-Enforcement (1) — Admission controls, runtime constraints │ │ └── Kubernetes-Security (2) — Cluster policy, RBAC, and control plane protection │ │ ├── Admission-Control-Policy(1) — OPA, Kyverno, baseline guardrails │ │ └── K8s-RBAC-Hardening (1) — Audit roles, limit escalation │ ├── IAM (4) — SSO, JIT, Secrets, Identity lifecycle across internal systems │ │ ├── Directory-Integration (1) — Okta/GWS/AAD SCIM connectors │ │ ├── RBAC/JIT-Access (1) — Role enforcement, TTL-based elevation │ │ └── Secrets-Management (2) — Vault, AWS KMS, secure workflows │ └── Cryptography (4) — Custody keys, MPC infra, HSMs, threshold signing │ ├── MPC-Platform (2) — Key orchestration and custody workflows │ └── Key-Lifecycle/HSMs (2) — Signing infra, key splits, storage logic ├── Security-Operations (16) — Detect, respond, and automate against real threats │ ├── Threat-Detection-and-Response (7) — Detection logic, SOAR, threat intel │ │ ├── Detection-Engineering (3) — SIEM pipelines, detections-as-code │ │ ├── Threat-Intel (2) — Actor mapping, TTPs, intel feeds │ │ └── SOAR-Automation (2) — Triage orchestration, auto-response playbooks │ ├── Incident-Response (5) — On-call, IR plans, forensics, containment │ │ ├── On-Call-IR (2) — Triage, escalation, coordination │ │ ├── Forensics/RCA (2) — Artifact handling, root cause │ │ └── Tabletop-Exercises (1) — IR maturity, team drills │ └── Insider-Threat (4) — DLP, high-risk access, behavioral monitoring │ ├── DLP-Monitoring (2) — GWS/DLP, SaaS monitoring │ └── Privileged-Access-Analytics (2) — Detection for abuse of access ├── GRC-and-Compliance (6) — Controls, policy, audit, vendor risk │ ├── Audit-Readiness (2) — SOC2, ISO27001, SOX testing │ ├── Risk/Control-Mapping (2) — NIST, CIS, CSA CCM frameworks │ ├── Vendor-Risk (1) — Third-party assessments and onboarding checks │ └── Policy-and-Awareness (1) — Internal policy docs and security training ├── Trust-and-Safety (5) — User trust, abuse prevention, fraud response │ ├── ATO-Detection/Mitigation (2) — Detect account takeovers, enforce MFA challenges │ ├── Abuse-Detection (1) — Scraping, spam, and API abuse │ └── Customer-Escalation-Support (2) — Handles inbound security tickets w/ CX ├── Blockchain-Security (4) — Smart contract risk, onchain analytics, bridge security │ ├── Smart-Contract-Review (2) — Manual audits, fuzzing, static analysis │ ├── Protocol/Bridge-Analysis (1) — Risk scoring of L1/L2 chains and bridges │ └── Onchain-Threat-Detection (1) — Real-time detection of illicit activity └── Security-Partners (3) — Embedded security engineers within core teams ├── Embedded-Infra-Squad (1) — Works with platform, DevOps, cloud teams ├── Embedded-Product-Squad (1) — Partners with feature teams on secure design └── Launch-Threat-Assessment (1) — Reviews high-risk launches and changes ``` --- ## 📊 Security Headcount vs Company Size (Recommended) | Company Size | Engineers | Recommended Security HC | % of Eng | |------------------|-----------|-------------------------|----------| | ~1,000 employees | 150–200 | 60–70 | 30–40% | | ~500 employees | 75–100 | 30–40 | 35–40% | | ~250 employees | 35–50 | 15–25 | 40–50% | --- ## 📈 How to Use - **Phase hiring**: prioritize InfraSec, AppSec, TDR, IAM, GRC → then scale out crypto/onchain/security partners - **Use the tree** to define ownership boundaries, accountability, team charters, and hiring plans - **Adapt to org size**: each sub-tree is independently scalable by company maturity