VU23214 Configure and secure networked end points

An endpoint is any device that a person uses to reach a network and its data: a desktop, a laptop, a phone, a tablet, a server, a point of sale terminal, a printer, a smart camera. If it has an address on the network and a processor running software, it is an endpoint, and it is a place an attacker can try to stand.

For years the security model was a hard shell around a soft centre. The organisation drew a perimeter, put a firewall on it, and trusted everything inside. That model quietly stopped matching reality. Staff work from home and from cafes; data sits in cloud services reached straight from a laptop; a contractor's tablet joins the same Wi-Fi as the finance team. The perimeter did not disappear, but it stopped being the line that matters. The device in the user's hands became the line that matters, and that is why a whole unit is given over to configuring and securing it.

There is a blunt way to see the stakes. Most successful intrusions do not begin with an attacker defeating a firewall; they begin on an endpoint, through a user opening an attachment, reusing a password, or running an unpatched application with a known hole in it. Harden the endpoint and you remove the ground most attacks are built on.

This unit teaches the hands-on craft of that hardening on a personal computer: installing the operating system cleanly, giving each user only the access they need, turning on the protections the system already ships with, keeping software patched, and understanding the device well enough to reason about its weaknesses. The notes below take that craft and set it beside the way endpoints are actually secured in workplaces in 2026, which has shifted a long way past a single well configured PC.

The endpoint attack surface

The attack surface of an endpoint is the sum of the ways in. It is worth naming the main ones early, because every later section maps back to one of them:

• The accounts on the device, and how much each one can do.
• The software installed, and whether it is patched.
• The services and ports the device is listening on.
• The data at rest on its disk, and whether it is encrypted.
• The physical device itself, and whether someone can walk off with it or boot it from a USB stick.
• The user, who can be tricked into running something.

Good endpoint security is not one control; it is a set of layers, each closing off part of that surface, so that a failure in one does not open the whole device. That idea, defence in depth, runs through this unit.

The unit starts at the hardware, and there is a security reason to start there rather than treat it as background. Modern endpoint protection reaches down into the hardware, and a technician who does not know what a TPM or Secure Boot is cannot reason about why a modern Windows install refuses to run on an old machine.

A personal computer is the familiar set of components: a motherboard carrying the CPU and memory, storage (a solid state drive or hard disk), a power supply, and peripherals such as the keyboard, mouse, display, and increasingly a camera and microphone that are themselves worth securing. For this unit you need to be comfortable identifying these parts and understanding preventative maintenance on them, because a device that fails is a device whose data may be lost, and availability is part of security.

The hardware roots of trust

Update, current as at August 2026. Two pieces of hardware have become central to endpoint security and now appear in the entry requirements for current operating systems.

The Trusted Platform Module (TPM) is a small chip, or a firmware equivalent, that stores cryptographic keys in hardware where software (including malware) cannot easily read them. It is what lets a disk encryption key be bound to a specific machine, and what lets a system prove it booted a known, untampered set of software. Windows 11 requires TPM 2.0, which is the single most common reason an older but otherwise capable PC cannot be upgraded to it.

Secure Boot is a UEFI firmware feature that checks the digital signature of the boot loader and operating system before handing control to them, so that a rootkit cannot quietly insert itself before the OS even starts. Together, a TPM and Secure Boot give the machine a hardware root of trust: a foundation the software layers above can rely on.

The teaching point for a technician is that endpoint security in 2026 is not only an operating system setting. It begins in firmware, and the questions "is Secure Boot on?" and "is there a TPM, and is it enabled in the UEFI?" belong at the very start of hardening a device.

The unit has you install operating systems inside virtual machines rather than on bare hardware, and that choice is doing more work than it first appears.

A virtual machine is a complete computer emulated in software: it has its own virtual CPU, memory, disk and network adapter, and it runs a full operating system that believes it is on real hardware. A hypervisor is the software that creates and runs those machines. VirtualBox, used in this unit, is a type 2 hypervisor: it runs as an application on top of a host operating system. Type 1 hypervisors such as Microsoft Hyper-V, VMware ESXi and Proxmox run directly on the hardware and are what data centres use.

Why does a security technician care? Three reasons.

