2 cissp ® Official Study Guide Eighth Edition

Firmware
Firmware
(also known as 
microcode
in some circles) is a term used to describe software 
that is stored in a ROM chip. This type of software is changed infrequently (actually, never, 
if it’s stored on a true ROM chip as opposed to an EPROM/EEPROM) and often drives the 
basic operation of a computing device. There are two types of firmware: BIOS on a mother-
board and general internal and external device firmware.
BIOS and UEFI
The 
basic input/output system (BIOS)
contains the operating system–independent primi-
tive instructions that a computer needs to start up and load the operating system from disk. 
The BIOS is contained in a firmware device that is accessed immediately by the computer at 

---

342
Chapter 9 
■
Security Vulnerabilities, Threats, and Countermeasures
boot time. In most computers, the BIOS is stored on an EEPROM chip to facilitate version 
updates. The process of updating the BIOS is known as “
flashing
the BIOS.”
There have been a few examples of malicious code embedding itself into BIOS/firmware. 
There is also an attack known as 
phlashing,
in which a malicious variation of official BIOS 
or firmware is installed that introduces remote control or other malicious features into a 
device.
Since 2011, most system manufacturers have replaced the traditional BIOS system on 
their motherboards with Unified Extensible Firmware Interface (UEFI). UEFI is a more 
advanced interface between hardware and the operating system, which maintains support 
for legacy BIOS services.
Device Firmware
Many hardware devices, such as printers and modems, also need some limited processing 
power to complete their tasks while minimizing the burden placed on the operating system 
itself. In many cases, these “mini” operating systems are entirely contained in firmware 
chips onboard the devices they serve. As with a computer’s BIOS, device firmware is fre-
quently stored on an EEPROM device so it can be updated as necessary.
Client-Based Systems
Client-based vulnerabilities place the user, their data, and their system at risk of com-
promise and destruction. A client-side attack is any attack that is able to harm a client. 
Generally, when attacks are discussed, it’s assumed that the primary target is a server
or a server-side component. A client-side or client-focused attack is one where the client 
itself, or a process on the client, is the target. A common example of a client-side attack is 
a malicious website that transfers malicious mobile code (such as an applet) to a vulner-
able browser running on the client. Client-side attacks can occur over any communications 
protocol, not just Hypertext Transfer Protocol (HTTP). Another potential vulnerability 
that is client based is the risk of poisoning of local caches.
Applets
Recall that agents are code objects sent from a user’s system to query and process data 
stored on remote systems. 
Applets
perform the opposite function; these code objects are 
sent from a server to a client to perform some action. In fact, applets are actually self-
contained miniature programs that execute independently of the server that sent them. The 
arena of the World Wide Web is undergoing constant flux. The use of applets is not as com-
mon today as it was in the early 2010s. However, applets are not absent from the Web, and 
most browsers still support them (or still have add-ons present that support them). Thus, 
even when your organization does not use applets in your internal or public web design, 
your web browsers could encounter them while surfing the public Web.

---

Client-Based Systems 
343
Imagine a web server that offers a variety of financial tools to web users. One of these tools 
might be a mortgage calculator that processes a user’s financial information and provides a 
monthly mortgage payment based on the loan’s principal and term and the borrower’s credit 
information. Instead of processing this data and returning the results to the client system, the 
remote web server might send to the local system an applet that enables it to perform those cal-
culations itself. This provides a number of benefits to both the remote server and the end user:
■
The processing burden is shifted to the client, freeing up resources on the web server to 
process requests from more users.
■
The client is able to produce data using local resources rather than waiting for a 
response from the remote server. In many cases, this results in a quicker response to 
changes in the input data.
■
In a properly programmed applet, the web server does not receive any data provided to the 
applet as input, therefore maintaining the security and privacy of the user’s financial data.
However, just as with agents, applets introduce a number of security concerns. They 
allow a remote system to send code to the local system for execution. Security administra-
tors must take steps to ensure that code sent to systems on their network is safe and prop-
erly screened for malicious activity. Also, unless the code is analyzed line by line, the end 
user can never be certain that the applet doesn’t contain a Trojan horse component. For 
example, the mortgage calculator might indeed transmit sensitive financial information to 
the web server without the end user’s knowledge or consent.
Two historical examples of applet types are Java applets and ActiveX controls.