ISSEP

Systems Security Engineering Fundamentals

The Information Systems Security Engineering Professional (ISSEP) certification validates expertise in integrating security throughout the systems engineering lifecycle. Systems Security Engineering (SSE) is a specialty engineering discipline focused on building trustworthy secure systems by applying science, mathematics, and engineering principles. SSE is not bolt-on security; it is built-in protection engineered into every stage of system conception, development, deployment, operation, and disposal.

The ISSEP exam aligns with the (ISC)2 CBK covering five domains: Systems Security Engineering Foundations, Risk Management, Security Planning and Design, Systems Implementation/Verification/Validation, and Secure Operations/Change Management/Disposal. Mastery requires fluency with authoritative references including NIST SP 800-160 Volume 1 and 2, the INCOSE Systems Engineering Handbook, NIST Cybersecurity Framework (CSF), ISO/IEC 15288, and the NIST Risk Management Framework (RMF).

Core Reference Documents

NIST SP 800-160 Volume 1 Principles

SP 800-160 Vol 1 defines 32 security design principles grouped into three categories. These principles guide architectural and design decisions for trustworthy systems.

• Structural Principles - Clear abstractions, least common mechanism, modularity and layering, partially ordered dependencies, efficient mediation, minimized sharing, reduced complexity, secure evolvability, trusted components, hierarchical trust, inverse modification threshold, hierarchical protection, minimized security elements, least privilege, predicate permission, self-reliant trustworthiness, secure distributed composition, trustworthy system control.
• Influencing Principles - Continuous protection, secure metadata management, self-analysis, accountability and traceability, secure defaults, secure failure and recovery, economic security, performance security, human factored security, acceptable security.
• Mitigating Principles - Repeatable and documented procedures, procedural rigor, secure system modification, sufficient documentation.

Trust vs Trustworthiness vs Assurance

These three concepts are foundational to security engineering and commonly confused on the ISSEP exam. Understanding the distinction is essential.

• Trust - A belief that an entity will behave as expected. Trust is subjective, often based on reputation, history, or authority. Trust can exist without evidence.
• Trustworthiness - An objective, evidence-based property of a system demonstrating it deserves trust. Measured through analysis, testing, and verification. A system is trustworthy when evidence supports belief in correct behavior.
• Assurance - Grounds for justified confidence that security claims are met. Produced through assurance cases combining evidence (test results, analysis, formal proofs) with argumentation linking evidence to claims.
• Assurance Case - A structured argument supported by evidence that a system will operate as intended in a defined environment. Uses Claims-Argument-Evidence (CAE) or Goal Structuring Notation (GSN).

ISO/IEC 15288 Technical Processes

The ISSEP integrates security activities into each of the ISO/IEC 15288 technical processes, aligned with SP 800-160 Vol 1 security engineering activities.

ISO/IEC 15288 Technical Processes mapped to Security:
  Business/Mission Analysis   -> Define protection needs
  Stakeholder Needs           -> Derive security requirements
  System Requirements         -> Security functional/assurance reqs
  Architecture Definition     -> Security architecture
  Design Definition           -> Security design
  System Analysis             -> Threat modeling, risk analysis
  Implementation              -> Secure coding, configuration
  Integration                 -> Security integration testing
  Verification                -> Security testing (pen test, SCA)
  Transition                  -> Authorization, deployment
  Validation                  -> Operational security validation
  Operation                   -> Continuous monitoring
  Maintenance                 -> Patching, security updates
  Disposal                    -> Sanitization, secure destruction

Security Engineering Principles Quick Reference

• Defense in Depth - Multiple, overlapping layers of security so that failure of one layer does not compromise the system.
• Least Privilege - Grant subjects only the minimum access rights required for their function.
• Separation of Duties - Divide critical tasks among multiple actors to prevent fraud and error.
• Fail Secure / Fail Safe - On failure, default to a secure state that protects confidentiality/integrity; fail-safe prioritizes life safety.
• Economy of Mechanism - Keep security mechanisms as simple as possible (Saltzer and Schroeder).
• Complete Mediation - Check every access to every object against the authorization database.
• Open Design - Do not rely on design secrecy (security through obscurity); rely on key secrecy instead.
• Psychological Acceptability - Security mechanisms must not make system unusable; users will bypass burdensome controls.
• Work Factor - Cost of circumventing the mechanism must exceed value of the protected asset to the attacker.

