VU23218 Implement network security infrastructure for an organisation

The first question the unit asks is not technical. It is: who is going to run this?

An organisation that decides it needs network security has to choose an operating model before it chooses a firewall. The unit frames the choice as three models, and that framing still holds, although the labels have drifted since the material was written.

On-premises and self-managed

The organisation buys the equipment, installs it in its own racks, and staffs the people who configure, monitor and respond. Everything sits inside the building, or inside a data centre the organisation controls.

The attraction is control. Policy is whatever the organisation decides it should be, the configuration is tailored to the way the business actually works, log data never leaves the premises, and there is no third party whose service level agreement sets the ceiling on how fast an incident gets handled. For an organisation with sovereignty requirements, classified data, or an operational technology environment that cannot tolerate an external dependency, this is often the only workable answer.

The cost is people. A security operations capability that genuinely runs around the clock without single points of failure needs somewhere between eight and twelve analysts, because three shifts a day, seven days a week, with leave and turnover, does not come out of a team of four. Add tooling licences and the annual figure gets large quickly. The published estimates vary widely and most of them come from vendors with something to sell, so treat the dollar figures as illustrative rather than as a quote; the shape of the argument is the durable part. What is not in dispute is that building the capability takes six to eighteen months before it is useful.

Here is where the Australian picture matters. Australia had roughly 137,500 cyber security professionals as at the Australian Computer Society's Digital Pulse 2025, with an additional 54,000 estimated as needed by 2030. ISC2's 2025 workforce work found 62 per cent of organisations reporting staffing shortages, with only about a third considering themselves appropriately staffed. An Australian organisation of a few hundred people that decides to run its own twenty-four-hour security operations centre is competing for scarce staff against banks, miners and the Commonwealth. Most of them lose that competition, and the model quietly becomes "one very tired systems administrator with an alert console".

Hybrid, with a managed provider

The middle model splits the work. Equipment stays on the premises, or at least the organisation keeps ownership of the policy and the platform, and a managed security service provider covers the hours and the depth the internal team cannot. The usual split is that the internal team holds business hours, strategy and the hard escalations, and the provider holds nights, weekends, public holidays, surge capacity, and the first two tiers of triage.

This is the model most Australian small and medium enterprises actually land on, and the older TAFE framing captures why: it suits an organisation that wants more control than a pure outsource gives, has already spent money on a security information and event management platform it does not want to abandon, and cannot justify a full internal roster. The older material also notes that staff are sometimes retrained or hired across into the provider, which does happen, although it is not the defining feature.

The distinction worth holding onto is between an MSSP and an MDR provider. A traditional managed security service provider monitors and notifies; it tells you something happened and the investigation and response stay with you. Managed detection and response goes further, taking the investigation and at least some containment actions on your behalf. Gartner's October 2025 market guide put global MDR spending growth at about 9.6 per cent annually and Asia Pacific growth at about 19 per cent, faster than other managed security services, which tells you which way the market is moving: organisations are buying the response, not just the alert.

Cloud delivered, and security operations as a service

The third model outsources the function entirely. The provider delivers monitoring, detection, investigation, containment, response and reporting as a subscription, usually with compliance reporting included, and the customer holds no internal analyst headcount at all. The older material calls this SOCaaS, and criticises it as offering the least flexibility. That criticism was fair when it was written and is now only half true.

Update, current as at September 2026. Two things have changed since the unit was written. The first is that the security controls themselves moved into the cloud, not just the people watching them. Firewall as a service, secure web gateway, cloud access security broker and zero trust network access are now bought as one platform, sold under the labels security service edge (SSE) and, when the wide area networking is bundled in as well, secure access service edge (SASE). Dell'Oro Group reported SASE revenue passing three billion US dollars in the first quarter of 2026, up 21 per cent year on year, with SSE growing at 22 per cent, and noted that SSE-first deployment remains the usual entry point. The second change is that Australian government policy has followed. The Australian Government Gateway Security Standard consultation paper of February 2025 explicitly accommodates cloud based gateway services including SSE and SASE, and it retires the requirement for entities to follow the lead gateway agency model established under the Gateway Reduction Program. That is a reversal of direction. Older teaching material that presents consolidation into a small number of monolithic gateways as the government's position is describing a policy that is being wound back.

So the honest current statement of the three models is less "physical, hybrid, cloud" and more a question of where the control points sit and who operates them. The control points can be on your premises, in a provider's cloud, or both. The operators can be your staff, a provider's staff, or both. Those two choices are independent, and the four combinations are all in use.

The risks of perimeter security devices

The unit asks students to identify the potential risks of network perimeter security devices. The intended answer, from the assessor guide, is a sensible if general one: perimeter devices are the servers, routers, wireless access points, firewalls and VPN concentrators that staff and customers connect through; they need careful monitoring and management, preferably by a single accountable owner; and rogue access points introduced by staff are a problem.

That answer is correct and badly out of date on emphasis, because between 2023 and 2026 the perimeter device stopped being a thing that needs monitoring and became the single most reliable way into an Australian organisation.

Consider what the record actually shows. In January 2024, Ivanti Connect Secure was exploited through a chained authentication bypass and command injection (CVE-2023-46805 and CVE-2024-21887); CISA's Emergency Directive 24-01 of 19 January 2024 was followed by a supplemental direction on 31 January ordering United States federal agencies to physically disconnect every affected Ivanti product by 2 February and factory reset it before returning it to service. In April 2024, Palo Alto's GlobalProtect gateway carried CVE-2024-3400, a command injection scoring the maximum 10.0, giving unauthenticated root code execution, exploited before it was disclosed. Cisco's ASA was hit twice: the ArcaneDoor campaign published by Talos on 24 April 2024, and then a second round of zero-days in September 2025. Citrix NetScaler produced CitrixBleed in 2023 and CitrixBleed 2 in June 2025. SonicWall's SSL VPN was the entry point for the Akira ransomware campaign that the Australian Signals Directorate wrote about specifically, on 10 September 2025, in an advisory titled "Ongoing active exploitation of SonicWall SSL VPNs in Australia".

There is a pattern in that list, and it is the teaching point. These devices sit on the internet by design, accept connections from anyone, terminate TLS, run a web application, and are almost never capable of running an endpoint detection agent. They are a web server with a firewall's privileges and no observability. When one is compromised, the attacker is not at the perimeter; they are past it, on a device that can read every session that crosses it.

The Five Eyes agencies said as much. On 4 February 2025, the ACSC, CISA, the Canadian Centre for Cyber Security, the United Kingdom's NCSC and others jointly released guidance on securing network edge devices, with ASD leading the mitigation strategies documents in both executive and practitioner versions. The practitioner guidance is worth reading in full; the executive version is short enough to hand to a manager. The follow-up joint fact sheet of 5 February 2026, "Reducing the Attack Surface for End-of-Support Edge Devices", makes three points: scan actively for edge devices you have forgotten about, replace unsupported ones promptly, and where you cannot replace one immediately keep it on the latest supported software.

A rogue access point is still a risk. It is just no longer the first one on the list.

Why administrative access to network devices is the first problem

A router or switch with a weak enable password is not one compromised device. It is every device downstream of it, every session that crosses it, and, if the attacker is patient, the running configuration of the whole estate.

The baseline is unglamorous and non-negotiable. Change default credentials on every device, without exception, before it goes into service. Use strong passwords, and store the enable secret with a modern hash rather than the reversible type 7 encoding that Cisco IOS still accepts for backwards compatibility. Disable Telnet and use SSH. Restrict which source addresses may reach the management plane, using an access class on the VTY lines, and better still put management on its own out-of-band network that user traffic cannot reach at all. Give individual accounts to individual administrators rather than a shared login, so the accounting record means something. Apply privilege levels or command authorisation so that a junior administrator who needs to check an interface cannot also erase the startup configuration.

That is what the unit means by "the process and reasons for configuring secure administrative access". The reason is accountability as much as secrecy: without individual accounts and command logging, you cannot answer the question every incident eventually asks, which is who changed this and when.

Authentication, authorisation and accounting

AAA separates three questions that older systems ran together.

Authentication asks who you are. Authorisation asks what you are allowed to do once you have proved it. Accounting asks what you actually did, and records it.

The separation matters because the three answers change at different rates and often come from different places. Identity might live in Active Directory. Authorisation might depend on a role assigned in a service catalogue. Accounting has to go somewhere it can be retained and searched. Building all three into a device's local user database means every change has to be made on every device.

flowchart LR
 A[User or administrator] -->|credentials| B[Network access server: switch, wireless controller, VPN gateway or router]
 B -->|Access-Request| C[AAA server]
 C -->|Access-Challenge or Access-Accept with attributes| B
 B -->|permit or deny, apply VLAN, ACL or privilege level| A
 B -->|Accounting-Request start, interim, stop| D[Accounting and log store]

Two protocols do this work, and students meet both.

RADIUS runs over UDP, ports 1812 for authentication and 1813 for accounting. It combines authentication and authorisation into a single exchange, and it encrypts only the user password attribute, leaving the rest of the packet in the clear. It is the protocol behind 802.1X network access, so it is what authenticates a laptop onto a wired port or a wireless SSID.

TACACS+ runs over TCP port 49, separates all three functions cleanly, and obfuscates the entire packet body rather than just the password. Its distinctive capability is per-command authorisation: the device can ask the server whether this administrator may run this specific command, every time. That is why the old shorthand holds up: RADIUS for network access, TACACS+ for device administration.

The unit's own lab configures both, first with a local AAA database on the router and then against a server. The local case is worth doing precisely because it shows the limitation. A local AAA database gives you the AAA method list structure without the central management, so a password change means touching every device.

Update, current as at September 2026: RADIUS is being moved off UDP

The unit teaches RADIUS as a solved thing. It is not, and the reason is worth understanding because it is a rare case where a well-known weak primitive turned out to be exploitable in a real protocol.

On 9 July 2024, a research team including Sharon Goldberg, Miro Haller, Nadia Heninger, Adam Suhl, Mike Milano, Dan Shumow and Marc Stevens published BlastRADIUS, tracked as CVE-2024-3596 and coordinated through CERT/CC as VU#456537. The paper, "RADIUS/UDP Considered Harmful", was presented at USENIX Security 2024.

The attack works like this. RADIUS protects the integrity of a server's response using a Response Authenticator computed with MD5. MD5 has been known to be vulnerable to chosen-prefix collisions for years, and the usual response has been that this does not matter much in practice. The researchers showed that it does: an attacker positioned on the path between the network access server and the RADIUS server can take a legitimate Access-Reject and turn it into a forged Access-Accept, granting access. They computed the necessary collisions in three to six minutes on modest hardware, and much faster with GPUs. Notably, the attacker does not need the shared secret.

Three qualifications matter for teaching. The attack requires a man-in-the-middle position between the RADIUS client and the RADIUS server, which is a real condition; the risk concentrates where RADIUS traffic crosses untrusted paths rather than a protected management network. Deployments using EAP are largely protected, because RFC 2869 already requires the Message-Authenticator attribute, and it is the non-EAP methods, PAP, CHAP and MS-CHAP, that are exposed. And RADIUS carried over TLS or DTLS is not affected at all.

The short-term mitigation is to require the Message-Authenticator attribute on all requests and responses, placed as the first attribute in Access-Accept, Access-Reject and Access-Challenge packets. Vendors shipped it as a configuration setting; Cisco ISE 3.5, for example, added "Message-Authenticator Required On Response" for external RADIUS servers and network device profiles.

The long-term answer is transport security. RADIUS over TLS, known as RadSec, is specified in RFC 6614 (May 2012) on TCP port 2083, and RADIUS over DTLS in RFC 7360. Both were published as Experimental, which is part of why adoption lagged. That is changing. The replacement draft, draft-ietf-radext-radiusdtls-bis, reached version 17 on 6 July 2026 and sits with the IESG awaiting publication; when it appears it will obsolete both earlier documents and move RadSec onto the standards track. A companion document, draft-ietf-radext-deprecating-radius (version 10, 3 July 2026), deprecates RADIUS over plain UDP and TCP outside secure networks, deprecates MS-CHAP and the MD5-based mechanisms, and states that RADIUS packets sent outside a secure network must use RadSec or transport security such as IPsec. It sets no hard deadline dates and is not yet an RFC, so the accurate way to describe it in September 2026 is that the direction is settled and the document is not.

TACACS+ has already crossed that line. RFC 9887, "TACACS+ over TLS 1.3", was published on 9 December 2025 as a Proposed Standard. It mandates TLS 1.3 as a minimum, requires mutual certificate authentication with revocation checking, assigns TCP port 300 for the TLS variant while leaving port 49 as the legacy port, and obsoletes the original MD5-based obfuscation. Cisco ISE 3.5 supports it.

Did you know? If you have deployed eduroam, the roaming wireless federation used across Australian universities and by AARNet, you have already been running RadSec for years. The federated model made transport security unavoidable, because the RADIUS proxy chain crosses organisational and national boundaries. The rest of the industry is now catching up to what the research and education sector had to solve first.

802.1X, EAP, and the method most organisations should have left behind

802.1X is the IEEE standard that puts an authentication exchange in front of network access at the port or the SSID. Three roles: the supplicant, which is the client's software; the authenticator, which is the switch, wireless access point or controller; and the authentication server, which is almost always RADIUS. Until authentication succeeds, the authenticator passes only EAP traffic; everything else is blocked.

EAP itself is not an authentication method, it is a framework that carries one. Which method you choose is the decision that determines how strong the deployment actually is.

