MODULE 19
Static Hosts
To conclude our discussion on host security, we now turn our attention away from traditional client devices and environments that we tend to think of as requiring firewalls, antivirus software, and so forth. These are the typical desktops, servers, and laptops, along with tablets and other devices. In this module, we’re going to look at more nontraditional devices, which are increasingly becoming connected to networks and the Internet, so that they can make use of Internet-based content and be managed via TCP/IP connections.
Static Environments
A static host is a term describing some of the newer types of nontraditional devices we are seeing more of in this age of the “Internet of Things.” This means that any type of device, from a handheld gaming system, to a television, to the heating and air conditioning controls that make your home comfortable, can all be connected to the global information grid—the Internet. These hosts may or may not have traditional operating systems, but they more likely have chip- or firmware-based operating systems (called embedded operating systems). They may be general purpose devices (think iPads and other tablets), or they may be special purpose devices (such as a set-top box that streams Netflix, Hulu, and Pandora into your television). We even have static hosts in our automobiles, in the form of cellular- and Bluetooth-enabled entertainment systems that also receive GPS signals.
Static hosts aren’t immune from requiring security; in fact, since they permeate our lives so much and actually have access to our most sensitive information (credit card info, physical address, e-mail, location data, and so on), securing them requires taking a much deeper look. Although traditional security methods help, some of these devices and environments require that we pay special attention to security using other methods. In this module we’ll look at precisely that—securing these static hosts and the environments in which they operate.
Static Host Types
In this section we’ll take a look at the different types of hosts that you may encounter in your professional career. Understand that there’s no way we can list every single possible type of host; there are those rare devices here and there that you may never see or may see only in a very specific kind of production environment. Some of those include devices used in military weapons systems, embedded medical devices, industrial control systems, and so forth. You will likely, however, see a lot of the consumer types of devices in your career, which include smart TVs for example, as well as the ever-popular smart devices that run on top of Google and Apple operating systems. We’ll break out the most common types of static hosts and explain them in some detail in the next few sections.
Embedded Devices
Embedded systems are at the heart of static hosts. An embedded system usually means that a network-connected functional computer system is integrated as part of a larger device or system. Embedded systems are usually very specific in functionality and aren’t used as fully functional computer systems. Examples of embedded consumer-based systems include “smart” TVs, photo printers, entertainment devices, game consoles, and so on. Certain industrial computer systems are also embedded devices; these systems are used to control utility and production facilities and equipment, and we’ll discuss them a bit later in the module. Figure 19-1 shows an example of an embedded entertainment device.
Figure 19-1 A set-top embedded consumer entertainment device
Mainframes
Mainframes may be considered anachronistic throwbacks to a bygone era of computing by some of the more tech-savvy young geeks of today, but this isn’t true at all. Although mainframes were originally built to be very large number-crunching machines encased in huge cabinets that only government institutions and large corporations could afford, they have evolved into different types of machines in this day and age. They are still used to process massive amounts of data and provide data analytics services to large organizations, but they are more affordable and powerful than their ancestors. They use modern technologies, powerful hardware, and even modern operating systems. They run huge data centers and are considered to be far more secure than computers used for consumer or commercial purposes.
What makes a mainframe fall into the static host category is its specialized use, embedded systems, and often unique hardware and operating environment requirements. Like other static hosts, mainframes are highly specialized devices; they often require much deeper levels of training for programmers and operators. They also use specialized hardware and operating systems that are built upon more secure processor architectures and complex computing models and designs. These provide for different types of security requirements and features that should be considered, such as different authentication methods, permission settings, and access control models. Additionally, they may use other network protocols in addition to TCP/IP, which can create unique interoperability and security challenges.
SCADA
Supervisory Control and Data Acquisition, or SCADA, is a newer buzzword in the security industry, although it’s actually been around for a number of years. SCADA systems are used in industrial applications, such as utilities (electric plants, sewage treatment centers, nuclear power plants), production facilities (for control of manufacturing systems, for example), and other specialized applications. Heating, ventilation, and air conditioning (HVAC) controls also fall into this category and are often automated and connected to the Internet or other networks to monitor and control environmental elements such as temperature and humidity in a facility. You’ll often hear the term “industrial control systems” (ICS) associated with SCADA.
Although SCADA systems have been around for a very long time, only in recent years have they become an important issue in the information security world. This is because we have only recently discovered that these systems are more and more often being connected to the Internet, and often in an unprotected state. They run TCP/IP protocols and often use embedded versions of some of the popular consumer operating systems, such as Windows or Linux. This makes them prime targets for hackers, who attack SCADA systems to damage critical infrastructure, launch denial-of-service attacks, and generally create mischief and outright harm. Since SCADA systems often connect to very critical systems, it’s not too hard to imagine a hacker attacking and gaining control of these systems and seriously affecting power, water, and other utilities and services on a massive scale. There have even been reported instances of hackers compromising SCADA systems and launching attacks on an organization’s traditional internal network infrastructure through them.
Methods of mitigating these types of attacks include the traditional ones, such as encryption, authentication, and patch management. In the case of many of these systems, infrastructure controls, such as intrusion detection systems (IDSs) and firewall devices, should also be implemented. One other method that should be examined is the complete separation of these networks and their devices from public networks, such as the Internet.
Android
Android is Google’s operating system and is based on Linux. As Linux is an open-source operating system, so is Android to a large degree. Different device manufacturers may customize Android in any way they see fit, within a certain amount of reasonable expectations, so that it will run on their hardware devices. For the most part, Android implementations between devices are fairly consistent; apps may run on all devices or only on a few Android-based devices. For example, Amazon has customized the Android operating system to run on its Kindle Fire devices, as has Samsung. Both of these types of devices have their own unique features, including apps and security features.
Security features that you usually find on an Android device include the ability to encrypt the device storage fully, so that it if it is lost or stolen, data can’t be easily accessed. Device lock, through the use of a PIN, password, or other strong authentication method, is also supported. Additionally, Androids, like other types of mobile smart devices, include geolocation hardware and applications that enable you to find and remotely wipe a lost or stolen device.
Android is an open-source operating system, and as such, developers have a lot of free reign over how they develop their applications. Because the use of Linux is all about choice, Android also follows this mantra to a certain degree. This gives both users and developers a wide range of latitude in how the user uses the device and what they can load on it. The downside of this is that there are less restrictive controls on software development for Android devices than there are on Apple, BlackBerry, or Windows devices, for example. This doesn’t mean that Android devices are less secure, though there have been instances of malicious applications that have been developed and installed on Android devices, even through legitimate app stores.
Another interesting feature of Android devices is that, unlike Apple devices, they can be connected to a computer and used just as you would any other type of removable media or storage, much like a thumb drive or SD card. So this makes it easier to move sensitive data to or from the device, which is a concern to businesses, of course. Another concern is that it’s possible to move malware to and from the device very easily. Even if a piece of malware that gets inadvertently stored on a device doesn’t affect the device itself, when it’s plugged into a computer system running Windows, for example, the malware may be designed to infect and propagate over Windows networks. This is a classic example of having to balance security with functionality, since the Android platform is a highly functional, very flexible platform to work with and use. It can also be used securely, but usually only with the right precautions and security controls. Obviously, the use of particular apps and control of sensitive data in an enterprise is important in securing Android devices when they’re used in in an organization. Encryption and strong authentication will help with these issues, as well as other types of controls imposed on Android users.
iOS
Apple devices run a proprietary operating system, iOS. This includes devices such as the iPhone, iPad, iPod touch, and even, to a smaller degree, the iPods that only play music. All of these devices run some form of Apple’s operating system. For the most part, it’s firmware-based and can be updated via an Internet-based connection through iTunes, Apple’s proprietary software. Although Apple devices have flooded the consumer market, businesses are now using them more and more in their mobile environments. There are now business and healthcare-specific applications that run on Apple devices, for example, and it is not too uncommon to see a doctor at a hospital typing diagnostic information into an iPad.
By and large, Apple devices are fairly secure; this is because Apple strictly controls its software development processes and allows vendors to create software for distribution to their devices only after strict code review. Apple also controls the hardware portion of the platform, so it is able to impose restrictions on how hardware is built and interfaces with the operating system, applications, and networks. However, even Apple devices are subject to security issues. Jailbreaking is a common practice among the hacker and geek communities; this is when a user installs unapproved software on an iPhone that can give the user lower level administrative, or “root,” user privileges on the device. Apple definitely does not approve of jailbreaking, and in fact, it can void the warranty on an Apple device. Even worse, it could render the device unusable in many cases, since jailbreaking software is not very reliable. Once an iPhone has been jailbroken, it can also be susceptible to security issues, such as unauthorized access.
All these are considerations with Apple devices and should be taken into account before the organization purchases a full-scale implementation of these devices for use throughout the enterprise. Additionally, from an enterprise perspective, they should be subject to centralized management through mobile device management (MDM) software. We have devoted an entire module, Module 35, to mobile devices, and we’ll discuss more about mobile device security there.
Game Consoles
Believe it or not, game consoles are a security concern. It only makes sense that they would be, simply because many game consoles today connect to the Internet and require subscriptions, which in turn requires money, which in turn usually requires that credit card information be entered into the system. Additionally, security concerns also deal with some of the young people who use those game consoles, since many of them are not adults. Keep in mind that game consoles don’t just play games anymore; they are able to open chat sessions, browse the Web, view social media, view video, and consume almost any other type of content that a normal computer could. Factor in the possibility that those young people will connect to the Internet and receive age-sensitive content, or be contacted by people with unsavory motives via chat, or social media, and therein lies some potential safety and security issues. So instead of these consoles being merely highly specialized static hosts that can perform only one function (play games), you almost have a fully fledged computer on your hands. These devices are connected to the Internet, usually in a wide-open, nonsecure fashion, and they are being entrusted, in many cases, to a child.
So now that we’re aware of the potential security concerns, what can we do to mitigate these issues? Most often, game consoles come with built-in security controls that can help, although in most cases parental or adult involvement is also a necessity. For example, many game consoles require a PIN or password input to access the device’s stored credit card information. Most of these devices also have controls in place to prevent children from arbitrarily buying games and other types of content without permission. In addition, most gaming devices also have content restriction filters that enable age-sensitive or other inappropriate or undesirable content to be blocked from the device. This might include violent games, media or other content of a sexual nature, or content that contains strong language, for example. There are also controls and restrictions that restrict the ability of users to chat with others via game consoles. Different game consoles have different security features, and you should investigate and thoroughly examine all the different security features that are available on the console. Again, not to stray into the social and legal arenas, but parental or adult involvement is probably also the strongest security control you could have. Figure 19-2 shows an example of a fully functional Internet-capable game console, with the author illustrating the challenges of imposing security controls on these types of devices and their user populations.
Figure 19-2 An Android-based handheld game console, the NVIDIA Shield
In-vehicle Computing Systems
Cars are now computerized; that’s a fact of life. The consumer market now demands cars with built-in systems that provide navigational functions, entertainment functions, and even, in some cases, access to the Internet. Obviously, car manufacturers want to cater to consumers by including all of these great features, as well as the ability to access vehicle health information via network connections. These network connections may include Bluetooth, Wi-Fi, or even, in some cases, cellular connectivity. So if computers are now being built into cars, or added in as aftermarket devices, what are the security ramifications? And how do you secure in-vehicle computer systems? Will it become necessary to install a firewall in your car?
From a security perspective, in-vehicle computing systems have some of the same common vulnerabilities that other systems have, which may include network security issues, such as the vulnerabilities that are already inherent to Bluetooth, Wi-Fi, and cellular technologies. There are also issues involving firmware and patch updates to the systems. Many of these systems have USB or SD card ports, for example, to upload firmware updates or play media content on the devices. Perhaps someday someone will develop a virus or other type of malware that could be injected into these types of systems via a removable media device.
Other security issues may be only the speculative fantasies of geeks, such as a hacker taking over your car and driving it while you’re going down the road or conducting a denial-of-service attack on your engine or transmission, resulting in the car coming to a complete halt on the freeway. However remote these possibilities may be, they may not be too far down the road (pun intended). In short, vehicular computing systems are a new frontier, for both security professionals and hackers. Although traditional security methods and controls will probably work to a large degree, other methods will have to be developed to ensure that these types of static hosts are well protected from malicious users and attacks.
Methods
Now that we’ve discussed a few of the many possible variations of static hosts you may encounter in your travels, we can discuss the different methods for securing these hosts. Obviously, since these hosts still have some things in common with traditional devices, such as IP connectivity, we can employ traditional methods to help secure them, such as firewalls, patching, and so on. We’ll cover those methods next, but we’ll also go over methods that may be unique to these types of devices.
Security Layers
We’ve already discussed the concept of defense-in-depth in previous modules, but let’s go over it again in relation to what we’re talking about here with static hosts. Remember that defense-in-depth means you shouldn’t rely on only one particular security control or defense. You should use multiple layers and multiple security techniques to protect your network and hosts. This is because if you rely only on a single security control, and that control is compromised, then you have nothing left to protect your network. For instance, many people who are uneducated on security matters think that a firewall is the be-all, end-all for security. They think that if they have a firewall installed, they are secure. We know, as security professionals, that this isn’t so. If that single firewall is compromised, an attacker would have an open gateway into a protected network. So we layer our defenses with multiple security methods. Certainly, we do have firewalls, but we also have border routers on our perimeter. We also use other means, such as encryption and authentication, to secure data and systems. We use anti-malware software to combat viruses, Trojans, and the like. All of these different layers contribute to the overall security of our network and hosts; without any one of them, we would be more vulnerable.
In terms of static hosts, you should use multiple different security layers to ensure the security of the host and environment in which it resides. A few of these include not only network protection, such as the use of firewalls and network segmentation, but also traditional host-based security methods, such as operating system patches, anti-malware, and so on. Also, don’t overlook the benefits of device encryption to protect data at rest, as well as transmission encryption using protocols such as SSL and SSH, for example. And, of course, whenever possible, use strong authentication methods with static devices. Many of these devices don’t have particularly strong authentication methods; tablets, for example, may be able to use certificate-based authentication, or strong passwords. Other types of devices, such as smart phones or the navigation system in your automobile, may use only a four-digit PIN, for example. Regardless of the device’s ability to use different authentication methods, you should use the strongest available methods that the device can support.
Control redundancy and diversity are also aspects of a layered security model that you should implement for both static and traditional hosts. Control redundancy refers to having multiple controls in place to perform a similar function. This ensures that if one of these controls is unavailable or is disabled, the other controls will continue to perform that function, so there will be no loss of protection. For example, having multiple firewalls in the DMZ is an example of control redundancy. If one becomes unavailable or is compromised, the others still fill that protection need. Control diversity, on the other hand, means that you will have multiple controls, but they will not be the same identical control, and an attacker would have to circumvent or disable them in different ways. For instance, with multiple firewalls in the DMZ, if they all come from the same vendor and are all the same model, they are more likely to incur the same vulnerabilities. Having a diversity of models and vendors for your firewall architecture would ensure that if a new zero-day vulnerability for one particular firewall is released, it would probably not affect any of the others. This principle applies not only to firewalls, of course, but to other security controls as well. This principle also has to be balanced with the need for standardization and interoperability within the network architecture. Figure 19-3 sums up our discussion on security layers, control redundancy, and control diversity.
Figure 19-3 Security layers, multiple controls, and diverse controls
Network Segmentation
We’ll discuss network segmentation for security reasons more in depth in the next module, but understand that this is an excellent time to bring up the subject, since these static hosts we’ve discussed should often be separated from other traditional hosts for various reasons. Let’s take an interesting type of unconventional host, for example: medical devices. These devices definitely fit the definition of static hosts; they often run embedded or specialized versions of operating systems (Linux or even Windows, for example), they fill a highly specialized need, and they are very often connected to an IP network. If you keep up with the current state of medical devices, then you know that they, too, can be accessed through traditional hacking methods over the network that disrupt their function. Can you imagine the consequences of someone hacking into a network of these devices and interfering with one that monitors the health of a critically ill patient, or one that functions as an insulin pump?
That’s why these devices are afforded special care in a hospital network; they are very often segmented physically away from the network and may also be segmented logically as well, through the use of virtual LANs (discussed in depth within later modules) and separate IP address ranges, in addition to being protected by internal firewalls and other security devices. Wireless medical devices pose an even bigger risk, since wireless networks and hosts are easily accessed by malicious persons. Network segmentation offers just one layer of defense; other layers should also be used to ensure that these specialized devices are not easily compromised.
Application Firewalls
Application firewalls can be thought of in two different contexts. In the first, an application firewall is an appliance or network device that works at all seven layers of the OSI model and has the ability to inspect data within protocols. Think of a situation in which HTTP traffic is filtered in a firewall. In an ordinary stateful firewall, the traffic is filtered based upon an established connection from an internal host. HTTP traffic is allowed in or out based upon whether or not the protocol itself is allowed, over which port, its source or destination IP addresses, if it is the result of an established connection, and so on. This means that filtering is done based upon the characteristics of the traffic itself, rather than the content of the traffic. Application firewalls look at the content of the traffic as well, in addition to its characteristics. So if HTTP is otherwise allowed into the network, an application firewall also looks at the content of the HTTP traffic, often detecting whether or not the content itself is allowed.
Application firewalls can be network-based or host-based; in the context of our discussions for this module, host-based firewalls are more relevant. Although most industrial static hosts do not use application firewalls specifically on their platforms, some of the more modern hosts, especially consumer devices, do have them. A host-based application firewall controls the applications and services on that particular device only, and it secures their connections to the network and interfaces with each other. Figure 19-4 shows an example of an application firewall specific to Android devices.
Figure 19-4 An Android firewall
Manual Updates
Nontraditional hosts often don’t lend themselves to automatic updates. This could be the case for several different reasons. First, some of these hosts are not always connected to the Internet. In the case of SCADA systems, or medical devices, for example, there may be no way to connect them to the Internet without incurring a security risk. Second, the vendor may not have included an automated update process with the device. Some devices may require the download of a patch, an image, or a piece of firmware that has to be manually installed on the device using a very specific process, often resulting in rebooting the device into a special maintenance mode. A third reason might be that the data sensitivity of the systems in question might be so high that the organization can’t perform automatic updates or connect them to the Internet for classification reasons. For example, some US government systems, particularly those of a classified nature, cannot be connected to the Internet.
For these reasons, manual updates may be required for some static hosts. If you have the ability to automate device updates, then obviously you should use that method as much as possible, since it ensures that updates the applied in the most efficient way possible. On the other hand, manual updates can give you the opportunity to test patches and other software updates before applying them to a production system. Often updates are downloaded manually first, tested in a test environment that mirrors the production systems, and then applied to the production systems only when you can be sure that they will cause no ill effects. Manual updates should also be recorded, so that any issues that arise from them can be traced back to a particular patch or update.
Firmware Version Control
Many of these types of devices frequently get firmware updates. Remember that firmware is typically applied as updates to programming in the chips on the hardware portion of the system, rather than as patches to the operating system or application software. Firmware updates can fix issues with both the operating system and hardware on a device, as well as provide for security patches. They can also add new features to a device. For personal devices, firmware version control may not be a big issue; often if the user experiences any issues with the device after the firmware has been updated, it can be a simple matter to reverse the update process and regress back to an earlier version. In an enterprise environment, however, it’s extremely important to maintain version control on firmware updates. This is because a firmware update may cause issues with production software or devices that the organization needs to fulfill its business purposes. As we mentioned previously when discussing manual updates, firmware updates should be tested first in an appropriate environment, and then applied to production devices only when it can be shown that they cause no ill effects. Firmware versions should also be recorded in a central database. Any firmware updates that are necessary should also be checked to see if there any known issues with any versions of software or hardware that the organization is using on the device.
Wrappers
Wrappers are used in different ways in the computing world. At its core, a wrapper is nothing more than a programming interface for different services that exist on the host, which are then translated to be compatible with other services on other hosts, via networking protocols. Wrappers are used to expose interfaces to different services on a host to others in a controlled and consistent manner, usually via the network. In a security context, you’ve probably heard of the TCP Wrappers service, which is used to “wrap” networking protocols securely, providing a filtered software interface to hosts. TCP Wrappers function more like access control lists, allowing only certain network hosts to access those protocols on the device. TCP Wrappers, implemented as a service and commonly found on UNIX and Linux systems, serve as a rudimentary form of firewall service for network protocols on the host.
For static hosts, wrappers may be implemented in different ways, since embedded and other specialized operating systems may require translation for their services and protocols to other hosts and the network. Discussions on implementation of any of these wrappers for any particular device is beyond the scope of this book, but from a security perspective, programmers should ensure that wrappers provide only the minimum functionality necessary to communicate with the device. They should also take encryption and authentication into account when designing wrappers for embedded devices, ensuring that there is some level of control over protecting data that transfers over these interfaces, and allowing some level control over external host and user access to them. Additionally, wrappers should be configured to allow minimum access possible from external interfaces, devices, and protocols. From a user perspective, most users won’t ever need to access wrapper interfaces with embedded devices. From an administrator or security perspective, however, you may occasionally need to access these interfaces through different configuration methods for the particular static or embedded hosts you’re working with.
Module 19 Questions and Answers
Questions
1. Which of the following would be considered static hosts? (Choose all that apply.)
A. HVAC systems controlled by remote access over an IP network
B. Game consoles with Internet access
C. A user workstation in an office
D. A pumping mechanism in a sewage treatment plant that uses an embedded Linux operating system
2. Which of the following has an operating system installed as firmware on a hardware chip?
A. Workstation
B. Embedded device
C. Server
D. Cluster
3. All of the following are characteristics of SCADA devices, except:
A. Used to control mechanical and production devices
B. Often found in utilities and manufacturing facilities
C. Fully fledged, multifunctional computing devices
D. Controlled remotely via network protocols
4. Which of the following device platforms is considered open source and less restrictive in terms of development requirements?
A. Android
B. Blackberry
C. iOS
D. Windows
5. Which of the following are common security concerns associated with Internet-connected gaming devices? (Choose two.)
A. Denial-of-service attacks against the device
B. Child safety
C. Attacks against user authentication
D. Unauthorized access to personal information stored on the device
6. Which of the following terms describes the use of several different manufacturers and models of web proxy devices in a layered security architecture?
A. Control compensation
B. Control redundancy
C. Control diversity
D. Defense-in-depth
7. All of the following would be considered ways to separate sensitive static hosts from others on a network, except:
A. Virtual LANs
B. Physically separated network segments
C. Different IP address ranges
D. Separate collision domains
8. Which of the following does an application firewall focus on for traffic filtering?
A. Traffic content
B. Protocol and port
C. Source or destination IP address
D. Domain name
9. Which of the following hardware characteristics for static hosts is important to control in an enterprise environment, due to interoperability and security issues?
A. Encryption strength
B. Software version
C. Firmware version
D. Authentication method
10. Which of the following refers to a programming or software-based interface used to manage connections and traffic access to and from a host?
A. Firewall
B. Wrapper
C. Firmware
D. Embedded OS
Answers
1. A, B, D. User workstations in an office would not be considered as static or specialized hosts.
2. B. An embedded device has an operating system installed as firmware on a hardware chip.
3. C. SCADA devices are usually single-purpose, limited functionality devices.
4. A. Android-based devices are considered open source and less restrictive in terms of development requirements.
5. B, D. Both child safety and unauthorized access to personal or financial information stored on gaming consoles are of particular concern to parents and security professionals alike.
6. C. Control diversity is a concept that describes the use of several different manufacturers and models of web proxy devices in layered security architectures.
7. D. Separate collision domains do not give any special type of separation or segmentation of sensitive static hosts from others on the network; devices separated only by collision domain are still usually on the same logical and physical network segment.
8. A. An application firewall focuses on traffic content for filtering, rather than on traffic characteristics.
9. C. Firmware version is important to control in an enterprise environment, due to interoperability and security issues.
10. B. A wrapper is a programming or software-based interface used to manage connections and traffic access to and from a host.