Mr. Watson—come here—I want to see you.

—Alexander Graham Bell

Up to this point, we’ve treated all the data as if it were equal. While it is true that a packet is a packet regardless of its contents, there are a number of common cases in which the purpose of a communication matters a lot. If we’re downloading a file from a server, we normally don’t care (or even know about) the variation in delay times between consecutive packets. This variation, known as packet jitter, could mean that some packets follow each other closely (no variance) while others take a lot longer (or shorter) time to arrive. While packet jitter is largely inconsequential to our file download, it could be very problematic for voice, video, or interactive collaboration communications channels.

Implementing secure communications channels has always been important to most organizations. However, the sudden shift to remote working brought on by COVID-19 has made the security of these channels critical due to the convergence of increased demand by legitimate users and increased targeting by threat actors. In this chapter, we look at some of the most prevalent communications channels that ride on our networks. These include voice, multimedia collaboration, remote access, and third-party channels. Let’s start with the one we’re most accustomed to: voice communications.

Voice Communications

Voice communications have come a long way since Alexander Graham Bell made that first call in 1876. It is estimated that 95 percent of the global population has access to telephone service, with most of those being cellular systems. What ties global voice networks together is a collection of technologies, some of which we’ve discussed before (e.g., ATM in Chapter 11 and LTE in Chapter 12), and some to which we now turn our attention.

Public Switched Telephone Network

The traditional telephone system is based on a circuit-switched, voice-centric network called the public switched telephone network (PSTN). The PSTN uses circuit switching instead of packet switching. When a phone call is made, the call is placed at the PSTN interface, which is the user’s telephone. This telephone is connected to the telephone company’s local loop via electric wires, optical fibers, or a radio channel. Once the signals for this phone call reach the telephone company’s central office (the end of the local loop), they are part of the telephone company’s circuit-switching world. A connection is made between the source and the destination, and as long as the call is in session, the data flows through the same switches.

When a phone call is made, the phone numbers have to be translated, the connection has to be set up, signaling has to be controlled, and the session has to be torn down. This takes place through the Signaling System 7 (SS7) protocol. Figure 15-1 illustrates how calls are made in the PSTN using SS7. Suppose Meeta calls Carlos. Meeta’s phone is directly connected to a signal switching point (SSP) belonging to the telephone company (telco) that provides her service. Her telco’s SSP finds the SSP of the telco providing Carlos’s phone service and they negotiate the call setup. The call itself is routed over the two signal transfer points (STPs) that interconnect the two SSPs. STPs perform a similar function in a circuit-switched network as routers do in an IP network. If Meeta wanted to call (or conference in) Nancy on her mobile phone, her SSP could query a service control point (SCP), which controls advanced features such as finding mobile subscribers’ SSPs and enabling conference calls involving multiple networks.

Figure 15-1 Major components of a public switched telephone network

DSL

It turns out that PSTN local loops (i.e., the telephone wires that go into our homes and offices) are able to support much more bandwidth than the small amount required for voice communications. In the 1980s, telcos figured out that they could transmit digital data at frequencies above those used for voice calls without interference. This was the birth of digital subscriber line (DSL), which is a high-speed communications technology that simultaneously transmits analog voice and digital data between a home or business and the service provider’s central office.

Figure 15-2 shows a typical DSL network. In the subscriber’s home, a DSL modem creates a LAN to which computers and wireless access points can be connected. This modem, in turn, is connected to a DSL splitter if the home also has analog phone service. A bunch of DSL subscribers in the same neighborhood are then connected to a DSL access multiplexer (DSLAM) in the central office, where analog signals are sent to a voice switch (and on to the PSTN) and digital signals are routed out to the Internet. The tricky part is that the maximum distance between the DSLAM and the DSL splitter in the subscriber’s home cannot be greater than about 2.5 miles unless you put extenders in place to boost the signal strength.

Figure 15-2 DSL network

DSL offers two broad types of services. With symmetric services, traffic flows at the same speed upstream and downstream (to and from the Internet or destination). With asymmetric services, the downstream speed is much higher than the upstream speed. The vast majority of DSL lines in use today are asymmetric, because most users usually download much more data from the Internet than they upload. The following are some of the most common types of DSL service:

• Asymmetric DSL (ADSL)   These lines allocate more bandwidth for downstream data than for upstream. The technology has gone through multiple upgrades, with ADSL2+ (ITU standard G.992.5) being the latest and fastest. It has data rates of up to 24 Mbps downstream and 1.4 Mbps upstream, but can only support distances of about a mile from the central office. ADSL is generally used by residential users.

• Very high-data-rate DSL (VDSL)   VDSL is basically ADSL at much higher data rates (up to 300 Mbps downstream and 100 Mbps upstream). It is capable of supporting high-bandwidth applications such as HDTV, telephone services (Voice over IP), and general Internet access over a single connection.

• G.fast   Since the biggest challenge with DSL is the length of the subscriber loop, why not run fiber-optic cable from the central office to a distribution point near the home and then finish the last few hundred feet using the copper wires that are already in place? This is what G.fast (ITU standards G.9700 and G.9701) does. It can deliver data rates of up to 1 Gbps.

ISDN

Integrated Services Digital Network (ISDN) is another technology that leverages legacy telephone lines to enable data, voice, and signaling traffic to travel over a medium in a digital manner previously used only for analog voice transmission. ISDN uses the same wires and transmission medium used by analog dial-up technologies, but it works in a digital fashion. If a computer uses a modem to communicate with an ISP, the modem converts the data from digital to analog to be transmitted over the phone line. If that same computer was configured to use ISDN and had the necessary equipment, it would not need to convert the data from digital to analog, but would keep it in a digital form. This, of course, means the receiving end would also require the necessary equipment to receive and interpret this type of communication properly. Communicating in a purely digital form provides higher bit rates that can be sent more economically.

ISDN is a set of telecommunications services that can be used over public and private telecommunications networks. It provides a digital, point-to-point, circuit-switched medium and establishes a circuit between the two communicating devices. An ISDN connection can be used for anything a modem can be used for, but it provides more functionality and higher bandwidth. This digital service can provide bandwidth on an as-needed basis and can be used for LAN-to-LAN on-demand connectivity, instead of using an expensive dedicated link.

Analog telecommunication signals use a full channel for communication, but ISDN can break up this channel into multiple channels to move various types of data and provide full-duplex communication and a higher level of control and error handling. ISDN provides two basic services: Basic Rate Interface (BRI) and Primary Rate Interface (PRI).