EAP-TLS uses mutual certificate authentication. The client presents a certificate, the server presents a certificate, both are validated, and no password crosses the network at all. There is nothing for an attacker to phish or crack. It is required for the WPA3-Enterprise 192-bit mode. Its cost is a public key infrastructure and a device enrolment process, which is exactly the work most organisations avoid.

PEAP with MSCHAPv2 is the method most organisations deploy instead, and it is the one to move away from. MSCHAPv2 was broken cryptographically in 2012, when Moxie Marlinspike and David Hulton showed that a captured MSCHAPv2 handshake reduces to breaking a single 56-bit DES key, independent of how strong the user's password is, and released chapcrack to do it. PEAP's answer is to wrap the whole MSCHAPv2 exchange inside a TLS tunnel, which works, but only for as long as the client actually validates the server's certificate. Where certificate validation is disabled, or the trusted root is set to "any", an evil twin access point terminates the tunnel itself, captures the inner exchange and cracks it offline.

The fair summary for study purposes: MSCHAPv2 as a cryptographic primitive is broken; PEAP-MSCHAPv2 as a deployment is conditionally safe and routinely misconfigured; EAP-TLS is where enterprise wireless is heading. And PEAP-MSCHAPv2 is still enormously widespread, so you will meet it.

Multi-factor authentication

The unit asks for two or three sentences on how MFA adds security, and the assessor guide's answer is the familiar one: a second factor is checked through a third-party device, usually a phone, which makes credential theft alone insufficient. That is right as far as it goes.

What is worth adding is that not all second factors are equal, and the differences have become practically important.

SMS one-time codes are the weakest common form, vulnerable to SIM swapping and to interception, and phishable in real time by an attacker relaying the code as the user reads it out. Time-based one-time codes from an authenticator application remove the telephone network from the problem but remain phishable in exactly the same way. Push notifications add a usability trap of their own, MFA fatigue, where an attacker with valid credentials simply sends approval prompts until a tired user taps accept; number matching, where the user must type a digit shown on the login screen, is the mitigation.

Phishing-resistant factors are the ones that break the relay attack. FIDO2 and WebAuthn security keys, and passkeys, bind the authentication to the origin, so a credential presented to a look-alike domain simply does not work; there is nothing for the user to read out and nothing for the attacker to replay. Certificate-based authentication has the same property. This is why the Essential Eight maturity levels distinguish between forms of multi-factor authentication rather than treating MFA as a single control.

The practical point for network infrastructure: MFA on the VPN and MFA on privileged administrative access are the two places it pays for itself fastest. Triskele Labs reported that VPN and remote desktop access without MFA accounted for about 60 per cent of initial access vectors across the ransomware incidents they responded to in the 2024-25 financial year. That is not a subtle finding.

Network access control

Network access control answers a narrow question at a specific moment: should this device be admitted to this network right now?

The five features the unit asks for, taken from the assessor guide, are a reasonable description of what a NAC product does.

Policy lifecycle management: one place to write and enforce access policy for every connection scenario, rather than a separate product for wired, wireless and remote.

Profiling and visibility: recognising what a device actually is before it is trusted, by fingerprinting its DHCP requests, HTTP user agent, MAC address organisationally unique identifier, and active scan responses. This is the feature that matters most in practice, because the printers, cameras, building management controllers and medical devices on a modern network cannot run an agent and cannot authenticate themselves.

Guest access: a self-service portal with registration, sponsorship and time-limited credentials, so that visitors do not end up on the corporate SSID.

Posture assessment: checking that a device meets policy before it is allowed on, and periodically afterwards; operating system patch level, disk encryption, whether an endpoint agent is installed and running, and antivirus definition currency.

Incident response: enforcing quarantine, so that a non-compliant or suspicious device can be moved to a remediation VLAN, restricted by a downloadable access control list, or blocked outright, without an administrator having to walk to a patch panel.

Underneath all of it, the enforcement mechanism is 802.1X where the device can authenticate, MAC authentication bypass where it cannot, and profiling to decide which of those to apply. NAC then assigns a VLAN, a security group tag or an access control list.

Update, current as at September 2026. Cisco ISE, which is the platform most Australian TAFE and university labs use, reached release 3.5 with general availability on 22 September 2025. Three things in that release show where the category is going: native deployment on AWS, Azure and Oracle Cloud Infrastructure, so the appliance model is no longer the only one; TACACS+ over TLS 1.3 per RFC 9887, and the BlastRADIUS remediation described above; and Microsoft Entra device authorisation over EAP-TLS, so wired and wireless authorisation can use device attributes held in the cloud identity platform. That last item is the concrete point where network access control and identity-plane zero trust meet.

There is an unresolved question about whether NAC survives as a distinct product category. Vendors argue both sides according to what they sell. The convergence argument is that zero trust network access already evaluates device posture continuously and enforces per-application rather than per-network, so a separate posture engine with a separate agent is duplicated work; "universal ZTNA" is the vendor answer, extending ZTNA enforcement to on-premises applications and campus users. The counter-argument is that ZTNA has nothing to say about the unmanaged device: the camera, the pump controller, the contractor's laptop. Only NAC can decide whether that thing gets a network address at all.

What is not in dispute is that 802.1X and RADIUS remain the enforcement mechanism underneath either model. Which is why the RADIUS transport security work described in the previous section matters more than it first appears.

Endpoint protection: EPP, EDR, XDR, MDR and DLP

The unit asks for a one-sentence definition of each. Here they are, with the overlap stated honestly, because the acronyms describe a market as much as they describe a technology.

Endpoint protection platform (EPP) is the preventive layer that runs on the endpoint: antimalware using signatures and cloud lookups, behaviour-based blocking, exploit and memory protections, attack surface reduction rules, device control and web protection. It tries to stop the thing before it executes.

Endpoint detection and response (EDR) records what the endpoint does, continuously, and makes that record searchable. Process ancestry, file writes, registry changes, network connections, command lines. Detection runs over that telemetry, and the response actions are isolating the host, killing a process, removing a file and collecting forensic artefacts. It assumes prevention will sometimes fail.

Extended detection and response (XDR) correlates the same idea across more than the endpoint: identity, email, cloud workloads and network telemetry in one investigation surface. Usually vendor-native, which is both its strength (the correlation actually works) and its weakness (it works best if you buy everything from one vendor).

Managed detection and response (MDR) is the service wrapper around any of the above. Gartner's description is turnkey, human-delivered threat detection, investigation and response.

Data loss prevention (DLP) inspects content against policy and enforces on data at rest, in motion and in use. Classification, then blocking or alerting on the copy to a USB device, the upload to a personal cloud account, the attachment to an outbound email.

The overlap is now the normal state rather than an anomaly. EPP and EDR ship as a single agent from every major vendor. XDR has absorbed network detection and response to the point where Omdia reported new standalone NDR licence revenue declining between 2022 and 2026 as Microsoft, Palo Alto Networks and CrowdStrike folded it into their platforms, followed by a partial reversal from about 2025 as AI-driven attack detection revived demand for specialists. DLP functions sit in both the endpoint agent and the secure web gateway. Anyone who tries to draw a clean boundary between the five terms is describing a taxonomy, not a product catalogue.

Case study: the day the endpoint agent took the world offline. On 19 July 2024 at 04:09 UTC, CrowdStrike released a content configuration update to Channel File 291 for its Falcon Windows sensor. The update triggered an out-of-bounds memory read in the kernel-mode driver, producing an invalid page fault and a bugcheck. Because the driver loads at boot, affected machines entered a boot loop that required manual intervention at each device. About 8.5 million Windows systems were affected. CrowdStrike reverted the content at 05:27 UTC and had a fix out by 09:45 UTC, but the fix could not reach a machine that would not boot, so recovery took days. Estimates of the economic impact run into the tens of billions of dollars globally, including roughly 5.4 billion US dollars across the United States Fortune 500 with only a fraction insured, and around 550 million US dollars at Delta Air Lines alone. CrowdStrike published its root cause analysis on 6 August 2024.

The lesson is not that CrowdStrike was uniquely careless. It is that a kernel-mode security agent with an automatically updating content channel is a single point of failure with global blast radius, and that "security agent" and "availability risk" are two descriptions of the same object. Microsoft's response was the Windows Resiliency Initiative, set out at Ignite in November 2024 and expanded on 26 June 2025 with the announcement of a Windows endpoint security platform allowing antimalware products to run in user mode "just as apps do", with CrowdStrike, Bitdefender, ESET, SentinelOne, Sophos, Trellix, Trend Micro and WithSecure named as partners and a private preview shipped in July 2025. As at September 2026 there is no published public preview or general availability date, and no date for restricting kernel access; Microsoft said explicitly in June 2025 that the announcement was not an announcement of future plans for kernel access, while analysts read it as signalling exactly that. This one is genuinely unsettled and should be watched rather than concluded.

Network monitoring tools

The unit asks for five features of a typical network monitoring tool. The assessor guide's answer, paraphrased: capture traffic, choose what to capture, filter it, decide what to do with what you find, and visualise and report. That is a fair generic description, and the tools that implement it fall into three tiers.

Full packet capture records the bytes. Wireshark is the analysis tool almost everyone learns first; the current release is 4.6.8, with 4.4.18 on the long-term support branch, both dated 12 August 2026. tcpdump and libpcap, at 4.99.6 and 1.10.6 respectively as at 30 December 2025, are what you use when there is no graphical display, which on a server is most of the time. Full capture is what an investigation needs to recover an exfiltrated file or extract a malware sample, and its constraint is storage, which limits retention to weeks rather than years.

Flow data records the metadata. IPFIX is standardised in RFC 7011 (September 2013, Internet Standard STD 77), and NetFlow is Cisco's predecessor to it. A flow record holds the five-tuple, timestamps, byte and packet counts, TCP flags, and interface and autonomous system information. It is small, cheap to retain for years, and generated natively by routers and switches. Its limits are that many devices generate flow from sampled traffic, so a low-volume event can be missed entirely, and that flow can never reconstruct a payload.

Between them sits protocol logging. Zeek, at 8.2 as at 14 May 2026, watches traffic and writes structured logs of what happened: connections, DNS queries, HTTP requests, TLS handshakes, files transferred, and notices. Far richer than flow, far smaller than full capture, and the standard feed into a SIEM. ntopng, at 6.6 as at 17 November 2025, sits on the flow analysis and traffic visibility side.

The practical answer is to run more than one tier: flow as the long-horizon index that tells you something happened and when, protocol logs as the searchable middle, and full capture as the short-horizon detail that tells you what it actually was.

From packet filter to next generation

A firewall's job has never changed: decide what may cross a boundary. What has changed repeatedly is how much of the traffic it has to understand in order to decide.

A packet filter looks at the header. Source and destination address, protocol, source and destination port, and for TCP the flags. It makes each decision independently, which is fast and cheap and blind: it cannot tell an inbound reply to an outbound request from an unsolicited inbound connection, so allowing return traffic means allowing a wide range of inbound ports.

A stateful firewall keeps a connection table. It records the outbound flow, and permits the return traffic that matches it, then removes the entry when the connection closes or times out. This is the model behind almost every access control list example students meet, and behind the ASA's default behaviour described below.

An application layer firewall, or proxy firewall, terminates the connection and re-originates it, so it sees the application protocol rather than just the transport. Which is slower, and is why the proxy became a separate product rather than a firewall feature; see the proxy section.

A next generation firewall folds those together and adds three things: it identifies the application regardless of port, so that traffic on 443 is not automatically "web"; it identifies the user, by integrating with the directory, so that policy can be written about people rather than addresses; and it runs intrusion prevention inline. Cisco's own current definition adds TLS decryption and inspection, URL filtering, threat intelligence integration, malware protection and sandboxing.

The unit asks for two or three sentences on NGFWs in terms of the TCP/IP layered model, and the assessor guide's answer is correct: they inspect at the internet, transport and, importantly, application layers, and the deeper the inspection the lower the throughput, which is why serious firewalls are expensive purpose-built hardware rather than software on a general-purpose server.

That trade-off is worth putting numbers to, because it is not a small effect and vendors publish the figures themselves. Cisco's technote on decryption performance for Secure Firewall Threat Defense, dated 19 August 2026, gives the Firepower 4115 a firewall-plus-application-visibility throughput of 33 Gbps, and a TLS hardware decryption throughput of 6.5 Gbps. That is roughly a fifth. Cisco's own recommended practice is not to decrypt everything: run a limited pilot first, exclude banking and financial sites, healthcare portals, certificate-pinned applications and business-critical systems, place those exclusions above the broad decrypt rules, monitor CPU and TLS handshake errors, and roll back on sustained saturation.

Which raises the obvious question. If almost all traffic is now encrypted, and you cannot afford to decrypt most of it, what is the firewall actually inspecting?

Update, current as at September 2026: how much traffic can a firewall still read?

Encryption has effectively won on the web, and the figures need their scope attached rather than being merged into one number.

Google's position, restated in its 28 October 2025 announcement of HTTPS by default, is that HTTPS accounts for roughly 95 to 99 per cent of Chrome main-frame page loads across platforms, and that the figure has been flat since about 2020. Chrome is going further: "Always Use Secure Connections" reaches Enhanced Safe Browsing users in Chrome 147 in April 2026 and all users in Chrome 154 in October 2026, and in testing fewer than three per cent of navigations triggered a warning. Cisco's Secure Firewall documentation, last modified 24 August 2026, uses the broader figure of over 90 per cent of internet traffic encrypted. Those two are not in conflict; they measure different things, and both should be quoted with their scope.