• Safe practice. A virtual machine is disposable. You can install a suspect file, watch what it does, and throw the machine away, all without risking the host. Snapshots let you save a clean state and roll back to it in seconds. Much of the practical craft of this course is safer, and cheaper, because it happens in VMs.
• Isolation. Running a risky task inside a VM keeps it away from your real data. This is the same instinct that leads analysts to detonate malware only in isolated sandboxes.
• It is how workloads actually run. Servers, and most of the cloud, are virtualised. Understanding VMs is the on-ramp to understanding the environments you will secure.

The VirtualBox networking you will meet

When you install a machine in VirtualBox and check its address, you will very often see 10.0.2.15. That is not a coincidence or a fault; it is VirtualBox's default. The virtual machine is set to obtain an address by DHCP, and VirtualBox places it behind Network Address Translation (NAT), handing out 10.0.2.15 from its built-in DHCP server and translating the VM's traffic out through the host. It is worth understanding the NAT and DHCP behaviour here, because it is the same mechanism, described in VU23213, that sits behind almost every home and small office network.

If you need the VM to be reachable from the host or other machines, you change the adapter from NAT to bridged or host-only networking. Knowing which mode to pick, and why, is part of configuring an endpoint for network connectivity.

Guest Additions and snapshots

After installing the guest operating system you install the VirtualBox Guest Additions, a set of drivers and tools that let the window resize properly, share a clipboard, and generally behave. The habit worth forming is to take a snapshot immediately after a clean install and Guest Additions, so you always have a known-good state to return to.

Update, current as at August 2026. Virtualisation is not only a lab tool; it has become a security control on the endpoint itself. Windows uses virtualisation-based security (VBS), and specifically hypervisor-protected code integrity (HVCI), to run parts of the operating system inside a small hypervisor-isolated space so that even malware with high privileges cannot tamper with them. The same idea that makes a VM a safe sandbox is now used inside the OS to wall off its most sensitive components.

This is the core of the unit: a clean Windows install, then the deliberate work of making it secure. The assessor tasks walk through Windows 7 and Windows 10 in VirtualBox; the security thinking below is what matters and it carries to any version.

Before the detail, an honest currency note, because it sits right on top of the unit's own tasks.

Update, current as at August 2026. The unit's practical tasks install Windows 7 and Windows 10. Both are now out of support. Windows 7 reached end of support in January 2020. Windows 10 reached end of support on 14 October 2025; after that date Microsoft no longer provides free security updates, feature updates or technical support for it (see Windows 10 support has ended on October 14, 2025 and the Microsoft Lifecycle announcement, Microsoft, read August 2026). They are still perfectly good machines to practise installation and configuration on inside a throwaway VM, which is exactly why the course uses them; but you would not run an unsupported operating system as a real endpoint, because an unpatched OS is the very thing this unit teaches you to avoid. In a workplace in 2026 the endpoint you harden is Windows 11, or a supported Windows 10 covered by paid Extended Security Updates during migration.

User accounts, and the principle that governs them

The first security decision on any endpoint is who can do what. Windows offers two broad account types:

• A standard user account can run applications and change settings that affect only that user. It cannot install software system-wide or change settings that affect everyone.
• An administrator account has full control of the machine.

An administrator account is created when Windows is installed. The mistake, and it is one of the most common in the field, is to then use that administrator account for everyday work. The principle to hold onto is least privilege: give each account only the access it needs to do its job, and no more. Day to day work happens in a standard account; administrator rights are used only when a task genuinely needs them, by choosing "Run as administrator" for that one action. This single habit blunts a large share of malware, because code launched by a standard user cannot quietly install itself for the whole machine.

Windows also gives you the Local Users and Groups tool to manage this efficiently. Rather than set rights on each person one at a time, you assign users to groups, and the group carries the rights. Windows ships with default groups that make the common cases easy:

• Administrators, who have full control of the computer and access to all folders.
• Users, who can run applications and use printers, with a profile that persists on the machine.
• Guests, who get a temporary profile created at logon and deleted at logoff. The Guest account is disabled by default, and on a secured endpoint it stays that way.