BRI has two B channels that enable data to be transferred and one D channel that provides for call setup, connection management, error control, caller ID, and more. The bandwidth available with BRI is 144 Kbps, and BRI service is aimed at the small office and home office (SOHO) market. The D channel provides for a quicker call setup and process in making a connection compared to dial-up connections. An ISDN connection may require a setup connection time of only 2 to 5 seconds, whereas a modem may require a timeframe of 45 to 90 seconds. This D channel is an out-of-band communication link between the local loop equipment and the user’s system. It is considered “out-of-band” because the control data is not mixed in with the user communication data. This makes it more difficult for a would-be defrauder to send bogus instructions back to the service provider’s equipment in hopes of causing a denial of service (DoS), obtaining services not paid for, or conducting some other type of destructive behavior.

PRI has 23 B channels and one D channel, and is more commonly used in corporations. The total bandwidth is equivalent to a T1, which is 1.544 Mbps.

ISDN is not usually the primary telecommunications connection for organizations, but it can be used as a backup in case the primary connection goes down. An organization can also choose to implement dial-on-demand routing (DDR), which can work over ISDN. DDR allows an organization to send WAN data over its existing telephone lines and use the PSTN as a temporary type of WAN link. It is usually implemented by organizations that send out only a small amount of WAN traffic and is a much cheaper solution than a real WAN implementation. The connection activates when it is needed and then idles out.

Cable Modems

The cable television companies have been delivering television services to homes for years, and then they started delivering data transmission services for users who have cable modems and want to connect to the Internet at high speeds. Cable modems provide high-speed access to the Internet through existing cable coaxial and fiber lines. The cable modem provides upstream and downstream conversions.

Coaxial and fiber cables are used to deliver hundreds of television stations to users, and one or more of the channels on these lines are dedicated to carrying data. The bandwidth is shared between users in a local area; therefore, it will not always stay at a static rate. So, for example, if Mike attempts to download a program from the Internet at 5:30 P.M., he most likely will have a much slower connection than if he had attempted it at 10:00 A.M., because many people come home from work and hit the Internet at the same time. As more people access the Internet within his local area, Mike’s Internet access performance drops.

Most cable providers comply with Data-Over-Cable Service Interface Specifications (DOCSIS), which is an international telecommunications standard that allows for the addition of high-speed data transfer to an existing cable TV (CATV) system. DOCSIS includes MAC layer security services in its Baseline Privacy Interface/Security (BPI/SEC) specifications. This protects individual user traffic by encrypting the data as it travels over the provider’s infrastructure.

IP Telephony

Internet Protocol (IP) telephony is an umbrella term that describes carrying telephone traffic over IP networks. So, if we have all these high-speed digital telecommunications services and the ability to transmit Voice over IP (VoIP) networks, do we even need analog telephones anymore? The answer is a resounding no. PSTN is being replaced by data-centric, packet-oriented networks that can support voice, data, and video. The new IP telephony networks use more efficient and secure switches, protocols, and communication links compared to PSTN but must still coexist (for now) with this older network. This means that VoIP is still going through a tricky transition stage that enables the old systems and infrastructures to communicate with the new systems until the old systems are dead and gone.

This technology gets around some of the barriers present in the PSTN today. The PSTN interface devices (telephones) have limited embedded functions and logic, and the PSTN environment as a whole is inflexible in that new services cannot be easily added. In VoIP, the interface to the network can be a computer, server, PBX, or anything else that runs a telephone application. This provides more flexibility when it comes to adding new services and provides a lot more control and intelligence to the interfacing devices. The traditional PSTN has basically dumb interfaces (telephones without much functionality), and the telecommunication infrastructure has to provide all the functionality. In VoIP, the interfaces are the “smart ones” and the network just moves data from one point to the next.

Because VoIP is a packet-oriented switching technology, the arrival times of different packets may not be regular. You may get a bunch of packets close to each other and then have random delays until the next ones arrive. This irregularity in arrival rates is referred to as jitter, which can cause loss of synchronicity in the conversation. It typically means the packets holding the other person’s voice message got queued somewhere within the network or took a different route. VoIP includes protocols to help smooth out these issues and provide a more continuous telephone call experience.

Four main components are normally used for VoIP: an IP telephony device, a call-processing manager, a voicemail system, and a voice gateway. The IP telephony device is just a phone that has the necessary software that allows it to work as a network device. Traditional phone systems require a “smart network” and a “dumb phone.” In VoIP, the phone must be “smart” by having the necessary software to take analog signals, digitize them, break them into packets, and create the necessary headers and trailers for the packets to find their destination. The voicemail system is a storage place for messages and provides user directory lookups and call-forwarding functionality. A voice gateway carries out packet routing and provides access to legacy voice systems and backup calling processes.

When a user makes a call, his VoIP phone sends a message to the call-processing manager to indicate a call needs to be set up. When the person at the call destination takes her phone off the hook, this notifies the call-processing manager that the call has been accepted. The call-processing manager notifies both the sending and receiving phones that the channel is active, and voice data is sent back and forth over a traditional data network line.

Moving voice data through packets is more involved than moving regular data through packets. This is because voice (and video) data must be sent as a steady stream, whereas other types of traffic are more tolerant to burstiness and jitter. A delay in data transmission is not noticed as much as is a delay in voice transmission. VoIP systems have advanced features to provide voice data transmission with increased bandwidth, while reducing variability in delay, round-trip delay, and packet loss issues. These features are covered by two relevant standards: H.323 and the Session Initiation Protocol (SIP).

H.323

The ITU-T H.323 recommendation is a standard that deals with audio and video calls over packet-based networks. H.323 defines four types of components: terminals, gateways, multipoint control units, and gatekeepers. The terminals can be dedicated VoIP telephone sets, videoconferencing appliances, or software systems running on a traditional computer. Gateways interface between H.323 and non-H.323 networks, providing any necessary protocol translation. These gateways are needed, for instance, when using the PSTN to connect H.323 systems. Multipoint control units (MCUs) allow three or more terminals to be conferenced together and are sometimes referred to as conference call bridges. Finally, the H.323 gatekeeper is the central component of the system in that it provides call control services for all registered terminals.

Session Initiation Protocol

