SecOps Handbook — Security Operations Reference

🛡️

Introduction

What SecOps is, the defender's mindset, and core operating principles

Security Operations (SecOps) is the discipline of continuously protecting organizational assets through detection, response, and prevention. It bridges security engineering with real-time operational work — threat hunting, alert triage, incident handling, and security posture management.

Assume Breach

Operate as if adversaries are already inside. Focus on detection and lateral movement prevention, not just perimeter defense. Minimize blast radius.

Defense in Depth

Layer independent security controls so that failure of any single control does not result in full compromise. No single point of trust or failure.

Least Privilege

Every identity, system, and process gets the minimum access required to function. Reduce attack surface by eliminating standing privilege.

🔵

Modern SecOps: The shift to cloud-native, distributed architectures means traditional perimeter-based security is insufficient. Modern SecOps combines Zero Trust architecture, infrastructure-as-code security scanning, behavioral analytics (UEBA), and automated response (SOAR) to operate at cloud scale.

📐

Security Frameworks

NIST CSF, MITRE ATT&CK, CIS Controls — know which framework to use when

NIST CSF 2.0

The Cybersecurity Framework organizes controls around six functions for communicating posture to leadership and boards.

Govern — Policies, roles, risk management strategy
Identify — Assets, vulnerabilities, risk assessment
Protect — Safeguards, access control, awareness
Detect — Anomalies, monitoring, detection processes
Respond — Response planning, communications, analysis
Recover — Recovery planning, improvements

MITRE ATT&CK

A globally-accessible knowledge base of adversary TTPs (Tactics, Techniques, Procedures) based on real-world observations.

Use for: Detection coverage mapping, red team planning
14 Tactics: Recon → Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → C2 → Exfiltration → Impact
attack.mitre.org — full technique catalog

CIS Controls v8

18 prioritized controls providing prescriptive, actionable hardening guidance. Organized into three Implementation Groups (IG1–IG3) by organizational maturity. Essential starting point for SMBs and enterprises alike.

OWASP Top 10 / ASVS

Application Security Verification Standard (ASVS) provides testable requirements for web app security. Top 10 is the minimal checklist for any web-facing service. Use ASVS Level 2 as the baseline for production applications.

Framework	Best For	Output
NIST CSF 2.0	Executive communication, overall program assessment	Maturity tiers, function coverage score
MITRE ATT&CK	Detection coverage gap analysis, adversary emulation	Coverage heatmap, detection rules
CIS Controls v8	Baseline hardening, audit preparation	IG1/2/3 checklist completion
STRIDE	Application threat modeling in design phase	Threat list per component
PASTA	Risk-based application threat modeling	Attack simulation, risk scores
ISO/IEC 27001	Certification, third-party trust	ISMS, Statement of Applicability

🎯

Threat Modeling

STRIDE, data flow diagrams, and the four-question framework

Threat modeling is a structured process to identify, enumerate, and prioritize threats against a system before — and after — it is built. The goal is to answer: What can go wrong, and what are we doing about it?

01

Scope

Define system boundaries, actors, entry points

02

Decompose

Draw DFDs, identify trust boundaries

03

Identify

Apply STRIDE per component

04

Rate

Score with DREAD or CVSS

05

Mitigate

Controls, design changes, accepted risks

06

Validate

Review, test, iterate per sprint

STRIDE categories

Letter	Threat	Violates	Example	Mitigations
S	Spoofing	Authentication	Impersonate a user or service	MFA, mutual TLS, signed tokens
T	Tampering	Integrity	Modify data in transit or at rest	HMAC, digital signatures, TLS
R	Repudiation	Non-repudiation	Deny performing an action	Audit logs, signed transactions
I	Information Disclosure	Confidentiality	Expose sensitive data	Encryption, ACLs, data classification
D	Denial of Service	Availability	Exhaust resources	Rate limiting, auto-scaling, WAF
E	Elevation of Privilege	Authorization	Gain unauthorized permissions	Least privilege, input validation, RBAC

✅

