Your FREE ISSEP Flashcards 2026 – 200+ Cards

ISSEP Flashcards

CISSP-ISSEP

Information Systems Security Engineering Professional — an ISC2 advanced concentration for CISSP holders that focuses on engineering security into systems and projects throughout the system life cycle.

Systems security engineering (SSE)

The disciplined application of engineering principles to design, build, and sustain trustworthy systems that satisfy stakeholder security needs across the entire life cycle (NIST SP 800-160 Vol. 1).

NIST SP 800-160 Vol. 1

Engineering Trustworthy Secure Systems — the foundational SSE publication that adapts ISO/IEC/IEEE 15288 life-cycle processes to security engineering.

NIST SP 800-160 Vol. 2

Developing Cyber-Resilient Systems — a Systems Security Engineering Approach, covering anticipate, withstand, recover, and adapt against advanced cyber threats.

ISO/IEC/IEEE 15288

The international standard defining the system life-cycle processes (agreement, organizational project-enabling, technical management, and technical) that SSE adapts for security.

Trustworthiness

The degree of confidence that a system meets its requirements, behaves as intended, and is worthy of being relied upon — the central goal of systems security engineering.

Trust vs. trustworthiness

Trust is a belief or willingness to depend on a system; trustworthiness is the demonstrated, evidence-based property that justifies that trust.

Protection needs

Stakeholder-driven statements of what must be protected and the consequences of loss; they ground security requirements in asset value rather than arbitrary controls.

Asset

Anything of value to stakeholders — data, systems, capabilities, or missions — whose loss, corruption, or denial would cause adverse consequences.

Loss

An adverse consequence to asset value from an event; SSE seeks to limit losses to a level acceptable to stakeholders.

Stakeholder

Any party with a legitimate interest in a system — owners, users, operators, regulators, or the public — whose needs and concerns drive requirements.

Adequate security

Security commensurate with the risk and magnitude of harm from loss — neither over- nor under-engineered relative to stakeholder protection needs.

Defense in depth

Layering multiple, diverse, overlapping safeguards so the failure of one control does not result in compromise of the asset.

Least privilege

Granting each subject only the minimum access and capability needed to perform its function, limiting the impact of compromise or error.

Separation of duties

Dividing a critical task among multiple parties so no single individual can complete it alone, reducing fraud and error.

Fail-safe / fail-secure

A design principle ensuring that when a system fails it defaults to a state that protects assets (e.g., denies access) rather than exposing them.

Economy of mechanism

Keeping the design and implementation of security mechanisms as simple and small as possible so they can be analyzed and verified.

Complete mediation

Every access to every object is checked against the security policy on each request, with no bypass paths.

Open design

Security should not depend on the secrecy of the design or mechanism (no security through obscurity); it should depend on protecting keys and credentials.

Psychological acceptability

Security mechanisms should be easy to use so that users apply them correctly and do not work around them.

Reference monitor

An abstract machine that mediates all access of subjects to objects; it must be tamperproof, always invoked, and small enough to verify.

Security kernel

The hardware, firmware, and software that implement the reference monitor concept within the Trusted Computing Base.

Trusted Computing Base (TCB)

The totality of protection mechanisms — hardware, software, firmware — responsible for enforcing a system's security policy.

Security architecture

The structure that describes how security controls and components are positioned and related to satisfy the protection needs of a system.

Enterprise architecture framework

A structured method (e.g., DoDAF, TOGAF, Zachman) for describing an organization's systems; security architecture aligns to and extends it.

Security concept of operations (Security CONOPS)

A narrative describing how a system's security functions are intended to operate from the user's and operator's perspective.

Concept of operations (CONOPS)

A user-oriented document describing system characteristics and how stakeholders intend to operate it, used to derive requirements.

Mission / business function

The organizational objective a system supports; SSE traces protection needs and risk back to mission impact.

Security requirement

A capability or constraint the system must satisfy to meet stakeholder protection needs; it is verifiable and traceable to a need.

