CSA (Other exams) cheat sheet

Security architecture is the set of design decisions, principles, and models that translate risk tolerance into technical structure; governance is the decision-rights system (who approves, who is accountable) that keeps those decisions consistent over time.

Defense in depth layers preventive, detective, and corrective controls so a single failure does not produce a breach; the layers must be independent - two controls on the same mechanism (e.g., two rules in one firewall) count as one layer.

SABSA maps business drivers to security services top-down (business attribute → security service → mechanism); TOGAF's Architecture Development Method embeds security in the Architecture Vision and Requirements Management phases rather than as a bolt-on.

Separation of duties requires that no single identity can both initiate and approve a high-impact action; the classic test is whether one compromised account can move money, change code, and deploy it to production.

Least privilege is enforced at the role level (RBAC) and the request level (attribute- or policy-based); standing privileges should be time-bound and just-in-time rather than permanent.

A security architecture review gate belongs at each phase transition (requirements, design, build, deploy); the cost of remediating a design flaw rises roughly an order of magnitude per phase it survives.

Trust boundaries are drawn wherever data or control crosses between components with different privilege, ownership, or exposure - user-to-web, web-to-app, app-to-database, and internal-to-third-party.

Governance artifacts: policy (management intent, mandatory), standard (specific mandatory requirements), procedure (step-by-step), guideline (recommended). Only policy and standard are auditable obligations.

Risk = likelihood × impact (qualitative) or annualized loss expectancy (ALE) = single loss expectancy (SLE) × annualized rate of occurrence (ARO); SLE = asset value × exposure factor.

Risk treatment options are exactly four: mitigate, transfer, avoid, accept. 'Ignore' is not a treatment; acceptance must be documented with an accountable owner and a review date.

Residual risk = inherent risk after controls; it must be compared to the risk appetite/tolerance statement, not to zero. Risk above tolerance requires escalation, not silent acceptance.

Inherent risk vs. residual risk is the standard way to express control effectiveness; control gap analysis compares the current control set to a target framework's requirements.

Common frameworks and their scope: ISO/IEC 27001 (certifiable ISMS requirements, Annex A controls), ISO/IEC 27005 (risk management guidance), NIST CSF (voluntary outcomes: Identify, Protect, Detect, Respond, Recover, plus Govern in CSF 2.0), NIST 800-53 (control catalog for US federal systems), SOC 2 (attestation over Trust Services Criteria), PCI DSS (cardholder data), GDPR (personal data of EU data subjects).

Compliance is not security: a control can be fully documented and still be ineffective. Evidence of operating effectiveness (samples, logs, test results) is what auditors assess, not policy text alone.

Third-party risk follows the data: the processor/ subprocessor chain, data residency, breach notification timelines, right to audit, and termination/data-return clauses are the highest-value contract terms.

A risk register entry needs: description, asset and owner, likelihood, impact, inherent score, controls, residual score, treatment decision, and review date. Without an owner and a date it is not a managed risk.

Authentication factors are knowledge, possession, and inherence; two factors from the same category (two passwords, two OTP apps) is single-factor authentication, not MFA.

NIST 800-63B treats SMS OTP and knowledge-based questions as restricted authenticators; phishing-resistant options are FIDO2/WebAuthn security keys and passkeys bound to the origin.

Authorization models: RBAC (roles assigned to users, permissions to roles), ABAC (decisions from attributes of subject, resource, action, environment), ReBAC (relationships, e.g., 'owner of document'), and policy-as-code (e.g., OPA/Rego).

Federation protocols: SAML 2.0 (XML assertions, browser SSO, enterprise), OIDC (identity layer on OAuth 2.0, JSON ID token, mobile/API), OAuth 2.0 is authorization delegation only and is not an authentication protocol by itself.

OAuth 2.0 hardening: use authorization code flow with PKCE for public clients, never implicit flow; validate redirect URI exact match; keep access tokens short-lived and scope-minimal.

Session management: rotate the session identifier at privilege change (login, elevation), enforce idle and absolute timeouts, and store tokens in HttpOnly, Secure, SameSite cookies rather than localStorage where feasible.

Privileged access management: vault credentials, broker sessions through a jump host with recording, require approval for elevation, and rotate secrets automatically after each checkout.

Joiner-mover-leaver lifecycle: access is granted from role, re-certified on a schedule (and on mover events), and revoked at termination within a defined SLA - orphaned accounts are a top audit finding.

Segmentation tiers: flat network → VLAN separation → subnet + ACL → firewall-enforced zones → microsegmentation (per-workload policy, identity-based). Each step reduces blast radius and east-west lateral movement.

A DMZ holds internet-facing services and permits only inbound flows to specific ports; the DMZ must not be able to initiate arbitrary connections into the internal network.

Zero Trust replaces 'trusted internal network' with per-request verification: policy decisions use identity, device posture, and context; the enforcement point (PEP) sits close to the resource.

Stateful firewalls track connection state; next-generation firewalls add application identification, TLS inspection, and IPS. A stateless ACL must permit return traffic explicitly.

TLS inspection requires a trusted re-signing CA distributed to endpoints; it breaks certificate pinning and must be excluded for privacy-sensitive or legally protected traffic.

DNS is a control point: filtering/ sinkholing at the resolver blocks command-and-control and phishing before connection; DoH/DoT can bypass enterprise filtering if not managed.

Remote access: VPN concentrators extend the network to the device; ZTNA grants per-application access without network-level presence - prefer ZTNA where the application can be proxied.