An alternative standard for voice and video calls is the Session Initiation Protocol (SIP), which can be used to set up and break down the call sessions, just as SS7 does for PSTN calls. SIP is an application layer protocol that can work over TCP or UDP. It provides the foundation to allow the phone-line features that SS7 provides, such as causing a phone to ring, dialing a phone number, generating busy signals, and so on. SIP is used in applications such as video conferencing, multimedia, instant messaging, and online gaming.

SIP consists of two major components: the User Agent Client (UAC) and User Agent Server (UAS). The UAC is the application that creates the SIP requests for initiating a communication session. UACs are generally messaging tools and soft-phone applications that are used to place VoIP calls. The UAS is the SIP server, which is responsible for handling all routing and signaling involved in VoIP calls.

SIP relies on a three-way-handshake process to initiate a session. To illustrate how a SIP-based call kicks off, let’s look at an example of two people, Bill and John, trying to communicate using their VoIP phones. Bill’s system starts by sending an INVITE message to John’s system. Since Bill’s system is unaware of John’s location, the INVITE message is sent to the SIP server, which looks up John’s address in the SIP registrar server. Once the location of John’s system has been determined, the INVITE message is forwarded to his system. During this entire process, the server keeps the caller (Bill) updated by sending his system a Trying response, indicating the process is underway. Once the INVITE message reaches John’s system, it starts ringing. While John’s system rings and waits for John to respond, it sends a Ringing response to Bill’s system, notifying Bill that the INVITE has been received and John’s system is waiting for John to accept the call. As soon as John answers the call, an OK packet is sent to Bill’s system (through the server). Bill’s system now issues an ACK packet to begin call setup. It is important to note here that SIP itself is not used to stream the conversation because it’s just a signaling protocol. The actual voice stream is carried on media protocols such as the Real-time Transport Protocol (RTP). RTP provides a standardized packet format for delivering audio and video over IP networks. Once Bill and John are done communicating, a BYE message is sent from the system terminating the call. The other system responds with an OK, acknowledging the session has ended. This handshake is illustrated in Figure 15-3.

Figure 15-3 SIP handshake

The SIP architecture consists of three different types of servers, which play an integral role in the entire communication process of the VoIP system:

• Proxy server Is used to relay packets within a network between the UACs and the UAS. It also forwards requests generated by callers to their respective recipients. Proxy servers are also generally used for name mapping, which allows the proxy server to interlink an external SIP system to an internal SIP client.

• Registrar server Keeps a centralized record of the updated locations of all the users on the network. These addresses are stored on a location server.

• Redirect server Allows SIP devices to retain their SIP identities despite changes in their geographic location. This allows a device to remain accessible when its location is physically changed and hence while it moves through different networks. The use of redirect servers allows clients to remain within reach while they move through numerous network coverage zones. This configuration is generally known as an intraorganizational configuration. Intraorganizational routing enables SIP traffic to be routed within a VoIP network without being transmitted over the PSTN or external network.

IP Telephony Issues

VoIP’s integration with the TCP/IP protocol has brought about some security challenges because it allows threat actors to leverage their TCP/IP experience to probe for flaws in both the architecture and the implementation of VoIP systems. Also involved are the traditional security issues associated with networks, such as unauthorized access, exploitation of communication protocols, and the spreading of malware. The promise of financial benefit derived from stolen call time is a strong incentive for most attackers. In short, the VoIP telephony network faces all the flaws that traditional computer networks have faced, plus the ones from legacy telephone systems too.

SIP-based signaling suffers from the lack of encrypted call channels and authentication of control signals. Attackers can tap into the SIP server and client communication to sniff out login IDs, passwords/PINs, and phone numbers. Once an attacker gets a hold of such information, she can use it to place unauthorized calls on the network. Toll fraud is considered to be the most significant threat that VoIP networks face, but illicit surveillance is also a threat for some organizations. If attackers are able to intercept voice packets, they may eavesdrop on ongoing conversations.

Attackers can also masquerade identities by redirecting SIP control packets from a caller to a forged destination to mislead the caller into communicating with an unintended end system. Like in any networked system, VoIP devices are also vulnerable to DoS attacks. Just as attackers would flood TCP servers with SYN packets on an IP network to exhaust a device’s resources, attackers can flood RTP servers with call requests in order to overwhelm its processing capabilities. Attackers have also been known to connect laptops simulating IP phones to the Ethernet interfaces that IP phones use. These systems can then be used to carry out intrusions and DoS attacks. Attackers can also intercept RTP packets containing the media stream of a communication session to inject arbitrary audio/video data that may be a cause of annoyance to the actual participants.

Attackers can also impersonate a server and issue commands such as BYE, CHECKSYNC, and RESET to VoIP clients. The BYE command causes VoIP devices to close down while in a conversation, the CHECKSYNC command can be used to reboot VoIP terminals, and the RESET command causes the server to reset and reestablish the connection, which takes considerable time.

Combating VoIP security threats requires a well-thought-out infrastructure implementation plan. With the convergence of traditional and VoIP networks, balancing security while maintaining unconstrained traffic flow is crucial. VoIP calls can (and probably should) be encrypted over TLS. The use of authorization on the network is also an important step in limiting the possibilities of rogue and unauthorized entities on the network. Authorization of individual IP terminals ensures that only prelisted devices are allowed to access the network. Although not absolutely foolproof, this method can prevent rogue devices from connecting and flooding the network with illicit packets.

The use of secure cryptographic protocols such as TLS ensures that all SIP packets are conveyed within an encrypted and secure tunnel. The use of TLS can provide a secure channel for VoIP client/server communication and prevents the possibility of eavesdropping and packet manipulation.

Multimedia Collaboration

The term multimedia collaboration is very broad and includes remotely sharing any combination of voice, video, messages, telemetry, and files during an interactive session. The term encompasses conferencing applications like Zoom, WebEx, and Google Meetings but also many other applications in disciplines such as project management, e-learning, science, telemedicine, and military. What distinguishes multimedia collaboration applications is their need to simultaneously share a variety of data formats, each of which has different loss, latency, jitter, and bandwidth requirements. Of course, as we work to meet these performance requirements and allow maximum participation from authorized users (potentially around the world), we also have to ensure the security of this communication channel.

Meeting Applications

Imagine this scenario: You are hosting an online leadership meeting with your international partners to discuss the year ahead. Suddenly, a participant with a name you don’t recognize starts sharing pornographic images and hate speech for all to see. You’ve just been “Zoom-bombed.” (A term that doesn’t necessarily mean you were using that particular platform.) This is what happens when access controls to your online meeting are inadequate. Many naïve users of meeting applications simply share a link with their guests, usually via e-mail or some other messaging application. Anyone with that link could then join the call if other precautions aren’t taken.