Functional vs. assurance requirements

Functional requirements state what a security control must do; assurance requirements state the evidence and rigor needed to trust that it does it.

Requirements traceability

Maintaining links from stakeholder needs to requirements, design, implementation, and test so every control has a justified origin.

Derived requirement

A requirement that arises from analysis or design decisions rather than directly from a stakeholder, but still traces back to a need.

Security verification

Confirming the system was built correctly — that it meets its specified security requirements ("did we build the system right?").

Security validation

Confirming the right system was built — that it satisfies stakeholder needs and intended use in the operational environment ("did we build the right system?").

Verification vs. validation

Verification checks compliance with requirements; validation checks fitness for purpose against stakeholder needs and the real environment.

Security assurance

Grounds for confidence — evidence and analysis — that a system meets its security objectives and behaves as intended.

Assurance case

A structured, evidence-backed argument that a system's security claims are satisfied, used to justify a trust decision.

Evidence

Artifacts produced across the life cycle (analyses, test results, reviews) that support the assurance case for a trust decision.

System life cycle

The full span of a system from concept through development, production, utilization, support, and retirement; SSE applies to every stage.

Concept stage

The earliest life-cycle stage where mission needs, protection needs, and feasibility are explored before requirements are set.

Development stage

The life-cycle stage where requirements are realized into an architecture, design, and implementation that is verified.

Production stage

The life-cycle stage where the system is manufactured or built to its verified design for fielding.

Utilization stage

The life-cycle stage where the system is operated to deliver its intended services; secure operations apply here.

Support stage

The life-cycle stage providing sustainment — maintenance, logistics, and change management — to keep the system operational and secure.

Retirement stage

The final life-cycle stage where the system is removed from service and disposed of securely (data sanitization, media destruction).

Risk Management Framework (RMF)

NIST SP 800-37's seven-step process for managing security and privacy risk: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor.

NIST SP 800-37

Risk Management Framework for Information Systems and Organizations — defines the RMF steps, tasks, and roles for authorizing systems to operate.

RMF Step 1 — Prepare

Establish context and priorities for managing risk at the organization and system levels before categorization begins (added in Rev. 2).

RMF Step 2 — Categorize

Determine the system's impact level by categorizing the information and system using FIPS 199 (confidentiality, integrity, availability).

RMF Step 3 — Select

Choose an appropriate baseline of security controls from NIST SP 800-53 and tailor it to the system and its risk.

RMF Step 4 — Implement

Deploy the selected controls and document how they are implemented in the system security plan.

RMF Step 5 — Assess

Evaluate whether controls are implemented correctly, operating as intended, and producing the desired outcome (per SP 800-53A).

RMF Step 6 — Authorize

A senior official (the authorizing official) accepts the residual risk and grants an Authorization to Operate (ATO).

RMF Step 7 — Monitor

Continuously track control effectiveness, system changes, and risk through ongoing assessment and reporting.

Authorization to Operate (ATO)

The formal management decision by an authorizing official to accept residual risk and permit a system to operate.

Authorizing Official (AO)

The senior executive with authority to formally assume responsibility for operating a system at an acceptable level of risk.

FIPS 199

Standards for Security Categorization — sets potential impact (low, moderate, high) for confidentiality, integrity, and availability.

FIPS 200

Minimum Security Requirements for Federal Information and Information Systems — mandates selecting an appropriate SP 800-53 control baseline.

High-water mark

The FIPS 199 rule that a system's overall categorization equals the highest impact value among its confidentiality, integrity, and availability ratings.

NIST SP 800-53

Security and Privacy Controls for Information Systems and Organizations — the catalog of controls and control baselines used in RMF Select.

Control baseline

A predefined set of minimum security controls (low, moderate, or high) selected for a system based on its FIPS 199 categorization.

Control tailoring

Adjusting a baseline by adding, removing, or refining controls and applying scoping and overlays to fit a specific system and risk.

Overlay

