CompTIA Security SY0-601 Exam: A Simple Guide To Secure Protocols

Objective: Given a scenario, implement secure protocols.

Topics:
- Domain Name System Security Extensions (DNSSEC)
- Secure Shell (SSH)
- Secure/Multipurpose Internet Mail Extensions (S/MIME)
- Secure Real-Time Transport Protocol (SRTP)
- LDAP over SSL (LDAPS)
- File Transfer Protocol, Secure (FTPS)
- SSH File Transfer Protocol (SFTP)
- Simple Network Management Protocol, version 3 (SNMPv3)
- Hypertext Transfer Protocol over SSL (HTTPS)
- Internet Protocol Security (IPsec)
- Authentication Header (AH)
- Encapsulated Security Payload (ESP)
- Secure Post Office Protocol, version 3 (POP3)
- Internet Message Access Protocol (IMAP)
The network infrastructure is subject to myriad internal and external attacks through services, protocols, and open ports. Older protocols that are still in use might leave a network vulnerable. Protocols such as Simple Network Management Protocol (SNMP) and Domain Name System (DNS) that were developed a long time ago and have been widely deployed can pose security risks, too. You must understand how to properly secure these protocols, especially if the network has been in existence for a while and newer or more secure protocols or versions have been developed. This guide helps you understand how to use the proper network implementation of secure protocols to protect and mitigate threats against network infrastructure.