The rise in popularity of meeting applications and their increased importance to the business of our organizations have put them in the crosshairs of a wide range of attackers beyond the Zoom-bombing troll we described. To prevent these attacks, consider the following best practices for securing online meeting applications:

• Don’t use consumer-grade products. There is much wisdom in the old adage “you get what you pay for.” Consumer-grade products are much cheaper than enterprise-grade ones (or even free), but they lack most security controls that we need to secure our organizational meetings.

• Use AES 256-bit encryption. It is rare to be able to support true end-to-end encryption for online meetings because most service providers need access to the traffic for things like recording, closed captioning, and echo cancelation. Still, you should ensure all call traffic is encrypted between each participant and the service provider.

• Control access to every meeting. Enterprise-grade conferencing services can integrate with your identity and access management service to ensure strong authentication. Failing that, ensure that, at a minimum, each meeting is password-protected.

• Enable the waiting room feature, particularly for external participants. Many services place participants in a virtual waiting room when they sign in to the meeting until the host lets them in. This gives you an opportunity to screen each participant prior to allowing them to join. At a minimum, ensure participants cannot connect to the call before the host does.

• Restrict participants’ sharing of their screens or cameras as appropriate. This is particularly important when the meeting involves external parties such as partners or clients. While cameras may be desirable for a variety of reasons, it is rare for all participants to need unfettered screen sharing. Either way, ensure this is a deliberate decision by the host or organizer and enforceable by the platform.

• Keep your software updated. Online meeting software is no different than any other in the need for patch and update management. Even if you don’t use dedicated clients and use web browsers to connect, you should ensure whatever you use is up to date.

• Don’t record meetings unless necessary. It is helpful to record meetings, particularly when some participants cannot join in real time and must watch it later. However, the recordings can contain sensitive data that could be stolen or lead to other types of liability. If you do record the meeting, ensure it is for good reasons and that the recorded data is encrypted.

• Know how to eject unwanted participants. If you do get Zoom-bombed, that is not the time to figure out how to eject (and lock out) an offending participant. Ensure all hosts know how to do this beforehand and, while they’re at it, learn also how to mute their microphones (and cameras) if needed.

Unified Communications

While meeting applications like videoconferencing systems have received a lot of attention recently, there is a broader application of multimedia collaboration services known as unified communications (UC). UC is the integration of real-time and non-real-time communications technologies in one platform. Real-time communications are those that are instantaneous and interactive, such as telephone and video conferencing. Non-real-time communications, on the other hand, don’t require our immediate attention and are exemplified by technologies such as e-mail and text messaging. The whole point of UC is that it integrates multiple modes of communication, as shown in Figure 15-4.

Figure 15-4 Unified communications components

One of the key features of UC is the concept of presence information, which is an indicator of a subject’s availability and willingness to communicate. If you have ever used a platform like Slack or Microsoft Teams, you will have noticed the presence icon next to your teammates. It may show that they are available, sleeping, on a call, or on a meeting. Presence information allows you to choose how to interact with your colleagues. If you need to get a message to Mohammed, who happens to be in a meeting, you can send him a text message. If, on the other hand, you see that Carmen is available, you may want to reach out to her on a voice or video call. Presence information can also show where in the world your colleagues are. For example, if you want to meet Bob and notice that he happens to be in the same city as you are, you may opt for a face-to-face meeting request.

Securing UC involves similar security controls that we would apply to any other communications platform, but with a couple of important caveats. For starters, UC relies on centralized data and access controls. This means that, whether your organization hosts its services on premises or in the cloud, there is a hub that supports and enables them. You want to ensure that this hub is adequately protected against physical and logical threats. Obviously, you want to protect your data, whether at rest or in motion, with strong encryption, but this will only get you so far if you allow anyone to access it. Consequently, you want to apply strict access controls that still allow the business processes to run efficiently. Finally, you want to ensure that demand spikes don’t cause self-inflicted denial-of-service conditions. Instead, ensure that you have enough spare capacity to handle these inevitable (if rare) spikes.

Remote Access

Remote access covers several technologies that enable remote and home users to connect to resources that they need to perform their tasks. Most of the time, these users must first gain access to the Internet through an ISP, which sets up a connection to the destination network. For many organizations, remote access is a necessity because it enables users to access centralized network resources; it reduces networking costs by using the Internet as the access medium instead of expensive dedicated lines; and it extends the workplace for employees to their home computers, laptops, and mobile devices. Remote access can streamline access to resources and information through Internet connections and provides a competitive advantage by letting partners, suppliers, and customers have closely controlled links.

VPN

We discussed VPNs in Chapter 13 as a general concept, but let’s circle back and see how to best employ them to provide secure remote connectivity for our staff members. VPNs are typically implemented using a client application that connects to a VPN server (commonly called a concentrator) in our organization. In a perfect world, you would have enough bandwidth and concentrator capacity to ensure all your remote staff members can simultaneously connect over the VPN. Then, you could enforce always-on VPN, which is a system configuration that automatically connects the device to the VPN with no user interaction. Obviously, this would only be possible with devices owned by the organization, but it can provide strong access controls if properly implemented. For even better results, you can implement a VPN kill switch, which automatically cuts off Internet access unless a VPN session is established.

Alas, things are usually a bit more complicated. Perhaps you don’t have enough VPN capacity for your entire workforce, or you allow use of personal devices. If you cannot implement always-on VPN, the next best thing is to ensure you use multifactor authentication (MFA) and network access control (NAC). NAC is particularly important because you want to be able to check that the user device is safe before allowing it to access your corporate network. Since not everyone will be connecting to the VPN, you want to ensure that remote users have access to the resources they need and no others, possibly by putting them on the right VLANs and ensuring you have the right access control lists (ACLs) in your internal routers.

Regardless, you want to ensure your VPN systems (clients and concentrators) are updated and properly configured. Many clients allow you to select the cryptosystem to use, in which case you want to select the strongest option you can. Finally, carefully consider whether you will allow split tunnels.

A VPN split tunnel is a configuration that routes certain traffic (e.g., to the corporate data center) through the VPN while allowing other traffic (such as web searches) to access the Internet directly (without going through the VPN tunnel). The advantage of this approach is that users will be less likely to experience latency induced by an overworked concentrator. It also allows them to print to their local printer at home while on VPN. The disadvantage is that, should they pick up malware or otherwise become compromised on the Internet, the adversary will automatically get a free ride into your corporate network through the VPN. To prevent this from happening, you can enforce a VPN full tunnel, which routes all traffic through the concentrators.