A specification of controls and tailoring for a community of interest (e.g., privacy, cloud, classified) applied on top of a baseline.

Common control

A control inherited by multiple systems and managed by a provider, reducing redundant implementation (the basis of control inheritance).

Hybrid control

A control partly inherited as common and partly implemented system-specifically.

Risk

A measure of the extent to which an entity is threatened by a potential event, expressed as a function of likelihood and impact.

Threat

Any circumstance or event with the potential to adversely impact assets through unauthorized access, destruction, disclosure, or denial of service.

Vulnerability

A weakness in a system, control, or process that could be exploited by a threat source.

Likelihood

A weighted estimate of the probability that a given threat will exploit a vulnerability, used with impact to determine risk.

Impact

The magnitude of harm from a loss of confidentiality, integrity, or availability of information or a system.

NIST SP 800-30

Guide for Conducting Risk Assessments — the methodology for identifying threats, vulnerabilities, likelihood, and impact.

NIST SP 800-39

Managing Information Security Risk — frames risk management at the organization, mission/business process, and information system tiers.

Three-tier risk model

SP 800-39's structure: Tier 1 organization, Tier 2 mission/business process, Tier 3 information system — risk flows between tiers.

Risk frame

The set of assumptions, constraints, tolerances, and priorities that establishes the context for organizational risk decisions.

Risk tolerance

The level of risk an organization is willing to accept in pursuit of its mission and objectives.

Risk treatment options

Accept, avoid, mitigate (reduce), or transfer (share) — the choices for responding to an assessed risk.

Residual risk

The risk remaining after controls are applied; the authorizing official must formally accept it before an ATO.

Inherent risk

The level of risk present before any controls or mitigations are applied.

Plan of Action and Milestones (POA&M)

A document that tracks identified weaknesses, planned remediation, resources, and milestones for closing security gaps.

Security Assessment Report (SAR)

The output of RMF Assess: findings on whether controls are implemented correctly and operating effectively, informing the authorization decision.

System Security Plan (SSP)

The formal document describing a system, its boundary, and the implementation of its selected security controls.

Authorization package

The SSP, SAR, and POA&M (plus supporting evidence) submitted to the authorizing official for the risk-acceptance decision.

Continuous monitoring (ISCM)

Ongoing awareness of security, vulnerabilities, and threats (NIST SP 800-137) supporting risk-based decisions throughout operation.

NIST SP 800-137

Information Security Continuous Monitoring (ISCM) for Federal Information Systems — defines the strategy and process for ongoing monitoring.

Ongoing authorization

A time-driven or event-driven continuous authorization approach that replaces periodic reauthorization using continuous monitoring data.

Reauthorization

Re-running the authorization decision when significant changes or events alter a system's risk posture.

Risk Management Framework roles

Includes the AO, system owner, common control provider, security control assessor, ISSO, ISSE, and SISO/CISO.

Security control assessor (SCA)

The independent party who conducts the assessment of security controls and produces the SAR.

Information System Security Officer (ISSO)

The individual responsible for ensuring an operational system's security posture is maintained day to day.

Information Systems Security Engineer (ISSE)

The engineer who applies SSE processes to define needs, design, and integrate security into a system across its life cycle.

ISSE process (IATF)

Discover needs, define requirements, design architecture, develop detailed design, implement, and assess effectiveness — the legacy IATF SE-companion model.

IATF

Information Assurance Technical Framework — historical guidance pairing the ISSE process with the systems engineering process.

Information assurance (IA)

Measures that protect and defend information and systems by ensuring availability, integrity, authentication, confidentiality, and non-repudiation.

Confidentiality

Preserving authorized restrictions on access and disclosure so information is not revealed to unauthorized parties.

Integrity

Guarding against improper modification or destruction of information and ensuring non-repudiation and authenticity.

Availability

Ensuring timely and reliable access to and use of information and systems by authorized users.

Authentication

Verifying the identity of a user, process, or device as a prerequisite to granting access to system resources.

