ISC2 CSSLP cheat sheet

Confidentiality prevents unauthorized disclosure, integrity prevents unauthorized modification, and availability ensures timely authorized access.

Authentication verifies an identity; authorization determines permitted actions; accountability links actions to identities through audit records.

Defense in depth uses multiple independent controls so the failure or bypass of one control does not expose the protected asset.

Least privilege grants the minimum rights needed for a task and for the minimum necessary duration.

Non-repudiation provides evidence that an action occurred and cannot be credibly denied by the actor.

Threat modeling identifies assets, entry points, trust boundaries, threats, and mitigations before implementation.

Attack surface is the set of reachable interfaces, protocols, services, and data paths; reducing it reduces exploitable exposure.

Secure by design means security requirements and controls are built into architecture rather than added after deployment.

SDLC phases include requirements, design, implementation, testing, deployment, operations, and maintenance; security activities occur in every phase.

A security gate is a phase checkpoint with defined exit criteria that must be satisfied before work advances.

Risk management iteratively identifies, assesses, treats, and monitors risk throughout the lifecycle until it is accepted, mitigated, transferred, or avoided.

Security champions are trained development-team members who promote secure practices and escalate issues to the security organization.

Threat modeling is repeated when architecture, data flows, trust boundaries, or deployment topology changes.

Security training is role-based because developers, architects, testers, and operators require different competencies.

Metrics such as vulnerability age, defect density, and mean time to remediate measure security program effectiveness.

Change management ensures changes are authorized, tested, recorded, and traceable to requirements.

Functional requirements define system behavior; security requirements define constraints on behavior, access, and data handling.

Abuse cases describe how attackers may misuse functionality and complement normal use cases.

Security requirements must be testable, measurable, and traceable to design elements and verification evidence.

Data classification determines handling, retention, encryption, access, and disposal requirements.

Regulatory and contractual obligations become security requirements when they constrain system behavior or data.

Privacy requirements include data minimization, purpose limitation, consent, retention limits, and subject access rights.

A requirements traceability matrix links each requirement to design, implementation, and test evidence.

Conflicting requirements are resolved through documented risk acceptance or formal requirement change.

Trust boundaries separate components with different privilege, ownership, or data sensitivity; data crossing them is validated.

A security architecture describes controls, their placement, and how they enforce security requirements.

Separation of duties divides critical functions so no single identity can complete a sensitive transaction alone.

Fail-safe defaults deny access unless explicitly allowed, and control failure preserves protection rather than granting access.

Encapsulation hides internal implementation, while least common mechanism avoids shared state that leaks data between users.

Secure design patterns include mediated access, layered defense, minimized attack surface, and complete mediation.

Architecture risk analysis evaluates components, data flows, and deployment topology for weaknesses and missing controls.

Cryptographic design uses vetted algorithms and protects keys separately from the data they protect.

Input validation uses allow lists and is performed on trusted servers, not only in clients.

Output encoding converts untrusted data into a context-specific safe form and prevents injection.

Parameterized queries separate SQL code from data and prevent SQL injection.

Secrets must not be hard-coded; managed secret stores and rotation reduce credential exposure.

Memory-safe languages reduce buffer overflow risk; unsafe languages require bounds and lifetime checks.

Error handling avoids revealing stack traces, internal paths, credentials, or sensitive data to users.

Security code review focuses on authentication, authorization, input handling, cryptography, logging, and error handling.

Static analysis finds some defects before execution but produces both false positives and false negatives.

Unit tests verify small code units; integration tests verify component interactions and data flows.

Dynamic testing executes the application; static testing examines code or binaries without execution.

Penetration testing simulates attacker behavior against a scoped target under documented rules of engagement.

Fuzzing supplies malformed or random inputs to discover crashes, hangs, and input-handling defects.

Security regression tests confirm previously fixed vulnerabilities remain fixed after changes.

Coverage measures executed code or requirements, not the absence of vulnerabilities.

False positives require triage; false negatives mean real defects remain undetected.

Acceptance testing confirms security requirements are met before release.

Hardening removes unnecessary services, accounts, protocols, and permissions before production exposure.

Configuration baselines define approved settings; drift detection identifies deviations from the baseline.

Patch management prioritizes vulnerabilities by exploitability, exposure, and business impact.

Logging and monitoring detect anomalies; logs require protection from tampering and retention according to policy.

Backup and recovery plans require tested restores, not only backup creation.

Incident response phases are preparation, detection and analysis, containment, eradication, recovery, and lessons learned.

Decommissioning requires data sanitization, credential revocation, and removal from inventories.

Production changes follow change control with rollback plans and post-deployment verification.

A software bill of materials lists components, versions, licenses, and dependencies for vulnerability tracking.

Third-party risk assessment evaluates supplier security posture, provenance, incident history, and contractual controls.

Dependency pinning and integrity hashes prevent unexpected component substitution.

Provenance attestations record how, when, and where an artifact was built.

Vendor notifications and vulnerability feeds enable timely response to upstream flaws.

Open-source components carry license and maintenance risks in addition to security risk.

Build systems require isolation and access control to prevent tampering with artifacts.

Supplier contracts define breach notification, patching, audit, and data-handling obligations.