VPN Authentication Protocols

While we’re talking about VPN configuration, let’s go over some of the authentication protocols you may come across, so you know what each brings to the table.

PAP

The Password Authentication Protocol (PAP) is used by remote users to authenticate over Point-to-Point Protocol (PPP) connections such as those used in some VPNs. PAP requires a user to enter a password before being authenticated. The password and the username credentials are sent over the network to the authentication server after a connection has been established via PPP. The authentication server has a database of user credentials that are compared to the supplied credentials to authenticate users. PAP is one of the least secure authentication methods because the credentials are sent in cleartext, which renders them easy to capture by network sniffers. PAP is also vulnerable to man-in-the-middle attacks. Although this protocol is not recommended for use anywhere, some (improperly configured) systems can revert to PAP if they cannot agree on any other authentication protocol.

CHAP

The Challenge Handshake Authentication Protocol (CHAP) addresses some of the vulnerabilities found in PAP. It uses a challenge/response mechanism to authenticate the user instead of having the user send a password over the wire. When a user wants to establish a PPP connection and both ends have agreed that CHAP will be used for authentication purposes, the user’s computer sends the authentication server a logon request. The server sends the user a challenge (called a nonce), which is a random value. This challenge is encrypted with the use of a predefined password as an encryption key, and the encrypted challenge value is returned to the server. The authentication server also uses the predefined password as an encryption key and decrypts the challenge value, comparing it to the original value sent. If the two results are the same, the authentication server deduces that the user must have entered the correct password and grants authentication. The steps that take place in CHAP are depicted in Figure 15-5. Unlike PAP, CHAP is not vulnerable to man-in-the-middle attacks because it continues this challenge/response activity throughout the connection to ensure the authentication server is still communicating with a user who holds the necessary credentials.

Figure 15-5 CHAP uses a challenge/response mechanism instead of having the user send the password over the wire.

EAP

The Extensible Authentication Protocol (EAP) is also supported by PPP. Actually, EAP is not a specific authentication protocol as are PAP and CHAP. Instead, it provides a framework to enable many types of authentication techniques to be used when establishing network connections. As the name states, it extends the authentication possibilities from the norm (PAP and CHAP) to other methods, such as one-time passwords, token cards, biometrics, Kerberos, digital certificates, and future mechanisms. So when a user connects to an authentication server and both have EAP capabilities, they can negotiate between a longer list of possible authentication methods.

There are many different variants of EAP, as shown in Table 15-1, because EAP is an extensible framework that can be morphed for different environments and needs.

Table 15-1 EAP Variants

Desktop Virtualization

Desktop virtualization technologies allow users to remotely interact with computers as if they were physically using them. In essence, these technologies present a virtual copy of a desktop that is running on some computer (physical or virtual) somewhere else in the network. IT staff frequently use desktop virtualization to manage rack-mounted servers (without having to attach a monitor, keyboard, and mouse to each), to log into jump boxes, and to manage and troubleshoot user workstations. In some organizations, remote desktop solutions allow staff to work from home and, through their personal devices, securely use an organizational computer. The upside of desktop virtualization is that the asset is protected by the organization’s security architecture but still is accessible from almost anywhere. There are two main approaches to desktop virtualization: remote desktops and virtual desktop infrastructure.

Remote Desktops

Two of the most common approaches to providing remote desktops are Microsoft’s Remote Desktop Protocol (RDP) and the open-source Virtual Network Computing (VNC) system. At a high level, both are very similar. They both require that a special server is running on the computer that will be controlled remotely and that the remote device has a software client installed and connected to the server, by default over port 3389 for RDP and 5900 for VNC. Although there are clients and servers for every major operating system, RDP is more common in Windows environments and VNC is more common in Linux environments.

The most important security consideration when deploying either RDP or VNC is to ensure that the connections are encrypted. Neither of these systems has robust security controls, so you have to tunnel them over a secure channel. If you are providing this service to remote users outside your organizational network, then you should ensure they are connected to the VPN. Having external RDP or VNC servers is a recipe for a security disaster, so their corresponding ports should be blocked at your firewall.

One of the advantages or disadvantages (depending on how you look at it) of RDP and VNC is that they allow a client to remotely control a specific computer. That computer must be provisioned somewhere on the network, specifically configured to allow remote access, and then must remain available. If it is powered off or is otherwise unavailable, there is nothing to remotely control.

Virtual Desktop Infrastructure

By combining virtualization and remote desktop technologies, we can create an environment in which users access the desktops of virtual machines (VMs) that look and behave exactly as the users have configured them, but that can be spun up or down, migrated, wiped, and re-created centrally as needed. Virtual desktop infrastructure (VDI) is a technology that hosts multiple virtual desktops in a centralized manner and makes them available to authorized users. Each virtual desktop can be directly tied to a VM (very similarly to the remote desktops described in the previous section) or can be a composite of multiple virtual components, such as a desktop template combined with virtual applications running on multiple different VMs. This flexibility allows organizations to tailor desktops to specific departments, roles, or even individuals in a scalable and resource-effective manner.

VDI deployments can be either persistent or nonpersistent. In a persistent VDI, a given user connects to the same virtual desktop every time and is able to customize it as allowed by whatever organizational policies are in place. In a persistent model, users’ desktops look the same at the beginning of one session as they did at the end of the last one, creating continuity that is helpful for long-term use and for complex workflows. By contrast, users of a nonpersistent VDI are presented with a standard desktop that is wiped at the end of each session. Nonpersistent infrastructures are useful when providing occasional access for very specific purposes or in extremely secure environments.

VDI is particularly helpful in regulated environments because of the ease with which it supports data retention, configuration management, and incident response. If a user’s system is compromised, it can quickly be isolated for remediation or investigation, while a clean desktop is almost instantly spawned and presented to the user, reducing the downtime to seconds. VDI is also attractive when the workforce is highly mobile and may log in from a multitude of physical devices in different locations. Obviously, this approach is highly dependent on network connectivity. For this reason, organizations need to consider carefully their own network speed and latency when deciding how (or whether) to implement it.

Secure Shell