Shift left: Run threat modeling in sprint 0 or during design review — not after code is written. Fixing a design flaw costs 10× less than patching a deployed vulnerability. Use OWASP Threat Dragon or Microsoft TMT for DFD tooling.

🔑

IAM & Zero Trust

Identity is the new perimeter — never trust, always verify

Zero Trust Pillars

Verify every request explicitly
Use least-privilege access
Assume breach — segment, monitor, encrypt
Evaluate: Identity, Device, Network, App, Data

Identity Hygiene

No shared accounts or service accounts with human names
Enforce MFA for all human identities
Regular access reviews (quarterly for privileged)
Disable stale accounts within 24 hours of offboarding

Privileged Access

Just-in-Time (JIT) access — no standing admin
Privileged Access Workstations (PAW) for admins
Break-glass accounts: vaulted, monitored, rotated
Record all privileged sessions

Zero Trust maturity levels (CISA)

Pillar	Traditional	Initial	Advanced	Optimal
Identity	Passwords only	MFA deployed	Risk-based auth, phishing-resistant MFA	Continuous validation, behavior analytics
Devices	Unknown endpoints	MDM enrolled	Compliance posture gates access	Real-time health signals, auto-remediation
Network	Flat network, VPN	Micro-segmentation started	Encrypted east-west, service mesh	Identity-aware network, no implicit trust
Applications	On-prem, VPN-gated	SSO, MFA on critical apps	App-level authz, CASB	Least-priv API access, continuous monitoring
Data	Perimeter encryption only	Data classification	DLP controls, encryption at rest	Object-level encryption, auto-classification

🔒

Authentication

MFA, passkeys, token standards, and session security

MFA Hierarchy (strongest → weakest)

🥇 FIDO2 / Passkeys — phishing-resistant, hardware-bound
🥈 Hardware security keys (YubiKey) — FIDO U2F/CTAP
🥉 TOTP apps (Authenticator) — susceptible to real-time phishing
⚠️ Push notifications — MFA fatigue attack vector
❌ SMS OTP — SIM-swap, SS7 attacks
❌ Email OTP — account takeover chain risk

JWT / OAuth 2.0 / OIDC

Sign JWTs with RS256 or ES256 — never HS256 in multi-party systems
Validate iss, aud, exp, nbf on every request
Short-lived access tokens (15m–1h), longer refresh tokens
Rotate refresh tokens on use (rotation + reuse detection)
Use PKCE for all public OAuth clients
Never store tokens in localStorage — prefer httpOnly cookies

JWT validation checklist

# Required validations on every token verification
# 1. Signature
alg = header['alg']   # Must be in allowlist — reject 'none', 'HS256' if RS key expected
verify_signature(token, public_key)

# 2. Claims
assert claims['iss'] == EXPECTED_ISSUER      # issuer
assert claims['aud'] == MY_CLIENT_ID          # audience
assert claims['exp'] > now()                  # not expired
assert claims['nbf'] <= now()                  # not before
assert claims['iat'] < now() + CLOCK_SKEW       # issued at (allow ~5 min skew)

# 3. Revocation (if needed)
assert token_id not in revocation_cache       # check jti against blocklist

⚠️

Algorithm confusion attacks: Always enforce the expected algorithm server-side. Never trust the alg header alone. An attacker can switch from RS256 to HS256 and sign with the public key as the secret if the server blindly accepts the header's algorithm claim.

🎛️

Authorization & RBAC

RBAC, ABAC, ReBAC — choosing and implementing access control

Model	Description	Best For	Complexity
RBAC	Role-Based: permissions assigned to roles, roles to users	Enterprise apps with clear job functions	Low
ABAC	Attribute-Based: policies using user, resource, and environment attributes	Fine-grained, context-sensitive access (e.g., "only during business hours")	High
ReBAC	Relationship-Based: access based on graph relationships (e.g., Google Zanzibar)	Hierarchical data, social/collaboration apps	Medium
PBAC	Policy-Based: centralized policy engine (e.g., OPA, Cedar)	Multi-service, complex logic, audit trails	Medium

MUST

Enforce server-side always

Authorization checks on the server. Never rely on UI to hide controls — assume the client is hostile. Check on every request, not just at login.