This grouping is not a Windows quirk; it is the everyday form of role based access control, which the next section examines properly.

The security features to turn on

Once the accounts are right, a handful of built-in protections do most of the base-level work the unit asks for:

• Antimalware. Windows includes Microsoft Defender Antivirus, on and updating by default. The technician's job is to make sure it stays active and current, and to enforce a policy about what software users may install, because a user tricked into running malware is still the most common way an endpoint is lost.
• The firewall. Windows Defender Firewall controls which network connections the machine will accept and make. Knowing how to check its status, and that it is on for the network the device is using, is part of base configuration.
• Updates and preventative maintenance. A preventative maintenance plan keeps the machine reliable and secure: scheduled operating system and application updates, antivirus updates, disk error checking, and backups. Of these, keeping Windows Update current is the one that matters most for security, because it closes the known holes attackers rely on.

Access control on files, and remote access

Access control on a Windows endpoint is applied at the file and folder level through NTFS permissions: right-click a file, choose Properties, then Security, and set which users and groups may read, write or execute it. This is where the access control theory becomes concrete.

Remote access is the other side of the coin: letting a legitimate user reach the machine or the corporate network from outside. The traditional answer is a virtual private network (VPN), which builds an encrypted tunnel across the public internet so that a remote user becomes, in effect, part of the private network. The user runs a VPN client, which encrypts traffic before it leaves the device, and a VPN gateway manages the tunnels at the other end.

Update, current as at August 2026. Two shifts are worth noting against the unit's VPN-centred picture. First, Remote Desktop Protocol (RDP) exposed directly to the internet has become one of the most common ways ransomware operators get in; if RDP is used, it belongs behind a VPN or a gateway, never open to the world. Second, many organisations have moved from the "VPN puts you inside the trusted network" model toward zero trust remote access, where each connection to each application is checked on its own, based on the user's identity and the device's health, rather than trusted because it came through the VPN. Zero trust is examined later in these notes.

Update, current as at August 2026. The base-level protections above are the floor, not the ceiling. A current Windows endpoint is hardened further with disk encryption (BitLocker), a security baseline applied centrally, application control, and multi-factor sign-in through Windows Hello. Those are covered in their own sections below, because they are where endpoint security has actually moved.

The unit's theory notes go beyond the Windows buttons into the models that sit underneath every access decision. This is worth knowing properly, because the same vocabulary appears in every operating system, every cloud console and every security exam.

Access control is what happens after a user's identity has been established: it decides which resources that identity may reach, and what it may do with them. It rests on three kinds of control working together:

• Physical access controls: the barriers that stop someone touching the hardware, such as locked rooms, cabinets and swipe cards. If an attacker can put hands on a device, many software controls can be bypassed, so physical control comes first.
• Logical access controls: the hardware and software mechanisms that manage access to systems and data, such as passwords, permissions and encryption.
• Administrative access controls: the policies and procedures, such as an acceptable use policy or a joiners-movers-leavers process, that govern how the other two are applied.

The three classic models

There are three models for deciding who may access what, and a technician should be able to tell them apart.

Discretionary access control (DAC) lets the owner of a resource decide who else may use it. The owner has discretion. This is the model behind ordinary file permissions in Windows and Linux: the person who owns a file grants access to others. It is flexible and familiar, and it is the least strict, because control is spread across many individual owners.

Role based access control (RBAC) assigns rights to roles, and assigns people to roles, rather than granting rights to individuals one by one. An "accountant" role carries exactly the access an accountant needs; move a person into that role and they inherit it. RBAC is how organisations put least privilege into practice at scale, and it is the everyday purpose of groups in Windows and Linux. It also has a well-known failure to watch for: role creep, where a person changes jobs, gains the new role's access, but keeps the old role's access as well, slowly accumulating rights they should no longer hold. Regular access reviews exist to catch exactly this.

Mandatory access control (MAC) is the strictest model. Access is set by the system according to security labels, and ordinary users cannot change it. Each resource carries a classification (for example high, medium, low) and a category (a "need to know" compartment), and a user can reach a resource only if both their clearance and their need to know match. MAC is used where control matters more than convenience, such as defence and government systems, and it demands heavy administration because every object and account must be labelled and kept current.

