ISM lookup / System hardening

ISM-1490 · September 2026

Application control

Guidelines for system hardening / Operating system hardening / Application control

Official control wording

Application control is implemented on internet-facing servers.

Applicability

  • Non-classified (NC)
  • OFFICIAL: Sensitive (OS)
  • PROTECTED (P)
  • SECRET (S)
  • TOP SECRET (TS)

These are ASD’s applicability markings. Select and tailor controls for your system’s risk, classification and operating context with the system owner and authorising officer.

ASD Essential Eight applicability: ML2 · ML3. A profile marking does not establish maturity attainment.

// Latticework implementation guidance · partial coverage

Review approved images and execution paths

Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.

Implementation steps

  1. Maintain an approved image registry policy with an owner and an exception process. Pin the policy revision and test regular and init containers.
  2. Evaluate approved registries, privileged execution and Pod Security settings. Separately review the binaries, scripts and execution locations inside images and on hosts.

Evidence to retain

  • Keep registry approvals, workload inventory, policy configuration, failing/passing fixtures and dated scan or admission results.
  • Link image contents and host application-control evidence to the same system boundary. Record namespaces and workload types omitted from the scan.

What the mapped checks can establish

Scan and PolicyReport results show workload image and execution guardrails on Kubernetes servers; they do not prove host or endpoint application control.

Responsibility boundary

Platform team: registry and admission guardrails. Workload team: image contents and required execution. Organisation: approved software set and exceptions.

The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.

Mapped checks to inspect

  • kubescape: ism-allowed-registries
  • kubescape: ism-no-privileged-containers
  • kubescape: ism-pod-security-standards
  • kyverno: ism-application-control-approved-registry
  • kyverno: ism-application-control-no-latest-tag
  • kyverno: ism-application-control-no-privileged

These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.

Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.

Official source

ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details

Control source identifier: ism-1490. Check the official release before relying on this snapshot for an assessment.

Official control wording and applicability: Australian Signals Directorate, © Commonwealth of Australia 2026. September 2026 ISM, OSCAL v2026.09.4, reproduced under CC BY 4.0. Formatting is adapted for this website.

Latticework Systems’ implementation guidance is our interpretation. Provenance and scope.