Role of the ISSEP

The ISSEP operates as a security-focused systems engineer, translating stakeholder protection needs into engineered solutions. Key responsibilities include translating mission and business needs into security requirements, participating in architecture and design reviews, selecting and tailoring security controls, performing threat modeling and risk assessments, overseeing secure integration and testing, supporting authorization decisions, and ensuring secure operation and disposal. The ISSEP serves as the technical authority who bridges security policy, engineering practice, and operational reality.

Risk Management Framework (RMF)

NIST SP 800-37 Revision 2 defines the Risk Management Framework, a seven-step process that integrates security, privacy, and cyber supply chain risk management activities into the system development lifecycle. The RMF is mandatory for U.S. federal information systems under FISMA and is widely adopted by industry and allied governments. For the ISSEP, RMF mastery is essential because it is the primary vehicle through which security engineering activities are planned, executed, and documented.

The Seven RMF Steps

FIPS 199 Security Categorization

FIPS 199 establishes security categories based on the potential impact on an organization should events occur that jeopardize the information and information systems. Impact is rated LOW, MODERATE, or HIGH for each of the three security objectives.

• Confidentiality - Preserving authorized restrictions on access and disclosure. Loss = unauthorized disclosure.
• Integrity - Guarding against improper modification or destruction. Loss = unauthorized modification or destruction.
• Availability - Ensuring timely and reliable access. Loss = disruption of access.
• High Water Mark - Overall system categorization equals the highest impact of any information type for any objective.

Example categorization:
  Financial data: (C: MOD, I: HIGH, A: MOD)
  PII records:    (C: HIGH, I: MOD,  A: LOW)
  System overall: (C: HIGH, I: HIGH, A: MOD)  <- High water mark

NIST SP 800-53 Rev 5 Control Families

SP 800-53 Rev 5 defines a catalog of 20 control families covering security and privacy. Controls are selected from SP 800-53B baselines (Low, Moderate, High) and tailored for the specific system.

• AC Access Control
• AT Awareness and Training
• AU Audit and Accountability
• CA Assessment, Authorization, and Monitoring
• CM Configuration Management
• CP Contingency Planning
• IA Identification and Authentication
• IR Incident Response
• MA Maintenance
• MP Media Protection
• PE Physical and Environmental Protection
• PL Planning
• PM Program Management
• PS Personnel Security
• PT PII Processing and Transparency
• RA Risk Assessment
• SA System and Services Acquisition
• SC System and Communications Protection
• SI System and Information Integrity
• SR Supply Chain Risk Management

Risk Management Hierarchy (SP 800-39)

SP 800-39 describes enterprise-wide risk management across three tiers. Risk decisions at higher tiers flow down as constraints to lower tiers.

• Tier 1 - Organization - Governance, risk executive function, enterprise risk strategy, risk appetite/tolerance.
• Tier 2 - Mission/Business Process - Enterprise architecture, information security architecture, risk-aware process design.
• Tier 3 - Information System - RMF applied to individual systems, control selection, assessment, authorization.

Risk Response Options

• Accept - Acknowledge risk and continue; appropriate when cost of mitigation exceeds expected loss or residual risk is within tolerance.
• Avoid - Eliminate the risk by removing the asset, activity, or exposure.
• Mitigate / Reduce - Implement controls to reduce likelihood or impact.
• Transfer / Share - Shift risk to a third party (insurance, outsourcing); residual risk remains with the owner.

Control Tailoring

After baseline selection, controls are tailored to match system context. Tailoring actions include applying scoping considerations, selecting compensating controls, assigning organization-defined parameters, supplementing baselines with additional controls, and providing specification information.

Tailoring example:
  Baseline: AC-2 (Account Management) - MODERATE
  Org-defined parameter: inactivity period = 90 days
  Scoping: AC-2(5) account monitoring N/A for single-user dev system
  Compensating: MFA via hardware token (AC-17 compensates for lack of VPN)
  Supplemental: Add SC-8(1) for mandatory TLS 1.3