Identification, authentication, authorisation, accountability

Underneath the models sits a sequence every access decision follows. It is often abbreviated to the four A's, though it opens with identification:

• Identification: the subject claims an identity, for example by presenting a username.
• Authentication: the subject proves that claim. Proof comes in three classic factors: something you know (a password, passphrase or PIN); something you have (a smart card or security key); and something you are (a biometric such as a fingerprint or face). Multi-factor authentication (MFA) combines at least two different factors, so that a stolen password alone is not enough.
• Authorisation: the system checks what that proven identity is allowed to do, and enforces it.
• Accountability: the system records the action, so that it can be traced back to the person or process later. Logs are where accountability lives; without them, an investigation has nothing to work from.

flowchart LR
  A[Subject claims identity] --> B[Identification]
  B --> C[Authentication<br/>know / have / are]
  C --> D{Authorisation<br/>allowed?}
  D -- yes --> E[Access granted]
  D -- no --> F[Access denied]
  E --> G[Accountability<br/>action logged]
  F --> G

Categories of control, by what they do

The same notes classify controls by the job they perform, and it is a useful lens when you are asked to recommend a mix rather than a single fix. Preventative controls stop unwanted activity before it happens; deterrent controls discourage it; detective controls notice it once it is under way; corrective controls counteract it and restore a safe state; recovery controls bring resources and capabilities back after a violation; and compensating controls stand in when a preferred control is not possible. A well secured endpoint uses several categories at once: a firewall prevents, logging detects, backups recover.

Update, current as at August 2026. Authentication is the part of this picture that has moved fastest. Passwords alone are treated as insufficient for anything that matters, and MFA is now the baseline rather than an extra. More than that, the industry is moving toward passwordless sign-in using passkeys, based on the FIDO2 and WebAuthn standards, where a cryptographic key held on the device (often protected by the TPM and unlocked with a fingerprint or face) replaces the password entirely. Passkeys are described as phishing-resistant because there is no shared secret for an attacker to capture or replay. On a Windows endpoint this is what Windows Hello for Business provides.

The unit's base configuration does not dwell on encryption, but no honest account of securing an endpoint in 2026 can leave it out, because it answers a question the account controls cannot: what happens when the device is lost or stolen?

Account passwords protect a running system. They do nothing for a thief who removes the disk and reads it in another machine, or boots the laptop from a USB stick to sidestep the login. Full disk encryption closes that gap by encrypting the whole drive, so that without the key the data is unreadable ciphertext.

• On Windows, this is BitLocker. It encrypts the drive and, on a machine with a TPM, binds the key to that hardware so the disk will only unlock on that device after a trusted boot. See the BitLocker overview (Microsoft Learn, read August 2026).
• On Linux, the equivalent is LUKS (Linux Unified Key Setup), offered as a tick box during most installations.
• On macOS, it is FileVault.

Update, current as at August 2026. Encryption on the endpoint is shifting from something a technician switches on to something that is on by default. Recent Windows 11 installations enable device encryption automatically on capable hardware. The practical consequence, and the thing a technician must get right, is key recovery: an encrypted disk whose recovery key has been lost is as unreadable to its owner as to a thief. On managed devices the recovery keys are escrowed centrally, for example in Microsoft Entra ID through Intune, so a device can always be recovered.

Patching is the least glamorous control and one of the most effective. The unit's own notes put it plainly: too many attacks use unpatched systems as their way in. When a vulnerability is given a Common Vulnerabilities and Exposures (CVE) identifier and made public, attackers begin scanning for it within hours, so the window to patch is short.

Good patch management on endpoints means a few disciplined habits: subscribe to security advisories so you learn about fixes promptly; apply updates soon after release rather than deferring them; use tooling to deploy patches across many machines rather than one at a time; and remove software that the vendor no longer supports, because it will never be patched again.