Non-repudiation

Assurance that a party cannot deny having performed an action, achieved through signatures, logging, and timestamps.

Authorization (access)

Granting an authenticated subject the rights and permissions to access specific resources and perform specific actions.

Accountability

The ability to trace actions uniquely to an entity through identification, authentication, authorization, and audit.

Cyber resiliency

The ability to anticipate, withstand, recover from, and adapt to adverse cyber conditions, stresses, attacks, or compromises (SP 800-160 Vol. 2).

Resiliency goals

Anticipate, Withstand, Recover, Adapt — the four high-level objectives of cyber-resilient systems engineering.

Resiliency techniques

Approaches such as redundancy, diversity, segmentation, deception, and adaptive response used to achieve cyber resiliency.

Segmentation

Dividing a system into isolated zones to limit the spread of compromise and contain adversary movement.

Diversity (resiliency)

Using heterogeneous components so a single vulnerability does not affect all elements of a system.

Deception (resiliency)

Using misdirection (e.g., decoys, honeypots) to confuse adversaries and reveal their activity.

Adversary (advanced persistent threat)

A capable, well-resourced threat actor that establishes a long-term presence to achieve objectives; a primary driver of cyber-resilient design.

Cyber kill chain

A model of attack phases (reconnaissance through actions on objectives) used to design controls that disrupt adversaries early.

MITRE ATT&CK

A knowledge base of adversary tactics and techniques used to inform threat analysis, control selection, and detection engineering.

Attack surface

The set of points where an attacker can attempt to enter, affect, or extract data from a system; SSE seeks to minimize it.

Threat modeling

Systematically identifying, enumerating, and prioritizing potential threats against a system during design (e.g., using STRIDE or attack trees).

STRIDE

A threat taxonomy: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

Attack tree

A hierarchical diagram modeling how an objective (the root) could be achieved through combinations of attack steps.

Security control

A safeguard or countermeasure — administrative, technical, or physical — that protects the confidentiality, integrity, and availability of a system.

Administrative control

A management control such as policy, procedures, training, or personnel security that governs behavior.

Technical control

A control implemented in hardware, software, or firmware, such as encryption, access control lists, or authentication.

Physical control

A control that protects facilities and equipment, such as locks, guards, fencing, and environmental safeguards.

Preventive control

A control that stops an undesirable event before it occurs (e.g., access control, encryption).

Detective control

A control that identifies and signals an event that has occurred (e.g., IDS, audit logs).

Corrective control

A control that restores systems to a normal state after an event (e.g., backups, patching).

Compensating control

An alternative safeguard used when a primary control is not feasible, providing equivalent protection.

Cryptographic protection

Using approved algorithms and key management to provide confidentiality, integrity, authentication, and non-repudiation.

FIPS 140-3

Security Requirements for Cryptographic Modules — the standard a module must meet for use in federal systems (validated via CMVP).

Cryptographic key management

The full life cycle of keys — generation, distribution, storage, rotation, and destruction — governed by NIST SP 800-57.

Public Key Infrastructure (PKI)

The certificate authorities, certificates, and policies that bind public keys to identities and manage trust.

Symmetric encryption

Encryption using one shared secret key for both encryption and decryption (e.g., AES); fast but requires secure key distribution.

Asymmetric encryption

Encryption using a public/private key pair (e.g., RSA, ECC) that solves key exchange and enables digital signatures.

Digital signature

A hash of data encrypted with the signer's private key, providing integrity, authenticity, and non-repudiation.

Data at rest / in transit / in use

The three states of data that each require protection — encryption for stored and moving data, and protections such as enclaves for data in processing.

Zero trust architecture

A model (NIST SP 800-207) that assumes no implicit trust and continuously verifies every access request based on identity, device, and context.

NIST SP 800-207

Zero Trust Architecture — defines the logical components (policy engine, policy administrator, policy enforcement point) and principles of ZTA.

Policy Enforcement Point (PEP)

