Your FREE ISSEP Flashcards 2026 – 200+ Cards

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.

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).

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

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

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

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 is a belief or willingness to depend on a system; trustworthiness is the demonstrated, evidence-based property that justifies that trust.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 checks compliance with requirements; validation checks fitness for purpose against stakeholder needs and the real environment.

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

Testing a running application to find vulnerabilities observable at runtime.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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