Home > Articles > Cisco Certification > CCNP Security / CCSP > CCNP Security Firewall Cert Guide: Recording ASA Activity

CCNP Security Firewall Cert Guide: Recording ASA Activity

Chapter Description

To help you prepare for the CCNP Security Firewall 642-617 exam, this chapter covers System Time, Managing Event and Session Logging, Configuring Event and Session Logging, Verifying Event and Session Logging, and Troubleshooting Event and Session Logging.

Configuring Event and Session Logging

Configuring event and session logging consists of some or all of the following tasks:

  • Globally enabling system logging and configuring global logging properties
  • Optionally, disabling logging of specific messages
  • Optionally, changing the level of specific messages
  • Optionally, configuring message event filters that will govern which system messages to send to particular destinations
  • Configuring event destinations and specifying message filters that apply to each of those destinations

Configuring Global Logging Properties

To globally enable system logging and set general logging properties, navigate in ASDM to Configuration > Device Management > Logging > Logging Setup. The Logging Setup pane opens, as shown in Figure 6-5. In this pane, you can set several global logging properties.

Figure 6-5

Figure 6-5 Setting Global Logging Parameters

In Figure 6-5, the Enable Logging check box is selected. This is necessary because, by default, all logging on the security appliance is disabled. Options within this same pane, none of which are selected in the figure, are as follows:

  • Enable logging on the failover standby unit: Check this box to enable logging for a standby security appliance, if one exists. By default, if this box is not checked, only severity level 1 messages are available on the standby unit (severity level 1 messages on the standby unit are related to failover events). Failover configurations are discussed in a later chapter.
  • Send debug messages as syslogs: Check this box to redirect all debug output to system logs. By default, debug output is not included in system log messages. Checking this box redirects debug messages to logs as syslog message 711001, with severity level 7.
  • Send syslogs in EMBLEM format: Check this box to enable Cisco EMBLEM format for all log destinations other than syslog servers. EMBLEM format is designed to be consistent with the Cisco IOS format. Many event management solutions will not recognize EMBLEM format messages, however. It is used primarily for the CiscoWorks Resource Manager Essentials (RME) Syslog Analyzer.

In Figure 6-5, the Buffer Size setting is left at the default of 4096 bytes (valid sizes are from 4096 to 1048576 bytes). This pertains to the internal buffer, maintained in memory. When this buffer gets full, it is overwritten in circular fashion, with each new message overwriting the oldest message in the buffer. If you do not want to lose information to these overwrites, there are two options for preserving buffered log messages: sending the buffer contents to an FTP server or saving them to internal flash memory. In Figure 6-5, the check box for FTP Server is checked, and the Configure FTP Settings button has been clicked, opening the Configure FTP Settings dialog box on the right side of the figure.

To enable saving of buffer contents to an FTP server, in the Configure FTP Settings dialog box, check the Enable FTP Client check box and configure information on the FTP server address, directory path for storing buffer log contents, and a username and password used to log in to the FTP server. In Figure 6-5, a server is defined in the out-of-band (OOB) management network, at IP address; the /ASALogs directory of the FTP server is used for storage; the username is set to CiscoASA; and a password of CCNPSecurity is entered twice, the second time to verify it is entered correctly. Clicking OK would complete the FTP server definition.

If you were saving buffered log contents to internal flash memory, you would need to define two parameters: the maximum amount of flash memory to be used for storing log information, and the minimum free space to be preserved in flash memory. Selecting this option creates a directory named "syslog" on the device disk on which messages are stored.

Finally, Figure 6-5 leaves the default queue size of 100 for messages retained in the ASDM log buffer. The ASDM log buffer is a different buffer than the internal log buffer.

Once the FTP server window is completed and saved, clicking Apply in the Logging Setup pane will send the new settings to the security appliance.

The CLI commands generated by the changes made are as follows:

logging enable
logging ftp-bufferwrap
logging ftp-server /ASALogs CiscoPress CCNPSecurity

If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.

Two other settings that are global for syslog messages are the syslog Facility Code and whether messages carry a time stamp when sent by the security appliance. These settings are not made in the same pane in which the other settings are made.


To modify these settings, navigate to Configuration > Device Management > Logging > Syslog Setup. This pane is shown in Figure 6-6. In the Syslog Format area, at the top of the pane, you can set the Facility Code and enable/disable time stamps.

