ISO/IEC 27034 Lead Application Security Implementer flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Organization Normative Framework

The organization-wide repository of security policies, business context, ASC catalog, baseline levels, roles, and verification criteria from which each application's normative framework is derived.

Application Normative Framework

The application-specific framework instantiated from the ONF, recording which ASCs apply to that application, how they are tailored, and the evidence required to verify them.

Application Security Control

A reusable control specification with a unique identifier, stated objective, defined verification method, and associated level of trust, catalogued in the ONF and applied via ANFs.

Target level of trust

The level of trust stakeholders require for an application, derived from business context such as data sensitivity, exposure, criticality, and regulatory obligations. It sets the success criterion for control implementation.

Achieved level of trust

The level of trust actually supported by recorded verification evidence for implemented controls. Comparing it with target level of trust identifies remediation and improvement priorities.

Application owner accountability

The application owner is accountable for the application's risk posture and level of trust, including approving target level of trust and formally accepting residual risk that remains after controls.

Business context determination

Establishing data sensitivity, user population, exposure, criticality, and legal obligations before control selection, because these factors determine the required target level of trust and control rigor.

ANF derivation from ONF

The planning step that filters the ONF control catalog against an application's context, selects applicable ASCs, and records tailoring plus required verification evidence in the application's framework.

Control tailoring traceability

Adapting an ASC to an application's technology is permitted, but the tailored control must remain traceable to the ONF ASC objective and verification method so equivalence can be audited.

Lifecycle verification scheduling

Assigning owners and timing to verification activities across design, build, test, and operations rather than only at release, since unscheduled verification cannot raise achieved level of trust.

Threat modeling gap handling

When threat modeling reveals a threat no existing ASC addresses, the plan must either propose a new ASC to the ONF or record a formal risk acceptance by the application owner.

Plan baselining

Version-controlling and baselining the security plan so that later changes to scope, architecture, or target level of trust are detectable and trigger deliberate re-planning.

Implementation evidence linkage

Objective, reproducible artifacts such as test results, configuration extracts, and review records must be linked to the specific ASC identifier and ANF version they support.

Control substitution equivalence

When a specified ASC cannot be implemented, an alternative control may replace it only if demonstrated equivalence to the original objective and verification method is documented.

Layered control implementation

Controls must be implemented and verified across design, code and libraries, configuration, deployment, and operations, because verification at a single layer may not hold for the whole system.

Enforcement over documentation

Secure coding and configuration standards are effective only when enforced by build gates, automated policy checks, or review checklists, rather than existing as unreferenced written documents.

Implementation status states

Each ASC is tracked as planned, implemented, verified, or accepted risk, enabling achieved level of trust to be computed from recorded states rather than estimated informally.

Production environment evidence

Evidence gathered in development or test environments may not demonstrate a control in production, because configuration, data, and network exposure often diverge between environments.

Incident response phases

Detection and triage, containment, eradication, recovery, and post-incident review, each with defined entry and exit criteria and assigned owners for the affected application.

ANF-linked incident triage

Severity classification uses the affected application, the ASCs implicated, data sensitivity, and current achieved level of trust to determine escalation path and response urgency.

Containment trade-off record

Containment choices such as disabling features, revoking credentials, edge virtual patching, or taking the application offline must record the availability versus exposure justification.

Root cause feedback to ONF

A recurring incident root cause indicates a defective ASC specification or verification method, so corrective action changes the ONF rather than only fixing the individual application.

Notification obligation planning

Regulatory, customer, and partner notification duties are determined by data type and jurisdiction and decided during security planning so response is not improvised under pressure.

Incident evidence integrity

Chain of custody, cryptographic hashes, and reliable timestamps preserve incident artifacts so they remain usable in legal, regulatory, and audit proceedings after recovery.

Verification versus monitoring

Verification confirms an ASC is implemented as specified at a point in time; monitoring confirms the control keeps operating. Sustained achieved level of trust needs both.

Verification method types

Inspection, analysis, demonstration, and testing. The ONF should state which method applies to each ASC and the acceptance criterion that constitutes a pass.

Independent verification

Verification performed by parties separate from the implementing team, reducing self-assessment bias and typically expected at higher target levels of trust.

Configuration drift detection

Monitoring that compares deployed configuration against the verified baseline. Detected drift reopens the affected ASC and requires re-verification before achieved level of trust is restored.

Control-objective metrics

Monitoring metrics expressed against control objectives, such as percentage of ASCs verified or mean time to detect drift, rather than raw activity counts that do not inform trust decisions.

Verification version linkage

Verification results carry timestamps and reference the ANF version tested, because evidence produced against a superseded version does not demonstrate the current implementation.

ONF change propagation

Revising an ASC in the ONF requires reassessing affected ANFs, re-verifying the revised control, and recording the impact on each application's achieved level of trust.

Risk acceptance expiry

A documented risk acceptance needs an owner, rationale, and review or expiry date. Once expired, it reverts to an open gap and reduces the application's achieved level of trust.