Update, current as at August 2026. The Australian Signals Directorate puts concrete timeframes on this in the Essential Eight. Patches for security vulnerabilities in internet-facing services should be applied within two weeks, or within 48 hours if an exploit is already circulating; patches for office productivity software, browsers, email clients, PDF readers and security products within one month; and unsupported software should be removed. Regular vulnerability scanning is used to find what is missing. See Essential Eight explained (ASD's ACSC, read August 2026).

For managing this across an organisation, the tooling has consolidated. Where the unit's notes mention Microsoft Endpoint Configuration Manager and third-party tools such as ManageEngine Endpoint Central, the current centre of gravity for endpoints is cloud based, through Microsoft Intune (examined in its own section).

The updates themselves can be the attack

There is a subtler point the unit raises that has only grown in importance: the update mechanism is itself a target. If an attacker can interfere with how a device fetches and trusts updates, they can turn the security control into the delivery vehicle. The classic attacks on update systems include:

• Arbitrary installation, where the attacker serves a malicious file in place of the real update.
• Rollback attacks, where the attacker serves an older, vulnerable version and the client, unaware it is obsolete, installs it.
• Freeze attacks, where the attacker keeps replaying files the client has already seen, so it never learns a fix exists.
• Endless data attacks, where a download is answered with an unending stream to exhaust the client's disk or memory.

The defence is to establish trust in the source before trusting its files: updates are cryptographically signed, and the client verifies the signature, so a file that did not come from the genuine vendor is rejected. Frameworks such as The Update Framework are built specifically to keep clients safe even when parts of the update infrastructure are compromised.

Update, current as at August 2026. This stopped being theoretical. Supply chain compromises, where attackers subvert a trusted vendor's build or update pipeline to push malware to that vendor's customers, have become one of the most damaging attack patterns of the decade; the SolarWinds Orion compromise disclosed in December 2020 and the 3CX desktop app compromise in 2023 both reached victims through a signed, trusted update. The lesson for an endpoint technician is that "it came through the official updater" is a reason for confidence only as strong as the vendor's own security.

Australia has a national baseline for exactly this work, and much of it lands on the endpoint. The Australian Signals Directorate's Essential Eight is a prioritised set of eight mitigation strategies drawn from its Strategies to Mitigate Cyber Security Incidents. They split into controls that prevent malware running and controls that limit damage and aid recovery.

The eight strategies are:

1. application control,
2. patch applications,
3. configure Microsoft Office macro settings,
4. user application hardening,
5. restrict administrative privileges,
6. patch operating systems,
7. multi-factor authentication, and
8. regular backups.

Read that list as an endpoint hardening checklist, because that is largely what it is. Application control decides which programs may run. Patching applications and operating systems closes known holes. Macro settings and user application hardening shut down two favourite delivery routes, malicious Office macros and browser add-ons. Restricting administrative privileges is least privilege by another name. Multi-factor authentication protects the accounts. Regular backups are what let you recover when something still gets through.

To help organisations judge how thoroughly they have implemented each strategy, the Essential Eight defines four maturity levels, from Maturity Level Zero (weaknesses present) up to Maturity Level Three, with each level set against a more capable class of attacker. See the Essential Eight maturity model (ASD's ACSC, read August 2026).

Update, current as at August 2026. The maturity model is not frozen; the ASD revised it substantially, with a set of changes first published in November 2023, and it continues to be tuned. Treat the specific timeframes and requirements as the current position of a moving control rather than a fixed figure, and check the source for the version in force when you rely on it. The direction of travel has been to raise the bar, particularly on patching speed and on phishing-resistant multi-factor authentication.

Application control, the modern form of whitelisting

The unit's notes call the first strategy application whitelisting: allowing only approved programs to run. The term has since shifted to application control, but the idea is unchanged and it is one of the most effective single controls an endpoint can have, because it denies malware the ability to execute at all. On current Windows, this is delivered through Windows Defender Application Control (WDAC) and AppLocker. It is demanding to run well, because someone must maintain the list of approved software, which is exactly why it sits high in the maturity model.

The unit teaches that a technician keeps Microsoft Defender Antivirus active and updated. That is correct and necessary, and it is also where the largest gap between the syllabus and current practice sits, so it is worth closing carefully.

Traditional antivirus works mainly by signatures: it recognises known-bad files by comparing them to a list. That still catches a great deal, but it struggles with malware it has never seen, and with attacks that use no malware file at all, living off legitimate tools already on the machine.

Endpoint detection and response (EDR) was built for that gap. Rather than only matching known files, EDR continuously records what is happening on the endpoint (processes starting, network connections, files changing, scripts running) and looks for suspicious behaviour and patterns. When it finds something, it can respond: isolate the device from the network, kill a process, and give an analyst a timeline of exactly what happened. See What is EDR? (Microsoft Security, read August 2026).

Extended detection and response (XDR) widens the same idea beyond the single endpoint, correlating signals from endpoints, email, identity and cloud services so that an attack moving from a phished mailbox to a laptop to a cloud app is seen as one story rather than four disconnected alerts. Microsoft's endpoint offering here is Microsoft Defender for Endpoint; CrowdStrike Falcon and SentinelOne are other widely used platforms. Where an organisation lacks the staff to watch these tools around the clock, it buys managed detection and response (MDR), a security operations centre as a service.

The teaching point is not that antivirus is obsolete; Defender Antivirus is in fact the foundation that Defender for Endpoint builds on. It is that detection has moved from recognising bad files to recognising bad behaviour, and that a modern endpoint is expected to be able to respond, not only to block.

Everything above describes securing one machine. A real organisation has hundreds or thousands, including phones and tablets and staff-owned devices, and it cannot secure them by visiting each one. This is the job of endpoint management, and it is a large part of what an endpoint-focused technician now does.

Mobile device management (MDM), which has broadened into unified endpoint management, lets an administrator enrol devices and then push configuration, security settings, applications and updates to all of them from one console, and check that each device complies before it is allowed near company data. Microsoft's platform is Intune.

Two capabilities are worth naming because they connect directly to earlier sections:

• Security baselines. Rather than set hundreds of hardening options by hand on each machine, Intune applies a vendor-recommended baseline, a pre-built set of secure settings, across every enrolled device at once. See Intune security baselines (Microsoft Learn, read August 2026).
• Compliance and conditional access. Intune continuously checks whether a device meets policy (encrypted, patched, EDR healthy, screen lock on) and reports that state. Conditional access then uses it: a device that is non-compliant, or unknown, can be blocked from reaching email or company data until it is fixed. This is the machinery that makes zero trust real on endpoints.

flowchart TD
  U[User signs in on a device] --> C{Device compliant?}
  C -- "encrypted, patched, EDR healthy" --> G[Access to company data granted]
  C -- "non-compliant or unknown" --> B[Access blocked or limited]
  B --> R[Remediate: encrypt, update, enrol]
  R --> C

Update, current as at August 2026. For a small business or a sole technician, the same ideas are available without heavy infrastructure through cloud services, and the ASD publishes plain-language guidance aimed at exactly that audience. The scale changes; the controls (encrypt, patch, least privilege, MFA, back up, monitor) do not.

An endpoint rarely works alone; it is usually a client talking to servers, and that relationship has its own security issues the unit asks you to understand.

A server is a computer running software that provides a service; a client is the program that consumes it. They meet at ports, the numbered endpoints of a network service. A technician should know the common ones on sight, because an open port is a service exposed, and a service exposed is attack surface: 21 for FTP, 22 for SSH, 23 for Telnet, 25 for SMTP, 53 for DNS, 80 for HTTP, 143 for IMAP, 161 and 162 for SNMP, and 443 for HTTPS. Note that several of these have secure and insecure versions; a hardened endpoint uses SSH rather than Telnet, and HTTPS rather than HTTP, because the insecure forms send data, including credentials, in the clear.

Clients face threats from malicious data and code, such as viruses, worms and Trojans. Servers face eavesdropping, denial of service, packet modification and man-in-the-middle attacks. There is also a family of client-side web attacks, cross-site scripting and its relatives, catalogued by the Open Web Application Security Project (OWASP); this unit only introduces them, because VU23222 Expose website security vulnerabilities examines them properly.

Peer-to-peer, and why it is a workplace risk

Peer-to-peer (P2P) networks let devices share files directly with each other rather than through a central server, and BitTorrent is the best-known example. The technology is legitimate and efficient; it is used to distribute large legitimate files such as Linux installation images and game updates. On a workplace endpoint, though, P2P file sharing carries real risk: it is a common route for pirated content carrying hidden malware, the IP addresses and file lists of peers are publicly visible on trackers, and the software can leave a machine reachable in ways the user did not intend. The sensible workplace posture is to scan everything downloaded, keep security software current, shut the software down after use, and, in most organisations, to disallow P2P file sharing on work devices altogether.

The unit gives Linux real weight, and rightly, because Linux is everywhere an endpoint can be: it runs most web servers, sits underneath Android phones, and drives a great deal of networking equipment and IoT. It is, as the unit's notes put it, the other operating system, and a cyber security technician who can only drive Windows is working with one hand.

How Linux is put together

Linux is built from a kernel and a shell. The kernel is the core: it sits between the hardware and the running programs, allocating processor time and memory and managing devices. The shell is the outer layer the user interacts with; it takes commands and passes requests to the kernel. Linux is famously comfortable at the command line, though graphical desktops exist.

Linux comes in distributions, which package the kernel with a set of tools and a management style. They fall into two broad camps, and the distinction matters for security:

• Rolling distributions such as Kali, Arch and openSUSE Tumbleweed update continuously to the latest software. They are current but move fast and need frequent updating.
• Fixed release distributions such as Debian, Ubuntu and Red Hat hold a stable set of versions and update on a defined release cycle. Their steadiness is why they dominate on servers.

Kali deserves a note, because you will meet it across this course: it is a rolling distribution built specifically for security testing, shipping with a large toolkit pre-installed.

The commands that carry the security weight

A few command-line habits do most of the base-level Linux security work the unit asks for.

• Getting help. The man command shows the manual page for any command, and whatis gives a one-line description. Knowing how to read the manual is more valuable than memorising flags.
• Users and permissions. Linux permissions are set with chmod, adding or removing read, write and execute rights for a file's owner, group and others; for example, chmod +x filename makes a file executable. This is discretionary access control in its most direct form. Administrative actions are run with sudo rather than by logging in as root, which is least privilege applied to Linux.
• Package management and updates. On Debian and Ubuntu systems, apt-get update refreshes the list of available packages, apt-get upgrade installs the newest versions of what is already present (this is how you get security updates), and apt-get install adds new software from trusted repositories. That repository model, software fetched from a signed, curated source, is itself a security feature, and it connects straight back to the earlier point about trusting the update source.

Update, current as at August 2026. Two small currency notes for anyone taking the unit's commands into a modern system. The unit uses ifconfig to view and set network addresses; on current Linux the net-tools package it belongs to is deprecated, and the ip command (for example ip address) is the maintained replacement, though ifconfig still appears widely and is worth recognising. And the everyday apt-get is now usually written simply as apt. On the update side, unattended-upgrades can apply security patches automatically, bringing the Essential Eight's patching discipline to Linux endpoints without manual effort.

Hardening and security tools on Linux

Linux is open source, which means a large and genuinely useful set of security tools, and the harder task, as the unit's notes observe, is judging which of them are trustworthy and well maintained rather than merely available. Base-level hardening on a Linux endpoint leans on a few well-established pieces: a host firewall (ufw is the approachable front end to it); mandatory access control through SELinux or AppArmor, which confine what a program can do even if it is compromised; and tools such as fail2ban that watch logs and block repeated failed logins. For everyday user-facing security the unit points to cross-platform tools such as the KeePassXC password manager and the Signal messenger, both sound recommendations that remain current.

Configuring a personal computer for network connectivity is one of the unit's required skills, and it overlaps with the wired and wireless LAN work in VU23213. The security of that connection is the part worth drawing out here.

On a wired LAN the endpoint is connected through a switch and reaches the wider world through a router; the assessor task builds exactly this topology. On wireless, the security of the link rests on the encryption the Wi-Fi uses.

Update, current as at August 2026. Wi-Fi security has a clear current answer: WPA3 is the current standard and should be used where the equipment supports it, with WPA2 as the fallback on older gear. The older WEP and WPA are broken and must not be used. For endpoints, two connection habits also matter: treat public Wi-Fi as untrusted and use a VPN or rely on the fact that almost all traffic is now HTTPS; and, on any network carrying IoT or guest devices, separate them from the devices holding company data using a separate network or VLAN, so that a compromised smart television cannot reach a finance laptop. That segmentation idea leads directly into the last topic.

The unit asks for an overview of IoT devices, and the security angle is the reason they belong in a cyber security course rather than a general IT one.

The Internet of Things is the enormous and growing population of everyday objects that now carry a processor and a network connection: cameras, doorbells, thermostats, televisions, medical devices, industrial sensors, building controls. Each one is an endpoint, but a peculiarly awkward one to secure, for reasons that are worth stating because they explain why IoT is so often the weak link:

• Many ship with default usernames and passwords that owners never change, so they are trivially taken over at scale.
• Many are rarely or never patched, because the vendor stops supporting them or the owner never updates them, leaving known vulnerabilities open for years.
• Many run stripped-down software with weak or no encryption, and cannot run the endpoint protections a PC can.
• They are often invisible to IT; nobody thinks of the meeting-room television as a computer on the network.

The consequences are not hypothetical. The Mirai botnet in 2016 spread by simply trying default passwords against internet-connected cameras and home routers, built an army of hundreds of thousands of them, and used it to launch some of the largest denial of service attacks seen to that point. It remains the standing example of what unsecured IoT enables.

The defences for a technician are practical: change default credentials immediately; keep firmware updated where the vendor provides it, and retire devices that are no longer supported; disable features and services a device does not need; and, above all, segment IoT onto its own network away from important systems, so that a weak device cannot become a path to a valuable one.

Update, current as at August 2026. Policy has started to catch up with the technology. Australia's approach began with a voluntary Code of Practice for IoT manufacturers built around secure-by-design principles, foremost among them no universal default passwords; see IoT secure-by-design guidance for manufacturers and the ACSC's advice on securing Internet of Things devices (ASD's ACSC, read August 2026). The direction internationally, and in Australian reform proposals, is toward mandatory minimum security standards for smart devices, moving the burden from the owner changing settings to the manufacturer shipping the device secure in the first place.

It helps to see the whole picture at once. Securing an endpoint is not a single control but a stack of them, each covering a different part of the attack surface named at the start, so that no one failure exposes the device. Read from the hardware up:

flowchart TD
  H[Hardware root of trust<br/>TPM 2.0, Secure Boot] --> D[Data at rest<br/>full disk encryption]
  D --> O[Operating system<br/>supported, patched, hardened baseline]
  O --> A[Accounts<br/>least privilege, MFA / passkeys]
  A --> C[Application control<br/>only approved software runs]
  C --> E[Detection and response<br/>EDR / XDR]
  E --> M[Central management<br/>Intune: compliance, conditional access]
  M --> P[People<br/>awareness, acceptable use]

Set against the unit as written, the mapping is clear. The unit teaches the clean install, the accounts and privileges, the built-in protections, the patching and the base Linux and networking skills; those are the lower and middle layers of that stack, and they are the right place to start. Current practice adds the hardware root of trust beneath them and the detection, response and central management above them, and it assumes the whole stack is verified continuously rather than trusted once. An entry level trainee who can build the middle of that stack by hand, and can explain why the layers above and below exist, is doing the job this unit is for.

The unit's scope, structure and required knowledge are from the CDU TAFE VU23214 Assessor Guide (v4.4, November 2022) and the 22603VIC Certificate IV in Cyber Security accredited course document held in the vault, and the Victoria University unit page for VU23214 Configure and secure networked end points (vu.edu.au, no publication date shown, read August 2026); the national training record is training.gov.au VU23214. The unit's own topic notes on access control models, client and server security, peer-to-peer risk, software-upgrade risk and Linux (CDU TAFE, July 2023) provided the theory, reshaped and brought current here. Current-practice material draws on the Australian Signals Directorate's Australian Cyber Security Centre: Essential Eight explained, the Essential Eight maturity model, securing Internet of Things devices and the IoT secure-by-design guidance for manufacturers; and on Microsoft documentation for the Windows 10 end of support announcement and support page, the BitLocker overview, Intune security baselines and What is EDR?. All web sources were read in August 2026; where a page shows no publication date, that is noted at the point of citation.