Security Architecture and Design

Security architecture translates protection requirements into an engineered structure of security services, mechanisms, and controls distributed across the system. A sound architecture establishes how trust is partitioned, where boundaries are drawn, how controls compose, and how the system remains defensible under operational stress. The ISSEP uses established architectural frameworks and reference models to produce defensible, traceable, and evolvable security designs.

Zero Trust Architecture (NIST SP 800-207)

Zero Trust (ZT) is a paradigm shift from perimeter-based trust to per-request, identity-centric, continuously verified access. No implicit trust is granted based on network location or asset ownership.

• ZT Tenets (7) - All data sources and services are resources; all communication secured regardless of network location; access granted per-session; access determined by dynamic policy; monitor and measure integrity/posture; strict authentication and authorization before access; collect telemetry to improve security posture.
• Core Components - Policy Engine (PE) makes decisions; Policy Administrator (PA) enacts decisions; Policy Enforcement Point (PEP) guards resource. Together PE+PA = Policy Decision Point (PDP).
• ZT Deployment Variants - Enhanced Identity Governance, Micro-segmentation, Software-Defined Perimeter (SDP), Resource Portal-based.
• Trust Algorithm Inputs - Subject identity/attributes, resource requirements, environmental context, threat intelligence, historical behavior.

SABSA Framework

Sherwood Applied Business Security Architecture (SABSA) is a business-driven, risk-focused enterprise security architecture framework with six layers viewed from different stakeholder perspectives.

SABSA uses the six questions at every layer: What (assets), Why (motivation), How (process), Who (people), Where (location), When (time).

Security Enclaves and Zoning

Enclaves partition a system into protected regions with uniform trust levels, typically bounded by policy enforcement points. Proper zoning reduces attack surface and limits lateral movement.

• Untrusted Zone - Internet, public networks. No trust assumed.
• DMZ - Semi-trusted buffer hosting internet-facing services behind reverse proxies.
• Trusted Zone - Internal production network; controls prevent direct external access.
• Restricted / Management Zone - High-trust segment for administrative interfaces, bastion hosts, PKI.
• Classified Enclaves - Air-gapped or cross-domain-only zones for classified data (e.g., SIPRNet, JWICS).

Control Inheritance

In RMF and SP 800-53, controls can be inherited from a common control provider, reducing duplication and enabling consistent protection. Three inheritance modes exist.

• Common (Inheritable) - Provided by another system/provider; inherited wholly (e.g., datacenter physical controls inherited by all tenants).
• System-Specific - Implemented entirely by the system itself.
• Hybrid - Partially inherited, partially system-specific (e.g., shared IAM plus local RBAC).

Defense in Depth Layers

Typical defense-in-depth stack:
  Data           -> Classification, DLP, encryption at rest
  Application    -> Input validation, SAST/DAST, WAF
  Host           -> EDR, HIDS, hardening (CIS, STIG)
  Internal Net   -> Microsegmentation, NAC, east-west IDS
  Perimeter      -> NGFW, IPS, secure web gateway
  Physical       -> Access control, CCTV, locks
  Policy/People  -> Training, AUP, background checks

Reference Architectures and Models

• Bell-LaPadula (BLP) - Confidentiality focus. No read up, no write down. Used in classified environments.
• Biba - Integrity focus. No read down, no write up.
• Clark-Wilson - Commercial integrity via well-formed transactions and separation of duties.
• Brewer-Nash (Chinese Wall) - Prevents conflicts of interest; dynamic access based on prior access history.
• TOGAF - Enterprise architecture framework; integrates with SABSA for security views.
• DoDAF / MODAF / UAF - Defense architecture frameworks used with SV and OV viewpoints.

Threat Modeling Methodologies

• STRIDE - Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Microsoft methodology.
• PASTA - Process for Attack Simulation and Threat Analysis. Seven-stage risk-centric methodology.
• LINDDUN - Privacy-focused: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
• Attack Trees - Hierarchical decomposition of attacker goals.
• MITRE ATT&CK - Adversary tactics and techniques matrix used for threat-informed defense.

Security Assessment and Authorization

