CompTIA Security+: Secure Systems Design and Deployment

Next up, system design.  As anyone who has architected a project knows, it’s much easier to change paths at the beginning.  When you’re mid-stream, it’s very hard to change.  So consider security issues at the beginning.  : )

This is a continuation of my blog post series on the CompTIA Security+ exam, where I share my studying and connect it to real-world events.


Use of hardware is unavoidable:  servers, mobile devices, workstations, and so on.  It also represents a lot of security risk.  Firmware (software that facilitates direct hardware functionality) can be changed.  Data can be retrieved from lost or stolen devices.  Access to hardware can undermine other security controls in place.

Use of full disk encryption (FDE) and self-encrypting disks (SED) can help.  These methods allow for cryptographic protection of hard disk drives and other storage media.  This means that the data is protected even if the drive is removed from the machine.

Trusted Platform Module (TPM) is a hardware solution for generating and storing keys.  This data is not accessible via normal software methods.

A hardware security module (HSM) is a device used to manage or store encryption keys.  Typically, it’s a peripheral advice (connected via USB or network connection).  Here’s an example from Yubikey.  HSMs are a way of using private keys without storing them on the networked system.

Basic Input/Output System, or BIOS, is “the firmware that a computer system uses as a connection between the actual hardware and the operating system.”  It initializes and tests interfaces to a system’s hardware, and is usually stored in nonvolatile flash memory.

Unified Extensible Firmware Interface (UEFI) is the upgrade/replacement to BIOS.  In addition to modernization for peripherals, communication speed, and storage, it also has more security features built into it.  All new systems are UEFI-based.

UEFI also has a feature called Secure Boot.  Operating systems have a number of drivers and add-ons that hook into it and extend functionality.  This is a great attack vector for malware, which can lead to attacks at boot time.  Secure Boot allows only signed drivers and OS loaders to be invoked.  It also provides attestation that these drivers/loaders have not changed since they were approved.  SecureBoot is supported by Windows and major versions of Linux.

Supply chains can be another security risk.  Because of the global manufacturing processes in use, it is almost impossible to track down (and verify) all hardware components.  Throw software in there too and it’s even more difficult.

Hardware root of trust is the idea that if you have a trusted source of given security functions, that layer can be used to promote security to higher layers of a system.  These roots of trust need to be very limited in functionality and kept secure.  Examples include Apple’s Secure Enclave coprocessor.

Lastly, this section talks about EMI and EMPs.  Electromagnetic interference (EMI) is an electrical disturbance that affects an electrical circuit, due to EM induction or radiation from another source.  An electromagnetic pulse (EMP) is a burst of current in an electronic device caused by a pulse of electromagnetic radiation… that definition seemed a bit circular.  A popular topic among preppers (I’m not going to touch that any further).

Operating Systems

Operating systems are “complex programs designed to provide a platform for a wide variety of services to run.”  The OS is responsible for managing the security aspects of hardware utilization.

There are many different types of operating systems:

Patch Management

All systems require software updates.  Each OS has its own way of doing things.  Windows is more user-friendly and has a built-in update mechanism.  Linux is usually a more difficult, manual process.  It’s critically important to keep systems up to date.

There are different types of fixes:


Operating systems come with a set of default configurations.  Typically, these have convenience–not security–in mind.

Hardening is the process of removing unnecessary applications and utilities, disabling unneeded services, setting appropriate permissions on files, and updating the OS and application code to the latest versions.

Hardening also involves the idea of least privilege, which means identifying the specific needs of a system and then enabling only the needed functionality.  This means disabling unnecessary ports and services.

Alongside least privilege is least functionality, which means that a system should do what it is supposed to do, and nothing more.  This helps reduce attack surface.

A trusted operating system is one that is designed to allow multilevel security in its operation.  This might mean fulfilling criteria, such as those outlined in the Common Criteria.

Applications can be blacklisted or whitelisted.  Blacklisting means there is a set list of disallowed programs, but this approach doesn’t do well against dynamic/changing threats.  Whitelisting means that only pre-approved applications can be installed, but the list of whitelisted apps can be long and unwieldy.  You can set this at the group or user level.

Lastly, disable all default accounts and passwords.  If you can’t disable the account, change the default password to something hard to crack.

To harden a system, you need to have:

  1. An OS installation that came from a trusted source, as well as trusted application installation sources.
  2. The installation, hardening and updates have to happen while the machine is connected (only) to a network that is completely trusted.
  3. All patches and updates are in place.
  4. After hardening, backup images are taken.


Peripherals used to be just “dumb” devices, but as functionality has been added, the attack surface has increased.


Sandboxing refers to quarantining or isolating a system from its surroundings.  This might also mean limiting interaction with the CPU or other processes by use of virtualization.


Organizations typically have separate computing environments for different purposes.  These often run on segregated hardware.

Secure Baseline and Integrity Management

Lastly, the chapter discusses a secure baseline (again).  The idea is that you determine your needs for a system, then remove all unnecessary functionality and privilege.  Once you’ve hardened a system, the resulting product is a secure baseline that allows the system to be used securely.

Changes from this baseline can help inform security decisions.  Integrity measurement is the measuring and identification of changes to a system, away from its expected or baseline value.  The point isn’t just to measure once and be done with it.  This should be regularly updated.