ISSEP key terms

A structured record linking each security requirement to its source, design element, implementation control, and verification evidence, so auditors and engineers can prove every requirement was addressed and tested.

Statements describing what a system must do to enforce policy, such as identification and authentication, audit generation, or access enforcement, usually expressed as testable shall-statements rather than design choices.

Requirements about the confidence and evidence behind a claimed security function, covering development rigor, testing depth, vulnerability analysis, and documentation, rather than the function's behavior itself.

The process of breaking high-level stakeholder and mission security needs into successively more specific, allocatable, and verifiable requirements for subsystems, components, interfaces, and procedures.

The documented description of a system's mission, boundary, operating environment, users, data sensitivity, and external interfaces that anchors threat analysis and requirement derivation.

The defined perimeter separating assets under one security policy or accreditation from everything else, marking where trust levels change and where interconnections require explicit controls and agreements.

A line in a design or data-flow diagram where data or control passes between components of differing privilege or assurance, marking where authentication, validation, and monitoring must be enforced.

A structured analysis identifying assets, entry points, adversaries, and attack paths, then ranking threats so that security requirements and countermeasures target realistic risks before design is finalized.

The sum of points where an adversary can attempt to enter, extract data from, or influence a system, including network services, interfaces, input channels, physical ports, and administrative functions.

Design and configuration practice of eliminating unnecessary services, ports, accounts, protocols, and privileges so fewer exploitable entry points remain, lowering residual risk without relying on detection alone.

A principle requiring systems to provide only the capabilities essential to the mission, with all other services, ports, and features disabled or removed to limit exploitable behavior.

Granting each user, process, or service only the access rights needed for its assigned task, for the shortest necessary duration, so compromise or error limits damage.

Splitting sensitive functions among different people or roles so no single actor can complete a harmful action alone, such as combining request, approval, and audit of a change.

Layering independent preventive, detective, and corrective controls across people, process, and technology so failure of one layer does not expose the whole system.

An alternative safeguard applied when a required or planned control cannot be implemented as specified, providing equivalent or acceptable risk reduction, documented with rationale and approval.

Choosing safeguards for a system by tailoring a control catalog to mission needs, threat profile, and environment, then documenting scoping decisions, parameters, and any additions or omissions.

The risk remaining after controls are applied, which must be compared against the organization's tolerance and formally accepted by an accountable authority before operation.

A documented decision by an accountable official to tolerate a specific residual risk for a defined period, with stated rationale, conditions, and review date.

A living record of identified risks with owners, likelihood and impact ratings, planned treatments, status, and review dates, used to track and communicate risk decisions across the program.

A repeatable procedure for identifying assets and threats, estimating likelihood and impact, and combining them into risk ratings that support prioritization and treatment decisions.

A formal, time-limited decision by an authorizing official permitting a system to operate, based on reviewed evidence that residual risk is acceptable against defined criteria.

The document recording assessment scope, methods, findings, control effectiveness, and risk conclusions, serving as the primary evidence package for an authorization decision.

An ongoing program of automated and manual checks on controls, configuration, vulnerabilities, and logs, feeding recurring risk decisions rather than relying on a one-time certification.

A documented, approved minimum set of settings for an operating system, application, or device, derived from recognized hardening guidance and managed through change control and periodic verification.

The disciplined identification, control, status accounting, and audit of system components and settings, ensuring only approved changes enter production and that deployed state matches documented state.

Any component, document, or setting designated for formal configuration control because its change could affect security posture, interoperability, or mission performance.

A chartered group that reviews proposed changes for security, schedule, and cost impact, then approves, defers, or rejects them and records the decision.

A review of a proposed change to determine whether it alters the system's risk posture, control effectiveness, or authorization basis, and what re-testing or re-approval is needed.

The coherent structure of security principles, domains, services, and controls that describes how protection is achieved across a system and how components interact to enforce policy.

A reusable, approved pattern of components, interfaces, and controls for a class of systems, providing a starting design that projects tailor rather than invent from scratch.

A structured examination of a proposed architecture against requirements, threat analysis, and standards, performed at defined milestones to catch flaws while correction is still inexpensive.

Verification confirms a system was built according to its specified requirements; validation confirms it meets user and mission needs in the intended operational environment.

Planned testing, scanning, and examination that produces evidence of control effectiveness, including functional tests, penetration testing, and configuration checks against defined criteria.

A predefined package of assurance requirements, from EAL1 through EAL7, specifying the depth of analysis and testing applied when evaluating a product against a protection profile or security target.

A technology-independent statement of security needs for a product category, defining required functional and assurance requirements that conforming products are evaluated against.

A vendor document stating a specific product's claimed security functions, assurance level, and evaluated configuration, forming the basis for its Common Criteria evaluation.

A formal document between organizations owning connected systems that specifies technical requirements, security responsibilities, and incident notification duties for the shared connection.

Identifying and mitigating risks introduced by vendors, integrators, and service providers, including counterfeit components, malicious inserts, foreign ownership, and weak provider security practices.

Controls over accounts with elevated rights, including inventory, strong authentication, session recording, just-in-time elevation, and periodic recertification to limit misuse and credential theft impact.

An access model assigning permissions to roles rather than individuals, with users granted roles, simplifying administration and enabling consistent enforcement of least privilege.