The threat side of it comes from vendor telemetry and should be attributed as such. Zscaler ThreatLabz, reporting on 5 December 2024 across the period October 2023 to September 2024 and 32.1 billion blocked encrypted attacks, found 87.2 per cent of the threats it blocked arrived over encrypted channels, up 10.3 per cent year on year. That is a share of one vendor's blocked attacks, not a share of all internet traffic, and it comes from a company that sells TLS inspection. It is still the best dated figure available.

Two protocol changes have made this harder rather than easier. TLS 1.3, standardised in RFC 8446 in August 2018, encrypts every handshake message after ServerHello, which means the server certificate is no longer visible on the wire; the old passive technique of reading the certificate's common name to identify a destination is gone. That left the Server Name Indication in the ClientHello as the last cleartext identifier, and Encrypted Client Hello removes that too. ECH is now RFC 9849, published March 2026, and it encrypts the inner ClientHello, including SNI and ALPN, under a server public key fetched from DNS. Cisco's August 2026 figures put browser support at 59 per cent, with 4.2 per cent of the top ten thousand websites and 9.2 per cent of the top million already supporting it. Worth noting as a live example of documentation lag: that same Cisco page still describes ECH as a draft awaiting standardisation, which the published RFC contradicts.

So what do defenders do?

Selective decryption, as above: decrypt the categories where the risk justifies the cost and the privacy position is defensible, and leave the rest.

Break the ECH bootstrap. Because a client that cannot fetch the ECH configuration from DNS falls back to cleartext SNI, blocking encrypted DNS (DoH, DoT, DoH3 and DoQ) to external resolvers forces the downgrade. The NSA's guidance on adopting encrypted DNS in enterprise environments, from January 2021, is still the reference: run your own DoH resolver and block outbound DoH to everyone else. This is a defensible enterprise control and it is also, plainly, a deliberate reduction in user privacy; both things are true and a student should be able to argue it either way.

Inspect the outside of the envelope. Fingerprinting and traffic analysis identify a client or a behaviour without reading the content. JA3, from 2017, hashed ClientHello fields into a single fingerprint of the client's TLS stack; JA4+, published by John Althouse at FoxIO on 26 September 2023, replaced it with a suite of readable fingerprints (JA4 for the TLS client, JA4S for the server response, JA4H for HTTP, JA4L for latency and distance, JA4X for certificate generation, JA4SSH for SSH sessions) in a component format so parts can be matched independently. JA4 is supported natively in Suricata, Zeek and Wireshark. Note the licensing: JA4 itself is BSD 3-Clause, while the rest of the suite sits under the FoxIO License 1.1, which is permissive for internal and academic use and requires an OEM licence for commercial products. Note also the limitation: a fingerprint identifies the client stack, not intent, and it is spoofable, so it is a triage signal and not a verdict.

Cisco's Encrypted Traffic Analytics does the same thing with flow telemetry, exporting the Initial Data Packet and the Sequence of Packet Lengths and Times alongside NetFlow for a classifier to score; on Secure Firewall the equivalent is the Encrypted Visibility Engine, which Cisco positions as the way to notice a suspicious non-browser process connecting to a content delivery network once SNI is no longer readable.

Zone-based policy firewalls

Cisco's zone-based policy firewall is the model the unit's first firewall lab configures, and it is a clean way to teach the idea that policy belongs to the boundary rather than to the interface.

Interfaces are assigned to zones. Traffic between interfaces in the same zone passes freely. Traffic between zones passes only where a zone-pair exists, and a zone-pair is unidirectional, so inside-to-outside and outside-to-inside are two separate policies. Class-maps classify traffic, by access list, protocol or application; policy-maps attach one of three actions, inspect, pass or drop; and the service-policy binds the policy-map to the zone-pair. There is also a system-defined self zone with no member interfaces, which governs traffic to and from the router itself, and which catches people out: if you create a zone-pair involving the self zone, you have taken responsibility for permitting your own management traffic.

The ordering discipline is the same as any firewall: specific rules before general ones, and an implicit deny at the end of every policy.

Zone-based policy firewall is still a current feature and is documented against IOS XE 17.x for platforms including the Catalyst 8500L edge platforms and the ASR 1000 series. It is worth being straightforward that the documentation carries an update date of January 2021, which is a fair signal of a mature, stable feature receiving no new investment rather than a deprecated one. On SD-WAN deployments the equivalent is the Enterprise Firewall with Application Awareness in the Catalyst SD-WAN security configuration guide, which carries the same zone model into the SD-WAN policy framework.

The ASA and its security levels

The second firewall lab configures a Cisco ASA with three interfaces, and the exercise is really about one idea: the ASA does not start from "deny everything and permit what you list". It starts from a numeric trust ordering, and access lists exist to override it.

Each interface gets a name and a security level from 0 to 100. In the lab: the inside interface is 100, the DMZ is 50, the outside is 0.

flowchart LR
 I["inside, security level 100"] -->|permitted by default| D["DMZ, security level 50"]
 I -->|permitted by default| O["outside, security level 0"]
 D -->|permitted by default| O
 O -.->|denied by default, needs an ACL| D
 O -.->|denied by default, needs an ACL| I
 D -.->|denied by default, needs an ACL| I

The rule is simply stated: traffic from a higher security level to a lower one is permitted by default and its return traffic is allowed by the connection table; traffic from a lower security level to a higher one is denied unless an access list permits it and that access list is applied to the interface with an access-group.

That single rule answers the lab's analysis question about which pings succeed. Inside to DMZ and inside to outside work without any configuration. DMZ to outside works. Outside to anywhere does not, and neither does DMZ to inside, until you write a rule. And the reason an inside host's ping to an outside host may still fail even though the outbound direction is permitted is that the ICMP echo reply is inbound on the outside interface and ICMP is not statefully inspected by default; the fix in the lab is either an access list permitting echo-reply, or enabling ICMP inspection in the policy map.

The configuration sequence the lab follows is the general shape of bringing up any ASA.

Name each interface, set its security level, address it and bring it up.

ASA(config)# interface gig 1/1
ASA(config-if)# nameif inside
ASA(config-if)# security-level 100
ASA(config-if)# ip address 10.10.10.1 255.255.255.0
ASA(config-if)# no shut

Give it a default route out.

ASA(config)# route outside 0.0.0.0 0.0.0.0 200.200.0.1

Configure network address translation using network objects, dynamic for the inside network hiding behind the outside interface address, and static for each DMZ server that has to be reachable from the internet.

ASA(config)# object network inside-network
ASA(config-network-object)# subnet 10.10.10.0 255.255.255.0
ASA(config-network-object)# nat (inside,outside) dynamic interface

ASA(config)# object network dmz-web
ASA(config-network-object)# host 10.10.20.3
ASA(config-network-object)# nat (dmz,outside) static 200.200.0.14

Write the access lists that override the default deny, and apply them.

access-list OUTSIDE-IN extended permit tcp any host 200.200.0.14 eq www
access-list OUTSIDE-IN extended permit tcp any host 200.200.0.13 eq domain
access-list OUTSIDE-IN extended permit udp any host 200.200.0.13 eq domain
access-list OUTSIDE-IN extended permit icmp any any echo-reply
access-group OUTSIDE-IN in interface outside

Then the Modular Policy Framework, which is the ASA's mechanism for attaching inspection and quality of service to classified traffic. A class-map matches the traffic, a policy-map specifies the inspections, and a service-policy attaches it globally or to an interface.

ASA(config)# class-map inspection_default
ASA(config-cmap)# match default-inspection-traffic
ASA(config)# policy-map global_policy
ASA(config-pmap)# class inspection_default
ASA(config-pmap-c)# inspect dns
ASA(config-pmap-c)# inspect http
ASA(config-pmap-c)# inspect icmp
ASA(config)# service-policy global_policy global

One habit worth forming while doing this lab: the access list permitting inbound web traffic references the translated address (200.200.0.14), not the real one. Getting that backwards is the single most common reason a lab DMZ server is unreachable, and the symptom (the connection is simply dropped, with a build-up of denied packets in the ASP drop counters) gives no obvious clue about the cause.

Update, current as at September 2026: the ASA in this lab is a museum piece, and that is instructive

The hardware the unit teaches on has reached the end of its life, and the story of how it got there is a better lesson than the configuration itself.

Every model in the ASA 5500-X series has now passed its last date of support. The dates are per model rather than per series, so any statement of one date for "the ASA 5500-X" is wrong. The 5512-X and 5515-X reached last date of support on 31 August 2022. The 5525-X, 5545-X and 5555-X with FirePOWER Services reached it on 30 September 2025. The 5508-X and 5516-X, the last models standing, reached it on 31 August 2026, days before this was written.

The software is a different matter, and this is the distinction to hold onto. ASA software is still current: release 9.24(1) with ASDM 7.24(1) shipped on 24 March 2026, running on Firepower 1000, 2100, 4100 and 9300 series, the Secure Firewall 1200, 3100, 4200 and 6100 series, the virtual ASAv and the ISA 3000. Cisco's current line is the Secure Firewall family, and the 1200 series datasheet is explicit that the platforms run either ASA or Firepower Threat Defense software. So the ASA versus FTD choice is now a software decision on the same hardware, not a product line decision, and the CLI skills this lab teaches remain useful. The boxes are obsolete; the operating system is not.

Now the part that matters. Between 2023 and 2026 the ASA was compromised three times in ways worth studying.

ArcaneDoor came first. Cisco Talos published it on 24 April 2024, tracking the actor as UAT4356 (Microsoft calls it STORM-1849). Tooling was developed around July 2023, infrastructure stood up in early November 2023, and activity peaked between December 2023 and January 2024. Two zero-days: CVE-2024-20353, a denial of service forcing a reboot, and CVE-2024-20359, persistence through a legacy WebVPN client preload feature. Two implants: Line Dancer, a memory-resident shellcode interpreter that disabled logging, dumped the configuration, captured and exfiltrated packets, and hooked the crash-dump process so that a forced reboot destroyed the evidence rather than preserving it; and Line Runner, an HTTP backdoor that survived reboot by riding that legacy preload feature.

The September 2025 round came second, and it targeted exactly the hardware this lab uses. Cisco's event response page, first published 25 September 2025, names CVE-2025-20333 (VPN web server remote code execution, CVSS 9.9), CVE-2025-20363 (HTTP server remote code execution, CVSS 9.0) and CVE-2025-20362 (VPN web server unauthorised access, CVSS 6.5, chained with the first). Cisco says the attacks were discovered in May 2025 and that the focus was ASA 5500-X models without Secure Boot, running 9.12 or 9.14 with VPN web services enabled. The United Kingdom's NCSC published its malware analysis the same day, naming RayInitiator, a persistent GRUB bootkit surviving both reboot and firmware upgrade, and LINE VIPER, a user-mode shellcode loader; NCSC assessed both as more capable and better at evading detection than the 2024 pair.

The response was unusually blunt. CISA issued Emergency Directive ED 25-03 on 25 September 2025, requiring United States federal agencies to identify every ASA and Firepower device and submit memory core dumps for internet-facing ASA hardware by the following night, to permanently disconnect ASA hardware whose end-of-support date was on or before 30 September 2025, and thereafter to apply Cisco updates within 48 hours of release. A supplemental direction issued the same day specified the exact order of commands for evidence collection, warning that deviating from it would trigger the actor's anti-forensics and destroy what you were trying to collect.

FIRESTARTER came third. CISA published malware analysis report AR26-113A in April 2026. FIRESTARTER hooks LINA, the core packet-processing engine of ASA and FTD, relaunches itself when terminated, and survives reboots and firmware upgrades; removal requires a full power cycle. It affects Firepower 1000, 2100, 4100 and 9300, and Secure Firewall 1200, 3100 and 4200, which is to say the current hardware, not only the retired hardware. The teaching point is uncomfortable and important: patching alone did not evict it.

The ACSC issued matching Australian advice twice, on 26 September 2025 for the ASA 5500-X vulnerabilities and on 24 April 2026 with detection and reporting steps for FIRESTARTER, including running the vendor indicator-of-compromise command, capturing show checkheaps and show tech-support detail to an isolated system, generating core dumps and deploying CISA's YARA rules.

There is a contrast worth discussing here. CISA's instrument was a binding emergency directive with deadlines measured in hours. The Australian equivalent was an advisory: informative, detailed and technically identical in substance, but not directive. That difference reflects the limits of Commonwealth direction-setting powers over the wider economy rather than any difference in the technical assessment, and it is a fair discussion question about how Australian cyber policy actually works.

Nor is this over. CISA issued Emergency Directive 26-03 in March 2026 over CVE-2026-20127, an authentication bypass in Cisco Catalyst SD-WAN scoring the maximum 10.0, having already published guidance on ongoing global exploitation of Cisco SD-WAN on 25 February 2026. The perimeter device remains the target.

The difference, and why it is smaller than it looks

An intrusion detection system watches traffic and reports what it thinks is malicious. An intrusion prevention system does the same analysis and can act on it: drop the packet, reset the connection, block the source, or divert it.

The assessor guide makes a point that students often miss, and it is correct: the two are not separate products. Essentially every modern sensor is capable of both, and the difference is a deployment decision. Put the sensor on a span port or a network tap, receiving a copy of the traffic, and it is an IDS, because it has no way to interfere with the original. Put it inline, so traffic passes through it, and the same sensor becomes an IPS.

That deployment decision has a real cost attached, and it is the reason organisations hesitate. An inline device is a device that can drop legitimate traffic and a device that can fail. A false positive on an IDS produces a wasted hour of analyst time. A false positive on an IPS produces an outage, and if the outage lands on a payments system on a Friday afternoon, the political consequence is that the IPS gets switched to detect-only mode and stays there. Most organisations run in a middle position: block on the high-confidence signatures, alert on the rest.

