Home > Articles > Certification > Other IT

CompTIA Security+ Infrastructure Basics

This chapter discusses the concepts of identifying and mitigating network infrastructure threats and alerts you to the most common attacks.
This chapter is from the book

Terms you need to understand:

  • TCP/IP hijacking
  • Spoofing
  • Man-in-the-middle
  • Replay
  • DoS
  • DNS kiting and DNS poisoning
  • ARP poisoning
  • DMZ
  • VLAN
  • NAT
  • NAC
  • NIDS
  • HIDS
  • NIPS
  • Protocol analyzers

Techniques you need to master:

  • Differentiate between the different ports and protocols, their respective threats, and mitigation techniques.
  • Distinguish between network design elements and components.
  • Determine the appropriate use of network security tools to facilitate network security.
  • Apply the appropriate network tools to facilitate network security.
  • Explain the strengths and vulnerabilities of various security zones and devices.

The network infrastructure is subject to myriad internal and external attacks through services, protocols, and open ports. It is imperative that you understand how to eliminate nonessential services and protocols, especially if the network has been in existence for some period of time and some services are no longer needed or have been forgotten. To stop many would-be attackers, you must understand the different types of attacks that can happen, along with how to implement a network design, components, and tools that can protect the infrastructure.

This chapter discusses the concepts of identifying and mitigating network infrastructure threats and alerts you to the most common attacks. In addition to being able to explain these concepts, you will begin to understand how network design and components can be used as a tool to protect and mitigate all types of threats and to protect computers and network infrastructure.

Port and Protocol Threats and Mitigation Techniques

There are 65,535 TCP and UDP ports on which a computer can communicate. The port numbers are divided into three ranges:

  • Well-known ports—The well-known ports are those from 0 through 1,023.
  • Registered ports—The registered ports are those from 1,024 through 49,151.
  • Dynamic/private ports—The dynamic/private ports are those from 49,152 through 65,535.

Often, many of these ports are not secured and as a result are used for exploitation. Table 3.1 lists some of the most commonly used ports and the services and protocols that use them. All of these ports and services have vulnerabilities associated with them. Some of these were discussed in Chapter 2, “Online Vulnerabilities,” and some are discussed in this chapter. For those that are not discussed, such as Echo, Systat, and Chargen, you can find more detailed information in the “Suggested Reading and Resources” section at the end of this chapter.

Table 3.1. Commonly Used Ports

Port

Service/Protocol

7

Echo

11

Systat

15

Netstat

19

Chargen

20

FTP-Data

21

FTP

22

SSH

23

Telnet

25

SMTP

49

TACACS

53

DNS

80

HTTP

110

POP3

111

Portmap

137, 138, 139

NetBIOS

161/162

SNMP

443

HTTPS

445

SMB

1,812

RADIUS

Ideally, the configuration process should start with installing only the services necessary for the server to function. Table 3.1 includes a combination of protocols that currently are in use and antiquated protocols that might still be in use on a network. These protocols may be configured open by default when an operating system is installed or by the machine manufacturer. Every operating system requires different services for it to operate properly. If ports are opened for manufacturer-installed tools, the manufacturer should have these services listed in the documentation. The next sections cover port and protocol threats and mitigation techniques.

Antiquated and Older Protocols

Notice in Table 3.1 that there are older protocols such as Chargen and Telnet. Although these may be older, you might find that these protocols and the ports they use are still accessible. For example, Finger, which uses port 79, was widely used during the early days of Internet, and today’s sites no longer offer the service. However, you might still find some old implementations of Eudora mail that use the Finger protocol, or worse, the mail clients have long since been upgraded, but the port used 10 years ago was somehow left open. The quickest way to tell which ports are open and which services are running is to do a Netstat on the machine. You can also run local or online port scans.

Older protocols that are still in use may leave the network vulnerable. Protocols such as Simple Network Management Protocol (SNMP) and domain name service (DNS) that were developed a long time ago and have been widely deployed can pose security risks, too. SNMP is an application layer protocol whose purpose is to collect statistics from TCP/IP devices. SNMP is used for monitoring the health of network equipment, computer equipment, and devices such as uninterruptible power supplies (UPSs). Many of the vulnerabilities associated with SNMP stem from using SNMPv1. Although these vulnerabilities were discovered in 2002, vulnerabilities are still being reported with current SNMP components. A recent Gentoo Linux Security Advisory noted that multiple vulnerabilities in Net-SNMP allow for authentication bypass and execution of arbitrary code in Perl applications using Net-SNMP.

The SNMP management infrastructure consists of three components:

  • SNMP managed node
  • SNMP agent
  • SNMP network management station