The zero-trust component that enables, monitors, and terminates connections between a subject and a resource per policy.

Policy Decision Point (PDP)

The zero-trust logic (policy engine plus policy administrator) that decides whether to grant access to a resource.

Trade-off analysis

Evaluating competing design options against cost, performance, risk, and security to choose a balanced solution.

Security trade-offs

Balancing security objectives against usability, performance, cost, and mission needs to reach adequate (not maximal) security.

Cost-benefit analysis

Comparing the cost of a control against the reduction in expected loss it provides; a control should not cost more than the asset it protects.

Security boundary

The defined perimeter of a system that establishes what is inside the authorization and protection scope.

Authorization boundary

All components of an information system to be authorized for operation, excluding separately authorized systems it connects to.

System interconnection

A connection between two or more systems requiring agreements (e.g., ISA) and controls to manage shared risk.

Interconnection Security Agreement (ISA)

A document specifying the technical and security requirements for connecting two systems and managing the shared risk.

Memorandum of Understanding (MOU)

A document establishing the terms and responsibilities between organizations that interconnect or share resources.

Supply chain risk management (SCRM)

Managing risks from suppliers, components, and services across the system's supply chain (NIST SP 800-161).

NIST SP 800-161

Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (C-SCRM).

Counterfeit / tampered component

A supply-chain threat where hardware or software is altered or faked; mitigated by provenance, validation, and trusted suppliers.

Software Bill of Materials (SBOM)

A formal inventory of software components and dependencies used to manage supply-chain and vulnerability risk.

Secure SDLC

Integrating security activities into every phase of software development rather than testing for it only at the end (e.g., NIST SP 800-218 SSDF).

NIST SP 800-218 (SSDF)

Secure Software Development Framework — practices for producing well-secured software across the development life cycle.

Static application security testing (SAST)

Analyzing source code or binaries without executing them to find vulnerabilities early in development.

Dynamic application security testing (DAST)

Testing a running application to find vulnerabilities observable at runtime.

Security test and evaluation (ST&E)

Planned testing to determine whether security controls are implemented correctly and meet requirements before authorization.

Developmental test and evaluation (DT&E)

Testing during development to verify that the system meets technical and security requirements.

Operational test and evaluation (OT&E)

Testing in a realistic operational environment to validate the system performs and protects as intended in actual use.

Penetration testing

Authorized, simulated attacks that actively exploit weaknesses to demonstrate real impact under defined rules of engagement.

Vulnerability scanning

Automated identification of known weaknesses in a system without exploiting them.

Independent verification and validation (IV&V)

V&V performed by a party technically and managerially independent of the development team to increase assurance.

Configuration management (CM)

The discipline of identifying, controlling, and documenting a system's configuration items and their changes throughout its life.

Configuration item (CI)

A component or aggregation of components under configuration management that is treated as a single entity.

Baseline configuration

A documented, approved set of specifications for a system at a point in time, serving as the basis for change control.

Change management

The controlled process of requesting, evaluating, approving, testing, and documenting changes to a system to preserve its security posture.

Change Control Board (CCB)

The body that reviews and approves or rejects proposed changes, assessing their security and operational impact.

Security impact analysis (SIA)

An analysis of how a proposed change affects the security state of a system before the change is approved and deployed.

Patch management

The process of acquiring, testing, and deploying updates to remediate vulnerabilities while controlling operational risk.

Hardening

Reducing a system's attack surface by removing unnecessary services, applying secure configurations, and closing default weaknesses.

Secure configuration baseline (e.g., STIG)

A standardized, hardened configuration (such as a DISA STIG or CIS Benchmark) applied to reduce vulnerabilities.

Audit logging

Recording security-relevant events to support detection, accountability, and forensic analysis.

Security Information and Event Management (SIEM)

A platform that aggregates and correlates logs and events across systems for detection, alerting, and analysis.

Incident response

The structured process to prepare for, detect, contain, eradicate, recover from, and learn from security incidents (NIST SP 800-61).

