ISSEP study materials
ISSEP study resources

ISSEP cheat sheet

ISSEP · Keep the key ideas within reach.

Quick reference

Execute System Security Engineering Processes

  • Security engineering runs concurrently with the system lifecycle: concept, requirements, design, implementation, verification, transition, operations, retirement.

  • Verification confirms the system was built right (meets specified requirements); validation confirms the right system was built (meets stakeholder needs and operational intent).

  • A Security Assessment Report (SAR) documents findings, residual risk, and authorization recommendations; it feeds the authorization decision, not the design itself.

  • Configuration management baselines (functional, allocated, product) must be under change control before security-relevant changes are approved.

  • Traceability matrix links each security requirement to a design element, an implementation artifact, and a verification method (test, analysis, inspection, demonstration).

  • Defects found late cost more: requirement-phase defect repair is typically 1x, design 3-6x, operations 10-100x (relative cost-of-change heuristic).

  • Risk is assessed as likelihood x impact; residual risk after controls must be explicitly accepted by the authorizing official, not silently absorbed.

  • Process maturity reference: CMMI and ISO/IEC 15288 define lifecycle process areas; ISO/IEC 21827 (SSE-CMM) defines security engineering process areas.

Quick reference

Technical Procurement and Management

  • Procurement lifecycle: requirements definition, solicitation, source selection, contract award, contract management, acceptance, closeout.

  • Source selection uses best-value tradeoff or lowest-price-technically-acceptable (LPTA); LPTA is inappropriate when security differentiation is a key discriminator.

  • Evaluation criteria and their relative weights must be stated in the solicitation; criteria introduced after release are unenforceable and protest-prone.

  • Contract types: firm-fixed-price shifts cost risk to the seller; cost-reimbursement shifts it to the buyer; T&M pays for effort, not outcome.

  • Security requirements belong in the statement of work and as contract line items, with acceptance criteria tied to verification evidence (SSP, test reports, SAR).

  • Supply chain risk controls include vendor security questionnaires, SBOM and provenance requirements, right-to-audit clauses, and component authenticity checks.

  • Contractor systems processing government data must meet specified controls (e.g., NIST SP 800-171) with flow-down to subcontractors and a documented POA&M for gaps.

  • Acceptance testing should verify delivered security configuration against the contract baseline before final payment and government acceptance.

Quick reference

Security Risk Management and Operations

  • Risk = f(likelihood, impact); treatment options are mitigate, transfer, avoid, and accept - each must be documented with an owner and a date.

  • Risk register entries carry ID, description, source/threat, affected assets, inherent and residual scores, treatment, owner, and review date.

  • Qualitative scales (e.g., 1-5 likelihood x 1-5 impact) must have defined, written definitions per level to keep scoring consistent across assessors.

  • Quantitative methods: SLE = asset value x exposure factor; ALE = SLE x annualized rate of occurrence (ARO).

  • Defense in depth layers controls so a single failure does not yield compromise; compensating controls substitute when a required control is not feasible.

  • Continuous monitoring (ISCM) tracks configuration drift, vulnerability findings, and control effectiveness; findings feed the POA&M and risk register.

  • Incident response phases: preparation, detection and analysis, containment/eradication/recovery, post-incident activity - evidence handling preserves chain of custody.

  • Key risk metrics: mean time to detect (MTTD), mean time to respond (MTTR), percentage of assets with current patches, open POA&M aging.

Quick reference

Security Design and Systems Requirement Setting

  • Requirement types: functional, non-functional (performance, availability), and security; security requirements should be testable and traceable, not aspirational.

  • Well-formed requirement criteria: necessary, unambiguous, complete, singular, feasible, verifiable, and bounded (no 'shall consider' or 'should be secure').

  • Security functional requirements derive from threat modeling (e.g., STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege).

  • Security assurance requirements specify evidence of correctness (e.g., testing depth, configuration management, vulnerability analysis) rather than behavior.

  • Design principles: least privilege, separation of duties, fail-safe defaults, complete mediation, economy of mechanism, least common mechanism, open design.

  • Reference monitor properties: complete mediation, tamper-proof, and verifiable; it underpins the trusted computing base (TCB) concept.

  • Protection rings and privilege separation limit blast radius; the TCB should be minimized and its interfaces audited.

  • Requirements baseline changes require impact analysis on design, cost, schedule, and risk, then formal approval through configuration control.

Quick reference

Security Solutions, Operations and Management

  • Control families follow NIST SP 800-53 structure: AC, AU, AT, CM, CP, IA, IR, MA, MP, PS, PE, PL, PM, RA, CA, SA, SC, SI, and PII/PT families.

  • Access control models: DAC (owner discretion), MAC (labels/clearances), RBAC (role assignment), ABAC (attribute-based policy) - selection follows data sensitivity and scale.

  • Authentication factors: something you know, have, are; MFA requires factors from different categories; single-factor reuse across systems enables credential stuffing.

  • Cryptography: symmetric (AES) for bulk data, asymmetric (RSA/ECC) for key exchange and signatures, hashing (SHA-2/SHA-3) for integrity; never use MD5/SHA-1 for security.

  • Key management lifecycle: generation, distribution, storage, rotation, revocation, destruction; key escrow and split knowledge reduce single-point loss.

  • Audit logging must capture who, what, when, where, and outcome, with synchronized time, protected storage, and defined retention.

  • Patch and vulnerability management: identify, prioritize by exploitability and exposure, remediate within defined SLAs, verify, and document exceptions.

  • Change management requires impact assessment, approval, backout plan, and post-implementation review; emergency changes get retroactive review.