Assessment and authorization (A&A), historically called Certification and Accreditation (C&A), is the process by which a system's security posture is evaluated and a senior official accepts the residual risk of operation. The ISSEP plans and executes assessments, interprets findings, supports remediation, and contributes to the authorization package that the Authorizing Official (AO) uses to make the risk-based authorization decision.

NIST SP 800-53A Assessment Procedures

SP 800-53A provides assessment procedures for each SP 800-53 control. Procedures use a determination-statement approach with three assessment methods.

• Examine - Review, inspect, observe, study documents, mechanisms, or activities (e.g., review SSP, inspect config files).
• Interview - Discuss with individuals or groups to obtain understanding, clarify, or gather evidence.
• Test - Exercise assessment objects under specified conditions to compare actual vs expected behavior.

Each method has three depth attributes (basic, focused, comprehensive) and three coverage attributes (basic, focused, comprehensive), scaled to match the system impact level.

Authorization Package Artifacts

Authorization Decision Types

• ATO - Authorization to Operate - Full authorization for a defined period (commonly 3 years, or ongoing under continuous monitoring).
• IATO - Interim ATO - Deprecated in SP 800-37 Rev 2 but still used in some communities; short-term operation while remediating.
• DATO - Denial of ATO - AO determines risk unacceptable; system may not operate.
• Ongoing Authorization - Continuous authorization based on near-real-time risk determination via ConMon.
• Common Control Authorization - Separate authorization of inheritable controls (e.g., general support system, SaaS platform).
• Facility ATO - Physical and environmental authorization for a site.

POA&M Structure

Standard POA&M fields:
  - Weakness ID             - Source (SAR finding, audit, incident)
  - Weakness Description    - Affected Controls (e.g., AC-2, SC-8)
  - Severity / Risk Rating  - Scheduled Completion Date
  - Point of Contact        - Resources Required
  - Milestones              - Status (Ongoing, Completed, Delayed)
  - Remediation Plan        - Residual Risk if Not Completed

The POA&M is a living document; federal agencies report quarterly to OMB. Closed items require evidence of remediation validated by independent assessor.

Continuous Monitoring (ConMon)

SP 800-137 defines Information Security Continuous Monitoring (ISCM), and SP 800-137A provides ISCM program assessment. ConMon maintains ongoing awareness of security, vulnerabilities, and threats to support risk-based decisions.

• Key Capabilities - Asset inventory, vulnerability management, configuration management, patch management, malware detection, event logging, incident response integration.
• Reporting Frequency - Driven by control volatility and risk; high-impact controls monitored more frequently.
• Dashboards - CDM (Continuous Diagnostics and Mitigation) program in U.S. federal space provides centralized visibility.
• Metrics - SP 800-55 defines information security measurement program.

Common Criteria (ISO/IEC 15408)

Common Criteria (CC) provides an international framework for evaluating security properties of IT products. CC evaluations produce recognized assurance across participating nations (CCRA, SOGIS).

• Protection Profile (PP) - Implementation-independent statement of security requirements for a product class.
• Security Target (ST) - Implementation-specific security claims for a particular product.
• Target of Evaluation (TOE) - The product being evaluated.
• EAL 1-7 - Evaluation Assurance Levels; EAL 4 commonly the highest mutually recognized under CCRA; higher levels require formal methods.
• cPP / NIAP - Collaborative Protection Profiles used by NIAP (U.S.) for national security system procurements.

Independent Assessment Roles

• System Owner - Responsible for procurement, development, operation, and maintenance; prepares SSP.
• ISSO / ISSM - Information System Security Officer/Manager; day-to-day security stewardship.
• ISSE / ISSEP - Engineers secure solutions; supports categorization, control selection, implementation, and assessment support.
• Security Control Assessor (SCA) - Independently assesses control effectiveness; produces SAR.
• Authorizing Official (AO) - Senior federal official who accepts risk and signs the authorization decision.
• Risk Executive (Function) - Oversight body providing enterprise risk perspective to AOs.

Secure System Lifecycle Management

Security must be engineered into every stage of the system lifecycle, from initial concept through disposal. The ISSEP ensures that security considerations, including acquisition, supply chain integrity, configuration control, and end-of-life handling, are addressed with the same rigor as functional requirements. Failures at any stage can undo protections built earlier; integrated lifecycle security is therefore a fundamental ISSE discipline.