We don’t always need a graphical user interface (GUI) to interact with our devices. In fact, there are many advanced use cases in which users, especially experienced and administrative ones, are more productive using a command-line interface (CLI). The tool of choice in many of these cases (particularly in Linux environments) is Secure Shell (SSH), which functions as a type of tunneling mechanism that provides terminal-like access to remote computers. SSH is the equivalent of remote desktops but without the GUI. For example, the program can let Paul, who is on computer A, access computer B’s files, run applications on computer B, and retrieve files from computer B without ever physically touching that computer. SSH provides authentication and secure transmission over vulnerable channels like the Internet.

SSH should be used instead of Telnet, FTP, rlogin, rexec, or rsh, which provide the same type of functionality SSH offers but in a much less secure manner. SSH is a program and a set of protocols that work together to provide a secure tunnel between two computers. The two computers go through a handshaking process and exchange (via Diffie-Hellman) a session key that will be used during the session to encrypt and protect the data sent. The steps of an SSH connection are outlined in Figure 15-6.

Figure 15-6 SSH is used for remote terminal-like functionality.

Once the handshake takes place and a secure channel is established, the two computers have a pathway to exchange data with the assurance that the information will be encrypted and its integrity will be protected.

Data Communications

Up to this point in this chapter, we’ve been focused on communications channels used by users. It is probably a good idea to also consider machine to machine data communications. Recall from Chapter 7 that there are multiple system architectures that require quite a bit of backend chatter between system components. For example, in an n-tier architecture, you may have an application server communicating quite regularly with a database. We must also map out and secure all these not-so-obvious data communications channels.

Network Sockets

A network socket is an endpoint for a data communications channel. A socket is a layer 4 (transport) construct that is defined by five parameters: source address, source port, destination address, destination port, and protocol (TCP or UDP). At any given time, a typical workstation has dozens of open sockets, each representing an existing data communications channel. (Servers can have thousands or even tens of thousands of them.) Each of these channels represents an opportunity for an attacker to compromise our systems. Do you know what all your data channels are?

This is one of the reasons why understanding our systems architectures is so critical. Many systems use default installation configurations that are inherently insecure. In addition to the proverbial (weak) default password, a brand-new server probably includes a number of services that are not needed and could provide an open door to attackers. Here are some best practices for securing sockets-based communications channels:

• Map out every authorized data communications channel to and from each server.

• Apply ACLs to block every connection except authorized ones.

• Use segmentation to ensure servers that communicate with each other regularly are in the same network segment.

• Whenever possible, encrypt all data communications channels.

• Authenticate all connection requests.

One of the challenges of securing data communications channels is that they rely on service accounts that usually run with elevated privileges. Oftentimes, these service accounts are excluded from the password policies that are enforced for user accounts. As a result, service account passwords are seldom changed and sometimes are documented in an unsecure manner. For example, we know of organizations that keep a list of their service accounts and passwords on a SharePoint or Confluence page for their IT team. These passwords should be protected just like any other privileged account and securely stored in a password vault.

Remote Procedure Calls

Moving up one level to the session layer (layer 5), a remote procedure call (RPC) allows a program somewhere in your network to execute a function or procedure on some other host. RPC is commonly used in distributed systems because it allows systems to divide larger tasks into subtasks and then hand those subtasks to other systems. Although the IETF defined an RPC protocol for Open Network Computing (ONC), the RPC concept can take many different forms in practice. In most networks (especially Windows ones), RPC services listen on TCP port 135. RPC use is ubiquitous in many enterprise environments because it is so powerful. However, by default, it doesn’t provide any security beyond basic authentication.

If your organization uses RPC, then you should really consider upgrading its security. Secure RPC (S-RPC) provides authentication of both users and hosts as well as traffic encryption. As of February 9, 2021, Windows Active Directory (AD) systems require S-RPC. The IETF also released a standard for RPC security (RPCSEC) years ago, but because it is difficult to implement, it was never widely adopted. Instead, many organizations require TLS for authenticating hosts and encrypting RPC traffic. Other, vendor-specific implementations of RPC security exist, so you should research whatever versions are being used in your environment and ensure they are secure.

Virtualized Networks

A lot of the network functionality we have covered in this chapter can take place in virtual environments. You should remember from our coverage of virtual machines (VMs) in Chapter 7 that a host system can have virtual guest systems running on it, enabling multiple operating systems to run on the same hardware platform simultaneously. But the industry has advanced much further than this when it comes to virtualized technology. Routers and switches can be virtualized, which means you do not actually purchase a piece of hardware and plug it into your network, but instead you deploy software products that carry out routing and switching functionality. Obviously, you still need a robust hardware infrastructure on which to run the VMs, but virtualization can save you a lot of money, power, heat, and physical space.

These VMs, whether they implement endpoints or networking equipment, communicate with each other over virtual networks that behave much like their real counterparts, with a few exceptions. In order to understand some of these, let us first consider the simple virtual infrastructure shown in Figure 15-7. Let’s suppose that VM-1 is an endpoint (perhaps a server), VM-2 is a firewall, and VM-3 is an IDS on the external side of the firewall. Two of these devices (VM-1 and VM-3) have a single virtual NIC (vNIC), while the other one (VM-2) has two vNICs. Every vNIC is connected to a virtual port on a virtual switch. Unlike the real world, any data that flows from one vNIC to another vNIC is usually just copied from one memory location (on the physical host) to another; it only pretends to travel the virtual network.

Figure 15-7 Virtualized networks

The single physical NIC in our example is connected to vSwitch-2, but it could just as easily have been directly connected to a vNIC on a VM. In this virtual network, VM-2 and VM-3 have connectivity to the physical network but VM-1 does not. The hypervisor stores in memory any data arriving at the physical NIC, asks the virtual switch where to send it, and then copies it into the memory location for the intended vNIC. This means that the hypervisor has complete visibility over all the data traversing its virtualized networks, whether or not it touches the physical NIC.

It should come as no surprise that one of the greatest strengths of virtualization, the hypervisor, is potentially also its greatest weakness. Any attacker who compromises the hypervisor could gain access to all virtualized devices and networks within it. So, both the good and the bad guys are intensely focused on finding any vulnerabilities in these environments. What should you do to ensure the security of your virtualized networks and devices? First, just as you should do for any other software, ensure you stay on top of any security patches that come out. Second, beware of third-party add-ons that extend the functionality of your hypervisor or virtual infrastructure. Ensure these are well tested and acquired from reputable vendors. Last, ensure that whoever provisions and maintains your virtualized infrastructure is competent and diligent, but also check their work. Many vulnerabilities are the result of misconfigured systems, and hypervisors are no different.

