Update hardening document based on feedback

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/guides/hardening.md

@@ -47,29 +47,37 @@ An adventurous user will not be stopped by "warranty void if broken" stickers
 and security or obscure headed screws. Depending on your threat models, it may
 be necessary to:
 
-- Ensure the hardware provides functionality to securely store cryptographic.
-  Many ARM SoCs will have such functionality built in, on x86 systems design in
-  a TPM chip.
+- Ensure the hardware provides functionality to securely store cryptographic
+  keys.  Many ARM SoCs will have such functionality built in (such as the
+  ability to use Arm
+  [TrustZone](https://developer.arm.com/ip-products/security-ip/trustzone)), on
+  x86 systems design in a
+  [TPM](https://en.wikipedia.org/wiki/Trusted_Platform_Module) chip.
 - Don't expose unneeded ports and buses as these might be usable as part of a
   compromise.
 - Don't route out a serial port for use as a debug interface on the finally
   release of the PCB. As this is likely to be very useful for an attacker
   trying to break into the device.
-- Ball grid array (BGA) Flash parts make it harder to short pins to
-  block/corrupt reading of the flash. This is a common technique for forcing a
-  device into a debug mode.
+- [Ball grid array](https://en.wikipedia.org/wiki/Ball_grid_array) (BGA) Flash
+  parts make it harder to short pins to block/corrupt reading of the flash.
+  This is a common technique for forcing a device into a debug mode.
 - Ensure the bootstrapping configuration of the SoC is provided and stops
   fallback to boot options such as network/USB boot if supported by the
   hardware. This can enable the user to provide alternative boot firmware.
-- Ensure any One Time Programmable (OTP) Fuses that may be available to limit
-  boot options and debugging interfaces (such as JTAG) are blown prior to
-  shipping device.
+- Ensure any
+  [One Time Programmable (OTP) Fuses](https://en.wikipedia.org/wiki/Efuse) that
+  may be available to limit boot options and debugging interfaces (such as JTAG)
+  are blown prior to shipping device.
+- If using a processor with [Microcode](https://en.wikipedia.org/wiki/Microcode),
+  as is typically the case with x86 processors, ensure this is kept up-to-date.
 
 # Boot Firmware
 
-The boot firmware covers the software that runs after boot and is responsible
-for initial hardware configuration and loading the Linux kernel. This is
-typically UEFI on x86-based systems and U-Boot on ARM and other architectures.
+The boot firmware covers the software that
+[runs after boot]({{< ref "secure-boot.md#boot%20sequence" >}}) and is
+responsible for initial hardware configuration and loading the Linux kernel.
+This is typically UEFI on x86-based systems and U-Boot on ARM and other
+architectures.
 
 The boot process needs to be guarded against tampering. The ability for a user
 to compromise the boot process would potentially allow them to modify it and
@@ -100,8 +108,8 @@ reduces the commands that can be leveraged to alter the boot process.
 
 U-Boot can store environment variables in a number of places to allow these to
 be changed and saved for later boots. This ability should be disabled with
-default environment variables provided by the U-Boot binary to avoid
-alterations by attackers.
+[default environment variables provided by the U-Boot binary](https://github.com/u-boot/u-boot/blob/master/env/Kconfig#L15)
+to avoid alterations by attackers.
 
 Likewise, U-Boot can utilize boot scripts or configuration stored on the root
 file system to determine how to boot the system, with scanning being performed
@@ -160,13 +168,14 @@ be tested and characterized after any changes are made to ensure that the
 device still performs as expected.
 {{% /notice %}}
 
-# Minimize Software
+# Minimize Installed Software
 
 Most if not all software contains bugs, with an industry average of 15 to 50
 errors per 1000 lines of code. These bugs typically don't become apparent
 during "normal" usage, hence why they manage to escape any testing that is
 performed, but can prove to be exploitable by someone looking for ways to break
-into a device, by using the code outside of it's normal parameters.
+into a device or elevate their privileges once access has been gained, by
+using the code outside of it's normal parameters.
 
 In order to reduce the number of opportunities, it is advisable to minimize the
 software installed on a device to that which is necessary.
@@ -194,11 +203,18 @@ functionality to system services and using
 [D-Bus]({{< ref "d-bus_services.md" >}}) to communicate between the privileged
 system service and unprivileged user application.
 
+# Ensure Package Hardening Techniques Are Enabled
+
+There are a number of features that can be enabled as part of a component build
+process. These should be considered when adding packages to Apertis as part of
+images. These techniques are documented in the
+[Debian hardening documentation](https://wiki.debian.org/Hardening).
+
 # Authentication
 
 It is important that authentication used to identify the device and users of
-the device are kept secret. A need to authenticate may be present in many
-aspects of an Apertis based device:
+the device are kept secret and strong passwords are required where used. A need
+to authenticate may be present in many aspects of an Apertis based device:
 
 - To authenticate users of the device
 - Gaining access to protected download services
@@ -251,7 +267,21 @@ the USB storage before trusting anything found on it.
 # User setup
 
 - Ensure use of strong user passwords where relevant, the `pam_cracklib.so`
-  module can be used in the PAM configuration to enforce password requirements.
+  module can be used in the
+  [PAM configuration](https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html)
+  to enforce password requirements.
+
+  {{% notice tip %}}
+  Password security practices are a constantly evolving. It is best to evaluate
+  the latest guidance when implementing password policies as some commonly used
+  policies are no longer considered best practice.
+
+  Guidance can be found from bodies such as
+  [NIST](https://securityboulevard.com/2021/03/nist-password-guidelines-2021-challenging-traditional-password-management/),
+  [NCSC](https://www.ncsc.gov.uk/collection/passwords/updating-your-approach)]
+  and
+  [Microsoft](https://docs.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide).
+  {{% /notice %}}
 
 - If multiple users are expected to use the device, consider the guidance on
   [multi-user setups]({{< ref "multiuser.md" >}}).
@@ -263,11 +293,12 @@ the USB storage before trusting anything found on it.
 
 # Sandboxing applications and services
 
-Sandboxing utilizes the features provided by Linux to isolate applications and
-services from each other, allowing configuration to be provided to restrict
-access by a process to parts of the system or restricting access to only
-predefined parts. This reduces the impact that a compromised application or
-service can have on the running of the system as a whole.
+[Sandboxing](https://en.wikipedia.org/wiki/Sandbox_(computer_security))
+utilizes the features provided by Linux to isolate applications and services
+from each other, allowing configuration to be provided to restrict access by a
+process to parts of the system or restricting access to only predefined parts.
+This reduces the impact that a compromised application or service can have on
+the running of the system as a whole.
 
 Apertis provides 2 complementary tools that can be used to configure such
 sandboxing:
@@ -292,14 +323,17 @@ functionality:
 - Ensure there are not remote access services running that don't need to be
   provided (such as telnet, rlogin, sshd, etc).
 - Do not use remote services that require the use of plain text passwords (such
-  as telnet and ftp).
+  as telnet and ftp). Where possible,
+  [key-based authentication](https://www.ssh.com/academy/ssh/public-key-authentication)
+  should be used with SSH.
 - Ensure that the network is well firewalled using iptables rules. This should
   be done for both the ingress and [egress]({{< ref "egress_filtering.md" >}})
   of data to both protect the device and ensure that data from the device can't
   be sent back to the attacker should it be compromised.
-- Ensure that communications with network services are encrypted to reduce the
-  risk of leaking sensitive information and to provide authentication between
-  the device and the service.
+- Ensure that communications with network services are
+  [encrypted](https://en.wikipedia.org/wiki/Transport_Layer_Security) to reduce
+  the risk of leaking sensitive information and to provide authentication
+  between the device and the service.
 
 # Upgrades