SDLC Security Integration

NIST SP 800-64 (retired but still influential) and SP 800-218 SSDF (Secure Software Development Framework) define security activities mapped to SDLC phases.

NIST SSDF (SP 800-218) Practices

• Prepare the Organization (PO) - Define SSDF policies, implement roles, secure environments and tooling.
• Protect the Software (PS) - Protect code from tampering, provide mechanism for verifying release integrity, archive/protect releases.
• Produce Well-Secured Software (PW) - Design with security requirements, review design, reuse existing secure components, create source code with secure practices, configure compilation and build tools, test executable code.
• Respond to Vulnerabilities (RV) - Identify and confirm vulnerabilities, assess, prioritize, remediate, analyze root causes.

Acquisition: FAR and DFARS

U.S. federal acquisition integrates security via Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation Supplement (DFARS) clauses.

• FAR 52.204-21 - Basic safeguarding of covered contractor information systems (15 basic controls).
• DFARS 252.204-7012 - Safeguarding Covered Defense Information; requires NIST SP 800-171 compliance and 72-hour cyber incident reporting to DoD.
• DFARS 252.204-7019/7020/7021 - NIST SP 800-171 DoD Assessment requirements and CMMC.
• CMMC 2.0 - Cybersecurity Maturity Model Certification; levels 1 (Foundational), 2 (Advanced, aligns with 800-171), 3 (Expert, aligns with 800-172).
• SP 800-171 - Protecting Controlled Unclassified Information (CUI) in nonfederal systems.

Supply Chain Risk Management (SP 800-161r1)

Cyber supply chain risk management (C-SCRM) addresses risks from suppliers, products, and services throughout the lifecycle. SP 800-161 Rev 1 integrates C-SCRM into RMF.

• Threats - Counterfeit components, tainted software (backdoors), malicious insiders in supplier, insecure development practices, foreign ownership/control/influence (FOCI).
• Practices - Supplier risk assessment, tiered supplier inventory, contractual security clauses, SBOM (Software Bill of Materials), provenance verification, tamper-evident packaging.
• SBOM - Formal machine-readable inventory of software components (SPDX, CycloneDX). Mandated by U.S. EO 14028.
• SR Control Family - SP 800-53 Rev 5 added Supply Chain Risk Management family with 12 controls (SR-1 through SR-12).
• Section 889 NDAA - Prohibits certain telecommunications equipment (Huawei, ZTE, Hikvision, Dahua, Hytera).

Configuration and Change Management

SP 800-128 provides guide for security-focused configuration management of information systems. Robust CM is essential to preserve an authorization.

Configuration Management lifecycle:
  1. Planning             -> CM plan, roles, tools
  2. Identifying          -> CIs, baseline configurations
  3. Controlling          -> CCB review, change requests
  4. Monitoring           -> Drift detection, compliance scans
  5. Auditing             -> Periodic verification

Baselines per SP 800-128:
  - Functional baseline   (requirements)
  - Allocated baseline    (design, inter-CI)
  - Product baseline      (as-built)
  - Secure config baseline (DISA STIG, CIS Benchmark)

Media Sanitization and Disposal (SP 800-88r1)

Selection depends on data sensitivity and whether media will leave organizational control. Always produce certificate of sanitization/destruction.

DevSecOps Considerations

• Shift Left - Embed security testing (SAST, SCA, IaC scan, secret scan) in developer workflow and CI pipeline.
• Pipeline Security - Sign artifacts, use hermetic builds, protect CI/CD credentials, enforce SLSA levels.
• Policy as Code - Codify security and compliance policies (OPA, Sentinel) enforced automatically.
• Continuous ATO - Automated evidence collection via OSCAL (Open Security Controls Assessment Language) enabling near-real-time authorization.

Incident Response and Continuity

No system is impervious. The ISSEP engineers systems so that when adverse events occur, the organization can detect, respond, contain, recover, and learn. Incident response (IR), business continuity (BC), and disaster recovery (DR) are disciplined processes that preserve mission and limit damage. These capabilities must be engineered, trained, and tested continuously, not improvised when a crisis strikes.

NIST SP 800-61 Rev 2 Incident Response Lifecycle