How signature detection actually works

A signature engine reassembles the TCP stream, normalises protocol fields (decoding URL escapes, resolving Unicode, reassembling fragments), and matches rules against the normalised buffers. Rules combine fixed content strings with offsets and depths, regular expressions, and protocol keywords. A fast multi-pattern matcher, typically Aho-Corasick, pre-filters so that only rules with a plausible content match get fully evaluated, because evaluating every regular expression against every packet at line rate is not possible.

The unit asks students to describe signature matching for both files and packets, and the assessor guide's answer covers it: known malware signatures are compared against the binary contents of a received file for endpoint tools, and against packets as they arrive for IDS and IPS; a match, or a close match, raises a flag. The guide then names the weakness itself, which is unusual and welcome: simple matching fails against polymorphic malware, and wildcard masks give only partial coverage.

That weakness has two structural forms.

The first is volume and mutation. AV-TEST registers over 450,000 new malicious programs and potentially unwanted applications every day. Packers, crypters and polymorphic engines change the bytes on every build, so a signature keyed to a byte pattern identifies one build of one sample. Signatures still have real value, because commodity attacks reuse tooling and a signature that catches a widely-used loader catches a lot of unsophisticated attacks cheaply, but they cannot be the whole answer.

The second is encryption, covered in the firewall section. A rule that matches on payload content cannot fire on a payload it cannot read.

The tools worth knowing. Snort is at 3.12.2.0, dated April 2026, with Snort 2 still downloadable at 2.9.20 and being wound down; Cisco Talos announced end of life for eight Snort 2 versions and eight early Snort 3 versions on 20 January 2026 and no longer publishes rules for them. Snort 3 is also where Cisco's own IPS lives now: it arrived in Firepower 6.7 and became available on FMC-managed devices from release 7.0, and Cisco states that while Snort 2 support continues, Snort 3 is the focus of new detection features. Suricata is at 8.0.6 as at 9 July 2026, with the 7.x branch maintained in parallel and security patches shipped for both on the same day; Suricata 8, released 8 July 2025, added an experimental firewall mode with a deterministic pipeline and default-drop policy, and moved much of its parsing to Rust. Zeek, at 8.2, is a network security monitor rather than an IPS, producing protocol transaction logs rather than alerts, which is why the two are usually deployed together.

The Cisco IOS IPS feature set that some older material teaches is effectively finished. It is documented only against IOS Release 15MT and has no presence in IOS XE, and the separate appliance line was formally retired with all signature support ending 26 April 2018. Cisco has not published a single dated end of life for the IOS software feature itself, so the accurate description is superseded and unmaintained rather than formally retired.

Artificial intelligence and machine learning in detection

The unit asks how AI and machine learning detect malicious data, and the assessor guide gives the standard answer: it is behavioural, based on analysing the behaviour of suspect processes against a threshold, so that a file or process crossing that threshold is called malicious. That is right, and it is worth unpacking a little, and then complicating.

Rather than matching bytes, a behavioural engine builds features from observable actions. On the endpoint: process ancestry, system call sequences, file and registry writes, command lines, injection attempts. On the network: connection patterns, beacon periodicity, data volume asymmetry, packet size and timing distributions, destination reputation. Those features are scored against a model of normal behaviour, of known-bad behaviour, or both. The advantage over signatures is that the technique survives repacking, because repacking a binary does not change what it does once it runs.

The cost is calibration, and it is a serious one. The 2025 SANS detection and response survey found that 73 per cent of organisations name false positives as their primary detection challenge, up year on year, and that more than 60 per cent encounter false positives frequently or very frequently, with the "very frequently" band rising from 13 per cent to 20 per cent. That is what anomaly detection costs at enterprise scale: alert fatigue, analyst burnout, and enough noise for an attacker's lateral movement to hide in.

Signature engines are absorbing machine learning rather than being replaced by it. Talos launched SnortML, a neural network exploit detection engine, in Snort 3.1.82.0 in March 2024, and the current download set ships a libml library alongside the Snort binary.

Update, current as at September 2026. The uncomfortable part of this topic is that the machine learning model is itself an attack surface, and that attackers now use the same technology.

On the first point, the reference document is NIST AI 100-2e2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations", published 20 March 2025. It classifies attacks on predictive systems as evasion (crafting inputs that sit below the decision boundary), poisoning (contaminating the training data or the feedback loop that retrains the model), and privacy attacks (extracting the training data or the model itself). A detection model that retrains on analyst verdicts can be poisoned by an attacker who arranges for benign-looking versions of their tooling to be marked benign.

On the second point, there is now documented evidence rather than speculation. Google Threat Intelligence Group published the first public documentation of "just-in-time" AI in malware on 5 November 2025, naming among others PROMPTSTEAL, a Python data miner that queries a model API to generate Windows commands, deployed by APT28 against Ukraine in June 2025 and described as the first malware observed querying a large language model in live operations, and PROMPTFLUX, an experimental VBScript dropper that asks a model for new evasion code and regenerates its own source hourly. A follow-up report on 12 February 2026 documented model extraction attempts and further families, including a downloader that generates and compiles stage-two code in memory at run time. Anthropic reported on 27 August 2025 that its Claude Code product had been used to run a data extortion campaign against at least seventeen organisations, and on 13 November 2025 described what it assessed as the first documented large-scale cyberattack executed largely without human intervention, against roughly thirty targets, with the model performing an estimated 80 to 90 per cent of the campaign and humans intervening at a handful of decision points; MITRE ATT&CK tracks it as campaign C0062.

The balanced framing, which both Google and Anthropic make themselves, is that the same capability runs on both sides: automated vulnerability discovery and automated patch generation are the defensive counterparts. What has changed is the cost of producing a new variant, which has fallen towards zero. That is the argument for behavioural detection getting more important, not less, and simultaneously the argument for expecting more false positives while models chase a moving target.

What a proxy is, and the three shapes it takes

A proxy is an intermediary. It accepts a connection on behalf of one party and makes its own connection to the other, which means it sees both sides and can act on what it sees.

A forward proxy sits in front of clients and fetches on their behalf. This is where outbound controls get applied: user authentication, URL categorisation, malware scanning, data loss prevention, and logging of who went where. Clients are configured to use it, by browser setting, proxy auto-configuration file or group policy.

A reverse proxy sits in front of servers and accepts client connections on their behalf. This is where inbound controls get applied: TLS termination and offload, load balancing, caching, and web application firewalling. Clients do not know it is there; as far as they are concerned it is the server.

A transparent proxy is a forward proxy the client has not been configured to use, imposed by routing, WCCP redirection or policy-based routing. It removes the need to configure endpoints, and it removes the user's awareness that inspection is occurring, which is a policy question as much as a technical one.

The assessor guide's answer describes the function well: the proxy sits between the user and the service, all traffic flows through it, which is why it can slow the connection down, and why it can perform firewall-like tasks. The features it lists are monitoring and filtering, performance improvement through caching, translation, anonymous access to services, and added security.

Why proxies cause security problems

The unit asks students to identify the methods used to compromise a proxy and the mitigations. The assessor guide's list is a solid starting point: the proxy has an IP address and is therefore exposed to the same attacks as any host; because all data passes through it, compromise of the proxy means compromise of every session it has logged; it sits in series with the traffic and so affects throughput; cheaper proxies do not encrypt, exposing data in transit; and open ports are a potential exposure. Its mitigations are patching promptly, closing unused ports, using proxies that support encryption, and running vulnerability scans against them.

All correct. Here is what to add.

The concentration problem is the real one, and it deserves stating more strongly than "records can be compromised". A forward proxy that performs TLS inspection holds the plaintext of every employee's web session. It is not merely a device on the network; it is the single richest source of credentials, session tokens and confidential documents that the organisation possesses. Whoever controls it does not need to attack anything else.

Which leads to the finding that every student of this topic should know.

Case study: the interception paradox. In 2017, Zakir Durumeric, Zane Ma, Drew Springall, Richard Barnes, Nick Sullivan, Elie Bursztein, Michael Bailey, J. Alex Halderman and Vern Paxson published "The Security Impact of HTTPS Interception" at NDSS. Their method was clever: a web server can detect that a connection has been intercepted, because the middlebox's TLS stack does not behave the way the browser named in the HTTP User-Agent header behaves. Comparing the two reveals the interception.

They measured it at three vantage points and found interception on 4.0 per cent of connections to Firefox update servers, 6.2 per cent of connections to e-commerce sites, and 10.9 per cent of United States connections to Cloudflare, more than an order of magnitude above prior estimates.

Then they graded the security of the intercepted connections, A for equivalent to a modern browser through F for severely broken and vulnerable to active interception by a third party. Of twenty client-side security products tested, roughly 90 per cent reduced connection security and about half introduced severe vulnerabilities. Of twelve corporate middleboxes, eleven weakened security by default and five introduced severe vulnerabilities.

Read that again, because the inversion is the point. The appliance purchased to improve security was, in most cases, downgrading the cipher suites, accepting certificates the browser would have rejected, and in several cases making it possible for a third party to intercept the connection. The organisation bought a security control and installed a vulnerability.

That paper is nearly a decade old and implementations have improved, but the structural problem has not gone away: an interception device must reimplement TLS, and reimplementing TLS well is hard.

Where the proxy went, and the risks that came with it

Update, current as at September 2026. The forward proxy did not disappear; it was renamed and relocated. The secure web gateway inherited its role, and the secure web gateway now sits inside security service edge alongside the cloud access security broker, zero trust network access and firewall as a service. Gartner runs separate Magic Quadrants for security service edge and for single-vendor SASE, which is a fair signal that this is how the function is bought now.

Australian organisations should know that ASD's gateway guidance is directive on this point. The gateway technology guides, published 29 July 2022, state that organisations should implement web security policy and controls through web proxies by default, that the proxy should be identity aware and support user authentication and authorisation, that it should perform virus and unwanted-program detection, that it should block access by file type by default, that it should provide data leakage prevention, and that it should block sites with no categorisation or a categorisation indicating a newly registered domain. ASD also states plainly that effective implementation requires deep packet inspection, which in turn requires TLS decryption capability. So the Australian government position is that interception is expected; the NDSS finding above is the reason it has to be done carefully rather than the reason not to do it.

Three current proxy-specific risks are worth knowing beyond the unit's list.

Misconfiguration turning a reverse proxy into an open relay. The canonical example is Apache mod_proxy configured with a permissive Proxy directive. An attacker who finds one can reach the open internet through it, laundering scans and attacks behind your address; reach the proxy's own localhost, hitting services bound to 127.0.0.1 that were assumed unreachable; and reach your internal RFC 1918 space, using the proxy as a crude network mapper. ProjectDiscovery documented the pattern on 17 January 2022.

Residential proxy networks. This is the current-practice item the unit predates entirely, and it inverts a defensive assumption. Google Threat Intelligence reported on 2 July 2026 that the NetNut network alone spans at least two million devices, and that in June 2026 Google observed 316 distinct threat clusters per week using suspected NetNut exit nodes. The devices are recruited through software development kits bundled into applications that pay users for "unused bandwidth", and through smart televisions and streaming boxes. Attackers use them to mask origin addresses during intrusion and to run password spraying from addresses that look like ordinary home broadband. Many commercial residential proxy brands white-label the same infrastructure. The consequence for defenders is that IP reputation and geolocation blocking degrade badly, because the malicious traffic now arrives from the same ISP ranges as your customers.

Request smuggling and desync. James Kettle of PortSwigger published "HTTP/1.1 must die" on 6 August 2025, arguing that request smuggling is a fundamental protocol flaw rather than a patchable bug class: HTTP/1.1 concatenates requests on a connection, there is more than one way to declare where a request ends, and any place where a front-end proxy and a back-end server disagree about that boundary is exploitable. Affected infrastructure included Cloudflare, Akamai and Netlify, and the research earned around 350,000 US dollars in bounties, which the author donated. His remedy is upstream HTTP/2 with binary framing, which removes the ambiguity rather than patching each parser in turn. The general lesson holds well beyond HTTP: wherever two implementations parse the same input and disagree, there is a vulnerability.

The 802.11 standard

IEEE 802.11 is the family of standards for wireless local area networking. The amendments students meet are 802.11a, b, g, n (marketed as Wi-Fi 4), ac (Wi-Fi 5), ax (Wi-Fi 6 and, in the 6 GHz band, Wi-Fi 6E) and be (Wi-Fi 7). Each amendment increases data rate through wider channels, denser modulation, more spatial streams and more efficient multi-user access; each also inherits the constraints of radio.

The relationship between the physical and data link layers is the point the unit asks about, and it is worth understanding because it explains almost every practical wireless problem.

At the physical layer, 802.11 uses unlicensed spectrum. The 2.4 GHz band is divided into channels each occupying about 22 MHz, spaced 5 MHz apart, which means adjacent channels overlap; the standard practice for a multi-access-point deployment in 2.4 GHz is to use only channels 1, 6 and 11, because those three do not overlap. The 5 GHz band has far more non-overlapping channels, some of which are shared with radar and require dynamic frequency selection. The 6 GHz band, where available, has more again.

At the data link layer, the 802.11 frame resembles an Ethernet frame but carries more fields, because a wireless frame has to identify up to four addresses and carry control information that a wired frame does not need. The important difference is the access method. Ethernet uses collision detection: a station transmits, listens for a collision, and backs off if it hears one. A wireless station cannot do that, because it cannot hear while it is transmitting; its own signal swamps the receiver. So 802.11 uses collision avoidance instead.

