Events Report

In today's complex security environments, understanding the full journey of network traffic across multiple security services can be challenging, often requiring manual correlation of disparate logs. The Cisco Secure Access Events Report revolutionizes this by providing unified, correlated visibility across all security and network events in your environment.

At its core, the report leverages a unique Event Correlation ID that intelligently stitches together every stage of a traffic flow. This ID is generated at the very inception of a network connection, typically based on its unique 5-tuple (source IP, source port, destination IP, destination port, and protocol). As the traffic then traverses your security stack, this same Event Correlation ID is consistently propagated across various enforcement points. For instance:

• When a packet first hits the Firewall, the Event ID is assigned.

• If that traffic is subsequently handed off to the Secure Web Gateway (SWG) for web filtering, the same ID is carried over.

• Should an Intrusion Prevention System (IPS) inspect the traffic or a Decryption engine process it, their respective logs will also bear this identical ID.

• Even for Zero Trust Access (ZTA) events, this ID ensures a continuous trace.

This powerful service chaining mechanism transforms what would typically be fragmented logs from different services into a clear, cohesive, end-to-end narrative of the traffic's journey from source to destination. This allows you to effortlessly trace the complete lifecycle of a single user request, understanding every security control applied and every action taken along its path.

This comprehensive view empowers you to:

• Streamline Troubleshooting: Quickly pinpoint the exact point where an issue occurred, whether it's a block, an allow, or an isolation event, significantly reducing investigation time.

• Verify Policy Enforcement: Confidently confirm that your intent-based security policies are being applied correctly and consistently across all services.

• Enhance Compliance Activities: Maintain a complete and auditable record of all network activities, providing the detailed insights needed for regulatory requirements.

• Perform Offline Traffic Flow Analytics: Export detailed correlated data for in-depth analysis, custom reporting, and automated processing.

By providing a holistic perspective aligned with your intent-based security policies, the Events Report significantly reduces the time and effort required to understand and manage your network's security posture, transforming raw event data into actionable intelligence.

In this section, you will learn about:

• Key Features of Events Report

• How to View the Events Report

• Event Type Specific Details

• Filtering and Search Options

• Known Limitations

• Unified Event Log: Correlates logs from Zero Trust Access (ZTA), Firewall, and Secure Web Gateway (SWG) platforms, mapping a single flow across the entire service stack using consistent identifiers.

• Single Action Record: Each packet flow action (Allow, Block, Isolate) is recorded and reported after eliminating duplicate events for the same packet. Currently, the action is not displayed globally across all correlated events; however, users can use correlation to identify where enforcement actions occur at different enforcement points.

• Security Events: The report includes correlated security events.

• Advanced Filtering and Search: The Events Report offers flexible filtering options. You can use the search box at the top of the table for quick filtering by event ID, destination IP address, port, rule name, source, and private resource. For more granular analysis, click the Filters button on the right of the search box to reveal an advanced set of filtering options on the right side of the page. Additional features include custom time range selection and table column configuration using the gear icon.

The Events Report provides correlated visibility across various event types, each with its own characteristics and specific data points. Understanding these nuances helps in effectively interpreting the report.

You can schedule Events Report exports to be delivered to your email at regular intervals. The scheduled report email includes an HTML table preview of the filtered report, a downloadable CSV file with all relevant event data, and a direct link to view the live report in the portal. Any filters and column customizations applied to the Events Report are reflected in the scheduled report, ensuring you receive only the data that matches your requirements.

Any filters, including complex Boolean logic applied via Advanced Search, and column customizations are reflected in the scheduled report, ensuring you receive only the data that matches your specific requirements.

Scheduling is available for all supported event types, allowing you to tailor automated reporting for your organization’s monitoring, auditing, and compliance needs. For detailed step-by-step instructions, see Schedule a Report.

Note

Data older than 30 days cannot be included in scheduled or exported reports.

The Events Report supports enhanced customization and search management with the following functions:

• Auto-Save of Search State: When you apply filters or customize columns, your current view is automatically saved. If you navigate away from the Events Report and then return, your last auto saved state including filters and column selections is automatically restored.
• Restore Options: Restore options will appear only when a previous state or changes exist to revert to. Restore options allow you to quickly revert your report view to a previous or default state.
  • Restore to default Layout: Revert the report to its original default view.
  • Restore to Previous State: Return to your last auto-saved view.

    This option is disabled if no previous state exists (such as on your first visit or before making changes).

The Events Report provides robust filtering and search capabilities to help you quickly narrow down and analyze significant security and network activities. You can use a combination of basic search box filters and advanced filter options to focus on specific events.

Basic Filters

Located directly above the Events Report table, these filters allow for quick, direct searches on common event attributes.

The following list highlights key filter attributes available in the Events Report. For a complete and current set of filter options, please refer to the Events Report user interface.

• Event Type: Filter by one or more categories (for example, DNS, Web, Firewall, ZTNA, Decryption). Event Type filters are displayed as selectable buttons at the very top of the table. Each button displays the event count for that type, and toggling a button instantly applies or removes the filter.

• Event ID: Filter by one or more unique correlation IDs. When searching for a specific Event ID, the report displays the complete flow of that request across different event types. You can enter multiple IDs (for example, ID1, ID2, ID3) to return results matching any of the specified IDs.