The device loads the agent, which in turn collects the information and forwards it to the management station. Network management stations collect a massive amount of critical network information and are likely targets of intruders because SNMPv1 is not secure. The only security measure it has in place is its community name, which is similar to a password. By default, this is “public” and many times is not changed, thus leaving the information wide open to intruders. SNMPv2 uses Message Digest Version 5 (MD5) for authentication. The transmissions can also be encrypted. SNMPv3 is the current standard, but some devices are likely to still be using SNMPv1 or SNMPv2.

SNMP can help malicious users learn a lot about your system, making password guessing attacks a bit easier. SNMP is often overlooked when checking for vulnerabilities because it uses User Datagram Protocol (UDP) ports 161 and 162. Make sure network management stations are secure physically and secure on the network. You might even consider using a separate management subnet and protecting it using a router with an access list. Unless this service is required, it should be turned off.

The best way to protect the network infrastructure from attacks aimed at antiquated or unused ports and protocols is to remove any unnecessary protocols and create access control lists to allow traffic on necessary ports only. By doing so, you eliminate the possibility of unused and antiquated protocols being exploited and minimize the threat of an attack.

TCP/IP Hijacking

Hijacking is the term used when an attacker takes control of a session between the server and a client. This starts as a man-in-the-middle attack and then adds a reset request to the client. The result is that the client gets kicked off the session, while the rogue machine still communicates with the server. The attacker intercepts the source-side packets and replaces them with new packets that are sent to the destination.

During web sessions, cookies are commonly used to authenticate and track users. While the authenticated connection is in session, an attacker may be able to hijack the session by loading a modified cookie in the session page. Session hijacking can also occur when a session timeout is programmed to be a long period of time. This provides a chance for an attacker to hijack the session.

Telnet type plain-text connections create the ideal situation for TCP hijacking. In this instance, an attacker watches the data being passed in the TCP session. At any point, the attacker can take control of the user’s session. This is why TCP/IP hijacking is also called session hijacking.

Forcing a user to reauthenticate before allowing transactions to occur could help prevent this type of attack. Protection mechanisms include the use of unique initial sequence numbers (ISNs) and web session cookies. The more unique the cookie, the harder it is to break and hijack. Additional preventative measures for this type of attack include use of encrypted session keys and Secure Sockets Layer (SSL) encryption.

Null Sessions

A null session is a connection without specifying a username or password. Null sessions are a possible security risk because the connection is not really authenticated. A program or service using the system user account logs on with null credentials, and in some web-based programs, the set of credentials used for authentication defaults to anonymous access when null credentials are given. A hacker or worm can exploit this vulnerability and potentially access sensitive data on the system.

The best example of this is file and print sharing services on Windows machines. The services communicate by using an interprocess communication share, or IPC$. You have likely seen this on Windows machines (see Figure 3.1).

Figure 3.1

Figure 3.1 A Windows IPC$ share.

These null sessions were created to allow unauthenticated hosts to obtain browse lists from Windows NT servers and to use network file and print sharing services. By default, Windows XP and Windows Server 2003 standalone servers are not vulnerable to null session attacks. However, backward compatibility with Windows 2000 and NT open up vulnerability to null session attacks.

On a vulnerable machine, even if you have disabled the Guest account, a null session can be established by using the net use command to map a connection using a blank username and password:

net use \\ip_address\ipc$ "" "/user:"

After a null session connection has been established, many possibilities exist. You can use commands such as net view to view a list of shared resources on the target machine. You also can use application programming interfaces (APIs) and remote procedure calls (RPCs) to enumerate information, escalate privileges, and execute attacks.

You could also control null session access by editing the Registry on Windows-based computers to restrict anonymous access:

  • Key—HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
  • Value—RestrictAnonymous
  • Type—DWORD
  • Value—1

The key default value is 0. Changing this value to 1, which is more restrictive, keeps a null session from seeing user accounts and admin shares. Changing the value to 2 is the most restrictive. This disables null session without explicit permissions. However, this setting may conflict with some applications that rely on null sessions. Keep in mind that even though you can change the Registry settings to try to prevent this type of attack, some tools sidestep this measure. If security is a major concern, you might have to consider not allowing any null sessions on your public and private networks.

Spoofing

Spoofing is a method of providing false identity information to gain unauthorized access. This is accomplished by modifying the source address of traffic or source of information.

In blind spoofing, the attacker sends only data and only makes assumptions of responses. In informed spoofing, the attacker can participate in a session and can monitor the bidirectional communications.