SP 800-61 describes a four-phase incident handling lifecycle. Phases are iterative; detection may recur during containment as new indicators emerge.

• 1. Preparation - Build IR capability: policies, plans, CSIRT, tools, training, prevention controls. Maintain jump kits, call trees, communication channels.
• 2. Detection and Analysis - Identify events, classify as incidents, prioritize based on impact, scope, and recoverability. Correlate indicators of compromise.
• 3. Containment, Eradication, and Recovery - Limit damage (short-term/long-term containment), remove threat (eradicate malware, close vulns), restore operations (recover systems, validate).
• 4. Post-Incident Activity - Lessons learned meeting, update playbooks, preserve evidence, share indicators (via ISACs), report per regulatory requirements.

CSIRT Roles and Structure

• Incident Commander - Overall leader during an incident; makes containment/communication decisions.
• Technical Lead - Directs investigation, forensics, remediation.
• Communications Lead - Manages internal/external communications, legal notifications.
• Scribe - Maintains incident timeline, decisions, evidence chain-of-custody.
• Legal / Privacy Counsel - Advises on regulatory reporting, attorney-client privilege, law enforcement engagement.
• Executive Sponsor - Authorizes major response actions (isolation, takedown, external disclosure).

NIST SP 800-34 Contingency Planning

SP 800-34 Rev 1 describes contingency planning for federal information systems. It distinguishes related but distinct plans, each with a specific scope.

RTO, RPO, MTD, WRT

Critical recovery metrics are derived from the Business Impact Analysis (BIA). Understanding their relationship is frequently tested.

• MTD - Maximum Tolerable Downtime - Total time a business process can be unavailable before causing irrecoverable damage. MTD = RTO + WRT.
• RTO - Recovery Time Objective - Target time to restore the IT system or service after a disruption.
• WRT - Work Recovery Time - Time needed after technical recovery to validate data, test, reconcile transactions, and resume business operations.
• RPO - Recovery Point Objective - Maximum tolerable data loss, measured in time; drives backup frequency.
• MTTR - Mean Time To Repair - Average actual time to repair/recover.
• MTBF - Mean Time Between Failures - Average uptime between failures; reliability metric.

Timeline:
  Incident --> [ RTO: system restored ] --> [ WRT: data validated ] --> Business resumed
  |<------------------------- MTD -------------------------->|

  Last backup ---[ RPO window: data loss ]--- Incident
  |<--------- RPO --------->|

Alternate Site Strategies

• Cold Site - Basic facility with power and HVAC; weeks to activate; lowest cost.
• Warm Site - Partially equipped with hardware and connectivity; hours to days to activate; moderate cost.
• Hot Site - Fully equipped and continuously updated; minutes to hours to activate; high cost.
• Mirror Site - Real-time replica running in parallel; near-zero RTO/RPO; highest cost.
• Mobile Site - Trailer/container-based; useful for distributed or disaster zones.
• Reciprocal Agreement - Mutual aid with similar organization; low cost but unreliable at scale.
• Cloud DR - Pilot light, warm standby, or multi-site active-active using cloud provider capabilities.

Plan Testing Methods

• Checklist Review - Desktop review of plan completeness; minimal disruption.
• Walkthrough / Structured Walkthrough - Team steps through plan discussing roles; no execution.
• Tabletop Exercise - Facilitated discussion of a scenario; explores decisions and handoffs.
• Simulation / Functional Exercise - Teams execute actions in a simulated environment without impacting production.
• Parallel Test - Recovery systems run in parallel with production; validates functionality without cutover.
• Full Interruption Test - Actual failover to alternate site; highest realism, highest risk.

Digital Forensics Principles (SP 800-86)

• Order of Volatility - Collect in order of decreasing volatility: CPU cache/registers -> RAM -> running processes/network state -> temporary files -> disk -> remote logs -> archival media.
• Chain of Custody> - Document who handled evidence, when, where, and why; preserves admissibility.
• Hashing - Compute SHA-256 hash of evidence at acquisition; verify unchanged at each handoff.
• Write Blockers - Hardware/software to prevent modification of original media during imaging.
• Working Copy - Perform analysis on a copy; preserve the original untouched.