Figure 6-6

Figure 6-6 The Syslog Setup Pane

In Figure 6-6, the default syslog Facility Code of LOCAL4(20) is left unchanged. Syslog Facility Codes are included in messages sent to syslog servers. The codes are used by syslog servers to organize event messages as they arrive. Eight logging facilities are available, LOCAL0 to LOCAL7 (if set in decimal only, 16–23). LOCAL4(20) is the default setting for all Cisco ASA syslog events. In the figure, the check box to enable time stamps is selected. Click Apply to send the change to the security appliance.

The CLI command generated by the change is as follows:

logging timestamp

If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.

Altering Settings of Specific Messages

Sometimes a default system message does not contain any useful information, or the default severity assigned to a message is not suitable to a particular environment. In such cases, you can tune individual system messages by globally suppressing them or by altering their default severity. You tune these aspects in the Syslog Setup pane, also.

The Syslog ID Setup area comprises most of the Syslog Setup pane. The first option available is to change what message IDs are displayed in the main portion of this area. The default option is the display of all syslog message IDs. Other options available in the Show drop-down list are as follows:

  • Disabled syslog IDs: Display only message IDs that have been explicitly suppressed.
  • Syslog IDs with changed logging: Display only message IDs with severity levels that have been changed from their default values.
  • Syslog IDs that are suppressed or with a changed logging level: Display all message IDs that have been modified by being suppressed or having their default level modified.

To modify a specific message ID, click the message to select it, and then click the Edit button to open the Edit Syslog ID Settings dialog box, shown in Figure 6-7. In this dialog box, you can suppress (disable) a particular message or change its configured logging level.

Figure 6-7

Figure 6-7 Disabling a Message ID

In Figure 6-7, message ID 113007 has been selected for editing, and the Disable Messages check box has been selected. Clicking OK will configure global suppression of this particular message. Message 113007 is generated when a locked user account is unlocked by an administrator, and in this scenario, it has been decided that this information is unimportant—what is important is to log when an account is locked for excessive incorrect password attempts.

There are also times when you may want to log a particular message ID, but alter the severity level at which it is reported. You do so from the same Edit Syslog ID Settings dialog box. Click a message to select it, and then click the Edit button. Figure 6-8 shows an example of modifying the severity level of a syslog message.

Figure 6-8

Figure 6-8 Modifying a Syslog Message Severity Level

In Figure 6-8, message ID 106018 has been selected for modification. As you can see in the background, the default setting for this message ID is Critical (2). This particular message is generated if an ICMP packet is denied by an outgoing access list. Because outgoing filters do not exist by default on the security appliance, this means an administrator explicitly configured the security appliance to block such packets. However, given that an internal user generating a ping that is dropped by the security appliance would generate such a message, in this scenario it has been decided to alter the level from Critical to Notifications (5). Click OK to complete the modification of this message, and then click Apply to send these changes to the security appliance.

The CLI commands generated by the changes made are as follows:

logging message 106018 level Notifications
no logging message 113007

If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.

Configuring Event Filters

For each logging destination, you can configure filters (known as event lists) that determine which subset of all generated messages will be forwarded to that destination. You can configure such filters based on the following:

  • Event (message) severity only: For example, by specifying a maximum severity of 4 (Warnings), all messages with a severity of Warnings or higher (severity levels 0 to 4) would be forwarded to the logging destination. All messages with severities of 5 to 7 would be dropped.
  • Event classes: All system messages are grouped into event classes based on the subsystem that created the messages. For example, there is an event class for the Authentication subsystem.
  • A combination of event class and event severity: For example, all Authentication messages with a maximum severity of 4 (Warnings).
  • The message ID: Each message has a unique message ID. Therefore, you can select individual messages for forwarding to particular logging destinations.

Event lists are reusable groups of messages, which can be selected by a combination of event class and severity, or individually by message ID. When you create an event list, you can apply that same event list to multiple logging destinations, thus simplifying the configuration of message filters.

To create an event list, navigate to Configuration > Device Management > Logging > Event Lists. Click Add to create a new event list. This opens the Add Event List dialog box, which is shown in Figure 6-9. You assign a unique name to each event list, and then configure the parameters that define your desired filter.

Figure 6-9

Figure 6-9 Configuring an Event List