Services such as email, Web, and file transfer can also be spoofed. Web spoofing happens when an attacker creates a convincing but false copy of an entire website. The false site looks just like the real one: It has all the same pages and links. However, the attacker controls the false site so that all network traffic between the victim’s browser and the site goes through the attacker. In email spoofing, a spammer or a computer virus can forge the email packet information in an email so that it appears the email is coming from a trusted host, from one of your friends, or even from your own email address. If you leave your email address at some Internet site or exchange email with other people, a spoofer may be able to use your email address as the sender address to send spam. File-transfer spoofing involves the FTP service. FTP data is sent in clear text. The data can be intercepted by an attacker. The data could then be viewed and altered before sending it on to the receiver. These forms of attacks are often used to get additional information from network users to complete a more aggressive attack.

You should set up a filter that denies traffic originating from the Internet that shows an internal network address. Using the signing capabilities of certificates on servers and clients allows web and email services to be more secure. The use of IPsec can secure transmissions between critical servers and clients. This will help prevent these types of attacks from taking place.

Man in the Middle

The man-in-the-middle attack takes place when an attacker intercepts traffic and then tricks the parties at both ends into believing that they are communicating with each other. This type of attack is possible because of the nature of the three-way TCP handshake process using SYN and ACK packets. Because TCP is a connection-oriented protocol, a three-way handshake takes place when establishing a connection and when closing a session. When establishing a session, the client sends a SYN request, then the server sends an acknowledgment and synchronization (SYN-ACK) to the client, and then the client sends an ACK (also referred to as SYN-ACK-ACK), completing the connection. During this process, the attacker initiates the man-in-the-middle attack. The attacker uses a program that appears to be the server to the client and appears to be the client to the server. The attacker can also choose to alter the data or merely eavesdrop and pass it along. This attack is common in Telnet and wireless technologies. It is also generally difficult to implement because of physical routing issues, TCP sequence numbers, and speed. Because the hacker has to be able to sniff both sides of the connection simultaneously, programs such as Juggernaut, T-Sight, and Hunt have been developed to help make the man-in-the-middle attack easier.

If the attack is attempted on an internal network, physical access to the network will be required. Be sure that access to wiring closets and switches is restricted; if possible, the area should be locked.

After you have secured the physical environment, the services and resources that allow a system to be inserted into a session should be protected. DNS can be compromised and used to redirect the initial request for service, providing an opportunity to execute a man-in-the-middle attack. DNS access should be restricted to read-only for everyone except the administrator. The best way to prevent these types of attacks is to use encryption and secure protocols.

Replay

In a replay attack, packets are captured by using sniffers. After the pertinent information is extracted, the packets are placed back on the network. This type of attack can be used to replay bank transactions or other similar types of data transfer in the hopes of replicating or changing activities, such as deposits or transfers.

Protecting yourself against replay attacks involves some type of time stamp associated with the packets or time-valued, nonrepeating serial numbers. Secure protocols such as IPsec prevent replays of data traffic in addition to providing authentication and data encryption.

Denial of Service

The purpose of a denial-of-service (DoS) attack is to disrupt the resources or services that a user would expect to have access to. These types of attacks are executed by manipulating protocols and can happen without the need to be validated by the network. An attack typically involves flooding a listening port on your machine with packets. The premise is to make your system so busy processing the new connections that it cannot process legitimate service requests.

Many of the tools used to produce DoS attacks are readily available on the Internet. Administrators use them to test connectivity and troubleshoot problems on the network, whereas malicious users use them to cause connectivity issues.

