Back to top

Protecting below the OS

Last updated November 12th, 2024

Laptop PCs can be particularly challenging for IT admins to protect since the BIOS — the software that initializes the computer’s hardware components and starts the Operating System (OS) — is often the target of attackers. The BIOS needs to be particularly secure from threats to its data and its code, as these are most vulnerable to hackers. The following describes the types of compromises that are present if the BIOS isn’t properly protected, as well as their impacts on the BIOS:

Data compromise

A data compromise occurs when an attacker gains access to protected information like passwords, certificates, or encryption keys. During a normal boot sequence, the BIOS relies on the Trusted Platform Module, or TPM, to encrypt sensitive data and fend off hacking attempts on the hardware. Windows features like BitLocker then use the Trusted Platform Module to ensure that protected data is only available when trusted firmware has been loaded. If the BIOS is compromised, it may provide false information to the Trusted Platform Module and trick it into loading a malicious OS, thus giving an attacker backdoor access to protected enterprise data.

Code compromises

The integrity of the OS depends on the integrity of the BIOS, since it is ultimately trusted for loading and executing the code that starts the OS. If the BIOS is compromised, then the self-check code Windows uses to detect threats may also be compromised. Without properly functioning update-validation systems, the BIOS (which normally validates update packages) can update itself with malicious code, granting backdoor access to hackers and preventing itself from being removed. This could lead to the entire device being compromised unless an IT Admin intervenes.

Impacts of BIOS compromise

If a BIOS is compromised, the following may happen to either its data or code:

Impact Description
Tampered UEFI data The BIOS maintains most of its boot configuration data in UEFI variables stored in onboard flash memory. If a malicious root or admin process modifies one of these variables, then security-critical features such as Secure Boot can be disabled, thus letting the device potentially boot untrusted or malicious software.
Corrupted firmware BIOS code is also stored in flash memory, which may be accessible to compromised OS kernels or physical attackers looking to gain privilege or persistency. In the last several years, there have been multiple instances of malware adding malicious code to the BIOS which then caused malicious code to be run on the host OS.
Exposed enterprise network Physical attacks can disable Secure Boot settings or circumvent the Trusted Platform Module. This could result in the loading of unapproved OS images, and exfiltration of sensitive data. If an attacker does manage to boot a malicious OS image, they may abuse VPN policies to gain access to a corporate network.

Although these problems are persistent, they aren’t new to IT security professionals. Various technologies have been developed to help mitigate these problems. For example, UEFI introduced standards to the Secure Boot process to ensure that code only loads after it’s been verified. Other technologies like Intel Boot Guard extend the Secure Boot process by ensuring code verification begins with the CPU hardware itself.

Though these technologies help to mitigate some of the BIOS compromise issues mentioned above, they also present several limitations. For example:

  • While the UEFI Secure Boot process validates firmware code, it doesn’t validate UEFI configuration data.
    • This can lead to users and software processes making modifications to corrupt the BIOS settings. Once an attacker has access to BIOS settings, they could remove Secure Boot features altogether to allow the loading of malicious firmware code.
  • UEFI is limited in the response options it provides when it detects security issues.
    • This can be a problem in situations where the device can’t silently handle security issues by itself. For example, if a compromise is detected at boot time, the user or admin may need to trigger incident response processes, which might require unified and flexible response mechanisms out-of-scope from UEFI.
  • The existing Secure Boot process is focused solely on the detection and prevention of unsigned or revoked firmware being loaded.
    • During a normal boot sequence, the BIOS is loaded in several stages, with each stage verifying the authenticity of the next. If a tampered boot stage is detected anywhere in the process, the BIOS would simply stop booting, and likely require administrator intervention – costing valuable time and resources – to be repaired.

With all these limitations in place, IT admins and executives need a more secure and robust solution to protect their enterprise from the growing number of threats below the OS. A solution that guarantees data and code protection before the OS ever boots up. This is why we built the Samsung Galaxy Book with the Knox security platform, starting with the Samsung Galaxy Book4 — our most secure and tamper-resistant laptop to date.

Introducing the Samsung Galaxy Book4

Samsung Galaxy Books with the Knox security platform were designed to provide best-in-class hardware-backed security to meet the needs of enterprise users. They pair industry-wide standards with powerful OEM features to provide high levels of firmware protection and robust firmware recovery capabilities.

Every Galaxy Book with the Knox security platform comes equipped with our Secure Embedded Processor (SecEP), a standalone processor that validates firmware before the CPU ever powers up. This processor — along with its memory (RAM) and dedicated storage unit — are all isolated from the CPU in order to protect against compromises to the OS, hypervisor, and BIOS.

While the BIOS takes advantage of industry-standard security features like Intel Boot Guard and UEFI Secure Boot, the SecEP brings additional robust security features to help further protect the firmware. For example:

  • Intel Boot Guard ensures that only an OEM-approved BIOS may run on the CPU. The SecEP takes security one step further by ensuring that only approved versions of the BIOS may modify any boot configuration data, and that a backup copy of the BIOS firmware is always available even if the original is corrupted.

  • UEFI ensures that all firmware modules are verified by hash and validated against a binary revocation list. This means that only privileged processes have the ability to modify boot configuration data. The SecEP further enhances this process by making the revocation lists and boot configuration data tamper-resilient. It works with the BIOS to ensure that critical boot parameters only get modified by an authenticated user or admin through the BIOS setup utility. If UEFI detects an attempt to load suspicious firmware, the SecEP’s Tamper Alert feature can be configured to require either user or admin confirmation before booting.

By introducing the SecEP, admins gain more awareness and control of common security compromises. Critical features like auto-recovery, data protection, and tamper alert are deeply integrated with the BIOS, but also completely isolated from the OS. This helps to ensure that an attack on the BIOS gets handled before firmware ever gets loaded.

Throughout the rest of this document, we’ll describe the various hardware-backed security features and enhancements introduced by the Knox security platform. Join us, as we showcase our best-in-class, most secure and protected laptop PC yet.

Is this page helpful?