Secure Web Protocols
Basic web connectivity using Hypertext Transfer Protocol (HTTP) occurs over TCP port 80. No security is provided against the interception of transacted data sent in plaintext. Web protocol security is usually implemented at two layers: the transport layer and the application layer.
To secure against web communication interception, transport layer security protocols such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are used.
A more secure way to conduct web communication involves using SSL transport protocols operating on port 443, which creates an encrypted pipe through which HTTP traffic can be conducted securely. To differentiate a call to port 80 (http://servername/), HTTP over SSL calls on port 443, using HTTPS as the URL port designator (https://servername/).
HTTPS was originally created by Netscape Corporation. It used a 40-bit RC4 stream encryption algorithm to establish a secure connection encapsulating data transferred between the client and the web server. However, it can also support the use of X.509 digital certificates to allow the user to authenticate the sender. Now 256-bit encryption keys have become the accepted level of secure connectivity for online banking and electronic commerce transactions.
An alternative to HTTPS is Secure Hypertext Transfer Protocol (S-HTTP), which was developed to support connectivity for banking transactions and other secure web communications. S-HTTP supports DES, 3DES, RC2, and RSA2 encryption, along with CHAP authentication; however, the early web browser developers (for example, Netscape and Microsoft) did not adopt it, so it remains less common than the HTTPS standard.
Although HTTPS encrypts communication between the client and the server, it doesn’t guarantee that the merchant is trustworthy or that the merchant’s server is secure. SSL/TLS is designed to positively identify the merchant’s server and encrypt communication between the client and the server. When organizations use OpenSSL, they need to use version 1.0.1g or newer to avoid being vulnerable to the Heartbleed bug. Secure Sockets Layer (SSL) protocol communications occur between the HTTP (application) and TCP (transport) layers of Internet communications.
Millions of websites use SSL to protect their online transactions with their customers. SSL is a public key–based security protocol that Internet services and clients use for authentication, message integrity, and confidentiality. The SSL process uses certificates for authentication and encryption for message integrity and confidentiality. SSL establishes a stateful connection, in which both ends set up and maintain information about a session during its existence. In contrast, in a stateless connection, no prior connection has been set up. An SSL stateful connection is negotiated through a handshaking procedure between client and server. During this handshake, the client and server exchange the specifications for the cipher that will be used for that session. SSL communicates using an asymmetric key with a cipher strength of 40 bits or 128 bits.
SSL works by establishing a secure channel using public key infrastructure (PKI). This can eliminate the vast majority of attacks, such as session hijacking and information theft. As a general rule, SSL is not as flexible as IPsec (discussed next) from an application perspective, but it is more flexible for access from any location. Organizations must determine the usage requirements for each class of user and then decide on the best approach.
The terms SSL and TLS are often used interchangeably and are denoted as SSL/TLS except when there is a need to refer to one of the protocols separately. Although the SSL protocol was deprecated with the release of TLS 1.0 in 1999, it is still common to refer to these related technologies as “SSL” or “SSL/TLS.” The current version is TLS 1.3, defined in RFC 8446.
Another asymmetric key encapsulation (currently considered the successor to SSL) is the Transport Layer Security (TLS) protocol, based on Netscape’s Secure Sockets Layer 3.0 (SSL3) transport protocol. TLS provides encryption using stronger encryption methods, such as AES. It can work without encryption altogether if it is desired for authentication only. SSL and TLS transport protocols are similar but not entirely interoperable. TLS also provides confidentiality and data integrity.

TLS has two layers of operation:
- TLS Record protocol: Allows the client and server to communicate using some form of encryption algorithm (or without encryption, if desired).
- TLS Handshake protocol: Allows the client and server to authenticate one another and exchange encryption keys to be used during the session.

Domain Name System (DNS) was originally designed as an open protocol. DNS servers are organized in a hierarchy. At the top level of the hierarchy, root servers store the complete database of Internet domain names and their corresponding IP addresses. Different types of DNS servers exist. The most common types follow:
- Authoritative servers: These servers are definitive for particular domains and provide information about only those domains. An authoritative-only name server returns answers to queries about just the domain names that have been specifically configured.
- Caching or recursive servers: These servers use recursion to resolve a given name, from the DNS root through to the authoritative name servers of the queried domain.

DNS does not check for credentials before accepting an answer, and attackers exploit this basic vulnerability. An attacker can cause DNS poisoning by delegating a false name to the domain server and providing a false address for the server. To prevent this from happening, the Domain Name System Security Extensions (DNSSEC) protocol was developed. DNSSEC protects against such attacks by providing a validation path for records.
With DNSSEC, validation is done through the use of a key and a signature. To properly validate the path, DNSSEC must be implemented at each domain level. The higher organization level signs the key of the lower domain level. For example, with the domain www.example.com, the root level signs the .com key, and the .com level signs the example.com key. DNSSEC follows the chain of trust from the lowest-level domain to the top-level domain, validating the keys at each level along the way.
DNSSEC was developed to strengthen DNS through the use of digital signatures and public key cryptography.
 

Internet Protocol Security (IPsec)

The Internet Protocol Security (IPsec) authentication and encapsulation standard is widely used to establish secure VPN communications. IPsec can secure transmissions between critical servers and clients. This helps prevent network-based attacks from taking place. Unlike most security systems that function within the application layer of the OSI model, IPsec functions within the network layer. IPsec provides authentication services and encapsulation of data through support of the Internet Key Exchange (IKE) protocol.
IPsec can be run in either tunnel mode or transport mode. Transport mode is used between endpoints such as a client and a server. It can also be used between a gateway and an endpoint when the gateway is being treated as an endpoint, such as in a Remote Desktop (RDP) session.

IPsec’s default mode is tunnel mode. Tunnel mode is most often used between gateways such as a router and a firewall. When tunnel mode is used, the gateway acts as a proxy for the hosts. In tunnel mode, an AH or ESP header is used. The asymmetric key standard defining IPsec provides two primary security services:
- AH: Authentication Header (AH) provides authentication of the data’s sender, along with integrity and nonrepudiation. RFC 2402 states that AH provides authentication for as much of the IP header as possible, as well as for upper-level protocol data. However, some IP header fields might change in transit, and when the packet arrives at the receiver, the value of these fields might not be predictable for the sender. AH cannot protect the values of such fields, so the protection it provides to the IP header is somewhat piecemeal.
- ESP: Encapsulating Security Payload (ESP) supports authentication of the data’s sender and encryption of the data being transferred, along with confidentiality and integrity protection. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an antireplay service (a form of partial sequence integrity), and limited traffic-flow confidentiality. The set of services provided depends on options selected at the time of security association establishment and on the placement of the implementation. Confidentiality can be selected independently of all other services. However, the use of confidentiality without integrity/authentication (either in ESP or separately in AH) might make the traffic subject to certain forms of active attacks that could undermine the confidentiality service.

Protocols 51 and 50 are the AH and ESP components of the IPsec protocol. IPsec inserts ESP or AH (or both) as protocol headers into an IP datagram that immediately follows an IP header.
The protocol field of the IP header is 50 for ESP or 51 for AH. If IPsec is configured to do authentication instead of encryption, you must configure an IP filter to let protocol 51 traffic pass. If IPsec uses nested AH and ESP, you can configure an IP filter to let only protocol 51 (AH) traffic pass.
IPsec supports the Internet Key Exchange (IKE) protocol, which is a key management standard used to allow separate key protocols to be specified for use during data encryption. IKE functions within Internet Security Association and Key Management Protocol (ISAKMP), which defines the payloads used to exchange key and authentication data appended to each packet.
IPsec provides secure VPN and Internet communications by authenticating and encrypting network data packets.

Secure File Transfer Protocols
File Transfer Protocol (FTP) passes a username and password in a plaintext form. Attackers can thus use packet sniffing on the network traffic to read these values and possibly use them to gain unauthorized access to the server. File Transfer Protocol Secure (FTPS, also called FTP-SSL), is an FTP extension that adds support for TLS and SSL. FTPS supports channel encryption, as defined in RFC 2228.
With FTPS, data transfers take place so that the parties can authenticate each other. It prevents eavesdropping, tampering, and forgery on the messages exchanged. FTPS includes full support for the TLS and SSL cryptographic protocols, including the use of server-side public key authentication certificates and client-side authorization certificates. In addition, FTPS supports compatible ciphers, including AES, RC4, RC2, Triple DES, and DES. It supports the hash functions SHA1, MD5, MD4, and MD2.
Secure variations of FTP ensure that data cannot be intercepted during transfer and allow the use of more secure transfer of user access credentials during FTP logon. SSH File Transfer Protocol (SFTP) uses Secure Shell (SSH) to transfer files. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in plaintext over the network. It is functionally similar to FTP but uses a different protocol. Therefore, a standard FTP client cannot talk to an SFTP server, nor can an FTP server connect to a client that supports only SFTP. SFTP is similar to the secure copy protocol (SCP) in that they both securely transfer files between hosts using SSH. While SCP is more efficient, it does not provide the remote function capabilities of SFTP such as the ability to remove files or perform a directory listing.
A more secure version of FTP (SFTP) has been developed that includes SSL encapsulation. This version is also referred to as FTP over SSH. It uses the Secure Shell (SSH) TCP port 22.
Do not confuse SFTP (SSH File Transfer Protocol) with FTPS (FTP Secure). FTPS uses more than one port and can be either implicit or explicit. FTPS (Implicit) uses TCP port 990 for commands and uses passive ports for data. FTPS (Explicit) uses TCP port 21 for commands and uses passive ports for data. Either SFTP or FTPS can be used in an enterprise network.

Secure Email Protocols

The Multipurpose Internet Mail Extensions (MIME) protocol extended the capability of the original Simple Mail Transfer Protocol (SMTP) to allow the inclusion of non-textual data within an email message. Embedding data within an email message is an easy way to send images, audio and video files, and many other types of non-ASCII text. To provide a secure method of transmission, the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol was developed. S/MIME is a widely accepted technology for sending digitally signed and encrypted messages that provides authentication, message integrity, and nonrepudiation. S/MIME is based on the following standards:
- Asymmetric cryptography, using the algorithms RSA, DSA, or elliptic curve
- Symmetric cryptography, using Advanced Encryption Standard (AES)
- Cryptographic Message Syntax, which provides the underlying key security
(For more detailed information on how asymmetric and symmetric cryptography works, refer to  “Cryptographic Concepts.”)

When S/MIME is used to secure email, the technology behind it increases security and verifies that the message received is the exact message sent.
Other email protocols, such as Post Office Protocol, version 3 (POP3) and Internet Message Access Protocol (IMAP), can also be used in a more secure way. One of the biggest security issues with POP and IMAP is that login credentials are transmitted in plaintext over unencrypted connections. Keep in mind that POP3 and IMAP are used for retrieving email, whereas SMTP, over port 25, is used for sending email. In secure POP3 or IMAP mail, the communication occurs over an SSL/TLS session, which mitigates this insecurity. Encrypting mail during transmission protects the communication and makes reading the email more difficult for an attacker. Because a certificate is used to verify the identity of the server to the client, the connection fails if a valid certificate is not present.
Using POP3S (port 995) or IMAPS (port 993) allows the incoming data from the client to be encrypted because these protocols use an SSL/TLS session. SMTP is for outgoing email.
The ports used by secure versions of protocols differ from the ports used by insecure protocols. POP3 communicates over port 110, while POP3S uses port 995. IMAP communicates over port 143, while IMAPS uses port 993. Many sites disable IMAP and POP3 completely, forcing the use of an SSL/TLS-encrypted connection.

Secure Internet Protocols
The web, email, and file transfer are three of the most common applications used over the Internet. In addition to the protocols discussed earlier in this guide, this section covers several other general Internet protocols you should be familiar with.
As a more secure replacement for the common command-line terminal utility Telnet, the Secure Shell (SSH) utility establishes a session between a client and host computers, using an authenticated and encrypted connection. SSH requires encryption of all data, including the login portion. SSH uses the asymmetric (public key) RSA cryptography method to provide both connection and authentication.

Data encryption is accomplished using one of the following algorithms:
- International Data Encryption Algorithm (IDEA): The default encryption algorithm used by SSH, which uses a 128-bit symmetric key block cipher.
- Blowfish: A symmetric (private key) encryption algorithm that uses a variable 32- to 448-bit secret key.
- Data Encryption Standard (DES): A symmetric key encryption algorithm using a random key selected from a large number of shared keys. Most forms of this algorithm cannot be used in products meant for export from the United States.
- Triple Data Encryption Standard (3DES): A symmetric key encryption algorithm that dramatically improves upon the DES by using the DES algorithm three times with three distinct keys.
Using SSH helps guard against attacks such as eavesdropping, man-in-the-middle attacks, and spoofing. Attempts to spoof the identity of either side of a communication can be thwarted because each packet is encrypted using a key known only by the local and remote systems.
Some versions of SSH, including Secure Shell for Windows Server, provide a secure version of File Transfer Protocol (SFTP) along with the other common SSH utilities.

Lightweight Directory Access Protocol (LDAP)
Lightweight Directory Access Protocol (LDAP) is a directory services protocol used on IP networks. By default, LDAP traffic is unsecured; that is, attackers can use network-monitoring programs to view LDAP traffic, including Active Directory (AD)–associated services that use LDAP for authentication. Encryption is recommended when LDAP is used over a network that is not secure.
LDAP over SSL (LDAPS) is used to secure Lightweight Directory Access Protocol (LDAP) by enabling communication over SSL/TLS.

As with web, mail, and FTP protocols, LDAPS uses SSL/TLS to establish an encrypted tunnel to prevent traffic from being read. With LDAPS, the encrypted tunnel occurs between an LDAP client and a Windows AD domain controller. This is the process used for LDAPS communication:
An LDAP session is started between a client and the LDAP server, commonly referred to as the Directory System Agent (DSA) on default port 636. The Global Catalog is accessed via port 3269.
The server sends a client operation request response. The various requests a client can make include bind, search, and entry editing.
The DSA is the database that stores information hierarchically for easy retrieval. Information is encoded pursuant to the Basic Encoding Rules (BER) used by X.500 directories and is specified in RFC 4522.

Secure Real-Time Transport Protocol (SRTP)

Real-Time Transport Protocol (RTP) is used for video and audio communications on IP networks. As with many of the other protocols discussed previously, the design is inherently insecure, allowing for eavesdropping and communication interception. Support for RTP encryption in service provider gateways is lacking because of the inherent design. It is not possible to provide privacy and security for calls that go over the public switched telephone network (PSTN). The most common use of RTP is for VoIP. VoIP network communications are subject to the same attacks as other Internet communication methods.
Secure Real-Time Transport Protocol (SRTP or Secure RTP) is an extension to RTP that incorporates enhanced security features. As with RTP, it is intended particularly for voice over IP (VoIP) or video network communications.
SRTP adds confidentiality, message authentication, and replay protection to the communication exchange. UDP is still used as the RTP transport protocol, but keys are exchanged to enable encryption; this is similar to the HTTPS process used for secure web mail.

Simple Network Management Protocol (SNMP)

SNMP is an application layer protocol whose purpose is to collect statistics from TCP/IP devices. SNMP is used to monitor the health of network equipment, computer equipment, and devices such as uninterruptible power supplies (UPSs).

Simple Network Management Protocol, version 3 (SNMPv3) is the current standard, but some devices still use SNMPv1 or SNMPv2. The SNMP management infrastructure consists of three components:
- SNMP managed node
- SNMP agent
- SNMP network management station

The device loads the agent, which collects the information and forwards it to the management station. Network management stations collect a massive amount of critical network information and are likely to be targets of intruders. Using SNMP can help malicious users learn a lot about a system.
Many of the vulnerabilities associated with SNMP stem from using SNMPv1. Although these vulnerabilities were discovered many years ago, vulnerabilities are still being reported with current SNMP components. The only security measure SNMPv1 has in place is its community name, which is similar to a password. By default, the community name is public and often is not changed, thus leaving the information wide open to intruders.
SNMPv2 focused on performance more than security. One improvement was the implementation of Message Digest Algorithm 5 (MD5) for authentication between the server and the agent. SNMPv2 did not provide a way to authenticate the source of a management message, nor did it provide encryption. The plaintext password could still be sniffed from network traffic and was subject to replay attacks. SNMPv3 attempted to address the deficiencies in SNMPv2 by defining an overall SNMP architecture that included a set of security capabilities. SNMPv3 changed the structure to include access control, authentication, and privacy as a result of adding cryptographic security—specifically, support for AES and 3DES encryption.
SNMPv3 uses the same ports as SNMPv1 and SNMPv2. UDP port 161 is required for polling, and port 162 is required for notifications. SNMPv3 can also run over TCP.

SNMPv3 architecture
 

RFC 2271 defines these components of an SNMP entity:
- Dispatcher: Allows for concurrent support of multiple versions of SNMP messages
- SNMP message processing subsystem: Prepares messages for sending and extracts data from received messages
- SNMP security subsystem: Provides message security services
- SNMP access control subsystem: Provides authorization services
- SNMP command generator: Initiates request PDUs and processes the responses
- SNMP command responder: Receives request PDUs destined for the local system
- SNMP notification originator: Monitors a system and generates trap messages
- SNMP notification receiver: Listens for notification messages and generates response messages
- SNMP proxy forwarder: Forwards SNMP messages

With this improved architecture, the authentication mechanism provides a check to ensure that the received message was transmitted by the principal in the header, that no alteration occurred during transit, and that there was no purposeful delay or replay. The Data Encryption Standard (DES) algorithm is used to maintain privacy between a principal and a remote engine. The capability to allow different access levels in the agent configuration provides more granular access control.

SNMPv3 introduces cryptographic security:
- Confidentiality: Provides encryption to prevent eavesdropping by an unauthorized source.
- Integrity: Ensures that data has not been tampered with while in transit and includes a packet replay protection mechanism.
- Authentication: Establishes that the message is from a valid source.

Secure Protocol Use Cases
Use cases for secure protocols can be either business or system focused. Business use cases look less at technology and more at how the business can help users get the end result they are seeking. In a system user case, technology is used to help users get the end result they are seeking. This section discusses system use cases. Use cases vary in terms of levels of complexity and difficulty, but they primarily explain the interaction of systems and environments. The use cases presented here are examples of how many of the secure protocols described previously in this guide are applied.

Secure Web Communication
Because much of our daily activity is conducted via the Internet, web communication security is paramount in any organization. Depending on the protocol used, web communication security can involve one or more of the following: authentication, authorization, and message protection.

Using HTTPS for Web Communications
Use cases for deploying HTTPS in web communications are numerous. Whenever a website has any kind of nonpublic information, such as logins, HTTPS should be used. Some basic uses follow:
- A website that includes logins used only by administrators, such as an internal WordPress website
- User credentials that are required in a transaction, such as on bank websites, on sites that accept credit card payments, and with medical information access (One of the most well-known examples is PayPal.)
- Session cookies in which user credentials are stored
- Cloud-based environment communications
- Media streaming to protect privacy and to keep third-party analytics from collecting viewer data (Perhaps the most well-known implementation example is Netflix.)
- A method to prevent man-in-the-middle content hijacking
- A way to prohibit phishing websites and protect brand identity

By far the most common use case for HTTPS is secure communication for sites that collect sensitive data. Generally, use of HTTPS has become the norm. According to Google’s Transparency Report, more than 50% of web pages loaded by desktop users are over HTTPS. In January 2017, Google began flagging HTTP pages that collect sensitive data as insecure.

Using SSL/TLS for Remote Access
Most devices inherently support SSL/TLS, so organizations do not need to install client-side software. The main purpose of SSL/TLS is to secure data in transit. SSL/TLS can be used in many different ways. The following use cases are particular to securing remote access communications:
- Virtual environment application access
- Remote administrative functions
- SSL VPN
- Connection to an internal application over HTTPS

The most common use case for using SSL/TLS for remote access is an SSL VPN. SSL VPNs, which work at Layers 5 and 6 of the OSI model, are the preferred choice for remote access. Because SSL/TLS VPN access can be initiated via a web browser, organizations can take advantage of an IT cost reduction benefit.

Using DNSSEC for Domain Name Resolution
As discussed previously in this guide, DNS is inherently unsecure. The principle behind DNSSEC is that it functions as a way to provide a new PKI for authenticating Internet services. As DNSSEC becomes the foundation for secure Internet communication, use cases will continue to grow.

Consider the most common DNSSEC use cases:
- Protection from DNS cache poisoning
- PKI usage within DNS
- DNS-Based Authentication of Named Entities (DANE), which enables the validation of X.509 certificates tied to TLS using DNSSEC lookups
- SSH host fingerprint posting (SSHFP) in DNS

The most common use case for DNSSEC for DNS is protection from DNS poisoning. The Internet Society maintains ongoing statistics regarding the adoption of DNSSEC. Recent reports indicate that a majority of top-level domain (TLD) zones are signed.

Secure File Transfer Communication
FTP is not considered a secure protocol because it does not provide for any type of encryption during data transfer. In March 2017, the FBI issued a Private Industry Notification to healthcare providers outlining how cybercriminals were gaining access to personally identifiable information (PII) patient data via anonymous access on FTP servers.

Using FTPS and SFTP for File Transfer
SFTP and FTPS are more secure file transfer options than FTP, with strong authentication capabilities. Organizations should use FTPS when they need to transfer sensitive or confidential data between a client and a server that is configured to use SSL for secure transactions.

SFTP is easier to implement in regard to firewalls because only port 22 needs to be opened. FTPS, on the other hand, uses multiple port numbers because it uses a control channel and opens new connections for the data transfer. Here are some of the most common use cases for FTPS and SFTP:
- Publishing files on an internal web portal
- Performing transparent FTP tunneling
- Downloading files from servers that are located on the Internet through a DMZ
- Reducing risks during data exchanges
- Meeting compliance requirements
- Performing server-to-server file transfer
- Conducting large or bulk file transfers

One of the most common use cases for the implementation of FTPS and SFTP is compliance. Laws such as HIPAA, PCI DSS, SOX, and GLBA require secure file transfers to protect confidential data. Failing to implement proper protections can result in penalties and reputation damage.
Some organizations opt for using a managed file transfer (MFT) service or application to secure FTP communications. Using this type of solution provides secure internal, external, and ad hoc file transfers. Industries including healthcare, accounting, engineering, insurance, legal, and manufacturing commonly use MFT solutions.
 

Secure Email Communications
Like file transfer protocols, email protocols were not built with security in mind. Unprotected email leaves an organization vulnerable to attacks and disclosure of confidential data. Email can be secured via S/MIME, POP3S, and IMAPS.

Using S/MIME, POP3S, and IMAPS for Email
S/MIME requires a PKI infrastructure so that clients can be issued certificates. S/MIME is used for confidentiality and integrity. POP3S and IMAPS use SSL as a method to secure emails in transit between a POP server or an IMAP server and the client. Because no control governs how the message is transferred between external servers, end-to-end message protection is not guaranteed. Here are some common use cases for secure email:
- Protecting confidential user information such as credit card numbers
- Encrypting messages to prevent identity theft
- Securing internal client messages
- Protecting email passwords from easily being read by someone intercepting the traffic between a client computer and an email server

Because S/MIME is a client-based protocol, the most common use case for this protocol is securing internal client messages. The client side is responsible for protecting the message. The message is protected until the authorized recipient opens it. Organizations choose S/MIME when they want to secure messages from client to client because it is a cost-effective way to implement encryption and digital signing of email.
POP3S and IMAPS are mainly used to secure connections between client machines and their associated servers.
For example, Microsoft strongly recommends using TLS and SSL to secure communications between POP3 and IMAP clients and the Microsoft Exchange Client Access server. This use case is associated with protecting email passwords from easily being read by someone intercepting the traffic between a client computer and an email server.
Mail servers can also use DNSSEC verification to ensure that the server responsible for accepting email messages for the domain name is authentic and then retrieve the certificate fingerprint using secure mechanisms that bind the certificate to the domain.

Securing Internal Communications
Internal communications need to be secured not only from external threats but from internal threats as well. When business partners and vendors are able to access the same network and organizational users, additional measures to secure communication must be implemented. According to a recent Kaspersky report, 52% of businesses admit that the careless actions of employees put IT security at risk.

Using SRTP for Voice and Video
SRTP can secure voice and video. RFC 7201 lists several use cases in which SRTP can be implemented to secure voice and video:
- Media security for SIP-established sessions: This framework uses SIP with SDP procedures to exchange network addresses when the server endpoint has an SRTP-enabled server running.
- Media security for WebRTC sessions: In this implementation, JavaScript web application real-time media is transported using RTP and protected using a mandatory application of SRTP.
- IP Multimedia Subsystem (IMS) security: IMS media security uses end-to-access-edge security. SRTP is terminated in the first node in the core network.
- Real-Time Streaming Protocol: Using TLS-protected signaling, the client and server agree on the secure media transport of SRTP over UDP when doing the setup request and response.

Perhaps the most common use case for securing voice and video with SRTP is the first use case: security for SIP-established sessions. Cisco has published an extensive white paper on securing Internet telephony media with SRTP and SDP. It is a guide for applying SRTP to voice, fax, and other IP telephony media for engineers and network administrators.
An everyday use case for SRTP is videoconferencing with Skype Connect, which uses TLS and SRTP to encrypt SIP messages and media streams between Skype and the organization’s communication platform.

Using LDAPS for Directory Services
Much of organization communication is not restricted to the internal infrastructure, so encryption is recommended when LDAP is used over an insecure network. LDAPS works by using TLS to authenticate the connection between the LDAP client and the LDAP server. The data exchanges are then encrypted by a TLS-supported cipher suite. The following are some common use cases for LDAPS:
- Establishing an encrypted tunnel between an LDAP client and a Windows domain controller (DC)
- Securing LDAP subprotocols such as LDAP bind
- Preventing attackers from using network-monitoring software to read LDAP traffic between clients and DCs
- Using an application that integrates with AD and thus requires LDAP communication to be encrypted

Organizations generally use LDAPS to protect the authentication session when an application authenticates with Active Directory Domain Services (AD DS).
A well-documented use case for using LDAPS with AD-integrated applications is Oracle PeopleSoft. An SSL connection is established between PeopleSoft and LDAP. For this to work correctly, SSL must be configured in both PeopleSoft and on the directory server.

Using SNMPv3 with Routing and Switching
SNMPv3 is designed to provide added security to earlier versions of the SNMP protocol. For a network that is publicly accessible, it is best to use SNMPv3, which provides more secure access and encryption. Keep in mind that added security features on routers and switches result in reduced performance. Consider some use cases for SNMPv3 with routing and switching devices:
- Verifying that a message originated from a trusted source
- Validating that a packet has not been modified in transit
- Eliminating plaintext SNMP data on the network
- Securely monitoring interface counters, bandwidth usage, CPU load, and traps
- Securely backing up configuration files

The most common use case for SNMPv3 with routing and switching is to eliminate plaintext SNMP data on the network. SNMPv3 allows for granular control and advanced security mechanisms. It also does away with having to use the default read/write public community string that is accessible from anywhere. When SNMPv3 is used with routing and switching, common configurations include enforcing an SNMP view that restricts the download of full IP routing and ARP tables, using the maximum security level supported by SNMP managers, and using encrypted communication wherever possible.

Using Network Address Allocation
It is important to approach network address allocation with security in mind. Proper planning of IP address space across all layers of an organization network is critical to good traffic flow and adequate protection. Planning network address allocation entails dividing the network into subnets. Subnetting can be done for several reasons. If you have an IPv4 Class C address and 1,000 clients, you need to subnet the network or use a custom subnet mask to accommodate all the hosts.

Use cases for subnetting include the following:
- Network traffic control
- Improved network security
- Hosts arranged into different logical groups that isolate each subnet into its own mini-network
- Divisions based on business goals and security policy objectives
- Separation of branch offices
- Separation of intranets and extranets

The most common use case for network subnetting is to control network traffic. Splitting one network into two or more and using routers to connect the subnets means that broadcasts can be limited to each subnet. However, often networks are subnetted to improve network security, not just performance. Subnet divisions can be based on business goals and security policy objectives. For example, perhaps you use contract workers and want to keep them separated from the organization employees. Organizations with branches often use subnets to keep the branches separate. Other instances of subnetting include intranets and extranets.
When subnetting for IPv4 is done, an IP address usually originates from one of the IP address classes and default subnet masks listed above.

IPv4 Address Class, IP Range, and Default Subnet Mask

Notice that the 127 network address is missing. Although the 127.0.0.0 network is technically in the Class A area, using addresses in this range causes the protocol software to return data without sending traffic across a network. For example, the address 127.0.0.1 is used for TCP/IPv4 loopback testing, and the address 127.0.0.2 is used for testing purposes.
Special ranges in each IP address class are used specifically for private addressing. These addresses are not considered routable on the Internet.

Take a look at the private address ranges:
- Class A: 10.0.0.0 network. Valid host IDs are from 10.0.0.1 to 10.255.255.254.
- Class B: 172.16.0.0 through 172.31.0.0 networks. Valid host IDs are from 172.16.0.1 through 172.31.255.254.
- Class C: 192.168.0.0 network. Valid host IDs are from 192.168.0.1 to 192.168.255.254.

To denote the network prefix for a subnet mask, the number of bits in the prefix is appended to the address with a slash (/) separator. This type of notation is called classless interdomain routing (CIDR). Consider an example: A Class C internal address 192.168.0.0 with subnet mask 255.255.255.0 is written as 192.168.0.0/24.
IPv6 is designed to replace IPv4. IPv6 addresses are 128 bits instead of the 32 bits used in IPv4. IPv6 addresses are represented in hexadecimal. In IPv6, subnets use IPv6 addresses with 64 bits for the host portion. These addresses can be further subnetted, just as in IPv4. IPv6 is based on the concepts of variable-length subnet masking (VLSM) and CIDR. VLSM allocates IP addresses to subnets based on individual need instead of as a general network-wide rule. An example of CIDR notation for IPv6 is 2001:db8::/32, designating the address 2001:db8:: with a network prefix that consists of the most significant 32 bits. Just as in IPv4, blocks of addresses are set aside in IPv6 for private addresses. In IPv6, internal addresses are called unique local addresses (ULAs). Addresses starting with fe80: are called link-local addresses and are routable only in the local link area.

This is an example of securing internal client messages. Notice the IP addresses, subnet masks, and default gateway.


A segmented network

Watch for scenarios or examples similar to Figure 17.2, which ask you to identify a correct or incorrect subnet mask, default gateway address, or router.
Notice above that the subnets 192.168.1.0 and 192.168.2.0 are identified next to the router. These are not valid IP addresses for a network router; they are used to identify the 192.168.1.x and 192.168.2.x networks in routing tables.
Allocating network addresses can be done either statically or dynamically. Often client addresses are assigned via Dynamic Host Configuration Protocol (DHCP). This method is much easier than manual configuration, and DHCP has the capability to push out DNS configuration changes. DHCP servers face many of the same security problems associated with other network services, such as DNS servers.

Using Time Synchronization
Network Time Protocol (NTP) is a UDP communication protocol used to synchronize devices with a network time server. NTP time servers are arranged in a hierarchy, much like domain name servers. Accurate time is necessary for many network operations. Here are some use cases for time synchronization:
- Time-synchronized encryption and protocols such as Kerberos
- Time stamps in logs to track security breaches
- The modification times in shared filesystems
- Billing services and applications
- Regulatory mandates that require accurate time stamping
- Channel-based audio
- Surgical operations that are run simultaneously
- Digital certificates

Like many other older protocols, NTP has weaknesses. Exploitation of NTP weaknesses can result in time alterations and DoS attacks that shut down the server. In 2007, the Internet Engineering Task Force (IETF) began work on Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for NTP. NTS was submitted for review several years ago, and as of 2020, it was an approved draft RFC awaiting publication as a standard.

Using Subscription Services
Technology is advancing at a very fast rate, and organizations often have a hard time keeping up. We now have anything as a service (XaaS) to help. With this business model, companies offer services that are delivered via the Internet. Subscription services are part of XaaS, and they enable organizations to avoid the expense of upgrading hardware and software. The organization pays a monthly fee for a certain number of users or devices, and the service provider takes care of the software or hardware requirements.

One of the most prominent subscription services is Microsoft Office 365, which bundles Office 365 with Windows 10. Consider some additional use cases for subscription services:
- Gateway antivirus and antispyware
- Web and application filtering
- IPSs/IDSs
- Network automation and data analytics
- Malware detection and quarantining
- Desktop and server hardware

Using a subscription model for IT offers direct benefits. For example, subscription services might be good for smaller organizations that would not be able to afford the outright purchase of hardware or software. Subscription services can also benefit larger organizations, especially with hardware.
Remember that anything as a service (XaaS) refers primarily to the vast array of services available over the Internet via cloud computing technologies.
For example, take a look at the Microsoft 365 use case. If an organization has to replace thousands of PCs to meet the hardware requirements of Windows 10, it must provide the cost of the new machines and then deal with all the old hardware. Under a subscription service, Microsoft takes care of having equipment to run the OS; the user merely needs a browser.
Regarding security and subscription services, organizations choose a provider they can trust. Uptime, level of service, and security are all spelled out in a service-level agreement (SLA).

Quiz:
1. Which one of the following ports would block outgoing email? A. 25 B. 110 C. 443 D. 22
2. Which of the following protocols use SSH? (Select two.) A. SCP B. FTPS C. SFTP D. SSL
3. What two primary security services does the asymmetric key standard defining IPsec provide? A. DNSSEC and S/MIME B. SRTP and LDAPS C. SMTP and SNMPv3 D. AH and ESP

Answer 1: A. Port 25 would block outgoing email. This is the unsecured port for SMTP, which sends mail. Answer B is incorrect as this is the port for POP3, which is used to retrieve email. Answer C is incorrect, as this is the port for secure web access over HTTPS. Answer D is incorrect, as this is the port used for SSH and SFTP.
Answer 2: A and C. Both SCP and SFTP use SSH. Do not get confused here. SSH FTP (SFTP) uses SSH, whereas FTP Secure (FTPS) uses SSL. SSL does not use SSH either. Therefore, answers B and D are incorrect.
Answer 3: D. The asymmetric key standard defining IPsec provides two primary security services: Authentication Header (AH), which provides authentication of the data’s sender, along with integrity and nonrepudiation, and Encapsulating Security Payload (ESP), which supports authentication of the data’s sender and encryption of the data being transferred, along with confidentiality and integrity protection. Answers A, B, and C are incorrect because DNSSEC was developed to strengthen DNS through the use of digital signatures and public key cryptography. S/MIME is a widely accepted technology for sending digitally signed messages. SRTP is used to secure VoIP or video network communications. LDAPS protects the authentication session when an application authenticates with Active Directory. SMTP, over port 25, is used for sending email. SNMPv3 is used to collect statistics from TCP/IP devices.