Here are some examples of DoS attacks:

  • Smurf/smurfing—This attack is based on the Internet Control Message Protocol (ICMP) echo reply function. It is more commonly known as ping, which is the command-line tool used to invoke this function. In this attack, the attacker sends ping packets to the broadcast address of the network, replacing the original source address in the ping packets with the source address of the victim, thus causing a flood of traffic to be sent to the unsuspecting network device.
  • Fraggle—This attack is similar to a Smurf attack. The difference is that it uses UDP rather than ICMP. The attacker sends spoofed UDP packets to broadcast addresses as in the Smurf attack. These UDP packets are directed to port 7 (Echo) or port 19 (Chargen). When connected to port 19, a character generator attack can be run. Table 3.1 lists the most commonly exploited ports.
  • Ping flood—This attack attempts to block service or reduce activity on a host by sending ping requests directly to the victim. A variation of this type of attack is the ping of death, in which the packet size is too large and the system doesn’t know how to handle the packets.
  • SYN flood—This attack takes advantage of the TCP three-way handshake. The source system sends a flood of synchronization (SYN) requests and never sends the final acknowledgment (ACK), thus creating half-open TCP sessions. Because the TCP stack waits before resetting the port, the attack overflows the destination computer’s connection buffer, making it impossible to service connection requests from valid users.
  • Land—This attack exploits a behavior in the operating systems of several versions of Windows, UNIX, Macintosh OS, and Cisco IOS with respect to their TCP/IP stacks. The attacker spoofs a TCP/IP SYN packet to the victim system with the same source and destination IP address and the same source and destination ports. This confuses the system as it tries to respond to the packet.
  • Teardrop—This form of attack targets a known behavior of UDP in the TCP/IP stack of some operating systems. The Teardrop attack sends fragmented UDP packets to the victim with odd offset values in subsequent packets. When the operating system attempts to rebuild the original packets from the fragments, the fragments overwrite each other, causing confusion. Because some operating systems cannot gracefully handle the error, the system will most likely crash or reboot.
  • Bonk—This attack affects mostly Windows 95 and NT machines by sending corrupt UDP packets to DNS port 53. The attack modifies the fragment offset in the packet. The target machine then attempts to reassemble the packet. Because of the offset modification, the packet is too big to be reassembled, and the system crashes.
  • Boink—This is a Bonk attack that targets multiple ports rather than just port 53.

DoS attacks come in many shapes and sizes. The first step to protecting yourself from an attack is to understand the nature of different types of attacks in the preceding list.

Distributed DoS

Another form of attack is a simple expansion of a DoS attack, referred to as a distributed DoS (DDoS) attack. Masters are computers that run the client software, and zombies run software. The attacker creates masters, which in turn create a large number of zombies or recruits. The software running on the zombies can launch multiple types of attacks, such as UDP or SYN floods on a particular target. A typical DDoS is shown in Figure 3.2.

Figure 3.2

Figure 3.2 A DDoS attack.

In simple terms, the attacker distributes zombie software that allows the attacker partial or full control of the infected computer system.

Although DDoS attacks generally come from outside the network to deny services, the impact of DDoS attacks mounted from inside the network must also be considered. Internal DDoS attacks allow disgruntled or malicious users to disrupt services without any outside influence.

To help protect your network, you can set up filters on external routers to drop packets involved in these types of attacks. You should also set up another filter that denies traffic originating from the Internet that shows an internal network address. When you do this, the loss of ping and some services and utilities for testing network connectivity will be incurred, but this is a small price to pay for network protection. If the operating system allows it, reduce the amount of time before the reset of an unfinished TCP connection. Doing so makes it harder to keep resources unavailable for extended periods of time.

Subscribing to newsgroups and checking security websites daily ensures that you keep up with the latest attacks and exploits. Applying the manufacturer’s latest operating system patches or fixes can also help prevent attacks.

DNS Kiting

A newly registered domain name can be deleted or dropped with full refund of the registration fee during an initial five-day window called the add grace period (AGP). DNS kiting refers to the practice of taking advantage of this AGP to monopolize domain names without ever paying for them. How domain kiting works is that a domain name is deleted during the five-day AGP and immediately re-registered for another five-day period. This process is continued constantly, resulting in the domain being registered without actually paying for it.

DNS kiting can be done on a large scale. In this instance, hundreds or thousands of domain names are registered, populated with advertisements, and then canceled just before the five-day grace period. The amount of revenue generated by an individual kited domain is very small. However, there is no cost, and automation allows the registration of multiple domains.

Besides automatically registering domain names and placing advertising, domain kiters can track the amount of revenue generated. This is called domain tasting. It is used to test the profitability of domain names. The AGP is used as a cost-benefit period to determine whether traffic generated by the domain name can offset the registration cost.

The drawback for domain kiters is the chance that when the domain name is dropped at the end of the AGP, it will not be successfully re-registering.

DNS kiting can be eliminated if registrars such as the Internet Corporation for Assigned Names and Numbers (ICANN) stop the AGP practice, limit how many domains a client can register per day, or refuse to issue repeated refunds to the same client. It has also been suggested that if the ICANN portion of the registration fee were nonrefundable, the practice would stop.

DNS Poisoning

DNS poisoning enables a perpetrator to redirect traffic by changing the IP record for a specific domain, thus permitting the attacker to send legitimate traffic anywhere he chooses. This not only sends a requestor to a different website but also caches this information for a short period, distributing the attack’s effect to the server users. DNS poisoning may also be referred to as DNS cache poisoning because it affects the information that is cached.