MUST

Deny by default

Default to "deny all" and explicitly allow. An unconfigured permission must result in denial, not access.

SHOULD

Centralize policy

Use a policy engine (OPA, Cedar, Casbin) rather than scattered if checks throughout code. Centralization enables auditing and consistent enforcement.

AVOID

IDOR vulnerabilities

Always verify the requesting user owns or has access to the requested resource ID. Never assume a valid session means access to any object ID.

📡

SIEM & Logging

What to log, log quality, and SIEM query patterns

The logging imperative: security logs you must have

Source	Critical Events	Retention
Authentication	Login success/fail, MFA events, password reset, account lock, token issued/revoked	1 year
Authorization	Access granted/denied, privilege escalation, role changes	1 year
Network	Firewall accepts/drops, DNS queries, VPN connections, unusual egress	90 days
Endpoints	Process creation (EventID 4688), script execution, driver load, USB events	90 days
Cloud API	All control-plane actions (CloudTrail, Activity Log), IAM changes	1 year
Applications	Errors, input validation failures, admin actions, data exports	90 days
Data access	Access to sensitive datasets, bulk downloads, schema changes	1 year

Log quality standards

JSON — structured log event

{
  "timestamp":  "2025-03-14T09:26:53.412Z",   // ISO 8601 UTC — always
  "level":       "WARN",
  "event_type":  "auth.login_failed",             // structured taxonomy
  "actor": {
    "user_id":   "usr_9k2xz",
    "ip":        "198.51.100.42",
    "user_agent": "Mozilla/5.0 ..."
  },
  "resource": {
    "type":     "console",
    "service":  "auth-service"
  },
  "outcome":     "failure",
  "reason":      "invalid_password",
  "request_id":  "req_abc123",            // trace correlation ID
  "session_id":  "sess_xyz789"
}

# Anti-patterns in logs:
# ❌ "User login failed"                        — unstructured, not queryable
# ❌ Logging passwords, tokens, PII in plaintext — data leakage
# ❌ Local timestamps without timezone           — correlation nightmare
# ❌ Inconsistent field names (userId vs user_id) — schema chaos

Common SIEM detection queries (Splunk / KQL patterns)

KQL — Microsoft Sentinel

// Brute force detection — 10+ failures in 5 min
SigninLogs
| where ResultType != "0"
| summarize FailCount=count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailCount >= 10
| project TimeGenerated, UserPrincipalName, IPAddress, FailCount

// Impossible travel — same user from 2 countries within 1 hour
SigninLogs
| where ResultType == "0"
| summarize Locations=make_set(Location) by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Locations) > 1

// New admin account created outside business hours
AuditLogs
| where OperationName == "Add member to role"
    and TargetResources[0].displayName contains "Admin"
    and (hourofday(TimeGenerated) < 8 or hourofday(TimeGenerated) > 18)

// Mass data export — user downloads >100 files in 1 hour
OfficeActivity
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull")
| summarize Downloads=count() by UserId, bin(TimeGenerated, 1h)
| where Downloads > 100

🔍

Detection Engineering

Detection-as-code, Sigma rules, alert quality, and the detection lifecycle

Detection engineering is the practice of creating, testing, deploying, and maintaining security detections as code — with the same rigor as software engineering. Every detection should have a clear hypothesis, test cases, and documented false positive rate.

Detection quality metrics

True Positive Rate

Percentage of alerts that are genuine threats. Target: >40% for operational detections. Low TPR = alert fatigue and missed detections.

Mean Time to Detect

Average time from attacker action to alert firing. Target: <15 minutes for high-severity TTPs. Benchmark against MITRE ATT&CK technique dwell times.

Detection Coverage

Percentage of MITRE ATT&CK techniques with at least one active detection. Track per tactic to identify blind spots (Common gap: Credential Access, Defense Evasion).

Sigma rule — portable detection format

YAML — Sigma rule