In Figure 6-9, a name of ALERT_ADMIN_BY_EMAIL has been defined. The Add button in the Event Class/Severity Filters area was clicked to open the Add Class and Severity Filter dialog box, in which a specific class and severity can be defined. In this example, All Event Classes has been selected, and a severity level of Alerts (1) has been selected. In this scenario, it has been determined that any syslog message of severity 0 or 1 should generate an immediate email notification to an administrator (setup of the SMTP log destination is covered in the "Email" section of this chapter). This event list will accommodate such a configuration. Click OK twice to complete the configuration of the event class filter and the creation of the event list. Finally, click Apply to send the configuration to the security appliance.

The CLI command generated by the change is as follows:

logging list ALERT_ADMIN_BY_EMAIL level Alerts

If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.

Configuring Individual Event Destinations

After you have enabled logging globally, optionally set up global logging properties, and optionally configured event lists, you can configure the security appliance to send logging messages to one or more logging destinations. For each destination, you specify a filter that will select a subset of generated messages to be forwarded to that destination.

To configure logging destinations and filters, navigate to Configuration > Device Management > Logging > Logging Filters. In the Logging Filters pane that opens, you can activate logging to any of the eight available destinations and configure filters that determine which generated messages are forwarded to each.

Internal Buffer

The first example will be to configure the internal buffer as a logging destination. In the Logging Filters pane, select the Internal Buffer destination, and click Edit to open the Edit Logging Filters dialog box, shown in Figure 6-10.

Figure 6-10

Figure 6-10 Configuring the Internal Buffer Logging Filter

As you can see in Figure 6-10, you have several options for determining the logging filter for a particular log destination. To create a filter that applies to all event classes, choose one of the following radio buttons in the top, Syslogs from All Event Classes area:

  • Filter on severity: Filters system log messages by their severity level, and allows you to specify the level of messages that should be forwarded to the log destination. In Figure 6-10, this choice is selected, and the filter level is set to Debugging, which sends all system messages to the destination being configured (internal buffer). Depending on traffic, this particular choice can overwhelm the destination service (especially the console) or the user attempting to analyze events. You should carefully consider the impact of your choice before applying the configuration to the security appliance. If you wish to log all messages from all severity levels, it is strongly recommended that you do so to the internal buffer, and never to the console. In fact, it is generally recommended to leave console logging disabled.
  • Use event list: Filters system log messages based on a previously defined event list, and allows you to specify which event list to use, or create a new event list.
  • Disable logging from all event classes: Disables all forwarding of system messages to the destination being configured.

You can also create specific logging filters in this dialog box by entering the filter criteria in the Syslogs from Specific Event Classes area. This is equivalent to creating an event list for just this specific logging destination.

Click OK to complete the configuration of a logging filter to the internal buffer logging destination. Click Apply to send the modified settings to the security appliance.

The CLI command generated by the change made is as follows:

logging buffered Debugging

If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.


Cisco ASDM contains a powerful event viewer that you can use to display a real-time message feed from the security appliance. This event viewer is particularly useful when you are troubleshooting security appliance software and configuration issues, or when you are monitoring real-time activity over the security appliance.

You enable logging to the internal ASDM event viewer by configuring the ASDM logging destination and specifying a logging filter, in the same manner as for other logging destinations. Messages are forwarded to ASDM over the HTTPS session and are displayed in a log viewer window at the bottom of the ASDM Home page.

This example assumes that the ASDM logging destination has been configured to receive messages from all event classes, containing a maximum severity level of Informational. Click Apply to send the modified settings to the security appliance.

The CLI command generated by the change made is as follows:

logging asdm Informational

If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.


To use the full event viewer functionality, start the viewer by navigating in ASDM to Monitoring > Logging > Real-Time Log Viewer, selecting a logging level, and clicking the View button. The ASDM Real-Time Log Viewer opens in a dedicated window and starts displaying log messages as selected by the configured message filter. Figure 6-11 shows an example of the Real-Time Log Viewer.

Figure 6-11

Figure 6-11 Real-Time Log Viewer

In the Real-Time Log Viewer, you can set additional keyword-based filtering by entering a keyword in the Filter By field in the log viewer toolbar. Above this field are toolbar icons that can be used to pause, resume, and clear the event display, copy individual messages to the clipboard, and set message colors.