Carrier sense multiple access with collision avoidance works like this. The station listens to see whether the channel is idle. It may send a request-to-send frame asking the access point for dedicated access, and wait for a clear-to-send in reply; if no clear-to-send arrives it waits a random interval and starts again. It transmits the data. It waits for an acknowledgement, and if none arrives it assumes a collision and repeats the process.

Two consequences follow, and they explain a great deal. Wireless is half duplex, so the theoretical rate on the box is roughly double the throughput you will actually see. And because every frame is acknowledged and every station shares the medium, adding stations degrades everyone's performance in a way that adding hosts to a switched Ethernet does not.

WLAN architectures

Ad hoc mode, formally an independent basic service set, connects clients peer to peer with no access point. Useful for a direct file transfer, awkward for anything else, because there is no central point to apply policy.

Infrastructure mode is the normal case: clients associate with an access point, which bridges them to the wired network. One access point and its clients form a basic service set, identified by the access point's MAC address as the BSSID; several access points sharing a network name form an extended service set, which is what lets a client roam across a building while staying on the same SSID.

Tethering uses a phone's cellular data connection to provide a hotspot. Technically it is infrastructure mode with the phone as the access point, and from a security point of view it is a device on the organisation's premises bridging the corporate laptop to a network the organisation does not control. Which is exactly the rogue access point problem in a form that is difficult to prohibit.

Controller-based and cloud-managed architectures are the enterprise reality. Access points are thin, forwarding traffic and configuration decisions to a wireless LAN controller, either on the premises or in the vendor's cloud, which holds policy centrally, coordinates channel and power assignment, and handles roaming.

Authentication and association

A client joining a wireless network completes three steps, in order.

sequenceDiagram
 participant C as Wireless client
 participant A as Access point
 C->>A: Probe request, or passive scan for beacons
 A->>C: Probe response or beacon, carrying SSID and capabilities
 C->>A: Authentication request
 A->>C: Authentication response
 C->>A: Association request
 A->>C: Association response, association identifier assigned
 Note over C,A: 802.1X or SAE exchange, then four-way handshake, then data

Discovery: the client either listens passively for beacon frames or sends probe requests and reads the responses.

Authentication: at this stage the 802.11 sense of the word, which is not the same as proving who the user is. Open system authentication is a two-frame exchange that succeeds unconditionally, and is what public networks use before any higher-layer check. Shared key authentication, the original WEP mechanism, is obsolete and was actually worse than open system, because the challenge-response exchange leaked keystream.

Association: the client requests association and the access point assigns an association identifier, after which the client is a member of the basic service set.

For the client and access point to get this far, several parameters must agree: the SSID, the 802.11 standard in use, the security mode (WPA2, WPA3 and so on), and the channel and band.

The security work happens after association. On a personal network, the four-way handshake derives session keys; on WPA3 that is preceded by the SAE exchange. On an enterprise network, 802.1X runs and the EAP method does the real authentication before keys are derived.

WLAN encryption: strengths and weaknesses

WEP is obsolete. It was deprecated in 802.11i-2004, carried as deprecated through 802.11-2016, and reclassified as obsolete in 802.11-2020. Its RC4 key scheduling leaks key material through weak initialisation vectors, which is what AirSnort was built to collect. Do not deploy it, and treat its presence on a network as an incident rather than a configuration choice.

WPA with TKIP was the transitional fix that let existing hardware be patched rather than replaced. It wraps WEP's cipher in per-packet key mixing and a message integrity check. It is deprecated, it is prohibited in Wi-Fi Alliance certification, and it is not permitted with WPA3. Windows 11 blocks new connections to WEP and TKIP networks, which is the practical end of the road for both on any managed fleet.

WPA2 with AES-CCMP is the workhorse most students will actually meet. Advanced Encryption Standard in Counter mode with CBC-MAC Protocol provides confidentiality and integrity properly, and the cipher itself is not the problem. The problem is key establishment. WPA2-Personal derives the pairwise master key directly from the passphrase, so anyone who captures a four-way handshake has material they can guess against offline, indefinitely, at whatever rate their hardware allows. Which brings us to the attack that changed the practical position.

Did you know? In August 2018, Jens Steube, the developer of hashcat, found while researching WPA3 that many access points include a PMKID in the first message of the four-way handshake, inside the robust security network information element. That single frame is enough to mount the same offline dictionary attack. The significance is that it is clientless: no associated station is needed, no handshake capture, no deauthentication of a legitimate user. Before this, the standard answer to "how do I get a handshake?" was "wait for someone to connect, or force them to reconnect". After it, that was no longer true. The defence is unchanged and unglamorous: a long, random passphrase, because the attack still has to guess it.

WPA3 addresses key establishment directly. Simultaneous Authentication of Equals, the Dragonfly handshake, is a balanced password-authenticated key exchange in which each side proves knowledge of the password through a commit and confirm exchange, without transmitting anything from which the password can be recovered offline. Each guess therefore requires a fresh live exchange with the access point, which is rate-limited, logged and visible. SAE also provides forward secrecy: session keys are ephemeral, so recovering the password later does not decrypt traffic captured earlier.

WPA3 brings three related pieces. Protected Management Frames, specified in 802.11w and optional under WPA2, are mandatory in all WPA3 modes. They authenticate management frames, which blocks spoofed deauthentication and disassociation, the forced-reconnection step that most published Wi-Fi attack walkthroughs depend on, and forged channel switch or BSS transition frames used to steer a client to an evil twin. Enhanced Open, using Opportunistic Wireless Encryption, performs an unauthenticated Diffie-Hellman exchange during association so each client on an open network gets individually encrypted traffic with no password; it stops passive sniffing on a public network, and because it does not authenticate the access point it does not stop an evil twin. Wi-Fi Easy Connect, the Device Provisioning Protocol, onboards headless devices by scanning a QR code or using Bluetooth or NFC to bootstrap a public key, and is the sanctioned replacement for WPS and its brute-forceable PIN.

WPA3-Enterprise 192-bit mode is an optional profile, not the default: GCMP-256 for confidentiality, HMAC-SHA384 for key derivation and integrity, ECDSA and ECDHE on P-384, and EAP-TLS with certificates. There is no transition mode for it.

WPA3 was not perfect on arrival. In April 2019 Mathy Vanhoef and Eyal Ronen published Dragonblood, which found downgrade attacks (forcing WPA3-Transition mode back to WPA2 and restoring the offline dictionary attack, and downgrading the security group to a weaker curve), timing and cache side channels in the original hunting-and-pecking password element derivation that enabled a password partitioning attack, a denial of service through forged commit frames, and related flaws in EAP-pwd. A second round in August 2019 showed side-channel leakage persisting with Brainpool curves. Vendors patched under coordinated disclosure, and the structural fix is Hash-to-Element, added in 802.11-2020, which replaces the variable-time loop with a constant-time one-time derivation and also protects against group downgrade. H2E is required for 6 GHz and Wi-Fi 7 compliance.

Update, current as at September 2026. The practical position on WPA3 is better than the Dragonblood headlines suggest, with one large caveat.

What works against a correctly configured WPA3 network is short. Nothing recovers an SAE passphrase from a passive capture; that is the design point. Denial of service through commit-frame flooding still works and is cheap. Evil twin and rogue access point attacks still work, because SAE authenticates the password and not the network's identity, and Enhanced Open authenticates nothing at all; the client-side defence is server certificate validation on enterprise networks and user vigilance on personal ones. And because Protected Management Frames are mandatory, the deauthentication step that most tutorials open with simply fails.

The caveat is transition mode. Where an SSID advertises WPA3 and WPA2 together, an attacker forces the WPA2 path and then runs the ordinary PMKID or four-way-handshake offline attack. This is why the 6 GHz band forbids transition mode entirely, and why "WPA3 enabled" and "WPA3 only" are meaningfully different configurations. If you take one operational point from this section, take that one.

The certification requirements now enforce this. WPA3 has been mandatory for all new Wi-Fi CERTIFIED devices since July 2020. Wi-Fi CERTIFIED 6 requires WPA3. Wi-Fi 6E devices operating in 6 GHz must use WPA3, WPA2 is not permitted in that band at all, and there is no transition mode there. Wi-Fi 7 requires WPA3 on all bands, with GCMP-256 for Personal and Enhanced Open, mandatory beacon protection, and SAE-EXT-KEY required for Personal mode.

On the standards themselves: the Wi-Fi Alliance launched Wi-Fi CERTIFIED 7 on 8 January 2024 against a draft amendment; IEEE 802.11be-2024 received Standards Board approval on 26 September 2024 and was published on 22 July 2025. Certification preceded ratification by about nine months and publication by eighteen, which is normal for Wi-Fi and worth knowing when a datasheet and a standard appear to disagree. On 7 January 2026 the Alliance extended Wi-Fi 7 certification to 20 MHz-only devices, bringing multi-link operation and 4K QAM to IoT and industrial devices that do not use wide channels. Wi-Fi 8, 802.11bn, is projected for certification around January 2028 with IEEE approval around May 2028; those are projections and IEEE timelines slip.

Australian spectrum: what is actually available here

This is the part where international material misleads Australian students, so it is worth stating carefully.

The 2.4 GHz and 5 GHz bands are available under the Low Interference Potential Devices class licence as they always have been.

The lower 6 GHz band, 5925 to 6425 MHz, was opened for wireless local area network use following ACMA's 2021 consultation, with the outcomes paper published in March 2022. That is 500 MHz, not the 1200 MHz the United States released.

The upper 6 GHz band is where the Australian position differs sharply from the American one. ACMA consulted through 2024 and announced its decision on 17 December 2024, splitting the band: part to Wi-Fi through a variation to the class licence, and the remainder reserved for wide-area wireless broadband, meaning mobile, through apparatus or spectrum licensing. The implementation came with the Radiocommunications (Low Interference Potential Devices) Class Licence 2025, whose outcomes paper was published 5 September 2025 and which commenced on 1 October 2025, replacing the 2015 instrument. It adds RLAN transmitters in 6425 to 6585 MHz.

So the correct statement for Australia as at September 2026 is that 5925 to 6585 MHz is available for Wi-Fi, which is 660 MHz. Not 1200 MHz. Several trade publications described the December 2024 decision as "opening the upper 6 GHz band"; only the bottom 160 MHz of it was opened, and only for Wi-Fi. The remainder, roughly 6585 to 7125 MHz, is held for mobile with no allocation date set.

One further item is genuinely in progress. Australian 6 GHz operation is currently low power indoor and very low power; standard power and outdoor use would require an automated frequency coordination system to protect incumbent fixed links. ACMA opened a discussion paper on automated frequency coordination on 5 November 2025, with consultation closing 6 February 2026, covering whether to enable it, who would operate it, the licensing model and incumbent protection. As at September 2026 ACMA lists it as under review with no decision published. A trial has run in South Australia. This is a live question and the answer will change what Australian outdoor and campus wireless design looks like.

Tools for discovering available WLANs

The unit asks students to identify three tools that discover details about available WLANs and describe how each would be used. The assessor guide's list is Aircrack-ng, Kismet, AirSnort and NetStumbler, sourced from a listicle. Two of those four have not been maintained in twenty years, which makes this a useful exercise in checking a tool's currency before recommending it.

Aircrack-ng is a suite rather than a single tool. airmon-ng puts an adapter into monitor mode; airodump-ng captures and displays networks, clients, channels, encryption and signal; aireplay-ng injects frames, including the deauthentication that Protected Management Frames now blocks; aircrack-ng itself performs the offline cracking. Its most recent numbered release is 1.7, dated 10 May 2022; development continues in the repository without a new release. Airodump-ng has detected WPA3 and Enhanced Open, and flagged PMKIDs, since version 1.6 in January 2020. Note a discrepancy worth knowing about: some GitHub views render 1.7 as May 2023, while the project's own news page and Wikipedia both give May 2022.

Kismet is the better example of a modern passive discovery tool, and it is actively maintained on rolling date-stamped releases; the current stable release is 2025-09-R1. Kismet is passive by design, so it detects networks that do not broadcast their SSID by watching for client traffic, and it has expanded well beyond Wi-Fi into Bluetooth, general radio and other protocols.

hcxdumptool and hcxtools, maintained by ZerBea, are now the primary capture path for PMKID and EAPOL material, with hcxdumptool at 7.1.2 as at 8 February 2025 after a substantial rewrite in 7.0.0 in August 2024. hcxtools converts captures into hashcat and John the Ripper formats.

Wifite, in the maintained kimocoder/wifite2 fork at 2.8.2 as at 25 October 2024, is an orchestrator rather than an attack tool; it drives aircrack-ng, hcxdumptool, hashcat, reaver and bully. Useful for demonstrating a workflow, less useful for understanding one.

NetStumbler last released version 0.4.0 in April 2004 and supports Windows 2000 to XP. AirSnort last released 0.2.7e on 10 January 2005 and attacks WEP by collecting weak initialisation vectors, which is obsolete twice over. Both still appear in TAFE and certification material. They are a good illustration of syllabus drift, and naming them as such is more useful than quietly dropping them.

A note on lawful use, since this is a study page and not an invitation. Running any of these against a network you do not own or have written authority to test is an offence under Part 10.7 of the Criminal Code Act 1995 (Cth), which is covered in VU23223. Use your own equipment, a lab, or a documented authorisation.

A WLAN security checklist

The unit asks students to select a published WLAN security checklist, discuss its merits, and identify what it is missing. Here is one built for an Australian organisation in 2026, with the reasoning attached rather than a bare list.

Use WPA3 only, not WPA3 transition mode, wherever the client fleet allows it. Where legacy devices force transition mode, put them on a separate SSID with restricted network access rather than weakening the main one.