title: Suspicious PowerShell Encoded Command Execution
id: 7f92d827-4c5d-4e7a-9b93-2f5c1ae4c823
status: production
description: Detects PowerShell execution with base64 encoded command — common in malware and fileless attacks
references:
  - https://attack.mitre.org/techniques/T1059/001/
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - ' -EncodedCommand '
      - ' -enc '
      - ' -ec '
  filter_legit:
    ParentImage|endswith: '\sccm.exe'  # known SCCM usage
  condition: selection and not filter_legit
falsepositives:
  - Legitimate software management tools
  - Security tools using encoded payloads
level: high
fields:
  - CommandLine
  - ParentImage
  - User

🔧

Detection-as-code workflow: Store Sigma rules in Git → CI pipeline validates syntax and runs against test events → deploy to SIEM with PR review. Use sigma-cli to convert rules to Splunk SPL, KQL, or Elastic DSL. Version all detection changes for rollback.

🩺

Vulnerability Management

CVSS scoring, SLA tiers, patch prioritization, and EPSS

Vulnerability SLA by severity

Severity	CVSS Range	Criteria	Patch SLA	Compensating Control
CRITICAL	9.0–10.0	Remote code execution, unauthenticated, internet-exposed	24 hours	Isolate system immediately if patch unavailable
HIGH	7.0–8.9	High impact, may require auth or local access	7 days	WAF rule, network ACL, disable feature
MEDIUM	4.0–6.9	Limited impact or significant complexity required	30 days	Document risk acceptance if delayed
LOW	0.1–3.9	Minimal impact, difficult to exploit	90 days	Risk acceptance acceptable
INFO	0.0	Configuration finding, hardening recommendation	Next cycle	Track in backlog

ℹ️

CVSS ≠ risk priority. CVSS scores a vulnerability in isolation. Use EPSS (Exploit Prediction Scoring System) to prioritize by probability of exploitation in the wild. A CVSS 7.5 with EPSS 0.85 is more urgent than a CVSS 9.0 with EPSS 0.02. CISA's Known Exploited Vulnerabilities (KEV) catalog is the highest-priority source — these must be patched within 14 days for federal systems (CISA BOD 22-01).

bash — vulnerability pipeline

# Container image scanning in CI (Trivy)
trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest

# SBOM generation (Syft) — track all dependencies
syft myapp:latest -o spdx-json > sbom.json

# Check against CISA KEV catalog
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.product == "log4j")'

# Infrastructure scanning (Prowler — AWS/GCP/Azure)
prowler aws --compliance cis_level2_aws_well_architected_framework

# Secret scanning (pre-commit hook)
gitleaks detect --source . --verbose

🚨

Incident Response Lifecycle

PICERL: Preparation through Lessons Learned

01

Prepare

Playbooks, tooling, training, retainer

02

Identify

Detect, triage, declare incident

03

Contain

Stop spread, preserve evidence

04

Eradicate

Remove attacker, close entry point

05

Recover

Restore services, verify integrity

06

Review

PIR, timeline, improvements

Incident severity classification

Severity	Criteria	Response Time	Escalation
SEV-1	Active breach, ransomware, data exfiltration, production down	Immediate — 24/7 response	CISO, Legal, Executive team, retainer
SEV-2	Suspected compromise, targeted phishing with creds, critical vuln being exploited	<1 hour	Security manager, IR team lead
SEV-3	Policy violation, minor malware, isolated endpoint compromise	<4 hours (business hours)	SOC lead
SEV-4	Security misconfiguration, suspicious but unconfirmed activity	Next business day	Analyst on duty

🚫

Containment before eradication. Never remove malware or patch the entry point before containing the incident — you'll tip off the attacker and lose forensic evidence. First: isolate, preserve memory and disk images, capture network traffic. Then eradicate. Evidence collected after remediation is often inadmissible and untrustworthy.

📋

IR Playbooks

Phishing, ransomware, credential compromise, insider threat

Phishing / BEC playbook

Playbook — Phishing Response

## DETECT
□ Email reported by user OR auto-flagged by email gateway
□ Preserve original headers (X-Originating-IP, DKIM, SPF, DMARC results)
□ Extract and sandbox all URLs and attachments (VirusTotal, Any.run)

