ISM-1416 · September 2026
Software firewall
Guidelines for system hardening / Operating system hardening / Software firewall
Official control wording
A software firewall is implemented on workstations and servers to restrict inbound and outbound network connections to an organisation-approved set of applications and services.
Applicability
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.
// Latticework implementation guidance · partial coverage
Restrict workload traffic and test the actual path
Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.
Implementation steps
- Agree the required source, destination, port and protocol flows with service owners. Start with a non-production namespace.
- Apply ingress and egress NetworkPolicies for those flows. Confirm that the cluster network plugin enforces NetworkPolicy before promoting changes.
Evidence to retain
- Keep the reviewed flow matrix, versioned manifests, cluster/plugin version and a dated scan with its namespace exclusions.
- Capture successful approved connections and failed prohibited connections from representative workloads. Include node firewall evidence separately where the control requires it.
What the mapped checks can establish
NetworkPolicy coverage is evidence of workload-level traffic restriction only; it does not prove host firewall coverage, approved application and service lists, or effective enforcement by the cluster network plugin.
Responsibility boundary
Platform team: network plugin and network baseline. Workload team: required application flows and service tests. Organisation: approved business need 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-network-policy-coverage
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-1416. 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.