The log viewer interface also allows you to select a particular message, and invoke various options by right-clicking it. You can, for example, show or even create specific access rules based on log messages. For example, if a log message showed that a packet had been denied by an access rule, you could immediately create a rule to allow such packets in the future. Or, for all session-related messages, you could right-click the interface and select Show Access Rule to jump immediately to the table of access rules and to the exact rule permitting or denying this particular connection.

At the bottom of the Real-Time Log Viewer, a context-sensitive help window shows message descriptions, recommends actions to administrators, and offers full message details. This is the only tool in ASDM that provides an administrator with such detailed explanations of log messages. Additionally, the suggestion of remedies is an invaluable aid in rapid troubleshooting and resolution of identified problems.

You can also use ASDM to view a snapshot of the current appliance internal log buffer, by navigating to Monitor > Logging > Log Buffer, selecting a maximum severity level, and clicking View.

Syslog Server(s)

Probably the most common destination to configure for log messages is one or more syslog servers in your network. Configuring the security appliance to send logs to syslog servers enables you to easily archive logs, limited only by the available disk space on the remote syslog server. You can specify up to 16 syslog servers as log destinations. Further, the security appliance can deliver syslog messages to servers using either UDP (standard syslog) or TCP (specialized for firewall syslog) as transport protocols.

Prior to ASA software version 8.0, all syslog messages were transferred in clear text. Beginning with software version 8.0(2), support was introduced for secure logging, using a SSL/TLS transport layer between the security appliance and syslog servers. Certificate-based authentication and encrypted data transfer help mitigate security threats to the logging service when messages are crossing an untrusted network. To use secure logging, you must set up an SSL/TLS connection between the security appliance and a remote syslog server supporting SSL/TLS. Also, the SSL syslog server must be added to the ASA as a certificate trust point. Configuration of secure logging is not covered in this book, but more information can be obtained from the Cisco ASDM User Guide available at Cisco.com.


When a security appliance is configured to use TCP-based syslog to at least one syslog server, by default, the security appliance will block all traffic attempting to go through the appliance if the TCP-based syslog server is down or unable to record further messages in its logs (that is, it is out of disk space). This feature is designed to prevent traffic from traversing a security appliance that is unable to log events, a common requirement in high-security networks. Use this feature if your local security policy requires this level of risk control.

To configure (non-SSL/TLS) syslog servers as log destinations, navigate to Configuration > Device Management > Logging > Syslog Servers. In the Syslog Servers pane, click Add to define a new syslog server log destination. The Add Syslog Server dialog box opens, as shown in Figure 6-12. Here, you define which interface the security appliance uses to reach the server, the server's IP address, whether to use TCP or UDP as the transport protocol, the destination port on the server, and, optionally, the use of EMBLEM format (only if using UDP) or SSL/TLS encryption (only if using TCP).

Figure 6-12

Figure 6-12 Adding a Syslog Server Destination

In Figure 6-12, a syslog server is defined, reachable through the management interface (in the OOB management network), using IP address, and standard UDP-based syslog transport to port 514 (the default UDP port; the default TCP port is 1470). Click OK to complete the configuration of this server.

If you are using TCP-based syslog, you have the option to allow user traffic to traverse the ASA even when the TCP syslog server is down. To do so, in the main Syslog Servers pane, check the Allow User Traffic to Pass when TCP Syslog Server Is Down check box and then click Apply to send the new server definitions to the security appliance. Selecting this option generates the logging permit-hostdown command in the security appliance configuration.

After you have defined one or more syslog servers, you must configure a logging filter for the destination syslog servers, before the security appliance actually sends event messages to the configured servers. You do this the same way as covered previously. This example assumes that you have configured a logging filter to send all event classes, with a maximum severity of Warnings (4) to the logging destination of syslog servers.

The CLI commands generated by the changes made are as follows:

logging trap Warnings
logging host management

If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.

In most cases, using remote syslog servers as the primary method of reporting events to a central repository is recommended, as syslog is a widely supported and easily deployed logging protocol. Because UDP transport does not guarantee delivery, and should be used only over trusted or OOB networks, you should consider the use of TCP-based syslog when operating over a congested network subject to frequent packet loss. Also, consider the use of SSL/TLS if you are using untrusted ("sniffable") transport networks between the security appliance and the syslog server.