## SCOPE
□ Search mail gateway for same sender/subject/attachment hash across all mailboxes
□ Identify all recipients — did anyone click the link?
□ Query proxy/DNS logs for connections to phishing domain (last 24h)
□ Check if any credentials were entered (CASB, IdP login events)

## CONTAIN
□ Block phishing domain in email gateway, DNS, and proxy
□ Quarantine / delete email from all inboxes
□ If credentials compromised: force password reset + revoke all sessions immediately
□ If endpoint visited URL: isolate for forensics

## ERADICATE
□ Reset credentials for all potentially affected accounts
□ Review OAuth app grants for malicious consent (common in BEC)
□ Remove any mail rules created by attacker (forwarding rules)
□ Check for new MFA device registrations or added recovery emails

## NOTIFY
□ Inform affected users with clear instructions
□ If PII exposed: notify Privacy/Legal within regulatory window (72h GDPR)
□ Document IOCs: sender, domains, IPs, hashes

Ransomware playbook (immediate actions)

Playbook — Ransomware (SEV-1)

## T+0: FIRST 15 MINUTES
□ DECLARE SEV-1 — activate IR retainer / war room immediately
□ DO NOT pay ransom without legal and executive approval
□ ISOLATE affected systems — pull network cable, disable Wi-Fi (do not power off)
□ Preserve memory: capture RAM dump BEFORE isolation if possible

## T+15min: SCOPE
□ Identify patient zero — first infected host from EDR telemetry
□ Map lateral movement — which hosts have communicated with patient zero?
□ Identify ransomware variant (upload note + sample to ID Ransomware.com)
□ Check backup integrity — confirm backups are clean and not encrypted

## T+1hr: CONTAIN
□ Block C2 IOCs at firewall/DNS
□ Disable compromised accounts — assume all domain credentials stolen
□ Isolate domain controllers if reached
□ Engage Active Directory team — attackers likely have domain admin

## T+2hr+: ASSESS & RECOVER
□ Determine if decryptor available (NoMoreRansom.org)
□ Begin recovery from clean backups in isolated environment
□ Legal: assess breach notification requirements by jurisdiction
□ Forensics: preserve evidence chain of custody for potential prosecution

🔬

Digital Forensics

Evidence collection, memory forensics, disk analysis, and chain of custody

Order of Volatility

Collect evidence from most to least volatile:

1. CPU registers, cache, running processes
2. RAM / memory dump
3. Network state (connections, ARP, routing)
4. Running services and processes (full detail)
5. File system metadata (timestamps, MFT)
6. Disk image (full forensic copy)
7. Remote logging (SIEM, cloud logs)
8. Backups and archives

Chain of Custody

Document every person who accesses evidence
Timestamp all collection actions (UTC)
Hash all evidence (SHA-256) immediately at collection
Store originals in write-protected, sealed media
Work only on verified copies
Use tamper-evident packaging for physical media
Maintain custody log for litigation hold

bash — evidence collection commands

# Memory acquisition (Linux — LiME kernel module)
insmod lime.ko "path=/mnt/evidence/mem.lime format=lime"
sha256sum /mnt/evidence/mem.lime > /mnt/evidence/mem.lime.sha256

# Disk imaging (dd with verification)
dc3dd if=/dev/sda of=/mnt/evidence/disk.img hash=sha256 hlog=hash.log

# Network state capture
ss -tulpn       > /mnt/evidence/network_sockets.txt
arp -an         > /mnt/evidence/arp_table.txt
ip route show   > /mnt/evidence/routing.txt
tcpdump -i any -w /mnt/evidence/capture.pcap &