Never deploy WEP or TKIP, and treat their presence as an incident. Ensure Protected Management Frames are enabled, which WPA3 does for you.

Use 802.1X with EAP-TLS for corporate access. Where PEAP-MSCHAPv2 must be used, enforce server certificate validation and pin the trusted root through device management, because the whole security of that method rests on it.

Give guests and personal devices a separate SSID with client isolation, no route to internal networks, and a captive portal or Enhanced Open rather than a shared passphrase that is written on a whiteboard.

Change all default credentials on access points, controllers and management interfaces, and put wireless management on a network that ordinary users cannot reach.

Segment by function. Corporate devices, guests, building services and IoT belong on separate networks with policy between them; a camera should not be able to reach a file server.

Patch access points and controllers on a defined schedule, and track vendor advisories for the equipment you actually own. Wireless infrastructure is edge infrastructure and inherits everything in the edge device guidance.

Monitor. Wireless intrusion detection to spot rogue and evil twin access points, and centralised logging of association, authentication and RADIUS events so that an unusual pattern is visible after the fact.

Survey the site, and revisit it. Coverage that spills into the car park or the neighbouring tenancy is an unnecessary exposure, and the RF environment changes as walls, furniture and neighbours change.

Secure remote access properly, with MFA, rather than relying on the wireless network's own security as though it were a perimeter.

Maintain a device inventory, including the wireless devices nobody thinks of as computers, and back up controller configurations.

Educate staff about connecting to unknown networks, and about tethering, which is the rogue access point that walks in every morning in a pocket.

What most published checklists miss, and what the merit discussion should cover: they list controls and omit the decision framework. They rarely say what to do when a legacy device cannot support the control, which is the situation an actual administrator is in. They almost never mention monitoring or logging, only prevention. They tend to omit the physical layer entirely, so coverage spill and access point physical security go unmentioned. And they are usually silent on who is accountable for reviewing the configuration, which is why the checklist is completed once at installation and never again.

The vocabulary

Cryptology is the study of secret codes, and it splits into two disciplines. Cryptography is the development and use of codes. Cryptanalysis is the breaking of them. A cryptographer designs; a cryptanalyst attacks. Both are needed, because a cipher nobody has tried to break is a cipher nobody has any reason to trust.

Three services are what cryptography actually delivers on a network, and keeping them separate is the single most useful thing in this topic.

Confidentiality means the data has not been read by anyone else. Encryption provides it.

Integrity means the data has not been altered. Hashing provides it, with a qualification below.

Authenticity, or origin authentication, means the data came from the party it claims to have come from. Message authentication codes and digital signatures provide it.

A fourth, non-repudiation, means the sender cannot later deny having sent it. Only digital signatures provide that, because only they use a key that one party alone holds.

Symmetric and asymmetric algorithms

Symmetric algorithms use the same key to encrypt and decrypt. The key must be shared with the other party before any protected communication can occur, which is the whole difficulty. Think of two people with identical keys to one padlock: whoever locks the box, the other can open it, and either can send in either direction, but at some point those keys had to be handed over. Symmetric algorithms are fast, which is why they carry the bulk data in every protocol you will meet. AES is the standard, and AES-256 is the current target.

Asymmetric algorithms, also called public key algorithms, use a mathematically related pair: what one key encrypts, only the other can decrypt, and neither can be derived from the other in any reasonable time. That solves the distribution problem, because the public key can be published. It is far slower, so it is used to establish keys and to sign, not to encrypt bulk data. Protocols built on it include Internet Key Exchange, the foundation of IPsec VPNs; TLS, the successor to SSL; SSH; and PGP.

Almost every real protocol is a hybrid: asymmetric cryptography establishes a shared secret, then symmetric cryptography does the work.

Hashes, message authentication codes and digital signatures

A hash is a one-way function: easy to compute, infeasible to reverse, and producing a fixed-length output from any input. Change one bit of the input and the output changes completely. Hashes verify integrity by comparison; if the hash you compute matches the hash you were given, the data has not changed.

Here is the qualification the assessor guide gets right and many textbooks skip. Hashing alone detects accidental change, not deliberate change. An attacker who alters the message in transit can simply recompute the hash and send that too. To detect deliberate alteration you need something the attacker does not have.

That is what a hash-based message authentication code provides. HMAC combines the message with a secret key known only to sender and receiver before hashing, so an attacker cannot recompute a valid code without the key. HMAC-SHA-256 is the common current construction.

A digital signature goes further. The sender hashes the message and encrypts the hash with their private key. Anyone with the public key can decrypt it and compare, which proves that the holder of the private key produced it, that the message has not changed, and, because only the sender holds that key, that the sender cannot deny it. Three services in one construction: authenticity, integrity and non-repudiation. The standards are DSA, RSA and ECDSA.

Two uses students meet daily. Code signing wraps an executable in a signed envelope so the operating system can verify, before installation, that the code is authentic, unmodified and from the stated publisher. Digital certificates bind a public key to an identity, verified by a third party.

Public key infrastructure

A public key is only useful if you know whose it is. Public key infrastructure is the machinery that answers that question at scale.