Sending log messages to an email system is useful, as it provides a simple way to integrate event notification with many messaging solutions, including simple email, mobile email, and SMS or pager systems, using appropriate gateways.

Configuring the security appliance to send email notifications is similar to configuring syslog servers, in that you must first define how the security appliance reaches intended recipients (sender and receiver addresses, SMTP servers, and so on), and then create a logging filter instructing the security appliance to use email as a logging destination and what events to send.

To configure email sender and recipient addresses, navigate to Configuration > Device Management > Logging > E-Mail Setup. Enter a source email address in the provided field, and then click the Add button to add recipient information. Figure 6-13 shows an example, where a source address of ASA@CiscoPress.CCNP has been entered in the Source E-Mail Address field.

Figure 6-13

Figure 6-13 Adding an Email Recipient

In the Add E-Mail Recipient dialog box, the Destination E-Mail Address field has been completed with Admin@CiscoPress.CCNP as the recipient. Finally, the maximum severity of event messages that should generate an email to this recipient is configured in the Syslog Severity field, as Alerts.

After you have configured recipients, you must configure the security appliance with information about the SMTP server(s) through which the security appliance will send notifications. To do this, navigate to Configuration > Device Management > Logging > SMTP. The SMTP pane, as shown in Figure 6-14, is where you configure a primary and, optionally, secondary SMTP server address for the security appliance to send email through.

Figure 6-14

Figure 6-14 Defining SMTP Servers

Figure 6-14 shows an example where two SMTP servers on the DMZ network— as primary and as secondary—are configured.

After configuring sender and recipient addresses and SMTP servers, you configure email notifications just like any other logging destination. In this example, however, rather than simply set a maximum severity for all event classes, Figure 6-15 shows the configuration of a logging filter for the E-Mail destination, using the previously created event list named ALERT_ADMIN_BY_EMAIL.

Figure 6-15

Figure 6-15 Configuring Email Logging Filter

It is important to limit the amount of notifications sent via email, so use this destination only for exceptional events of critical importance. In this example, recall that event list ALERT_ADMIN_BY_EMAIL was defined with a maximum severity level of Alerts (1). This example might be overly restrictive, so use an appropriate level based on your local security policy.

Click OK in the Edit Logging Filters dialog box, and then click Apply in the Logging Filters pane, to complete the configuration of email as a logging destination.

The CLI commands generated by the changes made are as follows:

logging from-address ASA@CiscoPress.CCNP
logging recipient-address Admin@CiscoPress.CCNP level Alerts

If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.


To configure NSEL in the security appliance, you must first configure NetFlow export destinations by defining the location of NetFlow collectors. To do so, navigate to Configuration > Device Management > Logging > NetFlow. In the NetFlow pane, shown in Figure 6-16, you can configure NetFlow destinations, and also some options that might impact performance with NetFlow export enabled.

Figure 6-16

Figure 6-16 Configuring NetFlow Settings

In Figure 6-16, a NetFlow collector has been defined through the management interface, with IP address, and the default NetFlow port of UDP 2055. Additionally, the option Delay Transmission of Flow Creation Events for Short-Lived Flows has been enabled, and the delay set to 10 seconds. Finally, because use of NetFlow makes some syslog messages redundant, the option to Disable Redundant Syslog Messages has been selected. (Neither of the preceding options is enabled by default.)

Defining flows to be exported to NetFlow collectors is unique among logging destinations. With NSEL, you can granularly select which flows through the security appliance are exported using NetFlow, based on flow properties such as IP addresses, protocols, and ports. You configure this selection using Cisco Modular Policy Framework (MPF) service policies, which are covered in a later chapter.

The CLI commands generated by the changes made are as follows:

no logging message 106015
no logging message 106023
...output omitted...
flow-export delay flow-create 10
flow-export destination management 2055

If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.

Telnet or SSH Sessions

To enable the security appliance to display system event messages in Telnet or SSH sessions, you can configure a logging filter for the Telnet and SSH Sessions destination, like any other destination. This generates the logging monitor command in the security appliance's configuration file. Although these messages are sent to the Telnet or SSH session, the user must also use the terminal monitor command to see the messages displayed in their remote terminal session.

6. Verifying Event and Session Logging | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

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


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press 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.


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.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.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.


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


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


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.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. 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.ciscopress.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.


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