Third-Party Connectivity

We can’t wrap up our discussion of securing the multitude of communications channels in our systems without talking about third parties. In Chapter 2, we covered the risks that third parties bring to our organizations and how to mitigate them. These third parties cover a broad spectrum that includes suppliers, service providers, and partners. Each of them may have legitimate needs to communicate digitally with our organizations, potentially in an automated manner. How can we provide this required connectivity to third parties without sacrificing our security? The answer can be found by applying the secure design principles we’ve been revisiting throughout the book:

• Threat modeling   Always start by identifying the threats. What might malicious (or just careless) third parties be able to do with the communications channels we provide that would cause us harm? What are their likeliest and most dangerous actions? This deliberate exercise in understanding the threats is foundational.

• Least privilege   Third parties will have legitimate connectivity requirements that we should minimally provide. If a contractor needs to monitor and control our HVAC systems remotely, we should segment those systems on the same VLAN and ensure that only specific calls from specific hosts to specific devices are allowed, and nothing more.

• Defense in depth   Based on the threat model, we put in place controls to mitigate risks. But what happens if the first layer of controls fails to contain the threat? If that HVAC contractor is compromised in an island-hopping attack and the adversary is able to escape the VLAN, how do we detect the breach and then contain the attack?

• Secure defaults   While ensuring that default configurations are secure is generally a best practice, it is particularly important on systems that will be used by third parties. One of the keys here is to enforce strict configuration management. For any system that will be accessible by a third party, we must ensure that all defaults are secure by testing them.

• Fail securely   Speaking of testing, we should test the system under a range of conditions to see what happens when it breaks. For example, stress testing (under heavy usage loads), fuzzing, and power and network failure testing can show us what happens when a system fails. This is not specific to third-party systems, by the way.

• Separation of duties   Giving third parties the least privileges needed actually makes separating duties easier. For example, it may be that the HVAC contractor does not normally start or stop the furnace, but this may be occasionally required. Because this can have an impact on our facility, the action must be approved by our site manager.

• Keep it simple   This principle is centered on the statement of work (SoW) that describes the agreement with the third party and in the processes we build to support that work. A policy of “deny by default, allow by exception” can keep things simple, supports the least-privilege principle, and should be paired with a simple process for handling exceptions.

• Zero trust   It goes without saying that we should not trust third parties when it comes to access to our systems. For every interaction of third parties with our systems, we must ensure that authentication, nonrepudiation, and audit controls are sufficient to detect and mitigate any threat (deliberate or otherwise) that they introduce into our environments.

• Privacy by design   If we use this principle to guide the development of our entire security architecture (and we really ought to), then we really shouldn’t have to do anything else to account for third parties using our systems, particularly if we couple privacy with least privilege in the first place.

• Trust but verify   We already talked about auditability in the context of zero trust, but there is a difference between logging activities and analyzing those logs periodically (or even continually). What is the process by which our security staff verifies that the actions of third parties are appropriate? How are suspicious or malicious activities handled?

• Shared responsibility   Finally, who is contractually responsible for what? As the saying goes, “good fences make good neighbors.” It is important to define responsibilities in the service or partnership agreement so that there are no misunderstandings and, should someone fail, we can take financial or legal actions to recover our losses.

Chapter Review

With this chapter, we have finished our coverage of the fourth domain of the CISSP Common Body of Knowledge, Communication and Network Security, by discussing the myriad of technologies that allow us to create secure communications channels in our organizations. Though most people (particularly in the technology fields) would not consider voice to be their primary means of communication, it remains important for many reasons, not the least of which is the fact that traditional voice channels are more commonly used nowadays for digital data traffic. It is important to understand how these technologies blend in different ways so that we can better secure them.

The COVID-19 pandemic forced most organizations around the world to quickly move toward (or improve their ability at) supporting a remote workforce largely based in home offices. While the news media regularly featured stories on the vulnerabilities and attacks on our multimedia collaboration and remote access systems, it is remarkable how well these held up to the sudden increase in use (and attacks). We hope that this chapter has given you a better understanding of how security professionals can continue to improve the security of these systems while supporting a remote workforce and third-party connectivity.

Quick Review

• The public switched telephone network (PSTN) uses circuit switching instead of packet routing to connect calls.

• The Signaling System 7 (SS7) protocol is used for establishing and terminating calls in the PSTN.

• The main components of a PSTN network are signal switching points (SSPs) that terminate subscriber loops, signal transfer points (STPs) that interconnect SSPs and other STPs to route calls through the network, and service control points (SCPs) that control advanced features.

• A digital subscriber line (DSL) is a high-speed communications technology that simultaneously transmits analog voice and digital data between a home or business and a PSTN service provider’s central office.

• Asymmetric DSL (ADSL) has data rates of up to 24 Mbps downstream and 1.4 Mbps upstream but can only support distances of about a mile from the central office without signal boosters.

• Very high-data-rate DSL (VDSL) is a higher-speed version of ADSL (up to 300 Mbps downstream and 100 Mbps upstream).

• G.fast is DSL that runs over fiber-optic cable from the central office to a distribution point near the home and then uses legacy copper wires for the last few hundred feet to the home or office. It can deliver data rates of up to 1 Gbps.

• Integrated Services Digital Network (ISDN) is an obsolescent pure digital technology that uses legacy phone lines for both voice and data.

• Basic Rate Interface (BRI) ISDN is intended to support a single user with two channels each with data throughput of 64 Kbps.

• Primary Rate Interface (PRI) ISDN has up to 23 usable channels, at 64 Kbps each, which is equivalent to a T1 leased line.

• Cable modems provide high-speed access to the Internet through existing cable coaxial and fiber lines, but the shared nature of these media result in inconsistent throughputs.

• Internet Protocol (IP) telephony is an umbrella term that describes carrying telephone traffic over IP networks.

• The terms “IP telephony” and “Voice over IP” are used interchangeably.

• Jitter is the irregularity in the arrival times of consecutive packets, which is problematic for interactive voice and video communications.

• The H.323 recommendation is a standard that deals with audio and video calls over packet-based networks.

• The Session Initiation Protocol (SIP) is an application layer protocol used for call setup and teardown in IP telephony, video and multimedia conferencing, instant messaging, and online gaming.

