ISSEP cheat sheet
ISSEP · Keep the key ideas within reach.
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.
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.
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.
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.
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.