All Internet page requests start with a DNS query. If the IP address is not known locally, the request is sent to a DNS server. There are two types of DNS servers: authoritative and recursive. DNS servers share information, but recursive servers maintain information in cache. This means a caching or recursive server can answer queries for resource records even if it can’t resolve the request directly. A flaw in the resolution algorithm allows the poisoning of DNS records on a server. All an attacker has to do is delegate a false name to the domain server along with a providing a false address for the server. For example, an attacker creates a hostname hack.hacking.biz. After that, the attacker queries your DNS server to resolve the host hacking.biz. The DNS server resolves the name and stores this information in its cache. Until the zone expiration, any further requests for hacking.biz do not result in lookups but are answered by the server from its cache. It is now possible for me to set your DNS server as the authoritative server for my zone with the domain registrar. If the attacker conducts malicious activity, the attacker can make it appear that your DNS server is being used for these malicious activities.

DNS poisoning can result in many different implications. Domain name servers can be used for DDoS attacks. Malware can be downloaded to an unsuspecting user’s computer from the rogue site, and all future requests by that computer will be redirected to the fake IP address. This could be used to build an effective botnet. This method of poisoning could also allow for cross-site scripting exploits, especially because Web 2.0 capabilities allow content to be pulled from multiple websites at the same time.

To minimize the effects of DNS poisoning, check the DNS setup if you are hosting your own DNS. Be sure the DNS server is not open-recursive. An open-recursive DNS server responds any lookup request, without checking where it originates. Disable recursive access for other networks to resolve names that are not in your zone files. You can also use different servers for authoritative and recursive lookups and require that caches discard information except from the com servers and the root servers. From the user perspective, education works best. However, it is becoming more difficult to spot a problem by watching the address bar on the Internet browser. Therefore, operating system vendors are adding more protection. Microsoft Vista’s User Account Control (UAC) notifies the user that a program is attempting to change the system’s DNS settings, thus preventing the DNS cache from being poisoned.

ARP Poisoning

All network cards have a unique 48-bit address that is hard-coded into the network card. For network communications to occur, this hardware address must be associated with an IP address. Address Resolution Protocol (ARP), which operates at Layer 2 (data link layer) of the Open Systems Interconnect (OSI) model, associates MAC addresses to IP addresses. ARP is a lower-layer protocol that is simple and consists of requests and replies without validation. However, this simplicity also leads to a lack of security.

When you use a protocol analyzer to look at traffic, you see an ARP request and an ARP reply, which are the two basic parts of ARP communication. There are also Reverse ARP (RARP) requests and RARP replies. Devices maintain an ARP table that contains a cache of the IP addresses and MAC addresses the device has already correlated. The host device searches its ARP table to see whether there is a MAC address corresponding to the destination host IP address. When there is no matching entry, it broadcasts an ARP request to the entire network. The broadcast is seen by all systems, but only the device that has the corresponding information relies. However, devices can accept ARP replies before even requesting them. This type of entry is known as an unsolicited entry because the information was not explicitly requested.

In addition, they can broadcast a fake or spoofed ARP reply to an entire network and poison all computers. This is known as ARP poisoning. Put simply, the attacker deceives a device on your network, poisoning its table associations of other devices.

ARP poisoning can lead to attacks such as DoS, man-in-the-middle attacks, and MAC flooding. DoS and man-in-the-middle attacks were discussed earlier in this chapter. MAC flooding is an attack directed at network switches. This type of attack is successful because of the nature of the way all switches and bridges work. The amount of space allocated to store source addresses of packets is very limited. When the table becomes full, the device can no longer learn new information and becomes flooded. As a result, the switch can be forced into a hub-like state that will broadcast all network traffic to every device in the network. An example of this is a tool called Macof. Macof floods the network with random MAC addresses. Switches may then get stuck in open-repeating mode, leaving the network traffic susceptible to sniffing. Nonintelligent switches do not check the sender’s identity, thereby allowing this condition to happen.

A lesser vulnerability of ARP is port stealing. Port stealing is a man-in-the-middle attack that exploits the binding between the port and the MAC address. The principle behind port stealing is that an attacker sends numerous packets with the source IP address of the victim and the destination MAC address of the attacker. This attack applies to broadcast networks built from switches.

ARP traffic operates at Layer 2 (data link layer) of the OSI model and is broadcast on local subnets. ARP poisoning is limited to attacks that are local-based, so an intruder needs either physical access to your network or control of a device on your local network. To mitigate ARP poisoning on a small network, you can use static or script-based mapping for IP addresses and ARP tables. For large networks, use equipment that offers port security. By doing so, you can permit only one MAC address for each physical port on the switch. In addition, you can deploy monitoring tools or an intrusion detection system (IDS) to alert you when suspect activity occurs.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020