# Process and system state
ps auxf         > /mnt/evidence/processes.txt
lsof -n         > /mnt/evidence/open_files.txt
netstat -anlp   > /mnt/evidence/netstat.txt
cat /proc/*/cmdline 2>/dev/null > /mnt/evidence/proc_cmdlines.txt

# Windows — collect with KAPE or Velociraptor
# Velociraptor artifact collection (remote, no agent required)
velociraptor artifacts collect Windows.KapeFiles.Targets --output /evidence/

🏗️

Secure SDLC

Security at every phase — from design to deployment

SDLC Phase	Security Activity	Tools / Standards
Requirements	Security requirements, abuse cases, data classification	OWASP ASVS, privacy impact assessment
Design	Threat modeling, architecture review, trust boundary mapping	STRIDE, PASTA, Threat Dragon, Microsoft TMT
Development	Secure coding guidelines, peer review, pre-commit hooks	gitleaks, semgrep, language-specific linters
Testing	SAST, SCA, DAST, unit tests for security controls	Snyk, OWASP ZAP, Burp Suite, Semgrep
Build / CI	Container scanning, SBOM generation, IaC scanning	Trivy, Syft, Checkov, tfsec, Terrascan
Deploy	Secret injection, signed artifacts, runtime security policy	Vault, SOPS, Sigstore, OPA/Gatekeeper
Operate	DAST in production, pentesting, bug bounty, SIEM monitoring	HackerOne, Detectify, Qualys, Nessus
Retire	Secure decommission, certificate/key rotation, data deletion	Data retention policy, key rotation runbook

OWASP Top 10 — 2021

A01

Broken Access Control

#1 risk. IDOR, privilege escalation, missing authz checks. Enforce on every request server-side.

A02

Cryptographic Failures

Sensitive data transmitted or stored without strong encryption. Enforce TLS 1.2+, ban MD5/SHA1 for security, use AES-256-GCM.

A03

Injection

SQL, OS command, LDAP, SSTI injection. Parameterized queries always. Never concatenate user input into commands.

A04

Insecure Design

Missing security controls in design phase. Threat model before coding, not after. Security requirements are functional requirements.

A05

Security Misconfiguration

Default credentials, unnecessary features enabled, verbose errors in prod. IaC scanning + CIS benchmarks as CI gates.

A06

Vulnerable Components

Known CVEs in dependencies. SCA scanning in CI, SBOM tracking, automated dependency update PRs (Renovate/Dependabot).

🗝️

Secrets Management

Where secrets live, how they rotate, and what to scan for

Secrets Anti-patterns

❌ Hardcoded in source code
❌ In environment variables baked into container images
❌ In CI/CD logs or build artifacts
❌ In .env files committed to git
❌ Shared via Slack, email, or ticketing systems
❌ Same secret used in dev and production
❌ Secrets that never rotate

Secrets Best Practices

✅ Centralized secret store (Vault, AWS Secrets Manager, Azure Key Vault)
✅ Dynamic secrets — generated per-request, short TTL
✅ Rotation automated and tested
✅ Access to secrets requires authentication + authorization
✅ Pre-commit scanning (gitleaks, detect-secrets)
✅ Secret access audited and alerted
✅ Separate secrets per environment

bash — secrets hygiene

# Install gitleaks pre-commit hook
cat > .git/hooks/pre-commit <<'EOF'
#!/bin/bash
gitleaks detect --staged --no-banner
EOF
chmod +x .git/hooks/pre-commit

# Scan entire git history for leaked secrets
gitleaks detect --source . --no-banner --report-format json --report-path leaks.json

# HashiCorp Vault — dynamic DB credentials (example)
vault write database/config/my-postgres \
    plugin_name=postgresql-database-plugin \
    allowed_roles="app-role" \
    connection_url="postgresql://{{username}}:{{password}}@db:5432/mydb"

# App retrieves short-lived credentials (valid 1 hour)
vault read database/creds/app-role
# → Key: username  Value: v-app-role-xyz123   (auto-created)
# → Key: password  Value: <random 64-char>    (auto-revoked after TTL)

# SOPS — encrypt secrets file for GitOps
sops --encrypt --age $(cat ~/.config/sops/age/keys.txt | grep public | awk '{print $4}') \
    secrets.yaml > secrets.enc.yaml

🌐

Network Security

Segmentation, TLS standards, firewall policy, and DNS security

TLS configuration standards

Setting	Required	Banned
Protocol versions	TLS 1.2, TLS 1.3	SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
Key exchange	ECDHE-RSA, ECDHE-ECDSA, DHE (2048+ bit)	RSA key exchange (no forward secrecy), EXPORT ciphers
Ciphers	AES-128/256-GCM, ChaCha20-Poly1305	RC4, DES, 3DES, NULL ciphers, EXPORT ciphers
Certificate	RSA 2048+ or ECDSA P-256+, SHA-256 signature	MD5, SHA-1 signatures, self-signed in production
HSTS	`max-age=63072000; includeSubDomains; preload`	Missing header, max-age < 6 months

MUST

Micro-segmentation

Default-deny between workloads. Web → App → DB tiers with explicit allow rules only. East-west traffic must be authenticated and encrypted.

MUST

DNSSEC + DoH/DoT

Enable DNSSEC on authoritative zones. Use DNS-over-HTTPS or DNS-over-TLS for resolver traffic. Monitor for DNS tunneling (unusually large TXT/NULL queries).

SHOULD

Egress filtering

Allow-list known-good egress destinations. Block all others by default. Most C2 and data exfiltration relies on unrestricted outbound access.

AVOID

Flat networks

A single breach in a flat network = full lateral movement. Segment by data sensitivity, not just function. Crown jewels must be in their own segment with strict access controls.

📜

Compliance & GRC

SOC 2, ISO 27001, PCI DSS, GDPR, HIPAA — what applies and when

Framework	Scope	Mandatory?	Key Controls	Audit Cycle
SOC 2 Type II	SaaS/cloud service providers handling customer data	Customer-driven (B2B trust)	Security, Availability, Confidentiality, Privacy TSCs	Annual (6–12 month observation period)
ISO/IEC 27001	Any organization — ISMS-level	Customer/contract driven	114 controls across 14 domains (Annex A)	Annual surveillance, 3-year recertification
PCI DSS v4.0	Any entity handling cardholder data	Yes (card brand mandate)	12 requirements — network, access, crypto, monitoring	Annual QSA assessment or SAQ
GDPR / UK GDPR	Processing personal data of EU/UK residents	Yes (law)	Lawful basis, data minimization, 72h breach notification, DPO	Ongoing; DPA audits on complaint/incident
HIPAA	US healthcare — covered entities and BAs	Yes (US federal law)	PHI safeguards, BAAs, breach notification, audit controls	HHS OCR audits; self-assessment
NIST SP 800-53	US federal systems (FedRAMP for cloud)	Federal systems	1000+ controls across 20 families	Continuous monitoring; ATO renewal

✅

Compliance ≠ Security. Compliance is a minimum bar — passing a SOC 2 audit does not mean you are secure, only that you met a snapshot of controls at a point in time. Use compliance to formalize your program, but build security posture around threat-informed defense (ATT&CK coverage, vuln management, detection engineering) rather than checkbox compliance.

☁️

Cloud Security

AWS, Azure, GCP — IAM hardening, storage controls, and CSPM

Cloud security baseline (all providers)

Identity & Access

Root/Owner account: hardware MFA, no access keys, emergency use only
No long-lived access keys — use IAM roles, instance profiles, workload identity
Enforce SCPs / Azure Policy / Org Policies at management account level
Enable AWS IAM Access Analyzer / Azure AD Identity Protection
Audit unused permissions quarterly (Access Advisor, Entra)

Storage & Data

Block all public S3/Blob/GCS bucket access at org level unless explicitly required
Enable server-side encryption with CMK (KMS/Key Vault/CMEK)
Enable versioning + MFA delete on critical buckets
VPC endpoints / Private Link for storage — no traversal over public internet
Scan buckets for sensitive data (Macie, Purview, DLP)

bash — AWS security posture checks

# Check for public S3 buckets
aws s3api list-buckets --query 'Buckets[].Name' | \
  xargs -I{} aws s3api get-bucket-public-access-block --bucket {}

# List IAM users with access keys older than 90 days
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F, 'NR>1 {if ($9 != "N/A" && $9 < strftime("%Y-%m-%dT", systime()-7776000)) print $1, $9}'

# Check for root access key existence (should be empty)
aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

# Enable GuardDuty across all regions
aws ec2 describe-regions --query 'Regions[].RegionName' --output text | \
  xargs -I{} aws guardduty create-detector --enable --region {}

# CloudTrail — verify S3 data events logging (common gap)
aws cloudtrail get-event-selectors --trail-name management-events \
  --query 'EventSelectors[].DataResources'

Control	AWS	Azure	GCP
Audit logging	CloudTrail (all regions, S3 events)	Azure Monitor Activity Log + Defender	Cloud Audit Logs (Admin + Data)
Threat detection	GuardDuty	Microsoft Defender for Cloud	Security Command Center
CSPM	Security Hub + Config	Defender CSPM	SCC Premium
WAF	AWS WAF + Shield	Azure WAF + DDoS Standard	Cloud Armor
Secrets	Secrets Manager / Parameter Store	Key Vault	Secret Manager
Network	VPC Flow Logs, Security Groups, NACLs	NSG Flow Logs, Azure Firewall	VPC Flow Logs, Firewall

🗒️

Quick Reference

One-liners, port reference, common IOC patterns, and crypto standards

Common Attack Ports to Monitor

# Unusual outbound = potential C2 / exfiltration
# Metasploit default listener
# Common backdoor/leet port
# Jupyter, common C2
# IRC — legacy botnet C2
# RDP — must NOT be internet-exposed
5985/5986  # WinRM — lateral movement
  # SSH — monitor for brute force
 # SMB — ransomware spread
 # RPC — WMI lateral movement

Cryptography Standards

# Symmetric encryption
✅ AES-256-GCM  # authenticated, preferred
✅ ChaCha20-Poly1305  # mobile-friendly
❌ AES-ECB      # leaks patterns
❌ DES / 3DES   # deprecated

# Hashing (passwords)
✅ bcrypt (cost≥12), Argon2id, scrypt
❌ MD5, SHA-1, SHA-256 (unsalted)

# Key exchange
✅ ECDH (P-256/P-384), X25519
✅ RSA-OAEP (2048+ bit)
❌ RSA PKCS#1 v1.5 (PKCS#1 padding oracle)

IOC Pattern Types

# Network indicators
IP addresses     # C2 servers, proxy IPs
Domain names     # DGA domains, typosquats
URL patterns     # malware download paths
JA3/JA3S hashes # TLS fingerprinting

# Host indicators
File hashes      # MD5/SHA256 of malware
Registry keys   # persistence mechanisms
Mutexes         # prevent re-infection
Named pipes     # lateral movement

# Behavioral indicators (TTPs)
LOLBAS usage    # living off the land
Process hollowing  # memory injection

Security Headers Checklist

# HTTP response headers — must-have
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; ...
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

# Check your headers
curl -sI https://yourdomain.com | grep -iE \
  'strict-transport|content-security|x-content|x-frame|referrer'

# Use securityheaders.com for scoring

📚

Key resources: attack.mitre.org (TTPs) · nvd.nist.gov (CVEs) · cisa.gov/known-exploited-vulnerabilities-catalog (KEV) · owasp.org/Top10 · sigma.socprime.com (detection rules) · docs.hunting.security · lolbas-project.github.io (living-off-the-land binaries) · gtfobins.github.io (Linux privilege escalation)

SecOpsHandbook

Introduction

Security Frameworks

Threat Modeling

STRIDE categories

IAM & Zero Trust

Zero Trust maturity levels (CISA)

Authentication

Authorization & RBAC

SIEM & Logging

The logging imperative: security logs you must have

Log quality standards

Common SIEM detection queries (Splunk / KQL patterns)

Detection Engineering

Detection quality metrics

Sigma rule — portable detection format

Vulnerability Management

Vulnerability SLA by severity

Incident Response Lifecycle

Incident severity classification

IR Playbooks

Phishing / BEC playbook

Ransomware playbook (immediate actions)

Digital Forensics

Secure SDLC

OWASP Top 10 — 2021

Secrets Management

Network Security

TLS configuration standards

Compliance & GRC

Cloud Security

Cloud security baseline (all providers)

Quick Reference

SecOps
Handbook