2 cissp ® Official Study Guide Eighth Edition

375
Architecture/Infrastructure Considerations
When implementing mobile device policies, organizations should evaluate their network 
and security design, architecture, and infrastructure. If every worker brings in a personal 
device, the number of devices on the network may double. This requires planning to handle 
IP assignments, communications isolation, data-priority management, and increased intru-
sion detection system (IDS)/intrusion prevention system (IPS) monitoring load, as well 
as increased bandwidth consumption, both internally and across any internet link. Most 
mobile devices are wireless enabled, so this will likely require a more robust wireless net-
work and dealing with Wi-Fi congestion and interference. A mobile device policy needs to 
be considered in light of the additional infrastructure costs it will trigger.
Legal Concerns
Company attorneys should evaluate the legal concerns of mobile devices. Using personal 
devices in the execution of business tasks probably means an increased burden of liability 
and risk of data leakage. Mobile devices may make employees happy, but it might not be a 
worthwhile or cost-effective endeavor for the organization.
Acceptable Use Policy
The mobile device policy should either reference the company acceptable use policy or 
include a mobile device–specific version focusing on unique issues. With the use of personal 
mobile devices at work, there is an increased risk of information disclosure, distraction, 
and access of inappropriate content. Workers should remain mindful that the primary goal 
when at work is to accomplish productivity tasks.
On-board Camera/Video
The mobile device policy needs to address mobile devices with on-board cameras. Some envi-
ronments disallow cameras of any type. This would require that mobile devices be without a 
camera. If cameras are allowed, a description of when they may and may not be used should 
be clearly documented and explained to workers. A mobile device can act as a storage device, 
provide an alternate wireless connection pathway to an outside provider or service, and also 
be used to collect images and video that disclose confidential information or equipment.
Assess and Mitigate Vulnerabilities in 
Embedded Devices and Cyber-Physical 
Systems
An 
embedded system
is a computer implemented as part of a larger system. The embed-
ded system is typically designed around a limited set of specific functions in relation to the 
larger product of which it’s a component. It may consist of the same components found in a 

---

376
Chapter 9 
■
Security Vulnerabilities, Threats, and Countermeasures
typical computer system, or it may be a microcontroller (an integrated chip with on-board 
memory and peripheral ports). Examples of embedded systems include network-attached 
printers, smart TVs, HVAC controls, smart appliances, smart thermostats, vehicle enter-
tainment/driver assist/self-driving systems, and medical devices. 
Another similar concept to that of embedded systems are
static systems
(aka
static envi-
ronments
). A static environment is a set of conditions, events, and surroundings that don’t 
change. In theory, once understood, a static environment doesn’t offer new or surprising 
elements. A static IT environment is any system that is intended to remain unchanged by 
users and administrators. The goal is to prevent, or at least reduce, the possibility of a user 
implementing change that could result in reduced security or functional operation. 
In technology, static environments are applications, OSs, hardware sets, or networks 
that are confi gured for a specifi c need, capability, or function, and then set to remain unal-
tered. However, although the term
static
is used, there are no truly static systems. There 
is always the chance that a hardware failure, a hardware confi guration change, a software 
bug, a software-setting change, or an exploit may alter the environment, resulting in unde-
sired operating parameters or actual security intrusions.