flowchart TD
 CA[Certification authority] -->|issues signed certificate| B[Bob's server]
 CA -->|its own root certificate is pre-installed| A[Alice's browser]
 B -->|presents certificate during TLS handshake| A
 A -->|validates signature chain, name, validity dates| A2{Trusted?}
 A2 -->|yes| OK[Establish session]
 A2 -->|no| WARN[Warn or refuse]
 A -->|optionally checks revocation via OCSP or CRL| CA

A certification authority investigates an applicant's identity, then issues a digital certificate binding the applicant's public key to that identity, signed with the authority's own private key. Anyone who trusts the authority, which in practice means anyone whose operating system or browser ships the authority's root certificate, accepts the certificates it issues. The trust is transitive and that is the point: Alice does not need to have met Bob, she only needs to trust the authority that vouched for him.

Validation checks more than the signature. The name in the certificate must match the site being visited, the certificate must be within its validity dates, the chain must lead to a trusted root, and the certificate must not have been revoked, which is checked through a certificate revocation list or the Online Certificate Status Protocol.

The weaknesses of the model are worth knowing. Any trusted authority can issue a certificate for any name, so the security of the whole system is that of its weakest member; certificate transparency logs exist to make misissuance detectable. Revocation checking is unreliable in practice, which is why certificate lifetimes have been shortened rather than relying on it. And an organisation performing TLS inspection installs its own root on every managed device, which is precisely how the interception described in the proxy section works, and precisely why it must be protected as carefully as anything else the organisation owns.

Standards and protocols in common use

The protocols. TLS, which replaced SSL, protects HTTPS and much else, providing encryption, authentication and integrity; TLS 1.3, standardised in RFC 8446 in August 2018, is the current version and removed the older algorithms outright rather than deprecating them. IPsec provides the same three services at the network layer and is the basis of site-to-site VPNs. SSH provides secure remote access to devices. PGP, now OpenPGP, encrypts and signs messages, most visibly email.

The algorithms, with their current status, because this is where older material dates fastest.

Update, current as at September 2026. Several of the algorithms taught in older network security material are now formally out, and the transition dates are worth knowing.

MD5 was never a NIST-approved hash. The formal position is RFC 6151 of March 2011: MD5 is no longer acceptable where collision resistance is required, such as digital signatures, though it remains usable for non-adversarial error detection. Note the distinction, because it matters: attacks on HMAC-MD5 do not show a practical break of it as a message authentication code, so "MD5 is broken" and "HMAC-MD5 is broken" are different claims. BlastRADIUS, described in the authentication section, is what happens when an MD5 collision meets a protocol that assumed it did not matter.

SHA-1 is on a published timetable. NIST announced on 15 December 2022 that it will transition away from SHA-1 for applying cryptographic protection in all applications by 31 December 2030; it has been disallowed for signature generation for far longer. Do not select it for anything new.

3DES is already past its date. NIST deprecated it for all applications through 2023 and disallowed it after 31 December 2023, and withdrew SP 800-67 Rev. 2 effective 1 January 2024. Decrypting legacy data is still permitted; encrypting new data is not. Material presenting 3DES as a current option is simply wrong now.

DES was withdrawn in 2005, and RC4 was prohibited in TLS by RFC 7465 in February 2015.

AES and SHA-2 are unaffected. AES-128, AES-192 and AES-256 all remain acceptable; ASD names AES-256 specifically as the target. SHA-2 and SHA-3 variants are fine except the 224-bit ones, which follow SHA-1's timetable.

RSA-2048 is acceptable through 31 December 2030 in NIST's draft transition schedule, then deprecated; RSA-3072 meets the higher security bar. Both of those are classical framings, and the next paragraph is why they do not settle the question.

Update, current as at September 2026: the post-quantum transition, and why Australia's date is earlier

A sufficiently large quantum computer would break RSA, Diffie-Hellman and elliptic curve cryptography outright, using Shor's algorithm. No such machine exists today. The reason this is an operational problem now rather than a future one is store-now-decrypt-later: an adversary who records encrypted traffic today can decrypt it whenever such a machine arrives, which matters for anything that must stay confidential for a decade or more.

Symmetric cryptography is affected far less. Grover's algorithm gives a quadratic speed-up against key search, and the answer is to double the key length, which is why AES-256 rather than AES-128 is the recommendation.

NIST released the first three post-quantum standards on 13 August 2024, effective on publication in the Federal Register the following day: FIPS 203 for ML-KEM, formerly Kyber, the key encapsulation mechanism; FIPS 204 for ML-DSA, formerly Dilithium, the primary signature standard; and FIPS 205 for SLH-DSA, formerly SPHINCS+, a signature scheme built on hashing rather than lattices as a hedge. NIST announced HQC as a fifth algorithm on 11 March 2025, a code-based backup to ML-KEM, and estimated a draft standard about a year later; as at September 2026 no HQC draft appears on NIST's news listing, so that has slipped. The status of FIPS 206, for FN-DSA (formerly Falcon), is similar: NIST submitted a draft for approval on 28 August 2025 and presented a status update at its September 2025 conference, and vendor commentary has treated a public draft as imminent, but NIST's public news feed does not confirm one. Both are fair to describe as in progress and not yet delivered.

Deployment is further along than most people expect, at least in TLS. The hybrid key exchange X25519MLKEM768, which combines classical elliptic curve Diffie-Hellman with ML-KEM so that breaking either alone is not enough, is on by default in Chrome, Edge, Firefox, Brave, Opera and Safari, and supported server-side in OpenSSL 3.5 and later, Go 1.24 and later, BoringSSL, Caddy and Traefik. Cloudflare reported the post-quantum share of human web traffic on its network rising from 29 per cent at the start of 2025 to 52 per cent by early December 2025, driven substantially by Apple enabling it in iOS 26, and figures of around 65 to 67 per cent in the first half of 2026. Those are one company's measurements of its own network, there is no independent internet-wide equivalent, and the number moves month to month; that is the honest way to state it.

SSH is also well advanced. OpenSSH added a post-quantum key agreement as a default in version 9.0 in April 2022, added the ML-KEM hybrid in 9.9, made it the default in 10.0 in April 2025, and from 10.1 warns on connections that do not use a post-quantum key exchange on store-now-decrypt-later grounds.

IPsec is behind. RFC 9370 supplies the framework for multiple key exchanges in IKEv2, and the ML-KEM-specific specification reached version 09 on 5 July 2026 and sits in the RFC Editor queue rather than being published.

Now the Australian part, which is the reason this belongs in a unit taught here.

The Australian Signals Directorate has set an earlier deadline than the United States. ISM control ISM-1917, as updated in the December 2024 release of the Information Security Manual, requires that the development and procurement of new cryptographic equipment and software ensures support for ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030. It applies at all classifications, not only to high assurance systems. The same release signalled that RSA, Diffie-Hellman, elliptic curve Diffie-Hellman and ECDSA cease to be ASD-approved algorithms after the end of 2030, with staged milestones: a refined transition plan by the end of 2026, transition of critical systems commenced by the end of 2028, and transition complete by the end of 2030.

Compare NIST, whose draft IR 8547 deprecates the classical algorithms after 2030 and disallows them after 2035. That is a five-year gap between the Australian and American positions, and it is a real one for any Australian organisation with a procurement cycle longer than a few years.

Two further points deserve stating as the grey areas they are. ASD prefers the larger parameter sets, ML-KEM-1024 and ML-DSA-87, and does not approve ML-KEM-768 or ML-DSA-65 beyond 2030, while the hybrid deployed in every browser today uses ML-KEM-768. And ASD treats hybrid post-quantum and classical schemes as transitional rather than as an end state, while NIST, the IETF and every shipping browser and SSH client have standardised on hybrids. That is a genuine divergence between Australian government policy and current global practice, and anyone planning a transition here needs to know it exists. It is also worth noting that the NIST transition documents most often quoted, SP 800-131A Rev. 3 and IR 8547, are both still initial public drafts, so the dates in them are widely cited as settled and are not.

What a VPN is for

A virtual private network carries private traffic across a public network as though the two ends were on the same private link. The word doing the work is "virtual": there is no dedicated circuit, only encapsulation and, usually, encryption.

The advantages the unit asks about are cost, security, scalability and compatibility. Cost, because a VPN over the internet is cheaper than a leased line between two offices. Security, because the payload is encrypted, authenticated and integrity-protected across a network nobody controls. Scalability, because adding a site or a user is a configuration change rather than a civil works project. Compatibility, because the tunnel carries whatever the private network carries, including protocols the public network does not route.

Two deployment shapes. A site-to-site VPN joins two networks through gateways at each end; the hosts behind those gateways do not know it exists and need no software. A remote access VPN connects an individual device to a network, with the user running a client, or in some cases a browser.

Tunnelling

Tunnelling means carrying packets across a network by wrapping them inside other packets. The original packet, with its original source and destination addresses, becomes the payload of a new packet addressed between the two tunnel endpoints. The intermediate network routes the outer packet normally, without knowing or caring about the inner one. At the far end the outer header is stripped and the original packet continues on its way.

The unit's first VPN lab builds exactly this with a generic routing encapsulation tunnel between R1 and R3, with R2 in the middle as an ordinary router that knows nothing about the tunnel.

flowchart LR
 L1["R1 Loopback0, 1.1.1.1"] --> R1
 R1["R1, tunnel0 12.12.12.1"] -->|"outer header: 192.168.13.1 to 192.168.23.2, carrying inner 1.1.1.1 to 2.2.2.2"| R2["R2, ordinary routing, no tunnel awareness"]
 R2 --> R3["R3, tunnel0 12.12.12.2"]
 R3 -->|"outer header removed, inner packet delivered"| L2["R3 Loopback0, 2.2.2.2"]

The configuration on each end is short, and every line of it earns its place.

interface tunnel0
 ip address 12.12.12.1 255.255.255.252
 mtu 1476
 tunnel source g0/0/0
 tunnel destination 192.168.23.2

The tunnel interface gets its own address on its own small subnet, which is the address space of the virtual link. The tunnel source is the local physical interface the outer packets will leave from, and the tunnel destination is the far end's physical address, which must be reachable by ordinary routing; if R1 cannot ping 192.168.23.2 without the tunnel, the tunnel will not come up. The MTU of 1476 accounts for the 24 bytes of GRE and outer IP header that the encapsulation adds to a 1500-byte packet; get this wrong and you produce the classic tunnel fault where small packets work, pings work, and large transfers hang.

Static routes then point the loopback networks at the tunnel rather than at the physical path, which is what makes the traffic take the tunnel at all.

What actually happens to a packet from 1.1.1.1 to 2.2.2.2: R1's routing table sends it to tunnel0, the tunnel interface encapsulates it in a new packet from 192.168.13.1 to 192.168.23.2, R2 forwards that as ordinary traffic, R3 receives it, strips the outer header, and forwards the original packet to its own loopback. A traceroute from R1 to R3's loopback shows one hop, because R2 is invisible from inside the tunnel. That single observation is the clearest demonstration of what tunnelling does.

The three encapsulation protocols the unit names: GRE, which adds a GRE header and can carry non-IP protocols and multicast, which is why it is often used to carry a routing protocol; IP-in-IP, which is the same idea without the GRE header and therefore without multicast support; and IPsec, which is not merely encapsulation but a protocol suite providing encryption and authentication as well.

The point the lab is building towards is stated in its own analysis question: a GRE tunnel gives a direct virtual connection, and the obvious next step is to encrypt it. A tunnel is the basis of a VPN; it is not yet a VPN.

IPsec

IPsec, summarised in RFC 6071, is a suite rather than a single protocol, and it provides four things.

Confidentiality, through encryption, so the packet contents cannot be read. Integrity, through hashing, so alteration in transit is detected. Origin authentication, through Internet Key Exchange, using pre-shared keys, digital certificates or RSA keys. And secure key exchange, through Diffie-Hellman, so that two peers can establish a shared secret across a network where everything they say is overheard.

The framework has choices at each point, which is what the IPsec configuration tables in the lab are actually expressing.

The IPsec protocol is either Authentication Header, which authenticates the whole layer 3 packet including the header, or Encapsulating Security Payload, which encrypts and authenticates the payload. In practice it is always ESP, and the reason is instructive: because AH authenticates the IP header, any device that rewrites the header breaks it, and network address translation rewrites the header. AH and NAT cannot coexist, and NAT is everywhere.

Confidentiality is provided by the encryption algorithm: historically DES, 3DES, AES or SEAL; in current practice AES, and preferably AES-GCM.

Integrity is provided by a hash: historically MD5 or SHA-1; in current practice SHA-256 or better.

Authentication is handled by IKE, using pre-shared keys, one-time passwords, biometrics or certificates.

And Diffie-Hellman group selection determines the strength of the key exchange.

sequenceDiagram
 participant A as Peer A
 participant B as Peer B
 Note over A,B: IKE phase 1, establish a protected management channel
 A->>B: Propose ISAKMP policy, encryption, hash, DH group, authentication, lifetime
 B->>A: Accept a matching policy
 A->>B: Diffie-Hellman key exchange
 B->>A: Diffie-Hellman key exchange
 A->>B: Authenticate, pre-shared key or certificate
 B->>A: Authenticate
 Note over A,B: IKE phase 2, negotiate the tunnel that carries user data
 A->>B: Propose transform set and interesting traffic
 B->>A: Agree, security associations established
 Note over A,B: Encrypted data flows

The configuration follows that structure exactly, which is why understanding the two phases makes the commands memorable rather than arbitrary. Phase one builds a protected channel between the two peers so that phase two can be negotiated privately. Phase two builds the security associations that actually carry user traffic. A crypto access list defines which traffic is "interesting" and therefore should be protected; a transform set names the algorithms; a crypto map ties the peer, the access list and the transform set together; and the crypto map is applied to the outside interface. When a site-to-site tunnel will not come up, the fault is almost always a mismatch in the phase one policy, a mismatched pre-shared key, or crypto access lists at the two ends that are not exact mirrors of each other.

Update, current as at September 2026. Three points where the older material has been overtaken.

IKEv1 is formally deprecated. RFC 9395, published April 2023, moves IKEv1 and its supporting documents to Historic status, noting it had been superseded by IKEv2 for more than fifteen years, and it also deprecates a list of obsolete algorithms including HMAC-MD5-128 and the DES variants. Configure IKEv2.

Diffie-Hellman group selection has moved. RFC 8247 marks group 1 (768-bit MODP) as MUST NOT, describing it as breakable within hours on cheap hardware, and groups 2 (1024-bit) and 5 (1536-bit) as SHOULD NOT. Group 14 (2048-bit MODP) is the MUST, raised from a weaker recommendation specifically to replace group 2, and group 19 (256-bit elliptic curve) is a SHOULD. Current practice goes further than the RFC and prefers the elliptic curve groups, 19, 20 and 21, or group 31 for Curve25519, on both security margin and performance grounds. Note that RFC 8247 is itself nine years old, and the post-quantum work sits on top of it rather than replacing it.

Algorithm requirements for ESP have tightened. RFC 8221 makes AES-GCM a MUST in order to push deployments towards authenticated encryption, keeps AES-CBC as a MUST for interoperability, marks 3DES as SHOULD NOT, marks DES and Blowfish as MUST NOT, makes HMAC-SHA-256 a MUST, downgrades HMAC-SHA-1 to SHOULD NOT, and marks HMAC-MD5 as MUST NOT. It also marks the combination of ESP with null encryption plus AH as NOT RECOMMENDED, since ESP with null encryption alone provides the same authentication with less overhead.

Remote access VPN software

The unit asks students to compare three commercial remote access VPN products on cost, features and ease of implementation. The assessor guide names NordLayer, ExpressVPN and Cisco AnyConnect with 2023 prices attached.

Two problems with that exercise, and both are worth naming rather than working around. Published per-user prices go stale within months, so any figure written into a study page is wrong by the time it is read; the right approach is to state the pricing model rather than the price. And two of the three named products are consumer VPN services being used to illustrate an enterprise remote access problem, which conflates two different things.

The distinction is worth making clearly, because students meet both under the same word. A consumer VPN service moves the point at which your traffic enters the internet, so that your internet service provider and the local network see an encrypted tunnel rather than your browsing, and the destination sees the provider's address rather than yours. It is a privacy and geolocation tool. An enterprise remote access VPN connects a device into an organisation's private network so it can reach internal systems. Both encrypt a tunnel; they solve different problems and they have different threat models.

For enterprise remote access, the architecture matters more than the brand. The gateway authenticates the user and the device and creates the tunnel; the client software may be a full agent, or the connection may be made through a browser in what used to be called web mode. What is worth comparing is: how the gateway authenticates (does it support certificate-based device authentication and phishing-resistant MFA, or only a password and a code?), whether policy is per-network or per-application, how the client is deployed and updated across a fleet, what logging the gateway produces and where it goes, and how quickly the vendor patches and how well they communicate when they do. That last criterion has stopped being a soft factor.

Update, current as at September 2026: the remote access VPN is being dismantled

The section of the unit that has aged fastest is this one, and the evidence is not a prediction; it is a list.

Ivanti Connect Secure was exploited through CVE-2023-46805 and CVE-2024-21887 from January 2024, then again through CVE-2025-0282 in January 2025, then again through CVE-2025-22457 disclosed in April 2025, which had been quietly patched in February as an assumed product bug until an actor reverse-engineered the patch and worked out what it fixed. Fortinet's FortiOS SSL-VPN carried CVE-2024-21762 in February 2024, an unauthenticated remote code execution added to CISA's known exploited vulnerabilities catalogue the day it was disclosed. Citrix produced CitrixBleed in 2023 and CitrixBleed 2 in June 2025, with exploitation beginning before the public proof of concept, followed by CVE-2025-7775 in August 2025. Palo Alto's GlobalProtect carried CVE-2024-3400 in April 2024. SonicWall's SSL VPN was the route into the Akira ransomware campaign that ASD wrote about specifically for Australia in September 2025. And Cisco's ASA, covered in the firewall section.

The clearest signal that this is architectural rather than a run of bad luck is that Fortinet is removing SSL-VPN from its own products. From FortiOS 7.6.3, SSL VPN tunnel mode is replaced by IPsec VPN, which can be configured to use TCP port 443; the feature is no longer available in the graphical interface or the command line, this applies to all FortiGate models, and customers must migrate their configuration before upgrading. Web mode had already been removed from smaller models in 7.6.0, and what remains of it on larger models has been renamed Agentless VPN. A vendor that built much of its remote access business on SSL-VPN has concluded that a TLS-terminating web application sitting on the security perimeter, reachable by anyone on the internet, is the wrong shape.

Australia got its own demonstration in June 2026. The ACSC issued a critical alert on 18 June 2026, reissued on 22 June after Fortinet updated its guidance, about credential reuse against Fortinet FortiGate firewalls and VPN gateways. No new vulnerability was involved. Attackers were using credentials harvested in two earlier incidents, from December 2025 and January 2026, to log in legitimately, obtain remote access, and alter security controls. The ACSC noted that Fortinet devices are embedded across Australian corporate, government, healthcare and critical infrastructure environments. Fortinet's recommendations were to reset credentials, enforce MFA, upgrade, validate configurations, review logs for unauthorised access, and restrict management access.

The teaching point is the one the SonicWall advisory made nine months earlier and this one made again: organisations that upgraded the firmware and did not rotate the credentials stayed exposed. Patching is not remediation when the thing that leaked was not the code.

Reported scale figures for that campaign differ. Arctic Wolf and Insurance Business reported approximately 86,644 credentials harvested across 194 countries by mid-June 2026; Cyber Daily reported over 30,000 devices compromised across about 200 countries. Those two counts measure different things and were published at different points in a moving campaign. No figure for affected Australian organisations was published, and no Australian organisation has been publicly named as breached through an edge device in this period; Australian reporting stays at the advisory and aggregate level.

VPN-less remote access

The unit's last performance criterion asks students to examine VPN-less alternatives, and the assessor guide's answer names the right three: zero trust network access, secure access service edge and software-defined wide area networking. Here is what each actually means, and what is settled and what is not.

The drawbacks of the VPN model that these address: a VPN typically grants access to a network rather than to an application, so an attacker who obtains a credential is inside the network; the gateway must be reachable from the internet, which is the exposure described above; connections are all-or-nothing and often slow, since traffic hairpins through the corporate data centre before reaching a cloud application; and stolen credentials work from anywhere.

Zero trust network access replaces network-level access with per-application access, brokered by a service that evaluates identity, device posture and context on every request. Gartner's definition, from its 2023 market guide, describes products that create an identity and context-based logical access boundary around an application or set of applications, where the applications are hidden from discovery and access is restricted through a trust broker. Two properties distinguish it from a VPN: access is granted per application rather than per network, and the application is not discoverable by an unauthenticated party, because there is no listening service on the internet to find. The doctrine underneath is NIST SP 800-207, Zero Trust Architecture, published August 2020, with implementation guidance in SP 1800-35, finalised 10 June 2025.

Secure access service edge converges networking and security into one cloud-delivered service: SD-WAN plus secure web gateway, cloud access security broker, ZTNA and firewall as a service. Security service edge is the security half without the networking half, and it is the usual entry point.

Software-defined wide area networking replaces per-device rules and policies on physical routers with centralised software control of how traffic flows between sites, which allows policy to be written once and deployed everywhere, and allows application-aware routing rather than hub-and-spoke through the data centre.

What is settled: the direction. Dell'Oro reported SASE revenue passing three billion US dollars in the first quarter of 2026, up 21 per cent, with SSE at 22 per cent growth, and access router revenue falling 10 per cent.

What is not settled: the pace. The frequently repeated analyst prediction that ZTNA would replace VPN for most new remote access deployments by 2025 has not been borne out. Remote access VPN appliances were still being exploited at scale through 2025 and 2026 precisely because they are still deployed at scale. It is fair to say the direction is agreed and the timetable is not.

One more protocol worth knowing, because students will meet it. WireGuard was merged into the mainline Linux kernel at version 5.6 in 2020 and has builds for the major operating systems. Its design decision is to have no cipher suite negotiation at all: Curve25519, ChaCha20-Poly1305, BLAKE2s and a fixed construction, take it or leave it. That eliminates downgrade attacks and misconfiguration by eliminating configuration, which is a genuine advance over the negotiation-heavy IPsec and OpenVPN. The costs are the mirror image: no cryptographic agility, so no in-protocol path to post-quantum key exchange the way IKEv2 has through RFC 9370, and identity handled by static public keys, which pushes key distribution and user lifecycle management somewhere else. WireGuard is not an IETF standard and has no RFC. Its practical position in 2026 is as the data plane underneath commercial products, Cloudflare WARP and Tailscale being the obvious examples, rather than as a standalone enterprise remote access protocol. It is worth noting that Fortinet's replacement for SSL-VPN is IPsec on port 443, not WireGuard, which is a useful check on the idea that WireGuard is displacing IPsec in the enterprise.

The unit is written in the abstract, as accredited units have to be. Working in Australia, the network security infrastructure you build sits inside a specific set of expectations, and knowing them is part of doing the job.

The threat picture

ASD released its Annual Cyber Threat Report 2024-25 on 14 October 2025, the sixth edition, covering the 2024-25 financial year. The figures worth carrying:

ASD responded to over 1,200 cyber security incidents, an increase of 11 per cent, and issued more than 1,700 notifications to entities about potentially malicious activity, an increase of 83 per cent. ReportCyber received over 84,700 cybercrime reports, roughly one every six minutes, down 3 per cent. The Cyber Security Hotline took over 42,500 calls, about 116 a day, up 16 per cent. ASD blocked 334 million malicious domains.

The average self-reported cost of cybercrime rose across every segment: 33,000 dollars for individuals, up 8 per cent; 56,600 dollars for small business, up 14 per cent; 97,200 dollars for medium business, up 55 per cent; and 202,700 dollars for large business, up 219 per cent.

For critical infrastructure, the most common incident type was a compromised asset, network or infrastructure at 55 per cent, followed by denial of service at 23 per cent and compromised accounts or credentials at 19 per cent. Denial of service incidents exceeded 200, an increase of about 280 per cent. Ransomware accounted for 11 per cent of reported cybercrime, consistent with the previous year.

Read the top line of that against this unit: the single most common incident category is compromise of the network infrastructure itself. That is what VU23218 is about.

The Essential Eight, and what is happening to it

The Essential Eight is ASD's prioritised set of mitigation strategies, and the Essential Eight Maturity Model defines four maturity levels, zero through three, against which an organisation measures itself. Four of the eight bear directly on network infrastructure: multi-factor authentication, restricting administrative privileges, patching operating systems, and patching applications, which for these purposes includes the firmware on network appliances.

Two things to state accurately as at September 2026.

The model has not been revised since November 2023, and the companion frequently asked questions document is dated October 2024. There has been no 2025 or 2026 revision. Anyone citing a newer version is mistaken.

ASD has, however, flagged replacing it. A broader "Essentials series" grounded in the Information Security Manual, opening with a chapter titled "Essentials for enterprise IT", went to public consultation through the ASD Cyber Security Partnership Program portal from 15 June 2026, closing 12 July 2026, with later chapters expected on operational technology and cloud and agentic AI raised as a candidate. ASD has described an indicative transition of keeping both documents live, beginning to deprecate the Essential Eight, and retiring it in about twenty-four months. No retirement date has been published, and until one is, the Essential Eight Maturity Model remains current and every regulatory, contractual and insurance obligation that references it is unchanged.

What is driving the review is worth knowing, because it is a comment on implementation rather than on the model. Only 22 per cent of Commonwealth entities reached Maturity Level Two or higher in 2025, up from 15 per cent in 2024, and 59 per cent said legacy technology impeded implementation.

Gateways, edge devices and the ISM

The Information Security Manual is the control-level document, reissued on a rolling cycle; the current release as at September 2026 is June 2026, which expanded the cyber security principles from 34 to 49. Control numbers and wording change between editions, so quote from the edition you actually read and say which one.

ASD's gateway security guidance package was updated on 24 July 2025, timed with the Department of Home Affairs' new Gateway Security Standard. The changes matter for anyone building network security infrastructure in or for the Commonwealth: the old Gateway Security Policy is replaced by a mandatory Gateway Security Standard; the guidance explicitly accommodates cloud-based gateway services including SASE and SSE rather than assuming an on-premises firewall; agencies must embed cyber threat intelligence into gateway operations; monitoring with adequate gateway logging and telemetry is emphasised; and it states that outsourcing a service does not outsource the risk. The Standard supersedes the Gateway Policy developed by the Digital Transformation Agency under the Hardening Government IT program, and it retires the requirement to follow the lead gateway agency model.

On edge devices, the February 2025 international package is the reference set: ASD's mitigation strategies for edge devices in executive and practitioner versions, the Canadian-led security considerations for edge devices, and guidance for manufacturers on digital forensics and protective monitoring specifications for network devices. That last one is the interesting one for a technician, because it says what a defensible device should provide: logging that survives compromise, a documented forensic acquisition process, and a way to verify integrity. Most of the devices in the incident list above provided none of those.

Zero trust in Australian government policy

Zero trust is now policy rather than aspiration, and it is framed as culture and strategy rather than as a prescriptive architecture. Home Affairs released Guiding Principles to Embed a Zero Trust Culture in November 2024, with five principles: manage cyber risk at the enterprise level; understand accountabilities at all levels; know your most critical and sensitive technology assets; maintain resilience through a comprehensive strategy and uplift plans; and go beyond incident planning.

The Protective Security Policy Framework Release 2025, published 24 July 2025, introduced a requirement for entities to develop and maintain a cyber security strategy and uplift plan aligned to both the Information Security Manual and those zero trust principles. Release 2026, effective 1 July 2026, added application of the Commonwealth Technology Standard for systems up to SECRET, a post-quantum cryptography transition planning requirement, and gateway and hosting requirements aligned to the updated standards.

Critical infrastructure obligations

Two instruments bear on network security infrastructure directly.

Under the Security of Critical Infrastructure Act, the Critical Infrastructure Risk Management Program rules commenced 17 February 2023 with the grace period ending 18 August 2024. A CIRMP must address four hazard vectors, one of which is cyber and information security, and for that vector the entity adopts a recognised framework from Schedule 1: Essential Eight Maturity Level One, ISO/IEC 27001, the NIST Cyber Security Framework, the Australian Energy Sector Cyber Security Framework, or a sector equivalent. Worth flagging for this unit: the Essential Eight alone does not cover the full CIRMP scope, because it says nothing about incident detection and response, network segmentation or security monitoring. Three instruments commencing 4 April 2025 extended the regime to data storage systems holding business-critical data connected to a primary asset, and brought telecommunications carriers and qualifying carriage service providers under it.

Under the Cyber Security Act 2024, mandatory ransomware payment reporting commenced 30 May 2025. An entity carrying on business in Australia with annual turnover above three million dollars, or a responsible entity for a critical infrastructure asset regardless of turnover, must report within 72 hours of making a ransomware or extortion payment, or of becoming aware one was made on its behalf. There is no minimum payment threshold. Reports go to the ACSC through an online portal, and the civil penalty for failing to report is 60 penalty units.

Neither of these makes you configure a firewall differently. Both change what happens after the firewall fails, which is a large part of why the reporting and logging requirements in the sections above are not administrative overhead.

The unit scope, elements, performance criteria, performance and knowledge evidence, foundation skills and assessment structure are transcribed from the VU23218 Assessor Guide v4.4 (September 2024) held in the unit folder in the vault; the nominal hours, elective placement, delivery notes and assessment conditions are from the CDU TAFE course document for 22603VIC Certificate IV in Cyber Security (V001), also in the vault. The configuration walkthroughs for AAA, the ASA, the GRE tunnel and the site-to-site IPsec VPN follow the labs in that assessor guide, with commentary added.

Cisco platform facts come from Cisco's own end-of-life notices for the ASA 5500-X series, the Secure Firewall ASA compatibility matrix (ASA 9.24(1), 24 March 2026), the Secure Firewall 1200 series datasheet (updated 9 July 2025), Cisco's next generation firewall definition page (10 August 2026), the technote on TLS decryption performance for Secure Firewall Threat Defense (19 August 2026), the IOS XE 17.x zone-based policy firewall configuration guide (chapter updated January 2021), and the Cisco Secure Firewall documentation on defending against Encrypted Client Hello (last modified 24 August 2026). The ASA compromise material draws on Cisco Talos on ArcaneDoor (24 April 2024, updated 25 September 2025), Cisco's event response page for continued attacks against Cisco firewalls (first published 25 September 2025, updated 24 April 2026), the United Kingdom NCSC malware analysis of RayInitiator and LINE VIPER (25 September 2025), CISA Emergency Directive ED 25-03 and its supplemental direction (both 25 September 2025), CISA's FIRESTARTER malware analysis report AR26-113A (April 2026), and the ACSC alerts of 26 September 2025 and 24 April 2026.

Australian government sources are the ASD Annual Cyber Threat Report 2024-25 (14 October 2025), the Essential Eight Maturity Model (November 2023) and its FAQ (October 2024), the Information Security Manual (June 2026 release, with the cryptography guidelines of December 2024 and June 2025 for the post-quantum controls), ASD's Planning for post-quantum cryptography (first published July 2022, revised September 2025), the gateway security guidance package (updated 24 July 2025) and gateway technology guides (29 July 2022), the February 2025 edge device package including ASD's mitigation strategies in executive and practitioner versions, the joint fact sheet on reducing the attack surface for end-of-support edge devices (5 February 2026), the ACSC advisory on ongoing active exploitation of SonicWall SSL VPNs in Australia (10 September 2025), the ACSC alerts on Fortinet credential exposure (18 and 22 June 2026), the Home Affairs consultation papers on Guiding Principles to Embed a Zero Trust Culture (November 2024) and the Australian Government Gateway Security Standard (February 2025), and the ACMA record on 6 GHz spectrum: the March 2022 outcomes paper on the lower band, the December 2024 outcomes paper on the upper band, the September 2025 outcomes paper remaking the LIPD class licence, and the automated frequency coordination discussion paper of November 2025.

Standards and specifications are cited from their published documents: FIPS 203, 204 and 205 (NIST, 13 August 2024) and the HQC selection announcement (11 March 2025); NIST SP 800-207 (August 2020) and SP 1800-35 (10 June 2025); the draft SP 800-131A Rev. 3 (21 October 2024) and draft IR 8547 (November 2024), both still initial public drafts; NIST AI 100-2e2025 on adversarial machine learning (20 March 2025); RFC 6151 on MD5 (March 2011), RFC 7465 on RC4 (February 2015), RFC 8221 and RFC 8247 on IPsec algorithms (both 2017), RFC 8446 on TLS 1.3 (August 2018), RFC 9370 on multiple key exchanges in IKEv2 (May 2023), RFC 9395 deprecating IKEv1 (April 2023), RFC 9849 on Encrypted Client Hello (March 2026), RFC 6614 on RadSec (May 2012), RFC 9887 on TACACS+ over TLS 1.3 (9 December 2025), and RFC 7011 on IPFIX (September 2013); and the IETF drafts draft-ietf-radext-radiusdtls-bis (version 17, 6 July 2026) and draft-ietf-radext-deprecating-radius (version 10, 3 July 2026), neither yet published as an RFC.

Wireless material draws on the Wi-Fi Alliance announcements for WPA3 (25 June 2018), Wi-Fi CERTIFIED 6 (16 September 2019), Wi-Fi CERTIFIED 6E (7 January 2021) and Wi-Fi CERTIFIED 7 (8 January 2024), the WPA3 technology overview (January 2021), the IEEE record for 802.11be-2024 (approved 26 September 2024, published 22 July 2025), Mathy Vanhoef and Eyal Ronen's Dragonblood work (April 2019, with the August 2019 follow-up), and the reporting of the PMKID attack (August 2018).

Research and vendor telemetry cited by name: Durumeric and colleagues, "The Security Impact of HTTPS Interception" (NDSS 2017); the BlastRADIUS disclosure and the paper "RADIUS/UDP Considered Harmful" (9 July 2024, USENIX Security 2024); Marlinspike and Hulton on MSCHAPv2 (2012); James Kettle, "HTTP/1.1 must die" (PortSwigger, 6 August 2025); ProjectDiscovery on abusing reverse proxies for internal access (17 January 2022); Google Threat Intelligence Group on threat actor use of AI tools (5 November 2025 and 12 February 2026) and on residential proxy networks (2 July 2026); Anthropic's threat intelligence reports (27 August 2025 and 13 November 2025); Zscaler ThreatLabz on encrypted attacks (5 December 2024); Cloudflare Radar's 2025 year in review (15 December 2025) and post-quantum support documentation (updated 24 June 2026); Google's HTTPS by default announcement (28 October 2025); the CrowdStrike root cause analysis (6 August 2024) and Microsoft's Windows Resiliency Initiative announcements (November 2024 and 26 June 2025); Dell'Oro Group on SASE revenue (16 June 2026); the 2025 SANS detection and response survey; and the Australian Computer Society's Digital Pulse 2025 and ISC2's 2025 workforce work for the Australian workforce figures. Tool version and release dates are from the projects themselves: Snort, Suricata, Zeek, Wireshark, tcpdump, ntopng, Aircrack-ng, Kismet, hcxdumptool and wifite2.

Where figures for the same phenomenon differ between sources, both are given in the text rather than reconciled: the encrypted share of traffic depends on whether page loads or all traffic is being measured, and the reported scale of the June 2026 Fortinet credential campaign differs between the counts of credentials and of devices.