• Destination: Filter by destination IP address or resource (for example, FQDN, URL). When you click on a destination address in the Destination column, if it is an IP address, the system automatically converts this into an IP address search for that destination. Destination Country can now be selected from a type-ahead dropdown list, minimizing manual entry and improving accuracy.

• IP Address: Filter by a specific source or destination IP address. Currently, IP search is unified—searches are performed across both source and destination IP fields. Wildcard patterns are supported.

• Port: Filter by network port number. You can also exclude specific ports by selecting the Exclude checkbox.

• Rule Name: Filter by the name of the access rule applied to the request. Applicable to DNS, Web, Firewall, IPS, and ZTNA requests.

• Source: Filter by user identity or source IP address. IP address search supports wildcard patterns and attempts to match across multiple IP fields. Source Type (such as User, Device, or Network) and Browser/Browser Location filters are available where applicable.

• Private Resources: Filter by events related to designated private resources.

To ensure optimal performance and system stability, the Events Report operates with certain known limitations and boundaries. Understanding these helps manage expectations and provides context for specific behaviors.

This section details these aspects:

• Data Retrieval Limit (10,000 Offset)
• Understanding Data Availability (Missing Fields)
• Protocol-Specific Correlation Behaviors
• Known Issues and Ongoing Enhancements

The Events Report is designed to efficiently retrieve and display a large volume of data. However, to maintain system performance and responsiveness, there is a practical limit to the number of events that can be paginated and displayed in a single session.

• Limitation: The Events Report user interface (UI) allows navigation and display of events up to a maximum of 10,000 offsets.
• Behavior: If your search results contain more than 10,000 events, the UI will automatically prevent you from navigating beyond this 10,000-event threshold. This means you will not be able to view events that fall outside of this range through direct pagination.
• Implication: This boundary is implemented to prevent potential API errors and ensure a smooth user experience. If you need to analyze data beyond this limit, consider refining your search criteria (e.g., narrowing the time frame or applying more specific filters) to reduce the result set, or utilize the export functionality for offline analysis of larger datasets.

When reviewing events in the Events Report, you may observe that some fields appear blank or are not populated. This is expected behavior and typically indicates that the specific data was either not relevant to the event, not collected by the involved security service, or not enabled in your Cisco Secure Access configuration.

The availability of data in various fields depends on several factors:

• Enabled Services and Features: Many data points are only collected and displayed if the corresponding Cisco Secure Access service or feature is active and configured for the traffic flow.

  Example: If decryption is not enabled for a particular traffic type, fields related to Decrypt Action will be empty. Similarly, advanced threat-related fields may only be populated if relevant security modules are active.

• Policy Configuration: The presence of data in fields like Rule Name or specific Reason Codes often depends on whether a particular policy was matched or a specific security verdict (e.g., block, isolate) was generated. For allowed traffic, a Reason Code might be less specific or even empty if no explicit policy match or threat was involved.

  Posture Enforcement Status: Fields related to device posture, compliance, or specific client attributes will only be populated if device posture checks are enabled and applicable to the connection. If posture is not enabled or not relevant to the event, these fields will be blank.

  Traffic Type and Flow: Different types of traffic (e.g., DNS, Web, Firewall, ZTNA) inherently generate different sets of data. A field highly relevant for a Web event (like Content Category) might be irrelevant or empty for a Firewall event.

  Service Chaining and Data Propagation: While the Event Correlation ID ensures events are linked, not all data points are universally propagated across every service. Each service contributes its specific context to the overall correlated event. For instance, ZTNA may not log certain network-level protocols if its primary role is identity-based access.

What to do if a field is empty:

If you expect to see data in a particular field but find it blank, consider the following:

• Check your Cisco Secure Access configuration: Verify that the relevant services, features, and policies are enabled and correctly configured.

• Consider the traffic type: Is the field typically relevant for this type of event?

• Review the event context: For allowed connections, some fields (like Reason Code) may naturally be less detailed.

The Event Correlation ID aims to group logically related network activities. For certain protocols, this may result in a single correlation ID representing multiple underlying network events:

• ICMP Traffic Correlation: For Internet Control Message Protocol (ICMP) traffic, the correlation logic may group seemingly distinct events (such as traffic from different network hops, as seen in a traceroute) under a single Event Correlation ID. This is an intentional design to represent a single logical ICMP operation (for example, a traceroute or a series of pings) as one correlated event, even if it involves multiple intermediate network responses.

• Missing User ID in ZTNA Event Logs: In specific situations, particularly when Universal ZTNA (UZTNA) is enabled and an access block occurs before policy remediation, some ZTNA event logs may not include the User ID. This happens if the application cannot be identified, preventing the policy evaluation context from being fully set, which results in the User ID being absent from the event log.

• API Timeout Recovery and Graceful Degradation: While the 10,000 offset limit prevents direct errors, ongoing work aims to improve API timeout recovery and ensure graceful degradation for very large data requests.

• User-Friendly Error Messages: Efforts are underway to enhance the clarity and helpfulness of error messages across the application.

• Traffic Type Count Truncation for ZTA Client-based: For the ZTA Client-based traffic type, the digits in the count display may run out of space and be truncated.