• The Real-time Transport Protocol (RTP) is a session layer protocol that carries data in media stream format, as in audio and video, and is used extensively in VoIP, telephony, video conferencing, and other multimedia streaming technologies.

• RTP Control Protocol (RTCP) is used in conjunction with RTP and is also considered a session layer protocol. It provides out-of-band statistics and control information to provide feedback on QoS levels of individual streaming multimedia sessions.

• Multimedia collaboration is a broad term that includes remotely and simultaneously sharing any combination of voice, video, messages, telemetry, and files in an interactive session.

• Telepresence is the application of various technologies to allow people to be virtually present somewhere other than where they physically are.

• Unified communications (UC) is the integration of real-time and non-real-time communications technologies in one platform.

• An always-on VPN is a system configuration that automatically connects the device to the VPN with no user interaction.

• A VPN kill switch is a system configuration that automatically cuts off Internet access unless a VPN session is established.

• A VPN split tunnel is a configuration that routes certain traffic through the VPN while allowing other traffic to access the Internet directly.

• The Password Authentication Protocol (PAP) is an obsolete and insecure authentication protocol that sends user credentials in plaintext and should not be allowed.

• The Challenge Handshake Authentication Protocol (CHAP) uses a challenge/response mechanism using the password as an encryption key to authenticate the user instead of having the user send a password over the wire.

• The Extensible Authentication Protocol (EAP) is a framework that enables many types of authentication techniques to be used when establishing network connections.

• Desktop virtualization technologies, such as remote desktops and virtual desktops, allow users to remotely interact with computers as if they were physically using them.

• Two of the most common approaches to providing remote desktops are Microsoft’s Remote Desktop Protocol (RDP) and the open-source Virtual Network Computing (VNC) system.

• Virtual desktop infrastructure (VDI) is a technology that hosts multiple virtual desktops in a centralized manner and makes them available to authorized users.

• Secure Shell (SSH) is a secure tunneling mechanism that provides terminal-like access to remote computers.

• A network socket is an endpoint for a data communications channel, defined by five parameters: source address, source port, destination address, destination port, and protocol (TCP or UDP).

• Remote procedure calls allow a program somewhere in your network to execute a function or procedure on some other host.

Questions

Please remember that these questions are formatted and asked in a certain way for a reason. Keep in mind that the CISSP exam is asking questions at a conceptual level. Questions may not always have the perfect answer, and the candidate is advised against always looking for the perfect answer. Instead, the candidate should look for the best answer in the list.

1. In which type of networks is the Signaling System 7 (SS7) protocol used?

A. Integrated Services Digital Network (ISDN)

B. IP telephony network

C. Real-time Transport Protocol (RTP) network

D. Public switched telephone network (PSTN)

2. Which of the following is true about the Session Initiation Protocol (SIP)?

A. Used to establish virtual private network (VPN) sessions

B. Framework for authenticating network connections

C. Session layer protocol for out-of-band statistics

D. Application layer protocol used in online gaming communications

3. Which of the following is not considered a best practice for securing multimedia collaboration platforms?

A. Don’t record meetings unless necessary

B. Use consumer-grade products

C. Use AES 256-bit encryption

D. Restrict participants’ sharing of their screens or cameras as appropriate

4. How could you best protect a unified communications (UC) platform?

A. Protect it as you would any other systems

B. Enable Password Authentication Protocol (PAP)

C. Use the Session Initiation Protocol (SIP) for every new session

D. Ensure the hub is protected against physical and logical threats

Use the following scenario to answer Questions 5–7. You are the CISO of a research and development company that is transitioning to a 100 percent remote workforce, so your entire staff will be working from home. You don’t have enough laptops for all your staff, so those without one will be using their personal computers and printers for work. Your VPN concentrators are sufficient to support the entire workforce, and you will be requiring all staff members to connect to the VPN.

5. Which authentication protocol would be best for your VPN connections?

A. Password Authentication Protocol (PAP)

B. Challenge Handshake Authentication Protocol (CHAP)

C. Extensible Authentication Protocol (EAP)

D. Session Initiation Protocol (SIP)

6. Which of the following additional VPN configurations should you also enable?

A. Split tunneling

B. Full tunneling

C. VPN kill switch

D. Hybrid tunneling

7. Which of the following will best protect the confidentiality of your sensitive research data?

A. Secure Shell (SSH)

B. Virtualized networks

C. Virtual desktop infrastructure (VDI)

D. Remote Procedure Calls (RPC)

8. During a recent review of your enterprise architecture, you realize that many of your mission-critical systems rely on Remote Procedure Call (RPC). What measures should you take to ensure remote procedure calls are secured?

A. Implement ITU standard H.323

B. Tunnel RPC through Transport Layer Security (TLS)

C. Use the Password Authentication Protocol (PAP) for authentication

D. Enforce client-side authentication

9. Which of the following is not an advantage of virtual desktops?

A. Reduced user downtime during incident response

B. Support for both persistent and nonpersistent sessions

C. Support for both physical and remote logins

D. Better implementation of data retention standards

Answers

1. D. The SS7 protocol is used in a PSTN to set up, control, and disconnect calls.

2. D. SIP is an application layer protocol used for call setup and teardown in IP telephony, video and multimedia conferencing, instant messaging, and online gaming.

3. B. Consumer-grade products almost always lack the security controls and management features that we need to properly secure multimedia collaboration platforms.

4. D. Securing UC involves similar security controls that we would apply to any other communications platform, but with a couple of important caveats. Unified communications rely on a central hub that integrates, coordinates, and synchronizes the various technologies. You want to ensure that this hub is adequately protected against physical and logical threats.

5. C. EAP is considered much more secure than both PAP (which is not secure at all) and CHAP. SIP does not provide authentication mechanisms at all.

6. A. Because your staff will be using printers on their home networks, you will have to enable split tunneling, which allows some traffic to be sent over the VPN and other traffic to go to the local network or to the Internet directly.

7. C. VDI allows your sensitive data to remain in your protected network even as users are able to work with it over a virtual desktop. Properly configured, this infrastructure prevents any sensitive research data from being stored on the remote user’s computer.

8. B. Since many implementations of RPC lack security controls, many organizations require TLS for authenticating hosts and encrypting RPC traffic.

9. C. VDI is particularly helpful in regulated environments because of the ease with which it supports data retention, configuration management, and incident response through persistent and nonpersistent sessions. However, since VDI relies on VMs in a data center, there is not a computer at which a user could physically log in.