Network detection: NetFlow/IPFIX metadata reveals beaconing (regular intervals, consistent small byte counts, jitter), data staging, and unusual peer-to-peer flows without payload decryption.

Shared responsibility: the provider secures security 'of' the cloud (facilities, hypervisor, managed service internals); the customer secures security 'in' the cloud (identity, configuration, data, network policy). The boundary moves with IaaS → PaaS → SaaS.

Identity is the primary cloud perimeter: enforce MFA on all human accounts, eliminate long-lived access keys in favor of short-lived role assumption, and scope policies to specific resource ARNs.

Storage exposure is the most common cloud breach cause: block public access at the account level, use bucket policies plus IAM, enable default encryption, and log access (e.g., S3 server access logs, CloudTrail data events).

Control-plane logging (CloudTrail, Azure Activity Log, GCP Audit Logs) is required to detect privilege changes; data-plane logging is separate and must be enabled explicitly.

Virtualization: a hypervisor compromise breaks all guest isolation; harden the management plane, patch the hypervisor, and separate management traffic from guest traffic.

Containers share the host kernel, so isolation is weaker than VMs; use user namespaces, seccomp/AppArmor profiles, read-only root filesystems, and never run privileged containers.

Infrastructure as code should be scanned for misconfiguration (public buckets, open security groups, unencrypted volumes) before deployment; drift detection catches manual changes after deployment.

Cloud workload identity: prefer instance/ pod identity or workload identity federation over static secrets; rotate any remaining secrets through a managed secrets service.

Data states: at rest (storage encryption, KMS/HSM key management), in transit (TLS 1.2+; prefer 1.3, disable downgrade), in use (confidential computing, memory encryption). Each state needs its own control.

Symmetric algorithms: AES with 128/256-bit keys, GCM mode for authenticated encryption. Never use ECB (leaks patterns) or unauthenticated CBC without a MAC.

Asymmetric: RSA ≥ 2048-bit (3072 preferred) or ECC (P-256, P-384, Ed25519). Asymmetric keys are used for key exchange/signatures, not bulk data.

Hashing: SHA-256/ SHA-3 for integrity; passwords must use a memory-hard KDF (Argon2id, scrypt, bcrypt, PBKDF2) with per-user salt - never a plain fast hash.

Key management lifecycle: generation in a validated source, distribution, rotation, archival, destruction. Envelope encryption wraps data keys with a root key held in a KMS/HSM so data keys never leave the boundary in plaintext.

Data classification drives handling: public, internal, confidential, restricted. Controls (encryption, access, retention, DLP) attach to the class, not to individual files.

Privacy principles (GDPR-style): lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality, accountability. Data subject rights include access, rectification, erasure, portability.

Tokenization replaces sensitive data with a non-sensitive surrogate mapped in a vault; unlike encryption, the token has no mathematical relationship to the original, which reduces PCI scope when done properly.

Threat modeling (STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is performed at design time against a data-flow diagram with trust boundaries marked.

OWASP Top 10 categories that persist: broken access control (now ranked first), injection, insecure design, security misconfiguration, vulnerable components, identification/authentication failures.

Access control must be enforced server-side on every request; hiding a UI element is not authorization. Test with horizontal (same role, other user's object) and vertical (lower role, higher function) privilege escalation.

Injection defenses: parameterized queries/ prepared statements, output encoding contextual to the sink (HTML, attribute, JS, URL), and allow-list input validation - not blocklists.

Secrets must never be in source or build artifacts; use a secrets manager and scan repositories and CI logs for credentials.

Secure SDLC gates: security requirements, design review, SAST on commit, SCA/dependency scanning, DAST in a test environment, penetration test before major release, and vulnerability remediation SLAs.

Software supply chain: pin dependencies, verify signatures (Sigstore/cosign), generate an SBOM, and monitor for newly disclosed CVEs in components you ship.

API security: authenticate every endpoint, enforce object-level authorization, rate-limit, validate schemas, and avoid excessive data exposure in responses.

Detection pipeline: telemetry sources → collection/ normalization → correlation/ analytics → alert → triage → case. Log sources with the highest value: identity provider, EDR, cloud control plane, DNS, and egress proxy.

SOC tier model: Tier 1 triage, Tier 2 investigation, Tier 3 hunting/ response engineering. Metrics that matter: MTTD (mean time to detect), MTTA (acknowledge), MTTR (respond/ resolve), and false-positive rate.

Incident response phases (NIST SP 800-61): Preparation; Detection and Analysis; Containment, Eradication, and Recovery; Post-Incident Activity. Containment precedes eradication; evidence preservation precedes both.

Containment options: isolate host from network, disable account, revoke sessions and tokens, block indicator at egress. Revoking tokens matters because disabling an account does not invalidate issued OAuth tokens.

Order of volatility for evidence: CPU registers/ cache → memory → network state → disk → backups/ archival media. Capture memory before powering off a host.

Chain of custody: every transfer of evidence is logged with who, what, when, and why; hashes are computed at acquisition to prove integrity.

Forensics artifacts: Windows Event ID 4624 (logon) and 4625 (failed logon), 4688 (process creation), 4720 (account created); Linux auth.log, auditd, and shell history; cloud audit logs for role assumption and policy changes.

Tabletop exercises and purple-team drills validate the playbook before a real incident; a playbook that has never been exercised is an assumption, not a capability.