NIST SP 800-61

Computer Security Incident Handling Guide — defines the incident response life cycle and handling practices.

Containment

Limiting the scope and damage of an incident before eradication and recovery — "stop the bleeding first."

Contingency planning

Preparing to maintain or restore operations after a disruption (NIST SP 800-34), including backups and alternate sites.

NIST SP 800-34

Contingency Planning Guide for Federal Information Systems — covers BIA, recovery strategies, and plan testing.

Business Impact Analysis (BIA)

An analysis that identifies critical functions and sets recovery objectives (MTD, RTO, RPO), driving continuity decisions.

Recovery Time Objective (RTO)

The targeted time to restore a function after a disruption; it must be shorter than the maximum tolerable downtime.

Recovery Point Objective (RPO)

The maximum acceptable amount of data loss measured backward in time, which drives backup frequency.

Maximum Tolerable Downtime (MTD)

The longest a function can be unavailable before unacceptable harm occurs; it bounds the RTO.

Disaster recovery (DR)

The processes to restore IT systems and data after a disruptive event, a subset of overall continuity planning.

Backup strategy

The plan for full, incremental, or differential backups and their storage to meet the RPO and support recovery.

Media sanitization

Removing data from media via clearing, purging, or destruction so it cannot be recovered (NIST SP 800-88).

NIST SP 800-88

Guidelines for Media Sanitization — defines Clear, Purge, and Destroy levels matched to data confidentiality.

Data remanence

Residual data remaining on media after deletion or formatting that may be recoverable without proper sanitization.

Secure disposal

Securely retiring systems and media — sanitizing data, destroying keys, and documenting disposition — at end of life.

Decommissioning

The orderly removal of a system from service, including data migration, sanitization, and revocation of credentials and authorizations.

Key destruction (zeroization)

Securely erasing cryptographic keys from memory and storage so they cannot be recovered when a system is retired or compromised.

Acquisition security

Embedding security requirements into procurement and contracts so suppliers deliver trustworthy components and services.

Trusted foundry / provenance

Sourcing critical components from trusted, verified suppliers and tracking their origin to counter supply-chain tampering.

Privacy engineering

Applying engineering practices to manage privacy risk and protect personally identifiable information across the life cycle (NIST SP 800-53 privacy controls).

Personally Identifiable Information (PII)

Information that can be used to identify an individual; it requires privacy controls and influences categorization and protection.

FISMA

The Federal Information Security Modernization Act, which mandates risk-based security programs and authorization for federal systems.

OMB Circular A-130

Federal policy requiring agencies to manage information resources and security risk, including authorization and continuous monitoring.

Committee on National Security Systems (CNSS)

The body issuing policy and instruction (e.g., CNSSI 1253) for securing national security systems.

CNSSI 1253

Security Categorization and Control Selection for National Security Systems — the NSS counterpart to FIPS 199/200 and SP 800-53.

Common Criteria (ISO/IEC 15408)

An international standard for evaluating the security assurance of IT products against protection profiles and security targets.

Protection Profile (PP)

An implementation-independent set of security requirements for a category of products under Common Criteria evaluation.

Evaluation Assurance Level (EAL)

A Common Criteria rating (EAL1–EAL7) indicating the depth and rigor of an evaluation, not the strength of the product.

Security functional requirements vs. security target

The Security Target (ST) states the security claims for a specific product; functional requirements specify what the security functions must do.

Operational readiness review

An assessment confirming a system and its operators are prepared to securely transition into operations.

Transition to operations

The controlled handover of a verified, validated system from development into the operational environment with sustained security.

Lessons learned

Capturing what worked and what failed after incidents, tests, or projects to improve future engineering and operations.

Holistic protection

Engineering security across people, process, and technology and the full life cycle, rather than relying on isolated technical fixes.

Tailored trust

Designing the right level of trustworthiness for stakeholder needs and risk — adequate security, justified by assurance evidence.